Unser aktuelles Schlosssystem funktioniert, ist aber schon etwas in die Jahre gekommen. Es basiert auf Bluetooth Pairings. Beim Pairen von zwei Bluetooth Geräten wird ein kryptografischer Schlüssel ausgetauscht. Diesen verwenden wir zur Authentifizierung beim Schlosssystem.

Das System funktioniert gut, ist aber Prinzipbedingt recht langsam. Die gespeicherten Bluetooth Pairings werden der Reihe nach durchprobiert, wobei jedes ein paar Sekunden dauert. Der letzte in der Liste wartet ggf. ein paar Minuten bis sich das Schloss öffnet.

Nebst schnellerer Reaktion soll das neue System auch weitere Vorteile bieten. Welche das aber sind und wie wir das umsetzen, gilt es hier auszuarbeiten.

• Einmalschlüssel für Dienstleister wie z.B. Getränkelieferanten, Reinigung von extern.
  • Das bei Licht eingeschaltete WLAN könnte offen sein. Ein Lieferant könnte sein beliebiges Smartphone damit verbinden. Das WLAN würde ihn dann auf ein Captive Portal weiterleiten. Darauf würde er zur Eingabe eines vorher mitgeteilten Einmal-Codes aufgefordert. Dieser würde das Schloss direkt öffnen. Der Code bliebe dann z.B. noch für eine halbe Stunde gültig und erlischt dann automatisch. So könnten wir den Zeitraum für die Gültigkeit grob auf eine Woche voreinstellen, und nach erster Verwendung erlischt sie automatisch.
• Keyfobs auf z.B. ESP32- Basis
• Mit allen gängigen Smartphones benutzbar
• SpaceAPI
• Wenn's auf WLAN basiert, könnte das Schlosssystem beim Einschalten des Lichtes ein eigenes WLAN öffnen. Über dieses kann dann die Authentifizierung auf einem zusätzlich kryptografisch abgesicherten Verfahren erfolgen. Sobald die Authentifizierung erfolgt ist, wird dieses WLAN automatisch wieder ausgeschaltet.
• /dev/watchdog auf RasPi für mehr Zuverlässigkeit. 😉
• Über MQTT/TLS könnte ein Kommando gesendet werden. Als Payload könnte ein wechselnder Ausschnitt aus einem „one time pad“ verwendet werden. Das Schloss könnte dann den Benutzer mit dem Payload authentifizieren. Klingt, als wäre das mit MicroPython auf ESP32 umsetzbar.
• Schliessbutton innen.
• Code für bisheriges Schlossystem: https://github.com/PJaros/pySchloss
•  WLAN Hotspot auf RasPi mit nmcli

• Diese Anforderungen an das „alte“ Schlosssystems wollen wir erhalten:
  • Der bisherige Mechanismus mit dem Aussenlicht zur „Scharfschaltung“ und Abschliessen.
  • Jeder Schlüssel soll individuell und entsprechend individuell zurückziehbar sein.
• Von diesen bisherigen Anforderungen können wir ggf. abrücken:
  • Kopierbarkeit des Schlüssels ist auszuschliessen.
• Diese neuen Kriterien kommen hinzu:
  • Der Öffnungsvorgang soll schneller und stabiler sein „als bisher“

User_Story

• Als NSA Agent möchte ich eine Backdoor Key
• Als Organisation mit mehreren Schlössern wäre es wünschenswert, mehr als ein Schloss gleichzeitig nutzen und verwalten zu können.
• Als Organisation mit mehreren Mitgliedern möchten wir Benutzergruppen. Schlösser möchten wir einzelnen Usern zuweisen und entfernen bzw. deaktivieren sollte möglich sein.
• Als Organisation mit mehreren Mitgliedern möchten wir eine GUI zum Verwalten der Schlösser und Schlüssel, für Admins die keine CMD benutzen können bzw. wollen.
• Als Organisation mit mehreren Mitgliedern möchten wir die Schlüsselverwaltung über einen externen Bildschirm (Netzwerkverbindung?) administrieren können.
• Als Organisation mit mehreren Schlössern die weit vom Hauptrechner entfernt sind, möchten wir Schloss-Aktuatoren verwenden, die nicht über digitale Signale direkt, sondern über Netzwerk mit den Schlosssystem verbunden sind.
• Als Verfechter modularer Architekturen möchte ich Schloss-Aktuatoren auf verschiedene Situationen anpassen können. Als Beispiele seien die spezifische Ruum42 Situation mit dem Aussenlicht genannt, wie auch ein klassisches Schloss mit Drehknauf.
• Als Organisation mit mehreren Mitgliedern haben wir anstatt einen Schalter einen Bewegungsmelder, deshalb möchten wir, dass das Schloss dauerhaft nach Verbindungen sucht.
• Als Hackerspace möchten wir die Information über den Status der Tür (offen / geschlossen) über Netzwerk nach aussen kommunizieren. → SpaceAPI
• Als Schlossbenutzer im Ruum42 möchte ich mit einem Schalter in der Nähe der Türe die Türe schliessen ohne das Aussenlicht auszuschalten. Hintergrund: Um das korrekte Schliessen der Türe zu kontrollieren, ist dies nur bei geschlossener Türe möglich. Bisher wurde dazu das Licht ein- und ausgeschaltet, teils im Dunkeln hochgegangen um ein wieder öffnen zu verhindern (Bluetooth-Pairing alt). Das wird mit einem „Ausschalter“ bei der Türe nicht mehr nötig.
• Als Ruum42 Vollmitglied möchte ich das Schloss mit der Trigger Anwendung öffnen können.
• Als Ruum42 Vollmitglied möchte ich das Schloss auch ohne Smartföhn öffnen können. Idee ist ein ESP.
• (Allenfalls) Als Besucher ohne persönliches Login/Passwort möchte ich über die Trigger Anwendung mit einem „generischen“ Benutzer die Klingel betätigen können. Die Einrichtung des Benutzers finde ich auf der Ruum42 Webseite. Im Ruum42 ist eine Klingel angebracht, die vom Raspberry-PI angesteuert wird.

