Good old' mechanical locks

Mechanical locks are weak (1/4)

Lockpicking

Mechanical locks are weak (2/4)

Bumping

Mechanical locks are weak (3/4)

Impressioning

Mechanical locks are weak (4/4)

Decoding

Mechanical locks are old

• only a single key to lock or unlock
• you give access to someone by giving a copy of your key
• sometimes difficult to get the duplicate key back 😠
• change your lock if you lost your keys

It's time to evolve !

Credential dematerialization

Credential dematerialization 101

• No more physical keys, they are now data
• Easy to create, assign and revoke keys
• Easy to send a key to someone
• One lock, multiple keys !

Dematerialized keys

Dematerialization may save our lives

• Rent your flat with AirBnB and send keys to tenants
• Give access to your flat to your maid between specific hours
• Revoke keys if lost or no longer needed

Smartlocks for smart folks

Connected locks wanted

• Ability to communicate wirelessly with a smartphone
• Ability to adapt to any doors and locking systems
• Easy to use

Well, almost connected ...

• Your smartphone acts like a proxy
• Bluetooth Low-energy
• WiFi would drain the batteries

Technical challenges

• Avoid sniffing and replay
• Keys are data, they might be stolen more easily
• What happens in case of power outage ?
• Third-party service hacked, keys leaked !

Time to meet my smartlock

My sweet smartlock

• Model sold in the US and the EU
• Allows NFC tags and dematerialized keys
• Communicates over Bluetooth Low Energy with a smartphone
• Keys, authorizations and users managed in the Cloud

How it works

• A CC2540 chip is in charge of handling BLE stuff
• A STM32F103 microcontroller contains the logic
• Dedicated apps allow the user to interact
• One may swipe left or right to lock or unlock

STM32F103 - Contains logic

CC2540 - Handles BTLE

SWD Interface - Debugging

Actuator - Open/Close the lock

Actuator gears

What could possibly go wrong ?

GATT server

• BLE exposes services through a GATT server
• Each service provides one or more characteristics
• Characteristics may be R/W accessed
• A notification mechanism is provided to save power

Communicating through characteristics

• Only store a limited amount of data
• Communication is asynchronous
• Vendors implement their own protocol

Securing the communication channel

• Sniffing is easy, with affordable tools
• Communications between the smartlock and smartphone MUST be encrypted

Sniffing BLE communications

• using a dedicated hardware (Ubertooth, Adafruit's BLE Sniffer)
• by patching smali code if an Android app is available

Ubertooth

• Cost: ~100$
• Works under Windows/Linux/Mac

Adafruit's BLE Sniffer

• Cost: ~30$
• Works under Windows/Linux/Mac

Sniffing with Adafruit's BLE Sniffer

• The provided sniffer (Python) produces a pcap file
• The sniffer adds a custom wrapping layer
• Provided wireshark dissector requires some fixes
• I had to develop some Python classes to make scapy support this format

Sniffing reliability issues

• Sniffing is not as reliable as expected
• Smali patching saves a loooooot of time
• Modify callbacks/methods to add debugging through java.util.Log
• Difficult when dealing with obfuscated applications

Reverse-engineering the protocol

• My smartlock uses two layers:
• A transport layer, providing a way to send synchronous streams of bytes
• An application layer, providing information to the device

Transport protocol

• Trail flag (0x1)
• Segment flag (0x2)
• Maximum data length: 19 bytes

Application protocol

• Provides acknowledgements through BLE notifications
• Every packet need to be acknowledged
• Implements a synchronous communication channel over BLE

First blood

• The event log is transmitted in cleartext over BLE
• No authentication required !
• One may get the whole event log in less than a minute
• Practical way to get someone's week schedule

Demo time

*No fail please*

Encrypt- What ?

• Luckily, when it comes to send keys, everything is encrypted
• Application data is 20-byte long (with 1-byte operation code)
  
  

  48 B9 38 57 69 BE 31 12 61 61 6E 40 AD AF 37 7B 3E F6 1E 55 C3

  
  
• Uh, wait, what cipher is that to produce 20 bytes of encrypted data ?

Let's fuzz a bit ...

• No idea of what the data is
• Starting to fuzz one byte at a time from a valid key ...
• ... and the lock eventually opened !

And suddenly, I was like

Demo time

*Don't call me chicken*

Extra bytes ?

• Bruteforcing the first two bytes of the key make the lock open after some attempts
• Vendor says this lock uses AES encryption
• Encrypted data length should be a multiple of 16
• So, 4 extra bytes added at the start ?

Worst crypto ever

[07/08/2015 14:45:19] lock opened by ffff02
[07/08/2015 13:01:34] manual operation by ffff02
[07/08/2015 13:01:30] manual operation by ffff02
[07/08/2015 13:00:09] lock closed by 1
[07/08/2015 12:56:54] lock opened by 480001
[07/08/2015 12:56:42] lock closed by 1
[07/08/2015 12:56:04] lock opened by 1
[07/08/2015 12:55:27] lock closed by 1
[07/08/2015 10:37:17] lock opened by c0001
[07/08/2015 10:37:08] error 8004 occured by 830001
												

• Moreover, MSBs of user id (1) changed in the event log
• Are they using .... XOR ?
• Could also because of the AES/CBC and padding combination (padding oracle), but only a guess.

Blue Man in the Middle

• The android app does not authenticate the smartlock
• Easy to create a fake one with a computer and a BT 4.0 adapter
• No need to knock the device out, it's an easy race
• Sami Kamkar's RollJam style

Demo time

*Great Scott !!*

Undocumented commands

• Having a deeper look at the code showed a special command
  
• Just tried to send some bytes with that command
• Smartlock completely stuck, draining battery

Demo time

*Iä, Iä, Cthulhu fhtagn*

Possible attack scenarios

Scenario #1

Capture and replay a key

• BLE sniffing is not very reliable
• The attacker has to be close to the smartlock
• Leaves some traces in the entry log ...

Scenario #2

Blue Man in the Middle

• Mocking a device is reliable
• Our mocked device almost always win the race
• No traces left on the device

Scenario #3

Rage against the smartlock

DoS the smartlock and drain batteries, bitch.

Conclusion

My sweet pwn3d Smartlock

• Sends the entry log in cleartext to anyone asking for it
• Undocumented features may cause a DoS
• Encryption is a complete fail
• The smartapp does not correctly authenticate the smartlock
• Few traces left by an attacker

Responsible disclosure

• Vendor has been notified in March 2015
• No answer since then, even when contacted by CERT-FR

Bluetooth LE related tools

• Cost <= 100$
• Sniffing is reliable in a controlled environment
• Bleno.js is the way to mock devices
• Bluepy is perfect to communicate with devices
• Expect custom protocols and hours of reverse-engineering !

What about hardware attacks ?

• Firmware is read-protected (STM32 security mechanism)
• I tried to bypass it through glitching, and failed
• I managed to dump the RAM, but no keys in there
• Not skilled enough to get the firmware, I'm afraid