Mein Internet der Dinge: Guest Castle (Teil 2)

Hallo GT! Alles mit dem Kommen und der Vergangenheit!
Ich setze die Geschichte fort, wie ich das Türschloss mit dem Internet verbunden habe. Beginnen Sie hier .
Vielen Dank an alle für die Kommentare. Es gibt wirklich vorgefertigte Lösungen, aber es gibt auch eine Reihe von Nuancen, die es mir nicht erlaubt haben, sie zu verwenden. Eine Wohnung ist immer noch kein Hotel, daher entlassen wir spezialisierte Hotelburgen sofort. Schlüsselschlösser, Antennen für NFC, um die Nachbarn nicht zu erschrecken, berücksichtigen wir auch nicht. Es können auch keine Karten, Token oder andere physische Medien verwendet werden. Es versteht sich, dass es keine Möglichkeit gibt, diese an einen Gast zu übertragen, bevor er die Tür öffnet.
Kevo, August oder Lockitron konnten nicht verwendet werden, weil Sie basieren auf dem amerikanischen Schloss (Riegel), das an einer 65-70 mm dicken Stahltür nicht sehr gut installiert ist. Unsere Wahl ist das elektromechanische CISA für Panzertüren zum Preis von rund 500 Euro (noch nicht gekauft, weil teuer).
Und vor allem möchte ich etwas mit meinen eigenen Händen tun, nicht egoistisch sein, um Hobbyströmungen willen.


Ich möchte Sie daran erinnern, dass sich der Lock Controller tief hinter NAT im lokalen Heimnetzwerk befindet. Daher ist es nicht sinnvoll, den Webserver auf Arduin zu erhöhen. Es ist unmöglich, ihn über das Internet zu erreichen. Der Server wird in Python unter Verwendung des Twisted-Frameworks geschrieben, läuft unter Linux an einem anderen Ort, an dem eine echte IP-Adresse vorhanden ist, und der Controller stellt eine Verbindung dazu her und wartet auf Befehle.

Jetzt möchte ich über die Logik der Arbeit und der Kryptographie sprechen.
Ich habe nichts gefunden, das den Verkehr für Arduina verschlüsselt, da die Kommunikation zwischen Schloss und Server über offene Kanäle mit unverschlüsseltem Verkehr erfolgt.
Im ersten Prototyp habe ich MD5 verwendet, jetzt habe ich es in SHA-1 geändert, hier in dieser Cryptosuite- Bibliothek . Es verbraucht weniger Speicher und es gibt bereits eine vorgefertigte HMAC-Funktion.
Der Schlüssel ist ein Passwort mit bis zu 30 ASCII-Zeichen, das im EEPROM-Speicher des Controllers gespeichert ist.
Im ersten Prototyp wurde dasselbe Passwort explizit auf dem Server gespeichert, was natürlich keine Sicherheit darstellt. Der zweite Prototyp erforderte zwei Passwörter. Die erste besteht darin, die Sperre beim Herstellen einer Verbindung zum Server zu authentifizieren. Sie können die Sperre nicht mit diesem Kennwort öffnen. Sie wird benötigt, damit nur die richtigen Sperren eine Verbindung zum Server herstellen können.
Das Schloss stellt eine Verbindung zum Server her und teilt ihm zunächst seine Kennung mit. Der Server prüft in der Datenbank, ob eine solche Sperre vorliegt, und sendet als Antwort eine zufällig generierte ASCII-Sequenz. Das Schloss "signiert" es mit einem Passwort und sendet den Hash zurück. Der Server vergleicht den empfangenen Hash mit dem, was er selbst berechnet hat, und wenn er übereinstimmt, autorisiert er den verbundenen Controller als "Sperre".
Andernfalls wird die Verbindung zurückgesetzt.
Das zweite Passwort ist bereits ein digitaler Schlüssel und wird nicht auf dem Server gespeichert.
Es funktioniert wie folgt: Die Benutzeranwendung ruft über die SOAP-Funktion auf dem Server auf, gibt die ID der Sperre und den Befehl an, den sie ihm senden möchte. Infolgedessen gibt die Funktion die Anforderungs-ID zurück. Der Server leitet diesen Befehl an die Steuerung weiter, die Steuerung sendet als Antwort eine zufällig generierte ASCII-Sequenz und wartet einige Sekunden auf die „richtige“ Antwort. Als nächstes muss die Benutzeranwendung es vom Server über dieselbe SOAP per Anforderungs-ID abrufen, mit einem digitalen Schlüssel signieren und zurücksenden.
Der Controller vergleicht den empfangenen Hash mit dem berechneten selbst und führt bei Übereinstimmung den zuvor empfangenen Befehl aus, der dem Server gemeldet wird.
Die Zeit zur Bestätigung des Befehls ist auf 2 Sekunden begrenzt. Wenn während dieser Zeit keine Antwort empfangen wird, ignoriert die Steuerung den zuvor empfangenen Befehl. Wenn die Hashes nicht übereinstimmen, wird der Befehl ebenfalls ignoriert.
Daher versuche ich, mich vor dem Angriff „Mann in der Mitte“ zu schützen, der sehr einfach auf den Drähten meines Providers zu arrangieren ist. Die Verbindung ist dort einfach, keine Passwörter und Zertifikate, es reicht aus, das Twisted Pair im Shield zu schneiden, es auf beiden Seiten zusammenzudrücken, es von der Apartment-Seite mit der IP-Adresse des Befehlsservers in das Netzwerk einzustecken, die Sperre am anderen Ende zu emulieren (ich habe auch ein Skript zur Emulation auf dem Python zum Debuggen geschrieben ), nachdem eine solche "Firewall" mit Abhören angeordnet wurde.
In dieser Hinsicht erwies sich die Burg meiner Meinung nach als ziemlich geschützt.
Selbst das Hacken des Befehlsservers und das Stehlen seiner Datenbank mit Passwörtern zur Autorisierung durch die Sperre wird keine großen Probleme verursachen, da sie die Sperre nicht öffnen können.
Es bleibt nur mit den Gästen zu tun. Dies sind die Anforderungen Nr. 6-8 aus dem ersten Artikel.
Tastaturen, Proxys, RFID und NFC sind keine Option. Aber fast jeder hat ein Smartphone und alle Smartphones haben Bluetooth, die Wahl liegt auf der Hand!

