Architecture ouverte
Le protocole, le micrologiciel et la partie serveur sont ouverts. Vous n'êtes pas lié à un fournisseur unique : le système fonctionne hors ligne, peut être audité et, si besoin, tourne sur votre propre infrastructure.
Ce qui est déjà fait
- »Un protocole ouvert fait
Spécifications complètes BLE et socket — disposition au niveau de l'octet, la cryptographie et vecteurs de test pour confronter votre propre implémentation. Vous la réalisez sur votre carte à partir de la documentation, sans rien à rétro-concevoir. - »Micrologiciel de référence sous licence MIT fait
ESP32, ESP8266, Raspberry Pi et Node.js — du code qui fonctionne des deux côtés, prêt à reprendre et à porter. - »Le BLE fonctionne sans aucun serveur fait
L'ouverture va directement du téléphone au contrôleur par Bluetooth, sans internet ni appel à notre serveur. Les contrôleurs sont livrés vides et se lient en local. - »Le serveur ne voit jamais vos clés et ne peut pas forger une ouverture signée fait
Les commandes sont signées sur le téléphone et le serveur ne fait que les relayer. Une clé d'invité voyage dans une enveloppe dont la clé ne passe jamais par le serveur. La signature est vérifiée par la serrure Bluetooth, par le contrôleur réseau ESP32 lié au téléphone du propriétaire et par le téléphone du propriétaire lui-même avant d'appeler ou d'envoyer un webhook : le serveur ne peut donc pas les ouvrir de lui-même (voir plus bas). - »Provisionnement des appareils pour la production fait
Les appareils sont produits par lots n'appartenant à personne ; l'acheteur les lie avec le code figurant sur le boîtier.
Le modèle de confiance — ce que le serveur peut et ne peut pas faire
Les ouvertures sont signées sur le client (chiffrement de bout en bout) et les secrets passent chiffrés à côté du serveur. D'où :
| Le serveur NE PEUT PAS | Le serveur peut |
|---|---|
| lire vos clés (la clé d'invité, le secret du propriétaire) | refuser le service (être indisponible) |
| forger une ouverture là où la serrure, le contrôleur ou le téléphone du propriétaire vérifie la signature | voir les métadonnées : qui, quoi, quand, et les adresses IP |
| élever ses propres privilèges | ouvrir ce qui lui fait confiance : un webhook envoyé depuis le serveur, des contrôleurs sur ESP8266, Raspberry Pi ou Node.js |
Ainsi, là où la serrure, le contrôleur ou le téléphone du propriétaire vérifie la signature, le serveur — le nôtre ou le vôtre — n'influe que sur la disponibilité. C'est le cas des serrures Bluetooth, du contrôleur réseau ESP32 lié au téléphone du propriétaire, ainsi que des appels et des webhooks envoyés par le téléphone du propriétaire. Un webhook envoyé depuis le serveur et les contrôleurs simples sur ESP8266, Raspberry Pi et Node.js font confiance au serveur : il détient l'adresse ou la connexion et peut envoyer une ouverture lui-même. Hébergez le serveur vous-même et vous masquez aussi les métadonnées.
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.
Le firmware de référence vérifie le certificat du serveur : personne sur le même réseau ne peut se faire passer pour le serveur.
Feuille de route
- ●Étape 1 — n'importe quel hôte dans l'application fait
L'application peut être pointée vers votre propre serveur Entrixy : les connexions et les liens d'invité qu'elle génère y aboutissent. Un invité qui ouvre un lien issu d'un autre serveur s'y connecte automatiquement. - ●Étape 2 — le serveur sous forme de distribution fait
Une image Docker de la partie serveur : le serveur WebSocket, le schéma de base de données et la notice. La disponibilité est alors entre vos mains et nos pannes ne vous touchent pas. - ○Étape 3 — code source ouvert pour l'application prévu
Pour que le client puisse être audité et recompilé par n'importe qui — une indépendance totale vis-à-vis d'une infrastructure tierce et des boutiques d'applications.
À qui cela s'adresse
Les fabricants de barrières, serrures, interphones et contrôleurs dont le produit doit continuer de fonctionner indépendamment de nous plutôt que de dépendre d'une seule entreprise. Et tous ceux qui fabriquent eux-mêmes un contrôleur et veulent rester indépendants d'un fournisseur unique. Pour discuter intégration et conditions OEM, écrivez à hello@entrixy.com. Protocoles : BLE, socket. Code de référence et configurateur : contrôleurs.