Mon Internet des objets: Guest Castle (Partie 2)

Salut GT! Le tout avec le futur et le passé!
Je continue l'histoire de la façon dont j'ai connecté la serrure de porte à Internet. Commencez ici .
Un grand merci à tous pour les commentaires. Il y a vraiment des solutions toutes faites, mais il y a aussi un certain nombre de nuances qui ne m'ont pas permis de les utiliser. Un appartement n'est toujours pas un hôtel, nous rejetons donc immédiatement les châteaux spécialisés. Serrures à clé, antennes pour NFC, afin de ne pas effrayer les voisins, nous n'envisageons pas non plus. Aucune carte, jeton ou autre support physique ne peut être utilisé non plus, il est entendu qu'il n'y a aucun moyen de les transférer à un invité avant qu'il n'ouvre la porte.
Kevo, August ou Lockitron ne pouvaient pas être utilisés, car ils sont basés sur le type américain de serrure (pêne dormant), qui n'est pas très bien installé sur une porte en acier de 65 à 70 mm d'épaisseur. Notre choix est le CISA électromécanique pour portes blindées, au prix d'environ 500 euros (pas encore acheté, car cher).
Et surtout, je veux faire quelque chose de mes propres mains, ne pas être égoïste au nom des courants de loisir.


Permettez-moi de vous rappeler que le contrôleur de verrouillage est situé profondément derrière NAT dans le réseau domestique local, et donc cela n'a aucun sens d'élever un serveur Web sur Arduin; il n'y a aucun moyen de l'atteindre depuis Internet. Le serveur est écrit en Python en utilisant le framework Twisted, fonctionne sous Linux dans un autre endroit où il y a une vraie adresse IP, et le contrôleur s'y connecte et attend les commandes.

Maintenant, je veux parler de la logique du travail et de la cryptographie.
Je n'ai pas trouvé de trafic crypté pour Arduina, car les communications du château et du serveur passeront par des canaux ouverts avec du trafic non crypté.
Dans le premier prototype, j'ai utilisé MD5, maintenant je l'ai changé en SHA-1, ici sur cette bibliothèque Cryptosuite . Il consomme moins de mémoire et il existe déjà une fonction HMAC prête à l'emploi.
La clé est un mot de passe de 30 caractères ASCII maximum, stocké dans la mémoire EEPROM du contrôleur.
Dans le premier prototype, le même mot de passe était stocké explicitement sur le serveur, ce qui n'est bien sûr pas de sécurité. Le deuxième prototype nécessitait deux mots de passe. La première consiste à authentifier le verrou lors de la connexion au serveur, vous ne pouvez pas ouvrir le verrou avec ce mot de passe, il est nécessaire pour que seuls les verrous corrects puissent se connecter au serveur.
Le verrou se connecte au serveur et lui indique tout d'abord son identifiant. Le serveur vérifie dans la base de données s'il existe un tel verrou et, le cas échéant, il envoie une séquence ASCII générée de manière aléatoire en réponse. Le verrou le «signe» avec un mot de passe et renvoie le hachage. Le serveur compare le hachage reçu avec ce qu'il a calculé par lui-même, et s'il correspond, il autorisera le contrôleur connecté en tant que «verrou».
Sinon, la connexion est réinitialisée.
Le deuxième mot de passe est déjà une clé numérique, il n'est pas stocké sur le serveur.
Il fonctionne comme suit: l'application utilisateur appelle via la fonction SOAP sur le serveur, indique l'ID du verrou et la commande qu'il souhaite lui envoyer. Par conséquent, la fonction renvoie l'ID de demande. Le serveur transmet cette commande au contrôleur, le contrôleur envoie une séquence ASCII générée aléatoirement en réponse et attend la réponse «correcte» pendant quelques secondes. Ensuite, l'application utilisateur doit l'obtenir du serveur, via le même SOAP par ID de demande, la signer avec une clé numérique et la renvoyer.
Le contrôleur compare le hachage reçu avec celui calculé de lui-même et s'ils correspondent, il exécute la commande précédemment reçue, qui est signalée au serveur.
Le temps pour confirmer la commande est limité à 2 secondes, si aucune réponse n'est reçue pendant ce temps, le contrôleur ignore la commande reçue précédemment. Si les hachages ne correspondent pas, la commande est également ignorée.
Ainsi, j'essaie de me protéger de l'attaque de «l'homme au milieu», qui est très facile à agencer sur les fils de mon fournisseur. La connexion y est simple, pas de mots de passe et de certificats, il suffit de couper la paire torsadée dans le bouclier, de la serrer des deux côtés, de la brancher sur le réseau depuis l'appartement avec l'adresse IP du serveur de commande, d'émuler le verrou de l'autre côté (j'ai également écrit un script d'émulation sur le python pour le débogage ), après avoir organisé un tel «pare-feu» avec écoute électronique.
À cet égard, à mon avis, le château s'est avéré être assez protégé.
Même le piratage du serveur de commandes et le vol de sa base de données avec des mots de passe pour l'autorisation par le verrou ne feront pas beaucoup de problèmes, car ils ne peuvent pas ouvrir le verrou.
Il ne reste plus qu'à s'occuper des invités. Ce sont les exigences n ° 6-8 du premier article.
Les claviers, les proxys, la RFID et le NFC ne sont pas une option, ce qui précède a expliqué pourquoi. Mais presque tout le monde a un smartphone et tous les smartphones ont Bluetooth, le choix est évident!

