Veranstaltung/LabAccess

!!! Achtung, diese Seite ist unfertig !!!

Abstract

Diese Seite beschreibt den Aufbau, die Verfahren und den Stand der Implementierung des zukünftigen Labor-Zugangssystems.

Vorstellung des "Stands der Dinge"

Folgendes soll im Vortrag kurz (oder in Länge "on demand") behandelt werden:

• Was das Ganze soll
• Designkriterien
• Sicherheitsanforderungen/Sicherheitsprobleme
• Wie es geplant ist
• Was existiert
• Was zu tun ist

Was es bis jetzt gibt

• die Protokolle sind nahezu fertig (allerdings noch nicht geschrieben oder implementiert)
• die Datenstrukturen sind fast fertig designed
• die kryptographischen Primitiven sind bereits implementiert, nur der PRNG muss nochmal kurz überarbeitet werden, und der XTEA geht noch ein wenig kleiner.

Der grundlegende Aufbau

Das System besteht im wesentlichen aus zwei Komponenten, dem Token-Holder und der Main-Unit, welche sich wiederum aus Terminal und Main-Unit zusammensetzt. Der Token-Holder wird nach derzeitigen Planungen als I²C-Speicherchipkarte im ID-00 Format realisiert. Stark vereinfacht arbeite das System mit Einweg-Tokens, wobei eine berechtigte Karte ein Einweg-Token enthält, welches von der Main-Unit ausgelesen und überprüft wird. Handelt es sich um ein gültiges Token, so generiert die Main-Unit ein neues Einweg-Token und legt dieses auf der Karte ab.

Der Token-Holder (Chipkarte)

Eine Speicherchipkarte mit I²C-Bus dient als Speicherort für ein oder mehrere der im nachfolgenden beschriebenen Datenobjekte, welche jeweils die für die Autorisierung an einer SU notwendigen Daten enthalten. Damit ist es möglich mit einer einzelnen Karte verschiedenen Objekte zu steuern, die an verschiedenen SUs hängen.

UserEntity structure

Name	Beschreibung	Größe des Datenobjektes	Labels
ASN.1 Header	Headerinformationen nach ASN.1 zur Bildung logischer Datenobjekte	?	<struct>
Version ID	gibt den Versionsstand der nachfolgenden LabAccess-Struktur an	min. 8 Bit = 1 Byte (?)	<struct>
Entity ID	Spezifiziert das Zugangssystem zu welchem dieses Datensatz gehört	16 Bit = 2 Byte
User ID	User ID für die Entity	16 Bit = 2 Byte
Token	das Einwegtoken	256 Bit = 32 Byte	<sec>
Flags	diverse Flags	?
Start-Date	Datum, ab wann der Zugang gültig ist	?
Stop-Date	Datum, bis wann der Zugang gültig ist	?
PIN-HMAC	Ein HMAC, mit dem sich die PIN validieren lässt	256 Bit = 32 Byte	<sec>
HMAC	HMAC über die vorrangegangenen Daten ab einschl. ASN.1 Header, zum Schutz gegen Manipulation	256 Bit = 32 Byte	<sec>

Die Security-Unit (SU)

Die Security-Unit ist das Herz des Zugangssystems. Diese Einheit führt die eigenliche Autorisierung und die damit verbundenen Überprüfungen durch.

Hardwarekomponenten

Nach derzeitiger Planung setzt sich die SU aus folgenden Hardwarekomponenten zusammen:

• Microcontroller (ATmega32)
• I²C EEPROMS für die User-Database
• I²C Thermosensor (zur Zufallsgewinnung und überwachung der Betriebstemperatur)
• Realtime-Clock (mögl. I²C Anbindung)
• Diodenschaltung zur Nutzung physikalischen Zufalls
• Serielle Schnittstelle zur Kommunikation mit Terminal
• von Aussen zugänglich Taster für gewisse Steuerfunktionen
• evtl. Display zur Statusanzeige

Hardwaredokumentation

Der werte Herr Erbauer hielt es leider nicht für nötig der Nachwelt die Schaltpläne offen zu legen oder sonst irgendwie etwas zu dokumentieren, daher sind folgende Beschreibungen unvollständig und wahrscheinlich in Teilen nicht richtig.

Die folgenden Angaben sind aus prokeliger Reverseengineererei entstanden, weil sich jemand zur Aufgabe gemacht hat, die Unendliche Geschichte (aka Zugangssystem, aka Z-Wort) endlich mal zuende zu schreiben.

Panel

• ATmega 32

2x8 PIN Connector zum Cardreader

(pinbelegung undokumentiert)

2x13 PIN Connector zum Panel

Zur Ansteuerung der Buttons & Anzeigen

(pinbelegung undokumentiert)

6 Federklemmen zum Anschluss an die Master Control Unit

Pinbelegung:

 1 GND
 2 VCC IN (über Diode zum Eingang des 7805)
 3 GND
 4 RXD (über Widerstand) an PD0 des Atmegas
 5 TXD (über Widerstand) an PD1 des ATmegas
 6 unbelegt

Master Control

Allgemeines

An Alle Power-Pins kommt an den jeweils Roten das positive Potential, an den grauen ist Ground.

Alle Pins sind in Leserichtung der jeweiligen Labels daneben gezählt, also von Links nach Rechts.

PWR IN

12 V zum und vom Akku (Große Buchse Oben) und Klemme unten für den Power-Eingang.

Cardreader (R0/R1)

R0 und R1 sind Cardreader out/inputs, deren Pinne 1 bis 3 jeweils wie folgt beschaltet sind:

 1 GND
 2 VCC (12V, bzw. je nach PWR IN)
 3 GND

