WEBVTT
00:00:00.000 --> 00:00:09.959
Vorspannmusik
00:00:09.959 --> 00:00:13.859
Herald: Heute geht es um
„Hardware-Trojaner in Security-Chips“.
00:00:13.859 --> 00:00:18.720
Also nicht um Software-
Trojaner, die die Polizei einsetzen will.
00:00:18.720 --> 00:00:22.550
Die beiden Herren neben
mir, Peter und Marcus,
00:00:22.550 --> 00:00:27.210
forschen seit mehreren Jahren
zu Smartcards und arbeiten
00:00:27.210 --> 00:00:32.600
komischerweise beide für Infineon,
sind aber beide privat hier, und…
00:00:32.600 --> 00:00:35.110
heißt sie herzlich willkommen!
00:00:35.110 --> 00:00:43.720
Applaus
00:00:43.720 --> 00:00:46.469
Peter: Ja vielen Dank und herzlich
willkommen zu unserem Vortrag über
00:00:46.469 --> 00:00:51.309
„Hardware-Trojaner and Security-Chips“.
Wie versprochen reisen wir gleich auf die
00:00:51.309 --> 00:00:56.600
dunklere Seite der Chip-Technologien, aber
bevor wir das machen, ganz kurz zu unserer
00:00:56.600 --> 00:00:59.830
Person: was machen wir, wo kommen wir
her? Und, ja, vielen Dank noch mal für die
00:00:59.830 --> 00:01:05.960
Einführung; In der Tat sind wir seit 1989
aktiv im Bereich der Chipkarten-Forschung;
00:01:05.960 --> 00:01:09.860
und das Ganze fing an in Brunsbüttel,
eine kleine Schleusenstadt, ungefähr
00:01:09.860 --> 00:01:15.600
80 km nordwestlich von hier, mit der
Forschung an der deutschen Telefonkarte.
00:01:15.600 --> 00:01:19.850
Die war damals ganz neu und wir wollten
natürlich unbedingt wissen: Was verbirgt
00:01:19.850 --> 00:01:23.770
sich hinter diesen kleinen Goldkontakten
in der Chipkarte, wie funktioniert der
00:01:23.770 --> 00:01:29.160
Chip und vor allem wie werden da die
Gebühren drauf gespeichert? Ungefähr
00:01:29.160 --> 00:01:33.930
1991, also zwei Jahre später haben wir
auch das erste Mal für den CCC-Kongress
00:01:33.930 --> 00:01:38.430
einen Vortrag gehalten. Es war damals
noch im Eidelstädter Bürgerhaus – also
00:01:38.430 --> 00:01:42.341
viel, viel kleiner als das hier – hat aber
auch schon Riesenspaß gemacht, dabei
00:01:42.341 --> 00:01:48.500
zu sein und auch das Wissen mit anderen zu
teilen. Ja, neben dem Studium – das war
00:01:48.500 --> 00:01:51.730
bei Marcus in Hamburg und bei mir in Kiel
– haben wir uns weiter mit dem Thema
00:01:51.730 --> 00:01:56.520
auseinandergesetzt und auch so die
eine oder andere Sicherheitsschwäche
00:01:56.520 --> 00:02:00.010
aufgedeckt und das Ganze auch etwas
erweitert im Bereiche ‚Datensicherheit und
00:02:00.010 --> 00:02:05.880
Datenschutz‘. Und wie schon angekündigt
arbeiten wir momentan auch professionell
00:02:05.880 --> 00:02:13.140
in dem Bereich, unter anderem für einen
Halbleiterhersteller, bei dem wir eine
00:02:13.140 --> 00:02:15.990
kleine Expertengruppe dann
damals aufgebaut haben.
00:02:15.990 --> 00:02:19.890
Aber interessant für uns ist: die private
Forschung läuft weiter und wir schauen
00:02:19.890 --> 00:02:24.080
uns zum Beispiel momentan an, was
es so auf dem Surplus-Markt gibt an
00:02:24.080 --> 00:02:28.970
Equipment, mit dem man dann fröhlich
forschen kann und schlagkräftiges
00:02:28.970 --> 00:02:34.920
Equipment zusammenstellen kann. Deshalb,
kommen wir auch gleich zum eigentlichen
00:02:34.920 --> 00:02:39.430
Thema: Die Hardware-Trojaner.
Software-Trojaner, kam in der Einführung
00:02:39.430 --> 00:02:46.319
schon ganz gut rüber, sind schon lange
bekannt, deshalb wollen wir hier ein
00:02:46.319 --> 00:02:50.450
bisschen mehr über die Hardware-Trojaner
berichten. Die werden ziemlich
00:02:50.450 --> 00:02:54.520
vernachlässigt – in der Literatur
und auch in der Öffentlichkeit.
00:02:54.520 --> 00:02:58.319
Hardware-Trojaner genauso wie
Software-Trojaner dienen zwei Zwecken und
00:02:58.319 --> 00:03:02.980
zwar einerseits der Exfiltration und
andererseits der Infiltration.
00:03:02.980 --> 00:03:06.809
Exfiltration – da denkt sofort jeder
dran. Zum Beispiel, wenn man einen
00:03:06.809 --> 00:03:09.840
Software-Trojaner hat, der möchte
Kreditkartendaten irgendwo aus einem
00:03:09.840 --> 00:03:13.770
System herausschleusen/herausholen,
oder auch die berühmten Staats- und
00:03:13.770 --> 00:03:17.940
Bundestrojaner die aus einem geschützten
System dann private Daten zum Beispiel
00:03:17.940 --> 00:03:22.730
heraus-exfiltrieren sollen. Das können
aber auch anderen Dinge sein, die mit
00:03:22.730 --> 00:03:26.430
dieser Exfiltration verbunden sind, zum
Beispiel können das kryptografische
00:03:26.430 --> 00:03:30.260
Schlüssel sein. Wenn ein System
z.B. Nachrichten bereits
00:03:30.260 --> 00:03:33.020
verschlüsselt hat – man hat jetzt diese
verschlüsselten Nachrichten zum Beispiel
00:03:33.020 --> 00:03:38.610
abgefangen – dann möchte man eventuell
heran an diesen Schlüssel, der das Ganze
00:03:38.610 --> 00:03:42.640
verschlüsselt hat, um im Nachhinein diese
Daten wieder entschlüsseln zu können.
00:03:42.640 --> 00:03:48.470
Oder: noch perfider sind die Startwerte
für Pseudo-Zufallszahlen-Generatoren.
00:03:48.470 --> 00:03:53.630
Heute ist es häufig so, dass
Zufallszahlen nicht NUR durch reinen,
00:03:53.630 --> 00:03:58.300
echten, physikalischen Zufall erzeugt
werden, sondern dass man Startwerte nimmt,
00:03:58.300 --> 00:04:01.260
die wirft man in
Pseudo-Zufallszahlen-Generatoren hinein
00:04:01.260 --> 00:04:04.930
und wenn man die dann kennt – und auch
den Startwert – dann weiß man, was
00:04:04.930 --> 00:04:08.870
diese Pseudo-Zufallszahlen-Generatoren als
nächstes ausspucken werden. Wenn man also
00:04:08.870 --> 00:04:13.530
den Startwert kennt, weiß man, was als
nächstes kommt. Und schließlich kann es
00:04:13.530 --> 00:04:19.200
Code sein, also Software, Firmware, zum
Beispiel im Bereich der Industriespionage,
00:04:19.200 --> 00:04:24.200
wenn man Code herausholen möchte aus
einem System, Code Dump tun möchte. Was
00:04:24.200 --> 00:04:28.770
immer so ein bisschen vernachlässigt wird
ist die Infiltration – was ja eigentlich
00:04:28.770 --> 00:04:32.780
ein Trojaner macht, der infiltriert ja ein
System. Am ehesten kennt man das noch im
00:04:32.780 --> 00:04:38.060
Bereich der Software – also Malware in
ein System einzubringen; dafür benutzt
00:04:38.060 --> 00:04:43.480
man trojanische Pferde in Software, aber
das können genauso auch andere Daten
00:04:43.480 --> 00:04:48.620
sein, oder Parameter, z.B. falsche
Parameter für Industriesteuerungen, da
00:04:48.620 --> 00:04:51.990
gibt es ja auch so einige Beispiele
dafür. Oder das können zum Beispiel
00:04:51.990 --> 00:04:56.610
bekannte Werte für Verschlüsselungen
sein, wenn ein Verschlüsselungssystem
00:04:56.610 --> 00:05:00.380
intern eine Verschlüsselung benutzt, die
der Angreifer dann hinterher brechen kann,
00:05:00.380 --> 00:05:04.610
dann ist das für ihn natürlich auch
interessant. Und schließlich – das
00:05:04.610 --> 00:05:08.100
sollte man auch nicht vergessen, deshalb
kommen wir nachher auch noch zu den
00:05:08.100 --> 00:05:12.389
ethischen Themen und den moralischen
Aspekten: das „Kompromat“, also
00:05:12.389 --> 00:05:17.560
kompromittierendes Material, denn mit
Hilfe eines Trojaners oder einer Backdoor
00:05:17.560 --> 00:05:22.100
kann man natürlich auch belastendes
Material in ein System hineinbringen und
00:05:22.100 --> 00:05:25.419
das kann Leute, die das System benutzen
oder damit zum Beispiel eine Grenze
00:05:25.419 --> 00:05:29.530
überqueren möchten und ähnliches, dann
durchaus in richtige Schwierigkeiten
00:05:29.530 --> 00:05:36.820
bringen. Dann gibt’s neben den Trojanern
auch die Begriffe Bugdoor und Backdoor und
00:05:36.820 --> 00:05:40.510
oft wird das miteinander vermischt;
dementsprechend haben wir hier mal
00:05:40.510 --> 00:05:45.050
aufgezeichnet: was ist das eigentlich und
wie hängt das ganze zusammen? Man kann
00:05:45.050 --> 00:05:50.820
sich das eigentlich ganz einfach merken
anhand des historischen Vorbildes: Das
00:05:50.820 --> 00:05:56.430
trojanische Pferd ist eigentlich ja ein
Vehikel, das eine Nutzlast trägt – wird
00:05:56.430 --> 00:06:00.949
aufgemacht, kommen die Soldaten rein, das
trojanische Pferd wird von der Stadt, also
00:06:00.949 --> 00:06:05.510
vom System durch die User, hereingeholt
– heute würde man sagen: „Oh toll,
00:06:05.510 --> 00:06:10.520
eine gratis App! Muss ich haben!“.
Wird also in das System integriert,
00:06:10.520 --> 00:06:17.061
„Gratispferd“ sozusagen. Und… in der
Stadt angekommen, schaltet die Nutzlast in
00:06:17.061 --> 00:06:20.790
dem Pferd, also die Soldaten, zunächst
einmal die Sicherheitsfeatures aus (die
00:06:20.790 --> 00:06:25.349
Wachen) und öffnen dann die Tür für den
Rest der Armee. Und das ist genau die
00:06:25.349 --> 00:06:31.010
Backdoor. Das heißt der Trojaner, oder
das trojanische Pferd, bewegt und steuert
00:06:31.010 --> 00:06:34.550
im Prinzip die Backdoor. Das wär also die
richtige Bezeichnung, aber wie gesagt:
00:06:34.550 --> 00:06:39.140
wird oft vermischt, wollen wir auch jetzt
nicht so streng sein. Dann gibt’s noch
00:06:39.140 --> 00:06:43.590
eine ganz interessante Wortschöpfung –
die „Bugdoor“, aus „Bug“ und
00:06:43.590 --> 00:06:46.760
„Backdoor“. Und das ist im Prinzip
einfach schlechte Programmierung oder
00:06:46.760 --> 00:06:52.640
schlampige Programmierung. Z.B.
können das Hintertüren sein in einer
00:06:52.640 --> 00:06:57.389
entsprechenden Software, die einem
Entwickler mal erlaubt haben, z.B.
00:06:57.389 --> 00:07:01.189
Änderungen vorzunehmen, die dann
hinterher aber nicht ausgebaut wurden. Und
00:07:01.189 --> 00:07:06.450
davon gibt es in der Tat eine ganze Menge.
Jetzt ist natürlich die Frage: wo können
00:07:06.450 --> 00:07:13.040
sich solche Trojaner oder Backdoors
eigentlich verstecken? Wo kommen sie her?
00:07:13.040 --> 00:07:16.889
Das wichtige hierbei ist, dass die
Trojaner immer im System selber wirken,
00:07:16.889 --> 00:07:21.880
also das System ist der Wirkungsort der
Trojaner – egal wo sie jetzt herkommen.
00:07:21.880 --> 00:07:26.320
Sie können auch ihre Plätze tauschen –
auch ganz interessant. Und das System
00:07:26.320 --> 00:07:30.660
besteht immer – jedenfalls die Systeme
über die wir hier so sprechen – besteht
00:07:30.660 --> 00:07:36.060
immer aus Software und Hardware. In der
Software ist die Programmierung eines
00:07:36.060 --> 00:07:41.090
Trojaners eigentlich relativ einfach;
jeder, der sich einigermaßen auskennt mit
00:07:41.090 --> 00:07:45.210
Programmierung, wird in der Lage sein,
wenn er lange genug dran arbeitet, einen
00:07:45.210 --> 00:07:51.030
Trojaner zu schreiben. Das heißt, das
Hindernis, so etwas einzubauen ist relativ
00:07:51.030 --> 00:07:56.330
einfach oder relativ niedrig. Aber
es gibt auch einen Nachteil dieser
00:07:56.330 --> 00:07:59.920
Software-Trojaner natürlich, denn die
sind auch relativ leicht zu entdecken. Das
00:07:59.920 --> 00:08:02.980
heißt, jeder, der an die Software
herankommt, der die also disassemblieren
00:08:02.980 --> 00:08:07.550
kann und verstehen kann, der wird auch
sehen, dass da etwas nicht stimmt. Und
00:08:07.550 --> 00:08:12.120
wenn er das erstmal gefunden hat, dass da
irgendetwas faul ist, dann kann er auch
00:08:12.120 --> 00:08:17.650
einigermaßen leicht einen Beweis führen,
was dieser Trojaner eigentlich tut. Da
00:08:17.650 --> 00:08:21.790
gibt’s ja auch schon bestimmte Arbeiten
dazu, die wirklich dann nachgewiesen
00:08:21.790 --> 00:08:25.060
haben, wie solche Trojaner funktionieren
und wann sie aktiv werden und was sie
00:08:25.060 --> 00:08:28.830
alles können. Anders ist das bei
den Hardware-Trojanern: bei den
00:08:28.830 --> 00:08:31.249
Hardware-Trojanern wird nicht die Software
geändert, sondern es wird die Hardware
00:08:31.249 --> 00:08:37.250
selber geändert und zwar in dem Sinne,
dass ein Chip zum Beispiel verändert
00:08:37.250 --> 00:08:41.489
wird, dass die Funktionalität
tatsächlich in der Hardware anders ist.
00:08:41.489 --> 00:08:44.919
Und da kann man sich vorstellen, dass der
Aufwand – das werden wir gleich noch
00:08:44.919 --> 00:08:49.300
sehen, wie hoch der Aufwand tatsächlich
ist – dass der Aufwand recht hoch ist,
00:08:49.300 --> 00:08:52.320
dass das Ganze teuer ist, dass es
vielleicht auch nicht so einfach zu
00:08:52.320 --> 00:08:57.040
verbergen ist gegenüber anderen Leuten,
zum Beispiel in der Entwicklung solcher
00:08:57.040 --> 00:09:01.290
Geräte. Aber auf der anderen Seite
ist es so, dass der Angreifer, oder
00:09:01.290 --> 00:09:04.970
beziehungsweise derjenige der so etwas
macht, auch Vorteile hat. Z.B. ist die
00:09:04.970 --> 00:09:09.410
Identifizierung relativ schwer. Will man
einen Hardware-Trojaner wirklich finden
00:09:09.410 --> 00:09:13.480
und will man den identifizieren, muss
man üblicherweise so einen Chip
00:09:13.480 --> 00:09:17.030
reverse-engineeren – sich den wirklich ganz
genau anschauen. Und selbst wenn man
00:09:17.030 --> 00:09:21.980
das gemacht hat, ist immer noch die Frage:
eine bestimmte Hardwarefunktionalität,
00:09:21.980 --> 00:09:26.519
die man dann gefunden hat – Was tut sie
wirklich? Ist sie wirklich noch aktiv?
00:09:26.519 --> 00:09:30.480
Oder ist es vielleicht eine schlafende
Funktionalität, die nie verwendet wird?
00:09:30.480 --> 00:09:37.390
Wie dem auch sei – der Beweis ist
aufwändig. Um jetzt herauszufinden, wie
00:09:37.390 --> 00:09:42.540
aufwändig tatsächlich der Einbau eines
Hardware-Trojaners ist, ist es natürlich
00:09:42.540 --> 00:09:46.100
zunächst mal interessant, sich
anzuschauen: Wie baut man so einen Chip?
00:09:46.100 --> 00:09:48.910
Und wenn man das weiß und wenn man diese
Prozesse kennt, dann kann man sich auch
00:09:48.910 --> 00:09:53.520
ansehen: Wo könnte man an diesen Stellen
einen Trojaner einsetzen? Und hier einfach
00:09:53.520 --> 00:09:59.520
mal ganz kurz gezeigt: Wie baut man einen
Chip? Wie wird so etwas hergestellt? Links
00:09:59.520 --> 00:10:03.190
fängt das Ganze an, mit der
Hardware-Beschreibungssprache, das ist
00:10:03.190 --> 00:10:07.840
hier in diesem Fall VHDL zum Beispiel.
VHDL ist so etwas wie eine
00:10:07.840 --> 00:10:11.930
Programmiersprache für Software, bloß
dass man ‚Hardware direkt schreibt‘.
00:10:11.930 --> 00:10:15.990
Und dieser Code enthält im Prinzip
dann die Funktionalität – was soll die
00:10:15.990 --> 00:10:20.670
Hardware tun: Logische Funktionen, ganze
CPUen kann man da drin schreiben. Jeder
00:10:20.670 --> 00:10:24.800
der schon mal mit ‘nem FPGA vielleicht
was gemacht hat, der kennt das gut. Wenn
00:10:24.800 --> 00:10:29.320
diese VHDL-Sprache, wenn der Code fertig
ist, dann wirft man den, genau wie
00:10:29.320 --> 00:10:33.220
Software-Code in einen Compiler und aus
diesem Compiler kommt zunächst mal ein
00:10:33.220 --> 00:10:37.990
Schaltplan heraus. Da sind die einzelnen
Funktionalitäten miteinander verbunden,
00:10:37.990 --> 00:10:41.629
im Prinzip so, wie bei normalen
Schaltplänen auch. Und aus diesem
00:10:41.629 --> 00:10:45.350
Schaltplan kann man dann – das ist das
zweite Bild – ein Layout erstellen. Das
00:10:45.350 --> 00:10:50.390
Layout zeigt, wo auf dem Chip die
verschiedenen Funktionselemente liegen und
00:10:50.390 --> 00:10:53.760
wie die miteinander verbunden sind. Kann
man sich so ungefähr vorstellen wie eine
00:10:53.760 --> 00:10:56.899
Platine – da sind auch die verschiedenen
Bauelemente drauf und es gibt
00:10:56.899 --> 00:11:00.580
Metallverbindungsleitungen dazwischen;
hier ist das genauso: die verschiedenen
00:11:00.580 --> 00:11:03.150
Farben sind auch
Metallverbindungsleitungen bloß auf
00:11:03.150 --> 00:11:07.330
verschiedenen Ebenen. Wenn man daraus
jetzt tatsächlich einen Chip machen
00:11:07.330 --> 00:11:13.080
möchte, dann muss man das Ganze auf ein
optisches System übertragen. Das ist hier
00:11:13.080 --> 00:11:17.640
aufgezeigt anhand eines sogenannten
„Maskensatzes“. Das sind also
00:11:17.640 --> 00:11:24.500
Quarzglasscheiben; ich habe hier mal so
einen Rohling mitgebracht. Auf diesen
00:11:24.500 --> 00:11:28.370
Quarzglasscheiben wird Chrom abgeschieden
– eine ganz dünne Schicht – und
00:11:28.370 --> 00:11:35.031
mikrostrukturiert. Und das benutzt man
dann als optische Maske, um einzelne
00:11:35.031 --> 00:11:39.390
Schichten auf einen Rohsilizium-Wafer
nacheinander aufzubringen. Davon braucht
00:11:39.390 --> 00:11:43.410
man so einige Dutzend von diesen Masken.
Und wenn man die dann nacheinander
00:11:43.410 --> 00:11:47.380
prozessiert hat, dann hat man schließlich
den Wafer – ich denke mal das kennt
00:11:47.380 --> 00:11:49.990
jeder – brauchen wir gar nicht viel
drüber zu erzählen. Auf so ‘nem Wafer
00:11:49.990 --> 00:11:53.820
sind dann die ganzen Chips angeordnet und
den muss man nur noch auseinander sägen
00:11:53.820 --> 00:11:58.240
oder auseinander lasern um dann
die einzelnen Chips zu bekommen.
00:11:58.240 --> 00:12:01.980
Marcus: Nun ist da natürlich die Frage:
Wo ist jetzt hier eigentlich der Trojaner?
00:12:01.980 --> 00:12:05.860
Das heißt, wir sehen: hier gibt’s viel,
viel mehr Fertigungsschritte als zum
00:12:05.860 --> 00:12:09.220
Beispiel wenn man eine Software
implementiert. Infolge dessen gibt es
00:12:09.220 --> 00:12:11.810
natürlich auch viel, viel mehr
Möglichkeiten, wo man einen Trojaner
00:12:11.810 --> 00:12:16.040
implementieren kann. Und in der Tat ist
es so, dass es in jeder der einzelnen
00:12:16.040 --> 00:12:20.380
Fertigungsstufen ein Trojaner prinzipiell
eingebracht werden kann, das heißt sowohl
00:12:20.380 --> 00:12:25.930
im VHDL als auch im Layout oder im
Maskensatz. Gehen wir schrittweise vor:
00:12:25.930 --> 00:12:31.459
Was kann man im VHDL machen? Nun, Peter
hatte ja schon gesagt: im VHDL ist die
00:12:31.459 --> 00:12:36.890
Funktionalität genau beschrieben. Was hindert
mich daran, ein paar Zeilen Code mehr
00:12:36.890 --> 00:12:40.479
reinzuschreiben und eine zusätzliche
Funktionalität, nämlich die
00:12:40.479 --> 00:12:45.810
Trojanerfunktionalität, hier zu
integrieren? Das heißt, ein Trojaner kann
00:12:45.810 --> 00:12:51.510
durch die direkte Implementierung eines
VHDL-Codes in ein großes Projekt direkt
00:12:51.510 --> 00:12:55.430
mit implementiert werden und wird dann
natürlich in den folgenden Schritten auch
00:12:55.430 --> 00:13:00.589
ins Layout, in den Maskensatz und damit in
das fertige Produkt mit übernommen. Man
00:13:00.589 --> 00:13:05.030
merkt schon: die Implementierung ist an
der Stelle relativ einfach. Allerdings
00:13:05.030 --> 00:13:09.170
auch wenn dieser Code genau gereviewt
wird und man genauer überprüft „Was
00:13:09.170 --> 00:13:12.930
steht eigentlich da drin? Was sind die
einzelnen Funktionalitäten, die im VHDL
00:13:12.930 --> 00:13:16.279
beschrieben sind?“, ist auch die
Entdeckwahrscheinlichkeit normalerweise
00:13:16.279 --> 00:13:20.590
recht einfach. Hinzu kommt dann noch, dass
dieser VHDL-Code natürlich noch durch
00:13:20.590 --> 00:13:25.040
viele Schritte prozessiert wird, das
heißt viele Leute schauen da noch mal
00:13:25.040 --> 00:13:31.500
drauf und die Entdeckwahrscheinlichkeit
steigt damit. Selbst wenn der VHDL-Code
00:13:31.500 --> 00:13:36.790
ohne Trojaner geschrieben worden ist,
könnte im Schritt des Layoutes noch ein
00:13:36.790 --> 00:13:41.520
Trojaner eingebracht werden. Wir sehen
hier auf dem Beispiel ja die verschiedenen
00:13:41.520 --> 00:13:45.560
elektrischen Verbindungen, wie Peter schon
gesagt hat, in den verschiedenen Farben.
00:13:45.560 --> 00:13:50.019
Und mit einem speziellen Layout-Programm,
vergleichbar praktisch mit einem
00:13:50.019 --> 00:13:53.210
Bildbearbeitungsprogramm, kann man
natürlich auch diese Verbindungen
00:13:53.210 --> 00:13:57.730
verändern, kann neue Elemente einfügen,
kann die elektrischen Verbindungen so
00:13:57.730 --> 00:14:00.740
verändern, dass eine zusätzliche
Funktionalität – die
00:14:00.740 --> 00:14:05.520
Trojaner-Funktionalität – implementiert
wird. Schon allein da dran merkt man
00:14:05.520 --> 00:14:08.459
allerdings, dass der Aufwand
natürlich deutlich höher wird. Eine
00:14:08.459 --> 00:14:12.220
Vielzahl von Elementen und eine Vielzahl
von Leitungen müssen verändert werden
00:14:12.220 --> 00:14:16.430
und das heißt, dies ist nichts mehr, was
man schnell nebenbei in einen Code
00:14:16.430 --> 00:14:21.730
reinschreibt, sondern tatsächlich viele
Stunden Arbeit. Dafür: Wer schaut sich
00:14:21.730 --> 00:14:27.059
das Layout schon genau an? Das heißt also
auch, die Entdeckung ist an dieser Stelle
00:14:27.059 --> 00:14:31.130
normalerweise zumindest mal schwerer
als beim VHDL. Man müsste wirklich jede
00:14:31.130 --> 00:14:35.120
einzelne Leitung dann wieder verfolgen,
wo geht sie hin, ist das die gewünschte
00:14:35.120 --> 00:14:40.880
Funktionalität. Naja, und so, wie man aus
dem Layout den Maskensatz macht, kann man
00:14:40.880 --> 00:14:45.250
natürlich auch im Maskensatz selber auch
einen Trojaner einbringen. Das heißt
00:14:45.250 --> 00:14:49.690
also: die Strukturen, die auf der Maske
vorgezeichnet sind und dann später in dem
00:14:49.690 --> 00:14:53.960
Chip realisiert werden sollen, kann man
natürlich auch auf der Maske verändern.
00:14:53.960 --> 00:14:59.210
Jetzt kann man schwererdings einfach die
Belichtungsmaske hernehmen und da mit
00:14:59.210 --> 00:15:03.290
‘nem Skalpell oder sowas kratzen
– das ist einfach viel, viel zu grob.
00:15:03.290 --> 00:15:07.089
Stattdessen muss man dann natürlich
tatsächlich einen neuen Maskensatz oder
00:15:07.089 --> 00:15:11.110
zumindest neue Masken, die man geändert
hat, erzeugen und dafür braucht man
00:15:11.110 --> 00:15:15.320
natürlich schon hochpräzises
Spezialequipment. Infolgedessen ist die
00:15:15.320 --> 00:15:19.050
Implementierung nochmal komplizierter
als beim Layout; man muss nicht nur die
00:15:19.050 --> 00:15:22.250
Leitungen und die Elemente verändern,
sondern auch noch die Gerätschaften
00:15:22.250 --> 00:15:26.180
dafür haben. Die Entdeckung auf
der anderen Seite ist dafür dann
00:15:26.180 --> 00:15:31.680
normalerweise natürlich nochmal eine
ganze Stufe schwerer, denn: Wie soll man
00:15:31.680 --> 00:15:36.839
genau so eine Maske verifizieren, dass
sie keine veränderten Funktionalitäten
00:15:36.839 --> 00:15:40.339
enthält? Man müsste dann wieder einen
Vergleich zum Layout (machen) – und
00:15:40.339 --> 00:15:43.700
hoffen, dass das sich das Layout nicht
verändert hat in der Zwischenzeit durch
00:15:43.700 --> 00:15:48.399
jemanden, der den Trojaner einbringen
möchte… Also man merkt: die Entdeckung
00:15:48.399 --> 00:15:53.480
wird hier schon sehr kompliziert. Das
waren jetzt Möglichkeiten, wie man
00:15:53.480 --> 00:15:57.610
Trojaner – so wie man es sich jetzt
direkt denkt – einfach implementieren
00:15:57.610 --> 00:16:02.260
kann. Aber: ihr seht auch hier haben wir
schon angegeben, dass die Entdeckung
00:16:02.260 --> 00:16:07.620
normalerweise einfach, mittelschwer oder
schwer ist. Warum „normalerweise“?
00:16:07.620 --> 00:16:12.970
Denn es gibt – wir nennen es
„Snakeoil-Features“, die stark
00:16:12.970 --> 00:16:17.010
begünstigen können, dass man Trojaner
einbringen kann und auf der anderen Seite
00:16:17.010 --> 00:16:22.499
sogar sehr stark erschweren können,
dass man Trojaner detektieren kann.
00:16:22.499 --> 00:16:27.829
Snakeoil-Features, klar, das Schlangenöl,
das angepriesen wird wie ein
00:16:27.829 --> 00:16:33.160
Wunderheilmittel, tolle Wirkung haben
soll, aber vielleicht auch tatsächlich
00:16:33.160 --> 00:16:36.292
die Wirkung nicht ganz so entfaltet – oder
sogar noch viel schlimmer: sogar noch
00:16:36.292 --> 00:16:40.730
eine Nebenwirkung, eine gefährliche
Nebenwirkung ausprägen kann. Und genau
00:16:40.730 --> 00:16:45.180
das kann hier auch passieren: etwas, was
man vielleicht mit dem guten Gefühl
00:16:45.180 --> 00:16:50.920
eingebaut hat in den VHDL-Code, um eine
Funktionalität, um ein Security-Feature
00:16:50.920 --> 00:16:55.120
zu realisieren, dass sich dann natürlich
im Layout, im Maskensatz und letztlich im
00:16:55.120 --> 00:17:01.500
Produkt auch wiederfindet. Aber:
vielleicht ermöglichen solche Features
00:17:01.500 --> 00:17:07.199
auch ‘ne ganz leichte Modifikation in
dem Herstellungsprozess. Schauen wir uns
00:17:07.199 --> 00:17:11.860
an, wie das zum Beispiel am Anfang der
Prozesskette ausschauen kann. Stellen wir
00:17:11.860 --> 00:17:18.010
uns vor, dass der VHDL-Code nicht einfach
geschrieben ist, sondern komplexer ist –
00:17:18.010 --> 00:17:26.440
ein VHDL-Code, direkt ansehen kann:
Was steckt da eigentlich drin? In diesem
00:17:26.440 --> 00:17:30.360
komplexen Quellcode ist es natürlich
auch viel, viel leichter, andere
00:17:30.360 --> 00:17:33.520
Funktionalitäten mit reinzubringen, die
man zunächst einmal vielleicht gar nicht
00:17:33.520 --> 00:17:38.099
vermutet. Die Detektion, dadurch dass er
ja komplexer ist, ist automatisch auch
00:17:38.099 --> 00:17:41.449
schwerer. Man muss diese ganzen komplexen
Funktionen dann natürlich genau
00:17:41.449 --> 00:17:46.289
nachvollziehen; was passiert da
eigentlich? Ist das nur Theorie?
00:17:46.289 --> 00:17:51.310
Naja, wir kennen ja aus der Software-Welt die
sogenannte „White-Box-Kryptografie“.
00:17:51.310 --> 00:17:56.830
Die White-Box-Kryptografie nutzt ja gerade
möglichst komplexe Software-Codes, um da
00:17:56.830 --> 00:18:01.519
drin kryptografische Schlüssel zu
verstecken. Das heißt: um einen
00:18:01.519 --> 00:18:06.130
kryptografischen Schlüssel in einer
Software möglichst gut gegen Ausspähen
00:18:06.130 --> 00:18:12.439
zu verstecken, wird halt das Thema
White-Box-Kryptografie angepriesen. Die
00:18:12.439 --> 00:18:15.559
Codes hier drin sind so komplex, dass
man sie an sich kaum noch wirklich
00:18:15.559 --> 00:18:20.729
durchschauen kann. Übertragen wir das auf
die Hardware: Was bedeutet, wenn man statt
00:18:20.729 --> 00:18:24.929
dem VHDL-Code, der hier abgebildet ist,
plötzlich eine viel komplexere Struktur
00:18:24.929 --> 00:18:29.680
einbaut, wie wir hier symbolhaft in dem
roten Kasten abgebildet haben. Diese
00:18:29.680 --> 00:18:32.789
komplexen Funktionen genau zu
durchleuchten – was steckt da eigentlich
00:18:32.789 --> 00:18:37.309
alles hinter? – ist natürlich ungleich
schwerer, und somit kann man relativ
00:18:37.309 --> 00:18:43.109
einfach dann auch schwer erkennbare
Trojaner einschleusen. Selbst, wenn es
00:18:43.109 --> 00:18:48.059
nicht am vorderen Teil der
Herstellungskette eingeschleust wird,
00:18:48.059 --> 00:18:57.509
können (…) Snakeoil-Features
begünstigen, das man zu einem späteren
00:18:57.509 --> 00:19:01.169
Prozessschritt entsprechend noch
Veränderungen vornimmt. Stellen wir uns
00:19:01.169 --> 00:19:06.990
vor, ein Snakeoil-Feature ist im VHDL-Code
integriert worden mit dem guten Gefühl
00:19:06.990 --> 00:19:11.390
„Ja, das ist jetzt das Wundermittel. Das
hilft uns. Das macht den Chip jetzt so
00:19:11.390 --> 00:19:18.010
viel sicherer.“ Aber erlaubt vielleicht
bei dem Maskensatz mit einer einfachen
00:19:18.010 --> 00:19:23.410
zusätzlichen Maske eine Manipulation
vorzunehmen und damit tatsächlich die
00:19:23.410 --> 00:19:26.950
Chips in einer Art und Weise zu
verändern, dass man sie leicht
00:19:26.950 --> 00:19:33.439
kontrollieren kann. Wie könnte sowas
aussehen? Ein praktisches Beispiel dafür
00:19:33.439 --> 00:19:38.179
sind die sogenannten „physical
unclonable functions“, die eine hohe
00:19:38.179 --> 00:19:43.000
Gefahr bergen, dass sie manipuliert werden
können. Bei den physical unclonable
00:19:43.000 --> 00:19:48.480
functions wird ja bei den S-RAM physical
unclonable functions der interne
00:19:48.480 --> 00:19:53.269
Arbeitsspeicher verwendet, der
beim Einschalten die Zellen eher…
00:19:53.269 --> 00:19:57.799
einige Zellen eher nach 0 kippen lassen,
andere Zellen eher die Vorzugsrichtung
00:19:57.799 --> 00:20:01.689
nach 1 haben. Das ist bausteinindividuell
und hängt von ganz kleinen
00:20:01.689 --> 00:20:07.350
Herstellungstoleranzen ab. Damit hat man
also einen bausteinindividuellen Wert, der
00:20:07.350 --> 00:20:10.960
hier erzeugt wird; insbesondere, wenn bei
jedem Einschalten wieder das gleiche
00:20:10.960 --> 00:20:14.679
Muster entsteht, kann man hieraus
natürlich versuchen, zum Beispiel
00:20:14.679 --> 00:20:21.359
kryptografische Schlüssel abzuleiten,
eben die Funktionalität einer „physical
00:20:21.359 --> 00:20:25.910
unclonable function“. Dieses
Einschaltverhalten ist aber natürlich
00:20:25.910 --> 00:20:30.090
insbesondere durch eine einfache
zusätzliche Maske im Herstellungsprozess
00:20:30.090 --> 00:20:36.120
leicht manipulierbar: Ich kann einfach
die RAM-Zellen durch eine Maske in eine
00:20:36.120 --> 00:20:40.720
Vorzugslage bringen, dass eben gewisse
Zellen, die ich kenne als Einbringer
00:20:40.720 --> 00:20:46.519
dieser Maske, eher nach 0 kippen, oder
andere eher nach 1 kippen. Was passiert
00:20:46.519 --> 00:20:52.149
ist, dass ich die Veränderung in diesem
Chip kennen würde, jemand anderes, der
00:20:52.149 --> 00:20:56.320
den Chip aber beobachtet, zunächst
einmal nicht weiß: Ist das jetzt ein
00:20:56.320 --> 00:21:00.830
bausteinindividueller zufälliger Wert,
oder ist das ein Wert, der verändert
00:21:00.830 --> 00:21:06.460
worden ist? Und genau das zeigt ja schon,
wie kompliziert es ist, solche Trojaner
00:21:06.460 --> 00:21:12.249
dann zu identifizieren. Eine ähnliche
Methode ist auch denkbar bei den
00:21:12.249 --> 00:21:16.859
sogenannten „Camouflage Chip Designs“
– hier handelt es sich nicht um eine
00:21:16.859 --> 00:21:22.140
einfache Speicherzelle, sondern um ein
universelles Logik-Element. Dieses
00:21:22.140 --> 00:21:25.840
Logik-Element wird zunächst einmal im
Schaltplan platziert und kann zu einem
00:21:25.840 --> 00:21:30.989
späteren Zeitpunkt im Herstellungsprozess
festgelegt werden, ob es jetzt zum
00:21:30.989 --> 00:21:33.609
Beispiel eine UND- oder eine
ODER-Verknüpfung oder eine andere
00:21:33.609 --> 00:21:38.859
logische Verknüpfung darstellen soll.
Genauso, wie die Programmierung in diesem
00:21:38.859 --> 00:21:43.770
letzten Schritt durch die Maske erfolgt,
kann ich natürlich auch, wenn ich einen
00:21:43.770 --> 00:21:48.499
Trojaner einbringen möchte, hier eine
spezielle Maske einschmuggeln und damit
00:21:48.499 --> 00:21:52.950
dann entsprechend die Funktionalität
so verändern, wie sie für mich als
00:21:52.950 --> 00:21:59.330
Hardware-Trojaner-Anwender dann von
Vorteil wäre. Also man sieht schon, dass
00:21:59.330 --> 00:22:03.849
neben den normalen Arten, wie man einen
Trojaner in einen Chip einbringen kann
00:22:03.849 --> 00:22:07.629
auch viele Möglichkeiten bestehen,
die zum Beispiel über solche
00:22:07.629 --> 00:22:12.160
Snakeoil-Features dann deutlich
begünstigt werden und die sehr schwer
00:22:12.160 --> 00:22:16.869
teilweise zu detektieren sind. Und
selbst wenn man sagt: „Moment, der
00:22:16.869 --> 00:22:21.219
Hardware-Trojaner muss ja irgendwann mit
der Außenwelt kommunizieren. Kann man das
00:22:21.219 --> 00:22:25.259
dann nicht einfach detektieren?“, so
sehen wir, dass es auch sehr, sehr viele
00:22:25.259 --> 00:22:29.720
verschiedenartige Backdoors gibt, die als
Mittel zur versteckten Kommunikation
00:22:29.720 --> 00:22:35.299
genutzt werden können. Das kann sowohl
über Protokolle erfolgen, das kann über
00:22:35.299 --> 00:22:40.269
Seitenkanal-Informationen erfolgen – die
aber im Gegensatz zu Seitenkanal-Angriffen
00:22:40.269 --> 00:22:45.970
hier gezielt Informationen ausgeben –
das kann über Chip-Manipulation, das
00:22:45.970 --> 00:22:49.399
heißt also tatsächlich über
physikalisches Beeinflussen des Chips oder
00:22:49.399 --> 00:22:54.629
sogar über Fehlerinduktion erfolgen.
Und diese Vielfältigkeit, die man hier hat
00:22:54.629 --> 00:22:59.019
für diese Backdoors finden wir sehr
spannend und deshalb möchten wir auch auf
00:22:59.019 --> 00:23:03.939
einige dieser Fälle jetzt genauer drauf
eingehen. Hier haben wir für uns aber
00:23:03.939 --> 00:23:07.710
insbesondere eine Auswahl getroffen, wie
man auch unten an den Beispielquellen
00:23:07.710 --> 00:23:11.909
sieht, die auch publiziert sind; denn wir
möchten jetzt natürlich nicht noch
00:23:11.909 --> 00:23:15.530
Dienste auf irgendwelche neuen,
interessanten Ideen bringen, sondern wir
00:23:15.530 --> 00:23:20.129
möchten eher aufklären und zeigen, was
für Möglichkeiten gibt es überhaupt,
00:23:20.129 --> 00:23:25.220
wie Protokolle missbraucht werden können
um Daten zu übertragen. Und das
00:23:25.220 --> 00:23:29.570
bekannteste natürlich, was man
auch von Software-Trojanern kennt,
00:23:29.570 --> 00:23:33.339
ist natürlich, dass undokumentierte
Befehle oder Befehlssequenzen akzeptiert
00:23:33.339 --> 00:23:37.929
werden, oder auch ein Generalschlüssel
integriert wird, mithilfe dessen man dann
00:23:37.929 --> 00:23:44.169
unbemerkten Zugang auf die internen Daten
oder auf den Code haben kann. Eine andere
00:23:44.169 --> 00:23:48.769
Methode, ebenfalls aus der Welt der
Software-Trojaner relativ gut bekannt,
00:23:48.769 --> 00:23:53.519
sind geschwächte Krypto-Algorithmen.
Derjenige, der den Trojaner einbringt, der
00:23:53.519 --> 00:23:58.179
kennt halt: welche Funktionalität hat er
hier als Backdoor gewählt und wie kann er
00:23:58.179 --> 00:24:03.230
den kryptografischen Algorithmus relativ
leicht angreifen. Das heißt, er kann dann
00:24:03.230 --> 00:24:08.190
die kryptografischen Geheimnisse
extrahieren und damit dann an die internen
00:24:08.190 --> 00:24:13.340
Daten rankommen. Ein Szenario, was aber
auf den Protokollen bisher noch nicht so
00:24:13.340 --> 00:24:17.830
groß diskutiert worden ist, ist das Thema
„Watermarking“. Klar, Watermarking
00:24:17.830 --> 00:24:22.519
kennen wir zum Beispiel aus dem Bereich,
wo Videos, Bilder oder Audiofiles
00:24:22.519 --> 00:24:29.289
übertragen werden, als Kennung „Wo
kommt diese Datei eigentlich her?“. Aber
00:24:29.289 --> 00:24:34.539
was passiert eigentlich, wenn ein Chip
eine größere Menge Daten ausgeben muss
00:24:34.539 --> 00:24:38.869
und hier einfach ein Watermarking
sozusagen steganografisch
00:24:38.869 --> 00:24:44.210
Zusatzinformationen in dem Output
versteckt? Wer nicht das Verfahren kennt,
00:24:44.210 --> 00:24:48.410
wie man diese Daten daraus extrahiert,
wird sich sehr schwertun, festzustellen:
00:24:48.410 --> 00:24:52.049
Ist das eigentlich jetzt die normale
Datei, die normale Information, die
00:24:52.049 --> 00:24:56.809
rauskommt, oder sind da vielleicht ein
paar einzelne Bits eben verändert über
00:24:56.809 --> 00:25:02.030
die dann Informationen aus dem Chip
herausextrahiert werden? Und genau dieses
00:25:02.030 --> 00:25:07.519
Wissen ist besonders auch, was bei
Seitenkanal-Backdoors schwer ist, diese zu
00:25:07.519 --> 00:25:12.109
detektieren. Beobachte ich das
Stromprofil, oder zum Beispiel die
00:25:12.109 --> 00:25:17.799
elektromagnetische Abstrahlung, so kann
ich relativ einfach detektieren: Ja, das
00:25:17.799 --> 00:25:22.779
schaut alles zufällig aus. Oder: Das
schaut alles irgendwie aus, als ob es
00:25:22.779 --> 00:25:28.199
einfach der Funktionalität geschuldet
ist. Aber jemand der speziell diese
00:25:28.199 --> 00:25:32.259
Backdoor eingebracht hat, weiß
vielleicht, dass er genau zu gewissen
00:25:32.259 --> 00:25:37.200
Zeitpunkten den Stromverlauf oder die
elektromagnetische Abstrahlung sich
00:25:37.200 --> 00:25:41.950
anschauen muss, und kriegt damit dann die
einzelnen Informationen übertragen über
00:25:41.950 --> 00:25:46.669
eben zum Beispiel die Amplitude, wieviel
Strom verbraucht worden ist, oder wieviel
00:25:46.669 --> 00:25:50.609
abgestrahlt worden ist. Also ein
Verfahren, was auch relativ schwer zu
00:25:50.609 --> 00:25:54.640
detektieren ist, um zu sehen: ist da jetzt
eigentlich eine zusätzliche
00:25:54.640 --> 00:26:00.879
Informationsausgabe oder nicht? Noch
komplizierter wird es beim Thema
00:26:00.879 --> 00:26:06.489
Lichtabstrahlung. Viele kennen sicherlich,
dass wenn ein Transistor mehrere Male
00:26:06.489 --> 00:26:12.489
schaltet – typischerweise so 1000 bis
10.000 Mal – entsteht als Nebenprodukt
00:26:12.489 --> 00:26:17.579
auch ein Photon, ein infrarotes
Lichtteilchen. Und dieses kann man
00:26:17.579 --> 00:26:22.149
natürlich messen oder zum Beispiel mit
speziellen Kameras aufnehmen. Damit kann
00:26:22.149 --> 00:26:25.849
man sehen, wo ist zum Bespiel Aktivität
im Chip, wo sind viele Transistoren, die
00:26:25.849 --> 00:26:30.819
schalten. Aber, wenn man eine
entsprechende Backdoor einbaut, könnte
00:26:30.819 --> 00:26:35.159
man natürlich auch ein Element auch so
gezielt manipulieren, dass es besonders
00:26:35.159 --> 00:26:39.399
häufig Informationen oder häufig
Photonen ausstrahlt, oder noch viel
00:26:39.399 --> 00:26:43.490
interessanter: man weiß einfach, an
welcher Stelle ist dieser Transistor, den
00:26:43.490 --> 00:26:48.820
ich beobachten muss, und damit „morst“
sozusagen, wie mit einer Taschenlampe
00:26:48.820 --> 00:26:55.210
dieser Transistor dann die Informationen
halt entsprechend raus. Genauso messen
00:26:55.210 --> 00:27:00.649
kann man auch das Potenzial natürlich auf
Signalleitungen; sicherlich habt ihr bei
00:27:00.649 --> 00:27:05.109
unserem Vortrag „25 Jahre
Chipkarten-Angriffe“ auch gesehen, wie
00:27:05.109 --> 00:27:10.179
man mittels Elektronen-Rastermikroskop
die Potenziale auf elektrischen Leitungen
00:27:10.179 --> 00:27:15.189
messen kann. Wenn ich jetzt den gesamten
Chip beobachte, dann sehe ich natürlich
00:27:15.189 --> 00:27:20.469
eine Vielzahl von Potenzialen auf den
einzelnen Leitungen. Aber: Jemand der
00:27:20.469 --> 00:27:24.929
gezielt diese Backdoor nutzt, hat sich
vielleicht eine Leitung in eine obere
00:27:24.929 --> 00:27:30.269
Metalllage gelegt, von der er weiß, hier
laufen alle kritischen Daten rüber. Jetzt
00:27:30.269 --> 00:27:34.559
kann er diese einfach mit dem
Elektronenstrahl ausmessen und damit dann
00:27:34.559 --> 00:27:38.759
die Informationsübertragung aus dem
Chip heraus in das System – in das
00:27:38.759 --> 00:27:44.320
Analysesytem – vornehmen. Ja, und wie
vielfältig das Ganze ist, sieht man sogar
00:27:44.320 --> 00:27:48.529
(daran), dass selbst die Temperatur
genutzt werden kann. Auch hier gibt es
00:27:48.529 --> 00:27:54.259
gerade jüngste Quellen, die zeigen, dass
auf einem Multi-Core-System auf dem einen
00:27:54.259 --> 00:28:00.029
Prozessor viel gerechnet wird und das die
Bearbeitung auf dem anderen Core in diesem
00:28:00.029 --> 00:28:04.500
System beeinflusst. Ja, viel mehr noch:
es gibt sogar eine entsprechende
00:28:04.500 --> 00:28:09.619
Veröffentlichung, wo einfach zwei PCs
nebeneinander stehen; auf dem einen PC
00:28:09.619 --> 00:28:14.029
wird gerechnet und auf dem anderen PC
wird aufgrund der intern integrierten
00:28:14.029 --> 00:28:19.269
Temperatursensoren dann die Erwärmung
beobachtet und somit praktisch kontaktlos
00:28:19.269 --> 00:28:23.109
von einem System zum anderen die
Information übertragen. Natürlich: das
00:28:23.109 --> 00:28:26.770
ist sehr, sehr langsam, weil so
Temperatur ändert sich natürlich nicht
00:28:26.770 --> 00:28:30.710
so schnell, da spricht man nur von wenigen
Bits pro Stunde, die übertragen werden
00:28:30.710 --> 00:28:35.090
können, aber immerhin – auch solche
Seitenkanäle können dafür genutzt
00:28:35.090 --> 00:28:45.009
werden. Sehr viel bekannter sind wiederum
Manipulations-Backdoors; wer kennt es
00:28:45.009 --> 00:28:48.769
nicht, dass auf einem Chip, wenn man sich
den mal genauer anschaut, vielleicht nicht
00:28:48.769 --> 00:28:52.570
nur die angeschlossenen Kontaktfelder
sind, sondern vielleicht auch zusätzliche
00:28:52.570 --> 00:28:56.720
Kontaktfelder, wo im Datenblatt
ganz lapidar „n/c“ – not connected
00:28:56.720 --> 00:29:03.279
dransteht, oder „RFU“ – for future
use. Wer weiß, was dahinter wirklich
00:29:03.279 --> 00:29:07.760
steckt, ob die wirklich nicht
angeschlossen sind, oder ob da nicht eine
00:29:07.760 --> 00:29:11.859
zusätzliche Funktionalität ist – sei
es eine Debug-Schnittstelle oder andere
00:29:11.859 --> 00:29:17.539
Funktionalitäten, über die man dann mit
dem Chip entsprechend kommunizieren kann?
00:29:17.539 --> 00:29:22.299
Und genauso, wie man das auf den
Kontaktfeldern beobachten kann, ist
00:29:22.299 --> 00:29:28.369
natürlich auch denkbar, dass man (…)
bei der Implementierung eines Trojaners
00:29:28.369 --> 00:29:33.010
eine vorbestimmte Signalleitung auf dem
Chip implementiert und wird diese zum
00:29:33.010 --> 00:29:37.029
Beispiel mittels eines Laserstrahls
durchgeschnitten – ein normaler
00:29:37.029 --> 00:29:41.460
Lasercutter, der auch auf dem
Gebrauchtmarkt recht preiswert zu haben
00:29:41.460 --> 00:29:46.139
ist – dann kann man entsprechend die
Zusatzfunktionalität in diesem Chip
00:29:46.139 --> 00:29:50.440
vielleicht freischalten und dann
plötzlich erst nach dieser Manipulation,
00:29:50.440 --> 00:29:56.789
nach diese physikalischen Manipulation mit
dem Chip kommunizieren. Und selbst
00:29:56.789 --> 00:30:01.219
Speicherzellen wie zum Beispiel das RAM,
hatten wir eben ja schon gesehen bei
00:30:01.219 --> 00:30:04.780
physical unclonable functions, bei
den sogenannten „unklonierbaren
00:30:04.780 --> 00:30:10.080
Funktionen“, kann man mittels zum
Beispiel Ionenimplantation auch verändern
00:30:10.080 --> 00:30:16.479
und damit andere Daten vorgeben oder die
Funktion der Schaltung verändern. Last
00:30:16.479 --> 00:30:20.739
but not least: der Bereich der
Fehlerinduktion kann auch noch genutzt
00:30:20.739 --> 00:30:27.639
werden, um (…) durch die Backdoor zu
kommunizieren und dem Trojaner
00:30:27.639 --> 00:30:32.899
entsprechend Informationen mitzuteilen.
Zum Beispiel könnte man spezielle
00:30:32.899 --> 00:30:38.479
Elemente mit einem Laserstrahl anleuchten
– und klar, der Chip ist aus Silizium,
00:30:38.479 --> 00:30:42.309
das ist am Ende nichts anderes als auch
eine Solarzelle vielleicht auf dem Dach
00:30:42.309 --> 00:30:46.589
– das heißt, der Laserstrahl induziert
dann eine kleine Photospannung oder einen
00:30:46.589 --> 00:30:50.999
Photostrom und kann dadurch dann
natürlich eine Schaltfunktionalität
00:30:50.999 --> 00:30:55.609
auslösen, die man von außen so gar nicht
direkt steuern kann, wenn man nicht genau
00:30:55.609 --> 00:31:01.209
weiß, wo man mit dem Laser draufblitzen
muss. Was bekannter ist, ist auch, das
00:31:01.209 --> 00:31:06.699
häufig Speicher mit Schutzmechanismen
ausgestattet werden. Wer kennt es nicht:
00:31:06.699 --> 00:31:10.669
nachdem man ein Programm in einem
Mikrocontroller heruntergeladen hat, dann
00:31:10.669 --> 00:31:15.080
wird ein Schreibschutz-Bit gesetzt und
anschließend soll es nicht mehr möglich
00:31:15.080 --> 00:31:20.739
sein, die Daten auszulesen. Wenn man aber
als Designer vielleicht genau weiß: diese
00:31:20.739 --> 00:31:24.629
Transistorzelle entscheidet jetzt
darüber, ob man einen Zugriff hat, oder
00:31:24.629 --> 00:31:29.759
nicht, weiß man vielleicht auch wo man
genau mit dem ultravioletten Licht
00:31:29.759 --> 00:31:33.899
draufleuchten muss, um diesen
Schreibschutz halt zu deaktivieren und
00:31:33.899 --> 00:31:38.349
dann doch wieder einen Zugriff auf den
Speicher zu bekommen. Jetzt gibt es das
00:31:38.349 --> 00:31:42.550
teilweise, dass das tatsächlich als
Bugdoor, wie Peter ja auch schon erklärt
00:31:42.550 --> 00:31:46.879
hat, einfach als schlechtes Design
implementiert ist. Aber es könnte
00:31:46.879 --> 00:31:51.070
natürlich auch vorsätzlich implementiert
sein, als Backdoor, dass der Designer
00:31:51.070 --> 00:31:55.230
genau weiß wenn ich die Daten hier raus
haben möchte, dann lösche ich diese eine
00:31:55.230 --> 00:32:02.490
Speicherzelle, z.B. mittels UV-Strahlung
und habe dann den Zugriff. Eine sehr
00:32:02.490 --> 00:32:07.999
spannende, aber auch kniffligere Sache ist
das Thema der Zufallszahlen-Generatoren.
00:32:07.999 --> 00:32:13.190
Die Zufallszahlen-Generatoren werden
ja viel genutzt um kryptographische
00:32:13.190 --> 00:32:19.119
Funktionen abzusichern. Der Zufall, eben
eine nicht vorhersagbare Funktion
00:32:19.119 --> 00:32:25.790
innerhalb dieses Chips, auszunutzen um
z.B. Daten zu randomisieren, oder aber
00:32:25.790 --> 00:32:31.869
Abläufe zufällig zu gestalten. Das Ganze
wir aber natürlich ad-absurdum geführt,
00:32:31.869 --> 00:32:36.499
wenn man diese Zufallszahlen von außen
beeinflussen kann. Oder aber sogar deren
00:32:36.499 --> 00:32:41.910
Werte vorgeben kann. Und genau auch das
ist mit Fehlerinduktion denkbar, dass man
00:32:41.910 --> 00:32:47.219
z.B. von außen ein elektromagnetisches
Feld, also im Prinzip eine Radiofrequenz
00:32:47.219 --> 00:32:52.919
vorgibt, und damit die internen
Zufallszahlen in einer Weise beeinflusst,
00:32:52.919 --> 00:32:58.189
dass man direkt Daten einprägen kann,
oder aber zumindest aufsynchronisieren
00:32:58.189 --> 00:33:03.390
kann, dass man nicht mehr unvorhersagbare,
sondern vorhersagbare Zufallszahlen
00:33:03.390 --> 00:33:09.880
generiert. Eine Geschichte, nur wer genau
diese Frequenz kennt, wie er es einkoppeln
00:33:09.880 --> 00:33:14.859
kann, kann diese Backdoor dann nutzen
um z.B. die Zufallsprozesse innerhalb des
00:33:14.859 --> 00:33:21.099
Chips außer Gefecht zu setzen. Naja und
wenn wir über Sicherheitschips sprechen,
00:33:21.099 --> 00:33:26.249
dann wissen wir ja auch, dass sehr häufig
z.B. Sensoren eingebaut werden. Sensoren
00:33:26.249 --> 00:33:31.339
um Angriffe zu vermeiden, seien es z.B.
Spannungssensoren, Sensoren gegen
00:33:31.339 --> 00:33:41.410
Lichtbestrahlung, Temperatursensoren usw.
Wer sagt denn, dass diese Sensoren
00:33:41.410 --> 00:33:47.190
tatsächlich den gesamten Raum abdecken,
oder ob vielleicht nicht absichtlich eine
00:33:47.190 --> 00:33:51.399
Schutzlücke eingebaut worden ist, das
heißt derjenige, der diesen Sensor
00:33:51.399 --> 00:33:55.859
implementiert hat, weiß vielleicht dass
genau bei diesem genauen Parametersatz ist
00:33:55.859 --> 00:34:00.809
der Sensor „blind“ sozusagen, und er
kann diesen Parametersatz nutzen, um
00:34:00.809 --> 00:34:05.229
gezielt eine Fehlerinduktion in dem
Programmablauf oder in den verrechneten
00:34:05.229 --> 00:34:10.200
Daten einzuführen. Und damit dann
entsprechend, auch wieder mit dem Trojaner
00:34:10.200 --> 00:34:16.209
zu kommunizieren. Also man sieht schon,
es gibt rund um das Thema Backdoors sehr,
00:34:16.209 --> 00:34:20.440
sehr viele verschiedene Möglichkeiten
in der Hardware – weitaus mehr
00:34:20.440 --> 00:34:25.199
Möglichkeiten als bei Software-Trojanern
– wie man mit ihm kommunizieren kann und
00:34:25.199 --> 00:34:30.770
wie man hier auch tatsächlich
Informationen austauschen kann. Eine
00:34:30.770 --> 00:34:36.740
besondere, große Bedrohung geht von
den Analyseschnittstellen aus. Denn die
00:34:36.740 --> 00:34:41.418
Analyseschnittstellen sind ja meistens
ein Feature was sogar mit einer guten
00:34:41.418 --> 00:34:46.569
Intention eingebaut worden ist. Z.B. bei
den Festplatten, wie man hier im oberen
00:34:46.569 --> 00:34:52.400
Bild sieht, wo ein Debug-Port eingebaut
worden ist, um, wenn die Festplatte nicht
00:34:52.400 --> 00:34:56.369
richtig funktioniert, festzustellen, was
ist da jetzt wirklich kaputt, kann man
00:34:56.369 --> 00:35:00.969
vielleicht eine neue Firmware einspielen,
kann man vielleicht noch Daten retten. Auf
00:35:00.969 --> 00:35:04.339
der anderen Seite kann genau dieser
Debug-Port natürlich auch dafür
00:35:04.339 --> 00:35:10.080
missbraucht werden, um auf Daten direkt
zuzugreifen oder aber um Trojaner in die
00:35:10.080 --> 00:35:15.049
Firmware der Festplatte einzuspielen.
Ja, und noch größer ist natürlich der
00:35:15.049 --> 00:35:19.740
Bereich der sogenannten JTAG-Ports, die
Analyse-Schnittstelle, die sich in vielen
00:35:19.740 --> 00:35:25.189
Geräten wiederfindet und teilweise sehr
mangelhaft abgesichert ist. Denn hier
00:35:25.189 --> 00:35:29.400
haben wir ein Beispiel von einem
WLAN-Router, wo man über den JTAG-Port
00:35:29.400 --> 00:35:35.999
auch neue Firmware, z.B. mit Trojanern,
in die WLAN-Router einbringen kann.
00:35:35.999 --> 00:35:37.730
Denken wir das jetzt noch einmal weiter:
00:35:37.730 --> 00:35:40.970
was passiert, wenn jetzt eigentlich
ein Sicherheits-Chip mit solch einem
00:35:40.970 --> 00:35:45.960
Analyse-Port ausgestattet ist? Nun, da
kann man natürlich sagen, wenn dieser
00:35:45.960 --> 00:35:49.650
Chip mal ausfällt, kann ich versuchen,
darüber dann tatsächlich nochmal
00:35:49.650 --> 00:35:54.190
den zu reparieren, oder zumindestens
an die Daten wieder ranzukommen, sie
00:35:54.190 --> 00:35:58.340
zu restaurieren. Ja, aber, genau das
ist ja das was man nicht möchte. Ein
00:35:58.340 --> 00:36:02.519
Sicherheits-Chip soll doch bitte die
Daten auch wirklich geheim in sich halten
00:36:02.519 --> 00:36:06.470
und nicht dann über einen Analyse-Port
vielleicht doch wieder zugänglich
00:36:06.470 --> 00:36:12.380
machen. Und deshalb sind insbesondere auf
Sicherheits-Chips natürlich Analyse-Ports
00:36:12.380 --> 00:36:17.799
alles andere als eine gute Wahl. Und
wie manches Mal aus einem guten
00:36:17.799 --> 00:36:22.599
Feature tatsächlich dann auch eine
missbräuchliche Nutzung entstehen kann,
00:36:22.599 --> 00:36:27.230
haben wir einfach mal dargestellt an
dem Beispiel eines Türspions. Wir sehen
00:36:27.230 --> 00:36:31.710
hier den Türspion. Und im zweiten Bild
einfach mal was passiert eigentlich,
00:36:31.710 --> 00:36:35.119
wenn ich durch den Türspion nach
draußen schaue: naja, ich habe die
00:36:35.119 --> 00:36:39.470
gute Möglichkeit, zu sehen: wer steht
da eigentlich vor der Tür? Ist das
00:36:39.470 --> 00:36:43.229
eine zumindestens dem Anschein nach
vertrauenswürdige Person? Sollte
00:36:43.229 --> 00:36:47.759
ich jetzt besser die Tür öffnen oder
lieber besser geschlossen lassen? Genauso
00:36:47.759 --> 00:36:51.040
wie diese gute Funktionalität in dem
Türspion drin ist, kann sie aber auch
00:36:51.040 --> 00:36:55.170
missbräuchlich genutzt werden. Wenn
ich z.B. wie im 4. Bild zu sehen, eine
00:36:55.170 --> 00:36:59.029
Umkehr-Optik von draußen aufsetze,
dann sehe ich nicht mehr nur den
00:36:59.029 --> 00:37:03.660
kleinen Lichtpunkt hinter der Tür,
wo das ganze Bild zusammengezerrt ist;
00:37:03.660 --> 00:37:07.569
sondern aufgrund dieser Umkehr-Optik
kann ich plötzlich feststellen, was ist
00:37:07.569 --> 00:37:11.980
eigentlich in der Wohnung? Es erlaubt
mir den Blick nach innen und damit:
00:37:11.980 --> 00:37:15.460
wer ist eigentlich in der Wohnung,
oder ist da überhaupt jemand? Wie ist
00:37:15.460 --> 00:37:19.890
sie ausgestattet? Und so weiter. Das
ist unseres Erachtens nach ein schönes
00:37:19.890 --> 00:37:25.200
Beispiel, wie tatsächlich auch ein gut
gemeintes Feature eventuell dann eben
00:37:25.200 --> 00:37:28.880
als Backdoor missbraucht wird.
00:37:28.880 --> 00:37:33.950
Peter: Ja, in den 90er Jahren – Ende
der 90er Jahre, würde ich sagen
00:37:33.950 --> 00:37:37.540
– war ziemlich klar, dass nach
Software-Trojanern als nächstes
00:37:37.540 --> 00:37:40.490
Hardware-Trojaner auf dem Plan
stehen. Dass das also eine echte
00:37:40.490 --> 00:37:43.959
Bedrohung ist. Und dementsprechend
haben wir uns zu der Zeit auch schon
00:37:43.959 --> 00:37:48.330
mal überlegt, was kann man eigentlich
machen, prophylaktisch, um sowas zu
00:37:48.330 --> 00:37:53.100
verhindern, um das Risiko zu minimieren;
und überhaupt Technik so zu bauen, dass
00:37:53.100 --> 00:37:59.459
sie Trojaner- und Backdoor-resistent
ist. In dem Rahmen, wie das möglich ist.
00:37:59.459 --> 00:38:02.970
Und um uns dieser Sache zu nähern,
haben wir uns zunächst mal überlegt,
00:38:02.970 --> 00:38:05.500
was können das eigentlich für Motive
sein? Also was bringt eigentlich die
00:38:05.500 --> 00:38:09.840
Leute dazu, Trojaner und Backdoors
einzubauen? Ob das jetzt willentlich
00:38:09.840 --> 00:38:15.239
ist oder unwillentlich. Das zeigen wir
hier in diesen 4 Kategorien. Es fängt
00:38:15.239 --> 00:38:20.450
an mit dem „Bösen Willen“, hier auf
dem ersten Foto mal zu sehen. Beim
00:38:20.450 --> 00:38:24.190
Bösen Willen ist es im Prinzip ganz
klar, daran denkt jeder zunächst mal
00:38:24.190 --> 00:38:28.660
als erstes. Es könnten Sabotagegründe
sein, z.B. Erpressung könnte eine Rolle
00:38:28.660 --> 00:38:34.000
spielen. Ein bestimmtes System ist schon
im Feld und ein Hersteller, z.B. dieses
00:38:34.000 --> 00:38:37.619
Systems wird erpresst, dass man mit einem
bestimmten Kommando einer Backdoor dieses
00:38:37.619 --> 00:38:41.320
System komplett lahmlegen könnte. Zum
Beispiel. Aber es können auch politische
00:38:41.320 --> 00:38:46.439
Motive da eine Rolle spielen. Auch
alles bekannt; also der Diktator unserer
00:38:46.439 --> 00:38:50.869
Wahl sozusagen möchte seinen Bürgern
etwas näher auf den Zahn fühlen und
00:38:50.869 --> 00:38:55.179
die Kommunikation überwachen, baut
dementsprechend Backdoors ein. Oder,
00:38:55.179 --> 00:38:59.179
bringt Trojaner ins Spiel. Auf der
anderen Seite des Spektrums, ganz
00:38:59.179 --> 00:39:03.400
interessant, der Gute Wille. Auch das
geschieht dann aus Vorsatz. Und Markus
00:39:03.400 --> 00:39:07.490
hatte da ja schon einige Beispiele
mal gezeigt: das können Dinge sein,
00:39:07.490 --> 00:39:11.650
wie z.B. Service-Schnittstellen, das
können Debugging-Sachen sein. Im
00:39:11.650 --> 00:39:15.950
Prinzip, letztlich sogar, Kundendienst,
dass jemand also wirklich fragt,
00:39:15.950 --> 00:39:19.570
er möchte bei so einem Chip die
Möglichkeit haben, im Nachhinein was
00:39:19.570 --> 00:39:23.000
zu reparieren oder die Daten wieder
rauszuholen. Passt natürlich nicht zu
00:39:23.000 --> 00:39:27.190
Sicherheits-Chips. Und dann schließlich,
auch da gibt’s politische Motive. Da ist
00:39:27.190 --> 00:39:30.749
es dann nicht der fiese Diktator unserer
Wahl, sondern der freundliche Monarch
00:39:30.749 --> 00:39:34.289
unserer Wahl, der aber das Gleiche will,
seinen Bürgern auf den Zahn fühlen
00:39:34.289 --> 00:39:40.420
und alles mitlesen können. Wir haben
auch noch zwei andere Kategorien hier
00:39:40.420 --> 00:39:44.730
aufgezeigt. Die sind nicht aktiver
Natur. Also nicht vorsätzlicher Natur,
00:39:44.730 --> 00:39:49.059
sondern eher passiver Natur. Und zwar
haben wir die erstmal als Ignoranz
00:39:49.059 --> 00:39:53.130
und Dummheit bezeichnet, und das auch
voneinander getrennt. Warum haben
00:39:53.130 --> 00:39:57.910
wir das voneinander getrennt? Bei der
Ignoranz ist es so, dass die Auswirkungen
00:39:57.910 --> 00:40:02.170
zumindest teilweise bekannt sind. D.h.
jemand weiß eigentlich, das was er da
00:40:02.170 --> 00:40:06.309
gerade macht, in einer bestimmten
Entwicklung oder Konzeptionierungsphase,
00:40:06.309 --> 00:40:10.680
dass das eigentlich falsch ist. Es
könnten z.B. Gründe dahinterstehen, wie
00:40:10.680 --> 00:40:14.450
Zeitdruck. Eine Analyse-Schnittstelle
z.B. soll für ein fertiges Produkt noch
00:40:14.450 --> 00:40:17.969
ausgebaut werden. Eigentlich muss man
das machen, um den Chip dann sicher zu
00:40:17.969 --> 00:40:21.520
bekommen. Es wird aber aus Zeitdruck
nicht gemacht. Dazu kann z.B. auch noch
00:40:21.520 --> 00:40:25.240
Verdrängung kommen, dass man dann sich
sagt „Ja, es ist ja nicht so schlimm, das
00:40:25.240 --> 00:40:29.850
wird schon keiner finden“. Oder eben auch,
dass Hierarchien eine wesentliche Rolle
00:40:29.850 --> 00:40:34.469
spielen; dass jemandem gesagt wird „Mach’
das mal so, bau’ das mal so ein!“ und das
00:40:34.469 --> 00:40:37.869
nicht hinterfragt wird, warum das
eigentlich notwendig ist, wofür man das
00:40:37.869 --> 00:40:40.510
eigentlich braucht, und ob man das
hinterher wieder ausbauen soll. Oder
00:40:40.510 --> 00:40:45.280
drinlassen soll. Ja, und dann
schließlich, das Thema ‚Dummheit‘ haben
00:40:45.280 --> 00:40:49.870
wir hier auch explizit mal so genannt,
so plakativ. Einerseits Bildungsmangel,
00:40:49.870 --> 00:40:55.130
Überforderung kann eine Rolle spielen.
Auch etwas plakativ hier mal dargestellt,
00:40:55.130 --> 00:40:59.000
das Thema ‚Fachidiotie‘ wirklich zu
nennen. Das ist wirklich die Plage des
00:40:59.000 --> 00:41:04.600
21. Jahrhunderts. Denn die Systeme die man
heute baut, die sind sehr, sehr komplex
00:41:04.600 --> 00:41:09.730
und da sind teilweise Hunderte von
Entwicklern, Hunderte von Leuten dabei
00:41:09.730 --> 00:41:14.910
sowas zu machen. Wie das Einzelne
ineinander spielt, also welches Zahnrad in
00:41:14.910 --> 00:41:19.410
welches andere Zahnrad greift, und welche
Zahnräder in Kombination zusammen ein
00:41:19.410 --> 00:41:23.940
Schlangenöl ergeben oder auch nicht,
das ist oft nicht bekannt. Und auch da
00:41:23.940 --> 00:41:28.880
hatte Marcus ja schon so einige Beispiele
mal gezeigt, wie eine eigentlich gut
00:41:28.880 --> 00:41:34.250
gemeinte Sache dann schließlich zu einer
Backdoor führt oder zu einem hohen Risiko
00:41:34.250 --> 00:41:40.440
des Backdoor-Auftretens. Und natürlich
für uns interessant gewesen: was kann man
00:41:40.440 --> 00:41:47.570
dagegen tun? Und auch hier haben wir uns
3 Kategorien ausgedacht: die Aufklärung
00:41:47.570 --> 00:41:51.470
Technologie – also technologische Gegen-
maßnahmen, und die Verpflichtung – kann
00:41:51.470 --> 00:41:58.019
von extern oder auch selbst passieren. Und
hier an diesem grünen und grauen Streifen
00:41:58.019 --> 00:42:03.430
haben wir mal versucht aufzuzeigen, wie
wirksam das Ganze ist. Und das erste, was
00:42:03.430 --> 00:42:08.670
wir da aufgezählt haben, die Aufklärung,
ist natürlich ganz klar gegen Dummheit,
00:42:08.670 --> 00:42:14.230
gegen Nichtwissen nützt am besten
Aufklärung. Gegen bösen Willen auf der
00:42:14.230 --> 00:42:17.970
anderen Seite nützt Aufklärung wenig.
Vielleicht sogar im Gegenteil, wenn man
00:42:17.970 --> 00:42:22.109
jemandem sagt: „Das wäre also wirklich
der Tod des Unternehmens, wenn da so eine
00:42:22.109 --> 00:42:26.050
Backdoor eingebaut wäre, die so und so
aussieht“, dann kann das natürlich sein,
00:42:26.050 --> 00:42:30.280
dass der Saboteur genau das dann
einbringt. Klar. Aber wie gesagt, die
00:42:30.280 --> 00:42:34.779
Aufklärung sehen wir als ganz, ganz
wichtig an. Bei der Technologie... bei den
00:42:34.779 --> 00:42:39.269
technologischen Gegenmaßnahmen, da ist es
so, dass einerseits man sagen muss, ist
00:42:39.269 --> 00:42:43.090
vom Motiv des Angreifers eigentlich
unabhängig. Technologische
00:42:43.090 --> 00:42:50.000
Gegenmaßnahmen erschweren den Einbau von
Backdoors und Trojanern generell. Trotzdem
00:42:50.000 --> 00:42:54.260
haben wir das Ganze etwas eingekerbt, auf
der rechten und auf der linken Seite. Und
00:42:54.260 --> 00:42:58.500
das hat auch seinen Grund: weil diese
beiden Bereiche mit Vorsatz verbunden
00:42:58.500 --> 00:43:03.510
sind. Und das könnte heißen, dass jemand
z.B. der so etwas vorhat sich schlaumacht:
00:43:03.510 --> 00:43:07.260
was sind denn da für technologische
Gegenmaßnahmen eingebaut; und dann
00:43:07.260 --> 00:43:11.870
versucht, vielleicht auch mit anderen
Leuten zusammen, um diese technologischen
00:43:11.870 --> 00:43:16.299
Gegenmaßnahmen herumzukommen und
die außer Kraft zu setzen. Und dann
00:43:16.299 --> 00:43:20.940
schließlich gibt es noch die dritte
Kategorie: die Verpflichtung, kann
00:43:20.940 --> 00:43:24.030
Selbstverpflichtung sein oder auch externe
Verpflichtung, da kommen wir gleich noch
00:43:24.030 --> 00:43:28.449
drauf zu sprechen, auf diese 3 Bereiche.
Und auch da ist es so, dass das sehr, sehr
00:43:28.449 --> 00:43:32.860
unterschiedlich wirksam ist. Beim Bösen
Willen natürlich am wenigsten, aber bei
00:43:32.860 --> 00:43:39.209
den anderen Motiven schon etwas mehr.
Aber wie versprochen etwas mehr über diese
00:43:39.209 --> 00:43:44.880
Möglichkeiten, was kann also jeder tun,
der in einem dieser Bereiche Entwicklung,
00:43:44.880 --> 00:43:48.940
Konzeption oder auch Test arbeitet, um
Backdoors zu verhindern oder die zu
00:43:48.940 --> 00:43:53.660
erkennen. Und einerseits hier nochmal
die Punkte der Aufklärung. Das kann
00:43:53.660 --> 00:43:58.329
technische Aufklärung sein, das steht
natürlich im Vordergrund. Security by
00:43:58.329 --> 00:44:03.490
Obscurity darf nicht das Ziel sein.
Kerckhoffs sollte man schon berücksichtigen,
00:44:03.490 --> 00:44:07.480
wenn man irgendetwas baut.
Debug-Schnittstellen passen nicht zu
00:44:07.480 --> 00:44:11.479
Sicherheits-Chips – auch ganz wichtig.
Obwohl es immer wieder nachgefragt wird,
00:44:11.479 --> 00:44:16.200
kann man nicht für eigene Entwicklungen,
für eigene Fehleranalyse z.B so etwas
00:44:16.200 --> 00:44:21.020
einbauen. Gehört da nicht rein. Muss
leider draußen bleiben. Und nicht zu
00:44:21.020 --> 00:44:24.599
vergessen unser Aspekt auch hier,
Entwickler denken sehr oft nicht wie
00:44:24.599 --> 00:44:29.839
Hacker. D.h. sie sind eher konstruktiv,
manchmal konstruktivistisch unterwegs, und
00:44:29.839 --> 00:44:34.619
das bedeutet, dass man oft seinen eigenen
Resultaten oder dem was man da
00:44:34.619 --> 00:44:40.050
zusammengebaut hat, dann sehr hoch
vertraut. Und einen Angriff z.B. oder
00:44:40.050 --> 00:44:43.970
einen Sicherheits-Penetrationstest dann
eher so als Angriff auf die eigene Person
00:44:43.970 --> 00:44:48.830
sieht. Und jeder der im
IT-Sicherheits-Business tätig ist, der
00:44:48.830 --> 00:44:52.920
kennt das auch, dass man da erstmal so
eine konstruktive Atmosphäre schaffen
00:44:52.920 --> 00:44:57.870
muss. Indem man zusammen das Produkt dann
besser macht. Politische Aspekte sind
00:44:57.870 --> 00:45:04.300
natürlich auch ein wichtiges Thema. Hier
der Frankenstein-Effekt, sozusagen, zu
00:45:04.300 --> 00:45:07.809
nennen. Wenn man so einen Trojaner
tatsächlich irgendwo in der Praxis hat,
00:45:07.809 --> 00:45:11.210
dann ist der unkontrollierbar. D.h. man
weiß nicht, was damit passiert, wer den
00:45:11.210 --> 00:45:14.709
benutzt, schließlich. Er kann sich
natürlich auch gegen seinen eigenen
00:45:14.709 --> 00:45:18.819
Urheber richten. Und gleichzeitig ist
es auch so, braucht man bloß ins
00:45:18.819 --> 00:45:22.230
Geschicht-Buch reinzuschauen, dass die
politischen Situationen sich auch ändern
00:45:22.230 --> 00:45:26.780
können. Das ist hier vielleicht nicht
unbedingt so stark der Fall, im eigenen
00:45:26.780 --> 00:45:31.059
Land. Aber wenn ein Hersteller z.B. in
verschiedene Länder exportiert, 100..150
00:45:31.059 --> 00:45:35.390
Länder, dann ist die Wahrscheinlichkeit
doch relativ hoch, dass eins davon in den
00:45:35.390 --> 00:45:39.160
nächsten Monaten oder Jahren dann mal
umkippen könnte. Und dementsprechend
00:45:39.160 --> 00:45:42.790
wäre auch darauf natürlich zu achten.
Das Ganze verbunden auch mit den ethischen
00:45:42.790 --> 00:45:47.259
Aspekten. Für uns auch wichtig, denn
Backdoors können Personen in tödliche
00:45:47.259 --> 00:45:51.729
Gefahr bringen. Das ist also kein Spiel.
Und kein Spielzeug, sondern, wenn, gerade
00:45:51.729 --> 00:45:55.540
wenn man z.B. an das Thema Kompromat
denkt, und jemanden mit
00:45:55.540 --> 00:45:58.980
Top-Secret-Material, was ihm da
‚aufgeschleust‘ wurde, sozusagen
00:45:58.980 --> 00:46:02.119
‚angeschleust‘ wurde, an einer Grenze
festgehalten wird, dann ist das schon
00:46:02.119 --> 00:46:06.830
durchaus unangenehm. Wir sagen da immer:
„The road to hell is paved with good
00:46:06.830 --> 00:46:12.949
intentions“, gilt eigentlich für alles
da, was da steht. Oder auf Deutsch, frei
00:46:12.949 --> 00:46:18.650
nach diesem Motto „Gut gemeint ist
nicht gut gemacht“. Ja, es gibt einige
00:46:18.650 --> 00:46:21.759
technologische Gegenmaßnahmen gegen
Trojaner und Backdoors, also rein
00:46:21.759 --> 00:46:25.950
prophylaktisch, was auch sehr, sehr
wirksam ist. Dazu gehört zunächst mal:
00:46:25.950 --> 00:46:30.629
keine backdoor-fördernden Technologien
einzusetzen. Die gehören raus, und
00:46:30.629 --> 00:46:33.920
wenn man merkt, dass eine Technologie
backdoor-fördernd ist, oder sowas
00:46:33.920 --> 00:46:38.870
begünstigt, dann sollte man die in
Sicherheits-Chips nicht verwenden.
00:46:38.870 --> 00:46:41.740
Darüber hinaus gibt es ein paar
Möglichkeiten, dass man das Design so
00:46:41.740 --> 00:46:45.710
anlegt, dass Änderungen auffallen. D.h.
jemand anderes, der auch an dem Design
00:46:45.710 --> 00:46:50.390
arbeitet, eher merkt, dass etwas nicht
stimmt, oder dass im Test oder in der
00:46:50.390 --> 00:46:54.680
Evaluierung dann auffällt, dass etwas
nicht stimmt, weil die Änderungen, die
00:46:54.680 --> 00:46:58.400
durchzuführen sind, größer sind als
das was man bei schlangenöl-haltiger
00:46:58.400 --> 00:47:03.410
Technologie machen muss. Der Rest ist
im Prinzip ähnlich wie beim Thema der
00:47:03.410 --> 00:47:10.500
technologischen Aufklärung. Aber wir
haben hier auch gleichzeitig noch 2 andere
00:47:10.500 --> 00:47:15.840
Möglichkeiten aufgeführt. Das sind die
Selbsttest von Chips. Und die Erkennung
00:47:15.840 --> 00:47:19.239
nachdem ein Chip fertig ist. Aber da muss
man ein bisschen vorsichtig sein. Bei den
00:47:19.239 --> 00:47:23.510
Selbsttest ist es noch so, dass die
einigermaßen wirksam sind. Das bedeutet,
00:47:23.510 --> 00:47:27.470
dass ein Chip bevor er eine wirklich
kritische Operation macht, also z.B. eine
00:47:27.470 --> 00:47:31.259
Nachricht verschlüsseln, dass er vorher
eine Testoperation durchführt und schaut
00:47:31.259 --> 00:47:34.740
ob alles okay ist. Ob die Schlüssel nicht
manipuliert sind, die Zufallszahlen in
00:47:34.740 --> 00:47:39.310
Ordnung sind usw. Da gibt’s also ’ne ganze
Menge dieser Selbsttest, und wenn die alle
00:47:39.310 --> 00:47:45.509
vernünftig durchgelaufen sind, dann macht
ein Chip die eigentliche Operation. Aber
00:47:45.509 --> 00:47:49.579
kann natürlich sein, dass ein Insider
sich Gedanken macht und überlegt, was
00:47:49.579 --> 00:47:52.679
könnte da alles eingebaut sein das
mir das Leben schwer macht. Und
00:47:52.679 --> 00:47:57.219
dementsprechend auch diese Tests
manipuliert. Bedeutet aber, dass man da
00:47:57.219 --> 00:48:01.440
mehr Einfluss braucht, mehr Aufwand,
und vielleicht sogar Mitwisser. Das ist
00:48:01.440 --> 00:48:07.510
natürlich dann auch ein Problem. Bei der
Erkennung sind wir etwas skeptischer, also
00:48:07.510 --> 00:48:11.289
es gibt einige Resultate, einige
Arbeitsgruppen, auch die sich mit dem
00:48:11.289 --> 00:48:14.910
Thema Erkennung auseinandersetzen und
sagen man könnte doch bei einem fertigen
00:48:14.910 --> 00:48:18.329
Chip, wenn der sozusagen fertig
prozessiert ist, schauen ob da ’ne
00:48:18.329 --> 00:48:22.599
Backdoor drin ist, anhand z.B. der
Stromaufnahmekurven, die dieser Chip dann
00:48:22.599 --> 00:48:26.920
liefert. Da muss man aber sehr vorsichtig
sein, denn üblicherweise würde so eine
00:48:26.920 --> 00:48:31.449
Backdoor ja so angelegt werden, dass sie
nicht ständig aktiv ist. Und außerdem
00:48:31.449 --> 00:48:34.120
ist es so bei Sicherheits-Chips, bei
Sicherheits-Software und auch bei
00:48:34.120 --> 00:48:37.140
Sicherheits-Hardware, dass der
Stromverbrauch sowieso immer relativ
00:48:37.140 --> 00:48:42.919
zufällig gewählt wird. Einfach auch
um Seitenkanal-Angriffe abzuhalten.
00:48:42.919 --> 00:48:48.630
Dementsprechend ist so eine Entdeckung von
Manipulation am fertigen Chip sehr, sehr
00:48:48.630 --> 00:48:53.380
schwierig. Es gibt aber noch eine dritte
Möglichkeit, gegen Trojaner vorzugehen,
00:48:53.380 --> 00:48:57.949
auch präventiv. Und das ist die
Verpflichtung. Gibt 2 Möglichkeiten, also
00:48:57.949 --> 00:49:03.280
einerseits eine auferlegte Verpflichtung.
Und was man heute auch durchaus mal sieht,
00:49:03.280 --> 00:49:07.049
ist, dass Leute die Sicherheits-Chips
einsetzen, die die also kaufen oder sich
00:49:07.049 --> 00:49:11.930
umsehen, wo gibt’s die, dass die sehr,
sehr genau schauen, wer stellt die her,
00:49:11.930 --> 00:49:16.210
was haben die für eine Historie
z.B. die Hersteller, wie sind die
00:49:16.210 --> 00:49:19.969
Besitzverhältnisse, wo ist der
Hauptsitz z.B. der Firma, welche
00:49:19.969 --> 00:49:24.819
Einflussmöglichkeiten gibt es von
anderen, von Dritten, auf diese Firmen.
00:49:24.819 --> 00:49:30.749
Also das kommt immer mehr, man merkt
es eigentlich sehr schön. Ja, Gesetze und
00:49:30.749 --> 00:49:37.239
Richtlinien – zunächst mal zu nennen die
Datenschutzgesetze, natürlich. Ganz nett,
00:49:37.239 --> 00:49:41.380
die Frage natürlich: wer setzt die durch?
Und wer überprüft die Einhaltung dieser
00:49:41.380 --> 00:49:45.660
Gesetze die es schon gibt eigentlich? Und
da ist natürlich ein Realitätsabgleich
00:49:45.660 --> 00:49:50.670
nötig. Z.B. die Frage: Wo gelten die?
Also, zu Lande, im Weltraum und
00:49:50.670 --> 00:49:55.479
ähnliches? Ist ja immer die Frage wie wir
wissen. Und dann gibt’s schließlich noch
00:49:55.479 --> 00:50:00.110
die Selbstverpflichtung, die eigentlich
gar nicht so schlecht ist. In diesem Fall
00:50:00.110 --> 00:50:05.200
ist es so, dass der Hersteller selber
sich selbst verpflichten würde, keine
00:50:05.200 --> 00:50:09.430
Backdoors und keine Trojaner einzusetzen.
Jetzt natürlich die Frage: "Wieviel bringt
00:50:09.430 --> 00:50:15.060
das, wenn er sich nur selber verpflichtet?
Was da passiert ist im Prinzip, dass ein
00:50:15.060 --> 00:50:19.409
künstliches ökonomisches Risiko erzeugt
wird. Das heißt, wenn der Hersteller z.B.
00:50:19.409 --> 00:50:23.220
überführt wird, dass er also trotz
dieser Selbstverpflichtung trotzdem so
00:50:23.220 --> 00:50:26.849
eine Backdoor eingesetzt hat, oder
die verwendet, dann hat das für ihn
00:50:26.849 --> 00:50:31.500
natürlich negative Konsequenzen. Und
dieses ökonomische Risiko was dann
00:50:31.500 --> 00:50:34.780
entsteht, das führt dazu, dass
beim Hersteller selbst und in
00:50:34.780 --> 00:50:40.200
Entwicklungsprozessen mehr darauf geachtet
wird, solche Backdoors nicht einzubauen.
00:50:40.200 --> 00:50:44.480
Bzw. auch nicht unbeabsichtigt einzubauen.
D.h. die Tests... könnte man erwarten,
00:50:44.480 --> 00:50:48.610
dass die Tests z.B. besser werden, dass
die Evaluierungsmöglichkeiten besser
00:50:48.610 --> 00:50:52.250
werden, und dass natürlich auch die
Beeinflussungsmöglichkeiten schlechter
00:50:52.250 --> 00:50:58.070
werden. Dass die Aufklärung besser wird.
Also im Prinzip alles prima. Die Frage
00:50:58.070 --> 00:51:01.559
natürlich: Warum soll sich ein Hersteller
so einem ökonomischen Risiko aussetzen,
00:51:01.559 --> 00:51:05.949
wenn es nicht belohnt wird? Aber auch da
ändert sich momentan so ein wenig die
00:51:05.949 --> 00:51:11.640
Lage. Man sieht schon, dass Hersteller
die da vorpreschen, dass die schon eine
00:51:11.640 --> 00:51:15.730
Vorbildfunktion dann für andere auch
darstellen können. Man kann das Ganze mit
00:51:15.730 --> 00:51:21.749
anderen ethischen Werten koppeln. Aber
natürlich, schließlich die Frage: Lohnt
00:51:21.749 --> 00:51:24.969
es sich für einen Hersteller, wer macht
das bisher? Wir hoffen, dass das besser
00:51:24.969 --> 00:51:32.479
wird. Und dass da mehr Unternehmen sich
diesen Sachen dann widmen. So kommen wir
00:51:32.479 --> 00:51:35.380
auch schon zum Ende unseres Vortrages.
Wir haben einige Literatur noch
00:51:35.380 --> 00:51:40.659
zusammengestellt für euch. Wen es
interessiert, also hier z.B. von 1972
00:51:40.659 --> 00:51:46.740
die erste Literaturstelle, die erste
Fundstelle, wo wirklich von Computer-
00:51:46.740 --> 00:51:50.929
Trojanern wirklich gesprochen wird und wo
so die Konzepte aufgestellt werden. Bis
00:51:50.929 --> 00:51:55.990
hin zur letzten Fundstelle, gerade jetzt
von Dezember, eigentlich eine ganz
00:51:55.990 --> 00:52:00.900
interessante Arbeit. Kann sich jeder
gerne mal durchlesen, wenn er Zeit hat.
00:52:00.900 --> 00:52:05.110
Ja, damit wie gesagt, möchten wir dann
auch schließen. Wir wünschen euch viel
00:52:05.110 --> 00:52:07.979
Spaß bei der eigenen Forschung. Wenn
es Fragen gibt, sind wir noch ein paar
00:52:07.979 --> 00:52:12.299
Minuten hier. Und ansonsten können wir
auch darauf verweisen, wir wären morgen
00:52:12.299 --> 00:52:15.563
in unserem Assembly. Und wer Lust hat kann
gern vorbeikommen, mit uns diskutieren.
00:52:15.563 --> 00:52:19.849
Vielleicht gibt es ja auch noch
interessante Ideen, die wir dann
00:52:19.849 --> 00:52:22.990
zusammen besprechen können.
Also vielen Dank schon mal!
00:52:22.990 --> 00:52:33.420
Applaus
00:52:33.420 --> 00:52:36.589
Herald: Vielen Dank! Also, ihr habt
gehört, ihr habt jetzt ein paar Minuten
00:52:36.589 --> 00:52:41.690
Zeit, Fragen zu stellen. Wenn es Fragen
gibt, stellt euch bitte an die Mikrofone.
00:52:41.690 --> 00:52:47.649
Die anderen die jetzt schon den Saal
verlassen, tun dies bitte möglichst leise!
00:52:47.649 --> 00:52:52.330
Gibt’s irgendwelche Fragen?
00:52:52.330 --> 00:52:57.000
Peter: Ah, da ist einer!
00:52:57.000 --> 00:53:02.010
Herald: Ah, dort hinten erkenne ich
jemanden an Mikrofon 3. Bitte!
00:53:02.010 --> 00:53:06.420
Frage: Und zwar stellt sich mir die Frage,
dass man ja Software gut eigentlich
00:53:06.420 --> 00:53:10.459
damit absichern kann, indem man beweist,
dass sie der Spezifikation genügt.
00:53:10.459 --> 00:53:13.450
Gibt es da Ansätze für Hardware
in den verschiedenen Leveln,
00:53:13.450 --> 00:53:18.289
also für VHDL, für die
Implementierung usw.?
00:53:18.289 --> 00:53:22.240
Marcus: Es gibt in der Tat, natürlich,
den Versuch, zu analysieren,
00:53:22.240 --> 00:53:26.849
ist da eine unbemerkte Funktionalität
eingebaut worden? Da gibt es auch
00:53:26.849 --> 00:53:31.019
entsprechende Ansätze. Allerdings muss
man ganz fairerweise sagen, dass natürlich
00:53:31.019 --> 00:53:36.060
diese Ansätze es sehr schwer haben,
eine Vollständigkeit nachzuweisen.
00:53:36.060 --> 00:53:40.139
Und wir haben es gerade gesehen, z.B. im
Herstellungsprozess stelle ich mir vor,
00:53:40.139 --> 00:53:45.399
ganz zum Schluss, in der Veränderung des
Maskensatzes, so ist dieses nur noch
00:53:45.399 --> 00:53:49.670
am fertigen Produkt oder an der Maske
selber nachweisbar. Infolgedessen
00:53:49.670 --> 00:53:53.690
ist an sich hier der Rückschluss – ist
das die ursprüngliche Funktionalität
00:53:53.690 --> 00:53:59.170
oder nicht? – kaum noch feststellbar. Also
ja, es gibt Ansätze, aber nein, sie sind
00:53:59.170 --> 00:54:03.139
bei weitem noch nicht voll umfassend.
Frage: Danke!
00:54:03.139 --> 00:54:08.169
Herald: Schhhhhhh!
Mikro 4, bitte!
00:54:08.169 --> 00:54:14.139
Frage: Hallo hallo! Ich hätte die Frage:
wie sieht ganz operativ der Aufwand aus
00:54:14.139 --> 00:54:17.419
für einen – ich nenn’s mal
Maulwurfentwickler – der jetzt eine
00:54:17.419 --> 00:54:23.450
zusätzliche Maske reinbringen will. Wenn
ich mir vorstelle, dass die Lagen, die
00:54:23.450 --> 00:54:28.969
Oxide etc. die man da mittlerweile plant,
so dünn sind, dass wenn ich ’ne
00:54:28.969 --> 00:54:34.049
Zusatzstruktur in bestehende Layer
dazwischenschiebe, dass ich dann Shunts
00:54:34.049 --> 00:54:39.170
produziere etc. und wenn ich was nebenan
lege, also abseits des normalen
00:54:39.170 --> 00:54:42.750
footprints, dann passts beim Dicing nicht
mehr, dann fällt das auf, dass da einfach
00:54:42.750 --> 00:54:46.210
zusätzliche Pfade liegen,
wo eigentlich nix hingehört.
00:54:46.210 --> 00:54:50.960
Peter: hustet Entschuldigung. Ja, also,
als Antwort, vielleicht: das Schöne ist,
00:54:50.960 --> 00:54:55.460
bei der Vermeidung der Trojaner, dass je
weiter man in Bereich der Masken geht,
00:54:55.460 --> 00:55:00.069
dass es umso aufwändiger wird. Hatten wir
vorhin auch ansatzweise so dargestellt.
00:55:00.069 --> 00:55:04.309
Also wenn man gleich in den VHDL-Code das
einbringt, so eine Schad„soft“ware, so
00:55:04.309 --> 00:55:08.049
einen Trojaner, ist es relativ einfach.
Nachher wird’s immer schwerer. Und
00:55:08.049 --> 00:55:15.150
das Interessante ist da, dass man wirklich
Technologien vermeiden muss, wo es einfach
00:55:15.150 --> 00:55:19.729
wird, sozusagen diese Manipulation
durchzuführen. Z.B. denken wir mal an
00:55:19.729 --> 00:55:24.660
diese RAM-Zellen. Da ist es so, der
RAM-Zelle ist es eigentlich mehr oder
00:55:24.660 --> 00:55:30.699
weniger egal, ob der eine Treiber dieser
RAM-Zelle etwas stärker ist oder etwas
00:55:30.699 --> 00:55:35.700
weniger stark. Die funktionieren
normalerweise. D.h. wenn man jetzt z.B.
00:55:35.700 --> 00:55:39.140
diese physical unclonable functions
anwendet und aus diesen RAM-Zellen etwas
00:55:39.140 --> 00:55:44.109
ableitet, z.B. einen Schlüssel, dann wird
das nicht auffallen, wenn jemand das
00:55:44.109 --> 00:55:47.820
manipuliert hat. Wenn es allerdings eine
Funktionalität ist, auf die der Chip
00:55:47.820 --> 00:55:51.700
wirklich angewiesen ist, und die auf gar
keinen Fall schieflaufen darf, dann ist
00:55:51.700 --> 00:55:56.340
das viel schwerer. Und dementsprechend
ist es so, dass zunächst mal wichtig ist,
00:55:56.340 --> 00:56:02.250
alles rauszuwerfen, was sozusagen diesen
Backdoors Vorschub leistet. Und, ja, da
00:56:02.250 --> 00:56:07.000
hattest du völlig recht, also es ist in
der Tat schwierig, aber wenn die falschen
00:56:07.000 --> 00:56:11.129
Technologien verbaut sind, dann wird es
ziemlich einfach. Und das ist genau das
00:56:11.129 --> 00:56:13.559
Problem dabei.
00:56:13.559 --> 00:56:15.340
Herald: So, die Zeit ist leider knapp.
00:56:15.340 --> 00:56:19.159
Deshalb die letzte Frage
aus dem Internet, bitte.
00:56:19.159 --> 00:56:22.719
Signal Angel: Die Frage ist: Wurden schon
mal wirklich absichtlich eingebrachte
00:56:22.719 --> 00:56:26.729
Trojaner gefunden? Also nicht im Sinne von
Debug-Stelle ausnutzen oder JTAG
00:56:26.729 --> 00:56:31.249
ausnutzen? Und wurde das
auch explizit verwendet?
00:56:31.249 --> 00:56:34.990
Marcus: Es gibt in der Tat einige
Beispiele, wo insbesondere auch
00:56:34.990 --> 00:56:40.079
Zufallszahlengeneratoren, die in Hardware
ausgelegt worden sind, verändert worden
00:56:40.079 --> 00:56:44.470
sind und damit praktisch die Zufallszahlen
nicht mehr wirklich komplett zufällig
00:56:44.470 --> 00:56:49.039
waren sondern beeinflusst waren. Also –
ja, es gibt auch praktische Beispiele, wo
00:56:49.039 --> 00:56:52.419
Hardware-Trojaner eingesetzt worden sind.
00:56:52.419 --> 00:56:55.219
Signal Angel: Gibt’s dazu
auch einen Namen?
00:56:55.219 --> 00:56:58.879
Herald: grinst dämlich
– Eigentlich keine Dialoge!
00:56:58.879 --> 00:57:04.709
Deshalb, vielen Dank, ihr
könnt nochmal applaudieren!
00:57:04.709 --> 00:57:12.349
Applaus
00:57:12.349 --> 00:57:17.549
Abspannmusik
00:57:17.549 --> 00:57:23.041
Untertitel erstellt von c3subtitles.de
im Jahr 2016. Unterstütze uns!