RFID/NFC - Sichere Authentifizierung?

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:
> 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:
> 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ß

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

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:

> 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...