Zugangssystem

Dieser Seiteninhalt bedarf einer Überarbeitung. Näheres sollte auf der Diskussionsseite angegeben sein. Bitte beteilige dich an der Verbesserung und entferne anschließend diese Markierung.

Zugangssystem
Weshalb	Zugang zum Space für (fast) alle
Was	hardware, software
Wer	Gtrs, Morlac
Status	läuft

Wir haben unseren Raum und jetzt wollen wir unseren Mitgliedern auch den Zugang ermöglichen.

Problem

Um in den Raum zu kommen müssen zwei Türen geöffnet werden:

• Haustür
• Elektrisches Rollo
• Zugang zur Toilette

Die Zugangstür verfügt über ein Standart-Zylinderschloss. Das Rollo kann von außen mit einem Schlüssel oder von innen Verfahren werden.

Der Plan

Haustür

Vermieter ist einverstanden. Ein Elektrischer Öffner mit Schlüssel installiert.

Elektrisches Rollo

Tagsüber ist es für gewöhnlich offen, da die Hausbewohner es auch benutzen.

Einige Mitglieder haben sich die Verkabelung schon einmal angesehen, für mich ist die Sicherheit der Benutzer im Vordergrund.

Zugang zur Toilette

Muss geplant und geklärt werden, wie es am besten zu realisieren ist.

Aktueller Stand

Der Tür-PI ist fast fertig, er hat schon ein neues Gehäuse und wird zzt verdrahtet, es sind 3 Schlüssel für das Rolltor angeschafft.

Zur Anwesenheitschallenge

Dazu gibt es verschiedene Ideen, die erste schließt die alte Methode ein, die neue auch eine Bestätigung via RFID Karte, die aber alleine die Tür nicht öffnen kann. Ich persönlich bin immer für eine 2FA bzw Anwesenheitschallenge+Anmeldung auf Seite

Angreifermodelle

die selben wie letztes mal. Zusätzliche können gerne hier gelistet werden.

---

Alternativen

Einige Dinge zum aktuellen Protokoll:

• Presence Challenge gibt keinen wesentlichen Mehrwert
• Online vs. Offline: Benutzer-IDs+Codes koennen auch auf dem Microcontroller hinterlegt werden

Methoden fuer Benutzereingabe: Vergleich

• Numpad
• Barcode Scanner
• Kamera fuer QR-Code
• RFID/NFC
• Wifi
• Funk ISM-Band

Online vs. Offline Vergleich

Ideensammlung fuer weiteres Vorgehen: Tuer Hackathon

Für die RFID/NFC Alternative scheint die Mifare DESFire EV1 Karte interessant zu sein, diese unterstützt Authentifizierung mittels AES. Im Application-Report der unter https://www.ti.com.cn/cn/lit/an/sloa213/sloa213.pdf zu finden ist, kann die Authentifizierungsmethode nachgelesen werden. Das simple authentifizieren über die UID funktioniert nicht, da es Karten gibt, bei der auch diese geschrieben werden kann. Als Reader könnte der PN532 von Interesse sein, allerdings ist bei diesem nicht klar, ob er die Authentifizierung der DESFire EV1 unterstützt. Andere Mifare-Karten könnten verwendet werden allerdings sind die S50 karten (Classic 1K, Classic 4K) und die DESFire ausgeschlossen, da diese den anfälligen Crypto 1 Algorithmus verwenden oder über Brute-Force angreifbar sind.

Das Protokoll

Für die Außentür könnte folgendes Protokoll verwendet werden.

Grundsätzliches

• Ein ESP8266 kontrolliert ein Relais, welches den Türöffner auslöst. Er ist über Freifunk mit dem Internet verbunden und besitzt ein LED-Display, welches von Aussen sichtbar ist. Dieses dient dazu, sicherzustellen, dass ein Benutzer, der eintreten möchte, auch tatsächlich vor Ort anwesend ist (oder ein großes Teleskop und Sichtverbindung/Periskop besitzt).
• Irgendwo sitzt ein Pi (der dann auch die Zwischentür steuert). Dort läuft eine Webseite.
• Benutzer bekommen SSL-Client-Zertifikate ausgestellt, wenn sie zutrittsberichtigt sind. Benutzer können Gast-Zutrittslinks erstellen und an Gäste vergeben. Die Links sind nur einmal benutzbar und laufen innerhalb weniger Stunden ab. Sie sind an die Gültigkeit des Zertifikats des Ausstellers gebunden.

Protokoll-Bestandteile

Challenges

Challenges sind 128-Bit-Werte sofern nicht anders angegeben.

• TC = Trigger Challenge
• OC = Opening Challenge
• PC = Presence Challenge (4-stelliger Zahlencode)
• AC = Acknowledge Challenge

Challenge Responses

• TCR = Trigger Challenge Response
• OCR = Opening Challenge Response
• ACR = Acknowledge Challenge Response

Secret Keys

PRNG keys werden verwendet, um mittels AES-CTR aus einem internen Counter nicht-vorhersagbare Challenges zu generieren.

