Veranstaltung/LabAccess: Unterschied zwischen den Versionen

Aus LaborWiki
Wechseln zu: Navigation, Suche
Keine Bearbeitungszusammenfassung
 
(39 dazwischenliegende Versionen von 20 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
'''!!! Achtung, diese Seite ist unfertig !!!'''
{{Veranstaltung
|title=LABOR - Access control
|actor=
|email=
|url=
|begin=2006/07/25 07:00:00 PM
|place=LABOR e.V., Rottstr. 31, 44793 Bochum
|contact=
|audience=
|tags=
|type=talk
|abstract=
|image=
|partof=
}}
{{Workinprogress}}<!-- keine Inhalte vor diesem Kommentar! (Kopf-Banner) -->
 
'''!!! Achtung, dieses Projekt wird nun als [[AnonAccess]] fortgeführt !!!'''
 


==Abstract==
==Abstract==
Zeile 5: Zeile 23:


==Vorstellung des "Stands der Dinge"==
==Vorstellung des "Stands der Dinge"==
''$Text zum Vortrag''
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==
==Was es bis jetzt gibt==
Zeile 14: Zeile 38:
==Der grundlegende Aufbau==
==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.
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-Speichechipkarte im ID-00 Format realisiert.
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.
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)==
==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.
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.


{| {{Prettytable}}
{| {{Prettytable}}
|+ UserEntity structure
! Name !! Beschreibung !! Größe des Datenobjektes !! Labels
! Name !! Beschreibung !! Größe des Datenobjektes !! Labels
|-
|-
|ASN.1 Header || Headerinformationen nach ASN.1 zur Bildung logischer Datenobjekte || ? || <struct>
|ASN.1 Header || Headerinformationen nach ASN.1 zur Bildung logischer Datenobjekte || ? || <struct>
|-
|-
|Version ID || gibt den Versionsstand der nachfolgenden LabAccess-Struktur an || 8 Bit (?) || <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 ||  
|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 ||  
|User ID || User ID für die Entity || 16 Bit = 2 Byte ||  
|-
|-
|Token || das Einwegtoken || 256 Bit || <sec>
|Token || das Einwegtoken || 256 Bit = 32 Byte || <sec>
|-
|-
|Flags || diverse Flags || ? ||
|Flags || diverse Flags || ? ||
Zeile 40: Zeile 65:
|Stop-Date || Datum, bis 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 || <sec>
|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 || <sec>
|HMAC || HMAC über die vorrangegangenen Daten ab einschl. ASN.1 Header, zum Schutz gegen Manipulation || 256 Bit = 32 Byte || <sec>
|}
|}


Zeile 48: Zeile 73:
Die Security-Unit ist das Herz des Zugangssystems. Diese Einheit führt die eigenliche Autorisierung und die damit verbundenen Überprüfungen durch.
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:
Nach derzeitiger Planung setzt sich die SU aus folgenden Hardwarekomponenten zusammen:
* Microcontroller (ATmega32)
* Microcontroller (ATmega32)
* I²C EEPROMS für die User-Database
* I²C EEPROMS für die User-Database
* I²C Thermosensor (zur Zufallsgewinnung und überwachung der Betriebstemperatur)
* I²C Thermosensor (zur Zufallsgewinnung und überwachung der Betriebstemperatur)
* Realtime-Clock (mögl. I²C Anbindung)
* Diodenschaltung zur Nutzung physikalischen Zufalls
* Diodenschaltung zur Nutzung physikalischen Zufalls
* Serielle Schnittstelle zur Kommunikation mit Terminal
* Serielle Schnittstelle zur Kommunikation mit Terminal
* von Aussen zugänglich Taster für gewisse Steuerfunktionen
* von Außen zugänglich Taster für gewisse Steuerfunktionen
* evtl. Display zur Statusanzeige
* 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) (IR Sender)
  8 Über Spannungsteiler gegen VCC (5V) an PA1 (IR Receiver)
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-Sender
  3 IR-Receiver
  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
{| {{Prettytable}}
! Name !! Kürzel !! Typ !! Länge !! Zweck
|-
| LabAccess-Current-Signingkey || Kcs || HMAC-Key || 256 Bit (?)
| signieren der Daten der UserEntity ...
|-
|}