Im ersten Prototyp wurde einem Gast ein einziger Zugangscode zugeordnet. In der Serverdatenbank für diesen Code wurden die ID der Sperre, das Datum und die Uhrzeit des Beginns und des Endes des Gastzugriffs sowie ein Textfeld für den vom Menschen lesbaren Namen des Gastes gespeichert.
Der Gast kommt zum Schloss, startet die mobile Anwendung auf seinem Smartphone, sendet einen Zugangscode über Bluetooth an den Controller, eine Nachricht vom Controller an den Server, die besagt, dass sich ein Gast mit einem solchen Zugangscode an ihn gewandt hat. Der Server vergleicht dies mit der Datenbank. Wenn der richtige Gast zur richtigen Zeit am richtigen Ort eingetroffen ist, sendet er den Befehl zum Öffnen der Sperre. Anstelle des eindeutigen Zugangscodes sendet der Gast einen HMAC-Hash, der mit einem „temporären Stempel“ signiert ist (eine Zeichenfolgendarstellung der Unix-Zeit geteilt durch 30, wobei der Bruchteil verworfen wird). Der Server zur Überprüfung sendet eine Anforderung an die Datenbank mit einer Auswahl aller derzeit gültigen Zugriffscodes für eine bestimmte Sperre, durchläuft diese dann und berechnet eine ähnliche HMAC für sie. Wenn er eine Übereinstimmung findet, sendet er einen Befehl zum Öffnen.Wenn die Suche nach Zugangscodes endet, bevor eine Übereinstimmung gefunden werden kann, wird beim Versuch, sie zu öffnen, eine negative Antwort an das Schloss gesendet.
Das Problem ist, dass der digitale Schlüssel für eine solche Autorisierung auf dem Server gespeichert werden musste.
Ich musste die "Gast" -Autorisierung für den zweiten Prototyp komplizieren. Der Gastzugangscode besteht jetzt aus zwei Schlüsseln. Nennen wir sie "Server" und "privat". Der Server wird benötigt, um ein Gastkonto auf dem Server einzurichten, und privat, um die Sperre selbst zu öffnen. Der Server wird explizit auf dem Server gespeichert, und vom privaten gibt es nur einen Hash, aber keinen einfachen, sondern einen HMAC mit einem digitalen Schlüssel für das Schloss.
Jetzt sieht die Gastautorisierungssitzung folgendermaßen aus:
1. Die Gastanwendung sendet den "Server" -Schlüssel an den Controller (wie im ersten Prototyp seinen Hash) und
2. Der Server überprüft ihn auf die gleiche Weise, aber anstelle des Befehls "Öffnen" wird der Hash des privaten Schlüssels gesendet
3. Der Controller vergleicht den Hash des vom Server empfangenen privaten Schlüssels mit dem unabhängig berechneten Hash. Wenn er übereinstimmt, wird die Sperre geöffnet.
Daher speichert der Server nichts, was die Sperre öffnen könnte. Es funktioniert nicht, den gewünschten Hash zu generieren, ohne den digitalen Schlüssel zu kennen.
Das gleiche Bluetooth wird auch für den Master-Zugriff ohne Internet verwendet. Der Controller empfängt Befehle über ihn und antwortet mit einem Einmalcode, der 2 Sekunden lang mit dem richtigen digitalen Schlüssel signiert werden muss.
Dadurch möchte ich die Grundeinstellungen des Controllers vornehmen. Der Eigentümer drückt eine spezielle Taste auf dem Controller. Danach akzeptiert er einen erweiterten Befehlssatz, z. B. das Festlegen der Sperr-ID, der geheimen Schlüssel, der Server-Port-Adresse, der Netzwerkeinstellungen usw. Aber in Adruin ging die Erinnerung aus und die Skizze passt nicht.
Am Ende eine kurze Demonstration der Arbeit.

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