Hertzbleed: CPU verrät Kryptokeys durch Taktänderungen

[HWL News Bot]

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

 

[Crizzo]

getauchte = getaufte

Nehme ich mal an.

Crazy 😬

 

[freakyd]

Crazy shit... indeed

 

[passat3233]

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]

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]

Theoretisch reicht es ja dann aus, Speedstep zu deaktivieren ?

 

[passat3233]

Würde ich auch sagen:
Taktfrequenz fixieren, dann gibt es das Problem nicht mehr.

 

[FirstAid]

Von der Schwachstelle betroffen sind alle Intel-Prozessoren ("All Intel Processors are affected.") und bei AMD alle Ryzen-Modelle sowie der Athlon X4.

Folgt man den Link, ist Ryzen 5000 für den Desktop nicht betroffen und Ryzen 4000 und Ryzen 5000 mit Grafikteil schon betroffen!

@Don Dann stimmt Dein Artikel nicht oder habe ich etwas überlesen⁉️

 

[Don]

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]

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]

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]

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]

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]

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]

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]

Ja geil, mein eigenhändiges OC festgetackert auf 4gHz ist direkt mal n Patch ja

Gruss Dennis

 

[Richard88]

Ja geil, mein eigenhändiges OC festgetackert auf 4gHz ist direkt mal n Patch ja

Gruss Dennis

Modern problems require modern solutions.

 

[Liesel Weppen]

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]

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.

 

[pillenkoenig]

Über die Leistungsaufnahme kann man einiges rausbekommen: https://en.m.wikipedia.org/wiki/Power_analysis
(Auch wenn die Szenarien dort dochbetwas anders gelagert sind.)

 

[Holt]

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:

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:

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.