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!