Aktuelles

Hertzbleed: CPU verrät Kryptokeys durch Taktänderungen

Thread Starter
Mitglied seit
06.03.2017
Beiträge
65.617
hertzbleed.jpg
Wenig überraschend gibt es in der Klasse der Seitenkanal-Attacken (side-channel attacks) nun eine weitere Methode, Daten aus einem System auszulesen, ohne dass dafür vorgesehene Sicherheitsvorkehrungen dies verhindern können. In der von den Wissenschaftlern beschriebenen Methode ist es möglich, gesicherte Krypto-Schlüssel auszulesen.
... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.

Crizzo

Enthusiast
Mitglied seit
05.09.2005
Beiträge
135
getauchte = getaufte

Nehme ich mal an.

Crazy 😬
 
  • Danke
Reaktionen: Don

freakyd

Enthusiast
Mitglied seit
03.03.2007
Beiträge
3.597
Ort
Traunstein
Crazy shit... indeed :d
 

passat3233

Enthusiast
Mitglied seit
01.05.2007
Beiträge
3.676
Naja, die Aussage, das es "alle" Intel-Prozessoren betrifft, stimmt so nicht.
Es betrifft alle Intel-Prozessoren, die eine Taktänderung erlauben.
Alte Prozessoren, wie z.B. ein Pentium 2/3 o.Ä. die nur mit einem festen Takt arbeiten, sind also nicht betroffen.
 

Don

[printed]-Redakteur, Tweety
Mitglied seit
15.11.2002
Beiträge
34.276
Naja, die Aussage, das es "alle" Intel-Prozessoren betrifft, stimmt so nicht.
Es betrifft alle Intel-Prozessoren, die eine Taktänderung erlauben.
Alte Prozessoren, wie z.B. ein Pentium 2/3 o.Ä. die nur mit einem festen Takt arbeiten, sind also nicht betroffen.
Das ist richtig, aber ich denke in der Aussage steckt so auch mit drin, dass Nutzer eines Pentium 2, von denen es nicht mehr viele im Alltagsbetrieb geben wird, sich um die Sicherheitslücke keine Gedanken machen müssen. Stattdessen sind aber alle im Einsatz befindlichen Intel-Prozessoren tatsächlich auch davon betroffen.
 

sch4kal

Enthusiast
Mitglied seit
18.07.2016
Beiträge
3.232
Theoretisch reicht es ja dann aus, Speedstep zu deaktivieren ?
 

Don

[printed]-Redakteur, Tweety
Mitglied seit
15.11.2002
Beiträge
34.276
Ja, die Angaben sind etwas inkonsistent oder? Erst dachte ich alle Zen-3-Prozessoren sind ausgenommen. Wei Ryzen 5000 Desktop fehlt, Ryzen 6000 Mobile und die 3. EPYC-Generation ebenfalls. Aber die 3. Generation Ryzen-Threadripper stehen drin.
 

Liesel Weppen

Experte
Mitglied seit
20.07.2017
Beiträge
4.533
Das klingt nach einem sehr theoretischen Szenario.

Man will aus Taktratenschwankungen Rückschlüsse auf einen berechneten Kryptokey ziehen... Ich kann mir durchaus vorstellen, das das klappen könnte, WENN man weiß, das diese CPU oder dieser eine Kern gerade eben einen Kryptokey berechnet hat und zwar NUR das und eigentlich muss man dazu sogar den Algorithmus der den Key berechnet hat mindestens auf ASM Ebene kennen. Da solche System aber idR nicht nur Kryptokeys berechnen und auch immer noch irgendwas anderes nebenbei läuft, kann ich mir nicht vorstellen, das man das so isolieren kann.

Und vorallem will man das ja so wie ich das verstehe, noch nichtmal an dem Verlauf von Taktraten ansich erkennen, sondern aus der resultierenden Berechnungszeit?
Also wenn man weiß, welche CPU rechnet, die nix anderes nebenbei tut und dann rauskommt "das hat jetzt 567us gedauert" will man daraus den Kryptokey abgreifen können? Das heisst, es gäbe eine Zuordnung von jedem einzelnen Kryptokey zu einer bestimmten Berechnungsdauer. Das geht aber vom Verhältnis her schon nicht auf, selbst wenn man jeden einzelnen Takt mitzählt und damit die maximal mögliche zeitliche Auflösung nehmen könnte.
 

