{"id":29043,"date":"2022-07-19T22:25:36","date_gmt":"2022-07-19T20:25:36","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=29043"},"modified":"2022-07-19T22:25:36","modified_gmt":"2022-07-19T20:25:36","slug":"hertzbleed-attack","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/hertzbleed-attack\/29043\/","title":{"rendered":"Was ist Hertzbleed und was macht die neue Entdeckung so besonders?"},"content":{"rendered":"

Im Juni ver\u00f6ffentlichten<\/a> Forscher dreier US-Universit\u00e4ten ein Paper, in dem sie eine aktuelle Angriffsmethode beschreiben, bei der die Tatsache ausgenutzt wird, dass sich die CPU-Frequenz in Abh\u00e4ngigkeit von ihrer Belastung \u00e4ndert (Standardverhalten moderner CPUs). Die CPU-Frequenz wird in Hertz gemessen; die \u00c4nderung der Frequenz kann hierbei zu einem Datenleck f\u00fchren. Die Autoren der Studie haben die dadurch m\u00f6gliche Angriffsreihe deshalb auf den Namen Hertzbleed<\/em> getauft.<\/p>\n

Die Methode kann als Hardware-Angriff eingestuft werden, d. h. als Angriff, der Sicherheitsl\u00fccken oder andere spezifische Schwachpunkte in der Hardware ausnutzt. Angriffe dieser Art gibt es viele, aber fast alle erfordern direkten Zugriff auf den Zielcomputer \u2013 oder zumindest auf einen bestimmten Chip. Hertzbleed kann jedoch aus der Ferne man\u00f6vrieren!<\/p>\n

Die Studie ist sehr interessant und l\u00e4sst sich trotz ihrer Komplexit\u00e4t auch f\u00fcr Laien verst\u00e4ndlich zusammenfassen. Um die detaillierteren Feinheiten zu verstehen, ist jedoch ein gewisses Hintergrundwissen erforderlich. Wir haben uns dazu entschieden, im Anschluss sowohl eine leicht verst\u00e4ndliche als auch eine etwas komplexere Erkl\u00e4rung des Angriffs an unsere Leser weiterzugeben.<\/p>\n

\"\"

Das Logo spiegelt die Grundidee der Schwachstelle wider: Das \u00c4ndern der CPU-Frequenz f\u00fchrt zu Datenlecks. Quelle<\/a>.<\/p><\/div>\n

\u00a0<\/strong><\/p>\n

Hertzbleed einfach erkl\u00e4rt<\/h2>\n

Um Strom zu sparen, \u00e4ndern moderne CPUs ihre Frequenz. Diese wird (ebenso wie die CPU-Spannung) automatisch an die jeweilige Belastung angepasst. Fallen nur wenige Aufgaben an, kann die Frequenz sehr niedrig sein \u2013 beispielsweise 900 MHz statt der nominellen 3,2 GHz. Wird die CPU hingegen mit vielen Aufgaben konfrontiert, kann die Frequenz der CPU-Kernel \u00fcber den Referenzwert hinausgehen. In der Praxis ist die Last (Anzahl und Komplexit\u00e4t der Aufgaben) nicht das einzige Kriterium f\u00fcr die \u00c4nderung der Frequenz. Sie kann zum Beispiel auch dann gesenkt werden, wenn die CPU \u00fcberhitzt.<\/p>\n

Den Forschern gelang es, diese systemeigene Funktion zu nutzen, um den Zustand der CPU bei der Ausf\u00fchrung eines Datenverschl\u00fcsselungsprogramms zu messen und im selben Zuge sensible Informationen zu stehlen. Sie fanden eine Funktion eines modernen Verschl\u00fcsselungsalgorithmus, die die CPU dazu \u201ezwingt\u201c, ihre Frequenz bei der Verarbeitung bestimmter Daten zu erh\u00f6hen. Je h\u00f6her die Frequenz ist, desto schneller die Datenverarbeitung und Reaktionszeit des angegriffenen Computers auf Anfragen. Durch die Messung der Antwortzeit konnten die Forscher den eigentlich geheimen Verschl\u00fcsselungskey rekonstruieren, mit dem sie dann theoretisch Daten, die das Zielsystem z. B. mit anderen Computern in einem virtuellen privaten Netzwerk austauscht, abfangen und entschl\u00fcsseln k\u00f6nnen. All das, ohne das der \u201eDiebstahl\u201c des Schl\u00fcssels \u00fcberhaupt registriert wird.<\/p>\n

Hertzbleed entwickelt die Idee von Hardware-Angriffen \u00fcber sogenannte Seitenkan\u00e4le. Gleichzeitig wird mit dieser Angriffsmethode die hypothetische M\u00f6glichkeit eingef\u00fchrt, Daten aus der Ferne zu stehlen, indem Anfragen das potenzielle Opfer \u00fcber das Netzwerk erreichen. Doch vorerst bleibt dies eine rein theoretische \u00dcbung auf der Suche nach komplexen Schwachstellen in modernen CPUs. Es ist jedoch m\u00f6glich, dass solche Angriffe in Zukunft \u201evereinfacht\u201c werden.<\/p>\n

Die etwas komplexere Erkl\u00e4rung<\/h2>\n

Seitenkanalangriffe<\/a> werden durch die indirekte Beobachtung des Betriebs eines einzelnen Chips oder eines ganzen Computers durchgef\u00fchrt. Die klassische Seitenkanalangriffsmethode besteht in der Beobachtung von Schwankungen im Stromverbrauch des Chips. Ist letzterer beispielsweise damit besch\u00e4ftigt, Daten zu verschl\u00fcsseln, k\u00f6nnen \u00c4nderungen des Stromverbrauchs in manchen F\u00e4llen genutzt werden, um den dazu verwendeten Geheimschl\u00fcssel zu rekonstruieren.<\/p>\n

Seitenkan\u00e4le k\u00f6nnen sowohl software- als auch hardwarebasiert sein. In der bekannten Spectre<\/a>-Studie wird ein solcher Seitenkanal direkt in der CPU verwendet, wobei spekulative Ausf\u00fchrungsfunktionen ausgenutzt werden, um sensible Daten zu stehlen. Zudem ist der Anschluss eines Voltmeters an den Computer oftmals nicht notwendig, um den Stromverbrauch der CPU zu \u00fcberwachen, da diese meist \u00fcber ein integriertes Voltmeter verf\u00fcgt. Mithilfe eines Systems zur \u00dcberwachung des durchschnittlichen Stromverbrauchs von Intel-Prozessoren wurde bereits ein Angriff im Zusammenhang mit Hertzbleed entwickelt.<\/p>\n

Lassen Sie uns nun einen Blick auf die dynamische Anpassung der CPU-Frequenz<\/em> werfen. Erm\u00f6glicht wird dies durch die DVFS-Technik, mit anderen Worten, die dynamische Spannungs- und Frequenzskalierung. Neben der Frequenz variiert auch die CPU-Spannung, um optimale Betriebsbedingungen zu gew\u00e4hrleisten (geringer Stromverbrauch bei geringer Last, stabiler Betrieb bei Spitzenleistung). Die Forscher beschreiben detailliert, wie sie zahlreiche DVFS-Experimente mit Intel-Prozessoren durchgef\u00fchrt haben (Intel selbst nennt diese Technologie Turbo Boost). Sie reduzierten die CPU-Last auf einen vernachl\u00e4ssigbaren Wert und beobachteten dann, wie sich die Frequenz ver\u00e4nderte. Dabei zeigten sich mehrere Muster: Um es so weit wie m\u00f6glich zu vereinfachen: Die CPU-Frequenz stieg bei einem Satz von Berechnungsdaten tendenziell an, bei einem anderen wiederum nicht. Au\u00dferdem f\u00fchrte eine h\u00f6here Frequenz zu schnelleren Berechnungen und dementsprechend auch zu einem schnelleren Ergebnis.<\/p>\n

Schauen wir uns nun noch einen letzten, dritten Begriff an, der in diesem Zusammenhang von Bedeutung ist: die zeitkonstante Programmierung<\/em>. Diese ist bei der Implementierung eines Verschl\u00fcsselungsalgorithmus von Bedeutung. Nehmen wir an, ein Programm erh\u00e4lt eine bestimmte Phrase als Eingabe und gibt dieselbe Phrase verschl\u00fcsselt wieder aus. Wir k\u00f6nnen Daten als Input geben, kennen den geheimen Verschl\u00fcsselungscode, den wir in der Zwischenzeit durch Beobachtung der Ausf\u00fchrungszeit zu ermitteln versuchen, jedoch nicht. Dies ist vergleichbar mit dem Versuch, einen Tresor zu knacken, der mit einem geheimen digitalen Code versehen ist und minimal anders auf fast richtige Zahlenfolgen reagiert und uns warm-kalt-Hinweise gibt. Die meisten Programme, die Verschl\u00fcsselungsalgorithmen implementieren, verf\u00fcgen \u00fcber einen Schutzmechanismus, um Versuche zu verhindern, den Schl\u00fcssel auf diese Weise zu ermitteln \u2013 das eigentliche Prinzip der zeitkonstanten Programmierung.<\/p>\n

Das wichtigste Ergebnis der Hertzbleed-Studie ist, dass die dynamische Anpassung der CPU-Frequenz<\/em> das Prinzip der zeitkonstanten Programmierung<\/em> \u2013 d. h. die Zeitinvarianz bei der Verschl\u00fcsselung \u2013 bricht. Die Forscher zeigten, wie man sich diese Tatsache zunutze machen kann. Dazu nahmen sie ein System mit einer realen Datenverschl\u00fcsselungssoftware und gaben eine Zeichenabfolge ein, die das Programm dann zu entschl\u00fcsseln versuchte. Die Eingaben wurden so gew\u00e4hlt, dass ein Angreifer den Verschl\u00fcsselungskey rekonstruieren kann. Au\u00dferdem wird der Schl\u00fcssel \u00fcber einen Seitenkanal<\/em> extrahiert, d. h. das Datenleck entsteht durch eine \u00c4nderung der CPU-Frequenz und dementsprechend der Programmausf\u00fchrungszeit und der Antwortzeit auf die Anfrage des Angreifers.<\/p>\n

\u00a0<\/p>\n

Fehlende Folgen<\/h2>\n

In unserer \u201ekomplexen Erkl\u00e4rung\u201c haben wir ungef\u00e4hr 0,05% der von den Forschern pr\u00e4sentierten Informationen abgedeckt. Es gibt unz\u00e4hlige weitere Nuancen, die f\u00fcr das Verst\u00e4ndnis der Funktionsweise ebenfalls wichtig sind. Insbesondere haben die Forscher eine Funktion des SIKE-Algorithmus genutzt, um Bedingungen zu schaffen, die ein Datenleck durch \u00c4nderung der Reaktionszeit oder der Frequenz erm\u00f6glichen. Dies \u00e4hnelt dem bereits erw\u00e4hnten Spectre-Angriff, bei dem spezielle Bedingungen in der angegriffenen Software geschaffen werden m\u00fcssen, um den Diebstahl wichtiger Daten zu erm\u00f6glichen. Streng genommen l\u00e4sst sich auf der Grundlage der Ergebnisse der Studie nicht eindeutig sagen, wo die Schwachstelle liegt: in der CPU oder im Programm.<\/p>\n

Des Weiteren m\u00fcssen wir folgenden Aspekt der Umsetzung erw\u00e4hnen: Obwohl die Forscher einen tats\u00e4chlichen, praktischen (nicht theoretischen) Angriff demonstrierten, wurde dieser unter kontrollierten Bedingungen durchgef\u00fchrt. Die Ver\u00e4nderung der Reaktionszeit in Abh\u00e4ngigkeit von den Eingaben war immer konstant. Was aber, wenn die CPU gleichzeitig andere Aufgaben ausf\u00fchrt, die sich ebenfalls auf die Reaktionszeit auswirken? Denn immerhin nahm die Rekonstruktion des Verschl\u00fcsselungskeys (in zwei verschiedenen Experimenten) selbst unter solchen idealen Bedingungen jeweils 36 bzw. 89 Stunden in Anspruch! W\u00e4hrend dieser Zeit wurden Tausende von Anfragen pro Sekunde an das Verschl\u00fcsselungsprogramm gesendet. Die einzige M\u00f6glichkeit, um sicherzustellen, dass alle notwendigen Funktionen der Software und der Hardware aufeinander abgestimmt waren, um das Datenleck hervorzurufen.<\/p>\n

Daher war die Reaktion auf die Studie nicht eindeutig. Einerseits wurden die Schwachstellen mit den \u00fcblichen Bezeichnungen versehen: CVE-2022-23823 f\u00fcr Intel und CVE-2022-24436 f\u00fcr AMD. Doch weder Intel<\/a> noch AMD<\/a> haben Updates f\u00fcr die betroffenen Systeme (bei Intel die CPUs Generation 8. bis 11.) in Aussicht gestellt. Tats\u00e4chlich hat die \u00c4nderung des SIKE-Algorithmus den demonstrierten Angriff verhindert. Microsoft und Cloudflare, die SIKE als eines der Elemente in ihren Verschl\u00fcsselungssystemen verwenden, haben ihre eigene Software aktualisiert.<\/p>\n

Dennoch ist die Studie von gro\u00dfer Bedeutung. Wie Spectre im Jahr 2018 wird dies nicht der letzte Angriff dieser neuen Klasse sein. Wenn ein<\/em> Beispiel f\u00fcr ein Datenleck durch dynamische Anpassung der CPU-Frequenz gezeigt werden kann, werden sicherlich weitere folgen. Auch f\u00fcr Kryptographen ist die Studie von Bedeutung. SIKE ist ein relativ neuer Algorithmus, wurde allerdings bereits auf seine Robustheit gegen\u00fcber Seitenkanalangriffen untersucht und als recht widerstandsf\u00e4hig befunden. Mit der Hertzbleed-Studie wird dieses Ergebnis jedoch teilweise widerlegt.<\/p>\n

Abschlie\u00dfend k\u00f6nnte man sagen, dass der Angriff, wie so oft bei solchen Studien, \u201eentdeckt\u201c aber nicht vollst\u00e4ndig und erfolgreich in die Praxis umgesetzt wurde. Die Entwickler von CPUs und Programmen, die besonders anf\u00e4llig f\u00fcr Angriffe von Cyberkriminellen sind, werden ihre eigenen Schl\u00fcsse aus den Ergebnissen ziehen und \u00c4nderungen vornehmen, bevor Datenlecks entstehen k\u00f6nnen. Nichtsdestotrotz besteht die M\u00f6glichkeit, dass Forscher beim n\u00e4chsten Mal eine Entdeckung machen, die es Angreifern erm\u00f6glicht, beispielsweise verschl\u00fcsselten Netzwerkverkehr abzufangen oder die Verschl\u00fcsselung v\u00f6llig anonym zu knacken. Mit ein wenig Fantasie k\u00f6nnte das in dieser Studie beschriebene System derartige Ausma\u00dfe annehmen. Dies muss jedoch erst noch bewiesen werden, und die Hertzbleed-Studie zeigt, dass dies keine leichte Aufgabe ist. Bei den Schwachstellen der Spectre-Klasse kam es seit nun mehr als vier Jahren nicht zu einem solchem Durchbruch<\/a>. Auch hier wird sich wahrscheinlich nicht viel \u00e4ndern: In etwa einem Jahr wird ein weiterer Bericht ver\u00f6ffentlicht werden, der den vorherigen leicht pr\u00e4zisiert. Und das ist positiv zu bewerten. Schlie\u00dflich gibt es bereits genug Probleme im Bereich Informationssicherheit!<\/p>\n","protected":false},"excerpt":{"rendered":"

Eine der komplexesten und dennoch leicht verst\u00e4ndlichen Infosec-Studien der letzten Zeit.<\/p>\n","protected":false},"author":665,"featured_media":29044,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1848,3107],"tags":[3964,1498,2842],"class_list":{"0":"post-29043","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-cpus","10":"tag-schwachstellen","11":"tag-spectre"},"hreflang":[{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/hertzbleed-attack\/29043\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/hertzbleed-attack\/24346\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/hertzbleed-attack\/19812\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/hertzbleed-attack\/26719\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/hertzbleed-attack\/25052\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/hertzbleed-attack\/27390\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/hertzbleed-attack\/33493\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/hertzbleed-attack\/10883\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/hertzbleed-attack\/44824\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/hertzbleed-attack\/19160\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/hertzbleed-attack\/19724\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/hertzbleed-attack\/25222\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/hertzbleed-attack\/30710\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/hertzbleed-attack\/30458\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.de\/blog\/tag\/schwachstellen\/","name":"Schwachstellen"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/29043","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/comments?post=29043"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/29043\/revisions"}],"predecessor-version":[{"id":29046,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/29043\/revisions\/29046"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media\/29044"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media?parent=29043"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/categories?post=29043"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/tags?post=29043"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}