Sidechannel Attacks

Lisa Hallo und herzlich willkommen zu einer neuen Episode vom INNOQ Security Podcast. Heute ist Christoph Iserlohn zu Gast bei mir und wir wollen über das Thema Seitenkanalangriffe sprechen. Hallo Christoph.

Christoph Iserlohn Hallo Lisa.

Lisa Wollen wir vielleicht einmal ganz einfach anfangen und du erklärst erst mal, was Seitenkanalangriffe grob sind?

Christoph Iserlohn Ja, Seitenkanalangriffe sind Angriffe meistens auf kryptografische Verfahren. Oder auch im Bereich Hardware, die man auch aber ganz allgemein anwenden kann, auch im Web. Das werden wir später sehen, wo wir ein bestimmtes Verfahren oder einen Algorithmus angreifen, zum Beispiel ein Verschlüsselungsverfahren, und dabei aber nicht das eigentliche Verfahren angreifen, sondern dessen Implementierung. Das Verfahren ist sicher, kann man vielleicht auch mathematisch nachweisen, dass es ein sicheres Verfahren ist, aber die Implementierung lässt dann Angriffe zu. Das heißt in der Theorie sicher, aber in der Praxis nicht. Und wie funktioniert das normalerweise? Wir haben irgendwelche Daten oder Umstände, die wir beobachten können, wenn der Algorithmus oder das Verfahren angewendet wird. Und aus diesen Daten, die wir beobachten, können wir dann Rückschlüsse auf die eigentlich geheimen Daten ziehen, zum Beispiel im kryptografischen Verfahren. Oder wir können versuchen, das System irgendwie zu manipulieren. Das geht jetzt nicht, indem wir Daten beobachten, sondern indem wir aktiv in das System eingreifen und an bestimmten Stellen gehen, wo es gar keinen Bug in dem System gibt. Wie wir das System manipulieren können, sprechen wir gleich mal im Beispiel an, ist jetzt ein bisschen abstrakt, um dann einen Fehler zu erzeugen, der zu unseren Gunsten ist, wenn wir die Angreifer sind. Von daher ergibt es sich vielleicht besser, wenn wir mal ein paar Beispiele gleich aufzählen, dann wird das vielleicht ein bisschen deutlicher als das so abstrakt zu erklären.

Lisa Dann sage gerne schon mal ein Beispiel.

Christoph Iserlohn Ich hatte gerade schon erwähnt, dass es verschiedene Arten von Seitenkanalangriffe gibt. Wir können erst mal vielleicht anfangen, einen Unterschied zwischen Hardware und Softwaresachen zu nennen. Ein ganz einfaches Beispiel ist, wenn wir sagen wollen, wir wollen Bildschirminhalte abgreifen und das Verfahren ist jetzt in einer Übertragung über ein Monitorkabel. Vom Computer geht ein Monitorkabel rein und wir schützen uns jetzt, indem wir sagen: Wir sind jetzt im Raum, der keine Fenster hat und nicht einsichtig ist. Dann können wir sagen: Das System, das Verfahren ist jetzt erst mal sicher. Man kann jetzt nicht den Bildschirm sehen und versuchen, zu sehen, was da eingegeben wird oder welche Bildschirminhalte da sind. Wenn das irgendwelche Geheimnisse sind, die jemand aufruft, können wir das nicht sehen. Jetzt ist es aber so. Unser Schutzverfahren ist einfach, wir lassen niemand anderes auf den Monitor schauen und schützen uns, indem wir in einem Raum sind, das keine Fenster hat und der Eingang abgeschlossen ist. Jetzt ist es aber so, dass ein Kabel zum Beispiel elektromagnetische Strahlungen abgibt, durch das Signal, was da durchgeht. Und das ist jetzt eine ganz alte Technik. Heutzutage geht das nicht mehr, bei den aktuellen Standards, HDMI und Co., dass die erst mal digitale Daten durchschicken und die dann auch noch verschlüsselt, über die Leitungen geht das nicht mehr, aber früher ging das, wenn man einen VGA Stecker hatte, also VGA Grafik, wo das noch ein analoges Signal ist, dass man aus dem Signal, was aus dem Kabel abgestrahlt wurde, der Bildschirminhalt rekonstruiert wurde. Und zwar so, dass man zum Teil durch Wände durchkam. Das heißt, beobachtbare Daten sind die elektromagnetische Abstrahlung und darauf können wir Rückschlüsse ziehen auf das, was geheim bleiben soll, der Bildschirminhalt, indem wir das damit einfach rekonstruieren können. Das heißt Van Eck Phreaking, das ist ein niederländischer Forscher, der das zum ersten Mal in den 80ern aufgebracht hat. Unter einem anderen Namen ist das noch als Tempest bekannt. Das war so ein großes Programm von den Geheimdiensten, die sowas genutzt haben, um elektromagnetische Strahlungen in allen möglichen Formen abzufangen, um daraus Signale zu rekonstruieren. Beobachtbare Daten geben Geheimnisse preis, die wir eigentlich verstecken wollen. Aber das kann man auch noch ganz anders machen. Es gibt noch mehrere Verfahren. Man kann zum Beispiel den Energieverbrauch messen. Wenn mein Computer jetzt irgendwas verschlüsselt, dann ist der Energieverbrauch ganz unterschiedlich, als wenn er einfach nichts tun würde oder bestimmte Programme machen würde. Und dann kann man das analysieren. Da unterscheidet man zwischen SPA und DPA. SPA steht für Simple Power Analysis und DPA für Differential Power Analysis. Heutzutage kann man da auch noch Machine Learning Algorithmen draufwerfen und da kann man aus dem Energieverbrauchsmuster Rückschlüsse darauf ziehen, was der Computer gerade macht. Und zwar ziemlich präzise. Nicht nur: Mein Browser läuft gerade oder irgendeine bestimmte Software, sondern sogar, was der Prozessor gerade für Befehle ausführt. Wenn man es sehr genau misst und sehr genau analysieren kann und mit genügend Samples, kann man daraus wie gesagt Rückschlüsse ziehen, was genau der Prozessor gerade macht. Und aus den Daten kann man natürlich dann vielleicht sehen, welche Daten er gerade verarbeitet. So ist es dann möglich, von Verschlüsselungsalgorithmen die Schlüssel zu extrahieren. Das könnte man machen. Man kann auch Geräusche analysieren. Da gab es einen sehr spektakulären Angriff. Den verlinken wir auch mal an den Shownotes. Da hat man das Transistor Rauschen mit Mikrofonen abgehört. So ein Prozessor macht auch Geräusche. Die Transistoren rauschen. Die sind zwar nicht für uns hörbar, aber man kann es mit Mikrofon aufnehmen und dann hat man ein Handy so 30 bis 50 Zentimeter von dem Rechner weg platziert, hat das Mikro in dem Handy benutzt, um die Geräusche aufzunehmen. Und aus diesem Transistorrauschen konnte man dann im Endeffekt irgendein geheimen Schlüssel extrahieren, während der Laptop irgendwelche Verschlüsselungssoftware gemacht haben. Da gibt es schon ganz spannende Dinge im Bereich der Hardware, was man alles abhören kann. Man kennt das vielleicht auch was für Geheimdienste entwickelt wird, Abhörtechniken und Mikrofone, die zum Beispiel dann messen, wie stark die Scheiben vibrieren und daraus Gespräche wieder rekonstruieren können in Räumen. Oder was vor ein, zwei Jahren mal war, dass man aus dem Flimmern von Lampen an der Decke irgendwas extrahieren kann. Ganz abgefahrene Sachen, die jetzt aber wahrscheinlich in unserem Entwickleralltag eher weniger eine Rolle spielen, sondern vielleicht wirklich was für die Ecke der Spionage ist. Weil man braucht den Zugriff meistens auf irgendwelche Hardware, den man vielleicht in der Software gar nicht so sehr hat. Bzw. wenn der Zugriff auf die Hardware da ist, vielleicht viel schlimmere Dinge möglich ist. Wenn ich die Platte rausschrauben kann und Daten so stehlen kann, dann brauche ich vielleicht keine Seitenkanalattacke. Obwohl, vielleicht schon, aber vielleicht will ich nicht erwischt werden. Und dann gibt es natürlich was so auf der Softwareebene und es gibt auch Mischformen. Auf der Softwareebene kann man zum Beispiel über fehlerhafte Eingaben sehen wie eine Software reagiert und die kann dann vielleicht auch Informationen preisgeben, darüber, über geheime Informationen, die sie verarbeitet. Wenn ich an OpenSSL, da gab es mal so ein Beispiel, fehlerhafte Daten eingegeben habe, zur Entschlüsselung, wo ich dann auch den Schlüssel eigentlich nicht hatte, anhand der Antworten wurden da so viele Daten ausgegeben, dass man Rückschlüsse ziehen könnte auf den verschlüsselten Text, den ich sonst nicht im Zugriff hatte. Was kann man noch machen? Man kann versuchen, irgendwelche Glitches zu erzeugen. Das ist sowohl über Software als auch über Hardware möglich. Was heißt Glitches? Ich könnte zum Beispiel einem Prozessor, wenn ich einen Rechner aufschraube, irgendwie zusätzlichen Strom anlegen. Ganz einfach gesprochen. Und dann könnte der Prozess in einen Zustand kommen, dass der vielleicht ein paar Befehle überspringt oder woanders hinspringt, wo er nicht soll. Der normale Programmfluss gestört ist. Oder ich könnt das Taktsignal verändern, dass er mal einen Befehl überspringt. Und das kann man dann zum Beispiel ausnutzen. Vorhin haben wir gesagt, man kann damit vielleicht Sachen abhören, aber man kann auch Sachen manipulieren. Eine Möglichkeit davon, die ist so wirklich vorgekommen bei einer Spielkonsole, ich glaube bei der Xbox oder bei irgendeinem Nintendo, das verlinken wir nochmal in den Shownotes, dass wenn an dem Prozessor entsprechend was angelegt hat, den Takt manipuliert. Auf jeden Fall hat er dann Befehle übersprungen und wenn man das im richtigen Zeitpunkt macht, wo er zum Beispiel in eine Kopierschutzmaßnahme gerade prüft oder dass es ein Originalspiel oder Code ist, der signiert ist von den Herausgebern der Spielekonsole. Und er überspringt genau diesen Befehl, wo er in diese Routine springt, dann läuft es einfach weiter und dann kann man sowas an der Stelle ganz einfach manipulieren. Und das geht auch zum Teil komplett Software mäßig. Mit der Software induziert, kann man auch solche Glitches manchmal erzeugen. Vielleicht kommen wir da später noch mal zu den Beispielen, was auch schon relativ spektakulär war. Und was typisch für Software natürlich ist der Seitenkanalangriff sind Timing Angriffe. Das heißt, ich messe die Zeit, wie lang irgendeine Berechnung dauert und kann darauf dann vielleicht schließen auf irgendein Geheimnis, was da verarbeitet wird. Ganz einfach, wenn ich sage, bei der Verschlüsselung muss ich mit riesig großen Zahlen umgehen, das dauert entsprechend lange. Und weil es so viele Möglichkeiten an Zahlen gibt von 1120 Zillionen, kann ich nicht alle per Brute Force durchsuchen. Dann ist der Suchraum so groß, dass ich nicht alle möglichen Varianten durchgehen kann. Wenn ich aber durch die Messung des Timings herauskriegen kann: Was ist die Range? Dann kann ich den Suchraum extrem verkleinern und dann wäre es vielleicht möglich, dass ich einfach die, die übrig bleiben an Möglichkeiten, einfach mal durchprobieren. Und das ist in der Software dann auch möglich. Mit einigen Sachen, die in letzter Zeit aufgekommen sind an der Hardware, kann man auch durch die Software ausnutzen. Da kommen wir vielleicht gleich noch mal darauf, wie das so ist – Stichwort Meltdown, Spectre und Co.

