Reverse Engineering Linear DX Wireless Door Locks

Employees at the network data security company Duo recently had their interest piqued when they discovered that their office’s keycard based door system had a wireless remote which was used by reception to unlock and lock the door. The device was a DX model magnetic lock created by Linear.

After noting down the FCC ID printed on the device, they determined that the operating frequency was 315 MHz. They discovered from the documentation that each wireless DX device is encoded with a unique code that is precoded at the factory. Only remotes with the correct code programmed in can open the door.

The first attack they tried was a simple replay attack. They used a HackRF to record the signal, and then play it back again. This worked perfectly first time.

Next they decided to take this further and reverse engineer the protocol and see if a brute force attack could be applied. By doing some logic analysis on the circuit, they were able to figure out how to iterate over the entire key space. It turns out that the lock can be brute forced in at most 14.5 hours, or 7.25 hours on average.

The Linear DX Wireless Door Lock
The Linear DX Wireless Door Lock
Subscribe
Notify of
guest

1 Comment
Inline Feedbacks
View all comments
Drone

Being so vulnerable to a simple replay attack is a sign that the manufacturer is either poorly educated, lazy, or both. I expect this kind of shoddy design in a five dollar device bought on ebaY. Not from a manufacturer that seems to be based in Carlsbad, CA (from the FCC ID anyway).

A simple replay mitigation that works for even half-duplex channels is for the transmitter to send a pseudo-random nonce generated using a key that is pre-shared with the receiver. The receiver validates the nonce then saves it in a dictionary. All subsequent nonces received that are already in the dictionary are rejected thereby defeating any replay attempts. Thoughtful selection of entropy size, dictionary depth, and retry delay time makes the system hard to brute-force attack, and keeps the self collision probability low. Bottom line: A successful attacker would need the pre-shared key; replay attempts are essentially futile.

The security and UI subsystems should be quite easy to host on a modern “popcorn” micro-controller (e.g., ARM Cortex-M0 based, or a TI MSP430). No frequent flash memory writes would be needed during operation as the pre-shared key protects the dictionary initialization.

What I describ is a half-duplex system. Full duplex systems are even more robust when it comes to thwarting replay attacks because they can share session tokens and/or sequence numbers as well.