*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!*