Hi, ich habe mich in letzter Zeit ein wenig mit RFID bzw. NFC auseinander gesetzt und möchte es einsetzen, um mich an einer elektronisch gesperrten Tür zu authentifizieren. Dabei handelt es sich natürlich um ein Hobby-Projekt und nicht um den Zugang zu irgendeinem Hochsicherheitstrakt. Dennoch bin ich mit den gängigen Lösungen bzw. Projekten, die man unter o.g. Stichwörtern so findet, absolut unzufrieden. Im Wesentlichen läuft es darauf hinaus, dass auf dem Tag irgendein eindeutiger Token hinterlegt ist, und dieser wird dann ausgelesen und entsprechend überprüft. Der durchschnittliche Hobbyist scheint sich damit auch zufrieden zugeben. Mir reicht das aber deswegen nicht, weil sich die Tags ja relativ einfach kopieren lassen. Zwar gibt es durchaus welche mit einem nicht beschreibbaren Bereich, aber so recht trauen tue ich der Sache dennoch nicht. Ich hätte da lieber etwas auf Basis einer Challenge-Response-Authentifizierung. Außerdem sollte das Ganze nach Möglichkeit standardisiert und von der Krypto-Gemeinschaft "abgesegnet" sein. Im Idealfall sollte es dann noch ein Public-Key-Kryptosystem sein, sodass sich Zugänge bequem verwalten (d.h. anlegen und sperren) lassen. Proprietäre Lösungen jedenfalls bieten da wenig bis keine Sicherheit, siehe z.B. [1]. Im Endeffekt würde ich gerne mein Android-Smartphone benutzen. Android bietet da auch entsprechende APIs (siehe [2]). Auf den ersten (bzw. zweiten ;)) Blick scheint es mir aber so, dass man da manuell mit einem entsprechenden Protokoll aufwarten müsste. Einen Standard oder ähnliches konnte ich jedenfalls nicht finden. Das ist natürlich zum Einen fehlerbehaftet (sowohl konzeptionell als auch in der Implementierung selbst) und zum Anderen nicht gerade wenig Arbeit - wenn man es richtig machen möchte. Daher würde ich gerne nach zum Thema passenden Quellen bzw. Referenzen fragen. Vielleicht findet sich ja jemand, der bereits vor einer ähnlichen Herausforderung stand bzw. schon etwas mehr Erfahrungen in diesem Gebiet sammeln konnte. Um ehrlich zu sein bin ich mir auch nicht ganz sicher, ob das das richtige Forum ist. Es geht hier zunächst einmal weniger um die dazugehörige Elektronik, sondern erst einmal um das Konzept an sich. Allerdings finden sich ja hier sicherlich einige, die schon Erfahrungen in diesem Gebiet gesammelt haben. Vielen Dank! [1]: https://de.wikipedia.org/wiki/Mifare [2]: https://developer.android.com/guide/topics/connectivity/nfc/advanced-nfc.html
Interessant, genau so ein Projekt werde ich in naher Zukunft auch für meine Haustür realisieren. Also Mobi an die Haustür halten und diese geht auf. Habe mich schon weit in die Kryptographie eingelesen und denk, dass ein Public-Key Verfahren für diese Anwendung total drüber ist (Rechenleistung, Ablauf, etc.). Auf der inneren Seite der Haustür soll sich lediglich ein kleiner Mikrocontroller befinden, der dann in annehmbarer Zeit den Summer der Tür ansteuert. Aus diesem Grund läuft es auf ein AES verschlüsseltes Challenge-Response Verfahren hinaus. Heißt: Tür sendet verschlüsselte Nonce(mit PRNG) -> Mobi entschlüsselt und bildet Hashwert mit einem Geheimnis über diese, verschlüsselt den Hashwert und sendet diesen an die Tür -> Tür bildet ebenfalls den Hashwert und vergleicht das Ergebnis ... Das Sperren von Zugängen ist z.B. mit einer zusätzlichen ID möglich, die das Mobi mit dem HASH verschlüsselt sendet. Dieses Verfahren ist sicher genug für die beschriebene Anwendung! Gruß
Ape schrieb: > denk, dass ein Public-Key Verfahren > für diese Anwendung total drüber ist (Rechenleistung, Ablauf, etc.). Meistens wahrscheinlich schon. Sobald ich eine Zertifizierungsstelle (CA) integrieren möchte brauche ich das natürlich. Aber nur für eine Tür ist das wohl übertrieben. > Aus diesem Grund läuft es auf ein AES verschlüsseltes Challenge-Response > Verfahren hinaus. Heißt: Tür sendet verschlüsselte Nonce(mit PRNG) -> > Mobi entschlüsselt und bildet Hashwert mit einem Geheimnis über diese, > verschlüsselt den Hashwert und sendet diesen an die Tür -> Tür bildet > ebenfalls den Hashwert und vergleicht das Ergebnis ... Auch das ist aufwendiger als nötig. Die Tür sendet das Nonce unverschlüsselt. Das RFID-Gerät erzeugt einen Hash (hier einen sicheren nehmen, mindestens SHA1, besser SHA2) über Nonce + Geheimnis und sendet das Hash-Ergebnis zurück. Die Tür kennt auch das passende Geheimnis und kann ihr Hash-Ergebnis mit dem empfangenen vergleichen. Fertig. Kein AES benötigt, nur einen Hash. Ein Angriffsszenario sollte man allerdings nicht außer Acht lassen: Ich sitze mit dem RFID-Token im Cafe. Angreifer 1 peilt das Ding mit ner starken Antenne von ein paar Tischen weiter an. Er sendet die Daten z.B. per UMTS zu Angreifer 2 der vor der RFID-gesicherten Tür steht. Die Authentifizierung wird über das UMTS weitergeleitet und die Tür öffnet für Angreifer 2. Klassischer Konter gegen diesen Angriff ist, die Zeit die das RFID-Token zum hashen bekommt stark zu begrenzen und so den Weg über die Funk-Weiterleitung unmöglich zu machen. LTE hat jetzt aber ziemlich geringe Latenzen, wird also immer schwerer das so zu machen. Für Autos wurde ein solcher Angriff schon praktisch demonstriert.
Ape schrieb: > Auf der inneren Seite der Haustür soll sich lediglich ein kleiner > Mikrocontroller befinden, der dann in annehmbarer Zeit den Summer der > Tür ansteuert. Ich hätte prinzipiell auch kein Problem damit, da etwas rechenstärkeres zu platzieren, wie z.B. einen Raspberry Pi bzw. GNUblin. Ape schrieb: > Dieses Verfahren ist sicher genug für die beschriebene Anwendung! Schön, dass du für mich entscheiden willst, dass es sicher genug ist ;). Ein "fester" Token wäre wahrscheinlich auch sicher genug - oder ein klassisches Schloss. Einen Schlüssel kann man immerhin auch nachmachen. Mir geht es hier halt im Rahmen eines Hobbyprojekts um ein möglichst "perfektes" Konzept. Public-Key Kryptografie wäre da schon sehr wünschenswert. Zunächst gibt es aber sowieso nur eine Tür und ein Token. Insofern erst einmal Overkill. Die gängigen "Protokolle" bzw. die dahinterstehenden Konzepte kenne ich durchaus. Ich hätte halt nur gern auf etwas solideres als eine Eigenentwicklung im Hobbybereich gesetzt. Die Geschichte der "modernen" Kryptologie ist voller Beispiele, dass Eigenentwicklungen ohne Rücksprache mit der Crypto-Community eigentlich immer ein Pfusch sind. Die o.g. proprietären Lösungen zeigen dies ja mal wieder eindrucksvoll. Daher würde ich halt gerne wissen, ob es ggf. schon entsprechende Standards bzw. Implementierungen im Bereich der Authentifizierung mittels NFC/RFID gibt. Meine (vielleicht etwas zu oberflächlichen) Recherchen jedenfalls haben nicht wirklich etwas ergeben. Gerd E. schrieb: > Klassischer Konter gegen diesen Angriff ist, die Zeit die das RFID-Token > zum hashen bekommt stark zu begrenzen und so den Weg über die > Funk-Weiterleitung unmöglich zu machen. Der einzige richtige Konter wäre wohl eher eine Zwei-Faktor-Authentifizierung z.B. mittels einer Pin-Eingabe an der Tür selbst. Oder aber das Aufbewahren des Tokens in Alufolie ;). Wie auch immer - das ist ein Angriffsvektor der mich erst einmal nicht interessiert. Wenn jemand nämlich dazu in der Lage ist, dann kann er meine Tür genausogut mechanisch "öffnen". Da ich ja sowieso im "Cafe" bin, bekomme ich es eh nicht mit ;). Gerd E. schrieb: > Für Autos wurde ein solcher Angriff schon praktisch demonstriert. Hast du da vielleicht entsprechende Referenzen bzw. Links? Interessant zum Durchschauen wäre es sicherlich.
K. B. schrieb: >> Für Autos wurde ein solcher Angriff schon praktisch demonstriert. > > Hast du da vielleicht entsprechende Referenzen bzw. Links? Interessant > zum Durchschauen wäre es sicherlich. http://heise.de/-1165992
K. B. schrieb: > Schön, dass du für mich entscheiden willst, dass es sicher genug ist ;). Nope, war auf mein Bsp. bezogen. K. B. schrieb: > Public-Key Kryptografie wäre da schon sehr > wünschenswert. Wer hält dich davon ab? Erstell deine eigene CA und signier dir dann die Zertifikate für die verschiedenen Nutzer. Ich hätte keine Lust 1 Minute vor der Tür zu stehen bis die sich öffnet ;). Natürlich abhängig von der Rechenleistung :P. Weitere möglichkeit um PK-Verfahren auf kleinen Controllern einzusetzen ist sich einen zusätzlichen Crypto-Controller zu besorgen und diesen die aufwändigen Rechnungen durchführen zu lassen. K. B. schrieb: > Ich hätte halt nur gern auf etwas solideres als eine > Eigenentwicklung im Hobbybereich gesetzt. Hmm, wo ist die Eigenentwicklung bei dem Verfahren? C-P ist ein durchaus anerkanntes Protokoll. Und solange du nicht MD2 oder sonst etwas verwendest durchaus sicher (meine Wahl wäre SHA256). Gerd E. schrieb: > Auch das ist aufwendiger als nötig. Die Tür sendet das Nonce > unverschlüsselt Da hast du wohl recht, jedoch anfällig auf Know-Plaintext und Wörterbuch Angriffe. Kommt halt immer drauf an was man möchte. AES ist jetzt nicht so aufwändig. Das schafft jeder uC in kurzer Zeit. Das interesse in meine Wohnung einzubrechen dürfte wohl gegen 0 gehen :). Trotzdem würde ich einen verschlüsselten CR vorziehen. K. B. schrieb: > Der einzige richtige Konter wäre wohl eher eine > Zwei-Faktor-Authentifizierung z.B. mittels einer Pin-Eingabe an der Tür > selbst. Oder aber das Aufbewahren des Tokens in Alufolie ;). Bevor das Mobi die Authentifikation startet, muss auf dem Display ein Button betätigt werden. Wenn das Mobi geklaut wird, kann man auch nur die Wohnung betreten, wenn der Angreifer die Tastensperre (wenn eingerichtet) entsperren kann. Also sicherer als ein Schlüssel ;). Gruß
Ape schrieb: > Natürlich abhängig von der > Rechenleistung :P. Eben. Und bei Verwendung von etwas wie einem Raspberry Pi (der dann auch einfachen Netzwerkzugriff erlauben würde), sollte das doch kein Problem sein. Beim Surfen durch das Internet passiert das ja auch dutzendfach ... Ape schrieb: > Hmm, wo ist die Eigenentwicklung bei dem Verfahren? Mit dem Verfahren an sich ist es ja nicht getan. Man braucht ja - gerade beim Einsatz von Public-Key-Krypto durchaus eine entsprechende Infrastruktur und muss die verschiedenen Konzepte miteinander "verbinden". Dabei entstehen erfahrungsgemäß nun einmal Fehler - zu Mal ich kein Krypto-Experte bin - wahrscheinlich genauso wenig wie der Rest hier :). Ape schrieb: > Bevor das Mobi die Authentifikation startet, muss auf dem Display ein > Button betätigt werden. Ja, das ist eine Überlegung wert. Mal sehen: Meiner Erfahrung nach ist ja "Funkradius" bei NFC stark begrenzt. Inwiefern da solche (theoretischen) Relay-Attacken also wirklich von Bedeutung sind, muss ich mir erst noch klar machen.
K. B. schrieb: > Mit dem Verfahren an sich ist es ja nicht getan. Man braucht ja - gerade > beim Einsatz von Public-Key-Krypto durchaus eine entsprechende > Infrastruktur Das sei mal dahingestellt. Besorg dir erst mal ein paar Bücher! Was ich empfehlen kann, ist das Buch: Kryptohrapfie von Klaus Schmeh. Wenn du das durchgearbeitet hast, wirst du einen anderen Blick auf die ganze Sache haben ;). Du wirst merken das die ganzen Verfahren und Protokolle und gerade die Infrastruktur kein Hexenwerk sind :). Zur Infrastruktur selbst von PK Systemen: Bei einer geringen Anzahl von Kommunikationspartner brauchst du nicht unbedingt eine PKI. "Lerne" einfach die verschiedenen User an dem Host System an. Dafür reicht es, wenn der Host den öffentlichen Schlüssel des Users speichert und der User den öffentlichen Schlüssel des Hosts. Jetzt sind beide Systeme bekannt und können auch nur untereinander Kommunizieren. Zum Öffnen der Tür sendet der Host einfach eine Nonce(mit seinem privaten Schlüssel verschlüsselt) und der User verschlüsselt diese dann mit seinem privaten Schlüssel. -> Alles gut = Tür offen. Würde hier jedoch eine symmetrisches Verfahren vorziehen ;). Wenn du auch usern unbekannter Herkunft Zutritt gewähren möchtest, dann benötigst du eine PKI zur Zertifikatserstellung. Der Unbekannte lässt sich dann ein Zertifikat von der CA ausstellen usw. Gruß
Also da niemand von uns genügend Ahnung von Kryptographie hat und da wir hier eh von Android Geräten reden kann man das auch gleich simpel und einfach machen. Man nimmt ssh. Ssh unterstützt Authentifizierung per Public Key. Sprich man erstellt ein Schlüsselpaar auf dem Mobilgerät, nimmt den öffentlichen Schlüssel, legt den in die .ssh/authorized_keys Datei auf einem Raspberry PI (oder einem Router). Dann stellt man in der /etc/passwd die shell dieses speziellen "Schließnutzers" auf ein kleines Programm das das Schloss öffnet, und setzt das Passwort auf nicht einlogbar. Jetzt logt man sich über ssh als diese Nutzer ein, die Authentifizierung erfolgt über den öffentlichen Schlüssel, als Shell wird das Schloss geöffnet, und der Benutzer wird wieder raus geschmissen. Die Kommunikation kann beispielsweise über WLAN erfolgen. Die Vorteile davon sind: 1. Auf alle kryptographischen Komponenten hat schon mal jemand mit Verstand drauf geschaut. 2. Es geht extrem einfach mit simpler Hardware wie einem Raspberry PI. Zumindest der Elektronikteil davon ist deutlich sicherer als alles was kommerziell verfügbar ist.
Ape schrieb: > Wenn du > das durchgearbeitet hast, wirst du einen anderen Blick auf die ganze > Sache haben ;). Das glaube ich kaum. Wie gesagt: Prinzipiell halte ich das durchaus für implementierbar. Allerdings zeigt halt die Erfahrung, dass man da leicht etwas falsch machen kann bzw. gerne etwas übersieht. Und das Problem ist halt, dass ein solches Kryptosystem selbst bei kleinen Fehlern leicht in sich "zusammenbrechen" kann. Christian Berger schrieb: > da wir > hier eh von Android Geräten reden kann man das auch gleich simpel und > einfach machen. > > Man nimmt ssh Sorry, aber das halte ich für einen der schlechtesten Ansätze überhaupt. Das hat ein Hackerspace so bereits umgesetzt (https://wiki.muc.ccc.de/luftschleuse). Ich persönlich halte das für einen schlechten Witz. Zum Einen dürfte das auf der Seite des Mobiltelefons absolut "unpraktisch" sein - vor allem wenn man mit einer sicheren Passphrase arbeitet und diese erst eingeben müsste. Gut man kann das sicherlich benutzerfreundlicher gestalten und sogar eventuelle einen entsprechenden Passphrase Agent verwenden, aber das Gelbe vom Ei wirds nicht werden. Des Weiteren fügt das nur einen Haufen Fehlerquellen ein. Da hätten wir das Netzwerk und ein komplettes Betriebssystem. Wenn da mal etwas schief geht (und sei es etwas banales wie ein Stromausfall, der den Access Point betrifft), dann schaut es mau aus. Ein einzelner Mikrocontroller (bzw. z.B. ein Raspberry Pi) lässt sich da einfach von einer Batterie versorgen als eine ganze Netzwerkstruktur in die ich das einbinden müsste. Zeittechnisch dürfte das auch eine Katastrophe sein. Ich will nicht vor der Tür stehen und warten bis mein Handy sich per W-Lan verbunden hat und konfiguriert (DHCP) hat um dann anschließend manuell etwas auf dem Handy zu starten und dann darauf zu warten, dass sich die Tür öffnet. Genau dafür ("schnell & unkompliziert") wurde NFC gemacht. Das vereinfacht die Sache doch enorm.
Christian Berger schrieb: > Zumindest der Elektronikteil davon ist deutlich sicherer als alles was > kommerziell verfügbar ist. Um darauf nochmal zurück zu kommen: Mit der Elektronik hat das rein gar nichts zu tun. Ich müsste meine Magnetverriegelung genauso ansteuern wie davor. Das betrifft einzig und allein die Software. Ja, die ist zumindest etabliert und wahrscheinlich fehlerärmer als eine Eigenimplementierung. Aber auch da gab es (z.B. bei Debian) schon Probleme, siehe http://jblevins.org/log/ssh-vulnkey
Hi! hast du hier schon fortschritte gemacht? Beschäftige mich auch gerade mit PKI per NFC für ein UNI-Projekt. Nach meinen Recherchen dürfte per NFC am Smartphonehauptsächlich Android Beam, Profile und so Spielereien funktionieren. Ein Problem am Smartphone ist auch das Secure Element - also wo du die Zertifikate abspeicherst. Die einzige offene Lösung sind secure SD Cards - die sind aber recht schwer zu bekommen. Vor allem in kleinen Stückzahlen konnte ich noch gar nichts finden. Mit einer Mifare Desfire karte werde ich es als nächstes probieren, wenn der Rest einmal funktioniert, ist der Umstieg aufs Smartphonedann auch kein Problem mehr... Hier könnte man die Sicherheit sogar erhöhen - wenn Smartphone und NFC Reader (an einem RPi o.ä.) mit dem internetverbunden sind, könnte der Reader eine zusätzliche Verbindung über diesen Kanal aufbauen und so Relay Attacken verhindern. Andererseits wurde mir auch schon erklärt, dass Standardkonforme NFC Implementierungen nicht anfällig gegen Relay Attacken sind. Das ist nur Möglich wenn die Timeouts zu lasch/gar nicht gehalten werden. (zb bei Kreditkarten wegen Rückwärtskompatibilität: NFC-Kreditkarte <-> Android als Reader <-> Internet <-> Android Card Emulation <-> Bezahlterminal) Bin auch noch am recherchieren wie weit die Unterstützung für asymmetrische Verschlüsselung mit freien Tools wie libnfc & Co überhaupt schon möglich ist. Gibt ein paar Projekte dazu zB.: https://code.google.com/p/nfcdoorlock/wiki/Info und einige Arbeiten mit Lösungswegen - zumindest theoretischen, aber ich bin mir immer unsicherer, ab davon eine wirklich praktisch nutzbar ist. Smart Keys for Cyber-Cars http://www.trust.informatik.tu-darmstadt.de/publications/publication-details/?no_cache=1&tx_bibtex_pi1%5Bpub_id%5D=TUD-CS-2013-0004 sg Dirm
Christian Berger schrieb: > Die Vorteile davon sind: > 1. Auf alle kryptographischen Komponenten hat schon mal jemand mit > Verstand drauf geschaut. Ach ja?! Ich erinnere bloß mal an das Debilian-SSL-Debakel. Ist noch garnicht so lange her... Und was die Sicherheit von PKI betrifft: Ich erinnere an das "niederländische" (eigentlich aber weltweite) Debakel um die Sicherheit und Vertrauenswürdigkeit der CAs. Auch noch nicht sehr lange her... Inwieweit diesbezüglich auch noch Herr Snowden für interessante neue Sachverhalte sorgen wird, ist auch noch alles andere als klar. Mich würde es jedenfalls keinesfalls wundern, wenn die NSA Zugang zu den privaten Schlüsseln ALLER großen CAs hätte. Angesichts dieser Sachverhalte ist eine (kryptographisch vielleicht nicht wirklich gegen jeden Angriffsvektor sichere) proprietäre Lösung jederzeit vorzuziehen. Jedenfalls solange es eine kleine Lösung für die eigenen drei oder fünf Türen bleibt. Gefährlich wird es erst dann, wenn sowas massenhaft benutzt wird und damit das Interesse potentieller (und hinreichend fähiger) Angreifer weckt.
Hi, Bernhard Müller schrieb: > hast du hier schon fortschritte gemacht? Nein. Bisher ist es bei einer mechanischen Lösung (Schloss) geblieben. Für eine Eigenentwicklung hatte ich weder Zeit noch Nerv. Vielleicht in den kälteren Herbst bzw. Wintermonaten wieder. > Beschäftige mich auch gerade > mit PKI per NFC für ein UNI-Projekt. Auf jeden Fall ein interessantes Thema. > Nach meinen Recherchen dürfte per > NFC am Smartphonehauptsächlich Android Beam, Profile und so Spielereien > funktionieren. Ja, machbar sollte es definitiv sein. > Ein Problem am Smartphone ist auch das Secure Element - also wo du die > Zertifikate abspeicherst. Die einzige offene Lösung sind secure SD Cards > - die sind aber recht schwer zu bekommen. Da kenne ich mich um ehrlich zu sein nicht aus. Was spricht gegen den Zertifikatsspeicher von Android? > Mit einer Mifare Desfire karte werde ich es als nächstes probieren, Mich haben die proprietären Lösungen absolut nicht überzeugen können. Die billigen sowieso nicht, und gerade Mifare hat sich in Sachen Kryptografie keinen guten Namen gemacht. Als Einstiegspunkt aber vielleicht gut genug. > Hier könnte man die Sicherheit sogar erhöhen - wenn Smartphone und NFC > Reader (an einem RPi o.ä.) mit dem internetverbunden sind, könnte der > Reader eine zusätzliche Verbindung über diesen Kanal aufbauen und so > Relay Attacken verhindern. Ist halt die Frage wie "praxistauglich" das Ganze dann noch ist. Zu lange sollte das nämlich nicht dauern, weil man nur ungern vor der Tür warten möchte. Auch ist es fraglich, inwiefern der Reader überhaupt eine Verbindung mit dem mobilen Gerät aufbauen kann (NAT & Co.). Außerdem würde das nur Sinn machen, sofern man am Smartphone noch etwas absegnen müsste. Das macht es wiederum "unpraktisch". Man denke an den Fall der "vollen" Hände nach dem Einkauf. > Andererseits wurde mir auch schon erklärt, > dass Standardkonforme NFC Implementierungen nicht anfällig gegen Relay > Attacken sind. Das ist nur Möglich wenn die Timeouts zu lasch/gar nicht > gehalten werden. (zb bei Kreditkarten wegen Rückwärtskompatibilität: > NFC-Kreditkarte <-> Android als Reader <-> Internet <-> Android Card > Emulation <-> Bezahlterminal) Gibt es dafür Referenzen? Ich kenne die Spezifikationen nicht. > Bin auch noch am recherchieren wie weit die Unterstützung für > asymmetrische Verschlüsselung mit freien Tools wie libnfc & Co überhaupt > schon möglich ist. Ich habe "damals" nichts Fix und Fertiges finden können. c-hater schrieb: > Christian Berger schrieb: > >> Die Vorteile davon sind: >> 1. Auf alle kryptographischen Komponenten hat schon mal jemand mit >> Verstand drauf geschaut. > > Ach ja?! > > Ich erinnere bloß mal an das Debilian-SSL-Debakel. Ist noch garnicht so > lange her... Ich hatte das ja bereits oben erwähnt. Mittlerweile ist es doch schon eine ganze Weile her. Übrigens könnte man das auch so interpretieren, dass das Open-Source Prinzip hier geklappt hat, weil es ja letztendlich doch entdeckt wurde. Meines Wissens gibt es auch keine Berichte davon, dass das ganze "in the wild" eingesetzt wurde. > Und was die Sicherheit von PKI betrifft: Ich erinnere an das > "niederländische" (eigentlich aber weltweite) Debakel um die Sicherheit > und Vertrauenswürdigkeit der CAs. Das hat aber nur bedingt etwas mit PKI zu tun. Solange ich die PKI selbst betreibe, muss ich nur mir selbst vertrauen. Dass unser (Browser-)SSL Modell "kaputt" ist, sollte bei der enormen Anzahl an CAs jedem klar sein. Eine einzelne kompromitierte CA reicht ja bereits aus, um Schaden anzurichten. > Inwieweit diesbezüglich auch noch Herr Snowden für interessante neue > Sachverhalte sorgen wird, ist auch noch alles andere als klar. Mich > würde es jedenfalls keinesfalls wundern, wenn die NSA Zugang zu den > privaten Schlüsseln ALLER großen CAs hätte. Interessante Theorie. Wobei das auch nur bedingt wirkungsvoll ist. Die NSA könnte damit ein paar MITM Angriffe starten. Diese wiederum würden sich aber ziemlich leicht feststellen lassen. Dafür gibt es entsprechende Browserplugins. Bekannt sind solche Angriffe meines Wissens nach nur vom Iran. > Angesichts dieser Sachverhalte ist eine (kryptographisch vielleicht > nicht wirklich gegen jeden Angriffsvektor sichere) proprietäre Lösung > jederzeit vorzuziehen. Das ist nicht dein Ernst, oder? Proprietäre Lösungen sind in den meisten Fällen ein totaler Pfusch. Selbst wenn es kein Pfusch sein sollte, kann man sich nie sicher sein, dass es nicht doch irgendwelche Hintertürchen gibt. Wenn du schon Snowden erwähnst, dann wäre doch die "Verschlüsselung" von Outlook & Co. ein Musterbeispiel dafür, dass man proprietären Lösungen niemals vertrauen sollte. > Jedenfalls solange es eine kleine Lösung für die > eigenen drei oder fünf Türen bleibt. Ich persönlich habe hier immer davon gesprochen, dass ich an einer "perfekten" bzw. der "besten" Lösung interessiert bin. Dass das für eine einzelne Tür Overkill ist, war mir klar. Andererseits halte ich die meisten der Frickellösungen, die schlichtweg ein und denselben Wert einlesen, für nicht sicher genug. > Gefährlich wird es erst dann, wenn > sowas massenhaft benutzt wird und damit das Interesse potentieller (und > hinreichend fähiger) Angreifer weckt. Naja, mit der Begrüdung "interessiert ja eh keinen" kann man halt nicht schlechte Kryptografie rechtfertigen. Dann kann man sich das Ganze nämlich gleich sparen.
Ich schaue mir gerade das hier an: ATSHA204 und ATECC108 Das erste erlaubt die symmetrische Variante, das zweite ist ideal für public key. http://www.atmel.com/products/Other/cryptoauthentication/atmel_cryptoauthentication.aspx
K. B. schrieb: >> Ein Problem am Smartphone ist auch das Secure Element - also wo du die >> Zertifikate abspeicherst. Die einzige offene Lösung sind secure SD Cards >> - die sind aber recht schwer zu bekommen. > > Da kenne ich mich um ehrlich zu sein nicht aus. Was spricht gegen den > Zertifikatsspeicher von Android? naja ohne Secure Element werden die Zertifikate einfach im Speicher abgelegt, d.h. du kannst sie einfach kopieren. Secure Element kann die SIM Karte sein, dazu brauchst du aber einen Provider - das ist auch für viele kommerzielle Produkte eine Nummer zu groß... Option 2 sind eingebaute TPM Elemente und Co. Nutzt zb Google Wallet - hier lässt dich aber wieder Google und Co nicht ran. Option 3 secure micro SD Card - das ist Quasi eine SmartCard im SD Karten Format. d.h. du kannst Zertifikate sicher ablegen (vgl Desfire & Co) und hast auch Speicher dabei wie bei einer "normalen" SD card. Diese Karte wurde aber erst im Juni 2013 offiziell in denn SD-Card Standard aufgenommen. Es gibt zwar schon seit einigen Jahren so Karten, aber die sind sehr schwer zu bekommen und oft nur mit SDK 1000$ und mehr. > Mich haben die proprietären Lösungen absolut nicht überzeugen können. > Die billigen sowieso nicht, und gerade Mifare hat sich in Sachen > Kryptografie keinen guten Namen gemacht. Als Einstiegspunkt aber > vielleicht gut genug. naja um eine "SmartCard" in welcher Form auch immer kommst du nicht herum >> Andererseits wurde mir auch schon erklärt, >> dass Standardkonforme NFC Implementierungen nicht anfällig gegen Relay >> Attacken sind. Das ist nur Möglich wenn die Timeouts zu lasch/gar nicht >> gehalten werden. (zb bei Kreditkarten wegen Rückwärtskompatibilität: >> NFC-Kreditkarte <-> Android als Reader <-> Internet <-> Android Card >> Emulation <-> Bezahlterminal) > > Gibt es dafür Referenzen? Ich kenne die Spezifikationen nicht. wurde mir nur telefonisch von der Firma Cryptas erklärt. Die haben aber auch erst einzelne Tests laufen und meinen das es noch recht instabil und hauptsächlich mit alten Nokia Teilen funktioniert. (Authentifizierung per NFC am Smartphone) Hier muss man aber bedenken, dass die natürlich vorerst die etablierten stabilen Lösungen verkaufen wollen... >> Und was die Sicherheit von PKI betrifft: Ich erinnere an das >> "niederländische" (eigentlich aber weltweite) Debakel um die Sicherheit >> und Vertrauenswürdigkeit der CAs. > > Das hat aber nur bedingt etwas mit PKI zu tun. Solange ich die PKI > selbst betreibe, muss ich nur mir selbst vertrauen. Dass unser > (Browser-)SSL Modell "kaputt" ist, sollte bei der enormen Anzahl an CAs > jedem klar sein. Eine einzelne kompromitierte CA reicht ja bereits aus, > um Schaden anzurichten. seh ich auch so. aber "SSL ist mathematisch bewiesen", solange die Implementierung passt und eine kompromittierte CA ist nicht OK... >> Inwieweit diesbezüglich auch noch Herr Snowden für interessante neue >> Sachverhalte sorgen wird, ist auch noch alles andere als klar. Mich >> würde es jedenfalls keinesfalls wundern, wenn die NSA Zugang zu den >> privaten Schlüsseln ALLER großen CAs hätte. > > Interessante Theorie. Wobei das auch nur bedingt wirkungsvoll ist. Die > NSA könnte damit ein paar MITM Angriffe starten. Diese wiederum würden > sich aber ziemlich leicht feststellen lassen. Dafür gibt es > entsprechende Browserplugins. Bekannt sind solche Angriffe meines > Wissens nach nur vom Iran. > >> Angesichts dieser Sachverhalte ist eine (kryptographisch vielleicht >> nicht wirklich gegen jeden Angriffsvektor sichere) proprietäre Lösung >> jederzeit vorzuziehen. > > Das ist nicht dein Ernst, oder? Proprietäre Lösungen sind in den meisten > Fällen ein totaler Pfusch. Selbst wenn es kein Pfusch sein sollte, kann > man sich nie sicher sein, dass es nicht doch irgendwelche Hintertürchen > gibt. Wenn du schon Snowden erwähnst, dann wäre doch die > "Verschlüsselung" von Outlook & Co. ein Musterbeispiel dafür, dass man > proprietären Lösungen niemals vertrauen sollte. hier hast du oft die Gefahr das, die Lösung schnell auf den Markt müssen. Hyundai testet seine NFC Smartphone-Schlüssel an den i30 Gurken... Damit sind sie die ersten und die paar Diebstähle zahlen sie halt... auch ganz interessant zu dem Thema: http://www.golem.de/news/sicherheitsforscher-vw-sicherheitsluecke-darf-nicht-veroeffentlicht-werden-1307-100655.html sg Dirm
K. B. schrieb: > Ich hatte das ja bereits oben erwähnt. Mittlerweile ist es doch schon > eine ganze Weile her. Es geht nicht darum, wie lange es her ist, sondern darum, wie lange der Zustand der absoluten Unsicherheit angehalten hat. Und das waren über zwei Jahre. > Übrigens könnte man das auch so interpretieren, > dass das Open-Source Prinzip hier geklappt hat, weil es ja letztendlich > doch entdeckt wurde. Ja klar. Bisher wurde auch jeder Bankraub irgendwann entdeckt. Spätestens am nächsten Werktag. Die Kohle war allerdings trotzdem schon weg. > Meines Wissens gibt es auch keine Berichte davon, > dass das ganze "in the wild" eingesetzt wurde. Du mußt definitiv erst noch lernen, zwischen den Zeilen der offizieller Verlautbarungen zu Sicherheitsvorfällen zu lesen... > Das hat aber nur bedingt etwas mit PKI zu tun. Nein, das zeigt ein ganz zentrales Problem von PKIs. > Solange ich die PKI > selbst betreibe, muss ich nur mir selbst vertrauen. Das ist korrekt. Gleichzeitig zeigt es aber auch schon die Grenzen deines Ansatzes. Du willst ja angeblich etwas breit nachnutzbares schaffen. Also besteht dann die Wahl, entweder den Nachnutzern deine PKI schmackhaft zu machen oder ihnen die Erstellung und Verwaltung einer eigenen aufzuerlegen. Das erste führt genau wieder zu den zentralistischen CA-Strukturen, die offensichtlich nachweislich untauglich sind, letzteres dazu, daß Leute mit Kryptographie umgehen müssen, die höchstens ansatzweise kapieren, was da passiert. Solche wie dieser bewußte Debian-Maintainer oder noch viel Ahnungslosere. Auch das kann also nachweislich nur schief gehen. Sprich: Dein Projekt ist absehbar zum Scheitern verurteilt. Und das ist schon klar, ohne auch nur einen Gedanken an die konkret zu verwendende Technik verschwendet zu haben. Das ist dann nämlich gleich der nächste Aspekt. Alle relevanten Technologien sind problemlos verfügbar, wenn man genug Rechenleistung hat. Bei Schließsystemen ist es aber nicht zumutbar und praktikabel, Geräte mit hinreichender Rechenleistung mit sich herumzuschleppen. Das diesbezüglich technisch Machbare existiert längst. Und wird regelmäßig gecrackt... Was läßt dich glauben, daß du es besser könntest als die (nicht gerade kleinen) Firmen, deren Systeme reihenweise scheitern?
Bernhard Müller schrieb: > naja ohne Secure Element werden die Zertifikate einfach im Speicher > abgelegt, d.h. du kannst sie einfach kopieren. Ich dachte die Zertifikate werden verschlüsselt hinterlegt und nur bei Eingabe der PIN (kurzzeitig) freigegeben. Bernhard Müller schrieb: > Option 3 secure micro SD Card - das ist Quasi eine SmartCard im SD > Karten Format. d.h. du kannst Zertifikate sicher ablegen Inwiefern wird das denn von gängigen Smartphones & Co. unterstützt? Bernhard Müller schrieb: > SSL ist mathematisch bewiesen Damit wäre ich vorsichtig. SSL baut ja in der Praxis in großen Teilen auf RSA und das lässt sich auf P vs NP zurückführen. Da gibt es bisher noch keinen schlüssigen Beweis ;). c-hater schrieb: > Es geht nicht darum, wie lange es her ist, sondern darum, wie lange der > Zustand der absoluten Unsicherheit angehalten hat. Und das waren über > zwei Jahre. Ja, wie gesagt, ist das alles andere als perfekt gelaufen. Ich persönlich bin auch kein all zu großer Freund von Debian und der "Wir patchen alles selbst" Politik, aber offengestanden sind das Fehler, die nun einmal jedem passieren können. Interessant wird es dann, wenn es darum geht wie man mit dem Ganzen umgeht. Und solange da nichts willentlich verheimlicht wird, kann man den Verantwortlichen hier keinen all zu großen Vorwurf machen. c-hater schrieb: > Du mußt definitiv erst noch lernen, zwischen den Zeilen der offizieller > Verlautbarungen zu Sicherheitsvorfällen zu lesen... Dann helfe mir doch bitte dabei und nenne ein paar Referenzen. Wilde Behauptungen aufstellen kann jeder ;). In vielen Fällen dürfte es deutlich leichtere Angriffsvektoren geben als derjenige, der durch o.g. Lücke "geboten" wurde. Ganz mathematisch unbegabt sollte man nämlich nicht sein, um davon Gebrauch machen zu können. c-hater schrieb: > Nein, das zeigt ein ganz zentrales Problem von PKIs. Nein! Eine PKI an sich ist nicht verkehrt. Und wie bereits gesagt ist alles schön und gut, solange ich meine eigene PKI betreibe (und weiß was ich tue). Problematisch wird es halt dann, wenn z.B. unsere Browser blind Hunderten von CAs vertrauen. Das kann dann natürlich nicht mehr gut gehen hat aber weniger mit dem Konzept einer PKI zu tun, als viel mehr mit der "Vertrauensfrage" an sich. c-hater schrieb: > Du willst ja angeblich etwas breit nachnutzbares > schaffen. Dann solltest du obige Beiträge nochmal genau lesen. Ich habe hier stets von meinem kleinen Hobbyprojekt geredet. Sofern das überhaupt jemand nachbauen sollte, ist derjenige natürlich für sich und seine Sicherheit selbst verantwortlich. Ich will keine Dienstleistung in Form einer PKI oder ähnliches bereit stellen. Wenn jemand keine eigene PKI betreiben kann/möchte, dann kannst du mir doch keine Vorwürfe machen. c-hater schrieb: > Bei Schließsystemen ist es aber nicht zumutbar und praktikabel, > Geräte mit hinreichender Rechenleistung mit sich herumzuschleppen. Ein o.g. Raspberry Pi (oder etwas vergleichbares) sowie jedes "aktuelle" Smartphone mit NFC sollten mehr als genug Rechenleistung haben. c-hater schrieb: > Und wird regelmäßig > gecrackt... Genau. Vor ein paar Beiträgen hattest du das aber noch als gangbare Lösung bezeichnet? c-hater schrieb: > Was läßt dich glauben, daß du es besser könntest als die (nicht gerade > kleinen) Firmen, deren Systeme reihenweise scheitern? Das große Firmen es immer wieder vergeigen zeigt nur, dass diese inkompetent sind oder aber Kompromisse eingehen, um mehr Profit zu machen. Ein Token mit ein bisschen "Security by obscurity" ist halt billig und schnell auf den Markt gebracht. Etwas aus kryptoanalytischer Sicht Brauchbares hingegen kostet viel Geld, ist eventuell nicht mehr so handlich und braucht vermutlich mehr Strom. In vielen Fällen dürfte die gebotene Sicherheit der kommerziell verfügbaren Systeme ja auch bei Weitem ausreichen. Man sollte auch stets bedenken, dass das beste System nichts bringt, wenn die anderen Parameter (z.B. robuste Mechanik) nicht stimmen. Ein Angreifer muss nicht auf den Durchbruch der Quantencomputer hoffen, wenn meine Tür schon von alleine in sich zusammenfällt, oder sich das Schloss mit einfachsten Mitteln "aufbohren" lässt. Wie bereits gesagt bin ich an keiner kommerziellen Vermarktung interessiert. Das ist ein reines Hobbyprojekt, und ich bin an einer technisch "guten" Lösung interessiert. Und das sollte mit den gängigen und bewährten Sicherheitsprotokollen durchaus machbar sein. Deine Negativität jedenfalls kann ich nicht ganz nachvollziehen, Konstruktives hast du jedenfalls nicht wirklich beigetragen.
K. B. schrieb: > Ein o.g. Raspberry Pi (oder etwas vergleichbares) sowie jedes "aktuelle" > Smartphone mit NFC sollten mehr als genug Rechenleistung haben. Einen RasPi wird man sich aber kaum an's Schlüsselbund hängen wollen. Smartphone geht, kostet aber auch so unvergleichlich viel mehr, daß es als reines Schlüsselsystem auch nicht in Frage kommt. Maximal wäre Zweitnutzung neben den eigentlichen Aufgaben eines Smartphones denkbar. Da stellt sich dann aber wiederum das Sicherheitsproblem. Smartphones sind ja offensichtlich mehr oder weniger offene Systeme, kaum geeignet als sicherer Aufbewahrungsort für private Schlüssel...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.