Lisa Ich hätte zu den Software Initiated Fault Attacks eine Frage. Was mir schon öfter mal aufgefallen ist da draußen in diesem Internet. Wenn man eine fehlerhafte Eingabe macht, muss jetzt nicht mal mutwillig sein, dann kriegt man auch ganz oft so Fehlermeldungs-IDs oder so und kriegt dann schon aus Versehen raus, auf welcher Datenbank Dinge laufen oder welche grundlegenden Frameworks verwendet werden. Zählt das auch schon als Seitenkanalangriff, weil daraus kann man auch schon viele Rückschlüsse ziehen oder ist das zu weit hergeholt, das als Seitenkanalangriff zu zählen?

Christoph Iserlohn Ja, das ist eine Grauzone, ob man das dazu zählt oder nicht. Was auf jeden Fall dazugezählt wird, ist, wenn man ganz einfaches Beispiel aus dem Web. Wenn ich mich bei einer Seite anmelden will bzw. einloggen will, gebe ich typischerweise Nutzernamen und Passwort ein. Und wenn ich das falsch gemacht habe, gibt es verschiedene Möglichkeiten, wie man das zurückgemeldet werden kann. Man könnte sagen, Benutzername ist falsch, Passwort ist falsch oder was man fast immer bekommt: Nutzername oder Passwort ist falsch. Die Idee ist jetzt, dass man sagt, der Seitenkanal, die Information, die ich nicht herausholen kann, existiert der Nutzer - Ja oder Nein. Wenn es heißt Passwort ist falsch, dann existiert wohl der Nutzer. Oder wenn Nutzername falsch ist, existiert er wohl nicht. Das würde man als Seitenkanalangriff sehen. Dass Informationen geleakt werden, worüber ich auf ein Geheimnis schließen kann. Das Geheimnis: Gibt es diesen Nutzer da? Da muss man jetzt ein bisschen differenzieren, weil das wird immer so leichtfertig gesagt. Das stimmt aber nur halb. Wenn der Nutzername die Emailadresse ist und ich kann mich damit registrieren, in irgendeinem Onlineshop oder einem öffentlichen Service, dann kriege ich dieselbe Information raus, wenn ich mich versuche zu registrieren. Ich könnte versuchen rauszukriegen: Ist die Lisa jetzt bei Service XY? Indem ich sage: Ich versuche mich einzuloggen und versuche die Information zu kriegen. "Der Username existiert nicht." Oder wenn man dann das so macht, dass man sagt: Nee, ich gebe nur die Information raus, Username oder Passwort falsch, dann weiß ich nicht, ob die Lisa jetzt diesen Service nutzt. Aber dann kann ich mich noch mal anmelden. Und spätestens da muss die richtige Information rausgegeben werden, weil dieser Benutzername, wenn das die Emailadresse ist, kann dann normalerweise nicht doppelt existieren, weil es den Account schon mal gibt. Das heißt, bei so offenen Systemen ist diese Art oder dieser Tipp zu sagen, gibt nicht raus, ob das jetzt ein Benutzername oder Passwort falsch ist. Eigentlich keinen wirksamen Schutz, aber es kann auch so sein, dass man sich nicht öffentlich registrieren kann. Irgendeine Firma hat ein Intranet oder ein extra Netz zur Verfügung gestellt. Das kann man aus dem Web erreichen und da kriege ich eine Maske für den Login. Aber da kann ich mich jetzt nicht selbst registrieren, sondern dieser User wird mir gestellt von der Firma, die wird eingerichtet und dann kann ich mich damit einloggen. Dann wird diese Information nicht noch woanders geleakt. Und das heißt, da muss ich auf jeden Fall dann sagen Nutzername oder Passwort falsch, damit ich keine Informationen kriege. Da muss man ein bisschen differenzieren. Aber schadet jetzt auch nichts, wenn man das nie rausgibt, was jetzt genau falsch war. Vielleicht leidet die Usability da ein bisschen, aber wäre jetzt nicht verkehrt, aber dann bei offenen Services, ist es dann falsch und das zählt dazu. Wenn du jetzt Fehler IDs ansprichst, könnte man vielleicht auch davon ausgehen, die Frage ist, was kriege ich noch zusätzlich raus? Wenn es eine interne ID von einem Framework ist, die bestimmte Sachen dann preisgeben, die eigentlich nicht nach außen gehen sollten, dann wäre das auch schon eine Art von Seitenkanalangriff. Ansonsten kann man das noch Information Disclosure nennen. Informationen, die den Nutzer so gesehen erst mal nichts angehen. Das war früher mal bei PHP-Seiten, wenn die SQL-Probleme hatten, dann stand auch immer direkt, dass ein Syntaxfehler im MySQL Statement, wo das Statement da steht und solche Sachen. Dann würde es wahrscheinlich eher ein Information Disclosure sein. Die Frage ist: Kann ich aus diesen Daten auch noch auf andere Dinge schließen? Wie gesagt, es ist ein kleiner Graubereich. Aber andererseits, man muss sich um beides kümmern. Ob es jetzt Information Disclosure ist oder Seitenkanalangriff, trotzdem sollte ich irgendwie eine Gegenmaßnahme ergreifen. Von daher ist es das auch nicht so schlimm, wenn man da nicht so haarspalterisch vorgeht.

Lisa Wo du gerade Gegenmaßnahmen sagst. Zu ganz vielen Dingen, die du gerade gesagt hast, fallen mir gar keine großartigen Gegenmaßnahmen ein. Gerade diese Hardware Sachen. Was wäre meine Gegenmaßnahme gegen: Jemand legt sein Handy neben meinen Laptop um mein Transistorrauschen aufzunehmen, wohingegen man Daten nicht nach außen geben oder dieses Benutzername oder Passwort, das kann man relativ "einfach" beheben. Aber genau dieses Handy oder Mikrofon neben dem Laptop kann ich mir gerade nicht so gut helfen.

Christoph Iserlohn Ja doch, da gibt es schon Gegenmaßnahmen. Fangen wir mal mit dem Einfachsten an. Was wir als erstes Beispiel hatten, die elektromagnetische Strahlung. Da kann ich erst mal versuchen, Kabel zu nehmen, die gut isoliert sind und nicht so viel von Strahlung nach außen lassen. Das ist jetzt auf der Hardwareebene eine Gegenmaßnahme. Aber ich könnte auch Gegenmaßnahmen auf der Softwareseite einführen oder auf der Protokollseite. Und das ist heute auch so, dass die heutigen Verfahren, wie man das Bild von der Grafikkarte bis zum Monitor kriegt, über Protokolle gehen, die auch verschlüsselt sind. Dann kann ich ein weißes Rauschen vielleicht rekonstruieren durch die elektromagnetische Strahlung, aber nicht das eigentliche Bild. Da geht schon was. Und dieses Problem mit dem Handy wurde auch in der Software gelöst. Dann hat man andere Befehlsfolgen genommen bei der Verschlüsselung. Man hat das ein bisschen anders programmiert, so dass dieses Rauschen weniger oder keine Rückschlüsse mehr darauf zulässt, welche Operationen jetzt gerade ausgeführt werden. Bzw. Zum Beispiel: Wie groß ist denn der Schlüssel, der verbraucht wird oder welche Zahlen werden da gerade berechnet? Da kann man schon was machen. Da ist natürlich das Problem, wenn man das auf Softwareseite löst, dass die Hardware sich auch ändert. Weil das ist ziemlich low level, was man da macht. Eigentlich erinnert man sozusagen den Maschinen Code, der da rauskommt, damit die Transistoren dann anders rauschen als vorher. Und dass das genauso bleibt bei der nächsten Prozessor Generation. Wenn ich zwischen AMD und Intel oder Apple Silicon wechsle. Das ist gar nicht gesagt. Das ist ein Problem. Andererseits ist für die Angreifer auch das Problem, ob dieser Angriff auch noch auf einer anderen Prozessor Generation oder vom anderen Hersteller dann noch funktioniert, ist natürlich auch nicht gesagt. Das sind schon sehr spezielle Angriffe, die man da hat. Ich finde es interessant, was man alles so schaffen kann, auch mit relativ einfacher Hardware. So ein Handy hat jeder und da ist ein Mikrofon drin und dann kann man da solche Angriffe fahren. Das finde ich schon sehr interessant. Aber wie gesagt, da muss die Hardware was am besten machen. Die können auch versuchen, Abschirmungen zu machen, dass die Daten nicht nach außen gelangen oder was es auch gibt, das wird dann in so HSM oder so verbaut. Dann hat der ein Security Modul, um den Energieverbrauch ein bisschen zu glätten, werden zusätzliche Elemente verbaut, die ein Rauschen in den Energieverbrauch einspeisen, dass das nicht mehr so klar ist. Und da gibt es auch Möglichkeiten, aber wir sollten uns vielleicht eher darum kümmern, was wir in der Software alles so machen können oder was auch schiefgehen kann, anstatt an der Hardware zu basteln. Ich habe bei meinem Mac auch immer das Gefühl, da kann man kein Geräuschangriff machen, weil er gefühlt immer so laut, das kann gar nicht gehen.

