Open architecture
The protocol, the firmware and the server side are open. You are not tied to a single supplier: the system works offline, can be audited and, if you need it to, runs on your own infrastructure.
What is already done
- »An open protocol done
Full specifications BLE and socket — byte-level layout, the cryptography and test vectors to check your own implementation against. You build it on your board from the documentation, with nothing to reverse engineer. - »Reference firmware, MIT licensed done
ESP32, ESP8266, Raspberry Pi and Node.js — working code for both sides, ready to take and port. - »BLE works with no server at all done
Opening runs straight from phone to controller over Bluetooth, with no internet and no call to our server. Controllers ship empty and are bound locally. - »The server never sees your keys and cannot forge a signed opening done
Commands are signed on the phone and the server only relays them. A guest key travels in an envelope whose key never passes through the server. The signature is checked by a Bluetooth lock, by an ESP32 network controller bound to the owner's phone and by the owner's phone itself before it places a call or sends a webhook, so the server cannot open these on its own (see below). - »Device provisioning for production done
Devices are produced in batches belonging to nobody; the buyer binds them with the code on the case.
The trust model — what the server can and cannot do
Openings are signed on the client (end-to-end encrypted) and the secrets are encrypted around the server. Hence:
| The server CANNOT | The server can |
|---|---|
| read your keys (the guest key, the owner secret) | deny service (be unavailable) |
| forge an opening where the lock, the controller or the owner's phone checks the signature | see metadata: who, what, when, and IP addresses |
| escalate its own privileges | open what trusts it: a webhook sent from the server, controllers on ESP8266, Raspberry Pi or Node.js |
So where the lock, the controller or the owner's phone checks the signature, the server — ours or your own — only affects availability. Bluetooth locks, an ESP32 network controller bound to the owner's phone, and calls and webhooks sent from the owner's phone work this way. A webhook sent from the server and the simple controllers on ESP8266, Raspberry Pi and Node.js trust the server: it holds the address or the connection and can send an opening itself. Run the server yourself and you hide the metadata as well.
A controller that works over the internet holds its own connection to the server, so the server sees the controller’s IP address and the time of each command sent to it. Only the ESP32 network controller bound to the owner’s phone checks the signature of every command; the others act on what the server sends.
The reference firmware checks the server certificate, so nobody on the same network can pose as the server.
Roadmap
- ●Stage 1 — any host in the app done
The app can be pointed at your own Entrixy server: connections and the guest links it generates go there. A guest who opens a link from another server connects to that server automatically. - ●Stage 2 — the server as a distribution done
A Docker image of the server side: the WebSocket server, the database schema and instructions. Availability is then in your hands and our outages do not touch you. - ○Stage 3 — open source for the app planned
So the client can be audited and rebuilt by anyone — complete independence from someone else's infrastructure and from app stores.
Who this is for
Makers of barriers, locks, intercoms and controllers who need their product to keep working independently of us rather than depend on one company. And anyone building a controller themselves who wants to stay independent of a single supplier. To discuss integration and OEM terms, write to hello@entrixy.com. Protocols: BLE, socket. Reference code and configurator: controllers.