Peter Laackmann, Marcus Janke: Hardware-Trojaner in Security-Chips

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!