• KH0 = Trigger PRNG Key
• KH1 = Opening PRNG Key
• K0 = Trigger Key
• K1 = Opening Key
• K2 = Acknowledge Key

Interne Counter des ESPs

• C0 = Interner Counter im RAM
• C1 = Interner Counter, der alle 100 Iterationen im Flash des ESPs gespeichert wird. Beim Booten wird er um 100 erhöht und sofort nochmal abgespeichert. (Write Cycle Reduction für den Flash)

Angreifermodell

• Der Angreifer hat volle Kontrolle über das WLAN (d.h., Verbindung Pi<->ESP).
• Der Angreifer kann die PC vom Display ablesen sofern angezeigt.
• Der Angreifer kann sich nicht am Pi authentifizieren.
• Der Angreifer hat keinen Zugriff auf den Flash-Speicher des ESPs.
• Der Angreifer besitzt kein gültiges Client-Zertifikat für das Webinterface.
• Der Angreifer hat keinen Zugriff auf den Pi.

Protokollablauf (siehe Bild unten)

(Mit || ist die Konkatenation gemeint.)

1. Der Benutzer besucht die Webseite und authentifiziert sich. Er klickt auf einen Button, und der Pi startet den Login-Vorgang (CSRF-geschützt)
2. Der Pi sendet dem ESP eine "Trigger"-Nachricht.
3. Der ESP berechnet TC=AES(C0++,KH0) und sendet TC an Pi
4. Pi berechnet TCR=HMAC(TC,K0) und sendet TCR an ESP
5. ESP assertet TCR==HMAC(TC,K0).
6. ESP berechnet OC=AES(C1++,KH1) und PC=Filter4ZiffernAus(AES(C1++,KH1)). Wichtig: C1 wird tatsächlich zweimal inkrementiert.
7. ESP zeigt PC auf Display an.
8. ESP sendet OC and Pi.
9. Benutzer liest PC von Display ab, und tippt es auf Webseite ein.
10. Pi würfelt AC (z.B. Hardware-Zufallszahlengenerator in der CPU).
11. Pi berechnet OCR=HMAC(PC||OC||AC, K1) und sendet OCR und AC an ESP
12. ESP assertet OCR==HMAC(PC||OC||AC, K1) und öffnet Tür
13. ESP berechnet ACR=HMAC(AC,K2) und sendet ACR als Response an Pi
14. Pi assertet ACR==HMAC(AC,K2) und sendet Tür-auf-Signal an KeyMatic (wie auch immer)

Anmerkungen

• Die Kommunikation zwischen Pi und ESP ist nicht verschlüsselt (braucht sie auch nicht zu sein).
• Im ESP ist gleichzeitig immer nur eine Session aktiv (d.h., OC und PC werden überschrieben, falls noch eine alte Session läuft)
• Session-Timeouts werden verwendet (bspw. nur 30 Sekunden zur Eingabe von PC)
• C0 wird im RAM gespeichert und kann dadurch durch einen Stromausfall auf einen definierten Wert gesetzt werden. Dies ist aber hier okay, da dadurch nur TC vorhersagbar wird, was nur dazu führt, dass ein Angreifer mehrfach triggern kann, was wiederum nur Flashspeicherabnutzung und ungewollten Displayanzeigen führt.

Nicht-ausgeschlossene Angriffe

• Hat der Angreifer volle Kontrolle über den ESP, kommt er in den Flur. Er braucht aber immer noch ein gültiges Zertifikat, um auch die Zwischentür zu öffnen.
• Hat der Angreifer volle Kontrolle über den Pi, kommt er rein.

Shoppingliste

Maschinendeck tut kaufen tun...

• Keymatic (1-2) ✔
• Schließzylinder (nochmal nachmessen!) ✔
• I2C-LED-Display ✔
• SD-Karte ✔
• Schlüsselkasten (s. oben)
• Netzteil ✔
• Gehäuse ✔
• Frontplatte weiß Plastik, min. 12x12 cm

Kommt von privat

• ESP8266 (-> Guido)
• Kondensator & Widerstand für Zeitsteuerung
• Transistoren und Dioden für Relais
• Step down AMR1117 o.ä. (-> Guido)
• Relais 14V~ (-> Guido)
• Raspberry Pi (-> Kaiser)
• 5V-Pi-Netzteil
• Frontplatte für Display und ESP-Gehäuse
• Abstandshalter LED-Display zu Frontplatte, ca. 4 mm

Umsetzung

'Einbau von KeyMatic und Steuerung über RasPi

Raspberry Pi

0. pi-Benutzer-Passwort geändert 1. ungefähr dieser Anleitung gefolgt: https://www.digitalocean.com/community/tutorials/how-to-set-up-uwsgi-and-nginx-to-serve-python-apps-on-ubuntu-14-04 2. zusaetzliche Abhaengigkeiten im Python virtualenv: pip install RPi.GPIO

Probleme

Manchmal blockiert Python das serielle Device zum RFM69. Ob das der Fall ist kann man sehen mit:

   #!/bin/bash
   
   lsmod | grep cdc_acm
   lsof | grep ACM