1 Termine ins Archiv verschoben
[stratum0-wiki.git] / Spacegate.mw
index 08c2286..b69bb3b 100644 (file)
@@ -8,37 +8,38 @@
 Das Spacegate sollte nach Möglichkeit von jedem Mitglied und ggf. auch kurzfristig autorisierten Gast geöffnet werden.
 Das äußere Spacegate lässt sich bisher einfach per Handy öffnen, ist zwar nicht toll, aber klappt.
 
-Für das Innere Gate wäre eine raffinierter Lösung erstrebenswert.
+Für das innere Gate wäre eine raffiniertere Lösung erstrebenswert.
 
 Zur Verwirklichung sind 2 Hürden zu überwinden.
-#Authetifizierung der Person die Zugang verlangt
-#ermöglichen des Zuganges
+# Authentifizierung der Person, die Zugang verlangt
+# ermöglichen des Zuganges
 
 === Authorisierung ===
 Wir sollten zum Autorisieren des Zuganges ein System haben, welches folgende Bedingungen erfüllt:
-*Günstig
-*Sicher
-*Flexibel
-*PrivacyProtecting
-*Available
+* Günstig
+* Sicher
+* Flexibel
+* PrivacyProtecting
+* Available
 
-Das Problem ist dabei größer als es Zunächst erscheint.
+Das Problem ist dabei größer als es zunächst erscheint.
 
 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.
 
 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.
+: Was ist mit [[Raspberry Pi]] ?!
 
 RFID ist im Grunde sehr viel versprechend aber birgt eine gewisse Privacyproblematik in sich, die ID des Tags und damit die Traceability des Users.
 
 Dennoch erscheint RFID als der Beste Ansatz, denn:
-*recht günstig
-*lässt sich vielfältig einsetzen (man könnte ungenutzte Bereiche von Karten offen für andere Nutzungen lassen)
-*flexibel ggf. kann ein Nutzer seine eigene Karte mitbringen und Beschreiben lassen
-*weit verbreitet, gerade 13,xxMHz Tags
-*ließe sich auch in Smartphones implementieren
-*einzelne Karten können bei Verlust de-autorisiert werden
+* recht günstig
+* lässt sich vielfältig einsetzen (man könnte ungenutzte Bereiche von Karten offen für andere Nutzungen lassen)
+* flexibel ggf. kann ein Nutzer seine eigene Karte mitbringen und Beschreiben lassen
+* weit verbreitet, gerade 13,xxMHz Tags
+* ließe sich auch in Smartphones implementieren
+* einzelne Karten können bei Verlust de-autorisiert werden
 
-bleibt die privacy Problematik durch die ID, dazu: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1508247 (z.B. aus dem Uninetz lesbar)
+Bleibt die privacy Problematik durch die ID, dazu: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1508247 (z.B. aus dem Uninetz lesbar)
 
 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]
 
@@ -120,12 +121,18 @@ Warum eigentlich 1Wire, wenn du eine 4-Pol Klinke nutzen möchtest? Bietet sich
 
 Noch ein paar Gedanken von mir:
 * 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
+:*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)
 * ESD-Schutz: Alle Leitungen außer GND mit Transil-Dioden ausstatten um den Host-ATMega ein langes Leben zu garantieren.
 * 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.
 * IO-Pins sollten dauerkurzschlussfest gegen GND und Vcc sein. Man weiß nie, was da rein gesteckt wird ;-)
 --[[Benutzer:Chrissi^|Chrissi^]] 10:12, 13. Mai 2012 (CEST)
 
+==== Alternativvorschlag IV ====
+Cam am Rasperry Pi nach draußen, Öffnung mit QR-Code. (Hat doch jeder ein Handy dabei, gell?) --[[User:Lulu|Lulu]]
+: Nette Idee, aber nicht besonders sicher gegen {{WP|Replay-Angriff}}e, oder? ;-) --[[Benutzer:Daniel Bohrer|Daniel Bohrer]] 02:40, 6. Jun. 2013 (CEST)
 
+==== Alternativvorschlag 5 ====
+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]]
 
 === Oeffnung ===
 
@@ -135,6 +142,14 @@ Ich habe einen Tueroeffner, den man vermutlich oben in den Tuerrahmen einbauen k
 ::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)
 : 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)
 
+== Projekttag ==
+
+Da nun ja eigentlich nurnoch wenige Schritte zur Umsetzung fehlen, hatte Oni die Idee einen Projekttag zum Abschluss der Planungsphase/Entwicklungsphase zu machen.
+
+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. 
+
+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 :).
+
 == Alte Diskussion ==
 ''…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)''
 
This page took 0.024247 seconds and 4 git commands to generate.