Keys ?
Where we're going, we don't need keys.

Damien Cauquil / @virtualabs

Who am I ?

  • Head of Research @Sysdream
  • Various security related fields:
    • Reverse-engineering
    • Electronics
    • Lockpicking
    • Coding

Just a few things

  • I will show only one lock
  • I cannot name the vendor, for some *obvious* reasons
  • Here comes the minion lock !


  • Good old' mechanical locks
  • Credential dematerialization
  • Smartlocks for smart folks
  • What could possibly go wrong ?
  • Conclusion

Good old' mechanical locks

Mechanical locks are weak (1/4)


Mechanical locks are weak (2/4)


Mechanical locks are weak (3/4)


Mechanical locks are weak (4/4)


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 dongle image
  • Cost: ~100$
  • Works under Windows/Linux/Mac

Adafruit's BLE Sniffer

Adafruit's BLE Sniffer image
  • 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.


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

Questions ?

and maybe answers 😏