Angriffsziel Embedded-Systems

Transcription

Kompaktseminar
Angriffsziel
Embedded-Systems
Der Referent
2001 – 2007 Doc und Postdoc
→ Algebraische Geometrie
2007 – 2013 Evaluator im Prüflabor von T-Systems
→ Untersuchung von Chips nach Common
Criteria und Pay-TV-Kriterien
→ Untersuchung von PINpads nach PCI Kriterien
→ Untersuchung von TAN-Verfahren
→ Untersuchung von Funkprotokollen
→ Sicherheitskonzept für Qivicon
Seit 2014
SEGRIDS
2/126
Dienstleistung
Beratung in Chip- und Embedded Security
● Sicherheitsarchitektur und -design
● Analysen und Tests
● Low-Level-Implementierung
● Härtung
● Dokumentation für Zertifizierung
● Zertifizierungsmanagement
3/126
Seminarziele
Mit welchen Angriffen müssen Sie rechnen?
Warum funktionieren die Angriffe?
Was Können Sie dagegen tun?
4/126
Inhalt
0. Übersicht über Angriffsmethoden
1. Reverse HW Engineering (Wegfahrsperre)
2. Seitenkanalanalyse (Chipkarte)
3. Fault Injection (System on a Chip)
4. Jailbreak (iPhone)
5. Man-in-the-Middle (EMV-Zahlung)
5/126
Zeitplan
9:00 – 10:30
10:30 – 11:00
11:00 – 12:30
12:30 – 13:30
13:30 – 15:30
6/126
Reverse HW Engineering
Seitenkanalanalyse I
Kaffepause
Seitenkanalanalyse II
Fault Injection
Mittagessen
Jailbreaks
Man-in-the-middle
Übersicht
Kapitel 0:
Übersicht über Angriffsmethoden
7/126
Übersicht
Sortieren Angriffe nach dem innersten verletzten
elektronischen oder mechanischen Schutzring.
Wie weit gelangt der Angreifer physikalisch an den
Kern?
8/126
Übersicht
9/126
Beispiel: PINpad
Welt
OBI
Display
eth
PINpad
HSM
ROM
Kartenleser
HSM
USB
RAM
Prozessor
JTAG
VCC
Prozessor
Flash
Copro
I/O
Tastatur
10/126
Slot
Übersicht
Ring Schnittstellen Angriffe
WAN
DSL, WLAN
Gerät
USB, Karten-Slot,
Tasten, Display
HSM
JTAG Ports, SensorSignale, SpeicherBusse, I/O, VCC
Chip
Strahlung
Die
Signale auf Die,
Sichtbarkeit der
Gatter
11/126
Unzählige Exploit
Kapitel
Heute mal kein
Thema
Jailbreak, Man-in-themiddle, Buffer Overflows
Kapitel 4
Power Glitches, Power
Analysis, Probing von I/OSignalen, JTAG Exploits
Kapitel 3
Seitenkanalanalyse, Laser
Fault Injection, EM Fault
Injection
Probing-Angriffe, Reverse
HW Engineering
Kapitel 2
Kapitel 1
Kapitel 1:
12/126
Angriffsschritte für Reverse IC Engineering:
1. Delayering
2. Analyse der Gatterstruktur
3. Analse der Verdrahtung
13/126
1. Delayering
● Die Frei ätzen (Flusssäure oder Azeton)
● Metal top fotografieren
● Metal top wegpolieren
●
…
● Metal 1 fotografieren
● Metal 1 wegpolieren
● Substrat fotografieren (>200nm: Optisches Mikroskop
<200nm: Elektronenmikroskop)
14/126
2. Analyse der Gatterstruktur
● Gattertypen identifizieren (es gibt 70
verschiedene)
● Gatter per Software den Typen zuordnen
● Auffällige Strukturen suchen, z.B.
Lange Flipflop-Reihen => Shiftregister
Viele XOR-Gatter => Kryptoengine
15/126
3. Analyse der Verdrahtung
● Verdrahtung für interessante Strukturen
nachvollziehen
● Schwierigkeit: Man benötigt viele Fotos von jeder
Lage, da Abschleifen nur lokal die Layer respektiert
16/126
Alternative Semi-invasive Methode:
„Backside Infrared Imaging“
Angriff von Substrat-Seite, IR-Licht geht da durch
● Auflösung: ca. 600nm
● Analyse am laufenden Chip
●
17/126
Referenz:
[1] http://events.ccc.de/congress/2008/Fahrplan/attachments/
1218_081227.25C3.HardwareReversing.pdf
[2] https://www.cl.cam.ac.uk/~sps32/ECRYPT2011_1.pdf
18/126
Seitenkanalanalyse
Kapitel 2:
Seitenkanalanalyse
19/126
Seitenkanalanalyse
Motiv:
Ermitteln der Prozessoraktivität über Messung der
Leistungsaufnahme oder der Elektromagnetischen
Abstrahlung (EM)
● EM ist feiner: welche Regionen sind aktiv?
● Im Einzel-Trace zu unterscheiden:
→ Rechenintensive Operationen
→ eventuell Muster
→ Leerlauf
→ Cache- / Speicher-Zugriff
20/126
Seitenkanalanalyse
EMA-Messung mit Nahfeldsonde (Spule mit ca. 5
Windungen),
Foto: http://www.langer-emv.de/produkt/e/set-sx/
21/126
Seitenkanalanalyse
Analyse für Angriffe nutzen:
● Räumliche Analyse für Reverse Engineering
● Timing-Analyse z.B. für Reverse Engineering
● Glitch-Zeitpunkt bestimmen für Fault Injection
● Kryptoanalyse: Welche geheimen Schlüssel
verwendet der Prozessor?
22/126
Seitenkanalanalyse
Wie kann Angreifer aus Signalen geheime
Schlüssel ermitteln?
SPA = Simple Power Analysis
DPA = Differential Power Analysis
SEMA = Simple Electo-Magnetic radiation Analysis
DEMA = Differential Electo-Magnetic radiation Analysis
Häufig: „SPA“ statt „SEMA“, „DPA“ statt „DEMA“
23/126
SPA / DPA
Signale werden mit Oszilloskop während der
Kryptooperation gesampelt
● Bandbreite (Samplerate) Oszilloskop >> Taktrate
● Typische Sampleraten:
2 GS/s für Chipkarte
20 GS/s für SoC
● Schwierigkeit:
Startpunkt der Verschlüsselung im
Signal finden
●
24/126
SPA /DPA Aufbau
25/126
SPA
Beispiel: RSA Decryption (Signatur)
● Schlüsselpaar (SK,PK) und Modulus N
● Ciphertext: X
●
Operation: dec(X) = XSK mod N
● Exponentiation per Square and Multiply
SK = b2048* 22048 + … + b0* 20
26/126
Square and Multiply R-Code
Berechnung von XSK, wo SK = b2048* 22048 + b0* 20:
> XtotheBitseq
function(X,b){
N = length(b)1
y = 1
for (i in N:0 ){
y = y^2
if (b[i+1] == 1){
y = y * X
}
}
return( y )
}
27/126
SPA Übung
SK per SPA angreifbar, sofern Square von Multiply
im Einzel-Trace zu unterscheiden ist.
Übung: Aus folgendem Trace-Ausschnitt die SKbits b11 … b0 ermitteln:
28/126
SPA Übung
29/126
SPA Gegenmaßnahmen
SK per SPA angreifbar, sofern Square von Multiply
im Einzel-Trace zu unterscheiden ist.
Zur Diskussion: Wie lässt sich der Angriff
verhindern?
30/126
DPA
Schaden groß bei globalen symmetrische
Schlüsseln:
● PayTV: Broadcasting verschlüsselter Streams
● Funknetzwerke in Industrie 4.0, Home Automation:
Funkmodule mit globalen Default-Schlüsseln
● iPhone: globaler GID Key
● KeeLoq: globaler Master Key
31/126
DPA Gegenmaßnahmen
Unzählige Fachartikel und Patente zu DPAGegenmaßnahmen. Bausteine:
● Maskierung von Zwischenwerten mit zufälligen
Masken
● Künstlicher Jitter
● Zusätzliche Dummy DES/AES – Runden mit
zufälligem Input
● Künstliches Rauschen
Nachweise zur DPA-Resistenz häufig Unfug
32/126
Beispiel DPA Contest
DPA Contest als methodischer Fortschritt gegenüber
Publikationen mit selbstbewerteten DPAGegenmaßnahmen:
● Unabhängige Kryptoanalytiker greifen eine
vorgeschlagene Implementierung an.
● Wettbewerb zwischen teilnehmenden Instituten
erzeugt hohen Einsatz (Angriffspotential).
● Bester Beitrag liefert reelle Bewertung der
Implementierung.
33/126
Bislang waren DPA Gegenmaßnahmen für Contest
nur schwach:
Version
Jahr
Anzahl
Gewinner
benötigter
Messungen
Land
v1
2008/09 141
Université de
Limoges
Frankreich
v2
2010/11 7061
Thales
Communications
Frankreich
v3
2011/12 800
Yokohama
Universität Japan
Japan
v4.1
2013/14 1
SEGRIDS
Deutschland
Typisch für Sicherheitschips > 1.000.000 Messungen
34/126
DPA Contest v4.1
AES mit DPA-Gegenmaßnahme basierend auf
Maskierung.
● Eine 4 bit-Zufallszahl pro Verschlüsselung
bestimmt die Maskierung.
● Aufgabe: Ermitteln des AES Key aus Messungen
● Messen macht der Veranstalter:
http://www.dpacontest.org/v4/rsm_doc.php
●
35/126
Zum Üben: 100.000 Messungen
(Klartext, Key, Zufallszahl, Trace)
● Messungen für Exploitphase:
(Klartext, Trace)
● Die
Zufallszahl ist per Template-Angriff aus
jeder Einzelmessung zu ermitteln.
● Damit fällt die Gegenmaßnahme zusammen.
●
Lernziel:
Prinzip des Template-Angriffs (ist nicht schwer!)
36/126
Bitte vollständig ausblenden: AES, Key, Klartext
● Greifen statt Key (16 Byte) jetzt nur Zufallszahl
(4 bit) an.
● Haben zum üben 100.000 Messungen
(Zufallszahl, Trace)
● Müssen anschließend zu einer Messung
(?, Trace)
die zugehörige Zufallszahl finden.
●
37/126
Können ein Paar (Zufallszahl, Trace) graphisch
darstellen, wenn wir den 16 Zufallszahlen eindeutig
Farben zuordnen:
38/126
Profiling Messung 1
39/126
Profiling Messung 2
40/126
Profiling Messung 3
41/126
Profiling Messung 4
42/126
Traces sind lang: 400.035 Samplepunkte
● Erstes Ziel: Einschränkung auf interessantes
Gebiet.
● Wo gibt es ein Farb-Leck, d.h. wo ist die TraceForm stark von der Farbe abhängig?
●
Vorschläge?
43/126
Sei M die Menge aller 100.000 traces zum Üben.
Var := Varianz(M)
beinhaltet Rauschen und Signal.
Kennen für trace in M die Farbe col(trace).
Betrachten für jede Farbe:
MFarbe := { trace in M | col(trace) = Farbe}
mean(Farbe) := mean( MFarbe) “Template“
Var(Farbe) := Varianz( MFarbe )
44/126
Betrachten das (über alle Farben gemittelte)
Rauschen:
Noise = Mean {Var(Farbe)| Farbe=rot, gelb, …}
Jeder Zeitpunkt t mit
Noise(t) << Var(t)
ist interessant.
45/126
Var / Noise
46/126
Var / Noise
47/126
Var / Noise
48/126
Schränken alle Traces auf Samplepunkte t ein, wo
Var(t) / Noise(t) > 4.
Reduzierung von 400035 auf 705 Punkte.
49/126
Prisma-Effekt
300 Messungen (Übungsphase) eingeschränkt auf Gebiet mit starkem Farb-Leck.
50/126
Erkennbar: Starke Abhängigkeit der Form von der
Farbe.
Frage: Ist für Einzeltrace die Farbe aus der Form zu
ermitteln?
Vorschläge?
51/126
ermitteln?
Versuch 1: Legen Einzeltrace über das Bild.
52/126
Messung 10000
53/126
Messung 10100
54/126
ermitteln?
→ Klappt nicht eindeutig.
Versuch 2: Legen Einzeltrace über Templates
{Mean(Farbe)| Farbe= schwarz, rot, … }
55/126
Templates
56/126
Messung 10000
57/126
Messung 10100
58/126
ermitteln?
Versuch 2: Legen Einzeltrace über Templates
{Mean(Farbe)| Farbe= schwarz, rot, … }
59/126
ermitteln?
Versuch 3: Abstand zu Templates ermitteln
Template mit minimalem Abstand liefert die Farbe des
Einzeltraces
Was ist die geeignete Metrik???
Naiver Ansatz: Euklidische Metrik liefert Trefferquote
von ca 90%
60/126
Das geht noch besser (99,95%):
●
Suchen Richtungen im Raum R705 der
eingeschränkten Traces mit optimalem SignalRausch-Verhältnis SNR:
● Wenden Transformation W an, die das Rauschen
Kugelförmig macht („Pre-Whitening“ / „RauschOrthogonalisierung“).
● Dann bilden die 16 Farb-Templates die Zentren von
16 Kugelförmigen Punktwolken im R705
● Die Templates bilden auch Wolke aus 16 Punkten.
● Das optimale SNR ist genau in der Richtung, der
maximalen Ausdehnung der 16-Punktwolke.
61/126
Transformation Messung 555
62/126
63/126
64/126
65/126
66/126
67/126
68/126
69/126
70/126
71/126
Referenz zu den Plots und Skripten:
R Core Team (2012). R: A language and environment
for statistical computing. R Foundation for Statistical
Computing, Vienna, Austria. ISBN 3-900051-07-0,
URL http://www.R-project.org/.
72/126
Fault Injection
Kapitel 3:
Fault Injection
73/126
Fault Injection
Angriff auf Ring 2 (HSM) oder Ring 1 (Chip)
● Ring 2 - Methoden: Spannungspulse, EM-Pulse
● Ring 1 - Methoden: EM-Pulse, Laserpulse
● Ziele: Programmfluss stören, Privilegien erhöhen,
Ports öffnen
●
74/126
Fault Injection
Was passiert physikalisch ?
75/126
Elektrotechnik
76/126
Elektrotechnik
77/126
Elektrotechnik
SRAM-Zelle
Ein kurzer Spannungspuls kann das Bit kippen.
● Beim regulären Kippen fließt kurz ein hoher Strom.
● Wenn sich das Bit nicht ändert, fließt fast kein
Strom.
●
78/126
Elektrotechnik
D-Latch (1 bit Register)
Wenn E (Enable / Clock) auf low: Bistabile
Kippstufe aus zwei NOT-Gattern
● Anfälligkeit für Glitches wie bei SRAM-Zelle
●
79/126
Fault Injection
Power oder EM-Glitches schlagen galvanisch /
induktiv / kapazitiv bis zu Kippstufen in SRAMZellen oder Registern durch.
● Dadurch ändern sich ggf. einige Bits.
● Das ermöglicht viele Exploits.
● Als „Proof of Concept“ folgt ein Experiment.
●
80/126
Experiment
Glitch-Generator von Conrad
Piezo-Zündelement 15 kV
SUPI V01
81/126
Experiment
8 bit – Register: 74HC/HCT573 (Philips)
82/126
Experiment
Konfigurieren die Eingänge D0,..., D7 per
Schalter / Pull-Down beliebig.
● Die Ausgänge Q , …, Q sind mit LEDs
0
7
verbunden.
● Die Ausgänge bleiben permanent enabled (OE
auf GND).
● Disablen die Eingänge nach der gewünschten
Konfiguration (LE auf +5V).
● Erzeugen 15kV Spannungspulse mit dem
Piezzo-Zündelement.
● Was passiert?
●
83/126
Experiment: Latchen
84/126
Experiment: Glitchen
85/126
Experiment: Resultat
86/126
Beobachtung
Die D-Latches lassen sich per Glitch verwürfeln.
Einige Zellen sind leichter zu kippen als andere.
87/126
Glitch-Angriffe
Speicher und Register sind ähnlich.
● Sensible Speicher / Register-Inhalte:
Program Counter PC
Link Register LR
Gerettete Register auf Stack
ARM CP15 M[3:0]
Zustandsregister von Debug-Ports
Alle möglichen Flags
● Beispiel: Angriff auf Secure Boot
●
88/126
Beispiel
89/126
Beispiel
Boot-Sequenz Sicherheitsprozessor:
BootROM
SP Code
Boot-Sequenz Anwendungsprozessor:
LLB
(Low Level Bootloader)
Next Stage
OS
1. BootROM liest SP Code aus internem Flash in Secure
RAM, prüft Signatur, führt aus.
2. SP Code liest LLB aus externem Speicher oder Interface
ins Secure RAM, prüft Signatur, kopiert in AP's RAM und
startet AP.
3. LLB liest Next Stage aus externem Speicher, prüft
Signatur ...
90/126
Beispiel
Angriffsziel ist der Sicherheitsprozessor.
● Methode: Störung des PC (oder LR oder callArgument oder jmp-Argument) per Glitch
mittels ESD Simulator (25 kV)
● Ersetzen LLB Code (Anwendungsprozessor)
durch SP Payload.
● Glitch während SP den LLB lädt, vor
Signaturprüfung
● Wenn ein geeignetes bit im PC kippt, springt
SP in Payload.
● Automatisierter Angriff führt nach ca. 8
Stunden und 2000 Glitchen zum Erfolg.
●
91/126
Beispiel
Pseudo-Code des Exploit-Skripts:
Wiederhole 1 Woche lang:
Triggere Reset.
Sende Payload als „LLB Image“ über SW UpdateSchnittstelle. Warte 1 Sekunde.
Wiederhole 5 mal:
Triggere Glitch.
Warte 100 ms.
Prüfe, ob Payload läuft.
Falls ja, stoppe Skript.
92/126
Diskussionsrunde
Wie wäre der Angriff per Hardware zu verhindern?
Ist der Angriff per Software zu verhindern?
Harvard-Architektur
ARM: enable MPU
Ist prinzipiell ein Angriff auf den Program Counter per Software zu
verhindern?
93/126
Fault Injection per Power / EM
Résumé
● Per Power-/ EM-Glitches lassen sich örtlich
ungezielt Bits kippen.
● Power oder EM-Glitches schlagen galvanisch /
induktiv / kapazitiv bis zu Kippstufen in SRAMZellen oder Registern durch.
● Die erforderliche Hardware ist billig.
● Exploits erfordern zusätzliche Schritte, z.B.
Reverse Engineering, insb. Timing-Analysen.
● Für nicht speziell gehärtete Chips ist die
Methode stark.
● Moderne Sicherheitschips lassen sich damit
meistens nicht mehr angreifen.
94/126
Fault Injection per Laser-Puls
Gezieltes Kippen von Registern und SRAM geht
auch, ist allerdings teurer: Laser oder
Doppellaser
95/126
Fault Injection - Gegenmaßnahmen
Hardware-Schutzmassnahmen:
● „Replication“, z.B. mit „Triple Modular
Redundancy“; Wichtig: „Voting“-Schaltkreise
ebenfalls härten.
● Checksummen
96/126
Fault Injection - Gegenmaßnahmen
Software-Schutzmassnahmen:
● Checksummen
● Execution-Randomisierung
● Execution-Redundanz
● Fehler-Erkennung durch zusätzliche
Berechnungen
97/126
Buffer Overflow
Kapitel 4: Jailbreaks
98/126
Jailbreaks
Targets:
iPhone, iPad, Apple TV
Ziel:
Laden unauthentisierter SW
Angreifer:
Jailbreak-Spezialisten (Identifikation)
Eigentümer des Geräts (Ausnutzung)
Schaden für Apple:
<100 Euro pro gebrochenem Gerät
Nutzen für Apple:
Erweitert den Kundenkreis
Garantie fällt weg
99/126
Jailbreak versus Hactivation
Hactivation:
● schaltet SIM-Karte frei
● ist genau dann möglich, wenn Bootrom-Exploit
existiert
● ist nicht mehr so relevant: ab iOS 7.1 kein
SIM-Lock mehr
100/126
Jailbreaks
Schutz der Software durch:
● Verschlüsselung
● Signatur
101/126
Jailbreaks
Boot-Sequenz:
Ab iPhone 3GS: Jede Komponente prüft die
Signatur und entschlüsselt das Image der
nächsten.
102/126
Jailbreaks
Boot-Sequenz:
Drei Software Update Modi:
Modus
DFU Mode
Recovery Mode
post boot
103/126
Boot Status
BootROM
iBoot
iOS
Schnittstelle
USB
USB
USB / Netz
Jailbreaks - Historie
iPhone
1
3G
3GS
Jahr
2007
2008
2009
iOS
1.0.0 – 3.1.3
2.0 – 4.2.1
3.0 – 6.1.6
Hauptprozessor Bootrom Exploits
Jailbreaks
S5L8900
Pwnage
Pwnage 2.0
S5L8900
Pwnage
Pwnage 2.0
S5L8920
0x24000 Segment Overflow
Limera1n
blackra1n
BootNeuter
redsn0w
4
2010
4.0 – 8.1
S5L8930
Limera1n
SHAtter
4s
2011
5.0 – 8.1
S5L8940
%
Geeksn0w
Greenpois0n
Absinthe
Pangu
%
evasi0n7
Pangu
%
evasi0n7
Pangu
5
5s
2012
2013
6.0 – 8.1
7.0 – 8.1
S5L8950
S5L8960
5c
2013
7.0 – 8.1
S5L8950
%
evasi0n7
Pangu
6
2014
8.0 – 8.1
T7000
%
Pangu8
6
2014
8.0 – 8.1
T7000
%
Pangu8
104/126
Jailbreaks mit BootROM Exploit
Bootrom-Exploit bringt BootROM zur Ausführung
eines unsignierten Payloads
Ein kompletter Jailbreak erfordert zusätzlich:
● LLB im Klartext auslesen und Signaturprüfung für
iBoot eliminieren
● iBoot im Klartext auslesen und Signaturprüfung für
iOS eliminieren
● LLB patch und iBoot patch ins Flash schreiben
Der BootROM-Exploit macht das alles möglich!
105/126
BootROM Exploit
Beispiel für BootROM Exploit:
0x24000 Segment-Overflow
●
●
●
●
Target: iPhone 3GS
Methode: Buffer-Overflow
Schwachstelle: BootROM prüft nicht ob LLB Image in Puffer
passt
Gefunden von: chronic, CPICH, ius, MuscleNerd, Planetbeing,
pod2g, posixninja, et al.
106/126
BootROM Ablauf
0x22000000
0x22024000
Puffer für (verschlüsselten) LLB
BSS
Heap
Stack
SRAM Start
BootROM
● kopiert (verschl.) LLB Image vom Flash in Puffer
● Im DFU Mode: Image von USB-Schnittstelle
● Triggert Berechnung von SHA1(LLB Code)
● Prüft, ob Signatur korrekt, d.h. ob
RSA_enc(ROM-Key, Signatur) == SHA1(verschl. LLB CODE)
● Entschlüsselt LLB Code
● Springt in LLB Code
107/126
Exploit Grundlage
●
●
●
●
SHA1 per Hardware
BSS enthält Adresse des 64 Byte SHA1 Engine Input
Registers
0x20024000 Segment Overflow nutzt fehlenden GrößenCheck, um diese Adresse zu verändern
Sprungbrett, um im nächsten Schritt eine Rücksprungadresse
im Stack zu verändern
108/126
BootROM - Pseudocode
WriteLLBImage2Buffer(){
//Fehlende Prüfung der Image-Größe
...
//Exploit: Überschreiben der Adresse des
//Sha1 Input Registers
}
doSha1(Puffer){
Sha1 = <64 Byte Initialwert>
for Block in Puffer{
sha1 = sha1 ^ Digest(Block)
}
return (sha1)
}
Digest(Block){
WriteSha1Input(Block) //Adresse aus BSS (!)
TriggerSha1Engine()
return(ReadSha1Output()) }
109/126
Jailbreak LLB Image
0x22024000
LLB DATA
LLB Image Buffer
doSha1 LR
Adr SHA1Eng
Reguläres Image
0x22000000
BSS
Stack
SHA1 Buffer
0x14
110/126
Payload
0x2202FE38
doSha1 LR
LLB DATA
0x22023000
0x2202FE24
0x22023000
Jailbreak Image
Heap
Jailbreak - Ablauf
●
●
●
●
●
Bauen LLB Jailbreak Image
Versetzen iPhone 3GS in DFU Mode und senden das Jailbreak
Image per USB-Kabel (DFU Protokoll).
WriteLLBImage2Buffer( ) schreibt das Exploit Image ins SRAM.
Die Input-Adresse der SHA1 Engine wird mit 0x2002FE24
überschrieben. Das ist 0x14 Bytes vor der Stackposition, an welcher
später die Rücksprungsadresse zu doSha1 gerettet wird.
DoSha1( ) ruft in der for-Schleife Digest(Block) auf, wobei
Block = SHA1 Buffer [0:63]
●
●
Vor Digest( ) wird dar PC (R15) von DoSha1 ins LR (R14) kopiert.
An Stelle 0x14 des Blocks steht 0x20030000, die Startadresse des
Payloads.
111/126
Jailbreak - Ablauf
●
●
Digest( ) ruft WriteSha1Input( ) auf
Zuerst werden die Register gerettet,
Rücksprungadresse zu doSha1 verschoben:
dabei
wird
die
R14 → 0x2002FE38
●
Digest( ) sucht die (überschriebene) SHA1 Engine Input Adresse in
BSS und kopiert den Block dahin.
Dabei wird die Rücksprungadresse zu doSHA1( ) mit der
Startadresse von Payload überschrieben.
●
Nach dem return( ) von Digest( ), startet jetzt Payload.
112/126
Untethered Jailbreak
Möglichkeiten des Payloads:
● Nutzung der Hardware AES-Engine und ihrer
Keys (GID Key, UID Key)
● Verschlüsseln / Entschlüsseln von Images
● Flashen von Images
● „Tethered Jailbreak“ (bisher) zum „Untethered
Jailbreak“ machen
113/126
Jailbreaks - Referenzen
[1] http://theiphonewiki.com/wiki/25C3_presentation_
%22Hacking_the_iPhone%22
[2] https://code.google.com/p/chronicdev/wiki/Bootrom
114/126
Schwache Protokolle
Kapitel 5:
Schwache Protokolle Beispiel EMV-Zahlung
115/126
Schwächen im EMV-Protokoll
Beispiel: Bezahlung mit Chipkarte
Verfahren: EMV offline
Teilnehmer:
● Karteninhaber
● Chipkarte (VISA Card mit DDA)
● Terminal
● Kassierer
Daten:
● PAN
● Betrag
116/126
Authentifizierung
Authetifizierung:
Wer? authentifiziert was? wie? gegenüber
wem?
117/126
Schwächen im EMV-Protokoll
Authetifizierung:
Wer? authentifiziert was? wie? gegenüber wem?
118/126
wer
was
wie
wem
Terminal
sich
nicht
Kunde
Kunde
sich
Besitz der
Chipkarte
Kassierer
Terminal
sich
nicht
Chipkarte
Chipkarte
sich
DDA
Terminal
Kunde
sich
PIN
Chipkarte
Chipkarte
Kunde
„9000“
Terminal
Chipkarte
Betrag
AC
Terminal
Chipkarte authentifiziert sich nicht gegenüber Kunde.
„Schuhkarton-Angriff“ ist immer möglich.
Täter: Aufsteller des Schuhkartons
● Bei bedienten Geräten ist der Kassierer
der erste Verdächtige.
● Keine Transaktion kommt zustande.
●
119/126
Chipkarte authentifiziert sich per DDA gegenüber Terminal.
120/126
Kunde authentifiziert sich per PIN gegenüber Chipkarte.
121/126
Chipkarte authentifiziert Kunden per 9000 gegenüber Terminal.
122/126
Man-in-the-midlle Angriff
Die 9000er Nachricht („PIN OK“) ist nicht signiert.
Man-in-the-middle-Angriff möglich.
● Täter: Karten-Dieb
● Geschädigter: OBI
● Angriff 2010 von Ross Anderson veröffentlicht
● War schon vorher bekannt.
●
123/126
Chipkarte authentifiziert Kunden per 9000 gegenüber Terminal.
Übung: Zeichnen Sie ein Kommunikationsdiagramm
für den beschriebenen Angriff.
124/126
Chipkarte authentifiziert Betrag per AC gegenüber Terminal.
Terminal erkennt falschen MAC nicht.
125/126
Verbesserung bei CDA-Unterstützung
Terminal erkennt falsche Signatur.
126/126

Angriffsziel Embedded-Systems

Transcription

Similar documents

2011-2013 - Horst Görtz Institut für IT-Sicherheit - Ruhr

gibt es den Artikel zum Nachlesen.