 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 Markus, forschen seit mehreren Jahren zu Smart Cards und arbeiten komischerweise beide für Infinieren, sind aber beide privat hier. Und heißt ihr herzlich willkommen. Ja, vielen Dank und herzlich willkommen zu unserem Vortrag über Hardware-Trojaner in 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 eigentlich, wo kommen wir her? Und ja, vielen Dank nochmal für die Einführung. In der Tat sind wir seit 1989 aktiv in dem Bereich der Chip-Kartenforschung. Und das Ganze fing an in Brunsbüttel, eine kleine Schleusenstadt, ungefähr 80 Kilometer 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 Chip-Karte. 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. Das war damals noch im Eidelstitter-Bürgerhaus, also viel viel kleiner als das hier. Hat aber auch schon riesen Spaß gemacht, dabei zu sein und auch das Wissen dann mit anderen zu teilen. Ja, neben dem Studium, das war bei Markus 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. Das Ganze auch etwas erweitert im Bereich Datensicherheit und Datenschutz. Und wie schon angekündigt, arbeiten wir momentan auch professionell in dem Bereich. Unter anderem für einen Halbblatt der Hersteller, 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 Service Markt gibt an Equipment, mit dem man dann auch fröhlich forschen kann und schlagrechtiges Equipment zusammenstellen kann. Deshalb kommen wir auch gleich zum eigentlichen Thema, die Hardware-Trojana. Software-Trojana kam in der Einführung schon ganz gut rüber, sind schon lange bekannt. Deshalb wollen wir uns ein bisschen mehr über die Hardware-Trojana jetzt hier, ein bisschen mehr über die Hardware-Trojana berichten. Die waren ziemlich vernachlässigt in der Literatur und auch so in der Öffentlichkeit. Hardware-Trojana, genauso viel Software-Trojana dienen zwei Zwecken. Und zwar einerseits der Exfiltration und andererseits der Infiltration. Exfiltration, der denkt sofort jeder dran. Zum Beispiel, wenn man ein Software-Trojana hat, der möchte Kreditkartendaten irgendwo aus einem System heraus schleusen, herausholen oder auch die berühmten Staats- und Bundes-Trojana, die aus einem geschützten System dann private Daten zum Beispiel heraus exfiltrieren sollen. Das kann aber auch andere Dinge sein, die mit dieser Exfiltration verbunden sind. Zum Beispiel können das kryptografische Schlüssel sein. Wenn man ein System zum Beispiel Nachrichten bereits verschlüsselt hat, man hat jetzt diese verschlüsselten Nachrichten zum Beispiel abgefangen, möchte man eventuell da heran an diesen Schlüssel, der das Ganze verschlüsselt hat, um im Nachhinein sozusagen diese Daten wieder entschlüsseln zu können. Oder noch perfider sind die Startwerte für Pseudo-Zufall-Zahlen-Generaturen. Heute ist es häufig so, dass Zufall-Zahlen nicht nur durch reinen echten physikalischen Zufall erzeugt werden, sondern dass man Startwerte nimmt. Die wirft man in Pseudo-Zufall-Zahlen-Generaturen hinein. Und wenn man die dann kennt und auch den Startwert, dann weiß man, was diese Pseudo-Zufall-Zahlen-Generaturen als nächstes ausspucken werden. Wenn man also den Startwert kennt, weiß man, was als nächstes kommt. Und schließlich kann das Code sein. Also Software, Fernwehr, zum Beispiel im Bereich der Industrie-Spionage, wenn man ein Code herausholen möchte aus einem System, Code-Damp 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 ersten kennt man das noch im Bereich der Software. Also Mileware in ein System einzubringen. Da benutzt man Trojanische Ferdin-Software. Aber das können genauso auch andere Daten sein oder Parameter, zum Beispiel falsche Parameter für Industrie-Steuerungen. Da gibt es ja auch so einige Beispiele dafür. Oder das können zum Beispiel bekannte Werte für Verschlüsselung sein. Wenn ein Verschlüsselungssystem intern eine Verschlüsselung benutzt, die der Angreifer denn 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 des 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 dieses System benutzen oder damit zum Beispiel eine Grenze überqueren möchten und Ähnliches dann durchaus in richtige Schwierigkeiten bringen. Nun gibt es neben den Trojanern auch die Begriffe Backdoor und Backdoor und oft wird das miteinander vermischt. Dementsprechend haben wir hier mal aufgezeichnet, was ist es eigentlich und wie hängt das Ganze zusammen. Man kann sich das eigentlich ganz einfach merken anhand des historischen Vorbildes, das Trojanische Pferd. Das Trojanische Pferd ist eigentlich ein Vehikel, was an den 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. Es wird also in das System integriert, gratis Pferd sozusagen. Und in der Stadt angekommen, schaltet die Nutzlast in den Pferd. Also die Soldaten zunächst mal in 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äre also die richtige Bezeichnung. Aber wie gesagt, wird oft vermischt. Wollen wir auch jetzt nicht so streng sein. Dann gibt es noch eine ganz interessante Wortschaffung, die Backdoor aus Back und Backdoor. Und das ist im Prinzip einfach schlechte Programmierung oder schlampige Programmierung. Zum Beispiel können das Hintertüren sein in einer entsprechenden Software, die einem Entwickler mal erlaubt haben, zum Beispiel Änderungen vorzunehmen, die dann hinterher war, 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, im Fall, 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, so ein Trojaner zu schreiben. Das heißt, das Hindernis, also 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 sie disassemblieren kann und verstehen kann, der wird auch sehen, dass da irgendetwas nicht stimmt. Und wenn er das erst mal gefunden hat, dass da irgendetwas faul ist, dann kann er auch einigermaßen leicht ein Beweis führen, was dieser Trojaner tatsächlich tut. Da gibt es ja auch schon bestimmte Arbeiten dazu, die wirklich nachgewiesen haben, wie solche Trojaner funktionieren und wann sie aktiv werden, 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. Sie 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 bzw. derjenige, der so etwas macht, auch Vorteile hat. Zum Beispiel ist die Identifizierung relativ schwer. Will man eine Hardware Trojaner wirklich finden und will man den identifizieren, muss man üblicherweise so einen Chip Revers engenieren. Muss ich den wirklich ganz genau anschauen. Und selbst wenn man das gemacht hat, ist immer noch die Frage eine bestimmte Hardware Funktionalitä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 aufwendig. Um jetzt herauszufinden, wie aufwendig 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 so Prozesse kennt, dann kann man sich auch ansehen, wo könnte man an diesen Stellen einen Trojaner einsetzen. Wir haben 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 im Prinzip 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 CPU, kann man da drinschreiben. Jeder, der schon mal mit dem FPGA vielleicht was gemacht hat, der kennt das gut. Wenn diese VHDL Sprache, wenn der Code fertig ist, dann wirft man den genau wie Softwarecode in einen Compiler. Und aus diesem Compiler kommt zunächst mal ein Schaltplan heraus. Das sind die einzelnen Funktionalitäten miteinander verbunden, 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 Baulimente drauf. Und es gibt Metallverbindungsleitungen dazwischen. Hier ist das genauso. Die verschiedenen Farben, das 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. Und das ist hier auch gezeigt, anhand eines sogenannten Masken-Satzes. Das sind also Quartsklass-Scheiben. Ich habe hier mal so einen Rohling mitgebracht. Auf diesen Quartsklass-Scheiben wird Chrom abgeschieden, eine ganz dünne Schicht, und mikrostrukturiert. Und das benutzt man dann als optische Maske, um einzelne Schichten auf einen Rosilition-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. Da brauchen wir gar nicht viel drüber zu erzählen. Auf so einem Wafer sind dann die ganzen Chips angeordnet. Und den muss man nur noch auseinandersägen oder auseinanderlasern, um dann die einzelnen Chips zu bekommen. Ist natürlich die Frage, wo ist jetzt hier eigentlich der Trojaner? Das heißt, wir sehen, hier gibt es viel, viel mehr Fertigungsschritte als zum Beispiel, wenn man eine Software implementiert. Folge 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 in jedem der einzelnen Fertigungsstufen ein Trojaner prinzipiell eingebracht werden kann. Das heißt, sowohl im VHDL als auch im Layout oder im Masken-Satz. 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 Zahlen Kot mehr reinzuschreiben und eine zusätzliche Funktionalität, nämlich die Trojaner Funktionalität hier zu integrieren. Das heißt, ein Trojaner kann durch die direkte Implementierung eines VHDL-Kotes in ein großes Projekt direkt mitimplementiert werben und wird dann natürlich in den folgenden Schritten auch ins Layout, in den Masken-Satz und damit in das fertige Produkt übernommen. Man merkt schon, die Implementierung ist an der Stelle relativ einfach, allerdings auch, wenn dieser Kot genau gereviewt wird und man genauer überprüft, was steht eigentlich da drinnen, 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-Kot natürlich noch durch viele Schritte prozessiert werden. Das heißt, viele Leute schauen da nochmal drauf und die Entdeckwahrscheinlichkeit steigt damit. Selbst wenn der VHDL-Kot ohne Trojaner geschrieben worden ist, könnte im Schritt des Layouts noch ein Trojaner eingebracht werden. Wir sehen hier auf dem Beispiel 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 Verbindung verändern. Kann neue Elemente einfügen, kann die elektrischen Verbindung so verändern, dass eine zusätzliche Funktionalität, die Trojaner Funktionalität, implementiert wird. Schon allein daran 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, dieses ist nichts mehr, was man schnell nebenbei irgendwo in ein Kot reinschreibt, sondern tatsächlich viele Stunden Arbeit. Dafür wehrschaut 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 muss wirklich jede einzelne Leitung dann wieder verfolgen, wo geht sie hin, ist das die gewünschte Funktionalität. Na ja, und so wie man aus dem Layout den Masken-Satz macht, kann man natürlich auch im Masken-Satz selber auch ein Trojaner einbringen. Das heißt also, die Strukturen, die auf der Maske vorgezeichnet sind und dann später in dem Schip realisiert werden sollen, kann man natürlich auch auf der Maske verändern. Jetzt kann man schweredings einfach die Belichtungsmaske hernehmen und damit im Skalpell oder sowas kratzen. Das ist einfach viel, viel zu grob. Stattdessen muss man dann natürlich tatsächlich einen neuen Masken-Satz oder zumindest das neue Masken, die man geändert hat, erzeugen und dafür braucht man natürlich schon hochpräzise Spezial-Equipment. Folge dessen ist die Implementierung nochmal komplizierter als beim Layout. Man muss nicht nur die Leitung und 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 genauso eine Maske verifizieren, dass sie keine veränderten Funktionalitäten enthält. Man müsste dann wieder einen Vergleich zum Layout und hoffen, dass 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 sich es 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 Snake Oil Features, die stark begünstigen können, dass man Trojaner einbringen kann und auf der anderen Seite sogar sehr stark erschweren kann, dass man Trojaner dediktieren kann. Snake Oil Features, klar, dass Schlangenöl, das angepriesen wird, wie ein Wunderheilmittel tolle Wirkung haben soll, aber vielleicht auch tatsächlich die Wirkung nicht ganz so entfaltet oder auch viel schlimmer, sogar eine Nebenwirkung, eine gefährliche Nebenwirkung ausbregen kann. Und genau das kann hier auch passieren. Etwas, was man vielleicht mit dem guten Gefühl eingebaut hat in dem 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 eine 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, den man vielleicht nicht so direkt analysieren kann oder den man nicht direkt ansehen kann, was steckt da eigentlich drinnen? In diesem komplexen Quellcode ist es natürlich auch viel, viel leichter, andere Funktionalitäten mit reinzubringen, die man zunächst einmal gar nicht vermutet. Die Detektion dadurch, dass er 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? Na ja, wir kennen ja aus der Softwarewelt die sogenannte Whitebox-Kryptografie. Die Whitebox-Kryptografie nutzt ja gerade möglichst komplexe Softwarecodes, um da drinnen kryptografische Schlüsse zu verstecken. Das heißt, um ein kryptografisches Schlüssel in einer Software möglichst gut gegen Ausspielen zu verstecken, wird halt das Thema Whitebox-Kryptografie angepriesen. Die Codes hier drinnen 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 VDL-Code, der hier abgebildet ist, plötzlich eine viel komplexere Struktur einbaut, wie wir 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 einsplösen. Selbst wenn es nicht am vorderen Teil der Herstellungskette eingeschleust wird, können Trojaner begünstigen, dass man zu einem späten Prozessschritt, können Snake Oil Features begünstigen, dass man zu einem späten Prozessschritt entsprechend noch Veränderungen vornimmt. Stellen wir uns vor, ein Snake Oil Feature ist im VDL-Code integriert worden, mit dem guten Gefühl, ja, das ist jetzt das Wundermittel, das hilft uns, das macht den Ship jetzt so viel sicherer. Aber erlaubt vielleicht, bei dem Masken-Satz mit einer einfachen zusätzlichen Maske eine Manipulation vorzunehmen und damit tatsächlich die Ships 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 unclone functions, die eine hohe Gefahr bergen, dass sie manipuliert werden können. Bei den physical unclone functions wird ja bei den SRAM physical unclone functions, der interne Arbeitsspeicher verwendet, der beim Einschalten die Zellen eher, einige zellen eher nach Null kippen lassen, andere zellen eher die Vorzugsrichtung nach 1 haben. Das ist Baustein individuell und hängt von ganz kleinen Herstellungstoleranzen ab. Damit hat man also einen Baustein individuellen Wert, der hier erzeugt wird. Insbesondere wenn bei jedem Einschalten wieder das gleiche Muster entsteht, kann man hier raus natürlich versuchen, zum Beispiel kryptografische Schlüssel aus abzuleiten. Eben die Funktionalität eines physical unclone functions. Dieses Einschaltverhalten ist aber natürlich insbesondere durch eine einfache zusätzliche Maske im Herstellungsprozess leicht manipulierbar. Ich kann einfach die Rammzellen durch eine Maske in eine Vorzugslage bringen, dass eben gewisse Zellen, die ich kenne, als Einbringer dieser Maske, eher nach Null kippen oder andere eher nach 1 kippen. Was passiert ist, dass ich die Veränderung in diesem Ship kennen würde. Jemand anders, der den Ship aber beobachtet, zunächst einmal nicht weiß, ist das jetzt ein Baustein individueller 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 Ship Designs. Hier handelt es sich nicht um eine einfache Speicherzelle, sondern um ein universelles Logikelement. Dieses Logikelement wird zunächst einmal im Schaltplan platziert und kann zu einem späteren Zeitpunkt im Herstschungsprozess festgelegt werden, ob es jetzt zum Beispiel eine Und- oder eine Oderverknü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 ein 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 vom Vorteil wäre. Also man sieht schon, dass neben den normalen Arten, wie man ein Trojaner in ein Ship einbringen kann, auch viele Möglichkeiten bestehen, wie zum Beispiel über solche Snake Oil 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 können sowohl über Protokolle erfolgen, das kann über Seitenkanal-Information erfolgen, die aber im Gegensatz zu Seitenkanal-Angriffen hier gezielt Informationen ausgeben, das kann über Ship-Manipulation, das heißt also tatsächlich über physikalisches Beeinflussen des Ships 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 darauf eingehen. Hier haben wir 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 Softwaretroyalern kennt, ist natürlich, dass undokumentierte Befehle oder Befehlsequenzen 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 auch aus der Welt der Softwaretroyana, 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 Audio-Files übertragen werden, als Kennung, wo kommt diese Datei eigentlich her. Aber was passiert eigentlich, wenn ein Ship eine größere Menge Daten ausgeben muss und hier einfach ein Watermarking sozusagen stenikonographisch Zusatzinformation in dem Output versteckt. Wer nicht das Verfahren kennt, wie man diese Daten daraus extrahiert, wird sich sehr schwer tun, festzustellen, ist das eigentlich jetzt die normale Datei, die normale Informationen, die rauskommen oder sind da vielleicht ein paar einzelne Bits eben verändert, über die dann Informationen aus dem Ship heraus extrahiert werden. Und genau dieses Wissen ist besonders auch, was bei Seitenkanal-Bectors 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 irgendwie aus, als ob es einfach von der Funktionalität geschuldet ist. Aber jemand, der speziell diese Bector 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, wie viel Strom verbraucht worden ist oder wie viel abgestrahlt worden ist. Also ein Verfahren, was auch relativ schwer zu detektieren ist, um zu sehen, ist da jetzt eigentlich wirklich 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 1.000 bis 10.000 Mal, entsteht als Nebenprodukt auch ein Photon, ein impferotes Lichtteilchen. Und dieses kann man natürlich messen oder zum Beispiel mit speziellen Kameras aufnehmen. Damit kann man sehen, wo es zum Beispiel Aktivität im Schiff, da sind viele Transistoren, die schalten. Aber wenn man eine entsprechende Bector einbaut, könnte man natürlich auch ein Element 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 morse sozusagen wie mit einer Taschenlampe dieser Transistor dann die Information halt entsprechend raus. Genauso messen kann man auch das Potenzial natürlich auf Signalleitungen. Sicherlich habt ihr bei unserem Vortrag 25 Jahre Schiffkartenangriffe, auch gesehen, wie man mittels Elektronenraster-Mikroskop die Potenziale auf elektrischen Leitungen messen kann. Wenn ich jetzt den gesamten Schiff beobachte, dann sehe ich natürlich eine Vielzahl von Potenzialen auf den einzelnen Leitungen. Aber jemand, der gezielt diese Bector 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 Schiff heraus in das System, in das Analyse-System vornehmen. Ja, und wie vielfältig das Ganze ist, sieht man sogar, 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 dass die Bearbeitung auf dem anderen Core in diesem System beeinflusst. Ja, vielmehr 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 Informationen ü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-Spectors. Wer kennt es nicht, dass auf einem Schiff, wenn man sich dem mal genauer anschaut, vielleicht nicht nur die angeschlossenen Kontaktfelder sind, sondern vielleicht noch zusätzliche Kontaktfelder, wo im Datenblatt ganz lapidar NC, Not Collected, dran steht, oder RFU, vor Future News. 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 Schiff entsprechend kommunizieren kann. Und genauso, wie man das auf den Kontaktfeldern beobachten kann, ist es natürlich auch denkbar, dass man bei der Implementierung eines Trojaners eine vorbestimmte Signalleitung auf dem Schiff implementiert und wird diese zum Beispiel mittels eines Leserstrahls durchgeschnitten, einem normaler Lasercutter, der auch auf dem gebrauchten Markt preiswert zu haben ist, dann kann man entsprechend die Zusatzfunktionalität in diesem Schiff vielleicht freischalten und dann plötzlich erst nach dieser Manipulation, nach dieser physikalischen Manipulation mit dem Schiff kommunizieren. Und selbst Speicherzellen, wie zum Beispiel das RAM, hatten wir eben ja schon gesehen beim Physical Antlone-Befunctions bei den sogenannten unplanierbaren Funktionen, kann man mittels, zum Beispiel Ionenimplantation auch verändern und damit andere Daten vorgeben oder die Funktion der Schaltung verändern. Lass man oder ließ, der Bereich der Fehlerinduxtkuren kann auch noch genutzt werden, um mit der durch die Backdoor zu kommunizieren und dem Trojaner entsprechend Informationen mitzuteilen. Zum Beispiel könnte man spezielle Elemente mit einem Leserstrahl anleuchten. Und klar, der Schiff ist aus Elitium, das ist am Ende nichts anderes als auch eine Solarzelle vielleicht auf dem Dach, das heißt der Leserstrahl induziert dann eine kleine Fotospannung oder ein Fotostrom und kann dadurch dann natürlich eine Schaltfunktionität auslösen, die man von außen so gar nicht direkt steuern kann, wenn man nicht genau weiß, wo ich mit dem Laser drauf blitzen muss. Was bekannter ist, ist auch, dass häufig Speicher mit Schutzmechanismen ausgestattet werden. Wer kennt es nicht, nachdem man ein Programm in ein Mikro-Kontroller 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 raufleuchten muss, um diesen Schreibschutz halt zu deaktivieren und dann doch wieder ein Zugriff auf den Speicher zu bekommen. Es gibt es teilweise, dass das tatsächlich als Backdoor, wie Peter ja auch schon erklärt hat, 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, zum Beispiel mit der UV-Strahlung und habe dann den Zugriff. Eine sehr spannende, aber auch kniffligere Sache ist das Thema der Zufall-Zahlen-Generatoren. Die Zufall-Zahlen-Generatoren werden ja viel genutzt, um kriptografische Funktionen abzusichern. Der Zufall, eben eine nichtvorhersagbare Funktion innerhalb dieses Ships auszunutzen, um zum Beispiel Daten zu randomisieren oder aber Abläufe zufällig zu gestalten. Das Ganze wird aber natürlich ad absurdum geführt, wenn man diese Zufall-Zahlen von außen beeinflussen kann oder aber sogar deren Werte vorgeben kann. Und genau auch das ist mit Fehlerinduktion denkbar, dass man zum Beispiel von außen ein elektromagnetisches Feld, also im Prinzip eine Radiofrequenz, vorgibt und damit die internen Zufall-Zahlen in einer Weise beeinflusst, dass man direkt Daten einprägen kann oder aber zumindest aufsynchronisieren kann, dass man nicht mehr unvorhersagbare, sondern plötzlich vorhersagbare Zufallszahlen generiert. Eine Geschichte, nur wer genau diese Frequenz kennt, wie er es einkoppeln kann, kann diese Bector dann nutzen, um zum Beispiel die Zufallsprozesse innerhalb des Ships außer Gefecht zu setzen. Naja, und wenn wir um Sicherheits-Ships sprechen, dann wissen wir ja auch, dass sehr häufig zum Beispiel Sensoren eingebaut werden. Sensoren, um Angriffe zu vermeiden, sei es zum Beispiel Spannungssensoren, sei es Sensoren gegen Lichtbestrahlung, sei es Sensoren, die detektieren sollen, welche Temperatur hat dieser Ship jetzt gerade und so weiter. 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, vielleicht genau bei diesem Parametersatz ist der Sensor blind sozusagen und er kann diesen Parametersatz nutzen, um gezielt eine Fehlerinduktion in den Programmablauf oder in den verrechneten Daten einzufügen und damit dann entsprechend auch wieder mit dem Trojaner zu kommunizieren. Also man sieht schon, es gibt rund um das Thema Bector sehr, sehr viele verschiedene Möglichkeiten in der Hardware, weit aus 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 Analyse-Schnittstellen aus, denn die Analyse-Schnittstellen sind ja meistens ein Feature, was sogar mit einer guten Intention eingebaut worden ist. Zum Beispiel bei den Festplatten, wie man hier im oberen Bild sieht, wo ein Debugport 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 Debugport 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 J-Tech-Ports, die Analyse-Schnittstelle, die sich in vielen Geräten wiederfindet und teilweise sehr mangelhaft abgesichert ist. Denn hier haben wir ein Beispiel jetzt von einem WLAN-Router, wo man über den J-Tech-Port auch neue Firmware, zum Beispiel mit Trojanern, in die WLAN-Router einbringen kann. Denken wir das jetzt noch einmal weiter, was passiert, wenn jetzt eigentlich ein Sicherheitschip mit solch einem Analyse-Port ausgestattet ist? Nun, da kann man natürlich sagen, wenn dieser Schip mal ausfällt, dann kann ich versuchen, darüber dann tatsächlich nochmal den zu reparieren oder zumindest an die Daten wieder ranzukommen, sie zu restaurieren. Ja, aber genau das ist ja das, was man nicht möchte. Ein Sicherheitschip soll doch bitte die Daten auch wirklich geheim in sich halten und nicht dann über ein Analyse-Port vielleicht doch wieder zugänglich machen. Und deshalb sind insbesondere auf Sicherheitschips 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, zumindest es dem Anschein, nach vertrauenswürdige Personen, sollte ich jetzt besser die Tür öffnen oder lieber besser geschlossen lassen. Genauso wie diese gute Funktionalität in dem Türspion drinnen ist, kann sie aber auch missbräuchlich genutzt werden. Wenn ich zum Beispiel, wie im vierten Bild zu sehen, eine Umkehroptik von draußen aufsetze, dann sehe ich nicht mehr nur den kleinen Lichtpunkt hinter der Tür, wo das ganze Bild zusammengezehrt ist, sondern aufgrund dieser Umkehroptik 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 unser Erachtens nach ein schönes Beispiel, wie tatsächlich auch ein gut gemeintes Feature eventuell dann eben als Bektor missbrauch wird. 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. Dementsprechend haben wir uns zu der Zeit auch schon mal überlegt, was kann man eigentlich machen, profilaktisch, um so was zu verhindern, um das Risiko zu minimieren und überhaupt Technik so zu bauen, dass sie Trojaner und Bektor resistent ist, jedenfalls 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? Es bringt eigentlich die Leute dazu, um das zu bauen, das jetzt willendlich ist oder unwillendlich. Das zeigen wir hier in diesen vier 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 könnte das sabotage Grunde sein, zum Beispiel Erpressung, könnte eine Rolle spielen, ein bestimmtes System ist schon im Feld und ein Hersteller zum Beispiel, dass man mit einem bestimmten Kommando einer Bektor 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 Bektors ein oder bringt Trojaner ins Spiel. Auf der anderen Seite des Spektrums, ganz interessant, der gute Wille. Auch das geschieht dann aus Vorsatz und der Fokus hatte da schon einige Beispiele mal gezeigt. Das können Dinge sein, wie zum Beispiel Service-Schnittstellen, es 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 sowas zu reparieren oder die Daten wieder rauszuholen. Passt natürlich nicht zu Sicherheitschips. Und dann schließlich auch da gibt es politische Motive, da ist es dann nicht der fiese Diktator unserer Wahl, weil 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 das mal 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. Das heißt, jemand weiß eigentlich, was er da gerade macht in einer bestimmten Entwicklung oder Konzeptionierungsphase, dass das eigentlich falsch ist. Es könnte zum Beispiel Gründe dahinter stehen, wie Zeitdruck. Eine Analyse-Schnittstelle zum Beispiel soll für ein fertiges Produkt noch ausgebaut werden. Ich muss man das machen, um den Chip dann sicher zu bekommen. Es wird aber aus Zeitdruck nicht gemacht. Dazu kann zum Beispiel auch noch Verdrängung kommen, dass man dann sich sagt, ja, es war nicht so schlimm, das wird schon keiner finden. Es wird eben auch das Hierarchien eine wesentliche Rolle spielen, dass jemanden gesagt wird, mach das mal so, bau das mal so ein. Und es nicht hinterfragt wird, warum das eigentlich notwendig ist, wofür man das eigentlich braucht und ob man das hinterher wieder ausbauen soll oder drinnen lassen soll. Ja, und dann schließlich das Thema Dummheit. Haben wir hier auch explizit mal so genannt, so plakativ. Einerseits Bildungsmangel oder Überforderung kann da 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, so was zu machen. Wie das Einzelne ineinander spielt, also welches Zahnrad und 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 Markus 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 drei Kategorien ausgedacht. Die Aufklärung Technologie, technologische Gegenmaßnahmen und die Verpflichtung kann von extern oder auch selbst passieren. Und hier an diesen 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ösenwillen auf der anderen Seite nützt Aufklärung wenig, vielleicht sogar am Gegenteil. Wenn man sagt, das wäre also wirklich das Tod des Unternehmens, wenn da so eine Backdoor eingebaut wäre, die so und so aussieht, dann kann es natürlich sein, dass der Savorteur genau das dann einbringt. Klar. Aber wie gesagt, die Aufklärung sehen wir jetzt ganz, ganz wichtig an. Bei der Technologie, den technologischen Gegenmaßnahmen, da ist es so, dass einerseits man sagen muss, vom Motiv des Angreifers eigentlich unabhängig technologische Gegenmaßnahmen erschweren den Einbau von Backdoors und Trojanern generell. Trotzdem haben wir das Ganze etwas eingekärbt, auf der rechten und auf der linken Seite. Und es hat auch seinen Grund, weil diese beiden Bereiche mit Vorsatz verbunden sind. Und das könnte heißen, dass jemand zum Beispiel so etwas vorhat, dass er dann sich auch schlau macht. 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 selbst Verpflichtung sein, oder auch externe Verpflichtung, können wir gleich noch darauf zu sprechen auf diese drei Bereiche. Und auch da ist es so, dass das sehr unterschiedlich wirksam ist beim Bösenwellen natürlich am wenigsten, aber bei den anderen Motiven schon etwas mehr. Aber wie versprochen, etwas mehr über diese Möglichkeiten, kann also jeder tun, der in einem dieser Bereiche Entwicklung, Konzeption oder auch Test arbeitet, um Backdoors zu verhindern oder die zu erkennen. In einerseits, hier nochmal die Punkte der Aufklärung. Das kann technischer Aufklärung sein, das steht natürlich im Vordergrund. Security bei Obscurity darf nicht das Ziel sein, also Kerckhoff sollte man schon berücksichtigen, wenn man irgendetwas baut. Die Backschnittstellen passen nicht zu Sicherheitschips, das ist ganz wichtig, obwohl es immer wieder nachgefragt wird, kann man nicht für eigene Entwicklung, für eigene Fehleranalyse z.B. 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. Das heißt, die sind eher konstruktiv, manchmal konstruktivistisch unterwegs. Und das bedeutet, dass man oft seinen eigenen Resultaten unter dem, was man da zusammengebaut hat, dann sehr hoch vertraut. Ein Angriff z.B. oder ein Sicherheitsfinitrationstest dann eher als Angriff auf die eigene Person sieht. Jeder, der im IT-Sicherheitsbusiness tätig ist, erkennt das auch, dass man da erstmal so eine konstruktive Atmosphäre schaffen muss, indem man zusammen das Produkt dann besser macht. Politischer Aspekt ist natürlich auch ein wichtiges Thema. Hier der Frankenstein-Effekt sozusagen zu nennen, wenn man so ein Trojaner tatsächlich irgendwo in der Praxis hat, dann ist er unkontrollierbar. Das heißt, man weiß nicht, was damit passiert, wer den benutzt schließlich. Er kann sich natürlich auch gegen seinen eigenen Urheber rechnen. Und gleichzeitig ist es auch so, braucht man bloß ins Geschichtbuch 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 auch relativ hoch, dass eines davon in den nächsten Monaten oder Jahren einmal umkippen könnte. Und dementsprechend werden wir auch darauf natürlich zu achten. Das Ganze verbunden auch mit den ethischen Aspekten, für uns auch wichtig, denn Bektos können Personen in tödliche Gefahr bringen. Es ist also kein Spiel und kein Spielzeug, sondern gerade wenn man z.B. an das Thema Kompromat denkt und jemand mit Top-Secret-Material, was ihm da aufgeschleust wurde, sozusagen angeschleust wurde, an einer Grenze festgehalten wird, dann ist das schon durchaus unangenehm. Er sagt immer, the road to hell is paved with good intentions, gilt eigentlich für alles, was da steht, oder auf Deutsch frei nach diesem Motto, gut gemeint ist, nicht gut gemacht. Ja, es gibt einige technologische Gegenmaßnahmen gegen Trojanos und Bektos, also rein prophylaktisch, was auch sehr, sehr wirksam ist. Dazu gehört zunächst mal, Fördernden-Technologien einzusetzen. Die gehören raus und wenn man merkt, dass eine Technologie Beckdorf fördernd ist, oder sowas begünstigt, dann sollte man die in Sicherheitschips nicht verwenden. Darüber hinaus gibt es ein paar Möglichkeiten, dass man das Design so anlegt, dass Änderungen auffallen. Das heißt, jemand anders, der auch an dem Design arbeitet, eher merkt, dass etwas nicht stimmt, oder das im Test oder in der Evaluierung dann auffällt, dass etwas nicht stimmt, sondern die Änderungen, die durchzuführen, sind größer sind, als das, was man bei schlangenölhaltiger Technologie machen muss. Der Rest ist im Prinzip ähnlich wie beim Thema der technologischen Aufklärung. Aber wir haben hier auch gleichzeitig noch zwei andere Möglichkeiten aufgeführt. Das sind die Selbsttests von Chips und die Erkennung, nachdem ein Chip fertig ist. Aber da muss man ein bisschen vorsichtig sein. Bei den Selbsttests ist es noch so, dass ein Chip bevor eine wirklich kritische Operation macht, also zum Beispiel eine Nachricht verschlüsseln, dass er vorher eine Testoperation durchführt und schaut, ob es okay ist, ob die Schlüssel nicht manipuliert sind, ob die Zufallzahlen in Ordnung sind usw. Dann gibt es eine ganze Menge dieser Selbsttests. Wenn die alle vernünftig durchgelaufen sind, dann macht ein Chip die eigentliche Operation. Aber es kann natürlich sein, dass ein Insider sich Gedanken macht und überlegt, was könnte da alles eingebaut sein, dass es mir das Leben schwer macht und dementsprechend auch diese Test 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. Es gibt einige Resultate, einige Arbeitsgruppen, die sich mit dem Thema Erkennung auseinandersetzen und sagen, man könnte doch bei einem fertigen Chip, schauen, ob dann ein 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 ein Backdoor so angelegt werden, dass sie nicht ständig aktiv ist. Und außerdem ist es so bei Sicherheitschips, bei Sicherheitssoftwaren, auch bei Sicherheitshardware, 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. Es gibt zwei Möglichkeiten, also einerseits eine auffälligte Verpflichtung. Und was man heute doch durchaus mal sieht, ist, dass Leute, die Sicherheitschips einsetzen, die die also kaufen oder sich umsehen, wo gibt es 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. 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. Zum Beispiel die Frage, wo gelten die, also zu Lande, im Weltraum und Ähnliches. Das ist ja immer die Frage, wie wir wissen. Und dann schließe ich 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 Trojane einzusetzen. Jetzt ist natürlich die Frage, wie viel 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 zum Beispiel ü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 in den Entwicklungsprozessen mehr darauf geachtet wird, solche Backdoors nicht einzubauen bzw. auch nicht unbeabsichtigt einzubauen. Das heißt, die Tests, könnte man erwarten, dass die Tests zum Beispiel besser werden, dass die Evaluierungsmöglichkeiten besser werden und das natürlich auch die Einflussmö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 das 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ßt sich die Frage, lohnt es sich für einen Hersteller, wer macht das bisher? Wir hoffen, dass es 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 ist interessiert? Also hier zum Beispiel von 1972 die erste Literaturstelle, so die erste Fundstelle, wo wirklich von Computer-Trojanern gesprochen wird und wo sie die Konzepte aufgestellt werden. Bis hin zur letzten Fundstelle, gerade jetzt vom Dezember, eigentlich eine ganz interessante Arbeit, kann sich jeder gerne mal durchlesen, wenn er Zeit hat. 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 werden morgen in unserem Assembly und weil Lust hat, kann gerne vorbeikommen mit uns diskutieren. Vielleicht gibt es ja auch noch interessante Ideen, die wir dann zusammengesprochen können. Also vielen Dank schon mal. 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 es irgendwelche Fragen? Ah, das andere. Ah, dort hinten erkenne ich jemanden an Mikrofon 3, bitte. 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 und so weiter? Es gibt in der Tat natürlich, der 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 ja schwer haben, eine Vollständigkeit nachzuweisen. Und wir haben es gerade gesehen, zum Beispiel im Herstellungsprozess, stell ich mir vor, ganz zum Schluss in der Veränderung des Mastensatzes, so ist dieses nur noch am fertigen Produkt oder an der Maske selber nachweisbar. Folge dessen 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 vollumfassend. Dankeschön. Mikrofon 4, bitte. Hallo, hallo. Ich hatte die Frage, wie sieht ganz operativ der Aufwand aus für einen, ich nenne es mal Maulwurfentwickler, der jetzt eine zusätzliche Maske reinbringen will. Ich mir vorstelle, dass die Lagen, die Oxide, etc., die man da mittlerweile plant, so dünn sind, dass wenn ich eine Zusatzstruktur in bestehende Layer dazwischenschiebe, dass ich dann Chance produziere, etc., und wenn ich was nebenan lege, also absetzt das normalen Footprints, dann passt es beim Dicing nicht mehr, dass da einfach zusätzliche Fade liegen, wo eigentlich nichts hingehört. Entschuldigung. Ja, also als Antwort, vielleicht das Schöne ist bei der Vermeidung der Trojaner, dass je weiter man im Bereich der Masken geht, dass es umso aufwendiger wird. Das hat mir vorhin auch ansatzweise so dargestellt, also wenn man gleich in den VHDLQ das einbringt, seine Schadsoftware, seine Trojaner, ist es relativ einfach. Daher wird es immer schwerer. Wenn man wirklich Technologien vermeiden muss, wo es einfach wird, sozusagen diese Manipulation durchzuführen. Zum Beispiel denken wir mal an diese Rammzellen. Der Rammzell ist es eigentlich mehr oder weniger egal, ob der eine Treiber dieser Rammzelle etwas stärker ist oder etwas weniger stark. Die funktionieren normalerweise. Das heißt, wenn man jetzt zum Beispiel diese Physical Enclonable Functions anwendet und aus diesen Rammzellen etwas ableitet, zum Beispiel ein 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. Dementsprechend ist es so, dass zunächst mal wichtig ist, alles rauszuwerfen, was sozusagen diesen Backdoors-Vorschub leistet. Da ist es 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. So, die Zeit ist leider knapp. Deshalb die letzte Frage aus dem Internet, bitte. Die Frage ist, wurden schon mal wirklich absichtlich eingebrachte Trojaner gefunden. Also nicht im Sinne von Debug-Steller ausnutzen oder J-Tech ausnutzen und wurde das auch effizit verwendet. Es gibt in der Tat einige Beispiele, wo insbesondere auch Zuverzahlen-Generatoren, die in Hardware ausgelegt worden sind, verändert worden sind und damit praktisch die Zuverzahlen nicht mehr wirklich komplett zufällig waren, sondern beeinflusst waren. Also ja, es gibt auch praktische Beispiele, wo Hardware-Trojaner eingesetzt worden sind. Gibt es jetzt auch einen Namen? Eigentlich keine Dialoge. Deshalb vielen Dank. Ihr könnt noch mal applaudieren.