Lisa Eine Frage jetzt. Das geht auch auf Software. Ich hatte das Gefühl, gerade die Hardwareangriffe würde ich als Bereitsteller von Dingen gar nicht unbedingt mitkriegen. Ich würde nicht unbedingt mitkriegen, wenn du meinen Laptop aufnimmst. Ich würde nicht unbedingt mitkriegen, wenn du das Flackern meines Lichtes in dem Raum aufnimmst, aber ich als Softwarebereitsteller würde schon mitkriegen. Wenn du viele fehlerhafte Anmeldungsversuche durchführst. Ist es nur so ein Gefühl, dass man Software-Seitenkanalangriffe eher mitbekommen würde als Hardware-Seitenkanalangriffe. Oder ist das ein fehlerhaftes Gefühl?

Christoph Iserlohn Keine Ahnung, ob man das so pauschal sagen kann. Es gibt eine bestimmte Ausprägung und Dimensionen, indem man das so kategorisiert. Es gibt einmal die Sache invasiv, nicht invasiv und dann aktiv und passiv. Also invasiv heißt, wenn ich zum Beispiel einen Glitch einführen muss, weil ich das Taktsignal des Prozessors ändert, muss ich da irgendwie an den Prozessor ran und da eine Leitung anlegen und ein Signal darüber senden. Es gibt Angriffe, die die Hitze des Prozessors messen, eine Wärmebildaufnahme machen und eine Heat Map erstellen und dann sehen, welche Bereiche des Prozessors gerade wärmer sind. Dann kann man auch Rückschlüsse ziehen, was der gerade macht. Wenn bestimmte Funktionseinheiten gerade nicht so arbeiten sind die kühler, dann muss ich irgendwie den Kühler entfernen und eine Kamera machen. Das sind beide Sachen die relativ klar ist, dass sie invasiv sind, während die nicht invasiven, wo ich sagen kann, ich lege jetzt das Handy daneben und muss nichts beeinflussen. Und das muss man noch mal abgrenzen von aktiv und passiv. Passiv ist das, was du gerade gesagt hast: Ich merke davon nichts. Passiv ist, wenn ich nur das Rauschen aufnehme von außen, dann merkst du nicht, wenn ich einen Anmeldeversuch mache, dann ist das natürlich aktiv. Und wenn ich viel ausprobiere, dann macht man einen Brute Force Angriff, um herauszufinden, welche Nutzer da sind. Eine User Enumeration wird man das nennen. Das wird man dann vielleicht merken. Auch bei anderen Angriffen, die dann aktiv ablaufen, ein Rowhammer, wo der Speicher beeinflusst wird über die Software, indem man ganz schnell immer Sachen liest im Speicher. Und wenn man das immer wieder macht, kann man bei so Speicherbausteinen das elektromagnetische Feld verändern. Dann kann man ein Bit Flip erzeugen. Sowas könnte man vielleicht dann merken. Während andere aktive Angriffe, Meltdown und Spectre, die dann irgendwie andere Teile des Prozessors abhören können, vielleicht auch gar nicht mehr. Nehmen wir an, du bist in der Cloud auf einer VM, einer virtuellen Maschine. Und da merkst du nicht, dass die Nachbar virtuelle Maschine versucht, gerade den Prozessor abzuhören, obwohl die da sehr aktiv ist. Das kannst du dann auch nicht merken. Deshalb ist es schwierig, das pauschal zu sagen, ob man das merkt oder nicht. Wie gesagt, da muss man schauen. Invasiv merkt man vielleicht auch nicht. Wenn ich im Rechenzentrum meine Rechner habe, habe ich da wahrscheinlich keine Webcam drin und beobachte den die ganze Zeit. Und wenn sich dann jemand zu schaffen macht und das ist invasiv, aber passiv, kann es auch sein, dass ich das nicht bemerke. Das ist nicht einfach pauschal zu sagen, merkt man oder merkt man nicht. Egal welche Dimension da ist, man muss dann schauen: Wie ist die Kombination dazwischen?

Lisa Du hattest jetzt schon ganz oft Meltdown und Spectre gesagt. Ich glaube, es wäre ein guter Zeitpunkt, einmal darauf einzugehen. Willst du noch einmal kurz diese beiden Lücken oder Angriffe beschreiben, bevor du da tiefer drauf eingehst?