==Das Terminal==
==Das Terminal==


==Kommunikation zwischen Terminal und SU (foogleport)==
==Kommunikation zwischen Terminal und SU==
 
Die Kommunikation zwischen Terminal und SU läuft unter anderem über den [[qport-tiny]] der Sicherheit im Sinne von security gewährleistet.


==kryptographisch Funktionen==
==kryptographisch Funktionen==
Die verwendeten kryprographischen Funktionen stammen aus der [[AVR-Crypto-Lib]] welche gegenwärtig auch im SVN liegt.
Als kryptographische Funktionen kommen zum Einsatz:
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.
===Hashfunktion===
*PRNG: Der PRNG ist eine "Eigenkonstruktion" und benutzt ganz viel SHA-256. Sollte auf jeden Fall nochmal genau betrachtet werden.
Als sichere Hashfunktion dient '''SHA-256''' gemäß FIPS 180-2.
*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).
 
===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 ähnlich dem folgendem aus:
[[Bild:PRNG1.png]]
 
Die aktuelle Version gibts gerade nur in ASCII-Art:
 
*                      ################################################################################################
*                      #                                                                                              #
*                      #        +---------------------------+                                                        #
*                      #        |                          |                            +---+                      #
*                      #        V                          |                            |  |                      #
*                      #      (concat)                      |                            |  V                      #
*  +---------------+  #    o---------o            (xor)+---------+      o---------o      | o----o    o---------o  #    +--------------+
*  | entropy Block | -----> | sha-256 | --(offset)-<    | rndCore | ---> | sha-256 | --+--+-| +1 |---> | sha-256 | -----> | random Block |
*  +---------------+  #    o---------o            (xor)+---------+      o---------o  |    o----o    o---------o  #    +--------------+
*                      #                                (xor) (xor)                    |                            #
*                      #                                  ^    ^                      |                            #
*                      #                                    \  /                      |                            #
*                      #                                  (offset)---------------------+                            #
*                      #                                                                                              #
*                      ################################################################################################
 
 
 
 
 
 
Eine Legende wird noch folgen, aber schon mal folgende Tipps am Rande:
*H: Hashfunktion
*||: Konkatenierung
*+ im Kreis: XOR-Verknüpfung
 
 
Der Code kann unter [https://www.das-labor.org/trac/browser/microcontroller-2/crypto-lib/prng.c] eingesehen werden.
 
==Die Initialisierung==
 
 
==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.
{| {{Prettytable}}
|+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>
|-
|}
 
==Mögliche Angriffe==
 
 
==Weitere Ideen==
Statt der I²C-Karte als Token eine LED-Lampe mit bidirektionaler Kommunikation über die LED verwenden. Ist ein cooles Bastelprojekt, wurde z.B. [http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2006/bcr6/final_report/index.html hier] schon mal entwickelt.


==FAQ==
==FAQ==
Zeile 74: Zeile 260:
*'''Q:'''Dann können die Karten aber doch einfach kopiert werden?
*'''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.
'''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!
[[Kategorie:Veranstaltung]]

Aktuelle Version vom 29. November 2014, 22:18 Uhr

LABOR - Access control
Akteur
Akteur Email
Akteur URL
Beginn 2006/07/25 07:00:00 PM
Ende
Ort LABOR e.V., Rottstr. 31, 44793 Bochum
Verantwortlich
Publikum
Schlagworte
Art talk
Rahmenveranstaltung
Export iCalendar-Datei
Kurzbeschreibung:


Kran
Diese Seite befindet sich noch im Aufbau bzw. wird gerade heftig überarbeitet. Vorsicht: Herumliegende Gedankenfetzen!
Dieser Banner ist hier dokumentiert.

!!! Achtung, dieses Projekt wird nun als AnonAccess fortgeführt !!!


Abstract[Bearbeiten | Quelltext bearbeiten]

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

Vorstellung des "Stands der Dinge"[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

  • 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[Bearbeiten | Quelltext bearbeiten]

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)[Bearbeiten | Quelltext bearbeiten]

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)[Bearbeiten | Quelltext bearbeiten]

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

