Spacegate.mw

   1 {{Projekt
   2 |verantwortlich={{Benutzer|DooMMasteR}}
   3 |status=aktiv
   4 |interessenten=[[Benutzer:Daniel Bohrer|Daniel Bohrer]], [[Benutzer:Hellfyre|Hellfyre]],[[Benutzer:Chrissi^|Chrissi^]], [[Benutzer:DieLenaMaria|DieLenaMaria]]
   5 }}
   6 == Idee ==
   7
   8 Das Spacegate sollte nach Möglichkeit von jedem Mitglied und ggf. auch kurzfristig autorisierten Gast geöffnet werden.
   9 Das äußere Spacegate lässt sich bisher einfach per Handy öffnen, ist zwar nicht toll, aber klappt.
  10
  11 Für das innere Gate wäre eine raffiniertere Lösung erstrebenswert.
  12
  13 Zur Verwirklichung sind 2 Hürden zu überwinden.
  14 # Authentifizierung der Person, die Zugang verlangt
  15 # ermöglichen des Zuganges
  16
  17 === Authorisierung ===
  18 Wir sollten zum Autorisieren des Zuganges ein System haben, welches folgende Bedingungen erfüllt:
  19 * Günstig
  20 * Sicher
  21 * Flexibel
  22 * PrivacyProtecting
  23 * Available
  24
  25 Das Problem ist dabei größer als es zunächst erscheint.
  26
  27 Mechanische Schlüssel scheiden aus, da sie 1. recht teuer sind und 2. bei Verlust zu Problemen in der Autorisierungskette anderer Schlüssel führen.
  28
  29 IP-Basierende Systeme scheiden aus, da sie den Betrieb eines IP-Fähigen Endgerätes voraussetzen und auch recht hohen Implementierungsaufwand auf verschiedenen Plattformen mit sich brächte.
  30 : Was ist mit [[Raspberry Pi]] ?!
  31
  32 RFID ist im Grunde sehr viel versprechend aber birgt eine gewisse Privacyproblematik in sich, die ID des Tags und damit die Traceability des Users.
  33
  34 Dennoch erscheint RFID als der Beste Ansatz, denn:
  35 * recht günstig
  36 * lässt sich vielfältig einsetzen (man könnte ungenutzte Bereiche von Karten offen für andere Nutzungen lassen)
  37 * flexibel ggf. kann ein Nutzer seine eigene Karte mitbringen und Beschreiben lassen
  38 * weit verbreitet, gerade 13,xxMHz Tags
  39 * ließe sich auch in Smartphones implementieren
  40 * einzelne Karten können bei Verlust de-autorisiert werden
  41
  42 Bleibt die privacy Problematik durch die ID, dazu: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1508247 (z.B. aus dem Uninetz lesbar)
  43
  44 Falls der Link oben nicht funktioniert (IEEE Seite hat merkwürdige Cookie-Magie), hier der DOI [http://dx.doi.org/10.1109/DEXA.2005.28 10.1109/DEXA.2005.28]
  45
  46 Lösung bisher: KEINE -.-
  47 Das Problem wäre beim Einsatz eines aktiven Tags nicht vorhanden
  48 * Der FoeBuD hat hier eine [https://shop.foebud.org/thema/stoprfid/rfid-kartenschutzetui-metall.html Lösung] (auch in anderen Ausführungen) für alle die Privacy-Bedenken mit RFID haben.
  49
  50 ==== Alternativvorschlag 1: ====
  51 * Aktiver Key auf LED-Basis
  52 ** Protokoll basierend auf http://www.merl.com/papers/docs/TR2003-35.pdf
  53 ** Hardware: umbauen einer fertigen LED-Keychain im einstelligen EUR-Bereich mit einem 8pin-uC (1EUR) und nem Widerstand
  54 ** Security: Einfachste Möglichkeit ist, eine ID, einen fixen Schlüssel der Tür und einen des Tokens direkt im uC zu speichern. Die Tür "authed" sich also beim Schlüssel, er spuckt seine ID und Schlüssel zurück. Wenn man das ganze dann noch "richtig" sicher machen will, versucht man entweder ne Hashfunktion mit auf den uC zu quetschen (http://www.das-labor.org/wiki/AVR-Crypto-Lib), oder baut einen SHA-256-chip mit ein (http://de.mouser.com/Search/Refine.aspx?Keyword=AT88SA100S).
  55 ** Nachteile:
  56 *** noch ungetestet
  57 *** Frickelarbeit mit der Keychain
  58 ** Vorteile
  59 *** LED-Funktion bleibt erhalten
  60 *** kein Problem mit der Traceability
  61 *** Sicher (je nach Aufwand)
  62 *** Ich finds cool ;)
  63
  64 Ich wollte sowas in der Art immer mal bauen, wenn ich mich selber mal hingesetzt habe und nen Prototyp läuft, berichte ich vielleicht nochmal.
  65 --[[Benutzer:Cbounce|Cbounce]] 17:09, 3. Apr. 2012 (CEST)
  66
  67 Diese Variante scheint mir hinsichtlich ESD-Beständigkeit, mechanische Festigkeit (Anzahl und Zärtlichkeit der Steckzyklen) und Wandalisussicherheit (Was ist das für eine Buchse? Mal eine Büroklammer reinstecken. Oder: Mal sehen, was passiert wenn man das Ding von aussen mit 24V versorgt... ) die bessere zu sein. Nachteil: Der Key müsste eine eigene Energieversorgung haben. --[[Benutzer:Chrissi^|Chrissi^]] 10:12, 13. Mai 2012 (CEST)
  68
  69
  70 ==== Alternativvorschlag 2: ====
  71 Die Idee gefällt, als Schlüssel hätte man einen ATtiny mit 2,5mm 4pol klinke, der UART und SHA2 kann und außerdem ein Secret enthält.
  72
  73 So mal als Pseudocode die Idee:
  74
  75 Host:
  76 <syntaxhighlight lang="C">
  77 int challenge = random();
  78 sendToKey(getKeyID, null);
  79 int keyID = getFromKey();
  80 sendToKey(authChallenge, challenge);
  81 if (sha2(keychain[keyID] + challange) == getFromKey()) {
  82   openGate();
  83 }
  84 </syntaxhighlight>
  85
  86
  87 AVR-authkey:
  88 <syntaxhighlight lang="C">
  89 void serialEvent() {
  90   if (header != null) {
  91     switch (header) {
  92        case getKeyID :
  93          uart.send(keyID);
  94        case authChallenge :
  95          uart.send(sha2(localKey + data));
  96        default :
  97          resetData();
  98       }
  99   resetData();
 100   }
 101 }
 102
 103 void resetData() {
 104   data = null;
 105   header = null;
 106 }
 107 </syntaxhighlight>
 108
 109 --[[Benutzer:DooMMasteR|DooMMasteR]] 02:06, 11. Apr. 2012 (CEST)
 110
 111 Gestern mal flink sha256 auf dem Arduino zum laufen gebracht und über jede Menge linkercrap gerannt :P
 112 aber es klappt so hacked erstmal. Die SHA256 Implementierung kommt von http://www.das-labor.org/wiki/AVR-Crypto-Lib und rennt in 0,01s über 64byte (32byte key + 32byte challenge) :). <br>
 113 https://stratum0.org/mediawiki/index.php/Spacegate/1.Crap
 114 Ist nur schnell zusammengeklatscht und sieht halt auch so aus :P aber es geht… <br>
 115 Nächster Schritt ist OneWire und Kommunikation zwischen 2 AVRs (inkl. authing :P). --[[Benutzer:DooMMasteR|DooMMasteR]] 15:35, 12. Apr. 2012 (CEST)
 116
 117
 118 Warum eigentlich 1Wire, wenn du eine 4-Pol Klinke nutzen möchtest? Bietet sich nicht eher UART (bidirektional) an?--[[Benutzer:Chrissi^|Chrissi^]] 10:12, 13. Mai 2012 (CEST)
 119
 120
 121
 122 Noch ein paar Gedanken von mir:
 123 * Anzahl der Steckzyklen einer Klinkenbuchse begrenzt. z.B. http://de.farnell.com/lumberg/1501-03/kupplung-buchse-chassis-2-5mm/dp/1200127 5k Stück. Kann zum Ausfall führen. Dabei ist die mechanische Fixierung auf der Leiterplatte nicht ohne
 124 :*Wir sind nun bei 3-Pol 6,3mm Klinke angekommen, die sind robuster (kann man schön in eine Edelstahlplatte integrieren), außerdem gibt es die Stecker in edlen vollmetall Versionen die genügen Platz für ATTiny+vllt noch LED usw. haben http://www.reichelt.de/Klinkenstecker/KSSKG-63/3/index.html?;ACTION=3;LA=446;ARTICLE=9586;GROUPID=5170;artnr=KSSKG+63 . --[[Benutzer:DooMMasteR|DooMMasteR]] 19:00, 21. Jun. 2012 (CEST)
 125 * ESD-Schutz: Alle Leitungen außer GND mit Transil-Dioden ausstatten um den Host-ATMega ein langes Leben zu garantieren.
 126 * Spannungsversorgung für Key mit Serienwiderstand oder FET-Stromquelle gegen externen Kurzschluss schützen. Eventuell zusätzlich eine Serien-Diode um Speisung von außen zu verhindern.
 127 * IO-Pins sollten dauerkurzschlussfest gegen GND und Vcc sein. Man weiß nie, was da rein gesteckt wird ;-)
 128 --[[Benutzer:Chrissi^|Chrissi^]] 10:12, 13. Mai 2012 (CEST)
 129
 130 ==== Alternativvorschlag IV ====
 131 Cam am Rasperry Pi nach draußen, Öffnung mit QR-Code. (Hat doch jeder ein Handy dabei, gell?) --[[User:Lulu|Lulu]]
 132 : Nette Idee, aber nicht besonders sicher gegen {{WP|Replay-Angriff}}e, oder? ;-) --[[Benutzer:Daniel Bohrer|Daniel Bohrer]] 02:40, 6. Jun. 2013 (CEST)
 133
 134 ==== Alternativvorschlag 5 ====
 135 Ein OAuth-System aufsetzen, das über das Space-WLAN erreichbar ist, alternativ Ethernet-Buchse nach draußen. Dann Login per Twitter/Facebook/OpenID erlauben. --[[Benutzer:Daniel Bohrer|Daniel Bohrer]]
 136
 137 === Oeffnung ===
 138
 139 Ich habe einen Tueroeffner, den man vermutlich oben in den Tuerrahmen einbauen kann. Bei Anlegen von 12V gibt das frei. habs allerdings nie ausprobiert. Ich brings mal mit demnaechst --[[Benutzer:Valodim|Valodim]] 20:04, 30. Mär. 2012 (CEST)
 140
 141 :Liegt jetzt übrigens hier im Lounge-Regal. --[[Benutzer:Daniel Bohrer|Daniel Bohrer]] 22:24, 2. Apr. 2012 (CEST)
 142 ::ist aber ohne Austausch der Schließmechanik leider sehr unsicher, ein Servo am Schließzylinder auf der Innenseite ist wohl sinvoller. --[[Benutzer:DooMMasteR|DooMMasteR]] 02:08, 11. Apr. 2012 (CEST)
 143 : Der Öffner sagt, er braucht 6V bis 12V. Hab's eben mit dem 5,7V-Netzteil vom Tür-Handy probiert, geht. --[[Benutzer:DieLenaMaria|DieLenaMaria]] 13:03, 27. Mai 2012 (CEST)
 144
 145 == Projekttag ==
 146
 147 Da nun ja eigentlich nurnoch wenige Schritte zur Umsetzung fehlen, hatte Oni die Idee einen Projekttag zum Abschluss der Planungsphase/Entwicklungsphase zu machen.
 148
 149 Es würde dann die Platine für den Master erstellt werden/ggf erstmal nur Breadboard Aufbau, BOMs erstellen, für Keys und Master, Software finalisieren und implementierung auf ALEX oder RPi testen, Zeug bestellen.
 150
 151 Als mögliche Termine kommen der 3.-4.01.2013 in Frage, daher ein kleines Doodle [http://doodle.com/c5nsnbxuq3sp683a] daher die Bitte an alle Interessenten, das Doodle zu füllen :).
 152
 153 == Alte Diskussion ==
 154 ''…wurde vorher auf [[Open/Close-Monitor]] geführt, hier der Vollständigkeit halber hinverschoben --[[Benutzer:Daniel Bohrer|Daniel Bohrer]] 12:17, 31. Mär. 2012 (CEST)''
 155
 156 Falls der Space sich hinreichend entwickelt hat, kann über weitergehende Maßnahmen nachgedacht werden. Im µCCC z.B. wird die Türschließung durch ein [https://wiki.muc.ccc.de/luftschleuse Zugangssystem per SSH] gesteuert.
 157
 158 === Verbesserung der Klingel ===
 159 …wenn wir grad schonmal am Klingelhacken sind. Im Chat kam der Vorschlag nach einer optischen Klingel (Blinken o.ä.). Alternativ, falls alle Spaceinsassen gerade schlafen:
 160
 161  [11:59:51] <rohieb> dann die sofas mit drahtgeflecht versehen und die klingel stromschläge draufgeben lassen?
 162  [12:00:04] <tommie-lie> schon besser
 163  [12:00:04] <neobechstein> :D
 164  [12:00:06] <neobechstein> rohieb: +1
 165
 166 Alternativ wäre zu überlegen, ob man [[ZombiePoet]] beibringt, Klingelevents im IRC zu verkünden. Bzw, wenn an der Tür später eh ein µC/ARM oder ähnliches mit Netzwerk hängt, könnte man dort direkt einen IRC-Bot implementieren ;-) (ZombiePoet läuft ja auf einem externen Server, das würde dann nur noch eine Schicht mehr hinzufügen)
 167
 168 [[Kategorie:Infrastruktur]]