Nach meiner Vorstellung handelt es sich dabei um Software. Die Software wird spezifisch auf die Gegebenheiten eines ganz bestimmten physikalischen Schlosses angepasst. Schloss-Aktuatoren sollen austauschbar sein. Das heisst, die interne Architektur sieht eine einheitliche Schnittstelle vor, über welche die Schloss-Aktuatoren mit dem Authentifizierungsmodul kommunizieren.

Der Schloss-Aktuator signalisiert dem Authentifizierungsmodul, wann es Authentifizierungen entgegennehmen darf und wann nicht. Damit können wir das aktuelle Verhalten abbilden, mit dem nur bei Aussenlicht die Authentifizierung zulässig ist.

Der Schloss-Aktuator kontrolliert natürlich auch das Schloss selber. Dafür erhält er vom Authentifizierungsmodul eine Mitteilung, wenn eine erfolgreiche Authentifizierung stattgefunden hat. In der Ruum42- Situation kann nach erfolgter Authentifizierung das Schloss geöffnet werden, und so lange offen gehalten werden, bis das Licht wieder gelöscht wird. In einer anderen Situation könnte beispielsweise nach „open“-Authentifizierung das Schloss geöffnet und nach „close“-Authentifizierung das Schloss geschlossen werden.

Grafik erstellt mit drawio.

• Als Benutzerverwalter möchte ich neue Benutzer erstellen, suspendieren und löschen können.
• Als Benutzer möchte ich mein initiales Passwort auf meinem eigenen PC / Smartphone setzen und bearbeiten können.
• Als Benutzerverwalter möchte ich sehen, wann ein Passwort zuletzt verändern und oder als Login benutzt wurde.
• Als Benutzerverwalter möchte ich Mindestanforderungen an Passwörter setzen, z.B. mindestens 20 Zeichen, haben. Das Passwort soll zwei Mal eingegeben werden.

• Eigenbau
  • Ermöglicht simple Konfiguration von Schlüsseln auf Basis von HTTPS
  • Öffnen des Hackerspace per:
    • SSH-Channel-Exec per Paramiko und Trigger-App auf F-Droid
    • SSH-Shell auf mit demselben Paramiko-Dienst
    • MQTT (mit TLS)
    • HTTPS
• Home-Assistant installieren und das Schlosssystem mit einem Protokoll ausstatten das es erlaubt die Türe zu öffnen.

Ein Admin soll Benutzer ohne SSH oder sonstigen Kommandozeilen-Tools verwalten können. Ziel ist Benutzer, Schlüssel und Passwörter einfach verwalten zu können.

• Eigenbau
  • Mit Python per
    • Django, Doc
    • TurboGears, Doc (← Abandonware?)
    • Flask, Tutorial + Flask-WTF, Tutorial
  • Mit Java per Spring-Framework
  • Mit Rust per Axum
  • Mit C++ mit einem Web Application Framework
• Bestehende Lösungen verwenden und ausbauen
  • Webmin bietet eine eingebettete Benutzerverwaltung an. Es können zusätzliche Dienste verwaltet werden. Die Schlüsselverwaltung könnte dort darüber eingebunden werden. Youtube Installationsanleitung
  • openHAB ist eine Software für Hausautomatisierung, allerdings schon etwas umfangreicher.
  • SuperTokens

• Mögliches Gehäuse mit durchsichtigem Kunststofffenster:
  • BoVersa BOV-FG-G 211405, 210 x 140 x 63 mm
  • BoVersa BOV 2114 FG-9003, 210 x 140 x 24 mm

# CA Schlüssel und Zertifikat erstellen
openssl req -new -x509 -days 14 -extensions v3_ca -keyout ca.key -out ca.crt
# Es wird nach einem Passwort gefragt. Hier eines definieren. Es wird später zum Signieren gebraucht.
 
# Der private Schlüssel 'ca.key' muss geheim bleiben und sollte möglichst nicht auf dem Server/Schlosssystem gelagert werden.
 
# Server Schlüssel erstellen
openssl genrsa -out server.key 4096
 
# Signierungsanfrage für den Server-Schlüssel erstellen
openssl req -out server.csr -key server.key -new
 
# Den Schlüssel mit dem CA Zertifikat signieren
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 7
 
# Informationen zum Zertifikat anzeiten
openssl x509 -noout -text -in server.crt
 
# Den RasPi Timestamp anpassen für den Fall, dass es ohne Verbindung zum NTP Server startet
sudo touch /var/lib/systemd/timesync/clock

# wene-raspi-lock ist der hostname des MQTT brokers in diesem Setup
 
# Alle MQTT Nachrichten abonnieren: (zum Debuggen)
mosquitto_sub -h wene-raspi-lock -t "#" -v -p 8883 --cafile path/to/ca.crt 
 
# Kommando zum Öffnen an's Schloss schicken:
mosquitto_pub -h wene-raspi-lock -t "main-door/lock" -m "open" -p 8883 --cafile path/to/ca.crt
 
# Das Schloss schickt den Status "opened" zurück:
mosquitto_pub -h wene-raspi-lock -t "main-door/status" -r -m "opened" -p 8883 --cafile ca.crt
# Das Flag '-r' steht für "retain" und bedeutet, dass dieser Wert auf dem Broker als Status gespeichert bleibt und neuen Clients bei Verbindung zugestellt wird.