Christoph Iserlohn Gerne. Meltdown und Spectre sind Angriffe. Die sind vor einigen Jahren aufgekommen. Ich weiß gar nicht, wie lange das her ist, fünf Jahre, sechs Jahre. Die eine ganz neue Klasse begründet haben. Und zwar sind das Angriffe, die auf der Prozessorebene stattfinden. Und das waren die ersten beiden, die wurden beschrieben und vorher war auf der Ebene das immer so eine Blackbox, was die Prozessoren so machen. Und dann haben sich Leute, die ganz viel Grips haben, damit ein bisschen beschäftigt und haben da solche Lücken gefunden. Theoretisch war das schon vorher bekannt, dass so was gehen könnte, aber es war nicht irgendwie klar, dass man das irgendwie praktisch umsetzen könnte. Und die haben es dann geschafft. Und da kam noch eine ganze Reihe an Lücken nach, die auf denselben Prinzipien fußen. Und was ist jetzt das Prinzip? Das ist so, dass moderne Prozessoren immer schneller werden sollen. Wir wollen immer schnellere Rechner, weil Office wird immer schlimmer und schwerer, also muss mein Rechner schneller werden. Und unsere Services werden immer schneller oder verbrauchen immer mehr Ressourcen. Also muss ich jetzt anstatt zehn Kilobyte JavaScript in meinem Browser fünf Megabyte verbreiten, also baue ich einen schnellen Prozessor. Da gibt es verschiedene Möglichkeiten, das schneller zu machen. Einmal könnte ich den Takt hochsetzen. Vor 20, 30 Jahren war der Takt bei 100 MHz bzw. der erste Prozessor, den ich kannte vom C64 war unter 1 MHz. Und jetzt sind wir im GHz Bereich und das heißt der Takt ist schneller. Das heißt, mehr Befehle können in einer Sekunde ausgeführt werden. Aber da sind die Grenzen erreicht. Seit ein paar Jahren werden die Taktraten kaum schneller, weil das gibt dann Probleme, je höher der Takt ist, desto mehr Hitze wird erzeugt. Dann kann man die nicht vernünftig kühlen. Das funktioniert dann nicht. Dann versucht man den IPC hoch zu setzen, Instruction per Clock Cycle. Pro Takt könnte jetzt ganz einfach sagen, ein Rechenbefehl kostet fünf Taktzyklen bis der abgearbeitet ist. Und dann kann man versuchen das hoch zu bringen, dass man pro Taktzyklus mehr macht, indem entweder die Befehle kürzer werden, dass sie vielleicht nur noch einen Taktzyklus verbrauchen, aber wenn sie alle nur noch einen verbrauchen, dann geht es dann auch nicht mehr schneller. Und da muss man versuchen, dass die mehrere Befehle auf einmal machen, dass mehrere Befehle gleichzeitig bearbeitet werden. Man kann dann sozusagen die nächsten zehn Befehle erst mal reinladen und dekodieren und dann gleichzeitig bearbeiten. Das ist dann die sogenannte Pipeline, die ist zehn Stufen lang und in jeder Stufe passiert eine Kleinigkeit. Die erste dekodiert das, die zweite führt das aus, und so weiter und so fort, bis am Ende das rauskommt. Und dann kann man das versuchen, damit zu parallelisieren, indem man zum Beispiel sagt: Wir haben jetzt einen Befehl, der addiert zwei Integerzahlen, 1+2 plus macht er und der andere macht zwei Gleitkommazahlen. 2,0 + 1,3. Und der Prozessor hat eine Funktionseinheit für diese Gleitkommazahlen und eine für die Integer, um die zu addieren oder multiplizieren. Und das könnte man gleichzeitig ausführen, er könnte beide Funktionseinheiten gleichzeitig benutzen, dann werden die parallel ausgeführt. Das nennt man dann auch Out of Order Execution. Nicht jeder Befehl wird nacheinander gemacht, sondern Befehle, die gleichzeitig ausgeführt werden können, die keine Abhängigkeit haben, werden dann gleichzeitig ausgeführt. Dann kann man diese Pipeline ziemlich voll machen und den Prozessor gut auslasten. Das heißt, ich führe immer viele Schritte auf einmal aus und das Problem ist, was passiert jetzt, wenn ein Sprung kommt? Wir haben im Programm, haben wir eine If-Bedingung, das heißt, ich führe entweder jetzt den Programmteil A oder B aus. Was in dem If-Block steht oder was in dem Else-Block steht. Da muss der Prozessor sich auch auf der untersten Ebene entscheiden: Was führe ich jetzt aus? Und er könnte jetzt warten, bis das Ergebnis feststeht, damit diese If-Bedingungen genommen werden kann. Das heißt aber, in der Zeit ist die Pipeline leer. Er kann nicht weiter und schon mal weitere Befehle ausführen, weil er erst warten muss, bis das Ergebnis da ist. Und das ist schlecht. Eigentlich will man das verhindern. Deshalb haben irgendwann die Prozessor Hersteller angefangen zu sagen: Wir führen das mal spekulativ aus. Wir sagen, wahrscheinlich wird der Teil in dem If-Block, dann führen wir den aus. Und wenn das nicht der Fall ist, dann verwerfen wir das alles und führen dann B noch mal aus. Das heißt immer, wenn ich einen Treffer habe bei dieser Vorhersage, welche Seite denn genommen wird, ist die sogenannte Branch Prediction, dann behalte ich meine Geschwindigkeit bei, dann habe ich nicht so ein Stopp, wo ich erst mal auf das Ergebnis warten muss. Und das Problem ist jetzt bei diesem Aufräumen kann es sein, dass so Sachen übrig bleiben, weil das ist sehr teuer. Ich kann sagen, ich habe irgendwelche Speicheradressen geladen oder sonst was gemacht und die füllen jetzt den Cache auf. Der Cache wird aber nicht verworfen, sondern es wird einfach weitergearbeitet, weil für den anderen Teil spielt das keine Rolle, was jetzt im Cache steht, sondern das beeinflusst jetzt nur die Ausführungsgeschwindigkeit des anderen Teils. Dann wird es dann ein bisschen langsamer, weil die falschen Daten im Cache sind. Aber sonst passiert nichts. Eigentlich ist das Verfahren save für die Korrektheit der Programmausführung. Der führt immer noch das Programm korrekt aus. So, da ist jetzt aber ein Problem, dass man diese Mechanismen, solche Reste übrig bleiben kann, ausnutzen kann, um zum Beispiel den gesamten Speicher auszulesen. Bei diesem Spectre ist das so. Dass ich versuche, diesen Teil, der voraussagt, welcher Branche denn jetzt genommen wird, auszutricksen. Das heißt, ich mache irgendwie eine Schleife, da macht er was ganz Bestimmtes drin, dass immer wieder die Schleife ausgeführt wird oder eine bestimmte If-Bedingung in der Schleife. Dann trainiert man diesem Branch Predictor darauf zu sagen: Okay, ich nehme jetzt Teil A. Und dann wird das immer genommen, spekulativ ausgeführt, und dann macht man in dieser spekulativen Ausführung einen Zugriff auf Speicher, den man eigentlich nicht zugreifen dürfte, der vielleicht von einem anderen Prozess ist. Und dann wird der Speicher in den Cache geladen und es gibt normalerweise, wenn das ausgeführt wird, eine Speicherschutzverletzung und dann gibt es einen Fehler in dem Programm. Aber in dieser spekulativen Ausführung sind wir noch gar nicht an der Stelle, der macht das schon mal in der Zukunft. Deshalb gibt es diese Speicherschutzverletzung noch nicht. Das heißt, er liest das ein, liest das in den Cache und dann haben wir das in den Cache geladen. Aber in dem Fall geht der Branch dann nicht dort rein, sondern den anderen Weg. Das heißt, wir haben den Cache jetzt mit Daten befüllt, die wir eigentlich nicht lesen sollten, und dann können wir schauen, dass wir diese Daten wieder aus dem Cache irgendwie extrahieren können. Man kann hier nicht direkt zugreifen, aber man kann zum Beispiel über das Timing rauskriegen, welche Daten jetzt im Cache sind. Ob der Zugriff langsam oder schnell war. Und dann kann ich Daten auslesen. Und so ist es da gelungen, zum Beispiel den gesamten Speicherbereich auszulesen. Das heißt, wenn ich von anderen Prozessoren Speicher auslesen kann, könnten da auch Geheimnisse drin sein. Wenn mein Browser Speicher ausliest von anderen Programmen, von meinem Password Manager, der gerade den Safe geöffnet hat, dann ist das natürlich schlecht. Dann komme ich auf einer Webseite, die liefert mir JavaScript aus, die mein Speicher ausliest. Und dann lesen sie mein Passwort Manager, der gerade geöffnet ist, weil ich gerade im Browser mein Passwort vorher eingegeben hat, für eine andere Seite oder so. Das liegt dann entschlüsselt im Speicher oder wo wir vorhin dabei waren, wo man das merkt oder nicht. Du bist jetzt in der Cloud mit deinem Service, hast eine virtuelle Maschine. Und meine virtuelle Maschine, die auf dem gleichen Rechner ist, versucht jetzt den Speicher deiner auszulesen. Wenn du da SSL Verbindungen hast, dann liegt da auch Schlüsselmaterial und das kann ich dann versuchen auszulesen, ohne dass du das merkst, weil wie gesagt, das siehst du dann nicht. Und wie gesagt, Meltdown, Spectre waren die ersten, es kam eine ganze Reihe danach, die alle aber auf diesem Prinzip beruhen, dass man irgendwie spekulativ was ausführt und dann in dieser spekulativen Ausführung auf Speicherbereiche zugreift oder Register zugreift, die man sonst nicht sehen würde. Und dieser Meltdown war so, dass man das gar nicht über den Cache gemacht hat, sondern da waren mehrere Befehle gleichzeitig da, dann hat man Sachen in ein Register geladen, in den Prozessor und das war aber nicht erlaubt. Aber wie gesagt, da waren mehrere Befehle gleichzeitig, die gleichzeitig in Bearbeitung waren. Und dann konnte man das aus diesem Register schon auslesen. Und Spectre beruht darauf, dass man ein Caching ausliest. Und wie gesagt, da kamen noch ganz viele nach und auch aktuell sind wieder welche. Das ist ein Problem, was dauerhaft irgendwie da ist, wo immer wieder neue Sachen gefunden werden, begleitet uns das bis heute, obwohl das Grundprinzip jetzt schon ein paar Jahre alt ist.

Lisa Und wie werden diese Sachen dann behoben? Das ist jetzt gerade nicht mehr das akute Problem mit dem Spectre und Meltdown, sondern dann eher die neuen. Aber was wird getan, damit es nicht mehr auftritt?

Christoph Iserlohn Ja, nun gibt es wieder verschiedene Möglichkeiten. Sowohl Hardware als auch Software-seitig. Und dass das nicht mehr so auftritt, ist auch eine Sache, die nur halb stimmt. Nachdem die ersten Schutzmaßnahmen kamen, kamen verbesserte Angriffsmöglichkeiten, die die dann wieder ausgehebelt haben. Was passiert? Einmal wird versucht die Prozessoren zu patchen, was natürlich nicht so ganz einfach ist, weil diese Prozessoren sind Hardware, die kann man nur bedingt ändern. Da gibt es die sogenannten Micro Code, die da Sachen im Prozessor steuern, da kann man schon einiges mit machen und da wird versucht über einer neuen Prozessorrevision oder neueren Generation, dass dieses Zurückrollen von einer spekulativen Ausführung natürlich besser ist und nicht einfach irgendwelche Artefakte überlässt, sondern versuchen das wirklich in den Urzustand zurückzuversetzen. Oder Möglichkeiten von Caching, Cache Speicher auszulesen. Da gibt es auf der Hardware Möglichkeiten und auf der Software-Seite gibt es auch Möglichkeiten. Zum Beispiel kann man die Speicherbereiche im Browser, also das Spectre könnte man auch im Browser ausnutzen, mit wenigen Zeilen JavaScript war das interessant. Es war eine Hardware-Lücke, die total tief im Prozessor drin ist. Und dann macht man JavaScript und High Level Sprache, man hat zehn Zeilen Exploit um Speicher auszulesen. Das war spektakulär, aber da versucht man natürlich auch was zu machen auf der Software-Seite. Im JavaScript hat man einfach auch die Timer, die man benutzt hat, um das zu messen, ungenau gemacht. Man konnte sehr genau messen, im Nanosekundenbereich und die haben dann einfach die Genauigkeit verändert, damit man diese Differenzen, ist das jetzt im Prozessor Cache drin oder nicht? Dass man die einfach so ungenau gemacht hat, dass man das nicht mehr machen konnte. Das wäre zum Beispiel eine Möglichkeit. Und auch wie die Compiler, jetzt sind wir wieder auf der Low Level Ebene den Code erzeugen, dass diese spekulative Ausführung, dass dann nicht bestimmte Befehle vorher ausgeführt werden, die dann Sachen laden, sondern dass man vor dem Branch andere Dinge macht, die dafür nicht anfällig sind. Das geht jetzt in die technische Tiefe. Das ist schwierig, dass wir das auf der Tonspur besprechen, aber wichtig ist, es gibt die Hardware-Seite, Microcode Updates, neue Prozessor Generation plus auch auf der Software-Seite die Compiler ändern sich, die Runtimes ändern sich, um so was zu verhindern. Und das hat man gemacht. Aber das Problem dabei ist, dass gerade die Hardware-Seite nicht ohne Auswirkung war, weil diese ersten Micro Code Patches ziemlich starke Leistungsverluste unter bestimmten Workloads verursacht haben. Zum Teil bis zu 50% Einbußen. Und das ist schlecht für den Rechner zu Hause, wenn er auf einmal lahm wird. Wobei das da wahrscheinlich nicht so sehr aufgefallen ist, aber wenn man seine Sachen in der Cloud hat und auf einmal vielleicht dadurch auf die größere VM wechseln muss, weil ein Performance Einbruch gibt, hat man auch die entsprechenden Kosten. Ich kann mich nicht erinnern, dass AWS, Google Cloud und Azure und Co. einem dann irgendwelche Rabatte dafür gegeben hat, dass die Leistung auf einmal geringer war von den Prozessoren. Es ist schon schwierig gewesen.

