Open, Sesame! On the Security of Electronic Locks David Oswald - - PowerPoint PPT Presentation

open sesame
SMART_READER_LITE
LIVE PREVIEW

Open, Sesame! On the Security of Electronic Locks David Oswald - - PowerPoint PPT Presentation

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 Kppers Gregor


slide-1
SLIDE 1

Open, Sesame!

David Oswald (david.oswald@rub.de) Ruhr-Uni Bochum / Kasper & Oswald

On the Security of Electronic Locks

slide-2
SLIDE 2

2

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
slide-3
SLIDE 3

3

Ruhr-University Bochum: beautiful.

slide-4
SLIDE 4

5

(The life of) a typical pirate

Pegleg Eye patch Pirate hat Pirate laughter

slide-5
SLIDE 5

6

slide-6
SLIDE 6

7

???

slide-7
SLIDE 7

8

„Opening“ doors – LEVEL 1

slide-8
SLIDE 8

9

slide-9
SLIDE 9

14

Opening doors – LEVEL 2

slide-10
SLIDE 10

15

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 ...
slide-11
SLIDE 11

16

Clone on Blank Card Fails (wrong UID)

Wrong UID

slide-12
SLIDE 12

17

  • Chameleon emulates everything including UID
  • Open source project:

https://github.com/emsec/ChameleonMini

  • Buy / Kickstarter info:

http://kasper-oswald.de/gb/chameleonmini

slide-13
SLIDE 13

18

Succeeds

(emulates everything including UID) Quite old prototype, was actually stolen …

slide-14
SLIDE 14

19

slide-15
SLIDE 15

20

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 …
slide-16
SLIDE 16

22

Opening doors – LEVEL 3

slide-17
SLIDE 17

23

Electronic Locking System

Token Lock

slide-18
SLIDE 18

27

Reverse-Engineering (1)

Black-box analysis: Token and lock perform authentication protocol

Token Lock

Authentication protocol

???

slide-19
SLIDE 19

28

Lock Token

Reverse-Engineering (2)

slide-20
SLIDE 20

30

Lock

Embedded code?

Read-out protection!

Token

Reverse-Engineering (3)

slide-21
SLIDE 21

31

Decapping an IC (1)

slide-22
SLIDE 22

32

Decapping an IC (2)

slide-23
SLIDE 23

33

Decapping an IC (3)

slide-24
SLIDE 24

34

Decapping an IC (4)

slide-25
SLIDE 25

35

Microscopic View of the Silicon Die

slide-26
SLIDE 26

36

Exposure to UV-C: Disable Read-Out Protection (1)

slide-27
SLIDE 27

37

Exposure to UV-C: Disable Read-Out Protection

slide-28
SLIDE 28

38

Exposure to UV-C: Why it works

slide-29
SLIDE 29

39

Reverse-Engineering continued

  • Use standard programmer
  • Reverse-Engineer (e.g., IDA)

 all internals known

slide-30
SLIDE 30

40

Challenge C

88 32 32 24 32 80

Key derivation

KT IDL IDT D

Compute KT = SKL(IDT, D)

KL

Both: RKT(C, D, IDT, IDL) = RT || RL

Response RT (verify RL) Response RL (verify RT)

slide-31
SLIDE 31

41

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
slide-32
SLIDE 32

42

Challenge C

88 32 32 24 32 80

KT IDL IDT D

Compute KT = SKL(IDT, D)

KL

Both: RKT(C, D, IDT, IDL) = RT || RL

Response RT (verify RL) Response RL (verify RT)

Authentication

slide-33
SLIDE 33

43

𝑱𝑬𝑼 𝑬 𝑳𝑴

O*

64

DES*

1..64

O

65..128 128 128 128 128

O

128 128 64 128

O

DES*

1..64 65..128 128

𝒂𝑺 𝒂𝑻

Cryptographic Functions R and S

IDL IDT D C RT || RL KT

slide-34
SLIDE 34

44

𝑱𝑬𝑼 𝑬 𝑳𝑴

O*

64

DES*

1..64

O

65..128 128 128 128 128

O

128 128 64 128

O

DES*

1..64 65..128 128

𝒂𝑻

Cryptographic Functions R and S

IDL IDT D C RT || RL KT

slide-35
SLIDE 35

45

𝑳𝑴

O*

64

DES*

1..64

O

65..128 128 128 128 128

O

128 128 64 128

O

DES*

1..64 65..128 128

𝒂𝑻

Cryptographic Functions R and S

IDL IDT D C RT || RL KT IDT D

slide-36
SLIDE 36

46

O*

64

DES*

1..64

O

65..128 128 128 128 128

O

128 128 64 128

O

DES*

1..64 65..128 128

Cryptographic Functions R and S

IDL IDT D C RT || RL KT IDT D KL

slide-37
SLIDE 37

47

O*

64

DES*

1..64

O

65..128 128 128 128 128

O

128 128 64 128

O

DES*

1..64 65..128 128

Cryptographic Functions R and S: Security Vulnerabilities

RT || RL KT IDT D IDL IDT D C ZR KL 40 bit of ZR used as C in next run 128 bit from 64 bit entropy ... O has „bad“ cryptographic properties

slide-38
SLIDE 38

48 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

Consequence: Wireless Lock-only Attack

  • Initate some, not successful protocol runs
  • Compute KT (for known IDT)
slide-39
SLIDE 39

49

  • Initate some, not successful protocol runs
  • Compute KT (for known IDT)

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

Consequence: Wireless Lock-only Attack

Improve Report flaws

slide-40
SLIDE 40

50

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)

slide-41
SLIDE 41

Responsible Disclosure

When pirates do good ...

slide-42
SLIDE 42

53

slide-43
SLIDE 43

54

By RedAndr, Wikimedia Commons

slide-44
SLIDE 44

55

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

slide-45
SLIDE 45

56

Countermeasures

slide-46
SLIDE 46

57

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

slide-47
SLIDE 47

58

Live Demo

„Everything that can go wrong, will go wrong“

slide-48
SLIDE 48

59

Expect the unexpected.

slide-49
SLIDE 49

Thanks!

Questions now?

  • r later:

david.oswald@rub.de @sublevado