Woozy

Lesertest-Fluraufsicht
Hardwareluxx Team
Mitglied seit
19.10.2009
Beiträge
8.856
Ort
127.0.0.1
Das klingt nach einem sehr theoretischen Szenario.

Man will aus Taktratenschwankungen Rückschlüsse auf einen berechneten Kryptokey ziehen... Ich kann mir durchaus vorstellen, das das klappen könnte, WENN man weiß, das diese CPU oder dieser eine Kern gerade eben einen Kryptokey berechnet hat und zwar NUR das und eigentlich muss man dazu sogar den Algorithmus der den Key berechnet hat mindestens auf ASM Ebene kennen. Da solche System aber idR nicht nur Kryptokeys berechnen und auch immer noch irgendwas anderes nebenbei läuft, kann ich mir nicht vorstellen, das man das so isolieren kann.

Und vorallem will man das ja so wie ich das verstehe, noch nichtmal an dem Verlauf von Taktraten ansich erkennen, sondern aus der resultierenden Berechnungszeit?
Also wenn man weiß, welche CPU rechnet, die nix anderes nebenbei tut und dann rauskommt "das hat jetzt 567us gedauert" will man daraus den Kryptokey abgreifen können? Das heisst, es gäbe eine Zuordnung von jedem einzelnen Kryptokey zu einer bestimmten Berechnungsdauer. Das geht aber vom Verhältnis her schon nicht auf, selbst wenn man jeden einzelnen Takt mitzählt und damit die maximal mögliche zeitliche Auflösung nehmen könnte.
Das ist wie bei vielen anderen, über Jahre an Universitäten erarbeiteten Schwachstellen: Die sind in der Tat nur Theoretisch und in freier Wildbahn nie verfügbar. Keiner würde sich die Mühe machen die Oma von Nebenan damit anzugreifen.
 

Don

[printed]-Redakteur, Tweety
Mitglied seit
15.11.2002
Beiträge
34.276
Nicht die "Oma von Nebenan", aber womöglich gibt es ja Ziele, für die sich ein gewisser Aufwand dann schon lohnt. Sonst könnten sich die Hersteller und Cloud-Anbieter die Mitigationen ja auch sparen.
 

DragonTear

Enthusiast
Mitglied seit
06.02.2014
Beiträge
15.603
Ort
Im sonnigen Süden
Sowas ist spannend um Systeme anzugreifen wo man das Gerät dauerhaft in der Hand hat. Z.B. das konfiszierte iPhone von Staatsfeinden.

Dass man damit tatsächlich cloud Server angreifen könnte würde mich allerdings auch überraschen aus den von Liesel genannten Gründen.
 

sch4kal

Enthusiast
Mitglied seit
18.07.2016
Beiträge
3.232
Sowas ist spannend um Systeme anzugreifen wo man das Gerät dauerhaft in der Hand hat. Z.B. das konfiszierte iPhone von Staatsfeinden.

Dass man damit tatsächlich cloud Server angreifen könnte würde mich allerdings auch überraschen aus den von Liesel genannten Gründen.
Was im Falle des iPhones tatsächlich nix bringen würde, da das einen separaten Cryptoprozessor hat.

Gerade Cloudserver sind hier die Targets, weswegen die auch vorrangig an Mitigationslösungen interessiert sind, und im Vorfeld der Publikation, neben den CPU Herstellern, ebenfalls informiert wurden.
 

Havellaender

Experte
Mitglied seit
20.06.2016
Beiträge
353
Ort
Potsdam
Das klingt nach einem sehr theoretischen Szenario.

Man will aus Taktratenschwankungen Rückschlüsse auf einen berechneten Kryptokey ziehen... Ich kann mir durchaus vorstellen, das das klappen könnte, WENN man weiß, das diese CPU oder dieser eine Kern gerade eben einen Kryptokey berechnet hat und zwar NUR das und eigentlich muss man dazu sogar den Algorithmus der den Key berechnet hat mindestens auf ASM Ebene kennen. Da solche System aber idR nicht nur Kryptokeys berechnen und auch immer noch irgendwas anderes nebenbei läuft, kann ich mir nicht vorstellen, das man das so isolieren kann.

