HQ/Zugangssystem/Fonera: Unterschied zwischen den Versionen

Aus C3D2
Zur Navigation springen Zur Suche springen
Zeile 44: Zeile 44:
* Token haben eine begrenzte Lebensdauer (TTL, ~2 Monate als Diskussionsgrundlage) nach der sie gelöscht werden
* Token haben eine begrenzte Lebensdauer (TTL, ~2 Monate als Diskussionsgrundlage) nach der sie gelöscht werden
* Abgelaufene Token werden noch eine Weile aufgehoben (Admins können verfifizieren das Token abgelaufen ist wenn neuer beantragt wird, unterscheidbar zu verloren und weitergegeben)
* Abgelaufene Token werden noch eine Weile aufgehoben (Admins können verfifizieren das Token abgelaufen ist wenn neuer beantragt wird, unterscheidbar zu verloren und weitergegeben)
* Der Token ist auf seinen Parent zurückführbar um Token auf Basis eines früher Tokens zurücknehmen zu können, ersten Zeichen des Tokens sind eine ID
* Der Token ist auf seinen Parent zurückführbar um Token auf Basis eines früher Tokens zurücknehmen zu können (ersten Zeichen des Tokens sind eine ID)
* Die Token sollen nicht eindeutig Personen zugeordnet werden
* Die Token sollen nicht eindeutig Personen zugeordnet werden
* Anzahl der an Personen neu vergebenen Token wird gespeichert (nur Nick und Anzahl)
* Anzahl der an Personen neu vergebenen Token wird gespeichert (nur Nick und Anzahl)

Version vom 26. Februar 2010, 00:52 Uhr

HQ-Zugangssystem

Hardware

Da es in unserem Hq ein kleines Schlüsselproblem gab, haben wir uns überlegt die Tür elektronisch aufzuschließen. Ein Magnetschloß war schon vorhanden jetzt fehlte nur noch die Ansteuerung des Schlosses. Wir entschieden uns erstmal einen Wlan-Router zu nehmen, da jeder eigentlich immer ein Gerät mit Wlan dabei hat. Als Wlan Router nahmen wir den Fonera (v.1), glücklicherweise wurden bei dem Fonera die GPIO Pins schon freigelegt, d.h. sie waren auf der Platine frei zugänglich. Die Belegung der Pins fanden wir hier. GND nahmen wir vom Seriellen Port (wie man auf dem Bildern sehen kann) es ist der 2. Pin rechts oben, wenn der Wlan Chip in eure Richtung zeigt.

Diese ganzen Pins wurden jetzt an einen 9-poligen Sub-D Stecker gelötet und in das Gehäuse gebaut. Um später auch die anderen Pins nutzen zu können.

Jetzt galt es das Schloss anzusteuern. Die Spannung der GPIO Pins konnten wir nicht nutzen weil die Spannung und der Strom einfach zu schwach für den Schaltmoment des Schlossen waren. Deshalb musste eine Transistor her. Die Transistorschaltung die wir haben wollten sollte quasi als Schalter dienen. Wir bauten eine einfache kleine Emitterschlatung mit einem BC137. Der Kollektor wurde durch eine Diode und einen Elko gegen Selbstinduktion des Schlosses geschützt (im Schloß befinden sich Magnete die bei Stromdurchfluß in sich einen Strom in entgegengesetzte Richtung induzieren). Ein paar Werte:

  • Ausgangsspannung des GPIO-Pins -> 3,3V
  • Versorgungsspannung Transistor -> ca. 12V / ca. 2A

Weil das Schloß soviel Spannung/Strom braucht haben wir somit 2 Netzteile, 1x Router, 1x Transistor.

Ok als nächstes mussten wir den Fonera sagen er solle den Pin an dem wir das Schloß angeschlossen haben, schalten. Auf dem Fonera ist OpenWRT installiert, das erleichterte uns einiges. Die erste Hürde war herauszufinden wie die GPIO Pins geschaltet werden, wir stießen da auf dieses kleine Tool gpioctl welches auch schon installiert war. Die zweite Hürde war herauszufinden welcher Hardware Pin zu welchen Software Pin gehört. Nach einigen Versuchen gelang es uns das Schloß schalten zu lassen, und wir schrieben sofort ein kleines Skript was 3 sek. lang das Schloß öffnet und wieder schließt. (Skript bzw. gpioctl Syntax folgt)


Software

Es wird gerade an einem einmal-Token basiertem skriptbarem Webinterface in Lua gearbeitet.

Design

  • Der Token besteht jeweils aus einer Base64 kodierten Zufallszahl
  • Beim öffnen der Tür mit diesem Token wird er ungültig und ein neuer gültiger Token wird ausgegeben (Plaintext über HTTP)
  • Es wird bei jeder syntaktisch korrekten Anfrage ein Token zurückgegeben (Nur physische Anwesenheit an der Tür ermöglicht validen Token zu erkennen)
  • Token haben eine begrenzte Lebensdauer (TTL, ~2 Monate als Diskussionsgrundlage) nach der sie gelöscht werden
  • Abgelaufene Token werden noch eine Weile aufgehoben (Admins können verfifizieren das Token abgelaufen ist wenn neuer beantragt wird, unterscheidbar zu verloren und weitergegeben)
  • Der Token ist auf seinen Parent zurückführbar um Token auf Basis eines früher Tokens zurücknehmen zu können (ersten Zeichen des Tokens sind eine ID)
  • Die Token sollen nicht eindeutig Personen zugeordnet werden
  • Anzahl der an Personen neu vergebenen Token wird gespeichert (nur Nick und Anzahl)
  • Startzeit der TTL wird obsfuscated (~1 Woche Abweichung maximal) um genaue Verfolgbarkeit zu verhindern
  • Anzahl der Requests in bestimmter Zeit pro Client-Adresse ist begrenzt (Bruteforce Schutz)
  • Vorschlag: Eventuell Logging der Aufschliessvorgänge (ohne Zuordnung zu Token)?

Umsetzung

  • Hauptsächlich in Lua
  • Datenhaltung in PostgreSQL
  • Webinterface auf moleflap
  • moleflap öffnet die Tür über ssh auf das Fonera
  • Zufallszahl aus /dev/urandom
  • Übergabe des Token als Query String
  • Admin-Skripte liegen auf moleflap

Der Code liegt auf gitorious.hq.c3d2.de.

Authentifizierung

Zurzeit ist das Öffnen der Türe aber damit noch nicht möglich, weil noch ein Türknauf außen an der Tür fehlt und eine ordentlich Authentifizierung installiert werden muss. Denn man kann momentan die Tür nur öffnen wenn man mit seinem ssh-Key in dem Router angemeldet ist.

Work in progress!

Weblinks