Lisa Jetzt haben wir sehr viel über Hardware gesprochen und eigentlich sind wir doch eher so ein Software-seitiger Podcast gewesen bis heute. Möchtest du noch mal ein bisschen näher auf die Seitenkanalangriffe in der Software-Entwicklung im Softwarebereich eingehen?

Christoph Iserlohn Ja, können wir gerne machen. Wie gesagt, wir waren da jetzt eigentlich schon. Wie gesagt, Spectre konnte mit JavaScript ausgenutzt werden und die anderen dann zwar nicht mehr mit JavaScript, aber auch mit Software-Programmen. Von daher ist das schon so, aber vielleicht gehen wir mal ein bisschen mehr auf die High Level Sachen. Wie gesagt, nicht irgendwelche speziellen Maschinencodes, die wir da brauchen, sondern da gibt es noch eine ganze Reihe mehr. Wie gesagt, JavaScript ist schon High Level und wie gesagt, das ist eigentlich auch relativ einfach da zu machen. Wir verlinken mal da einen POC Exploit wie der damals ging. Heute funktioniert der natürlich mit den aktuellen dann nicht mehr. Aber wie gesagt, das sind wenige Zeilen. Das ist einfach relativ einfach zu bewerkstelligen. Aber was man jetzt hat, sind natürlich wie gesagt Timing Angriffe. Ganz einfaches Beispiel ist der String Vergleich, den man hat. Normalerweise, wenn ich zwei Strings vergleiche, würde ich es so machen, dass ich das optimiert mache, dass ich möglichst wenig Zeit brauche. Das heißt, ich vergleiche die ersten beiden Zeichen. Wenn wir übereinstimmen, gehe ich in der Schleife weiter, vergleiche die zweiten beiden und so weiter. Aber sobald eins nicht mehr übereinstimmt, breche ich ab, weil dann kann ich sagen, das Ergebnis ist: Sie sind nicht gleich. Und spare mir das sozusagen über den ganzen String durch zu iterieren und jedes Zeichen zu vergleichen. Das lässt aber Rückschlüsse zu darauf über den eigentlichen String. Das kann ich dann rauskriegen. Wenn es jetzt ein Geheimnis ist und ich kann das eingeben, zum Beispiel Passwort. Ich mache einen Brute Force Angriff auf ein Passwort und dann kann ich das über einen String-Vergleich, der das Timing liest, rauskriegen. Dann probiere ich einfach. Der erste einfach nur mit A-A-A-A, also nur As. Die Länge lassen wir es mal weg zur Einfachheit, wie man noch an die Länge kommen. Und jetzt schaue ich und nach fünf Nanosekunden kriege ich das zurück, dann nach fünf Millisekunden kommt, bekomme ich die Antwort: Nee, war falsch, war falsch. Und dann gehe ich rauf. Dann gehe ich auf den Buchstaben B. Das geht wieder fünf Millisekunden und dann komme ich irgendwann zum G. Und G ist auf einmal zehn Millisekunden. Das heißt, der erste Vergleich war in Ordnung, ich springe jetzt zum Zweiten. Und dann kann ich den Suchraum total klein machen dadurch. Damit ich nicht mehr Brute Force alle Möglichkeiten durchgehen muss, sondern für jeden Buchstaben, wenn wir jetzt Groß- und Kleinschreibung und ein paar Ziffern und Sonderzeichen zur Verfügung haben, habe ich für jeden Buchstaben 70 Möglichkeiten. 70 Versuche, um einen Buchstaben zu raten. Und dann ist das vielleicht 20 Zeilen lang, dann sind das nicht viele Versuche, um nah ranzukommen, um das zu machen. Da muss ich den String Vergleich so machen, dass es immer gleich viel Zeit kostet, indem ich zum Beispiel immer sage: ich vergleiche alle Zeichen, ohne dass ich versuche, vorzeitig abzubrechen. Das gegenteilige Ziel, was ich sonst habe, performant zu programmieren, sondern da will ich einen Vergleich in konstanter Zeit haben. Für das Passwort ist das natürlich Unsinn, weil Passwörter speichern wir nicht im Klartext und vergleichen im Klartext, sondern die speichern wir natürlich gehasht. Wir hatten da mal eine Folge darüber, vielleicht verlinken wir die dann auch. Und das heißt, da wird das erst gehasht. Und jede kleine Änderung an dem Ursprung macht eine große Änderung in dem Hash, das ist der Lawineneffekt. Das heißt, da kann ich keine Rückschlüsse darüber bekommen, ob das jetzt gleich ist oder nicht. Aber es gibt andere Geheimnisse, die man vergleichen muss, die im Klartext vorliegen. Ein Verschlüsselungskey, der symmetrisch ist, da brauche ich das. Oder API Keys oder sonstiges. Es gibt Sachen, die muss ich dann schon im Klartext vorliegen haben, im Gegensatz zu Passwörtern und muss dann auch da vergleichen. Und dann wäre es schlecht, wenn ich da irgendwie durch Timing Informationen leake. Und das sollte man nicht machen. Und dann werden einige Hörerinnen vielleicht sagen: Ja, aber das Web zu messen, da so viel Jitter drin und so viel Ungenauigkeit. Es stimmt erst mal, wenn man das so primitiv macht, wie ich das jetzt so gesagt habe, aber wenn man genügend Statistik darauf anwendet und genügend Messungen macht, gibt es das schon. Da gibt es so ein Paper, das ist 2010 herausgekommen. Das verlinken wir auch mal, was sehr interessant war, das hat gezeigt, dass auch solche Timing Angriffe übers Web okay sind. Das heißt "Remote Timing Attacks Are Practical", das ist von zwei Leuten von der Stanford University gemacht, einer ist ein Kryptologe oder Kryptograph. Und da ist es so, dass wenn man genügend messen kann und genügend Ahnung von Statistik hat, kann man das auch rauskriegen. Es kann auch im Web eine Gefahr sein für bestimmte Sachen. Und das gilt auch nicht nur für einfache Strings, sondern auch alles im Bereich Kryptographie. Verschlüsselungsverfahren, da ist immer ganz wichtig, dass man die Berechnungen so macht, dass viele Berechnungen in konstanter Zeit passieren. Das geht dann nicht nur über den Stream Vergleich, sondern auch die Multiplikation großer Zahlen. Die sollte dann auch immer gleich lange dauern. Ob die jetzt 35 Stellen haben oder 35000 Stellen, sollte dann keinen Unterschied machen. Und da muss man ein bisschen aufpassen. Timing Angriffe, ganz wichtig. Aber es gibt auch eine ganze Reihe, wo wir beide auch viel unterwegs sind, Webentwicklung. Da gibt es einen ganzen Bereich, der nennt sich Crosssite Links. Der auch Informationen preisgibt über Webseiten, wo wir eigentlich nicht wollen, dass diese Informationen preisgegeben werden. Das kann zum Beispiel sein, dass ich da auch schaue, ob Sachen gecached sind. Jemand kommt auf meine Seite und da gebe ich irgendein Script ein oder irgendeine Ressource von einer anderen Seite, auf die nur derjenige Zugriff hat. Und dann kann ich messen, wie lange dieser Fetch Befehl gedauert hat oder dieser XAR Befehl und sehe, das ist vielleicht noch im Cache oder nicht. Auch wenn ich vielleicht auf die Daten nicht direkt zugreifen kann. Das wird auch von der Same Origin Policy verhindert. Ich kann zum Beispiel von meiner Seite aus ein Bild laden, was auf deiner Seite gehostet ist. Dann kommt das rein und ist gut. Aber ich kann jetzt nicht auf das Bild intern zugreifen, die Pixel. Ich kann das nicht in so ein Canvas Objekt stecken und dann die Pixel manipulieren. Das geht aber, wenn ich das von meiner eigenen Seite aus machen. Aber von deiner Seite wird es dann nicht gehen, weil das über Cross Origin, über verschiedene Origins hinweg und dann geht das nicht. Aber ich kann solche Informationen dann sehem, ob das Bild zum Beispiel bei dir schon im Cache liegt. Dann weiß ich, du warst auf der Seite. Das kann Informationen leaken, die man vielleicht nicht will, wenn man bestimmte JavaScript Snippets lädt und dann schaut, ob die schon im Cache lagen oder nicht. Da gibt es eine Seite, die heißt irgendwie Crosssiteleaks.dev, die verlinken wir auch noch mal, da ist eine ganze Reihe aufgeführt, wo Informationen geleakt werden, über die man da was machen kann. Eine berühmte Sache, die man vielleicht schon mal gehört hat und die auch einfach zu erklären ist, ist, dass ich schauen kann, auf welchen Seiten du warst, indem ich dir jetzt eine Seite schicke, klicke mal auf den Link und dann habe ich da ganz viele Seiten verlinkt. Twitter, Facebook, blablabla. Die bombenbauanleitung.de und so was. So ein Link, das kennt man, wenn man draufgeklickt hat, hat das eine andere Farbe. und das ist eine CSS Eigenschaft, die ich dann zum Beispiel abrufen kann. Per JavaScript kann ich schauen, welche Farbe ist in eins berechnet worden und dann kann ich daraus schließen, du warst schon mal auf der Seite, oder nicht. Weil der Link ist dann anders farblich hinterlegt. Das geht jetzt nicht mehr. Das haben die Browser Hersteller abgeklemmt, dass man diesen Unterschied noch erkennen kann. Aber das war mal eine Möglichkeit um deine Browser History auszulesen. Oder es können auch ID Attribute genutzt werden, die leaken. Ich könnte mit einer eine Seite als iFrame einbinden und zu dem Source Attribut zu dem iFrame dann direkt einen Anchor Tag nehmen und schauen, ob das da hin scrollt. Und dann verliert bei mir die Seite den Fokus. Dann kann ich auf dieses Event reagieren. Dann weiß ich, ob bestimmte Seiten Elemente enthalten. Da gibt es alle möglichen Sachen um da Informationen zu leaken. Meistens kommt jetzt nicht so ein wahnwitziger Angriff dabei raus, aber es gab schon einige, die dann auch schon nicht so gut waren. Zum Beispiel konnte man mit einem Angriff über so ein Caching schauen, ob so ein bestimmtes Script gecacht, User bei Twitter deanonymisieren und das war dann nicht so gut. Das ist jetzt auch schon längst behoben, aber es gibt eine ganze Reihe, die Sachen, die der Browser leakt. Deshalb hat man auch diese ganzen Header und Policies dafür eingeführt, um da gegenzusteuern. Das ist einmal die Seite auf dem Client, die angegriffen werden kann auf der Software-Seite, von dem was wir ausliefern. Und wie gesagt, die andere Seite ist auf dem Rechenzentrum, wo wir unsere Sachen hosten, die auch angegriffen werden können, wenn wir da Ressourcen teilen, was atypisch in der Cloud ist.

