Vorspannmusik Herald: Heute geht es um „Hardware-Trojaner in Security-Chips“. Also nicht um Software- Trojaner, die die Polizei einsetzen will. Die beiden Herren neben mir, Peter und Marcus, forschen seit mehreren Jahren zu Smartcards und arbeiten komischerweise beide für Infineon, sind aber beide privat hier, und… heißt sie herzlich willkommen! Applaus Peter: Ja vielen Dank und herzlich willkommen zu unserem Vortrag über „Hardware-Trojaner and Security-Chips“. Wie versprochen reisen wir gleich auf die dunklere Seite der Chip-Technologien, aber bevor wir das machen, ganz kurz zu unserer Person: was machen wir, wo kommen wir her? Und, ja, vielen Dank noch mal für die Einführung; In der Tat sind wir seit 1989 aktiv im Bereich der Chipkarten-Forschung; und das Ganze fing an in Brunsbüttel, eine kleine Schleusenstadt, ungefähr 80 km nordwestlich von hier, mit der Forschung an der deutschen Telefonkarte. Die war damals ganz neu und wir wollten natürlich unbedingt wissen: Was verbirgt sich hinter diesen kleinen Goldkontakten in der Chipkarte, wie funktioniert der Chip und vor allem wie werden da die Gebühren drauf gespeichert? Ungefähr 1991, also zwei Jahre später haben wir auch das erste Mal für den CCC-Kongress einen Vortrag gehalten. Es war damals noch im Eidelstädter Bürgerhaus – also viel, viel kleiner als das hier – hat aber auch schon Riesenspaß gemacht, dabei zu sein und auch das Wissen mit anderen zu teilen. Ja, neben dem Studium – das war bei Marcus in Hamburg und bei mir in Kiel – haben wir uns weiter mit dem Thema auseinandergesetzt und auch so die eine oder andere Sicherheitsschwäche aufgedeckt und das Ganze auch etwas erweitert im Bereiche ‚Datensicherheit und Datenschutz‘. Und wie schon angekündigt arbeiten wir momentan auch professionell in dem Bereich, unter anderem für einen Halbleiterhersteller, bei dem wir eine kleine Expertengruppe dann damals aufgebaut haben. Aber interessant für uns ist: die private Forschung läuft weiter und wir schauen uns zum Beispiel momentan an, was es so auf dem Surplus-Markt gibt an Equipment, mit dem man dann fröhlich forschen kann und schlagkräftiges Equipment zusammenstellen kann. Deshalb, kommen wir auch gleich zum eigentlichen Thema: Die Hardware-Trojaner. Software-Trojaner, kam in der Einführung schon ganz gut rüber, sind schon lange bekannt, deshalb wollen wir hier ein bisschen mehr über die Hardware-Trojaner berichten. Die werden ziemlich vernachlässigt – in der Literatur und auch in der Öffentlichkeit. Hardware-Trojaner genauso wie Software-Trojaner dienen zwei Zwecken und zwar einerseits der Exfiltration und andererseits der Infiltration. Exfiltration – da denkt sofort jeder dran. Zum Beispiel, wenn man einen Software-Trojaner hat, der möchte Kreditkartendaten irgendwo aus einem System herausschleusen/herausholen, oder auch die berühmten Staats- und Bundestrojaner die aus einem geschützten System dann private Daten zum Beispiel heraus-exfiltrieren sollen. Das können aber auch anderen Dinge sein, die mit dieser Exfiltration verbunden sind, zum Beispiel können das kryptografische Schlüssel sein. Wenn ein System z.B. Nachrichten bereits verschlüsselt hat – man hat jetzt diese verschlüsselten Nachrichten zum Beispiel abgefangen – dann möchte man eventuell heran an diesen Schlüssel, der das Ganze verschlüsselt hat, um im Nachhinein diese Daten wieder entschlüsseln zu können. Oder: noch perfider sind die Startwerte für Pseudo-Zufallszahlen-Generatoren. Heute ist es häufig so, dass Zufallszahlen nicht NUR durch reinen, echten, physikalischen Zufall erzeugt werden, sondern dass man Startwerte nimmt, die wirft man in Pseudo-Zufallszahlen-Generatoren hinein und wenn man die dann kennt – und auch den Startwert – dann weiß man, was diese Pseudo-Zufallszahlen-Generatoren als nächstes ausspucken werden. Wenn man also den Startwert kennt, weiß man, was als nächstes kommt. Und schließlich kann es Code sein, also Software, Firmware, zum Beispiel im Bereich der Industriespionage, wenn man Code herausholen möchte aus einem System, Code Dump tun möchte. Was immer so ein bisschen vernachlässigt wird ist die Infiltration – was ja eigentlich ein Trojaner macht, der infiltriert ja ein System. Am ehesten kennt man das noch im Bereich der Software – also Malware in ein System einzubringen; dafür benutzt man trojanische Pferde in Software, aber das können genauso auch andere Daten sein, oder Parameter, z.B. falsche Parameter für Industriesteuerungen, da gibt es ja auch so einige Beispiele dafür. Oder das können zum Beispiel bekannte Werte für Verschlüsselungen sein, wenn ein Verschlüsselungssystem intern eine Verschlüsselung benutzt, die der Angreifer dann hinterher brechen kann, dann ist das für ihn natürlich auch interessant. Und schließlich – das sollte man auch nicht vergessen, deshalb kommen wir nachher auch noch zu den ethischen Themen und den moralischen Aspekten: das „Kompromat“, also kompromittierendes Material, denn mit Hilfe eines Trojaners oder einer Backdoor kann man natürlich auch belastendes Material in ein System hineinbringen und das kann Leute, die das System benutzen oder damit zum Beispiel eine Grenze überqueren möchten und ähnliches, dann durchaus in richtige Schwierigkeiten bringen. Dann gibt’s neben den Trojanern auch die Begriffe Bugdoor und Backdoor und oft wird das miteinander vermischt; dementsprechend haben wir hier mal aufgezeichnet: was ist das eigentlich und wie hängt das ganze zusammen? Man kann sich das eigentlich ganz einfach merken anhand des historischen Vorbildes: Das trojanische Pferd ist eigentlich ja ein Vehikel, das eine Nutzlast trägt – wird aufgemacht, kommen die Soldaten rein, das trojanische Pferd wird von der Stadt, also vom System durch die User, hereingeholt – heute würde man sagen: „Oh toll, eine gratis App! Muss ich haben!“. Wird also in das System integriert, „Gratispferd“ sozusagen. Und… in der Stadt angekommen, schaltet die Nutzlast in dem Pferd, also die Soldaten, zunächst einmal die Sicherheitsfeatures aus (die Wachen) und öffnen dann die Tür für den Rest der Armee. Und das ist genau die Backdoor. Das heißt der Trojaner, oder das trojanische Pferd, bewegt und steuert im Prinzip die Backdoor. Das wär also die richtige Bezeichnung, aber wie gesagt: wird oft vermischt, wollen wir auch jetzt nicht so streng sein. Dann gibt’s noch eine ganz interessante Wortschöpfung – die „Bugdoor“, aus „Bug“ und „Backdoor“. Und das ist im Prinzip einfach schlechte Programmierung oder schlampige Programmierung. Z.B. können das Hintertüren sein in einer entsprechenden Software, die einem Entwickler mal erlaubt haben, z.B. Änderungen vorzunehmen, die dann hinterher aber nicht ausgebaut wurden. Und davon gibt es in der Tat eine ganze Menge. Jetzt ist natürlich die Frage: wo können sich solche Trojaner oder Backdoors eigentlich verstecken? Wo kommen sie her? Das wichtige hierbei ist, dass die Trojaner immer im System selber wirken, also das System ist der Wirkungsort der Trojaner – egal wo sie jetzt herkommen. Sie können auch ihre Plätze tauschen – auch ganz interessant. Und das System besteht immer – jedenfalls die Systeme über die wir hier so sprechen – besteht immer aus Software und Hardware. In der Software ist die Programmierung eines Trojaners eigentlich relativ einfach; jeder, der sich einigermaßen auskennt mit Programmierung, wird in der Lage sein, wenn er lange genug dran arbeitet, einen Trojaner zu schreiben. Das heißt, das Hindernis, so etwas einzubauen ist relativ einfach oder relativ niedrig. Aber es gibt auch einen Nachteil dieser Software-Trojaner natürlich, denn die sind auch relativ leicht zu entdecken. Das heißt, jeder, der an die Software herankommt, der die also disassemblieren kann und verstehen kann, der wird auch sehen, dass da etwas nicht stimmt. Und wenn er das erstmal gefunden hat, dass da irgendetwas faul ist, dann kann er auch einigermaßen leicht einen Beweis führen, was dieser Trojaner eigentlich tut. Da gibt’s ja auch schon bestimmte Arbeiten dazu, die wirklich dann nachgewiesen haben, wie solche Trojaner funktionieren und wann sie aktiv werden und was sie alles können. Anders ist das bei den Hardware-Trojanern: bei den Hardware-Trojanern wird nicht die Software geändert, sondern es wird die Hardware selber geändert und zwar in dem Sinne, dass ein Chip zum Beispiel verändert wird, dass die Funktionalität tatsächlich in der Hardware anders ist. Und da kann man sich vorstellen, dass der Aufwand – das werden wir gleich noch sehen, wie hoch der Aufwand tatsächlich ist – dass der Aufwand recht hoch ist, dass das Ganze teuer ist, dass es vielleicht auch nicht so einfach zu verbergen ist gegenüber anderen Leuten, zum Beispiel in der Entwicklung solcher Geräte. Aber auf der anderen Seite ist es so, dass der Angreifer, oder beziehungsweise derjenige der so etwas macht, auch Vorteile hat. Z.B. ist die Identifizierung relativ schwer. Will man einen Hardware-Trojaner wirklich finden und will man den identifizieren, muss man üblicherweise so einen Chip reverse-engineeren – sich den wirklich ganz genau anschauen. Und selbst wenn man das gemacht hat, ist immer noch die Frage: eine bestimmte Hardwarefunktionalität, die man dann gefunden hat – Was tut sie wirklich? Ist sie wirklich noch aktiv? Oder ist es vielleicht eine schlafende Funktionalität, die nie verwendet wird? Wie dem auch sei – der Beweis ist aufwändig. Um jetzt herauszufinden, wie aufwändig tatsächlich der Einbau eines Hardware-Trojaners ist, ist es natürlich zunächst mal interessant, sich anzuschauen: Wie baut man so einen Chip? Und wenn man das weiß und wenn man diese Prozesse kennt, dann kann man sich auch ansehen: Wo könnte man an diesen Stellen einen Trojaner einsetzen? Und hier einfach mal ganz kurz gezeigt: Wie baut man einen Chip? Wie wird so etwas hergestellt? Links fängt das Ganze an, mit der Hardware-Beschreibungssprache, das ist hier in diesem Fall VHDL zum Beispiel. VHDL ist so etwas wie eine Programmiersprache für Software, bloß dass man ‚Hardware direkt schreibt‘. Und dieser Code enthält im Prinzip dann die Funktionalität – was soll die Hardware tun: Logische Funktionen, ganze CPUen kann man da drin schreiben. Jeder der schon mal mit ‘nem FPGA vielleicht was gemacht hat, der kennt das gut. Wenn diese VHDL-Sprache, wenn der Code fertig ist, dann wirft man den, genau wie Software-Code in einen Compiler und aus diesem Compiler kommt zunächst mal ein Schaltplan heraus. Da sind die einzelnen Funktionalitäten miteinander verbunden, im Prinzip so, wie bei normalen Schaltplänen auch. Und aus diesem Schaltplan kann man dann – das ist das zweite Bild – ein Layout erstellen. Das Layout zeigt, wo auf dem Chip die verschiedenen Funktionselemente liegen und wie die miteinander verbunden sind. Kann man sich so ungefähr vorstellen wie eine Platine – da sind auch die verschiedenen Bauelemente drauf und es gibt Metallverbindungsleitungen dazwischen; hier ist das genauso: die verschiedenen Farben sind auch Metallverbindungsleitungen bloß auf verschiedenen Ebenen. Wenn man daraus jetzt tatsächlich einen Chip machen möchte, dann muss man das Ganze auf ein optisches System übertragen. Das ist hier aufgezeigt anhand eines sogenannten „Maskensatzes“. Das sind also Quarzglasscheiben; ich habe hier mal so einen Rohling mitgebracht. Auf diesen Quarzglasscheiben wird Chrom abgeschieden – eine ganz dünne Schicht – und mikrostrukturiert. Und das benutzt man dann als optische Maske, um einzelne Schichten auf einen Rohsilizium-Wafer nacheinander aufzubringen. Davon braucht man so einige Dutzend von diesen Masken. Und wenn man die dann nacheinander prozessiert hat, dann hat man schließlich den Wafer – ich denke mal das kennt jeder – brauchen wir gar nicht viel drüber zu erzählen. Auf so ‘nem Wafer sind dann die ganzen Chips angeordnet und den muss man nur noch auseinander sägen oder auseinander lasern um dann die einzelnen Chips zu bekommen. Marcus: Nun ist da natürlich die Frage: Wo ist jetzt hier eigentlich der Trojaner? Das heißt, wir sehen: hier gibt’s viel, viel mehr Fertigungsschritte als zum Beispiel wenn man eine Software implementiert. Infolge dessen gibt es natürlich auch viel, viel mehr Möglichkeiten, wo man einen Trojaner implementieren kann. Und in der Tat ist es so, dass es in jeder der einzelnen Fertigungsstufen ein Trojaner prinzipiell eingebracht werden kann, das heißt sowohl im VHDL als auch im Layout oder im Maskensatz. Gehen wir schrittweise vor: Was kann man im VHDL machen? Nun, Peter hatte ja schon gesagt: im VHDL ist die Funktionalität genau beschrieben. Was hindert mich daran, ein paar Zeilen Code mehr reinzuschreiben und eine zusätzliche Funktionalität, nämlich die Trojanerfunktionalität, hier zu integrieren? Das heißt, ein Trojaner kann durch die direkte Implementierung eines VHDL-Codes in ein großes Projekt direkt mit implementiert werden und wird dann natürlich in den folgenden Schritten auch ins Layout, in den Maskensatz und damit in das fertige Produkt mit übernommen. Man merkt schon: die Implementierung ist an der Stelle relativ einfach. Allerdings auch wenn dieser Code genau gereviewt wird und man genauer überprüft „Was steht eigentlich da drin? Was sind die einzelnen Funktionalitäten, die im VHDL beschrieben sind?“, ist auch die Entdeckwahrscheinlichkeit normalerweise recht einfach. Hinzu kommt dann noch, dass dieser VHDL-Code natürlich noch durch viele Schritte prozessiert wird, das heißt viele Leute schauen da noch mal drauf und die Entdeckwahrscheinlichkeit steigt damit. Selbst wenn der VHDL-Code ohne Trojaner geschrieben worden ist, könnte im Schritt des Layoutes noch ein Trojaner eingebracht werden. Wir sehen hier auf dem Beispiel ja die verschiedenen elektrischen Verbindungen, wie Peter schon gesagt hat, in den verschiedenen Farben. Und mit einem speziellen Layout-Programm, vergleichbar praktisch mit einem Bildbearbeitungsprogramm, kann man natürlich auch diese Verbindungen verändern, kann neue Elemente einfügen, kann die elektrischen Verbindungen so verändern, dass eine zusätzliche Funktionalität – die Trojaner-Funktionalität – implementiert wird. Schon allein da dran merkt man allerdings, dass der Aufwand natürlich deutlich höher wird. Eine Vielzahl von Elementen und eine Vielzahl von Leitungen müssen verändert werden und das heißt, dies ist nichts mehr, was man schnell nebenbei in einen Code reinschreibt, sondern tatsächlich viele Stunden Arbeit. Dafür: Wer schaut sich das Layout schon genau an? Das heißt also auch, die Entdeckung ist an dieser Stelle normalerweise zumindest mal schwerer als beim VHDL. Man müsste wirklich jede einzelne Leitung dann wieder verfolgen, wo geht sie hin, ist das die gewünschte Funktionalität. Naja, und so, wie man aus dem Layout den Maskensatz macht, kann man natürlich auch im Maskensatz selber auch einen Trojaner einbringen. Das heißt also: die Strukturen, die auf der Maske vorgezeichnet sind und dann später in dem Chip realisiert werden sollen, kann man natürlich auch auf der Maske verändern. Jetzt kann man schwererdings einfach die Belichtungsmaske hernehmen und da mit ‘nem Skalpell oder sowas kratzen – das ist einfach viel, viel zu grob. Stattdessen muss man dann natürlich tatsächlich einen neuen Maskensatz oder zumindest neue Masken, die man geändert hat, erzeugen und dafür braucht man natürlich schon hochpräzises Spezialequipment. Infolgedessen ist die Implementierung nochmal komplizierter als beim Layout; man muss nicht nur die Leitungen und die Elemente verändern, sondern auch noch die Gerätschaften dafür haben. Die Entdeckung auf der anderen Seite ist dafür dann normalerweise natürlich nochmal eine ganze Stufe schwerer, denn: Wie soll man genau so eine Maske verifizieren, dass sie keine veränderten Funktionalitäten enthält? Man müsste dann wieder einen Vergleich zum Layout (machen) – und hoffen, dass das sich das Layout nicht verändert hat in der Zwischenzeit durch jemanden, der den Trojaner einbringen möchte… Also man merkt: die Entdeckung wird hier schon sehr kompliziert. Das waren jetzt Möglichkeiten, wie man Trojaner – so wie man es sich jetzt direkt denkt – einfach implementieren kann. Aber: ihr seht auch hier haben wir schon angegeben, dass die Entdeckung normalerweise einfach, mittelschwer oder schwer ist. Warum „normalerweise“? Denn es gibt – wir nennen es „Snakeoil-Features“, die stark begünstigen können, dass man Trojaner einbringen kann und auf der anderen Seite sogar sehr stark erschweren können, dass man Trojaner detektieren kann. Snakeoil-Features, klar, das Schlangenöl, das angepriesen wird wie ein Wunderheilmittel, tolle Wirkung haben soll, aber vielleicht auch tatsächlich die Wirkung nicht ganz so entfaltet – oder sogar noch viel schlimmer: sogar noch eine Nebenwirkung, eine gefährliche Nebenwirkung ausprägen kann. Und genau das kann hier auch passieren: etwas, was man vielleicht mit dem guten Gefühl eingebaut hat in den VHDL-Code, um eine Funktionalität, um ein Security-Feature zu realisieren, dass sich dann natürlich im Layout, im Maskensatz und letztlich im Produkt auch wiederfindet. Aber: vielleicht ermöglichen solche Features auch ‘ne ganz leichte Modifikation in dem Herstellungsprozess. Schauen wir uns an, wie das zum Beispiel am Anfang der Prozesskette ausschauen kann. Stellen wir uns vor, dass der VHDL-Code nicht einfach geschrieben ist, sondern komplexer ist – ein VHDL-Code, direkt ansehen kann: Was steckt da eigentlich drin? In diesem komplexen Quellcode ist es natürlich auch viel, viel leichter, andere Funktionalitäten mit reinzubringen, die man zunächst einmal vielleicht gar nicht vermutet. Die Detektion, dadurch dass er ja komplexer ist, ist automatisch auch schwerer. Man muss diese ganzen komplexen Funktionen dann natürlich genau nachvollziehen; was passiert da eigentlich? Ist das nur Theorie? Naja, wir kennen ja aus der Software-Welt die sogenannte „White-Box-Kryptografie“. Die White-Box-Kryptografie nutzt ja gerade möglichst komplexe Software-Codes, um da drin kryptografische Schlüssel zu verstecken. Das heißt: um einen kryptografischen Schlüssel in einer Software möglichst gut gegen Ausspähen zu verstecken, wird halt das Thema White-Box-Kryptografie angepriesen. Die Codes hier drin sind so komplex, dass man sie an sich kaum noch wirklich durchschauen kann. Übertragen wir das auf die Hardware: Was bedeutet, wenn man statt dem VHDL-Code, der hier abgebildet ist, plötzlich eine viel komplexere Struktur einbaut, wie wir hier symbolhaft in dem roten Kasten abgebildet haben. Diese komplexen Funktionen genau zu durchleuchten – was steckt da eigentlich alles hinter? – ist natürlich ungleich schwerer, und somit kann man relativ einfach dann auch schwer erkennbare Trojaner einschleusen. Selbst, wenn es nicht am vorderen Teil der Herstellungskette eingeschleust wird, können (…) Snakeoil-Features begünstigen, das man zu einem späteren Prozessschritt entsprechend noch Veränderungen vornimmt. Stellen wir uns vor, ein Snakeoil-Feature ist im VHDL-Code integriert worden mit dem guten Gefühl „Ja, das ist jetzt das Wundermittel. Das hilft uns. Das macht den Chip jetzt so viel sicherer.“ Aber erlaubt vielleicht bei dem Maskensatz mit einer einfachen zusätzlichen Maske eine Manipulation vorzunehmen und damit tatsächlich die Chips in einer Art und Weise zu verändern, dass man sie leicht kontrollieren kann. Wie könnte sowas aussehen? Ein praktisches Beispiel dafür sind die sogenannten „physical unclonable functions“, die eine hohe Gefahr bergen, dass sie manipuliert werden können. Bei den physical unclonable functions wird ja bei den S-RAM physical unclonable functions der interne Arbeitsspeicher verwendet, der beim Einschalten die Zellen eher… einige Zellen eher nach 0 kippen lassen, andere Zellen eher die Vorzugsrichtung nach 1 haben. Das ist bausteinindividuell und hängt von ganz kleinen Herstellungstoleranzen ab. Damit hat man also einen bausteinindividuellen Wert, der hier erzeugt wird; insbesondere, wenn bei jedem Einschalten wieder das gleiche Muster entsteht, kann man hieraus natürlich versuchen, zum Beispiel kryptografische Schlüssel abzuleiten, eben die Funktionalität einer „physical unclonable function“. Dieses Einschaltverhalten ist aber natürlich insbesondere durch eine einfache zusätzliche Maske im Herstellungsprozess leicht manipulierbar: Ich kann einfach die RAM-Zellen durch eine Maske in eine Vorzugslage bringen, dass eben gewisse Zellen, die ich kenne als Einbringer dieser Maske, eher nach 0 kippen, oder andere eher nach 1 kippen. Was passiert ist, dass ich die Veränderung in diesem Chip kennen würde, jemand anderes, der den Chip aber beobachtet, zunächst einmal nicht weiß: Ist das jetzt ein bausteinindividueller zufälliger Wert, oder ist das ein Wert, der verändert worden ist? Und genau das zeigt ja schon, wie kompliziert es ist, solche Trojaner dann zu identifizieren. Eine ähnliche Methode ist auch denkbar bei den sogenannten „Camouflage Chip Designs“ – hier handelt es sich nicht um eine einfache Speicherzelle, sondern um ein universelles Logik-Element. Dieses Logik-Element wird zunächst einmal im Schaltplan platziert und kann zu einem späteren Zeitpunkt im Herstellungsprozess festgelegt werden, ob es jetzt zum Beispiel eine UND- oder eine ODER-Verknüpfung oder eine andere logische Verknüpfung darstellen soll. Genauso, wie die Programmierung in diesem letzten Schritt durch die Maske erfolgt, kann ich natürlich auch, wenn ich einen Trojaner einbringen möchte, hier eine spezielle Maske einschmuggeln und damit dann entsprechend die Funktionalität so verändern, wie sie für mich als Hardware-Trojaner-Anwender dann von Vorteil wäre. Also man sieht schon, dass neben den normalen Arten, wie man einen Trojaner in einen Chip einbringen kann auch viele Möglichkeiten bestehen, die zum Beispiel über solche Snakeoil-Features dann deutlich begünstigt werden und die sehr schwer teilweise zu detektieren sind. Und selbst wenn man sagt: „Moment, der Hardware-Trojaner muss ja irgendwann mit der Außenwelt kommunizieren. Kann man das dann nicht einfach detektieren?“, so sehen wir, dass es auch sehr, sehr viele verschiedenartige Backdoors gibt, die als Mittel zur versteckten Kommunikation genutzt werden können. Das kann sowohl über Protokolle erfolgen, das kann über Seitenkanal-Informationen erfolgen – die aber im Gegensatz zu Seitenkanal-Angriffen hier gezielt Informationen ausgeben – das kann über Chip-Manipulation, das heißt also tatsächlich über physikalisches Beeinflussen des Chips oder sogar über Fehlerinduktion erfolgen. Und diese Vielfältigkeit, die man hier hat für diese Backdoors finden wir sehr spannend und deshalb möchten wir auch auf einige dieser Fälle jetzt genauer drauf eingehen. Hier haben wir für uns aber insbesondere eine Auswahl getroffen, wie man auch unten an den Beispielquellen sieht, die auch publiziert sind; denn wir möchten jetzt natürlich nicht noch Dienste auf irgendwelche neuen, interessanten Ideen bringen, sondern wir möchten eher aufklären und zeigen, was für Möglichkeiten gibt es überhaupt, wie Protokolle missbraucht werden können um Daten zu übertragen. Und das bekannteste natürlich, was man auch von Software-Trojanern kennt, ist natürlich, dass undokumentierte Befehle oder Befehlssequenzen akzeptiert werden, oder auch ein Generalschlüssel integriert wird, mithilfe dessen man dann unbemerkten Zugang auf die internen Daten oder auf den Code haben kann. Eine andere Methode, ebenfalls aus der Welt der Software-Trojaner relativ gut bekannt, sind geschwächte Krypto-Algorithmen. Derjenige, der den Trojaner einbringt, der kennt halt: welche Funktionalität hat er hier als Backdoor gewählt und wie kann er den kryptografischen Algorithmus relativ leicht angreifen. Das heißt, er kann dann die kryptografischen Geheimnisse extrahieren und damit dann an die internen Daten rankommen. Ein Szenario, was aber auf den Protokollen bisher noch nicht so groß diskutiert worden ist, ist das Thema „Watermarking“. Klar, Watermarking kennen wir zum Beispiel aus dem Bereich, wo Videos, Bilder oder Audiofiles übertragen werden, als Kennung „Wo kommt diese Datei eigentlich her?“. Aber was passiert eigentlich, wenn ein Chip eine größere Menge Daten ausgeben muss und hier einfach ein Watermarking sozusagen steganografisch Zusatzinformationen in dem Output versteckt? Wer nicht das Verfahren kennt, wie man diese Daten daraus extrahiert, wird sich sehr schwertun, festzustellen: Ist das eigentlich jetzt die normale Datei, die normale Information, die rauskommt, oder sind da vielleicht ein paar einzelne Bits eben verändert über die dann Informationen aus dem Chip herausextrahiert werden? Und genau dieses Wissen ist besonders auch, was bei Seitenkanal-Backdoors schwer ist, diese zu detektieren. Beobachte ich das Stromprofil, oder zum Beispiel die elektromagnetische Abstrahlung, so kann ich relativ einfach detektieren: Ja, das schaut alles zufällig aus. Oder: Das schaut alles irgendwie aus, als ob es einfach der Funktionalität geschuldet ist. Aber jemand der speziell diese Backdoor eingebracht hat, weiß vielleicht, dass er genau zu gewissen Zeitpunkten den Stromverlauf oder die elektromagnetische Abstrahlung sich anschauen muss, und kriegt damit dann die einzelnen Informationen übertragen über eben zum Beispiel die Amplitude, wieviel Strom verbraucht worden ist, oder wieviel abgestrahlt worden ist. Also ein Verfahren, was auch relativ schwer zu detektieren ist, um zu sehen: ist da jetzt eigentlich eine zusätzliche Informationsausgabe oder nicht? Noch komplizierter wird es beim Thema Lichtabstrahlung. Viele kennen sicherlich, dass wenn ein Transistor mehrere Male schaltet – typischerweise so 1000 bis 10.000 Mal – entsteht als Nebenprodukt auch ein Photon, ein infrarotes Lichtteilchen. Und dieses kann man natürlich messen oder zum Beispiel mit speziellen Kameras aufnehmen. Damit kann man sehen, wo ist zum Bespiel Aktivität im Chip, wo sind viele Transistoren, die schalten. Aber, wenn man eine entsprechende Backdoor einbaut, könnte man natürlich auch ein Element auch so gezielt manipulieren, dass es besonders häufig Informationen oder häufig Photonen ausstrahlt, oder noch viel interessanter: man weiß einfach, an welcher Stelle ist dieser Transistor, den ich beobachten muss, und damit „morst“ sozusagen, wie mit einer Taschenlampe dieser Transistor dann die Informationen halt entsprechend raus. Genauso messen kann man auch das Potenzial natürlich auf Signalleitungen; sicherlich habt ihr bei unserem Vortrag „25 Jahre Chipkarten-Angriffe“ auch gesehen, wie man mittels Elektronen-Rastermikroskop die Potenziale auf elektrischen Leitungen messen kann. Wenn ich jetzt den gesamten Chip beobachte, dann sehe ich natürlich eine Vielzahl von Potenzialen auf den einzelnen Leitungen. Aber: Jemand der gezielt diese Backdoor nutzt, hat sich vielleicht eine Leitung in eine obere Metalllage gelegt, von der er weiß, hier laufen alle kritischen Daten rüber. Jetzt kann er diese einfach mit dem Elektronenstrahl ausmessen und damit dann die Informationsübertragung aus dem Chip heraus in das System – in das Analysesytem – vornehmen. Ja, und wie vielfältig das Ganze ist, sieht man sogar (daran), dass selbst die Temperatur genutzt werden kann. Auch hier gibt es gerade jüngste Quellen, die zeigen, dass auf einem Multi-Core-System auf dem einen Prozessor viel gerechnet wird und das die Bearbeitung auf dem anderen Core in diesem System beeinflusst. Ja, viel mehr noch: es gibt sogar eine entsprechende Veröffentlichung, wo einfach zwei PCs nebeneinander stehen; auf dem einen PC wird gerechnet und auf dem anderen PC wird aufgrund der intern integrierten Temperatursensoren dann die Erwärmung beobachtet und somit praktisch kontaktlos von einem System zum anderen die Information übertragen. Natürlich: das ist sehr, sehr langsam, weil so Temperatur ändert sich natürlich nicht so schnell, da spricht man nur von wenigen Bits pro Stunde, die übertragen werden können, aber immerhin – auch solche Seitenkanäle können dafür genutzt werden. Sehr viel bekannter sind wiederum Manipulations-Backdoors; wer kennt es nicht, dass auf einem Chip, wenn man sich den mal genauer anschaut, vielleicht nicht nur die angeschlossenen Kontaktfelder sind, sondern vielleicht auch zusätzliche Kontaktfelder, wo im Datenblatt ganz lapidar „n/c“ – not connected dransteht, oder „RFU“ – for future use. Wer weiß, was dahinter wirklich steckt, ob die wirklich nicht angeschlossen sind, oder ob da nicht eine zusätzliche Funktionalität ist – sei es eine Debug-Schnittstelle oder andere Funktionalitäten, über die man dann mit dem Chip entsprechend kommunizieren kann? Und genauso, wie man das auf den Kontaktfeldern beobachten kann, ist natürlich auch denkbar, dass man (…) bei der Implementierung eines Trojaners eine vorbestimmte Signalleitung auf dem Chip implementiert und wird diese zum Beispiel mittels eines Laserstrahls durchgeschnitten – ein normaler Lasercutter, der auch auf dem Gebrauchtmarkt recht preiswert zu haben ist – dann kann man entsprechend die Zusatzfunktionalität in diesem Chip vielleicht freischalten und dann plötzlich erst nach dieser Manipulation, nach diese physikalischen Manipulation mit dem Chip kommunizieren. Und selbst Speicherzellen wie zum Beispiel das RAM, hatten wir eben ja schon gesehen bei physical unclonable functions, bei den sogenannten „unklonierbaren Funktionen“, kann man mittels zum Beispiel Ionenimplantation auch verändern und damit andere Daten vorgeben oder die Funktion der Schaltung verändern. Last but not least: der Bereich der Fehlerinduktion kann auch noch genutzt werden, um (…) durch die Backdoor zu kommunizieren und dem Trojaner entsprechend Informationen mitzuteilen. Zum Beispiel könnte man spezielle Elemente mit einem Laserstrahl anleuchten – und klar, der Chip ist aus Silizium, das ist am Ende nichts anderes als auch eine Solarzelle vielleicht auf dem Dach – das heißt, der Laserstrahl induziert dann eine kleine Photospannung oder einen Photostrom und kann dadurch dann natürlich eine Schaltfunktionalität auslösen, die man von außen so gar nicht direkt steuern kann, wenn man nicht genau weiß, wo man mit dem Laser draufblitzen muss. Was bekannter ist, ist auch, das häufig Speicher mit Schutzmechanismen ausgestattet werden. Wer kennt es nicht: nachdem man ein Programm in einem Mikrocontroller heruntergeladen hat, dann wird ein Schreibschutz-Bit gesetzt und anschließend soll es nicht mehr möglich sein, die Daten auszulesen. Wenn man aber als Designer vielleicht genau weiß: diese Transistorzelle entscheidet jetzt darüber, ob man einen Zugriff hat, oder nicht, weiß man vielleicht auch wo man genau mit dem ultravioletten Licht draufleuchten muss, um diesen Schreibschutz halt zu deaktivieren und dann doch wieder einen Zugriff auf den Speicher zu bekommen. Jetzt gibt es das teilweise, dass das tatsächlich als Bugdoor, wie Peter ja auch schon erklärt hat, einfach als schlechtes Design implementiert ist. Aber es könnte natürlich auch vorsätzlich implementiert sein, als Backdoor, dass der Designer genau weiß wenn ich die Daten hier raus haben möchte, dann lösche ich diese eine Speicherzelle, z.B. mittels UV-Strahlung und habe dann den Zugriff. Eine sehr spannende, aber auch kniffligere Sache ist das Thema der Zufallszahlen-Generatoren. Die Zufallszahlen-Generatoren werden ja viel genutzt um kryptographische Funktionen abzusichern. Der Zufall, eben eine nicht vorhersagbare Funktion innerhalb dieses Chips, auszunutzen um z.B. Daten zu randomisieren, oder aber Abläufe zufällig zu gestalten. Das Ganze wir aber natürlich ad-absurdum geführt, wenn man diese Zufallszahlen von außen beeinflussen kann. Oder aber sogar deren Werte vorgeben kann. Und genau auch das ist mit Fehlerinduktion denkbar, dass man z.B. von außen ein elektromagnetisches Feld, also im Prinzip eine Radiofrequenz vorgibt, und damit die internen Zufallszahlen in einer Weise beeinflusst, dass man direkt Daten einprägen kann, oder aber zumindest aufsynchronisieren kann, dass man nicht mehr unvorhersagbare, sondern vorhersagbare Zufallszahlen generiert. Eine Geschichte, nur wer genau diese Frequenz kennt, wie er es einkoppeln kann, kann diese Backdoor dann nutzen um z.B. die Zufallsprozesse innerhalb des Chips außer Gefecht zu setzen. Naja und wenn wir über Sicherheitschips sprechen, dann wissen wir ja auch, dass sehr häufig z.B. Sensoren eingebaut werden. Sensoren um Angriffe zu vermeiden, seien es z.B. Spannungssensoren, Sensoren gegen Lichtbestrahlung, Temperatursensoren usw. Wer sagt denn, dass diese Sensoren tatsächlich den gesamten Raum abdecken, oder ob vielleicht nicht absichtlich eine Schutzlücke eingebaut worden ist, das heißt derjenige, der diesen Sensor implementiert hat, weiß vielleicht dass genau bei diesem genauen Parametersatz ist der Sensor „blind“ sozusagen, und er kann diesen Parametersatz nutzen, um gezielt eine Fehlerinduktion in dem Programmablauf oder in den verrechneten Daten einzuführen. Und damit dann entsprechend, auch wieder mit dem Trojaner zu kommunizieren. Also man sieht schon, es gibt rund um das Thema Backdoors sehr, sehr viele verschiedene Möglichkeiten in der Hardware – weitaus mehr Möglichkeiten als bei Software-Trojanern – wie man mit ihm kommunizieren kann und wie man hier auch tatsächlich Informationen austauschen kann. Eine besondere, große Bedrohung geht von den Analyseschnittstellen aus. Denn die Analyseschnittstellen sind ja meistens ein Feature was sogar mit einer guten Intention eingebaut worden ist. Z.B. bei den Festplatten, wie man hier im oberen Bild sieht, wo ein Debug-Port eingebaut worden ist, um, wenn die Festplatte nicht richtig funktioniert, festzustellen, was ist da jetzt wirklich kaputt, kann man vielleicht eine neue Firmware einspielen, kann man vielleicht noch Daten retten. Auf der anderen Seite kann genau dieser Debug-Port natürlich auch dafür missbraucht werden, um auf Daten direkt zuzugreifen oder aber um Trojaner in die Firmware der Festplatte einzuspielen. Ja, und noch größer ist natürlich der Bereich der sogenannten JTAG-Ports, die Analyse-Schnittstelle, die sich in vielen Geräten wiederfindet und teilweise sehr mangelhaft abgesichert ist. Denn hier haben wir ein Beispiel von einem WLAN-Router, wo man über den JTAG-Port auch neue Firmware, z.B. mit Trojanern, in die WLAN-Router einbringen kann. Denken wir das jetzt noch einmal weiter: was passiert, wenn jetzt eigentlich ein Sicherheits-Chip mit solch einem Analyse-Port ausgestattet ist? Nun, da kann man natürlich sagen, wenn dieser Chip mal ausfällt, kann ich versuchen, darüber dann tatsächlich nochmal den zu reparieren, oder zumindestens an die Daten wieder ranzukommen, sie zu restaurieren. Ja, aber, genau das ist ja das was man nicht möchte. Ein Sicherheits-Chip soll doch bitte die Daten auch wirklich geheim in sich halten und nicht dann über einen Analyse-Port vielleicht doch wieder zugänglich machen. Und deshalb sind insbesondere auf Sicherheits-Chips natürlich Analyse-Ports alles andere als eine gute Wahl. Und wie manches Mal aus einem guten Feature tatsächlich dann auch eine missbräuchliche Nutzung entstehen kann, haben wir einfach mal dargestellt an dem Beispiel eines Türspions. Wir sehen hier den Türspion. Und im zweiten Bild einfach mal was passiert eigentlich, wenn ich durch den Türspion nach draußen schaue: naja, ich habe die gute Möglichkeit, zu sehen: wer steht da eigentlich vor der Tür? Ist das eine zumindestens dem Anschein nach vertrauenswürdige Person? Sollte ich jetzt besser die Tür öffnen oder lieber besser geschlossen lassen? Genauso wie diese gute Funktionalität in dem Türspion drin ist, kann sie aber auch missbräuchlich genutzt werden. Wenn ich z.B. wie im 4. Bild zu sehen, eine Umkehr-Optik von draußen aufsetze, dann sehe ich nicht mehr nur den kleinen Lichtpunkt hinter der Tür, wo das ganze Bild zusammengezerrt ist; sondern aufgrund dieser Umkehr-Optik kann ich plötzlich feststellen, was ist eigentlich in der Wohnung? Es erlaubt mir den Blick nach innen und damit: wer ist eigentlich in der Wohnung, oder ist da überhaupt jemand? Wie ist sie ausgestattet? Und so weiter. Das ist unseres Erachtens nach ein schönes Beispiel, wie tatsächlich auch ein gut gemeintes Feature eventuell dann eben als Backdoor missbraucht wird. Peter: Ja, in den 90er Jahren – Ende der 90er Jahre, würde ich sagen – war ziemlich klar, dass nach Software-Trojanern als nächstes Hardware-Trojaner auf dem Plan stehen. Dass das also eine echte Bedrohung ist. Und dementsprechend haben wir uns zu der Zeit auch schon mal überlegt, was kann man eigentlich machen, prophylaktisch, um sowas zu verhindern, um das Risiko zu minimieren; und überhaupt Technik so zu bauen, dass sie Trojaner- und Backdoor-resistent ist. In dem Rahmen, wie das möglich ist. Und um uns dieser Sache zu nähern, haben wir uns zunächst mal überlegt, was können das eigentlich für Motive sein? Also was bringt eigentlich die Leute dazu, Trojaner und Backdoors einzubauen? Ob das jetzt willentlich ist oder unwillentlich. Das zeigen wir hier in diesen 4 Kategorien. Es fängt an mit dem „Bösen Willen“, hier auf dem ersten Foto mal zu sehen. Beim Bösen Willen ist es im Prinzip ganz klar, daran denkt jeder zunächst mal als erstes. Es könnten Sabotagegründe sein, z.B. Erpressung könnte eine Rolle spielen. Ein bestimmtes System ist schon im Feld und ein Hersteller, z.B. dieses Systems wird erpresst, dass man mit einem bestimmten Kommando einer Backdoor dieses System komplett lahmlegen könnte. Zum Beispiel. Aber es können auch politische Motive da eine Rolle spielen. Auch alles bekannt; also der Diktator unserer Wahl sozusagen möchte seinen Bürgern etwas näher auf den Zahn fühlen und die Kommunikation überwachen, baut dementsprechend Backdoors ein. Oder, bringt Trojaner ins Spiel. Auf der anderen Seite des Spektrums, ganz interessant, der Gute Wille. Auch das geschieht dann aus Vorsatz. Und Markus hatte da ja schon einige Beispiele mal gezeigt: das können Dinge sein, wie z.B. Service-Schnittstellen, das können Debugging-Sachen sein. Im Prinzip, letztlich sogar, Kundendienst, dass jemand also wirklich fragt, er möchte bei so einem Chip die Möglichkeit haben, im Nachhinein was zu reparieren oder die Daten wieder rauszuholen. Passt natürlich nicht zu Sicherheits-Chips. Und dann schließlich, auch da gibt’s politische Motive. Da ist es dann nicht der fiese Diktator unserer Wahl, sondern der freundliche Monarch unserer Wahl, der aber das Gleiche will, seinen Bürgern auf den Zahn fühlen und alles mitlesen können. Wir haben auch noch zwei andere Kategorien hier aufgezeigt. Die sind nicht aktiver Natur. Also nicht vorsätzlicher Natur, sondern eher passiver Natur. Und zwar haben wir die erstmal als Ignoranz und Dummheit bezeichnet, und das auch voneinander getrennt. Warum haben wir das voneinander getrennt? Bei der Ignoranz ist es so, dass die Auswirkungen zumindest teilweise bekannt sind. D.h. jemand weiß eigentlich, das was er da gerade macht, in einer bestimmten Entwicklung oder Konzeptionierungsphase, dass das eigentlich falsch ist. Es könnten z.B. Gründe dahinterstehen, wie Zeitdruck. Eine Analyse-Schnittstelle z.B. soll für ein fertiges Produkt noch ausgebaut werden. Eigentlich muss man das machen, um den Chip dann sicher zu bekommen. Es wird aber aus Zeitdruck nicht gemacht. Dazu kann z.B. auch noch Verdrängung kommen, dass man dann sich sagt „Ja, es ist ja nicht so schlimm, das wird schon keiner finden“. Oder eben auch, dass Hierarchien eine wesentliche Rolle spielen; dass jemandem gesagt wird „Mach’ das mal so, bau’ das mal so ein!“ und das nicht hinterfragt wird, warum das eigentlich notwendig ist, wofür man das eigentlich braucht, und ob man das hinterher wieder ausbauen soll. Oder drinlassen soll. Ja, und dann schließlich, das Thema ‚Dummheit‘ haben wir hier auch explizit mal so genannt, so plakativ. Einerseits Bildungsmangel, Überforderung kann eine Rolle spielen. Auch etwas plakativ hier mal dargestellt, das Thema ‚Fachidiotie‘ wirklich zu nennen. Das ist wirklich die Plage des 21. Jahrhunderts. Denn die Systeme die man heute baut, die sind sehr, sehr komplex und da sind teilweise Hunderte von Entwicklern, Hunderte von Leuten dabei sowas zu machen. Wie das Einzelne ineinander spielt, also welches Zahnrad in welches andere Zahnrad greift, und welche Zahnräder in Kombination zusammen ein Schlangenöl ergeben oder auch nicht, das ist oft nicht bekannt. Und auch da hatte Marcus ja schon so einige Beispiele mal gezeigt, wie eine eigentlich gut gemeinte Sache dann schließlich zu einer Backdoor führt oder zu einem hohen Risiko des Backdoor-Auftretens. Und natürlich für uns interessant gewesen: was kann man dagegen tun? Und auch hier haben wir uns 3 Kategorien ausgedacht: die Aufklärung Technologie – also technologische Gegen- maßnahmen, und die Verpflichtung – kann von extern oder auch selbst passieren. Und hier an diesem grünen und grauen Streifen haben wir mal versucht aufzuzeigen, wie wirksam das Ganze ist. Und das erste, was wir da aufgezählt haben, die Aufklärung, ist natürlich ganz klar gegen Dummheit, gegen Nichtwissen nützt am besten Aufklärung. Gegen bösen Willen auf der anderen Seite nützt Aufklärung wenig. Vielleicht sogar im Gegenteil, wenn man jemandem sagt: „Das wäre also wirklich der Tod des Unternehmens, wenn da so eine Backdoor eingebaut wäre, die so und so aussieht“, dann kann das natürlich sein, dass der Saboteur genau das dann einbringt. Klar. Aber wie gesagt, die Aufklärung sehen wir als ganz, ganz wichtig an. Bei der Technologie... bei den technologischen Gegenmaßnahmen, da ist es so, dass einerseits man sagen muss, ist vom Motiv des Angreifers eigentlich unabhängig. Technologische Gegenmaßnahmen erschweren den Einbau von Backdoors und Trojanern generell. Trotzdem haben wir das Ganze etwas eingekerbt, auf der rechten und auf der linken Seite. Und das hat auch seinen Grund: weil diese beiden Bereiche mit Vorsatz verbunden sind. Und das könnte heißen, dass jemand z.B. der so etwas vorhat sich schlaumacht: was sind denn da für technologische Gegenmaßnahmen eingebaut; und dann versucht, vielleicht auch mit anderen Leuten zusammen, um diese technologischen Gegenmaßnahmen herumzukommen und die außer Kraft zu setzen. Und dann schließlich gibt es noch die dritte Kategorie: die Verpflichtung, kann Selbstverpflichtung sein oder auch externe Verpflichtung, da kommen wir gleich noch drauf zu sprechen, auf diese 3 Bereiche. Und auch da ist es so, dass das sehr, sehr unterschiedlich wirksam ist. Beim Bösen Willen natürlich am wenigsten, aber bei den anderen Motiven schon etwas mehr. Aber wie versprochen etwas mehr über diese Möglichkeiten, was kann also jeder tun, der in einem dieser Bereiche Entwicklung, Konzeption oder auch Test arbeitet, um Backdoors zu verhindern oder die zu erkennen. Und einerseits hier nochmal die Punkte der Aufklärung. Das kann technische Aufklärung sein, das steht natürlich im Vordergrund. Security by Obscurity darf nicht das Ziel sein. Kerckhoffs sollte man schon berücksichtigen, wenn man irgendetwas baut. Debug-Schnittstellen passen nicht zu Sicherheits-Chips – auch ganz wichtig. Obwohl es immer wieder nachgefragt wird, kann man nicht für eigene Entwicklungen, für eigene Fehleranalyse z.B so etwas einbauen. Gehört da nicht rein. Muss leider draußen bleiben. Und nicht zu vergessen unser Aspekt auch hier, Entwickler denken sehr oft nicht wie Hacker. D.h. sie sind eher konstruktiv, manchmal konstruktivistisch unterwegs, und das bedeutet, dass man oft seinen eigenen Resultaten oder dem was man da zusammengebaut hat, dann sehr hoch vertraut. Und einen Angriff z.B. oder einen Sicherheits-Penetrationstest dann eher so als Angriff auf die eigene Person sieht. Und jeder der im IT-Sicherheits-Business tätig ist, der kennt das auch, dass man da erstmal so eine konstruktive Atmosphäre schaffen muss. Indem man zusammen das Produkt dann besser macht. Politische Aspekte sind natürlich auch ein wichtiges Thema. Hier der Frankenstein-Effekt, sozusagen, zu nennen. Wenn man so einen Trojaner tatsächlich irgendwo in der Praxis hat, dann ist der unkontrollierbar. D.h. man weiß nicht, was damit passiert, wer den benutzt, schließlich. Er kann sich natürlich auch gegen seinen eigenen Urheber richten. Und gleichzeitig ist es auch so, braucht man bloß ins Geschicht-Buch reinzuschauen, dass die politischen Situationen sich auch ändern können. Das ist hier vielleicht nicht unbedingt so stark der Fall, im eigenen Land. Aber wenn ein Hersteller z.B. in verschiedene Länder exportiert, 100..150 Länder, dann ist die Wahrscheinlichkeit doch relativ hoch, dass eins davon in den nächsten Monaten oder Jahren dann mal umkippen könnte. Und dementsprechend wäre auch darauf natürlich zu achten. Das Ganze verbunden auch mit den ethischen Aspekten. Für uns auch wichtig, denn Backdoors können Personen in tödliche Gefahr bringen. Das ist also kein Spiel. Und kein Spielzeug, sondern, wenn, gerade wenn man z.B. an das Thema Kompromat denkt, und jemanden mit Top-Secret-Material, was ihm da ‚aufgeschleust‘ wurde, sozusagen ‚angeschleust‘ wurde, an einer Grenze festgehalten wird, dann ist das schon durchaus unangenehm. Wir sagen da immer: „The road to hell is paved with good intentions“, gilt eigentlich für alles da, was da steht. Oder auf Deutsch, frei nach diesem Motto „Gut gemeint ist nicht gut gemacht“. Ja, es gibt einige technologische Gegenmaßnahmen gegen Trojaner und Backdoors, also rein prophylaktisch, was auch sehr, sehr wirksam ist. Dazu gehört zunächst mal: keine backdoor-fördernden Technologien einzusetzen. Die gehören raus, und wenn man merkt, dass eine Technologie backdoor-fördernd ist, oder sowas begünstigt, dann sollte man die in Sicherheits-Chips nicht verwenden. Darüber hinaus gibt es ein paar Möglichkeiten, dass man das Design so anlegt, dass Änderungen auffallen. D.h. jemand anderes, der auch an dem Design arbeitet, eher merkt, dass etwas nicht stimmt, oder dass im Test oder in der Evaluierung dann auffällt, dass etwas nicht stimmt, weil die Änderungen, die durchzuführen sind, größer sind als das was man bei schlangenöl-haltiger Technologie machen muss. Der Rest ist im Prinzip ähnlich wie beim Thema der technologischen Aufklärung. Aber wir haben hier auch gleichzeitig noch 2 andere Möglichkeiten aufgeführt. Das sind die Selbsttest von Chips. Und die Erkennung nachdem ein Chip fertig ist. Aber da muss man ein bisschen vorsichtig sein. Bei den Selbsttest ist es noch so, dass die einigermaßen wirksam sind. Das bedeutet, dass ein Chip bevor er eine wirklich kritische Operation macht, also z.B. eine Nachricht verschlüsseln, dass er vorher eine Testoperation durchführt und schaut ob alles okay ist. Ob die Schlüssel nicht manipuliert sind, die Zufallszahlen in Ordnung sind usw. Da gibt’s also ’ne ganze Menge dieser Selbsttest, und wenn die alle vernünftig durchgelaufen sind, dann macht ein Chip die eigentliche Operation. Aber kann natürlich sein, dass ein Insider sich Gedanken macht und überlegt, was könnte da alles eingebaut sein das mir das Leben schwer macht. Und dementsprechend auch diese Tests manipuliert. Bedeutet aber, dass man da mehr Einfluss braucht, mehr Aufwand, und vielleicht sogar Mitwisser. Das ist natürlich dann auch ein Problem. Bei der Erkennung sind wir etwas skeptischer, also es gibt einige Resultate, einige Arbeitsgruppen, auch die sich mit dem Thema Erkennung auseinandersetzen und sagen man könnte doch bei einem fertigen Chip, wenn der sozusagen fertig prozessiert ist, schauen ob da ’ne Backdoor drin ist, anhand z.B. der Stromaufnahmekurven, die dieser Chip dann liefert. Da muss man aber sehr vorsichtig sein, denn üblicherweise würde so eine Backdoor ja so angelegt werden, dass sie nicht ständig aktiv ist. Und außerdem ist es so bei Sicherheits-Chips, bei Sicherheits-Software und auch bei Sicherheits-Hardware, dass der Stromverbrauch sowieso immer relativ zufällig gewählt wird. Einfach auch um Seitenkanal-Angriffe abzuhalten. Dementsprechend ist so eine Entdeckung von Manipulation am fertigen Chip sehr, sehr schwierig. Es gibt aber noch eine dritte Möglichkeit, gegen Trojaner vorzugehen, auch präventiv. Und das ist die Verpflichtung. Gibt 2 Möglichkeiten, also einerseits eine auferlegte Verpflichtung. Und was man heute auch durchaus mal sieht, ist, dass Leute die Sicherheits-Chips einsetzen, die die also kaufen oder sich umsehen, wo gibt’s die, dass die sehr, sehr genau schauen, wer stellt die her, was haben die für eine Historie z.B. die Hersteller, wie sind die Besitzverhältnisse, wo ist der Hauptsitz z.B. der Firma, welche Einflussmöglichkeiten gibt es von anderen, von Dritten, auf diese Firmen. Also das kommt immer mehr, man merkt es eigentlich sehr schön. Ja, Gesetze und Richtlinien – zunächst mal zu nennen die Datenschutzgesetze, natürlich. Ganz nett, die Frage natürlich: wer setzt die durch? Und wer überprüft die Einhaltung dieser Gesetze die es schon gibt eigentlich? Und da ist natürlich ein Realitätsabgleich nötig. Z.B. die Frage: Wo gelten die? Also, zu Lande, im Weltraum und ähnliches? Ist ja immer die Frage wie wir wissen. Und dann gibt’s schließlich noch die Selbstverpflichtung, die eigentlich gar nicht so schlecht ist. In diesem Fall ist es so, dass der Hersteller selber sich selbst verpflichten würde, keine Backdoors und keine Trojaner einzusetzen. Jetzt natürlich die Frage: "Wieviel bringt das, wenn er sich nur selber verpflichtet? Was da passiert ist im Prinzip, dass ein künstliches ökonomisches Risiko erzeugt wird. Das heißt, wenn der Hersteller z.B. überführt wird, dass er also trotz dieser Selbstverpflichtung trotzdem so eine Backdoor eingesetzt hat, oder die verwendet, dann hat das für ihn natürlich negative Konsequenzen. Und dieses ökonomische Risiko was dann entsteht, das führt dazu, dass beim Hersteller selbst und in Entwicklungsprozessen mehr darauf geachtet wird, solche Backdoors nicht einzubauen. Bzw. auch nicht unbeabsichtigt einzubauen. D.h. die Tests... könnte man erwarten, dass die Tests z.B. besser werden, dass die Evaluierungsmöglichkeiten besser werden, und dass natürlich auch die Beeinflussungsmöglichkeiten schlechter werden. Dass die Aufklärung besser wird. Also im Prinzip alles prima. Die Frage natürlich: Warum soll sich ein Hersteller so einem ökonomischen Risiko aussetzen, wenn es nicht belohnt wird? Aber auch da ändert sich momentan so ein wenig die Lage. Man sieht schon, dass Hersteller die da vorpreschen, dass die schon eine Vorbildfunktion dann für andere auch darstellen können. Man kann das Ganze mit anderen ethischen Werten koppeln. Aber natürlich, schließlich die Frage: Lohnt es sich für einen Hersteller, wer macht das bisher? Wir hoffen, dass das besser wird. Und dass da mehr Unternehmen sich diesen Sachen dann widmen. So kommen wir auch schon zum Ende unseres Vortrages. Wir haben einige Literatur noch zusammengestellt für euch. Wen es interessiert, also hier z.B. von 1972 die erste Literaturstelle, die erste Fundstelle, wo wirklich von Computer- Trojanern wirklich gesprochen wird und wo so die Konzepte aufgestellt werden. Bis hin zur letzten Fundstelle, gerade jetzt von Dezember, eigentlich eine ganz interessante Arbeit. Kann sich jeder gerne mal durchlesen, wenn er Zeit hat. Ja, damit wie gesagt, möchten wir dann auch schließen. Wir wünschen euch viel Spaß bei der eigenen Forschung. Wenn es Fragen gibt, sind wir noch ein paar Minuten hier. Und ansonsten können wir auch darauf verweisen, wir wären morgen in unserem Assembly. Und wer Lust hat kann gern vorbeikommen, mit uns diskutieren. Vielleicht gibt es ja auch noch interessante Ideen, die wir dann zusammen besprechen können. Also vielen Dank schon mal! Applaus Herald: Vielen Dank! Also, ihr habt gehört, ihr habt jetzt ein paar Minuten Zeit, Fragen zu stellen. Wenn es Fragen gibt, stellt euch bitte an die Mikrofone. Die anderen die jetzt schon den Saal verlassen, tun dies bitte möglichst leise! Gibt’s irgendwelche Fragen? Peter: Ah, da ist einer! Herald: Ah, dort hinten erkenne ich jemanden an Mikrofon 3. Bitte! Frage: Und zwar stellt sich mir die Frage, dass man ja Software gut eigentlich damit absichern kann, indem man beweist, dass sie der Spezifikation genügt. Gibt es da Ansätze für Hardware in den verschiedenen Leveln, also für VHDL, für die Implementierung usw.? Marcus: Es gibt in der Tat, natürlich, den Versuch, zu analysieren, ist da eine unbemerkte Funktionalität eingebaut worden? Da gibt es auch entsprechende Ansätze. Allerdings muss man ganz fairerweise sagen, dass natürlich diese Ansätze es sehr schwer haben, eine Vollständigkeit nachzuweisen. Und wir haben es gerade gesehen, z.B. im Herstellungsprozess stelle ich mir vor, ganz zum Schluss, in der Veränderung des Maskensatzes, so ist dieses nur noch am fertigen Produkt oder an der Maske selber nachweisbar. Infolgedessen ist an sich hier der Rückschluss – ist das die ursprüngliche Funktionalität oder nicht? – kaum noch feststellbar. Also ja, es gibt Ansätze, aber nein, sie sind bei weitem noch nicht voll umfassend. Frage: Danke! Herald: Schhhhhhh! Mikro 4, bitte! Frage: Hallo hallo! Ich hätte die Frage: wie sieht ganz operativ der Aufwand aus für einen – ich nenn’s mal Maulwurfentwickler – der jetzt eine zusätzliche Maske reinbringen will. Wenn ich mir vorstelle, dass die Lagen, die Oxide etc. die man da mittlerweile plant, so dünn sind, dass wenn ich ’ne Zusatzstruktur in bestehende Layer dazwischenschiebe, dass ich dann Shunts produziere etc. und wenn ich was nebenan lege, also abseits des normalen footprints, dann passts beim Dicing nicht mehr, dann fällt das auf, dass da einfach zusätzliche Pfade liegen, wo eigentlich nix hingehört. Peter: hustet Entschuldigung. Ja, also, als Antwort, vielleicht: das Schöne ist, bei der Vermeidung der Trojaner, dass je weiter man in Bereich der Masken geht, dass es umso aufwändiger wird. Hatten wir vorhin auch ansatzweise so dargestellt. Also wenn man gleich in den VHDL-Code das einbringt, so eine Schad„soft“ware, so einen Trojaner, ist es relativ einfach. Nachher wird’s immer schwerer. Und das Interessante ist da, dass man wirklich Technologien vermeiden muss, wo es einfach wird, sozusagen diese Manipulation durchzuführen. Z.B. denken wir mal an diese RAM-Zellen. Da ist es so, der RAM-Zelle ist es eigentlich mehr oder weniger egal, ob der eine Treiber dieser RAM-Zelle etwas stärker ist oder etwas weniger stark. Die funktionieren normalerweise. D.h. wenn man jetzt z.B. diese physical unclonable functions anwendet und aus diesen RAM-Zellen etwas ableitet, z.B. einen Schlüssel, dann wird das nicht auffallen, wenn jemand das manipuliert hat. Wenn es allerdings eine Funktionalität ist, auf die der Chip wirklich angewiesen ist, und die auf gar keinen Fall schieflaufen darf, dann ist das viel schwerer. Und dementsprechend ist es so, dass zunächst mal wichtig ist, alles rauszuwerfen, was sozusagen diesen Backdoors Vorschub leistet. Und, ja, da hattest du völlig recht, also es ist in der Tat schwierig, aber wenn die falschen Technologien verbaut sind, dann wird es ziemlich einfach. Und das ist genau das Problem dabei. Herald: So, die Zeit ist leider knapp. Deshalb die letzte Frage aus dem Internet, bitte. Signal Angel: Die Frage ist: Wurden schon mal wirklich absichtlich eingebrachte Trojaner gefunden? Also nicht im Sinne von Debug-Stelle ausnutzen oder JTAG ausnutzen? Und wurde das auch explizit verwendet? Marcus: Es gibt in der Tat einige Beispiele, wo insbesondere auch Zufallszahlengeneratoren, die in Hardware ausgelegt worden sind, verändert worden sind und damit praktisch die Zufallszahlen nicht mehr wirklich komplett zufällig waren sondern beeinflusst waren. Also – ja, es gibt auch praktische Beispiele, wo Hardware-Trojaner eingesetzt worden sind. Signal Angel: Gibt’s dazu auch einen Namen? Herald: grinst dämlich – Eigentlich keine Dialoge! Deshalb, vielen Dank, ihr könnt nochmal applaudieren! Applaus Abspannmusik Untertitel erstellt von c3subtitles.de im Jahr 2016. Unterstütze uns!