KeyWe Smart Lock unauthorized access and traffic interception
Introduction
The KeyWe smart lock suffers from multiple design flaws resulting in an unauthenticated - potentially malicious - actor being able to intercept and decrypt traffic coming from a legitimate user. This traffic - as described below - can then be used to execute actions (such as opening/closing the lock, denial of service, silencing the lock etc.) on behalf of the owner.
An attacker could exploit this vulnerability by intercepting any legitimate communications to steal the key and unlock the door at any point remotely.
Communication messages between a legitimate application and the lock are transported using Bluetooth Low Energy. Before sending they are encrypted using AES-128-ECB with a random 2B (two-byte) prefix (functioning as a replacement for an Initialization Vector) thus disallowing a third party to easily eavesdrop and tamper with commands originating from the legitimate parties. The key generation process is, however, affected by a serious flaw.
Security of the messaging channel currently used by KeyWe relies on two factors:
- the common key used to initiate the key exchange
- the app/lock (door) key calculation process
F-Secure has proven that both of those constraints can be overcome. Firstly - the common key is created based on the device bluetooth MAC address available globally, making it trivial to decrypt the first stage of the negotiation. Secondly, the key generation process can be retrieved from the mobile application.
It should be noted that the application utilises obfuscation and root detection to protect users from threats targeting their devices. The whole solution, however, can be targeted by a determined attacker that can - and will - overcome such protections regardless of their number and/or quality.
A technical blog post detailing this vulnerability and other features of the lock has been published here.
Communication
Before using the lock, a device ought to be registered. The registration process consists of three phases:
- phase 1: setting the lock mode in order to check whether registration is needed
- phase 2: registering a password for the device - later on referred to as EKEY
- phase 3: verifying the EKEY value (authentication and authorisation)
Once the device successfully passes the authentication/authorisation step, additional operations - such as opening the lock, closing etc. - are allowed. Each of the aforementioned phases consists of several additional steps.
First, a common key - based on the device Bluetooth address - is calculated. Each side uses the calculated key - later referred to as comm - to encrypt an arbitrary 12B (twelve-byte) value that is then sent to the other side, as shown below:
app num
app --[comm(12B value)]-> door
door num
app <-[comm(12B value)]-- door
Once the numbers are exchanged, each side calculates keys for itself and the other counterpart:
door_key = make_door_key(app_num, door_num)
app_key = make_app_key(app_num, door_num)
The communication - referred to as a handshake - is then as follows:
app <-[ door(Hello) ]-- door
app --[ app(Welcome) ]-> door
app <-[ door(START) ]-- door
Once the handshake is over, additional messages follow - including the EKEY verification command.
Impact
Although the door/key generation is based on a custom algorithm, it can be retrieved - i.e. from the Android library - and reverse engineered at a relatively low cost. Thus, as long as the malicious attacker is in the effective range of around 15 meters, the traffic can be intercepted and decrypted similarly to the description provided above.
Traffic interception can be performed at a relatively low cost as well, as - for example - the nRF51822 chip able to sniff BLE communication can be bought at ~5$.
Once the EKEY value is retrieved, the attacker can perform any actions a legitimate user is able to. This is possible as long as the original application is registered to the device. Moreover, the EKEY value is saved online rendering changing the mobile device insufficient to overcome such an attack.
In the unlikely scenario of the device not being registered at all (utilising only the mechanical lock), a malicious actor is able to hijack the lock and operate it without any additional interaction. As the mechanical part is dependent on the servomechanisms steering the locking mechanism, this results in a full compromise as well.
Mitigation
There are no mitigations to the issue at the time of writing. The only way, although inconvenient for the end user, is to pair a mobile device that will be as far from the device as possible and use a physical key/touchpad only.