Lisa Christoph, bei all den Sachen die wichtigste Frage ist doch: Hat die Wahl der Programmiersprache einen Einfluss darauf, wie gut oder schlecht man Seitenkanalangriffe ausführen kann?

Christoph Iserlohn Auf jeden Fall hat das Auswirkungen darauf. Leider gibt es überhaupt keine gute Programmiersprache dafür. Weil das Problem ist, wenn wir jetzt sagen, das eine sind so logische Sachen. Im Web, welche Fehlermeldungen gebe ich zum Beispiel zurück? Das kann ich in einer Software, egal in welcher Programmiersprache auf der logischen Ebene lösen. Aber diese Low Level Sachen, wo es um Timings geht, dann wird es schwierig. Da sind alle höheren Programmiersprachen eigentlich raus, weil da habe ich überhaupt keinen Einfluss darauf, wie das Timing aussieht. Wenn wir uns Java anschauen, da geht das durch den Compiler, der erst mal aus dem Java Quelltext Java Bytecode erzeugt. Da werden schon Optimierungen vorgenommen, die das Timing vielleicht verändern können. Das Problem ist auch wenn ich ein sage, wir sind bei dem Beispiel des String Vergleichs. Wir haben eine Schleife und wir haben den superschlauen Compiler, der könnte das auch weg optimieren, wenn er erkennt, dass das semantisch äquivalent ist. Ich meine, das macht der Java Compiler jetzt nicht, der ist eigentlich ziemlich doof. Der Quelltext in Java Bytecode verwandelt, da gibt es wenig Optimierung, aber das könnte man sich vorstellen und wäre auch noch von der Sprache Spezifikation gedeckt. Wenn das semantisch gleich ist, wäre das okay. Dann kommt der zweite Schritt, der wird ausgeführt, dann kommt der JIT-Compiler. Der macht einen Maschinencode daraus. Da haben wir überhaupt keinen Überblick mehr darauf, was für einen Maschinencode er erzeugt und welche Timings der verwirrt. Da sind wir dann komplett blind. Und dann, wenn wir es noch weitertreiben, das wird von einem Prozessor ausgeführt, der, wie wir jetzt gesehen haben, auch Optimierungen ausführt, um irgendwelche Sachen schneller auszuführen. Da sind wir eigentlich vollkommen verloren. Also können wir theoretisch nur auf Programmiersprachen zurückgreifen, die irgendwelche Low Level Controls anbieten dafür. So sind wir irgendwie bei C, wenn wir nicht direkt Assembler schreiben wollen. Und selbst in C ist das komplett schwierig, weil auch da der Compiler darauf ausgelegt ist, gute Optimierung zu machen, einen schnellen Code zu erzeugen. Und da ist es gar nicht so einfach zu sagen, wir wollen was in konstanter Zeit ausführen. Da muss man schon wissen, welche Konstrukte man benutzt, die der Compiler nicht weg optimieren kann. Und manche Compiler bieten auch solche Metainformationen, die aber nicht standardisiert ist, dass man sagt, das soll nicht weg optimiert werden. Da gibt es oft so Sachen, dass man irgendwelche Variablen einführt und da Sachen berechnet, die überhaupt keinen Sinn ergeben. Aber wo der Compiler nicht entscheiden kann, ob das jetzt wichtig ist oder nicht, und dann kann er andere Sachen dadurch nicht weg optimieren. Das ist schwierig und das ist nicht nur schwierig in Sachen Timing, auch in Sachen: Wie schütze ich meinen Speicher? Nehmen wir mal an. Wir haben jetzt das Passwort bekommen, haben das verglichen und sagen: Es okay, der User darf sich einloggen oder ist eingeloggt. Dann wollen wir das Passwort wieder loswerden. Das hatten wir jetzt im Klartext übermittelt bekommen. Also wollen wir es wieder loswerden, weil wenn sich da irgendwie hunderte User anmelden und alle Passwörter sind im Speicher und dann kriegt es jemand dazu, dass der Service abstürzt und einen Speicherdump macht, den er in die Hände kriegt. Dann sind da alle Passwörter drin. Also wollen wir das eigentlich schnell überschreiben. Und das geht in Programmiersprachen gar nicht, dass man das sicher überschreiben kann. Die Strings liegen dann irgendwo rum, in Java zum Beispiel liegen die in irgendeinem Heap-Bereich. Dann kommt eine Garbage Collection, dann liegen die irgendwo rum. Der Speicher, der jetzt als unbenutzt gilt, aber der wurde vorher nicht mit Nullen oder so überschrieben, sondern die sind dann immer noch. Und da kommen wir gar nicht mehr dran und könnten die löschen. Und deshalb ist auch wenn man solche Frameworks in Java zum Beispiel sieht, sind das immer Character Arrays und nicht direkt Strings, weil die kann man noch mit Nullen überschreiben. Da ist es ein bisschen einfacher, aber die können auch im Speicher bei der Garbage Collection hin- und hergeschoben werden. Eigentlich bräuchte man sogar so ein White Buffer, der außerhalb des normalen Heaps ist, um irgendwas sicher zu machen. Und ob das dann aber auch durch alle Caches geht, die es gibt von den Prozessoren, die irgendwie drei Caching Layer haben, das weiß man auch nicht. Und es gab mal vor ein paar Jahre einen Artikel, wie schwer das selbst in C ist, wo man Low Level Control hat. Wie schwer es ist da einen Speicherbereich sicher mit Nullen zu überschreiben. Und dass es eigentlich damals unmöglich war. Und dann hat die Standard-Bibliothek, also die libc dann eine Funktion dafür gekriegt, die dann sicherstellt, dass man irgendwas auch überschreiben kann, ohne dass irgendein Compiler das wegoptimieren könnte oder irgendwas passiert, wo man sich dann 100%ig sicher sein kann. Und das ist das Problem. Das wäre eigentlich keine Sache, wenn wir sagen, wir machen eigentlich alle solchen Low Level Kryptographie Sachen, wo wir das brauchen, wo wir konstante Ausführungszeichen brauchen, programmieren wir dann in C. Wenn C nicht sowieso von sich aus so anfällig wäre für Sicherheitslücken, weil es kein vernünftiges Speichermanagement hat, sondern ein manuelles Speichermanagement und auch sonst wenig Schutzmechanismen für so Out of Bounds Reads oder Writes, wo man in Java dann eine Array Out of Bounds Exception, wenn man in C einfach den Speicher dann überschreibt in so einem Array. Das ist natürlich sehr problematisch. Das wäre was, was ich mir für andere Programmiersprachen, Systemsprachen mal wünschen würde. Rust will C, C++ ablösen und ist auch sehr gut in Sachen: Wir brauchen das Memory Management nicht mehr. Beziehungsweise wir haben da Möglichkeiten, dass du durch diese Ownership Semantik, solche Fehler nicht mehr passieren. Aber da habe ich auch keine Möglichkeiten auf solche Sachen dann zu sagen: Okay, das führe das jetzt in konstanter Zeit durch oder hier bitte sicher den Speicher überschreiben. Das geht leider nicht. Aber gut, da müssen wir jetzt erst mal mit leben. Es geht nicht. Es ist auch immer die Frage, inwieweit so ein Angriff dann auch wahrscheinlich ist. Wenn wir jetzt sagen: so einen Speicherdump könnte man vielleicht vernachlässigen. Wir haben gesehen hier im Meltdown, Spectre und Co. Speicher auslesen geht. Vielleicht brauche ich nicht mehr einen Speicherdump wegen Fehlern, sondern die nette VM nebenan hört einem die ganze Zeit ab, ohne dass man das merkt. Ja, da habe ich leider auch keine Lösung für. Ich glaube Programmiersprachen wäre noch mal ein Thema, dem sollten uns noch mal in einer Extrafolge widmen, über die Sicherheitseigenschaften, die die so haben. Oder die Unsicherheitseigenschaften, die die mitbringen. Es ist ein sehr weites Feld.

