Schlosssystem 2026

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.
• Als Ruum42 Vollmitglied möchte ich mehrere Tokens zur Authentifizierung in meinem Account hinterlegen und verwalten können. Damit kann ich beispielsweise den SSH Schlüssen der Trigger App auf dem Smartphone sowie den SSH Schlüssel meines Laptops hinterlegen und im Falle eines Verlustes auch wieder getrennt zurückziehen. Die Schlüssel würde ich gerne anhand eines Namens, den ich selbst vergeben kann, identifizieren können.
• Als Vorstandsmitglied möchte ich Dienstleistern wie z.B. Getränkelieferanten einen Einmal-Schlüssel per E-Mail senden können. Dabei sollte der Dienstleister keine spezielle Hard- oder Software benötigen. Ein gängiges Smartphone mit Browser muss genügen. Der Einmal-Schlüssen wird ungültig, sobald er einmal benutzt wurde. (resp. ein paar Minuten danach, damit nach versehentlicher Schliessung nochmals geöffnet werden kann.) Beispiele für einen Schlüssel wären ein Link, der nur im Schloss-Netz gültig ist, oder ein Zahlencode der in einem Captive-Portal eingegeben werden muss.

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

Dies sind ein paar Kommandos, die auf einem Client verwendet werden können, um MQTT zu testen. Sie gehen von einer Verschlüsselten Verbindung über TLS aus. Details zur Konfiguration siehe nächster Abschnitt.

Um diese Kommandos verwenden zu können, muss folgendes installiert werden: sudo apt install mosquitto-clients

# 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.

So wird auf dem RasPi den MQTT Server, genannt „Message Broker“ installiert: sudo apt install mosquitto

Die Konfigurationsdatei /etc/mosquitto/mosquitto.conf enthält ein paar Standardeinstellungen welche wir auskommentieren. Die Einzige Zeile, die aktiv bleibt ist die letzte, welche die Konfigurationen aus den Dateien im Unterverzeichnis conf.d inkludiert.

In /etc/mosquitto/conf.d legen wir folgende Dateien mit entsprechendem Inhalt an:

log.conf

log_dest syslog

tls.conf

listener 8883
allow_anonymous true
cafile /etc/mosquitto/ca_certificates/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key

Die Datei tls.conf enthält Pfade zu Zertifikaten, welche wir natürlich erst an der Stelle ablegen müssen, damit das funktioniert. Wie sie erstellt werden, wird im Kapitel TLS Self Signed Certificates erklärt. Nachdem die Dateien an den entsprechenden Pfaden liegen, sollte Mosquitto als Eigentümer festgelegt werden: sudo chown mosquitto:mosquitto -R /etc/mosquitto/certs und sudo chown mosquitto:mosquitto -R /etc/mosquitto/ca_certificates.

Um aus Python MQTT zu nutzen, bietet sich Paho an: sudo apt install python3-paho-mqtt

Als NTP Server bietet sich Chrony an. Der kann sehr einfach so konfiguriert werden, die wahre NTP Zeit weiter zu leiten solange es eine Verbindung zu NTP Servern gibt. Wenn diese Verbindung nicht existiert, kann eine angenommene Zeit verbreitet werden.

Dies ist die Konfigurationsdatei in /etc/chrony:

chrony.conf

# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usable directives.

# Use Debian vendor zone.
pool 2.debian.pool.ntp.org iburst

# Use time sources from DHCP.
sourcedir /run/chrony-dhcp

# Use NTP sources found in /etc/chrony/sources.d.
sourcedir /etc/chrony/sources.d

# This directive specifies the location of the file containing ID/key pairs for
# NTP authentication.
keyfile /etc/chrony/chrony.keys

# This directive specifies the file into which chronyd will store the rate
# information.
driftfile /var/lib/chrony/chrony.drift

# Save NTS keys and cookies.
ntsdumpdir /var/lib/chrony

# Uncomment the following line to turn logging on.
#log tracking measurements statistics

# Log files location.
logdir /var/log/chrony

# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0

# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can't be used along with the 'rtcfile' directive.
rtcsync

# Step the system clock instead of slewing it if the adjustment is larger than
# one second, but only in the first three clock updates.
makestep 1 3

# Get TAI-UTC offset and leap seconds from the system tz database.
# This directive must be commented out when using time sources serving
# leap-smeared time.
leapseclist /usr/share/zoneinfo/leap-seconds.list

# Include configuration files found in /etc/chrony/conf.d.
confdir /etc/chrony/conf.d

# allow usage of local time without real time source
local

# allow changes using `chronyc settime`
manual

allow all

Beim Starten des RasPi ohne Zugang zum echten NTP Server wird die Änderungszeit der Datei /var/lib/systemd/timesync/clock verwendet. Leider wird dieser Zeitstempel bei Verwendung von chrony nicht automatisch aktualisiert. Das muss spätestens beim Ausstellen neuer Zertifikate manuell mit sudo touch gemacht werden.