Hardwarekomponenten[Bearbeiten | Quelltext bearbeiten]

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 Außen zugänglich Taster für gewisse Steuerfunktionen
  • evtl. Display zur Statusanzeige

Hardwaredokumentation[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

  • ATmega 32
2x8 PIN Connector zum Cardreader[Bearbeiten | Quelltext bearbeiten]

(pinbelegung undokumentiert)

2x13 PIN Connector zum Panel[Bearbeiten | Quelltext bearbeiten]

Zur Ansteuerung der Buttons & Anzeigen

(Pinbelegung undokumentiert)

6 Federklemmen zum Anschluss an die Master Control Unit[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

Allgemeines[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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

Cardreader (R0/R1)[Bearbeiten | Quelltext bearbeiten]

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"[Bearbeiten | Quelltext bearbeiten]

Pinbelegung wie folgt: 

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

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

Schloss[Bearbeiten | Quelltext bearbeiten]

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-Sender
 3 IR-Receiver
 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[Bearbeiten | Quelltext bearbeiten]

Die SU benötigt folgende Keys

Name Kürzel Typ Länge Zweck
LabAccess-Current-Signingkey Kcs HMAC-Key 256 Bit (?) signieren der Daten der UserEntity ...

Das Terminal[Bearbeiten | Quelltext bearbeiten]

Kommunikation zwischen Terminal und SU[Bearbeiten | Quelltext bearbeiten]

Die Kommunikation zwischen Terminal und SU läuft unter anderem über den qport-tiny der Sicherheit im Sinne von security gewährleistet.

kryptographisch Funktionen[Bearbeiten | Quelltext bearbeiten]

Die verwendeten kryprographischen Funktionen stammen aus der AVR-Crypto-Lib welche gegenwärtig auch im SVN liegt. Als kryptographische Funktionen kommen zum Einsatz:

Hashfunktion[Bearbeiten | Quelltext bearbeiten]

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

HMAC[Bearbeiten | Quelltext bearbeiten]

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

PRNG[Bearbeiten | Quelltext bearbeiten]

Der PRNG ist eine "Eigenkonstruktion" und benutzt ganz viel SHA-256. Sollte auf jeden Fall nochmal genau betrachtet werden. Das derzeitige Design sieht ähnlich dem folgendem aus: PRNG1.png

Die aktuelle Version gibts gerade nur in ASCII-Art: 

*                      ################################################################################################
*                      #                                                                                              #
*                      #         +---------------------------+                                                        #
*                      #         |                           |                             +---+                      #
*                      #         V                           |                             |   |                      #
*                      #      (concat)                       |                             |   V                      #
*  +---------------+   #    o---------o             (xor)+---------+      o---------o      | o----o     o---------o   #    +--------------+
*  | entropy Block | -----> | sha-256 | --(offset)-<     | rndCore | ---> | sha-256 | --+--+-| +1 |---> | sha-256 | -----> | random Block |
*  +---------------+   #    o---------o             (xor)+---------+      o---------o   |    o----o     o---------o   #    +--------------+
*                      #                                 (xor) (xor)                    |                             #
*                      #                                   ^     ^                      |                             #
*                      #                                    \   /                       |                             #
*                      #                                   (offset)---------------------+                             #
*                      #                                                                                              #
*                      ################################################################################################




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

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


Der Code kann unter [1] eingesehen werden.

Die Initialisierung[Bearbeiten | Quelltext bearbeiten]

Managment[Bearbeiten | Quelltext bearbeiten]

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

Operationen[Bearbeiten | Quelltext bearbeiten]

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>

Mögliche Angriffe[Bearbeiten | Quelltext bearbeiten]

Weitere Ideen[Bearbeiten | Quelltext bearbeiten]

Statt der I²C-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[Bearbeiten | Quelltext bearbeiten]

  • 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!

Abgerufen von „https://wiki.das-labor.org/index.php?title=Veranstaltung/LabAccess&oldid=22740“