❮ Contrôleurs Entrixy

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.

Qui bâtit un produit ou une activité sur Entrixy a besoin de plus qu'une promesse de fiabilité — il lui faut une garantie inscrite dans le système lui-même : un protocole ouvert avec des vecteurs de test, une ouverture qui fonctionne sans notre serveur, et une partie serveur que l'on peut déployer soi-même. L'indépendance vient de la conception, pas des assurances.

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 rien ouvrir à votre place 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 transite jamais par le serveur. Même un serveur compromis ne peut rien faire (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 l'ouverture d'un portail	voir les métadonnées : qui, quoi, quand, et les adresses IP
élever ses propres privilèges	—

Le serveur — le nôtre ou le vôtre — n'influe donc que sur la disponibilité : il ne peut rien ouvrir en votre nom. Hébergez-le vous-même et vous masquez aussi les métadonnées.

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 prévu
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.