R0 ist an Pinnen 4 und 5 wie folgt verbunden:

 4 INT0/PD3 (über Optokoppler und Spannungsteiler)
 5 INT1/PD2 ( " )

...und R1 ist so verbunden:

 4 PD1/TXD
 5 PD0/RXD

Angeschlossen ist nur R1, da ein zweites Kartenterminal an der Tür unten nun nicht mehr benötigt wird weil eben diese Tür nicht mehr existiert ;)

Anschluss für Schloss "L"

Pinbelegung wie folgt:

 1 VCC (12V, bzw. == VCC IN)
 2 PC2
 3 PC3
 4 PC4
 5 PC6
 6 GND
 7 PA7 (ADC7)
 8 Über Spannungsteiler gegen VCC (5V) an PA1

Nummer 8 ist demnach wohl an den Fototransistor des Schlosses gekoppelt und #7 dann wahrscheinlich der Eingang des Optokopplers...

Schloss

Der SUB-D Stecker am Schloss ist wie folgt belegt (Nummerierung gem. Beschriftung auf dem Stecker)

 1 Vermutlich GND, auf jeden Fall sind beide Dioden dran
 2 IR-Receiver
 3 IR-Sender
 4 unbelegt
 5 Braun (Motor)
 
 6 Blau (Motor)
 7 Weiss (Motor)
 8 Orange (Motor)
 9 Rot (Motor)

Bei dem Schrittmotor handelt es sich um einen "Mitsumi M35SP-7N". Wenn jemand ein Datenblatt dafür haben sollte, oder weiss wofür die Farben stehen, bitte melden oder hier rein schreiben.

Keys

Die SU benötigt folgende Keys

Name	Kürzel	Typ	Länge	Zweck
Foogle-Longterm-Key	Kfl	XTEA-Secretkey	128 Bit	Austauch der temporären Schlüssel für das Foogleport Protokoll
Foogle-Shortterm-KEy	Kfs	XTEA-Secretkey	128 Bit	Verschlüsselung der Daten beim Austausch über den Foogleport
LabAccess-Current-Signingkey	Kcs	HMAC-Key	256 Bit (?)	signieren der Daten der UserEntity ...

kryptographisch Funktionen

Die verwendeten kryprographischen Funktionen stammen aus der crypto-avr-lib welche gegenwärtig auch im SVN liegt. Als kryptographische Funktionen kommen zum Einsatz:

Hashfunktion

Als sichere Hashfuinktion dient SHA-256 gemäß FIPS 180-2.

HMAC

Es wird HMAC-SHA256 gemäß RFC 2104 verwendet.

PRNG

Der PRNG ist eine "Eigenkonstruktion" und benutzt ganz viel SHA-256. Sollte auf jeden Fall nochmal genau betrachtet werden. Das derzeitige Design sieht folgendermaßen aus:

Eine Legende wird noch folgen, aber schonmal folgende Tipps am Rande:

• H: Hashfunktion
• ||: Konkatenierung
• + im Kreis: XOR-Verknüpfung

Symmetrische Verschlüsselung

Zur symmetrischen Verschlüsselung wird XTEA eingesetzt. Er findet in mindestens zwei Modi Verwendung (CBC und der andere steht noch nicht fest).

Managment

Das System wird lokal verwaltet, d.h. die Administration der Accounts (erzeugen, sperren, ...) findet am Gerät selbst statt.

Operationen

Die folgende Tabelle zeigt, welche Funktionen geplant sind und wie die entsprechende Rechtevergabe gedacht ist.

Opertaionen

Operation	Beschreibung	Requirements
MainOpen	Tür öffnen	<valid card>
AddUser	neuen Benutzer Anlegen	<valid admin card + pin>
RemUser	Benutzer löschen	2*<valid admin card + pin>
AddAdmin	Benutzer zum Admin machen	2*<valid admin card + pin>
RemAdmin	Admin Rechte entziehen	2*<valid admin card + pin>
KeyMigration	Keys aus dem Gerät extrahieren	3*<valid admin card + pin>

Tor öffnen mit dem Handy

Dazu musst Du einfach das Programm toroeffner_addnumber auf roulette ausfuehren und Deine Nummer in die Liste eintragen:

 toroeffner_addnumber deinenummer deinname

Wobei die Nummer OHNE Laendervorwahl und OHNE Sonderzeichen eingetragen werden muss -> also z.B.:

 toroeffner_addnumber 02323424242 hanswurst

Ein Name oder Pseudonym ist fuer die Wartbarkeit der Liste leider erforderlich. Eintraege ohne Pseudonym oder Name werden kommentarlos geloescht. Die Nummern werden gehashed gespeichert.

Die Telefonnummer für den Toröffner ist: (Bochum)/54729-62

Weitere Ideen

Statt der I2C-Karte als Token eine LED-Lampe mit bidirektionaler Kommunikation über die LED verwenden. Ist ein cooles Bastelprojekt, wurde z.B. hier schon mal entwickelt.

FAQ

• Q:Warum keine intelligente Karte mit cooler Krypto drauf?

A:Weil die 'n Haufen Geld kosten (etwa Faktor 20), und komplizierter in der Ansteuerung sind (wobei sich das durchaus machen ließe).

• Q:Dann können die Karten aber doch einfach kopiert werden?

A:Ja, es ist durchaus möglich, von einer Karte 100 Kopien zu erstellen, und mit jeder von denen kann man dann in's Labor. Doch wenn man mit einer sich am Gerät angemeldet hat, werden alle anderen ungültig.

• Q: Wann können all die vielen Leute die jetzt keinen Schlüssel haben endlich ins Labor, bzw. wann ist es endlich fertig?

A: Es ist fertig, wenn es fertig ist. Wir arbeiten drann. Habt Geduld!