Lisa Das finde ich eine gute Idee. Ich schreibe mir das direkt mal auf, dass wir das nicht vergessen. Christoph, ich habe eigentlich gar keine Fragen mehr zu dem Thema Seitenkanalangriffen. Aber ich würde dich um ein schönes Schlusswort bitten, weil du jetzt so frustrierende Sachen am Ende gesagt hast und es wäre schöner, wenn man was Nettes im Kopf behält.

Christoph Iserlohn Ja, so schlimm ist es nun auch nicht. Wie gesagt, diese ganzen Hardware-Sachen, die überlassen wir dann mal den Spionen und nicht unserem Service. Bei den Sachen, die so Spectre, Meltdown und Co., also spekulative Ausführung, das ist so ein Hase Igel Rennen. Du hattest mir noch vorher so eine Meldung geschickt, wo jetzt Patchday von AMD und Intel, wo in den aktuellen AMD Prozessoren auch wieder solche Lücken aufgetaucht sind. Da muss man immer hinterher sein dabei. Aber immerhin, da passiert was. Das nehmen die Prozessor Hersteller nicht auf die leichte Schulter, sondern liefern auch mal was. Und von daher sollte das gehen und auf der Software-Seite, so Stringvergleich kriegen wir noch hin und was wir im Web machen, diese Crosssite Leaks, die auf der Logik Ebene sind, können wir auch was tun. Von daher ist nicht alles verloren. Und Kryptographie wollen wir alle nicht selbst machen. Da machen wir die Augen zu, das machen andere für uns. Da brauchen wir uns über konstante Ausführung keine Sorgen machen, sondern wir setzen die richtigen HTTP Header, übrigens auch noch mal vielleicht eine Folge, die wir machen sollen, wie man sich mit den HTTP schützt. Da gibt es auch welche, die gerade für Meltdown und Spectre eigentlich erfunden wurden um zu verhindern, dass irgendwelche Ressourcen von woanders geladen werden, die vielleicht so ein Spectre noch machen können. Auf der Ebene, wo wir unterwegs sind, da geht was und woanders machen wir die Augen zu. Das war auch kein tolles Schlusswort, um diese Stimmung zu heben, aber gut.

Lisa Schon besser. Eben waren wir ganz traurig. Christoph, vielen, vielen Dank. Das war ein spannendes Thema. Vor allen Dingen auch lustig. Ich habe nie darüber gedacht, wie man Monitorkabel abhören könnte, von daher fand ich das ziemlich interessant. Vielen Dank, dass du da warst. Vielen Dank an euch da draußen, die ihr zugehört habt. Wir hoffen natürlich, dass es euch auch gefallen hat und dass ihr es auch spannend und interessant fandet. Wenn es euch gefallen hat oder ihr irgendwelche Fragen habt, Feedback oder was auch immer, könnt ihr uns gerne eine Mail schreiben an die Emailadresse [email protected], die werden wir auf jeden Fall in den Shownotes verlinken. Wie auch viele, viele andere Dinge, die Christoph auch eben genannt hat. Und wir wünschen euch eine schöne Zeit und sagen bis zum nächsten Mal.

Christoph Iserlohn Ciao!

Lisa Hallo ihr und Überraschung, da sind wir wieder. Und zwar haben wir beide, also Christoph und ich, die Folge aufgenommen, haben uns gedacht: Okay, Seitenkanalangriffe, da passiert vielleicht erst mal nichts, aber dann sind doch noch Dinge passiert und die wollen wir euch natürlich nicht vorenthalten, weil die sehr spannend sind. Christoph, was ist denn in den letzten Wochen passiert?

Christoph Hallo noch mal, Lisa. Kaum hat man uns aufgenommen und geht es in die Postproduktion, kommen direkt zwei neue Seitenkanalangriffe raus, die auch beide sehr spannend sind. Beide im Bereich der Hardware wie Meltdown und Spectre. Bei dem ersten haben wir noch gedacht: Ja gut, haben wir Pech gehabt. Zwei Tage später nach der Aufnahme. Und noch ein paar Tage später kommt noch einer raus, da haben wir gesagt: Das müssen wir jetzt nochmal ergänzen. Deshalb gibt es da noch mal ein kleines Add-on an dem Podcast über die aktuellen Entwicklungen. Eigentlich hatten wir auch gedacht, Seitenkanalangriffe sind nicht so das aktuellste Thema, aber da wurden wir leider von der Realität überholt.

Lisa Ja, so schnell kann es gehen. Was ist denn der erste Angriff, der passiert ist?

Christoph Ja, der erste hat den schönen Namen Pacman. Man muss immer tolle Namen haben seit Heartbleed. Da handelt es sich um einen Angriff auf die Apple M1 CPU, der neue Prozessor von Apple bzw. jetzt ist auch gerade die zweite Generation angekündigt. Aber ob in dem zweiten was gefixt wurde, weiß man noch nicht. Und generell hat man das jetzt erst mal auf einem M1 erst mal gezeigt, so als Proof of Concept. Aber diese Funktionalität, die da angegriffen ist, die besteht eigentlich auch in jedem Armprozessor. Jedem Armprozessor, der etwas neuer ist. Das heißt, das könnte sich auch noch ein bisschen ausweiten. Warum heißt das jetzt Pacman? Der Armbefehlssatz hat eine Funktionalität, die nennt sich Pointer Authentication Codes, PAC. Das ist eine Sicherheitsmaßnahme, und zwar um eigentlich einen Schutz zu bieten vor anderen Lücken, vor Buffer Overflows oder Heap Overflows. Und zwar wird bei solchen Lücken normalerweise versucht so ein Pointer zu überschreiben, damit ein eigener Code ausgeführt wird. Zum Beispiel die Rücksprungadresse, wenn eine Funktion ausgeführt wird, oder wenn ein Heap irgendwo im Overflow ist, dass da bestimmte Adressen überschrieben werden, die dann auf Code zeigen, der dann bösartig ist. Und damit das verhindert wird, gibt es verschiedene Maßnahmen. und eine davon, die jetzt für Arm umgesetzt ist, sind solche Pointer Authentication Codes. Und sie haben sich gedacht: So ein Pointer, den sichern wir jetzt mal ab, in dem wir da einen Authentication Code drauf tun. Eigentlich sind die viel länger. Wir hatten das mal in der Crypto Folge bei HMax zum Beispiel geredet, da wird dann aber nur ein kleiner Teil benutzt. Ich weiß nicht, da sind so fünf, sechs Bits, die sonst bei dem Pointer ungenutzt sind, weil die auf Adressen zeigen, die dann irgendwo in einen Speicherbereich legen, den es nicht gibt, weil der so hoch ist. Und die benutzt man dann einfach anderweitig um so einen Authentication Code zu machen. Dazu kommt dann noch so ein Prozess-spezifisches Geheimnis und auch noch ein zweites Argument, die da verarbeitet werden und dann kommt das da dran. Und bevor jetzt ein Pointer wieder aufgelöst wird. Es gibt eine Funktion, mit dem ich so einen Authentication Code erstelle, sozusagen so eine Art, nicht signiert, aber integritäts-geschützter Pointer. Und in der anderen Instruktion kann ich das dann auflösen. Und wenn dann die Geheimnisse nicht übereinstimmen, die der Angreifer natürlich nicht kennen kann, wird eine Ausnahmesituation erzeugt. Das ist aber der grundlegende Schutz. Was hat man jetzt bei PACman gemacht? Da hat man ausgenutzt, ähnlich wie bei diesen anderen Angriffen auf die Hardware, dass man eine spekulative Ausführung des Codes haben kann. Und damit versucht man dann, den Authentication Code zu erraten. Und da das nur so ein paar Bits sind, sind gar nicht so viele Versuche nötig. Und dann macht man das so, bei dieser spekulativen Ausführung des Codes wird versucht, diesen Pointer auszulesen und dann kann man über einen anderen Kanal sehen, dass das erfolgreich war. Über wieder so einen Zeit Channel, dass sich die Timings ändern, wenn das wirklich gelesen wurde. Aber da das nur spekulativ ausgeführt wurde, wird das alles zurückgeholt. Und diese Aufnahmebedingungen, die eigentlich zutreffen müsste, wenn dieser Authentication Code falsch ist, der wird dann nicht getriggert und dann kann man das ausprobieren und man hat das auch gezeigt. Es gibt einen Proof of Concept dabei und das heißt, man hat diesen Sicherheitsmechanismus damit ausgehebelt. Und für den M1 selbst gibt es jetzt auch keinen Fix. Da ist wieder relativ lange Zeit vergangen, seit das entdeckt wurde, weil Apple dann erst mal lange darüber schauen musste. Wie gesagt, so Hardware ist nicht so einfach zu fixen. Und dafür gibt es jetzt aber im Moment keinen Fix. Und ob das jetzt beim M2 behoben wird, weiß man noch nicht und das wird wahrscheinlich auch in vielen anderen Armpozessoren noch drin schlummern, weil die auch so einen Mechanismus benutzen. Aber andererseits ist es nicht ganz so schlimm, weil das betrifft jetzt erst mal nur einen Sicherheitsmechanismus, der jetzt ausgehebelt ist, der andere Angriffe verhindern soll. Das ist sozusagen der doppelte Boden, den man da hat und einer davon ist jetzt kaputt. Aber es ist nicht ganz so schlimm in den Auswirkungen, aber trotzdem ein sehr interessanter Angriff, den man da geschafft hat.

Lisa Du hast gerade gesagt, es gibt keinen Fix oder noch keinen Fix. Denkst du, das ganze könnte sich irgendwie patchen lassen oder ist es da nicht möglich?

