HQ/Zugangssystem/Fonera

From C3D2
Revision as of 20:56, 26 October 2010 by Thammi (Talk | contribs)

Jump to: navigation, search

Contents

Fonera GPIO

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.

So jetzt hat der Fonera auch ein neues Gehäuse mit Lüfter.

Hier das Script das auf dem Fonera rattert:

#!/bin/sh

gpioctl clear 3
gpioctl dirout 3
gpioctl set 3
sleep 1
gpioctl clear 3
gpioctl set 3
sleep 1
gpioctl clear 3
gpioctl set 3
sleep 1
gpioctl clear 3


exit 0

Software

Eine einmal-Token basierte Lösung mit Webinterface in Lua.




MoleFlap
Türzuganssystemsoftware
Home: https://moleflap.hq.c3d2.de/
Meta
Sprachen:Lua
Plattformen:Unix
Links
Kommunikation
Mailing-Liste:http://mail.skyhub.de
MUC:[xmpp:c3d2@muc.hq.c3d2.de c3d2 auf muc.hq.c3d2.de]
Repository
GIT:http://gitorious.hq.c3d2.de/moleflap/software


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
  • 4 Zeichen Präfix
  • Übergabe des Token als Query String
  • Admin-Skripte liegen auf moleflap
  • User-Skripte liegen gleichfalls auf moleflap und sind über das Web-Interface direkt zu erreichen.
  • Code liegt auf gitorious.hq.c3d2.de

Design

  • Der Token besteht jeweils aus einer Base64 kodierten Zufallszahl mit insgesamt 164 Zeichen. Die ersten 4 davon sind als Präfix definiert der bei den folgenden Token wieder dabei ist.
  • 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 Präfix dient als hilfe für die Admins damit diese nur durch die Angabe dessen einen Token sperren können.
  • 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)
  • Der Admin kann einen PGP Schlüssel einem Prefix zuordnen, mit dem den Nutzer seinen Schlüssel wiederherstellen kann, falls er ihn kaputt gespielt hat oder mehrere Geräte zum Aufschließen benutzen möchte. Die Anonymität des Prefix geht dabei jedoch verloren.
  • Vorschlag: Eventuell Logging der Aufschliessvorgänge (ohne Zuordnung zu Token)?

Administration

Besteht aus insgesamt 9 Skripten:

  • createdb -- erstellt die Datenbank-Tabellen (sollte nichmehr nötig sein ;P)
  • deletedb -- löscht alle Daten aus der Datenbank inklusive der Tabellen (wer das macht ist *very-evil*)
  • addtoken -- erstellt einen neuen Token. Es können Angaben über Username und Präfix gemacht werden
  • revoke -- löscht den Token mit dem angegeben Präfix um den Zugang zu sperren (nötig um evtl. verlorene Token ungültig zu machen)
  • isvalid -- gibt an ob ein Token mit dem angebenen Präfix noch gültig ist
  • isdead -- gibt an ob ein Token mit dem angebenen Präfix bereits abgelaufen ist
  • listusers -- gibt eine Liste aller User zurück die jemals einen Token erhalten haben und die Anzahl, wieoft sie schon einen neuen Token erhalten haben (fängt bei eins an :3)
  • statistic -- gibt an wieviele User, gültige und abgelaufene Token das System kennt
  • setpgp -- setzt den PGP schlüssel für ein Prefix

Admins: Astro, Dodo, Poelzi, Thammi

Weblinks

Personal tools
Namespaces

Variants
Actions
Navigation
Tools
In other languages