Open, Sesame! On the Security of Electronic Locks David Oswald (david.oswald@rub.de) Ruhr-Uni Bochum / Kasper & Oswald
No, I did not do all this stuff alone Christof Paar Timo Kasper Benedikt Driessen Simon Küppers Gregor Leander Amir Moradi Ingo von Maurich Falk Schellenberg Daehyun Strobel 2
Ruhr-University Bochum: beautiful. 3
(The life of) a typical pirate Pirate hat Eye patch Pegleg Pirate laughter 5
6
??? 7
„Opening“ doors – LEVEL 1 8
9
Opening doors – LEVEL 2 14
Access Control System Mifare Classic cards unlock doors and elevators Secret keys are default (0xA0A1A2A3A4A5) Identification by UID and 1st block of 1st sector UID usually not changeable ... 15
Clone on Blank Card Fails (wrong UID) Wrong UID 16
Chameleon emulates everything including UID Open source project: https://github.com/emsec/ChameleonMini Buy / Kickstarter info: http://kasper-oswald.de/gb/chameleonmini 17
Succeeds (emulates everything including UID) Quite old prototype, was actually stolen … 18
19
Level 2: Summary Many locks still use UID only (from 125 kHz to DESFire EV1…) Mifare Ultralight (no crypto) e.g. used for hotel rooms Mifare Classic (broken in 2009) still wide-spread Backwards compatibility & mixed systems … 20
Opening doors – LEVEL 3 22
Electronic Locking System Lock Token 23
Reverse-Engineering (1) Black-box analysis: Token and lock perform authentication protocol Authentication Lock Token protocol ??? 27
Reverse-Engineering (2) Lock Token 28
Reverse-Engineering (3) Embedded code? Lock Token Read-out protection! 30
Decapping an IC (1) 31
Decapping an IC (2) 32
Decapping an IC (3) 33
Decapping an IC (4) 34
Microscopic View of the Silicon Die 35
Exposure to UV-C: Disable Read-Out Protection (1) 36
Exposure to UV-C: Disable Read-Out Protection 37
Exposure to UV-C: Why it works 38
Reverse-Engineering continued • Use standard programmer • Reverse-Engineer (e.g., IDA) all internals known 39
K T K L 24 ID L 32 ID T Key derivation 88 Challenge C 80 D Compute K T = S KL (ID T , D) Both: R KT (C, D, ID T , ID L ) = R T || R L 32 Response R T Response R L 32 (verify R L ) (verify R T ) 40
Weaknesses and Attacks (1) Each lock stores installation-wide cryptographic key UV-C attack in ~ 30 min (decap PIC) Side-channel attack in ~ 15 min (access to PIC) Attacking one lock gives access to all doors 41
K T K L 24 ID L 32 ID T 88 Challenge C Authentication 80 D Compute K T = S KL (ID T , D) Both: R KT (C, D, ID T , ID L ) = R T || R L 32 Response R T Response R L 32 (verify R L ) (verify R T ) 42
Cryptographic Functions R and S ID L ID T 128 D 128 1..64 64 O O DES * R T || R L C 𝒂 𝑺 128 128 65..128 K T 𝑱𝑬 𝑼 128 1..64 64 128 O * O DES * 𝑬 𝒂 𝑻 𝑳 𝑴 65..128 128 128 43
Cryptographic Functions R and S ID L ID T 128 D 128 1..64 64 O O DES * R T || R L C 128 128 65..128 K T 𝑱𝑬 𝑼 128 1..64 64 128 O * O DES * 𝑬 𝒂 𝑻 𝑳 𝑴 65..128 128 128 44
Cryptographic Functions R and S ID L ID T 128 D 128 1..64 64 O O DES * R T || R L C 128 128 65..128 K T ID T 128 1..64 64 128 O * O DES * D 𝒂 𝑻 𝑳 𝑴 65..128 128 128 45
Cryptographic Functions R and S ID L ID T 128 D 128 1..64 64 O O DES * R T || R L C 128 128 65..128 K T ID T 128 1..64 64 128 O * O DES * D K L 65..128 128 128 46
Cryptographic Functions R and S: Security Vulnerabilities 40 bit of Z R used as C ID L in next run ID T 128 D 128 1..64 64 O O DES * R T || R L C Z R 128 128 65..128 128 bit from 64 bit entropy ... O has „ bad “ cryptographic K T ID T 128 1..64 64 128 properties O * O DES * D K L 65..128 128 128 47
Consequence: Wireless Lock-only Attack • Initate some, not successful protocol runs • Compute K T (for known ID T ) Protocol Runs Run-Time Key Candidates 3 3,36 min 21,34 4 11,5 s 1 5 1,2 s 1 6 650 ms 1 48
Consequence: Wireless Lock-only Attack • Initate some, not successful protocol runs • Compute K T (for known ID T ) Protocol Runs Run-Time Key Candidates Report flaws 3 3,36 min 21,34 4 11,5 s 1 Improve 5 1,2 s 1 6 650 ms 1 49
Level 3: Management Summary Attacker can gain full access to any door Reasons for security flaws – Insecure hardware – Proprietary cryptography – „Bad“ system design Can the system be „ saved “? – Cryptanalytical attacks: Firmware update (cheap) – HW attacks: Require replacing all devices (expensive) 50
Responsible Disclosure When pirates do good ...
53
54 By RedAndr, Wikimedia Commons
Responsible Disclosure Locking system: – Vendor informed ~ 1 year before – Discussion of found flaws – Deployed patch to fix mathematical attacks Other examples: – Altera FPGAs: Informed ~ 6 months before – Yubikey : Informed ~ 9 months before 55
Countermeasures 56
Countermeasures Implementation attacks: Practical threat, but: First line of defense: Classical countermeasures – Secure hardware (certified devices) – Algorithmic level Second line of defense: System level – Detect : Shadow accounts, logging – Minimize impact (where possible): Key diversification 57
Live Demo „ Everything that can go wrong, will go wrong “ 58
Expect the unexpected. 59
Thanks! Questions now? or later: david.oswald@rub.de @sublevado
Recommend
More recommend