Dans le premier prototype, un invité était associé à un seul code d'accès. Dans la base de données du serveur pour ce code ont été stockés l'ID du verrou, la date et l'heure du début et de la fin de l'accès invité, ainsi, un champ de texte pour le nom lisible par l'homme de l'invité.
Un invité s'approche de la serrure, lance une application mobile sur son smartphone, il envoie un code d'accès via Bluetooth au contrôleur, un message arrive du contrôleur au serveur indiquant qu'un invité l'a approché avec un certain code d'accès. Le serveur le vérifie par rapport à la base de données, et si le bon invité est arrivé au bon moment au bon endroit, envoie la commande pour ouvrir le verrou. En fait, au lieu du code d'accès clair, l'invité enverra un hachage HMAC signé avec un «timbre temporaire» (une représentation sous forme de chaîne du temps Unix divisé par 30 avec la partie fractionnaire supprimée). Le serveur de vérification fait une demande à la base de données avec une sélection de tous les codes d'accès actuellement valides pour un verrou donné, puis l'itère et calcule un HMAC similaire pour eux, s'il trouve une correspondance, envoie une commande pour ouvrir,si la recherche des codes d'accès se termine avant qu'une correspondance ne puisse être trouvée, une réponse négative est envoyée au verrou lors d'une tentative d'ouverture.
Le problème est que la clé numérique d'une telle autorisation devait être stockée sur le serveur.
J'ai dû compliquer l'autorisation "invité" pour le deuxième prototype. Le code d'accès invité se compose désormais de deux clés, appelons-les «serveur» et «privé». Le serveur est nécessaire pour établir un compte invité sur le serveur et privé pour ouvrir le verrou lui-même. La salle des serveurs sera explicitement stockée sur le serveur, et à partir de la salle privée, il n'y aura qu'un hachage, mais pas un simple, mais un HMAC avec une clé numérique pour la serrure.
Maintenant, la session d'autorisation d'invité ressemble à ceci:
1. L'application invitée passe la clé «serveur» au contrôleur (comme dans le premier prototype son hachage) et
2. Le serveur le vérifie de la même manière, mais au lieu de la commande open envoie le hachage de la clé privée
3. Le contrôleur compare le hachage de la clé privée reçue du serveur avec celle calculée indépendamment et si elle correspond, le verrou s'ouvre.
Ainsi, le serveur ne stocke rien qui pourrait ouvrir le verrou. Il ne fonctionnera pas pour générer le hachage souhaité sans connaître la clé numérique.
Le même Bluetooth est également utilisé pour l'accès «maître» sans Internet. Le contrôleur reçoit des commandes à travers lui, répond avec un code à usage unique, qui doit être signé avec la bonne clé numérique pendant 2 secondes.
Grâce à lui, je veux faire les réglages de base du contrôleur. Le propriétaire appuie sur un bouton spécial du contrôleur, après quoi il commence à accepter un ensemble étendu de commandes, telles que la définition de l'ID de verrouillage, les clés secrètes, l'adresse du port du serveur, les paramètres réseau, etc. Mais à Adruin, la mémoire s'est épuisée et le croquis ne correspond pas.
À la fin, une courte démonstration du travail.

Source: https://habr.com/ru/post/fr382677/