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.

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.
• Die Klingelfunktion soll eingerichtet werden. Idealerweise über die „Trigger App“ Auch User die nicht Mitglied sind sollen diese auslösen können. Bekanntmachung darüber auf der Webseite. Das soll über einen Benutzer à la „Anonymus“ geschehen. Im Ruum soll eine Klingel angebaut werden, die per IO vom Rasberrypi und einem Relays angesteuert wird. Personen die Hilfe brauchen um die Treppe runterzukommen soll so der Zugang erleichtert 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