Walk up to a door with an iPhone in your pocket and it unlocks. Walk away, it relocks. No app, no button, no Face ID.
That's Aliro, the CSA's digital key standard. openaliro is the lock side of it, running on easily available, inexpensive chipsets.
Real unlock, real hardware, live iPhone.
What works
| Capability | State |
|---|---|
| NFC tap unlock (Express Mode, no Face ID) | Working |
| Bluetooth auth + key agreement | Working |
| On-air ranging setup | Working |
| Secure UWB ranging | Working |
| Distance-gated unlock / relock | Working |
Approach unlock has been driven end to end against a live iPhone. No tagged release yet; everything is on main.
It started as a bug
NFC tap unlocked the door fine. Walking up to it did nothing.
Tap working is a useful clue: it means the Bluetooth transport, provisioning, and credentials are all healthy, so whatever was broken lived in the UWB ranging path. Chasing that one bug turned into reverse-engineering the whole approach-unlock exchange, which is now written up in the repo.
A few things I learned that surprised me:
- The whole conversation happens over Bluetooth. UWB never carries any application data. It exists purely to measure distance. Everything else, auth, setup, the unlock decision, rides on BLE.
- You can't replay it. Both sides work out the ranging key independently from the Bluetooth authentication. It never travels over the air, so you can record the radio all day and never open the door with a recording.
- The radio lies quietly. The setup handshake can report success while the radio stays completely silent. Every negotiated parameter gets folded into the ranging key, so if the two sides disagree on a single value, they derive different keys and simply never hear each other. A lot of this project was staring at a silent radio that insisted everything was fine.
The thing that finally broke it open: instead of trusting the Bluetooth clock sync to line up the listening window, the lock recovers its timing from the first packet of each exchange, which arrives in the clear. That's what turned "setup looks good, radio is dead" into live distance readings.
Why the hardware choice makes it hard
Most UWB projects use a module that does the ranging for you, hiding the radio behind a friendly API, and expensive cost of the chipset. This one runs on a bare Qorvo DW3110 with no UWB coprocessor. So the medium-access layer, the physical framing, the scrambled timestamp sequence that makes a distance measurement trustworthy, and the key schedule all run in firmware on the nRF5340's application core.
How it fits together
Hardware
| Part | Role |
|---|---|
| nRF5340 DK | Host SoC: BLE + Matter + ranging engine |
| DWM3000EVB (DW3110) | UWB radio, on the Arduino header |
| X-NUCLEO-NFC12A1 (ST25R300) | NFC reader for tap |
Three boards, off the shelf.
Credits
Thanks to Nordic Semiconductor for the nRF Connect SDK and door-lock add-on, @Bruno Randolf for the ISC DW3000 decadriver, and @kormax, @rednblkx, and @scottjg for ideas on ECP, HomeKey, and UWB chipsets.
Independent personal project, not affiliated with any vendor or standards body. Provided as is. Don't rely on it to secure anything of value.
Get Started
Full source code here.
Top comments (0)