Christoph Ich kann es nicht einschätzen. Dazu habe ich von Hardware zu wenig Ahnung, wie man das auch vernünftig patchen kann. Aber es wird geschrieben, dass es dafür wohl keinen Patch geben wird. Aber von daher, wenn er schon von den Autoren in Absprache mit Apple gesagt wird, dann wird es wohl keinen geben. Vielleicht dann in neueren Prozessor Generationen, aber die haben auch so einen langen Vorlauf. Ich glaube, dass der M2 davon auch betroffen ist und keinen Schutz dagegen hat, weil die haben unglaublich lange Vorlaufzeiten solche Designs und da später das noch zu ändern, dazu glaube ich, ist das dann auch zu neu. Wenn es dann mal M3 gibt oder so, wird man vielleicht was getan haben. Keine Ahnung. Vielleicht muss Arm auch was tun von dem Prozessor Design her. Von dem Befehlsatz Design. Das weiß ich nicht. Jetzt müssen wir erst mal damit leben. Wie gesagt, es ist nicht ganz so schlimm. Es hebelt nur eine zusätzliche Sicherheitsmaßnahme aus. Wenn man gar keinen Buffer Overflow oder Heap Overflow hat, kann man das auch nicht ausnutzen. Von daher nicht ganz so schlimm. Der andere Angriff, der bekannt geworden ist, sehe ich in seinen Auswirkungen deutlich schlimmer.

Lisa Der andere Angriff hat so einen extrem coolen Namen, weil wir dauernd schon von Heartbleed reden. Können wir jetzt auch von Hertzbleed reden? Habe ich gerade gelesen. Was verbirgt sich denn hinter Herz Bleed?

Christoph Ja, hinter Hertzbleed verbirgt sich erst mal wieder ein cooler Name und ein tolles Logo. Aber der Angriff ist dann doch wie gesagt deutlich brisanter als der PACman. Worum geht es denn da? Da hat man herausgefunden, dass die CPU Frequenz ganz unterschiedlich sein kann, je nachdem was man berechnet. Warum ist das so? Verschiedene Befehle in dem Prozessor erzeugen unterschiedlichen Energieverbrauch. Das hatten wir auch in unserer bisherigen Aufnahme schon mal angesprochen, dass es darauf Angriffe gibt. Und jetzt ist aber, dass der Energieverbrauch von einem Prozessor auch entsprechend die Wärmeerzeugung beeinflusst. Je mehr Energie verbraucht wird, desto mehr Wärme erzeugt der Prozessor. Und was wird gemacht, wenn die heutzutage die Prozessoren zu warm werden? Dann werden die etwas runter getaktet bzw. eigentlich ist es umgekehrt. Es gibt einen Boost Modus, das heißt solange es noch kalt genug ist, läuft er mit höheren Frequenzen. An diesen Änderungen der Frequenzen ändert sich die Laufzeit vom Algorithmus und man kann jetzt sogar zurückrechnen, in diesem Angriff, welche Befehle so alles ausgeführt werden und welche Art von Befehlen. Weil manche Befehle mehr Hitze erzeugen und dann vielleicht die Frequenz kleiner wird und der Algorithmus länger dauert. Auf ihrer Homepage haben sie das relativ einfach beschrieben. Sie sagen, 2022 plus 23.823 wird anders sein von der Wärmeentwicklung und von der Power Consumption wie 2022 plus 24.436. Einfach die Addition von verschieden großen Zahlen hat darauf Auswirkungen. Was jetzt das Tolle daran ist. Darauf kann man dann einen Timing Angriff ausführen. Wenn der Prozessor langsamer rechnet, weil er zu warm ist, dann dauert die gesamte Berechnung länger. Und sie haben das vorgeführt, indem sie ein Key Encapsulation Algorithmus geknackt haben. Der heißt Sike, ich weiß gar nicht, ob er Sike ausgesprochen wird oder nicht. Das ist ein Algorithmus, der ist seit zehn Jahren in der Entwicklung. Der ist dafür da, dass man kryptographische Schlüssel auch noch austauschen kann, wenn es Quantencomputer gibt. Da sind ESA und elliptische Kurven, die kann man mit Quantencomputer knacken, wenn sie denn mal in ausreichender Größe da sind und um dafür gerüstet sein, da wird schon seit langem daran geforscht, dass man sozusagen Post Quantum Kryptographie hat. Verfahren, die dagegen resistent sind. Und das ist so ein Verfahren um Schlüssel auszutauschen und das hat man damit geknackt. Man konnte den Schlüssel extrahieren dabei. Und das Interessante dabei ist, a) bei der Implementierung hat man extra darauf geachtet, dass man die Implementierung so gemacht hat, dass die sogenannte Constant Time ausgeführt wird. Das hatten wir vorher auch mal besprochen, dass die Laufzeit immer gleich sein sollte. Aber ist sie in dem Fall nicht. Von daher ist das besonders interessant. Auch wenn man darauf achtet, ist man nicht unbedingt dagegen geschützt und das andere ist, dass man das auch remote ausnutzen kann. Den Proof of Concept haben sie auch mit Remote Timing gemacht. Das ist in dieser Hinsicht wirklich ein doppelt interessanter Angriff. Und das dritte ist, warum ich den so als besonders einschätze ist, dass sowohl Intel als auch AMD Prozessoren betroffen sind. Das konnten sie nachweisen und dass höchstwahrscheinlich auch die typischen Prozessoren davon auch betroffen sind. Das hat man jetzt nicht nachgewiesen. Aber die benutzen auch diese Frequenzskalierung je nach Hitze und entsprechend dem Verbrauch von Energie. Prinzipiell sind sie auf jeden Fall auch betroffen. Und das macht das echt besonders und wir haben es jetzt hier mit einem Angriff nicht auf ihren der Sicherheitsmaßnahme zu tun, sondern einen direkten Angriff auf das kryptografischen Verfahren, was sie jetzt gezeigt haben. Ich würde es als deutlich schlimmer einschätzen als jetzt den PACman Bug. Und es hat auch sehr lange gedauert bis zur Veröffentlichung, weil Intel da auch lange daran gearbeitet hat. Und im Moment gibt es Workarounds dafür, wie man so was dann abstellen kann. Zum Beispiel diesen Turbo Boost, so heißt das bei Intel, man versucht so was abzustellen, dass die Frequenz je nach Wärmeentwicklung entsprechend hoch gedreht wird oder runter gedreht wird und so was. Und auch wie man sich Software technisch dagegen schützen kann, indem man versucht dieses Konzept so zu implementieren, dass man auch konstant Power hat. Dass man auch gleich viel verbraucht. Aber das ist alles nicht so einfach. Da muss man schon sehr aufpassen bei der Implementierung. Das andere Problem ist, wenn da mal neuere Prozessorarchitekturen herauskommen, heißt das nicht mehr, dass es dann auf einmal doch wieder Constant Time oder Constant Power vor allem ist, weil man nicht weiß, ob die Befehle dann auf einmal nicht doch wieder mehr Energie verbrauchen oder vielleicht weniger. Das wird mal ganz schön tricky werden. Ich bin gespannt, was da so passieren wird in näherer Zukunft.

Lisa Da ist auch jetzt erst der der Bug quasi oder dieser Angriff bekannt geworden. Und da gibt es wahrscheinlich noch keine Äußerung von den Herstellern, wie sie planen zu agieren oder ob sie da überhaupt agieren können, oder?

Christoph Ja, bis jetzt ist das noch nicht bekannt. Intel und AMD haben wohl gesagt, dass es erstmal keine Microcode Patches erst mal planen, wie sie es bei Meltdown Spectre getan haben. Vielleicht, weil das auch nicht geht. Das andere Intel hat so eine Guideline bereitgestellt, wie man das in der Software mitigieren kann, wie man sozusagen die kryptografischen Verfahren oder überhaupt die Algorithmen so prämieren muss, dass da keine Information leakt. Aber sonst gibt es da noch nicht so viel. Von daher, keine Ahnung. Und was auf der der Webseite von Hertzbleed auch noch beschrieben wird, ist dass diese Workarounds, zum Beispiel dieses Turbo Boost abschalten, natürlich auch wieder mit Performance Einbußen auftreten. Wenn er dann nicht hoch taktet, kann ich bestimmte Dinge auch nicht schneller damit beschleunigen. Da sind wir in der Falle. Das haben wir beii Meltdown schon gesehen und Spectre, dass es da für diese ganzen Workarounds einen ordentlichen Performance Einbruch gibt. Und da stehen wir jetzt wieder vor und es sind natürlich auch wieder dieselben Systeme betroffen. Was ich in der Cloud betreibe, wo dann andere Leute vielleicht auch noch auf den selben VMs oder so unterwegs sind. Naja, mal schauen. Andererseits gibt es jetzt noch keinen Angriff auf ein etabliertes Verfahren, auf ESA oder so was, sondern auf den Algorithmus, der natürlich noch gar nicht groß in der Verbreitung ist, sondern mehr in der Forschung. Aber man weiß, das geht immer schnell, solche Weiterentwicklungen von solchen Angriffen. Schauen wir mal, ist aber wichtig, glaube ich, dass wir das noch mit aufgenommen haben. Sonst würde es sich so anhören, als wäre der Podcast irgendwie nicht am Herz der Zeit ist.

Lisa Schön noch das Herz untergebracht. Ja, auf jeden Fall spannend und ich finde es auch gut, dass wir jetzt den Zusatz noch aufgenommen haben. Ich hoffe, ihr da draußen findet es auch gut und richtig, dass wir jetzt noch diese kleine Zusatzabteilung dazugenommen haben. Wir hoffen auch, dass euch dieser zweite Teil noch gut gefallen hat und die ganzen Feedback Mechanismen treffen natürlich auch für diesen Teil zu. Wir hoffen, euch hat es gefallen und wir sagen jetzt hoffentlich bis zum nächsten Mal und nicht bis zum nächsten Seitenkanalangriff. Bis bald. Tschüss.

Christoph Ciao.