Und vorallem will man das ja so wie ich das verstehe, noch nichtmal an dem Verlauf von Taktraten ansich erkennen, sondern aus der resultierenden Berechnungszeit?
Also wenn man weiß, welche CPU rechnet, die nix anderes nebenbei tut und dann rauskommt "das hat jetzt 567us gedauert" will man daraus den Kryptokey abgreifen können? Das heisst, es gäbe eine Zuordnung von jedem einzelnen Kryptokey zu einer bestimmten Berechnungsdauer. Das geht aber vom Verhältnis her schon nicht auf, selbst wenn man jeden einzelnen Takt mitzählt und damit die maximal mögliche zeitliche Auflösung nehmen könnte.
Heisenberg lässt grüßen?
 

Dennis50300

Enthusiast
Mitglied seit
11.03.2012
Beiträge
2.789
Ort
Braunschweig
Ja geil, mein eigenhändiges OC festgetackert auf 4gHz ist direkt mal n Patch ja :ROFLMAO:

Gruss Dennis
 

Liesel Weppen

Experte
Mitglied seit
20.07.2017
Beiträge
4.533
Heisenberg lässt grüßen?
Dann hast du eine Wahrscheinlichkeit... dafür das ein Kryptokey berechnet wurde? Oder das der Kryptokey zu 10% genau dieser ist. Wissenschaftlich/Mathematisch sicherlich interessant, aber einen konkreten Kryptokey hast du dann immernochnicht.
 

Holt

Legende
Mitglied seit
05.07.2010
Beiträge
24.381
Das ist wie bei vielen anderen, über Jahre an Universitäten erarbeiteten Schwachstellen: Die sind in der Tat nur Theoretisch und in freier Wildbahn nie verfügbar.
Das würde ich auch so sehen, denn in einer Multithreadumgebung dürfte es schwer sein die Leistungsaufnahme eines Kernes genau diesem einen Vorgang zuzuordnen. Außerdem frage ich mich, wie man aus der Leistungsaufnahme mehr als bestenfalls die Länge des Passwortes ableiten könnte.
 

Holt

Legende
Mitglied seit
05.07.2010
Beiträge
24.381
Auch wenn die aufgeführten Beispiele doch etwas andere Szenarien sind
Ja, da geht es um ein System welches nur eine Aufgabe erfüllt und wo gibt es dies noch? Vor allem im Cloud oder generell Serverbereich? Zumal wenn die Services virtualisiert ist, kann man kaum noch einem Thread eine Kern zuordnen, ganz davon abgesehen, dass kaum nur ein SW Thread auf diesem einen Kern laufen wird.

Aber der Beispielcode ist auch maximal dumm geschrieben. So z.B.: for (int i = 0; i < strlen(correct_password); i++)
Wenn der Compiler den nicht ordentlich optimiert hat, bedeutet der Aufruf von strlen in jedem Durchauf der Schleife, dass strlen einmal über jede Buchstaben geht bis NULL gefunden wurden, die Schleife also viel länger dauert als hätte man das Ergebnis von strlen einmal in einer Variable gespeichert.

Sicherer wäre:
Code:
bool check_password(const char input[]){
  const char correct_password[] = "hunter2";
  bool Retval = true;
  int i =0;
  while (input[i] && correct_password[i]){
       if (input[i] != correct_password[i]) {
           Retval = false;
       }
       i++;
   }

   return Retval;
}
Dies verrät dann nur noch die Länge des Passwortes, aber nicht mehr wie viele Zeichen man schon richtig erraten hat. Das kann man aber auch noch recht einfach verhindern:
Code:
bool check_password(const char input[]){
  const char correct_password[] = "hunter2";
  bool Retval = true;
  int i =0;
  while (input[i] && correct_password[i]) {
       if (input[i] != correct_password[i]) {
           Retval = false;
       }
       i++;
   }
   while(input[i]) {
       if (input[i] != correct_password[0]) {
           Retval = false;
       }
       i++;     
   }

   return Retval;
}
Das if in der zweiten while Schleife dient nur dazu, dass deren Laufzeit möglichst genau der der ersten entspricht. Die Laufzeit ist jetzt proportional zur Länge des eingegeben Passworts und lässt keinerlei Rückschlüsse mehr auf das richtige Passwort zu. Manchmal ist eben weniger die Hardware die Schwachstelle eines System, als die Unwissenheit oder Dummheit des Softwareentwicklers, aber gute SW Entwickler sind leider schwer zu finden.
 
Oben Unten