Hallo, mal so ein Gedankengang von mir. Ein Art Rolling Key. Um z.B. einen Garagentöröffner zu bauen, sollte sich ja das Übertragene ständig ändern. Sonst könnte man es abfangen, und erneut senden und wäre drin. Sender und Empfänger haben bei einen festen AES Schlüssel der sich auch nicht ändert. Wenn jetzt Sender und Empfänger die die aktuelle Uhrzeit und Datum kennen würden, und man den "Zeitstempel" AES Verschlüssel und überträgt, der Empfänger dekodiert die Nachricht und vergleicht es mit seiner Uhrzeit. Sind beide gleich abzüglich einer kleinen Toleranz, ist die Nachricht(Code) gültig. Mich würde jetzt interessieren ob das Sicher ist, oder ob es möglich ist die nächste Nachricht vorherzusagen zukönnen. Angenommen man sendet 1 dann 2 dann 3 usw... verschlüsselt. Jemand fängt die verschlüsselten Nachrichten ab. Er kann zwar weder den Klartext erkennen noch kann er Rückschlüsse auf den AES Schlüssel ziehen, aber könnte man rein theoretisch ein Muster erkennen und dann aufgrund der Fortlaufenden Klartextdaten, eine nächste verschlüsselte Nachricht vorhersagen?? Somit wäre der gedachte Garagentoröffner nicht sicher, da man ein Muster erkennen könnte, was sich jede Sekunden ändert. Ich hoffe ihr versteht was ich meine. LG
:
Verschoben durch User
Ich denke nicht. Ich weiß nicht, ob das eine Grundregel ist, aber richtig verschlüsselte Daten kann man (normalerweise) nicht von Zufallsdaten unterscheiden. Für mehr Sicherheit würde ich aber trotzdem noch weitere Daten mitübertragen. Sonst könnte jemand auf die Idee kommen, das Datum als Klartext auszuprobieren. Ob den Aufwand jemand macht, ist die andere Frage, aber mit mehr Daten wird das mit wenig Aufwand nochmal deutlich schwieriger.
Für die beschriebene Anwendung wird keine Verschlüsselung benötigt, sondern eine kryptografische Signatur. Der vermeintliche Klartext enthält doch gar keine vertraulichen Informationen. Ein potentieller Angreifer, der irgendwo im Gebüsch hockt, sieht doch anhand der Reaktion des Garagentores, welchen gültigen Befehl der berechtigte Anwender gesendet hat. Das Geheimnis, welches Sender um Empfänger teilen, wird dann einfach in die Signatur einbezogen, vorzugsweise zusammen mit dem schon genannten Zeitstempel und einer fortlaufenden Sequenznummer. Durch die Sequenznummer werden Replay-Angriffe nochmals deutlich erschwert, aber zumindest einige Formen noch nicht ganz unmöglich gemacht. Ein interessantes Thema ist aber auch die Synchronisation der Uhren. Die Uhren über lange Zeit unsynchronisiert zu lassen, bedeutet aber auch, große Zeitunterschiede bei der gesendeten Nachricht zuzulassen. Synchronisiert man sie jedoch bei jeder Nachricht, muss man aufpassen, dass man nicht Replay-Angreifern die Möglichkeit eröffnet, ebenfalls die Empfängeruhr zu synchronisieren.
Also ich sperre meine Garage immer mit dem Schlüssel auf. Da kann mir keiner meinen Schlüssel abhören, und ich muss mir keine schlaflosen Nächte um Code-Verschlüsselung machen.
Andreas S. schrieb: > Für die beschriebene Anwendung wird keine Verschlüsselung benötigt, AES-128 ist ja meist 'kostenlos' (on-chip) - wenn man sich damit RSA oder ECC einsparen kann ... warum nicht?
Wenn man mal vergleicht, welche Sicherheitsstufe gewöhnlich akzeptierte mechanische Schlüssel haben, erscheint der übliche Aufwand bei elektronischen Schlüsseln beinahe grotesk. Jeder Schlüsseldienst knackt die einfachen Schlösser innerhalb von 15 Minuten, aber bei elektronischen Schlüsseln tut man so, als ob hinter der Türe ein Heiligtum gelagert würde.
Stefanus F. schrieb: > Jeder Schlüsseldienst knackt die einfachen Schlösser innerhalb von 15 > Minuten, aber bei elektronischen Schlüsseln tut man so, als ob hinter > der Türe ein Heiligtum gelagert würde. Genau. Wahrscheinlich schafft er es auch problemlos in 10 Minuten. Nur: Die braucht er für jedes Schloß einzeln. Beim elektronischen Schloß kann man mit dem Kleinbus durch die Straßen fahren und einfach schauen, welche Tür aufgeht.
Crypto-noob schrieb: > Andreas S. schrieb: >> Für die beschriebene Anwendung wird keine Verschlüsselung benötigt, > > AES-128 ist ja meist 'kostenlos' (on-chip) - wenn man sich damit RSA > oder ECC einsparen kann ... warum nicht? Ich habe doch keine Vorgabe bezüglich des Algorithmus gemacht. RSA und ECC werden für asymmetrische Verfahren eingesetzt. Die Tatsache, dass ein AES-Block zur Verfügung steht, bedeutet noch lange nicht, dass sich der Anwendungsfall danach richtet. Das sind einfach unterschiedliche Abstraktionsgrade.
Nur mal so nebenbei. Diese Idee ist im Prinzip https://de.m.wikipedia.org/wiki/Time-based_One-time_Password_Algorithmus Wenn man keine Uhren synchronisieren will gibt es https://de.m.wikipedia.org/wiki/HMAC-based_One-time_Password_Algorithmus
Die Anwendung heißt Challenge-Response-Authentication und ist schon seit Jahrzehnten bei E-Mail im Einsatz. Bitte sich in die Ecke zu stellen und schämen.
Jürgen W. schrieb: > Die Anwendung heißt Challenge-Response-Authentication und ist schon seit > Jahrzehnten bei E-Mail im Einsatz. Braucht aber einen Rückkanal. Wenn man den hat ist es natürlich besser als HOTP/TOTP weil nix (Zähler/Uhr) auseinanderlaufen kann.
Es stimmt, daß hier eigentlich eine Signatur nötig wäre, also ein Beweis, daß der Absender der Nachricht das Geheimnis kennt. Das kann ein einfacher AES aber genausogut leisten. Also besteht eine Nachricht z.B. aus Zeitstempel (4 Byte sollten reichen), Zähler (1 Byte) und Befehlscode (1 Byte), dann wird auf 16 Byte aufgefüllt (mit Nullbytes). Das kann man dann als einen AES-Block verschlüsseln. Der Empfänger prüft nach dem Entschlüsseln zuerst, ob die Füllbytes korrekt sind, denn damit ist bewiesen, daß der Absender das richtige Geheimnis kennt (den richtigen AES-Schlüssel benutzt hat). Dann prüft er, ob der Zeitstempel aktuell ist (also mit der eigenen Uhrzeit übereinstimmt, mit etwas Toleranz). Anhand des Zählers überprüft er dann, ob die Nachricht neu ist oder eine Wiederholung (dazu muß er Zähler+Zeitstempel akzeptierter Nachrichten speichern, bis deren Zeitstempel zu alt ist). Wenn das alles stimmt, wird die Nachricht akzeptiert (und vielleicht die Uhr nach dem Zeitstempel gestellt). Christian schrieb: > Mich würde jetzt interessieren ob das Sicher ist, oder ob es möglich ist > die nächste Nachricht vorherzusagen zukönnen. Angenommen man sendet 1 > dann 2 dann 3 usw... verschlüsselt. Jemand fängt die verschlüsselten > Nachrichten ab. Er kann zwar weder den Klartext erkennen noch kann er > Rückschlüsse auf den AES Schlüssel ziehen, aber könnte man rein > theoretisch ein Muster erkennen und dann aufgrund der Fortlaufenden > Klartextdaten, eine nächste verschlüsselte Nachricht vorhersagen?? Das wäre differenzielle Kryptoanalyse; Resistenz dagegen gehörte zu den Anforderungen bei der Auswahl des AES.
Nosnibor schrieb: > Es stimmt, daß hier eigentlich eine Signatur nötig wäre, Eigentlich ist nur eine Hashfunktion nötig. Ein PSK, eine Nonce und ein Hash und fertig ist der HMAC. Das ist ein sehr gängiges Verfahren für Authentifizierung bei APIs im web. Und da bekommt der Nachbar das Garagentor selbst mit dem Quantencomputer nicht geknackt, bei AES würd ich so eine Aussage nicht unterschreiben wollen.
:
Bearbeitet durch User
Christian schrieb: > Sender und Empfänger haben bei einen festen AES Schlüssel der sich auch > nicht ändert. Schon mal eine ganz schlechte Idee. Wie schon gesagt wurde: Authentifizierung / Signierung und Verschlüsselung sind hier zwei Paar Stiefel, letzteres verkompliziert nur, und gaukelt falsche Sicherheit vor. Mach es wie die Banken oder prof7bit :-). Die TAN-Generatoren-Logik ist recht simpel. Trotzdem funktionieren sie prima, der Angriff auf den Signierungsprozess einer Transaktion ist viel aufwendiger, als AES zu brute-forcen. Teilweise funktioniert Security by Obscurity sogar ganz gut, um z.B. RFID-Schlüssel laufend neu zu 'pairen' wenn einer verlorengeht. Nur das Pairing sollte man einigermassen unter Ausschluss einer MITM-Attacke durchführen (neuere Generation Mifare).
Fitzebutze schrieb: > Mach es wie die Banken oder prof7bit :-). Die TAN-Generatoren-Logik ist > recht simpel. Trotzdem funktionieren sie prima, Ich schlug HMAC mit Nonce vor, keine TAN-Liste. > Teilweise funktioniert Security by Obscurity sogar ganz gut Ich schlug HMAC mit Nonce vor, kein Securitry by obscurity.
Walter T. schrieb: > Stefanus F. schrieb: >> Jeder Schlüsseldienst knackt die einfachen Schlösser innerhalb von 15 >> Minuten, aber bei elektronischen Schlüsseln tut man so, als ob hinter >> der Türe ein Heiligtum gelagert würde. > > Genau. Wahrscheinlich schafft er es auch problemlos in 10 Minuten. Nur: > Die braucht er für jedes Schloß einzeln. Beim elektronischen Schloß kann > man mit dem Kleinbus durch die Straßen fahren und einfach schauen, > welche Tür aufgeht. So sieht's aus. Deshalb ist der Aufstand bei den elektronischen Schlüsseln auch gerechtfertigt: jedes noch so komplexe Vorgehen zum Brechen des Schlüssels kann in sehr einfach ein Programm gepackt werden und dann kann es jeder neunjährige bedienen. Das ist bei mechanischen Schlössern einfach anders.
Fitzebutze schrieb: > Christian schrieb: >> Sender und Empfänger haben bei einen festen AES Schlüssel der sich auch >> nicht ändert. > > Schon mal eine ganz schlechte Idee. > > Wie schon gesagt wurde: Authentifizierung / Signierung und > Verschlüsselung sind hier zwei Paar Stiefel, letzteres verkompliziert > nur, und gaukelt falsche Sicherheit vor. Das ist nicht richtig, AES mit MAC ist ausreichend. Du brauchst nichtmal einen expliziten MAC; der Angreifer wird es auch so nicht schaffen, eine Nachricht zu erzeugen, die nach dem Entschlüsseln irgendwie Sinn macht. Der Wert einer Signatur dem gegenüber liegt eigentlich nur darin, dass sie asymmetrisch ist. Das bringt hier nichts, deshalb benötigt man auch nicht unbedingt einen Signaturalgorithmus.
Sven B. schrieb: > kann in sehr einfach ein Programm gepackt werden > und dann kann es jeder neunjährige bedienen. Das ist bei mechanischen > Schlössern einfach anders. Das ist ein gutes Argument.
Christian schrieb: > Wenn jetzt Sender und Empfänger die die aktuelle Uhrzeit und Datum > kennen würden, und man den "Zeitstempel" AES Verschlüssel und überträgt, > der Empfänger dekodiert die Nachricht und vergleicht es mit seiner > Uhrzeit. Sind beide gleich abzüglich einer kleinen Toleranz, ist die > Nachricht(Code) gültig. Und was passiert wenn die Uhrzeit auseinander läuft?
GEKU schrieb: > Christian schrieb: > Wenn jetzt Sender und Empfänger die die aktuelle Uhrzeit und Datum > kennen würden, und man den "Zeitstempel" AES Verschlüssel und überträgt, > der Empfänger dekodiert die Nachricht und vergleicht es mit seiner > Uhrzeit. Sind beide gleich abzüglich einer kleinen Toleranz, ist die > Nachricht(Code) gültig. > > Und was passiert wenn die Uhrzeit auseinander läuft? Dann funktioniert der Schlüssel nicht. Man kann nicht alles haben.
Man kann die Uhrzeit ja neu synchronisieren bei jedem Öffnen.
Christian schrieb: > Mich würde jetzt interessieren ob das Sicher ist, oder ob es möglich ist > die nächste Nachricht vorherzusagen zukönnen. Angenommen man sendet 1 > dann 2 dann 3 usw... verschlüsselt. Jemand fängt die verschlüsselten > Nachrichten ab. Er kann zwar weder den Klartext erkennen noch kann er > Rückschlüsse auf den AES Schlüssel ziehen, aber könnte man rein > theoretisch ein Muster erkennen und dann aufgrund der Fortlaufenden > Klartextdaten, eine nächste verschlüsselte Nachricht vorhersagen?? Du hast das schon richtig erkannt/vermutet. Hier gibt es die Situation, dass bekannte Daten (die Uhrzeit) mit einem unbekannten Schlüssel (der geheime Key) codiert werden. D.h. ein Angreifer könnte einen eigenen Empfänger in die Nähe des Garagentor stellen, und über einen längeren Zeitraum die verschlüsselten Daten mitprotokollieren. Da die aktuelle Uhrzeit ja bekannt ist sammelt der Angreifer Klartext-Ciphertext-Paare. Hat er ausreichend viele, könnte er u.U. einen sogenannten "Known-Plaintext-Angriff" durchführen und so u.U. den geheimen Schlüssel finden. Allerdings ist nun eben bei AES so ein Angriff (der in der Praxis relavant wäre) nicht bekannt. D.h. für das Garagentor sollte Dein einfaches Verfahren weit mehr aus völlig ausreichend sein. Willst Du es etwas besser machen verwende noch einen Nonce, wie oben schon geschrieben wurde. Aber meiner Meinung nach unnötig: Bevor jemand zig Millionen Euro ausgibt, um die Verschlüsselung zu brechen, nimmt er lieber ein Brecheisen und hebel t das Schloss aus. Auch der oben genannte Bus ist ohne praktische Bedeutung. Denn aufgrund der begrenzten Datenrate kann so ein Bus keinen relevanten Brute-Force-Angriff fahren. Er müsste im Schneckentempo, vielleicht mit einigen Nanometern in einem Jahr durch die Straße kriechen. Der Suchraum ist einfach viel zu groß.
Krypto-Schüler schrieb: > Aber meiner Meinung nach unnötig: Bevor jemand zig Millionen Euro > ausgibt, um die Verschlüsselung zu brechen, nimmt er lieber ein > Brecheisen und hebel t das Schloss aus. Oder er öffnet das Gehäuse vom elektronischen Schloss und brückt das Relais (oder gibt 9V auf den Türsummer). Diese Schwachstelle wird meist vom Käufer übersehen.
Es kommt auch auf die Methode der AES-Verschlüsselung an! https://de.wikipedia.org/wiki/Betriebsmodus_(Kryptographie) In dem Beitrag über den ECB-Modus gibt es ein schönes Bild, dass die zeigt warum manchmal sogar mit dem blosen Auge eine AES-Verschlüsselung zu knacken ist :-)
:
Bearbeitet durch User
Eine kurze Anmerkung noch zur Verwendung der Urzeit: Das ist unpraktisch, weil z.B. nach einem Baterietausch die Uhr neu gestellt werden muss. Ich würde einfach eine Zahl nehmen. Der Sender zählt bei jedem Senden um 1 rauf. Der Empfänger akzeptiert alles was im Bereich 'letzte empfangene Zahl + 1' bis 'letzte empfangene Zahl + 10000' liegt. Damit hast du keine Probleme wenn mal ein Paket verloren geht oder der Nutzer einfach mal wild auf der Fernbedienung rumdrückt. Wenn deine Zahl lang genug ist (32 Bit dürften in der Praxis reichen) wird trotzdem nie ein gleiches Paket gesendet. Du brauchst natürlich weiterhin irgendeine Form von MAC.
Hermann K. schrieb: > Eine kurze Anmerkung noch zur Verwendung der Urzeit: Das ist > unpraktisch, weil z.B. nach einem Baterietausch die Uhr neu gestellt > werden muss. Ich würde einfach eine Zahl nehmen. Der Sender zählt bei > jedem Senden um 1 rauf. Der Empfänger akzeptiert alles was im Bereich > 'letzte empfangene Zahl + 1' bis 'letzte empfangene Zahl + 10000' liegt. > Damit hast du keine Probleme wenn mal ein Paket verloren geht oder der > Nutzer einfach mal wild auf der Fernbedienung rumdrückt. Wenn deine Zahl > lang genug ist (32 Bit dürften in der Praxis reichen) wird trotzdem nie > ein gleiches Paket gesendet. Du brauchst natürlich weiterhin irgendeine > Form von MAC. Dafür brauchst du einen Flash statt einer RTC ... ist das jetzt wirklich einfacher?
Hermann K. schrieb: > Ich würde einfach eine Zahl nehmen. Der Sender zählt bei jedem Senden um > 1 rauf. Der Empfänger akzeptiert alles was im Bereich 'letzte empfangene > Zahl + 1' bis 'letzte empfangene Zahl + 10000' liegt. Gibt es schon fertig, nennt sich HOTP. Hier im Thread werden auch mal wieder haufenweise Dinge erfunden die es schon lange fertig gibt ;-)
Hallo, also erstmal vielen Dank für die vielen Antworten und interessanten Diskussionen. Also die momentane Garagentorsicherheit ist ein 10 Bit DIP Schalter. Also alles was halbwegs intelligenter ist, wäre schon etwas sicherer. Ja die Sache mit der Uhrzeit gefällt mir auch nicht mehr so richtig nachdem ich das alles gelesen habe. Ich habe mir schon eine Kombination aus den verschiedenen Dingen überlegt. Also eine Challange Response in die gewisse einmalige Daten des Senders einfließen sowie ein Zähler. Das Ergebnis wird z.B. mit SHA3 gehasht. Die Hin und Her Übertragung erfolgt AES Verschlüsselt. Somit ist von jedem etwas dabei. Noch dazu ist die Challange ja auch individuell ausgedacht. Laufzeit ist ja auch egal, selbst wenn das 5s dauern sollte. Ich finde es interessant das ganze mal irgendwie auszuprobieren, über Sinn und Unsinn lässt sich streiten. Aber durch die Kombination verschiedener Dinge würde es nicht unsicherer werden oder? LG
Christian schrieb: > Aber durch die Kombination verschiedener Dinge würde es nicht unsicherer > werden oder? Also realistisch betrachtet doch, Probleme in Kryptosystemen liegen eigentlich meist bei "ein ungeeignetes Verfahren wurde angewendet", "das Protokoll hat ein theoretisches Problem", und "es wurde falsch implementiert". Je einfacher, desto besser; bei der AES-mit-Uhrzeit-Variante kann man nicht so viel falsch machen. Wenn du dein eigenes Schlüsselaustauschprotokoll entwirfst und umsetzt, ist danach garantiert etwas falsch. Je komplexer es ist, desto mehr wird falsch sein. Dann lieber TLS nehmen und mit TLS-Client-Zerfitikat authentifizieren.
Andreas S. schrieb: > Ein interessantes Thema ist aber auch die Synchronisation der Uhren. Die > Uhren über lange Zeit unsynchronisiert zu lassen, bedeutet aber auch, > große Zeitunterschiede bei der gesendeten Nachricht zuzulassen. Eine Synchronisierung bedeutet aber auch, dass es nur einen einzigen Sender geben kann. Der Empfänger könnte aber die Drift der Uhren erkennen (pro Sender) und jeweils das Fenster für den Bereich, der akzeptiert wird, entsprechend anpassen. Sven B. schrieb: > So sieht's aus. Deshalb ist der Aufstand bei den elektronischen > Schlüsseln auch gerechtfertigt: jedes noch so komplexe Vorgehen zum > Brechen des Schlüssels kann in sehr einfach ein Programm gepackt werden > und dann kann es jeder neunjährige bedienen. Das ist bei mechanischen > Schlössern einfach anders. Naja, wenn ich von einem mechanischen Schlüssel eine Kopie mache, kann die auch jeder Neunjährige bedienen.
Rolf M. schrieb: > Sven B. schrieb: >> So sieht's aus. Deshalb ist der Aufstand bei den elektronischen >> Schlüsseln auch gerechtfertigt: jedes noch so komplexe Vorgehen zum >> Brechen des Schlüssels kann in sehr einfach ein Programm gepackt werden >> und dann kann es jeder neunjährige bedienen. Das ist bei mechanischen >> Schlössern einfach anders. > > Naja, wenn ich von einem mechanischen Schlüssel eine Kopie mache, kann > die auch jeder Neunjährige bedienen. Aber nur das eine Schloss von dem du den Schlüssel kopiert hast, und nicht alle Schlösser ...
Jürgen W. schrieb: > Die Anwendung heißt Challenge-Response-Authentication und ist > schon seit > Jahrzehnten bei E-Mail im Einsatz. > > Bitte sich in die Ecke zu stellen und schämen. Das ist m.M. nach die einzig richtige Antwort auf die Initialfrage. Der TO fragt nach Playback Attacken und deren Vermeidung. Das wird dadurch gemacht, dass die Payload nicht mit dem "Urschlüssel" verschlüsselt wird, sondern mit einem Session Key, der für jede Session verschieden ist und eine dynamische Komponente (= starke Zufallszahl) hat. Beide Seiten verhandeln mit Hilfe des Urschlüssels für jede session einen abgeleiteten Schlüssel. Eine Playbackattacke wird dadurch unmöglich, weil die Sessionkeyverhandlung wegen der dynamischen Komponente nicht zurückgespielt werden kann. Wie Jürgen schon richtig geschrieben hat, sind das seit Ewigkeiten im Einsatz befindliche Verfahren. Die Sicherheit hängt natürlich elementar von der Stärke (Nichtdeterminismus und Entropie) der Zufallszahlen ab, die zum Generieren der Session keys verwendet werden.
Wunschlos Glücklicher schrieb: > Da kann mir keiner meinen Schlüssel abhören, und ich muss > mir keine schlaflosen Nächte um Code-Verschlüsselung machen. https://www.amazon.de/Lockpicking-Set-Dietrich-Transparentem-Trainingsschl%C3%B6ssern/dp/B07GSTWN84/
Sven B. schrieb: > Je einfacher, desto besser; bei der > AES-mit-Uhrzeit-Variante kann man nicht so viel falsch machen. Uhrzeit wäre das Letzte, auf das ich hier setzen würde. Einmal Stromausfall und die Batterie leer und Du kommst nicht mehr rein.
Karl K. schrieb: > Sven B. schrieb: >> Je einfacher, desto besser; bei der >> AES-mit-Uhrzeit-Variante kann man nicht so viel falsch machen. > > Uhrzeit wäre das Letzte, auf das ich hier setzen würde. Einmal > Stromausfall und die Batterie leer und Du kommst nicht mehr rein. Ist jetzt halt die Frage, wie schlimm das ist. Bei einem Garagentor wäre das vermutlich verkraftbar ... Wenn das Ding am Netz hängt und eine Backup-Batterie hat ist ein anderer Defekt, insb. "Schlüssel verloren", aber sowieso deutlich wahrscheinlicher als das.
Oldie but goldie: "Handbook of applied Cryptography". Da werden sie geholfen was grundlegende Algorithmen in dieser Richtung angeht. Ansonsten die Bücher von Schneier zusätzlich.
Sven B. schrieb: > Karl K. schrieb: >> Sven B. schrieb: >>> Je einfacher, desto besser; bei der >>> AES-mit-Uhrzeit-Variante kann man nicht so viel falsch machen. >> >> Uhrzeit wäre das Letzte, auf das ich hier setzen würde. Einmal >> Stromausfall und die Batterie leer und Du kommst nicht mehr rein. > > Ist jetzt halt die Frage, wie schlimm das ist. Bei einem Garagentor wäre > das vermutlich verkraftbar ... > Nein, ist es mit Sicherheit nicht. Mit Uhrzeiten kann wirklich Alles mögliche schief gehen. Erstens Mal gehen zwei Uhren niemals wirklich synchron, d.h. früher oder später laufen die Uhrzeiten so weit auseinander, dass daraus kein gemeinsamer Zeitstempel mehr abgeleitet werden kann. Natürlich ist es dann denkbar, dass sich beide Seiten protokollmässig ihre Uhren syncen, aber was das für die Sicherheit geegnüber einem Abhörer bedeutet, ist die Hausaufgabe für einen Erstsemester. Natürlich kann man dann über GPS oder DCF77 versuchen eine gemeinsame Basis zu finden, aber das ist wieder zusätzliche Hardware, die kaputt gehen, ihren Sender verlieren oder mehr Strom verbrauchen kann. Ausserdem muss man sich dann so mit Themen auseinandersetzen wie dass manche Uhrenbausteine in der Hoffnung, über mehr "Intelligenz" bessere Verkaufszahlen zu generieren, automatische Sommer/Winterzeitunterstützung als Default haben, d.h. man wundert sich darüber, dass das Garagentor ziemlich genau im Sommer nicht mehr funktioniert (wenn z.B. im Rahmen einer Wartung eine Seite mit einer gewechselten neuen Drittkomponente ausgestattet wird). > Wenn das Ding am Netz hängt und eine Backup-Batterie hat ist ein anderer > Defekt, insb. "Schlüssel verloren", aber sowieso deutlich > wahrscheinlicher als das. Nein. Wieso sind 16 Byte im nichtflüchtigen Speicher mehr gefährdet als ein Uhrenbaustein? Man kann die Schlüssel auch im EEPROM oder Flash ablegen, dann sind sie auch gegen Stromausfall resistent. Alles mit Uhrzeit sind Krücken. Sessionkeyverhandlung und ggf. periodische Key Generation changes, und damit ist der Kuchen gegessen. Mit diesen bewährten Techniken hat man nicht nur wesentlich robustere und verlässlichere Sicherheit, sondern auch wesentlich bessere Chancen, so ein System zertifiziert zu bekommen.
RAc schrieb: > Alles mit Uhrzeit sind Krücken. Sessionkeyverhandlung und ggf. > periodische Key Generation changes, und damit ist der Kuchen gegessen. > Mit diesen bewährten Techniken hat man nicht nur wesentlich robustere > und verlässlichere Sicherheit, sondern auch wesentlich bessere Chancen, > so ein System zertifiziert zu bekommen. Wenn man eine Bidirektionale Verbindung hat, ist Challenge-Response am einfachsten und robustesten. Mit zufälliger oder auch nur hochzählender Nonce (bei entsprechender Limitierung der Anfragen) sind Replay Attacken kein Thema mehr. Dann reicht auch HMAC mit PSK. Da braucht man sonst gar nichts, schon gar keine Sessionkeys, weil man gar keine geheimen Daten zum übertragen hat. Es geht ja nur um Authentifizerung. Aber wenn man eben nur Unidirektional hat, muss man sich was anderes einfallen lassen. Und handelsübliche RSA Tokens arbeiten auch jahrelang zuverlässig mittels eigener Uhr. Das geht also schon. Und da findet auch kein Sync statt.
:
Bearbeitet durch User
RAc schrieb: > Nein, ist es mit Sicherheit nicht. Mit Uhrzeiten kann wirklich Alles > mögliche schief gehen. Erstens Mal gehen zwei Uhren niemals wirklich > synchron, d.h. früher oder später laufen die Uhrzeiten so weit > auseinander, dass daraus kein gemeinsamer Zeitstempel mehr abgeleitet > werden kann. Natürlich ist es dann denkbar, dass sich beide Seiten > protokollmässig ihre Uhren syncen, aber was das für die Sicherheit > geegnüber einem Abhörer bedeutet, ist die Hausaufgabe für einen > Erstsemester. Das sehe ich nicht so. Du kannst 3 Minuten Abweichung akzeptieren, was für den vorliegenden Fall quasi keine Sicherheits-Implikation hat, und aus jedem "schließe das Tor auf"-Paket auf die darin enthaltene Uhrzeit synchronisieren. Dazu brauchst du kein zusätzliches Protokoll, die Informationen sind schon da. Wenn deine Uhr in den max. zwei Wochen zwischen zweimal Garagentor aufmachen im 3 Minuten driftet, ist sie kaputt. > Nein. Wieso sind 16 Byte im nichtflüchtigen Speicher mehr gefährdet als > ein Uhrenbaustein? Man kann die Schlüssel auch im EEPROM oder Flash > ablegen, dann sind sie auch gegen Stromausfall resistent. Aber du kannst das Kärtchen im Gulli verlieren, mit dem Knopf drauf, der das Tor öffnet. ;) > Alles mit Uhrzeit sind Krücken. Sessionkeyverhandlung und ggf. > periodische Key Generation changes, und damit ist der Kuchen gegessen. > Mit diesen bewährten Techniken hat man nicht nur wesentlich robustere > und verlässlichere Sicherheit, sondern auch wesentlich bessere Chancen, > so ein System zertifiziert zu bekommen. Klar, kannst du machen. Ist halt fünftausend mal so komplex: du brauchst - Datenübertragung vom Tor zum Schlüssel - Eine State Machine, die den ganzen Prozess handhabt, inkl. Konzept einer Verbindung etc -- denke mal daran, wie komplex das ist, das mit einem Funkmodul wie z.B. einem nRF24L01 umzusetzen - Ein Zertifikat und entweder eine CA oder die Cert-ID des Schlüssels im Tor - Erheblich schnellere Sender und Empfänger -- ein TLS-Handshake sind ca. 5 kB - Implememtierung eines asymetrischen Kryptoverfahrens - Implementierung eines Schlüsselaustausch-Algorithmus - Serialisierung für diese ganzen Dinge (x.509?) Und wenn du sowas benutzen willst wie normales TLS und sagen, dass du das "einfach ganz genau so machst wie der Browser", brauchst du zusätzlich noch - CRL Checking - Eine Uhr, um Gültigkeiten des Zertifikats zu prüfen Ich will nicht sagen, dass diese Variante schlecht ist. Bloß, die Uhr-Variante lässt sich vermutlich inkl. aller benötigten Verfahren und Hardware-Initialisierung und blabla in ca. 1000 Zeilen C umsetzen. Für die andere Methode bin ich sehr skeptisch, ob das realistisch in weniger als 20.000 Zeilen machbar ist. Für das Garagentor würde ich die Uhr-Variante nehmen.
:
Bearbeitet durch User
Sven B. schrieb: > RAc schrieb: >> Nein, ist es mit Sicherheit nicht. Mit Uhrzeiten kann wirklich Alles >> mögliche schief gehen. Erstens Mal gehen zwei Uhren niemals wirklich >> synchron, d.h. früher oder später laufen die Uhrzeiten so weit >> auseinander, dass daraus kein gemeinsamer Zeitstempel mehr abgeleitet >> werden kann. Natürlich ist es dann denkbar, dass sich beide Seiten >> protokollmässig ihre Uhren syncen, aber was das für die Sicherheit >> geegnüber einem Abhörer bedeutet, ist die Hausaufgabe für einen >> Erstsemester. > > Das sehe ich nicht so. Du kannst 3 Minuten Abweichung akzeptieren, was > für den vorliegenden Fall quasi keine Sicherheits-Implikation hat, und > aus jedem "schließe das Tor auf"-Paket auf die darin enthaltene Uhrzeit > synchronisieren. Dazu brauchst du kein zusätzliches Protokoll, die > Informationen sind schon da. Wenn deine Uhr in den max. zwei Wochen > zwischen zweimal Garagentor aufmachen im 3 Minuten driftet, ist sie > kaputt. > Verstehe ich nicht. Die moderne IT Sicherheit geht davon aus, dass der Programmierer der Angreifer ist, d.h. der Algorithmus ist dem Angreifer bekannt. Wer also sämtlichen Datenverkehr mitschneidet (davon wird ja bei dem Szenario ausgegangen) und weiss, in welchem 3 Minuten Zeitfenster jeder Öffnungszyklus liegt, hat irgendwann mal genügend Plain Text/Crypt Paare zusammen, um den Schlüssel daraus abzuleiten. Ohne starke Zufallskomponente geht da m.M. nach gar nichts. >> Nein. Wieso sind 16 Byte im nichtflüchtigen Speicher mehr gefährdet als >> ein Uhrenbaustein? Man kann die Schlüssel auch im EEPROM oder Flash >> ablegen, dann sind sie auch gegen Stromausfall resistent. > > Aber du kannst das Kärtchen im Gulli verlieren, mit dem Knopf drauf, der > das Tor öffnet. ;) > Schreiben wir aneinander vorbei? Du brauchst doch in jedem Fall zwei Komponenten, die miteinander in (Funk)Kommunikation stehen und in irgendeiner Form glauben sich gegenseitig vetrauen zu können, von denen die eine stationär (in der Garage) und die andere mobil (am Benutzer) ist, oder was fehlt mir da? Wenn Du die mobile verlierst oder im Gulli versenkst, ist das System in jedem Fall (by design) betriebsunfähig, oder? >> Alles mit Uhrzeit sind Krücken. Sessionkeyverhandlung und ggf. >> periodische Key Generation changes, und damit ist der Kuchen gegessen. >> Mit diesen bewährten Techniken hat man nicht nur wesentlich robustere >> und verlässlichere Sicherheit, sondern auch wesentlich bessere Chancen, >> so ein System zertifiziert zu bekommen. > > Klar, kannst du machen. Ist halt fünftausend mal so komplex: du brauchst > > - Datenübertragung vom Tor zum Schlüssel Wie oben geschrieben: Ist das nicht die Grundvoraussetzung der ganzen Angelegenheit? > - Eine State Machine, die den ganzen Prozess handhabt, inkl. Konzept > einer Verbindung etc -- denke mal daran, wie komplex das ist, das mit > einem Funkmodul wie z.B. einem nRF24L01 umzusetzen Wieso? Das ist Anwendungssoftware. > - Ein Zertifikat und entweder eine CA oder die Cert-ID des Schlüssels > im Tor Nein. Du brauchst für das Verfahren kein RSA. > - Erheblich schnellere Sender und Empfänger -- ein TLS-Handshake sind > ca. 5 kB Nein. Du brauchst kein TLS. > - Implememtierung eines asymetrischen Kryptoverfahrens Nein. > - Implementierung eines Schlüsselaustausch-Algorithmus Das wäre eine Protokollerweiterung, die mit 3 Zusatzpaketen abgehandelt ist. > - Serialisierung für diese ganzen Dinge (x.509?) > Nein. > Und wenn du sowas benutzen willst wie normales TLS und sagen, dass du > das "einfach ganz genau so machst wie der Browser", brauchst du > zusätzlich noch > > - CRL Checking > - Eine Uhr, um Gültigkeiten des Zertifikats zu prüfen > Nein. > Ich will nicht sagen, dass diese Variante schlecht ist. Bloß, die > Uhr-Variante lässt sich vermutlich inkl. aller benötigten Verfahren und > Hardware-Initialisierung und blabla in ca. 1000 Zeilen C umsetzen. Für > die andere Methode bin ich sehr skeptisch, ob das realistisch in weniger > als 20.000 Zeilen machbar ist. > > Für das Garagentor würde ich die Uhr-Variante nehmen. Ich nicht. ich arbeite seit über 20 Jahren in einem Bereich, in dem Zeit und Sicherheit zentrale Rollen spielen. Ich werde regelmässig wieder damit überrascht, was selbst nach all der damit verbundenen Erfahrung doch noch wieder schief gehen kann.
RAc schrieb: > Verstehe ich nicht. Die moderne IT Sicherheit geht davon aus, dass der > Programmierer der Angreifer ist, d.h. der Algorithmus ist dem Angreifer > bekannt. Wer also sämtlichen Datenverkehr mitschneidet (davon wird ja > bei dem Szenario ausgegangen) und weiss, in welchem 3 Minuten > Zeitfenster jeder Öffnungszyklus liegt, hat irgendwann mal genügend > Plain Text/Crypt Paare zusammen, um den Schlüssel daraus abzuleiten. > Ohne starke Zufallskomponente geht da m.M. nach gar nichts. Ok, kannst du mir mal bitte einen erfolgreichen Known-Plaintext-Angriff auf AES zeigen? Das funktioniert so nicht, du kannst noch und noch Cipertext/Plaintext-Paare sammeln ohne dass du den Schlüssel daraus ableiten kannst. > Wenn Du die mobile verlierst oder im Gulli > versenkst, ist das System in jedem Fall (by design) betriebsunfähig, > oder? Jaja, klar. Ich wollte bloß darauf hinaus, dass es deswegen nichts bringt, das System auf unendliche Zuverlässigkeit zu optimieren; du brauchst eh einen Plan B, wenn es nicht auf geht. >> Klar, kannst du machen. Ist halt fünftausend mal so komplex: du brauchst >> >> - Datenübertragung vom Tor zum Schlüssel > > Wie oben geschrieben: Ist das nicht die Grundvoraussetzung der ganzen > Angelegenheit? Nein, für ich-verschlüssle-die-Uhrzeit-mit-AES-und-prüfe-den-MAC-Variante brauchst du nur Datenübertragung vom Schlüssel zum Tor; nicht andersherum. >> - Eine State Machine, die den ganzen Prozess handhabt, inkl. Konzept >> einer Verbindung etc -- denke mal daran, wie komplex das ist, das mit >> einem Funkmodul wie z.B. einem nRF24L01 umzusetzen > > Wieso? Das ist Anwendungssoftware. Die mit TCP arbeitet. Was du auf einem kleinen Funkmodul nicht hast. >> - Ein Zertifikat und entweder eine CA oder die Cert-ID des Schlüssels >> im Tor > > Nein. Du brauchst für das Verfahren kein RSA. Ich hab auch nix von RSA gesagt. > >> - Erheblich schnellere Sender und Empfänger -- ein TLS-Handshake sind >> ca. 5 kB > > Nein. Du brauchst kein TLS. Aber etwas ähnliches wie TLS. >> - Serialisierung für diese ganzen Dinge (x.509?) > > Nein. Ach so, und die Daten für den Key Exchange werden dann per gutem Willen kommuniziert oder was? :D > Ich nicht. ich arbeite seit über 20 Jahren in einem Bereich, in dem Zeit > und Sicherheit zentrale Rollen spielen. Ich werde regelmässig wieder > damit überrascht, was selbst nach all der damit verbundenen Erfahrung > doch noch wieder schief gehen kann. Bei Key-Exchange-basierten Protokollen hingegen hat man noch nie gesehen, dass etwas schief geht ...
Sven B. schrieb: > RAc schrieb: >> Verstehe ich nicht. Die moderne IT Sicherheit geht davon aus, dass der >> Programmierer der Angreifer ist, d.h. der Algorithmus ist dem Angreifer >> bekannt. Wer also sämtlichen Datenverkehr mitschneidet (davon wird ja >> bei dem Szenario ausgegangen) und weiss, in welchem 3 Minuten >> Zeitfenster jeder Öffnungszyklus liegt, hat irgendwann mal genügend >> Plain Text/Crypt Paare zusammen, um den Schlüssel daraus abzuleiten. >> Ohne starke Zufallskomponente geht da m.M. nach gar nichts. > > Ok, kannst du mir mal bitte einen erfolgreichen Known-Plaintext-Angriff > auf AES zeigen? Das funktioniert so nicht, du kannst noch und noch > Cipertext/Plaintext-Paare sammeln ohne dass du den Schlüssel daraus > ableiten kannst. > Wenn ich das hier (https://crypto.stackexchange.com/questions/1512/why-is-aes-resistant-to-known-plaintext-attacks) richtig verstehe, ist das nur dann der Fall, wenn über den IV eine starke Zufallszahl mit ins Spiel gebracht wird, und damit sind wir wieder bei square one. In jedem Fall würde deine Strategie einem Angreifer ein Zeitfenster von 3 Minuten für eine Playback Attacke einräumen, was bei einem Garagentor je nach Location schon Sicherheitsfragen aufwerfen würde. >> Wenn Du die mobile verlierst oder im Gulli >> versenkst, ist das System in jedem Fall (by design) betriebsunfähig, >> oder? > > Jaja, klar. Ich wollte bloß darauf hinaus, dass es deswegen nichts > bringt, das System auf unendliche Zuverlässigkeit zu optimieren; du > brauchst eh einen Plan B, wenn es nicht auf geht. > >>> Klar, kannst du machen. Ist halt fünftausend mal so komplex: du brauchst >>> >>> - Datenübertragung vom Tor zum Schlüssel >> >> Wie oben geschrieben: Ist das nicht die Grundvoraussetzung der ganzen >> Angelegenheit? > > Nein, für > ich-verschlüssle-die-Uhrzeit-mit-AES-und-prüfe-den-MAC-Variante brauchst > du nur Datenübertragung vom Schlüssel zum Tor; nicht andersherum. > Ok, aber da ist keinerlei Authentifikation und damit Tür und Tor (pun intended) für Spoofing Attacken geöffnet. Für das Garagentor in einem durchschnittlichen Wohnviertel ist das vermutlich ausreichend, aber nicht im Allgemeinfall. >>> - Eine State Machine, die den ganzen Prozess handhabt, inkl. Konzept >>> einer Verbindung etc -- denke mal daran, wie komplex das ist, das mit >>> einem Funkmodul wie z.B. einem nRF24L01 umzusetzen >> >> Wieso? Das ist Anwendungssoftware. > > Die mit TCP arbeitet. Was du auf einem kleinen Funkmodul nicht hast. > Muss nicht über TCP gehen. Der Zustandsautomat kann auch durch Elemente der nonce im Datenpaket codiert sein. >>> - Ein Zertifikat und entweder eine CA oder die Cert-ID des Schlüssels >>> im Tor >> >> Nein. Du brauchst für das Verfahren kein RSA. > > Ich hab auch nix von RSA gesagt. > ok, akzeptiert. Ich hätte schreiben sollen "Nein. Du brauchst für das Verfahren kein PKA." >>> - Erheblich schnellere Sender und Empfänger -- ein TLS-Handshake sind >>> ca. 5 kB >> >> Nein. Du brauchst kein TLS. > > Aber etwas ähnliches wie TLS. > Nein, nur eine zustandsbehaftete (s.o.) 3 Stufen Authentifikationsverhandlung zum Generieren des session keys. Das lässt sich extrem schmal und effizient codieren (habe ich schon des Öfteren gemacht). >>> - Serialisierung für diese ganzen Dinge (x.509?) >> >> Nein. > > Ach so, und die Daten für den Key Exchange werden dann per gutem Willen > kommuniziert oder was? :D > Nein, aber sobald ein session key verhandelt ist und die zugehörige session gültig ist, lässt sich in der verschlüsselten payload ja verhandeln was man will, z.B. Schlüsselgenerationstausch. Die policies wie und wann das passiert sind ja frei definierbar. Ich würde es beim Garagentor z.B. so machen, dass der Schlüssel Generation 0 vom Hersteller hardcodiert ist, bei der Erstinbetriebnahme getauscht werden muss und danach (vom mobilen Teil gesteuert) nach Bedarf.
RAc schrieb: > Nein, aber sobald ein session key verhandelt ist und die zugehörige > session gültig ist, Wirst du merken dass du gar keine geheimen Daten zum übertragen hast und dein Verfahren overengineerter Unfug ist.
Sven B. schrieb: > Ok, kannst du mir mal bitte einen erfolgreichen Known-Plaintext-Angriff > auf AES zeigen? Das funktioniert so nicht, du kannst noch und noch > Cipertext/Plaintext-Paare sammeln ohne dass du den Schlüssel daraus > ableiten kannst. So ist es. Das war einer der Gründe für den AES. > Nein, für > ich-verschlüssle-die-Uhrzeit-mit-AES-und-prüfe-den-MAC-Variante brauchst > du nur Datenübertragung vom Schlüssel zum Tor; nicht andersherum. Das ist in der Tat ein Vorteil - auch sicherheitstechnisch. Denn das bedeutet, dass ein Angreifer ohne gerade aktiven Schlüsselbund keinerlei Informationen aus dem "System Garagentor" herauskitzeln kann, da es schlicht auf nichts antwortet. Die Idee mit einer laufenden Uhr und entsprechender Synchronisation bei Akzeptanz ist nicht schlecht. Wenn man seinen µC jetzt noch vernünftig schlafen legt, dann sollte sich auch der Energieverbrauch in Grenzen halten und man kann ohne externen Uhrenbaustein auskommen.
RAc schrieb: > In jedem Fall würde deine Strategie einem > Angreifer ein Zeitfenster von 3 Minuten für eine Playback Attacke > einräumen, was bei einem Garagentor je nach Location schon > Sicherheitsfragen aufwerfen würde. Das ist allerdings korrekt und spricht eindeutig gegen eine Uhrzeit-Lösung und FÜR ein einfaches aber bidirektionales Protokoll. > Das ist in der Tat ein Vorteil - auch sicherheitstechnisch. Denn das > bedeutet, dass ein Angreifer ohne gerade aktiven Schlüsselbund keinerlei > Informationen aus dem "System Garagentor" herauskitzeln kann, da es > schlicht auf nichts antwortet. Was sollte er denn für Informationen erlangen können, wenn das Garagentor auf eine Öffnungsanfrage lediglich eine zufällige Nonce sendet? Ich habe immer noch kein fundiertes Argument gegen eine Challenge-Response mit Nonce und HMAC gehört. Erfordert nur eine Hashfunktion. Kein AES, kein RSA.
:
Bearbeitet durch User
Cyblord -. schrieb: > In jedem Fall würde deine Strategie einem >> Angreifer ein Zeitfenster von 3 Minuten für eine Playback Attacke >> einräumen, was bei einem Garagentor je nach Location schon >> Sicherheitsfragen aufwerfen würde. Das ließe sich verhindern, wenn man zwar eine gewisse Zeitabweichung zulässt zum Synchronisieren, aber sich die bereits empfangenen Zeiten in diesem Akzeptanzintervall merkt. Dann akzeptiert man die bereits empfangenen Zeitstempel kein zweites Mal --> Replay nicht möglich.
chris schrieb: > Das ließe sich verhindern, wenn man zwar eine gewisse Zeitabweichung > zulässt zum Synchronisieren, aber sich die bereits empfangenen Zeiten in > diesem Akzeptanzintervall merkt. Dann akzeptiert man die bereits > empfangenen Zeitstempel kein zweites Mal --> Replay nicht möglich. Dann kommt es darauf an in welchem Interval deine Zeitstempel generiert werden und davon hängt dann ab wie viele mögliche Zeitstempel du durchprobieren musst um eine gewisse Abweichung zu tolerieren und anderseits aber die Funktion nicht all zu lange zu blockieren. Denn eine Aktion nur alle 30 sek. oder gar nur jede Minute durchführen zu können ist in der Realität eine große Einschränkung.
RAc schrieb: > In jedem Fall würde deine Strategie einem > Angreifer ein Zeitfenster von 3 Minuten für eine Playback Attacke > einräumen, was bei einem Garagentor je nach Location schon > Sicherheitsfragen aufwerfen würde. Das kann man leicht verhindern, indem man einen akzeptierten Schlüssel im Empfänger als "verbraucht" kennzeichnet. Nach drei Minuten kann man die Info dann wegwerfen. Darüberhinaus könnte man nach einem akzeptierten Schlüssel die "Schärfe" des Zeitfensters massiv erhöhen, denn Sender und Empfänger wurden ja gerade synchronisiert. Da reicht dann auch ein einsekündiges Fenster für die nächste Viertelstunde. Damit könnte man dann auch das Tore direkt wieder schließen, bspw. weil man es aus Versehen geöffnet hat oder jemand direkt davor steht. Wobei drei Minuten auch extrem sind. Selbst ohne Synchronisation habe ich das bei unabgeglichenen 08/15-Billigquarzuhren auch nach einem Jahr noch nicht gehabt. > Ok, aber da ist keinerlei Authentifikation und damit Tür und Tor (pun > intended) für Spoofing Attacken geöffnet. Für das Garagentor in einem > durchschnittlichen Wohnviertel ist das vermutlich ausreichend, aber > nicht im Allgemeinfall. Wenn Du so willst, ist das auch eine Session, die bei jedem erfolgreichen Öffnen erneuert wird.
Chris D. schrieb: > Darüberhinaus könnte man nach einem akzeptierten Schlüssel die "Schärfe" > des Zeitfensters massiv erhöhen, denn Sender und Empfänger wurden ja > gerade synchronisiert. Da reicht dann auch ein einsekündiges Fenster für > die nächste Viertelstunde. Damit könnte man dann auch das Tore direkt > wieder schließen, bspw. weil man es aus Versehen geöffnet hat oder > jemand direkt davor steht. Ja mit beliebig viel Aufwand geht alles irgendwie. Und wie handelt man den Batterietausch im Handsender? Wenn danach dessen Uhr wieder auf 0 ist?
Chris D. schrieb: > >> Nein, für >> ich-verschlüssle-die-Uhrzeit-mit-AES-und-prüfe-den-MAC-Variante brauchst >> du nur Datenübertragung vom Schlüssel zum Tor; nicht andersherum. > > Das ist in der Tat ein Vorteil - auch sicherheitstechnisch. Denn das > bedeutet, dass ein Angreifer ohne gerade aktiven Schlüsselbund keinerlei > Informationen aus dem "System Garagentor" herauskitzeln kann, da es > schlicht auf nichts antwortet. > Grundsätzlich ist das richtig, aber der TO hat ja gerade das Thema Playback Attacken ins Spiel gebracht. Meinem Verständnis nach setzt die Playback Attack Prevention notwendigerweise bidirektionale Kommunikation voraus. > Die Idee mit einer laufenden Uhr und entsprechender Synchronisation bei > Akzeptanz ist nicht schlecht. > Allerdings eröffnet sich damit u.A. die Möglichkeit einer Denial of Service Attacke. Wenn nämlich tatsächlich ein (mglw. aus Spass an der Freude agierender Nerd mit zu viel Zeit oder was auch immer) das 3 Minuten Zeitfenster ausnutzt, um mit einer Playback Attacke das Tor ein zweites Mal zu öffnen, hat er nämlich als Seiteneffekt die Uhr des Tores umsynchronisiert. Die Uhr des berechtigten Benutzers wird nun mit einer nicht geringen Wahrscheinlichkeit nicht mehr synchron zur Uhr im Empfänger sein, so dass der Originalkey eben nicht mehr berechtigt öffnen kann.
Cyblord -. schrieb: > chris schrieb: > >> Das ließe sich verhindern, wenn man zwar eine gewisse Zeitabweichung >> zulässt zum Synchronisieren, aber sich die bereits empfangenen Zeiten in >> diesem Akzeptanzintervall merkt. Dann akzeptiert man die bereits >> empfangenen Zeitstempel kein zweites Mal --> Replay nicht möglich. > > Dann kommt es darauf an in welchem Interval deine Zeitstempel generiert > werden und davon hängt dann ab wie viele mögliche Zeitstempel du > durchprobieren musst um eine gewisse Abweichung zu tolerieren und > anderseits aber die Funktion nicht all zu lange zu blockieren. Denn eine > Aktion nur alle 30 sek. oder gar nur jede Minute durchführen zu können > ist in der Realität eine große Einschränkung. Siehe meine Einlassung weiter oben: direkt nach der Synchronisation (also nach der ersten Aktion) ist die Abweichung nicht messbar. Daher kann dann auch das Zeitfenster minimal sein. Ganze "edel" wäre es, anhand der maximal zu erwartenden Drift von Sender/Empfänger das Fenster über die Zeit breiter werden lassen ;-)
Chris D. schrieb: > Ganze "edel" wäre es, anhand der maximal zu erwartenden Drift von > Sender/Empfänger das Fenster über die Zeit breiter werden lassen ;-) Nein nicht Edel, eben nerdiger Unsinn der wieder enormen Spielraum für Bugs und Unsicherheiten eröffnet. Mit jeder Iteration hier wird dein System komplexer und damit unsicherer.
Wenn er AES verschlüsseln möchte kann er doch ganz einfach ein simples Protokoll schreiben! Beide Geräte haben einen AES-Key Im Empfänger wird nach dedem gültigen Frame ein Zähler (der im Frame vom Sender kommt) als minimaler Wert gespeichert, der dann als ungültig erklärt wird. Das sichert gegen Replay-Attacken. Beim Sender baust du einen Start-Zähler ein. Bei jedem Frame wird er hochgezählt. Zusätzlich noch die Steuercodes (wie auf zu etc). Den Framecounter und die Steuercodes nimmst dann und cryptierst diese mit dem AES-Key. Das Ergebniss hängst hinten drann. Der Empfänger macht dann folgendes: Framecounter mit größer gleich soll vegleichen. Gültig? Weiter! Steuercodes lesen. Framecounter und Steuercodes mit dem internen AES-Key vergleichen und sehen ob die verschlüsselte Botschaft die selbe ist, bzw die Botschaft entschlüsseln und sehen ob der Counter und Steuercodes decryptiert übereinstimmen. Pastt es-> weiter und Framecounter-Wert speichern. Alles was gleich und kleiner ist, ist ungültig und eine Reply-Attacke. GGf dies auch speichern.
Cyblord -. schrieb: > Und wie handelt man den Batterietausch im Handsender? Wenn danach dessen > Uhr wieder auf 0 ist? Bspw. so wie bei einer Fritzbox: man drückt beim Empfänger einen Knopf und schickt dann mit frischer Batterie den ersten Zeitstempel, den sie als gültig zu akzeptieren hat. Und/oder man baut einen entsprechenden Pufferkondensator ein, der die paar Sekunden den Saft erhält. Man sollte dann natürlich nicht senden ;-)
Cyblord -. schrieb: > Chris D. schrieb: >> Ganze "edel" wäre es, anhand der maximal zu erwartenden Drift von >> Sender/Empfänger das Fenster über die Zeit breiter werden lassen ;-) > > Nein nicht Edel, eben nerdiger Unsinn der wieder enormen Spielraum für > Bugs und Unsicherheiten eröffnet. Mit jeder Iteration hier wird dein > System komplexer und damit unsicherer. Schon richtig. Dann belasse es eben dabei, nach einem akzeptierten Schlüssel das Fenster für 5 Minuten auf maximal 2 Sekunden Abweichung einzustellen, damit man direkt hintereinander mehrere Befehle absetzen kann.
Beitrag #5873004 wurde vom Autor gelöscht.
Chris D. schrieb: > Bspw. so wie bei einer Fritzbox: man drückt beim Empfänger einen Knopf > und schickt dann mit frischer Batterie den ersten Zeitstempel, den sie > als gültig zu akzeptieren hat. Dann musst du aber für jeden Schlüssel ein völlig eigene Uhrzeit mitführen. Aber ja, geht.
Cyblord -. schrieb im Beitrag #5873004: > Alex W. schrieb: >> Beim Sender baust du einen Start-Zähler ein. Bei jedem Frame wird er >> hochgezählt. Zusätzlich noch die Steuercodes (wie auf zu etc). Den >> Framecounter und die Steuercodes nimmst dann und cryptierst diese mit >> dem AES-Key. Das Ergebniss hängst hinten drann. > > Bringt ein großes Problem: Drückst du den Sender wenn der Empfänger > nicht in Reichweite ist, dann läuft der Framecounter im Sender lustig > weiter, im Empfänger aber nicht. Juckt nicht! Der Sender kann hochzählen so oft er will. Im Empfänger muss geprüft werden ob der Counter größer ist als der letzte bekannte Wert. Ist er es nicht, ist es eine Replay-Attacke. Ist er größer, kennt der Sender den Key. Dann ist es aber eh Wayne wenn es ein Angreifer ist...
Alex W. schrieb: > Juckt nicht! Der Sender kann hochzählen so oft er will. Im Empfänger > muss geprüft werden ob der Counter größer ist als der letzte bekannte > Wert. Ist er es nicht, ist es eine Replay-Attacke. Ist er größer, kennt > der Sender den Key. Dann ist es aber eh Wayne wenn es ein Angreifer > ist... Ahso du sendest den Counter als Klartext noch mit.
Chris D. schrieb: > RAc schrieb: >> In jedem Fall würde deine Strategie einem >> Angreifer ein Zeitfenster von 3 Minuten für eine Playback Attacke >> einräumen, was bei einem Garagentor je nach Location schon >> Sicherheitsfragen aufwerfen würde. > > Das kann man leicht verhindern, indem man einen akzeptierten Schlüssel > im Empfänger als "verbraucht" kennzeichnet. Nach drei Minuten kann man > die Info dann wegwerfen. > was dann aber implizieren würde, dass ein Schlüsselgenerationstausch mit jeder Transaktion verpflichtend wäre. Wenn das der Fall wäre, bräuchte man die Zeitsynchronisation gar nicht erst, dann wäre die Schlüsselneuverhandlung in der Transaktion ausreichend für die Playback Attack Prevention. Hätte allerdings den in der Praxis unangenehmen Seiteneffekt, dass nur ein Öffnungsmodul möglich wäre, also könnten nicht mehrere Leute mit mehreren Öffnern auf demselben Garagentor arbeiten. Oder meinst Du einfach, dass innerhalb eines 3 Minuten Zeitfensters nur eine Öffnung erlaubt ist? Sehe ich in der Praxis auch als problematisch an (im Regen 3 Minuten warten zu müssen weil einem eingefallen ist dass man noch etwas im Auto vergessen hat...). Klar kann man die 3 Minuten auch reduzieren (die waren jetzt erstmal nur eine Arbeitshypothese), aber beliebig niedrig kann man ja auch nicht gehen (s.u.)... > Darüberhinaus könnte man nach einem akzeptierten Schlüssel die "Schärfe" > des Zeitfensters massiv erhöhen, denn Sender und Empfänger wurden ja > gerade synchronisiert. Da reicht dann auch ein einsekündiges Fenster für > die nächste Viertelstunde. Damit könnte man dann auch das Tore direkt > wieder schließen, bspw. weil man es aus Versehen geöffnet hat oder > jemand direkt davor steht. > Naja, und was macht man da mit wenig frequentierten Garagen, die mglw. nur 1x am Tag genutzt werden? In solchen Fällen kumulieren sich ja leicht asynchrone Uhren, so dass kleine Zeitfenster zum Problem werden können.
Chris D. schrieb: > Darüberhinaus könnte man nach einem akzeptierten Schlüssel die "Schärfe" > des Zeitfensters massiv erhöhen, denn Sender und Empfänger wurden ja > gerade synchronisiert. Da reicht dann auch ein einsekündiges Fenster für > die nächste Viertelstunde. Damit könnte man dann auch das Tore direkt > wieder schließen, bspw. weil man es aus Versehen geöffnet hat oder > jemand direkt davor steht. Das berücksichtigt aber nicht, daß man z.B. zwei oder 3 Handsender hat. Es gibt ja auch für ein mechanisches Schloss manchmal mehrere Schlüssel :-) Also ist man wieder bei einem rolling code plus Handsender ID
Alex W. schrieb: > Wenn er AES verschlüsseln möchte kann er doch ganz einfach ein simples > Protokoll schreiben! > > Beide Geräte haben einen AES-Key > > Im Empfänger wird nach dedem gültigen Frame ein Zähler (der im Frame vom > Sender kommt) als minimaler Wert gespeichert, der dann als ungültig > erklärt wird. Das sichert gegen Replay-Attacken. > > Beim Sender baust du einen Start-Zähler ein. Bei jedem Frame wird er > hochgezählt. Zusätzlich noch die Steuercodes (wie auf zu etc). Den > Framecounter und die Steuercodes nimmst dann und cryptierst diese mit > dem AES-Key. Das Ergebniss hängst hinten drann. Auch nicht schlecht, zumal man das im EEPROM sichern könnte. > Alles was gleich und > kleiner ist, ist ungültig und eine Reply-Attacke. GGf dies auch > speichern. Für zusätzliche Sicherheit könnte man auch hier ein "Fenster" einsetzen, bspw. muss der Zähler im Bereich X+1000 stehen. Bei einem 32-Bit-Zähler spielt das keine Rolle, schränkt aber die gültigen Zählerstände kräftig ein. Natürlich darf man dann unterwegs nicht 1000 mal auf den Knopf drücken ;-)
Alex W. schrieb: > Juckt nicht! Der Sender kann hochzählen so oft er will. Im Empfänger > muss geprüft werden ob der Counter größer ist als der letzte bekannte > Wert. Ist er es nicht, ist es eine Replay-Attacke. Ist er größer, kennt > der Sender den Key. Dann ist es aber eh Wayne wenn es ein Angreifer > ist... Finde ich auf den ersten Blick nicht so schlecht die Variante. Aber das heißt auch, ein Angreifer muss nur ein einziges gültiges Frame erzeugen mit einem praktisch beliebigen Counterwert (solange größer als die letzten). Und hat dafür auch so lange Zeit wie er möchte. Das klingt für mich nach Birthday-Attacke. > Für zusätzliche Sicherheit könnte man auch hier ein "Fenster" einsetzen, > bspw. muss der Zähler im Bereich X+1000 stehen. Bei einem 32-Bit-Zähler > spielt das keine Rolle, schränkt aber die gültigen Zählerstände kräftig > ein. Das ist auf jeden Fall zu empfehlen.
:
Bearbeitet durch User
Cyblord -. schrieb: > Alex W. schrieb: >> Juckt nicht! Der Sender kann hochzählen so oft er will. Im Empfänger >> muss geprüft werden ob der Counter größer ist als der letzte bekannte >> Wert. Ist er es nicht, ist es eine Replay-Attacke. Ist er größer, kennt >> der Sender den Key. Dann ist es aber eh Wayne wenn es ein Angreifer >> ist... > > Ahso du sendest den Counter als Klartext noch mit. Genau. Im Endeffekt sendest du zuerst alles in Klartext und sendest dabei dann den Klartext nochmals verschlüsselt mit. AES ist sicher genug damit daraus nicht der Key errechnet werden kann.
Udo S. schrieb: > Das berücksichtigt aber nicht, daß man z.B. zwei oder 3 Handsender hat. > Es gibt ja auch für ein mechanisches Schloss manchmal mehrere Schlüssel > :-) Das stimmt. Man müsste also für jeden Schlüssel ein eigenes Zeitfenster und eine eigene Zeit haben, um sie unterscheiden zu können. Ist nicht schwer zu implementieren, widerspricht aber dem Prinzip: so einfach wie möglich. Ja, das ist ein Nachteil.
Alex W. schrieb: > Juckt nicht! Der Sender kann hochzählen so oft er will. Im Empfänger > muss geprüft werden ob der Counter größer ist als der letzte bekannte > Wert. Ist er es nicht, ist es eine Replay-Attacke. Ist er größer, kennt > der Sender den Key. Dann ist es aber eh Wayne wenn es ein Angreifer > ist... Nette Idee, berücksichtigt aber leider nicht die Möglichkeit, dass eine der beiden Seiten in einen Reset fällt oder aus einem anderen Grunde den Zählerwert verliert... im blödesten Fall liegt dann die erwartete Sequenznummer so niedrig, dass jeder Replay damit (einmalig, aber reicht ja) durchgewunken wird. Klar kann man nun wieder Handshakes und Signaturen definieren, um beide Seiten auf eine Neuverhandlung der Sequenznummer zu zwingen, aber dann sind wir wieder bei einer Zustandsbehafteten Verhandlung, und damit wäre das schon öfter erwähnte Challenge Response Verfahren zur Aushandlung von session keys doch wieder die einfachere Variante.
RAc schrieb: > Nette Idee, berücksichtigt aber leider nicht die Möglichkeit, dass eine > der beiden Seiten in einen Reset fällt oder aus einem anderen Grunde den > Zählerwert verliert... Möglich. Aber wenn die Zählwerte auf beiden Seiten remanent gespeichert werden ist die Wahrscheinlichkeit gering und nicht relevant für eine Garagentoranwendung. Ich finde die Variante deutlich besser als jene mit Uhrzeit. Alle Varianten haben gemein dass es umständlich wird, sobald mal eine Hardware die grätsche Macht und man Austauschen muss. Denn jede automatische Synchronisation bringt wieder sehr viel Komplexität mit sich. Dann muss man meist direkt Hand anlegen und die Schlüssel generieren und manuell in beide Geräte einspielen. Ist meistens so bei Hobbykram.
:
Bearbeitet durch User
RAc schrieb: > Nette Idee, berücksichtigt aber leider nicht die Möglichkeit, dass eine > der beiden Seiten in einen Reset fällt oder aus einem anderen Grunde den > Zählerwert verliert... In diesem Fall sollte man es typisch deutsch halten: einfach sein lassen wegen könnte, hätte, würde, fahradkette...
Ich denke allerdings immer noch über die sicherheitstechnischen Implikationen für AES nach, falls der Counterspace nicht eingeschränkt wäre. Klassische Birthday-Attacke für AES erfordert normalerweise sehr viele gültige Schlüssel wobei es reicht einen davon zu bekommen. Das ist hier nicht der Fall, denn es gibt nur einen Schlüssel. Aber vom Gefühl her müsste der Ansatz die Sicherheit von AES schon irgendwie beeinträchtigen.
Vielleicht habe ich es beim Überfliegen überlesen, aber was wäre, wenn man zufällige Daten mitüberträgt, die stimmig sein müssen? Zum Beispiel überträgt man vor der Zeit zwei zufällige Zahlen und dahinter das Produkt dieser beiden Zahlen, also "242-263-<Zeit>-63646". Selbst wenn ein Angreifer auf die Idee kommen sollte, dass das Datum als Nachricht verwendet wird, könnte er trotzdem wahrscheinlich keine gültige Nachricht erzeugen, weil relevante Teile der Nachricht fehlen. Das Verfahren ließe sich natürlich noch verbessern.
Cyblord -. schrieb: > RAc schrieb: >> Nette Idee, berücksichtigt aber leider nicht die Möglichkeit, dass eine >> der beiden Seiten in einen Reset fällt oder aus einem anderen Grunde den >> Zählerwert verliert... > > Möglich. Aber wenn die Zählwerte auf beiden Seiten remanent gespeichert > werden ist die Wahrscheinlichkeit gering und nicht relevant für eine > Garagentoranwendung. > > Ich finde die Variante deutlich besser als jene mit Uhrzeit. > Das in jedem Fall, aber sie ist schlechter als die Session Key Methode. Aus dem einfachen Grunde, dass damit wieder 1:many Tor<->Steuerkombinationen nicht gut abgehandelt werden können, denn die Steuergeräte kommunizieren ja nicht miteinander, wissen also nichts davon, welche Sequenznummer beim Tor gerade "aktuell" ist. Das liesse sich nur dann in den Griff kriegen, wenn sich die Steuergeräte identifizieren würden und die Sequenznummern instantiiert verwaltet werden.
Dussel schrieb: > Vielleicht habe ich es beim Überfliegen überlesen, aber was wäre, wenn > man zufällige Daten mitüberträgt, die stimmig sein müssen? > Zum Beispiel überträgt man vor der Zeit zwei zufällige Zahlen und > dahinter das Produkt dieser beiden Zahlen, also "242-263-<Zeit>-63646". > Selbst wenn ein Angreifer auf die Idee kommen sollte, dass das Datum als > Nachricht verwendet wird, könnte er trotzdem wahrscheinlich keine > gültige Nachricht erzeugen, weil relevante Teile der Nachricht fehlen. > Das Verfahren ließe sich natürlich noch verbessern. Security by Obscurity. Nicht mehr. Erhöht die Sicherheit nicht.
RAc schrieb: > Das in jedem Fall, aber sie ist schlechter als die Session Key Methode. Die aber bidirektionale Kommunikation erfordert. Damit ergeben sich IMO sowieso bessere Möglichkeit als einen Session Key. Aber wenn man die Unidirektionalen Varianten betrachtet ist der Ansatz der Beste, IMO.
Garagentor - Wochenendprojekt. 1. Garagenempfänger AVR <- AES128 2. Handsender AVR -> AES128 3. für beide gleicher Schlüssel 4. min. 32 Bit Zähler im Handsender + 2 Kommandos (AUF/ZU) 5. beide AVRs fangen mit Zählerstand 0 an. 6. Der empfangene Zählerstand darf max. 1000 nach oben abweichen 7. über 100 J. Funktion bei max. Abweichung, 32 Bit & 100 Betätigungen/d AVR-AES Empfehlung: http://point-at-infinity.org/avraes/
B. Jacob schrieb: > Garagentor - Wochenendprojekt. > > 1. Garagenempfänger AVR <- AES128 > 2. Handsender AVR -> AES128 > 3. für beide gleicher Schlüssel > 4. min. 32 Bit Zähler im Handsender + 2 Kommandos (AUF/ZU) > 5. beide AVRs fangen mit Zählerstand 0 an. > 6. Der empfangene Zählerstand darf max. 1000 nach oben abweichen > 7. über 100 J. Funktion bei max. Abweichung, 32 Bit & 100 Betätigungen/d > GENAU Darüber reden wir grade....
Cyblord -. schrieb: > RAc schrieb: >> Das in jedem Fall, aber sie ist schlechter als die Session Key Methode. > > Die aber bidirektionale Kommunikation erfordert. Damit ergeben sich IMO > sowieso bessere Möglichkeit als einen Session Key. > > Aber wenn man die Unidirektionalen Varianten betrachtet ist der Ansatz > der Beste, IMO. wie stehst Du zu der 1:many Problematik mit der Sequenznummer uni Lösung?
RAc schrieb: > wie stehst Du zu der 1:many Problematik mit der Sequenznummer uni > Lösung? Natürlich braucht man für jeden Handsender auch eine ID, einen eignen Key und ne eigene Sequenznummer in der Basisstation. Nur ist das ein Problem oder was meinst du genau?
:
Bearbeitet durch User
Cyblord -. schrieb: > RAc schrieb: > >> wie stehst Du zu der 1:many Problematik mit der Sequenznummer uni >> Lösung? > > Natürlich braucht man für jeden Handsender auch eine ID, einen eignen > Key und ne eigene Sequenznummer in der Basisstation. > > Nur ist das ein Problem oder was meinst du genau? ja, aber dann geht es sofort wieder los: Über das Protokoll muss sich jeder Sender dann zuerst identifizieren, d.h. wir sind dann wieder bei einem zustandsbehafteten Protokoll (was ja Sven eben nicht will). Mit einem zustandsbehafteten Protokoll können wir aber genau so gut gleich einen session key verhandeln (was sowieso nahe liegt, da mit der Identifikation auch eine Authentifikation ausgehandelt werden kann). Damit brauchen wir dann auch keine nonce mit Sequenznummer mehr. Wenn wir das mit instantiierten Sequenznummern machen, ist wieder die Frage, was passiert, wenn sich ein nicht bekanntes Modul anmeldet. Das ist im Endbetrieb ja erstmal jederzeit möglich (ein Handgerät wird gewechselt oder zugekauft). Solange der aktuelle key stimmt, spricht ja auch nichts dagegen, aber vermutlich sollte im workflow so ein neues Gerät "freigeschaltet" werden müssen (also wie bei der Fritzbox). Muss halt Alles gemacht werden! Mit Sessionbasierten Verhandlungen müssen Steuergeräte nicht identifiziert werden, da reicht der gemeinsame Schlüssel.
Es geht hier doch um EINE Garage, kein Massenprodukt und keine Raketenabschussbasis. Die zu übertragenden Daten sind unbekannt. Der Angreifer weiß also nicht, ob ein Datum und/oder eine Zufallszahl mit dem Geheimnis verknüpft übertragen wird. Es geht doch nur darum, dass niemand eine mitgeschnittene Übertragung wiederholen kann. Und wenn der Code mal nicht funktioniert, weil irgend etwas aus dem Sync gelaufen ist, muss es immer noch einen Schlüssel geben. In der Garage kann man den Sender problemlos zum Synchronisieren an einen (meinetwegen auch versteckt untergebrachten) Kontakt halten.
Brummbär schrieb: > Es geht hier doch um EINE Garage, kein Massenprodukt und keine > Raketenabschussbasis. > Ja, aber EINE Garage mit möglicherweise MEHREREN Steuergeräten. Das hat technisch schon einen Einfluss auf die Realisierung! > Die zu übertragenden Daten sind unbekannt. Der Angreifer weiß also > nicht, ob ein Datum und/oder eine Zufallszahl mit dem Geheimnis > verknüpft übertragen wird. Es geht doch nur darum, dass niemand eine > mitgeschnittene Übertragung wiederholen kann. > Richtig ("Playback Attacke"). Dafür gibt es mehrere Lösungsansätze, die (wie immer) gegeneinander abgewogen werden müssen in Bezug auf die relevanten Faktoren (Sicherheitsgrad, Realisierbarkeit, Aufwand, Stromverbrauch, Störsicherheit, Einfluss auf den workflow etc pp). Ich finde das in diesem Thread eigentlich sehr zivilisiert und on topic; wir diskutieren ja genau das, oder? > Und wenn der Code mal nicht funktioniert, weil irgend etwas aus dem Sync > gelaufen ist, muss es immer noch einen Schlüssel geben. In der Garage > kann man den Sender problemlos zum Synchronisieren an einen (meinetwegen > auch versteckt untergebrachten) Kontakt halten. Ack. Deswegen sollte aber der Notanker wirklich nur im seltenen Ausnahmefall zum Einsatz kommen, sonst leidet die Akzeptanz der Lösung darunter, oder?
RAc schrieb: > ja, aber dann geht es sofort wieder los: Über das Protokoll muss sich > jeder Sender dann zuerst identifizieren, d.h. wir sind dann wieder bei > einem zustandsbehafteten Protokoll Nein er sendet nur die ID mit den Klartextdaten mit, damit die Basis weiß welchen Schlüssel und welchen Sequenzzähler es zu bedienen gilt. Das fügt keinen Zustand hinzu. > Wenn wir das mit instantiierten Sequenznummern machen, ist wieder die > Frage, was passiert, wenn sich ein nicht bekanntes Modul anmeldet. Das > ist im Endbetrieb ja erstmal jederzeit möglich (ein Handgerät wird > gewechselt oder zugekauft). Solange der aktuelle key stimmt, spricht ja > auch nichts dagegen, aber vermutlich sollte im workflow so ein neues > Gerät "freigeschaltet" werden müssen (also wie bei der Fritzbox). Muss > halt Alles gemacht werden! Für Hobbykram macht man das manuell. Es geht ja nicht um ein Verkaufsprodukt.
Cyblord -. schrieb: > RAc schrieb: >> ja, aber dann geht es sofort wieder los: Über das Protokoll muss sich >> jeder Sender dann zuerst identifizieren, d.h. wir sind dann wieder bei >> einem zustandsbehafteten Protokoll > > Nein er sendet nur die ID mit den Klartextdaten mit, damit die Basis > weiß welchen Schlüssel und welchen Sequenzzähler es zu bedienen gilt. > Das fügt keinen Zustand hinzu. > Also dein Ansatz wäre eine "atomische" Öffnung, also ein einzelnes unidirektionales Paket vom Steuergerät zur Basis mit folgendem Inhalt: - Klartextnonce, minimal bestehend aus - Geräte Id - Sequenznummer - Anzahl relevanter Bytes der Payload (wichtig weil AES 16 byte gepaddete Blöcke fordert) - cryptierte Payload, minimal bestehend aus - <optional beliebige Originalpayload, z.B. neue Schlüsselgeneration> - CMAC über die nonce <und optionaler Klartextpayload> ? Dann würde die Basis nach Empfang das Paket trennen, die cryptierte Payload mit dem aktuellen Schlüssel decryptieren, die CMAC über die nonce und die optionale Originalpayload berechnen und vergleichen. Bei positivem Vergleich und akzeptierter Sequenznummer wird die Tür geöffnet, die erwartete Sequenznummer erhöht und ggf. die Payload ausgewertet (also z.B. Schlüssel tauschen). Ggf. durch geeignete Massnahmen dafür sorgen, dass die Sequenznummerierung fehlertolerant ist. Das könnte klappen. Was mir dabei noch einfällt ist dass die Sendestation in dieser Strategie keinerlei feedback über die Transaktion bekommt. Wenn z.B. tatsächlich ein Schlüsseltausch in der Payload beinhaltet ist, dann muss die Sendestation erfahren können, ob die Basis den Tausch wirklich angenommen hat, sonst haben nämlich beide Seiten plötzlich unterschiedliche Schlüssel. Das geht ja aber nicht, weil es keine Antwort gibt.* Es hilft dann leider auch nichts, wenn sich die Sendestation mehrere Schlüsselgenerationen merkt, weil sie eben durch das fehlende feedback nicht weiss, ob sie noch einen älteren Schlüssel ausprobieren sollte. Also mit einem atomischen Protokoll sind meinem Verständnis nach Schlüsselgenerationswechsel over the air nicht machbar. Muss ja aber auch nicht sein. Hobbyanwendung, wie Du sagst. Da es sich hier immer um einen begehbaren Bereich handelt, ist die manuelle Kopplung neuer Stationen realistisch möglich. Die höheren Anforderungen werden hier auf den Produktionsworkflow verlagert (die die Produktionsstätte verlassenden Geräte müssen in einem zusätzlichen Prüf- (und ggf. Produktions)schritt individualisiert werden). * Antworten würden das Protokoll sofort zustandsbehaftet machen (Stichwort Garagenparks mit mehreren nebenläufig geöffneten Garagen).
RAc schrieb: > Schreiben wir aneinander vorbei? Du brauchst doch in jedem Fall zwei > Komponenten, die miteinander in (Funk)Kommunikation stehen und in > irgendeiner Form glauben sich gegenseitig vetrauen zu können, von denen > die eine stationär (in der Garage) und die andere mobil (am Benutzer) > ist, oder was fehlt mir da? Wenn Du die mobile verlierst oder im Gulli > versenkst, ist das System in jedem Fall (by design) betriebsunfähig, > oder? -> jeden Chip kann man auslesen, zur Not direkt auf die Chipfläche. Ich war früher selbst mal im Bereich Garagentor unterwegs … Ich habe mich damals zum Einstieg etwas mit der Sicherheit beschäftigt … damals gabs noch keine Kinder und es war Abends viel Zeit nach der Arbeit. -> Aber zum Thema: Handsender senden meistens kontinuierlich, weil das bequem ist. Öffnen des Tores im Funk-Grenzbereich inzwischen muss ja das Signal eigentlich ausgewertet werden und das Tor darf sich nur im "Sichtbereich" öffnen lassen. Zumindest wenn das so gekommen ist wie es danach aussah. Aber egal: Das System das damals im Einsatz war, konnte man einfach damit überlisten, dass man das Signal so stark stört das nach einem akzeptierten Key des Tores ein nicht mehr benötigter so gestört wird, dass er noch nicht "Verbraucht" ist und diesen gleichzeitig aus der Störung die man ja kennt extrahiert. Ohne Zeit … bidirektionale Kommunikation usw. kann dieser dann nachträglich einfach gesendet werden und Sesam öffne dich das war schon irgendwie cool. Wobei in dem Fall auch der Schlüssel der Verschlüsselung noch über Nacht auf potenter Hardware berechnet werden konnte. Ältere Generationen ließen sich sogar noch einfach über die Lichtschranken im geschlossenen Zustand öffnen. Per EMV Störimpuls konnte man auch den Controller Resetten -> Tor fährt nicht mehr weiter zu. Auch nett ;). Allerdings kann ich schlecht abschätzen wie unauffällig das noch aus 25 m oder so gewesen wäre. Das ist auch ab und an beim Abschalten des Motors passiert -> das hat man dann über die gleiche Signalisierung von Betriebspunkten in der Software verdeckt und die Position doppelt abgelegt mitgeschrieben. Gab nie Auffälligkeiten, scheint also extrem zuverlässig funktioniert zu haben.
PS das mit dem Entschlüsselungsverfahren hatte nicht ich entwickelt, sondern das tauchte im Netz mal irgendwann als öffentliche Abschlussarbeit einer NRW-Hochschule auf.
RAc schrieb: > Also dein Ansatz wäre eine "atomische" Öffnung, also ein einzelnes > unidirektionales Paket vom Steuergerät zur Basis mit folgendem Inhalt: Also es war nicht mein Ansatz sondern der von Alex W. aber ich finde ihn gut. Und nein ganz korrekt hast du es nicht wiedergegeben: 1.) Sender sendet Paket aus ID+Sequenz+AES(Command+Sequenz). ID bestimmt Sequenzzähler und Schlüssel. 2.) Empfänger entschlüsselt 3.) Empfänger vergleicht Klartext Sequenz mit verschlüsselter Sequenz 4.) Sequenz muss größer als Sequenz in letztem gültigen Datenpaket sein 5.) Sequenz muss kleiner als (Sequenzin +1000) in letztem gültigen Datenpaket sein. 6.) Wenn das alles passt Command ausführen + letzte Sequenz auf aktuelle Sequenzin setzen. Ist zustandslos (auf Komm. Ebene) und unidirektional.
:
Bearbeitet durch User
Cyblord -. schrieb: > Dann muss man meist direkt Hand anlegen und die Schlüssel > generieren und manuell in beide Geräte einspielen. Ist meistens so bei > Hobbykram. Das ist genauso wenn man bei Autos Funkschlüssel neu anlernen muss. Cyblord -. schrieb: > 1.) Sender sendet Paket aus ID+Sequenz+AES(Command+Sequenz) > 2.) Empfänger entschlüsselt > 3.) Empfänger vergleicht Klartext ID mit verschlüsselter ID > 4.) ID muss größer als ID in letztem gültigen Datenpaket sein > 5.) ID muss kleiner als (ID+1000) in letztem gültigen Datenpaket sein. Verwechselst du ab Punkt 3 ID mit Sequenz?
Das Verfahren sieht mir doch sehr stark nach KEELOQ aus ;)
Udo S. schrieb: > Cyblord -. schrieb: >> Dann muss man meist direkt Hand anlegen und die Schlüssel >> generieren und manuell in beide Geräte einspielen. Ist meistens so bei >> Hobbykram. > > Das ist genauso wenn man bei Autos Funkschlüssel neu anlernen muss. > > Cyblord -. schrieb: >> 1.) Sender sendet Paket aus ID+Sequenz+AES(Command+Sequenz) >> 2.) Empfänger entschlüsselt >> 3.) Empfänger vergleicht Klartext ID mit verschlüsselter ID >> 4.) ID muss größer als ID in letztem gültigen Datenpaket sein >> 5.) ID muss kleiner als (ID+1000) in letztem gültigen Datenpaket sein. > > Verwechselst du ab Punkt 3 ID mit Sequenz? Ja, ist korrigiert.
RAc schrieb: > Wenn ich das hier > (https://crypto.stackexchange.com/questions/1512/why-is-aes-resistant-to-known-plaintext-attacks) > richtig verstehe, Dem ist übrigens m.E. nicht so, schon deshalb, weil IVs etwas für Verfahren sind die mehrere Blöcke chiffrieren, was du hier aber überhaupt nicht brauchst. Deine Payload ist ja kürzer als ein AES-Block. Den Rest des Klartext-Blocks kannst du dann einfach mit Zufall füllen. Oder mit Nullen, das sollte sich eigentlich gleich bleiben.
:
Bearbeitet durch User
Man braucht keine Verschlüsselung, ein guter hash reicht völlig aus.
RAc schrieb: > Wenn wir das mit instantiierten Sequenznummern machen, ist wieder die > Frage, was passiert, wenn sich ein nicht bekanntes Modul anmeldet. Das > ist im Endbetrieb ja erstmal jederzeit möglich (ein Handgerät wird > gewechselt oder zugekauft). Solange der aktuelle key stimmt, spricht ja > auch nichts dagegen, aber vermutlich sollte im workflow so ein neues > Gerät "freigeschaltet" werden müssen (also wie bei der Fritzbox). Muss > halt Alles gemacht werden! Was ich mir gestern noch überlegt habe: Man könnte das Anmelden neuer Geräte so vereinfachen, dass man jedem Gerät eine pro Gerät fortlaufende, feste ID zuteilt und die inkl. Zählerstand verschlüsselt mitschickt. Der Empfänger packt dann alles aus und sieht beim ersten Öffnen: "Aha - wir haben eine bisher unbekannte ID." Daraufhin legt er einen neuen Zähler im EEPROM an und speichert den übermittelten Zählerstand dort ab. Bei weiteren Empfängen dieser ID schaut er nur noch nach, ob diese bereits angelegt ist und vergleicht dann auch nur dessen Zählerstand. Damit wäre der Sender identifiziert und der Zähler korrekt initialisiert. Man braucht dafür also nicht mal eine Kopplung a la Fritzbox sondern kann wie bei einem sessionbasierendem Gerät den Sender sofort nutzen. Damit könnte man dann auch verlorene/gestohlene Sender explizit im Empfänger sperren. Gibt es dagegen Einwände?
:
Bearbeitet durch Moderator
Chris D. schrieb: > Man könnte das Anmelden neuer Geräte so vereinfachen, dass man jedem > Gerät eine pro Gerät fortlaufende, feste ID zuteilt und die inkl. > Zählerstand verschlüsselt mitschickt. Der Empfänger packt dann alles aus > und sieht beim ersten Öffnen: "Aha - wir haben eine bisher unbekannte > ID." > > Daraufhin legt er einen neuen Zähler im EEPROM an und speichert den > übermittelten Zählerstand dort ab. > > Bei weiteren Empfängen dieser ID schaut er nur noch nach, ob diese > bereits angelegt ist und vergleicht dann auch nur dessen Zählerstand. > > Damit wäre der Sender identifiziert und der Zähler korrekt > initialisiert. > > Man braucht dafür also nicht mal eine Kopplung a la Fritzbox sondern > kann wie bei einem sessionbasierendem Gerät den Sender sofort nutzen. > > Damit könnte man dann auch verlorene/gestohlene Sender explizit im > Empfänger sperren. > > Gibt es dagegen Einwände? Bin mir nicht ganz sicher, ob ich das richtig verstehe... da der letzte Diskussionsstand ja eine unidirektionale Kommunikation war, würden sich Endgeräte in deinem Workflow selber anmelden? Wie würden dann zwei nebeneinanderliegende Garagen unterscheiden können, welche Öffner zu ihnen und nicht der anderen Garage gehören? Die Anderen Variante würde ja voraussetzen, dass es auch einen Datenfluss vom Tor zum Öffner gibt, was wir ja eigentlich vermeiden wollten?
Ruediger A. schrieb: > Bin mir nicht ganz sicher, ob ich das richtig verstehe... da der letzte > Diskussionsstand ja eine unidirektionale Kommunikation war, würden sich > Endgeräte in deinem Workflow selber anmelden? Ja. > Wie würden dann zwei > nebeneinanderliegende Garagen unterscheiden können, welche Öffner zu > ihnen und nicht der anderen Garage gehören? Durch den allen Sendern zu einem Epfänger gemeinsamen Schlüssel. Die anderen Garagenempfänger können mit der Nachricht gar nicht erst etwas anfangen, da sie den Schlüssel nicht besitzen. Der Sender muss in dieser Hinsicht also schon zum Empfänger "passen". Ansonsten müsste man doch wieder mit Taste am Empfänger arbeiten, um Sender anzumelden. Aber das Problem hat man auch bei bidirektionaler Kommunikation. > Die Anderen Variante würde ja voraussetzen, dass es auch einen > Datenfluss vom Tor zum Öffner gibt, was wir ja eigentlich vermeiden > wollten? Ja.
Ich habe diese AppNote von Microchip gefunden: http://ww1.microchip.com/downloads/en/AppNotes/00001683A.pdf Stichwort Ultimate KeeLoq Da reiner Rolling-Code mit inkrementiertem Zähler auch attackiert werden kann, wird hier ein Timestamp verwendet.
1 | Many vehicles on the road use a remote keyless system, or key fob, for the convenience of the user. Modern systems are hardened against simple replay attacks, but are vulnerable to buffered replay attacks. This attack is performed by placing a device that can receive and transmit radio waves within range of the target vehicle. The transmitter will attempt to jam any RF vehicle unlock signal sent to it, while placing it in a buffer for later use. Upon further attempts to unlock the vehicle, the transmitter will jam the new signal, cache it, and play back the old one, creating a rolling buffer that is one step ahead of the vehicle. At a later time, the attacker may use this buffered code to unlock the vehicle. |
( https://howlingpixel.com/i-en/Replay_attack ) Bei Ultimate KeeLoq wird auch ein Timestamp verwendet. In der AppNote wird auch ein Verfahren zur Resynchronisation bei Batteriewechsel des Senders beschrieben. (Jeder Sender hat einen Zähler, der die Anzahl seiner Power-Ups zählt. Nach einem Power-Up setzt er ein Resync-Bit im Datenpaket. Der Empfänger akzeptiert eine Neusynchronisation nur, wenn der Power-Up-Zählerstand höher ist als beim letzten Mal --> Replay verhindert) Der Empfänger sollte dagegen eine batteriegepufferte RTC haben, da man sonst alle Sender neu synchronisieren muss (z.B. durch Batterie raus und rein). Vorteil davon ist nebenbei: Ein Sender kann mit mehreren Empfängern verwendet werden, ohne dass seine Sequenznummer zu weit von der im anderen Empfänger gespeicherten abweicht, da immer nur Timestamps verwendet werden. Das ganze zu implementieren wäre doch ein nettes Projekt ;) LG Chris
Wenn ich mal davon ausgehe, dass man aus einer Nachricht nicht mit vertretbarem Aufwand auf den verwendeten Schlüssel zurückrechnen kann: Dann kann ich eine ausreichend lange Zufallszahl erzeugen, die einmal im Klartext und einmal ausreichend hoch verschlüsselt schicken. Der Empfänger kann die Nachricht entschlüsseln und den Inhalt von Klartext und entschlüsseltem Text vergleichen. Stimmt er überein, stammt die Nachricht vom Sender mit dem richtigen Schlüssel. Wenn jemand die Nachricht mitschreibt, kennt er zwar den Klartext, aber der ist ja kein Geheimnis. Aber er kann keine eigenen Nachrichten erzeugen, denn er hat den Schlüssel nicht und kann ihn nicht ermitteln. Der Empfänger muss nur sicherstellen, dass er bereits empfangene Zufallszahlen nicht wieder akzeptiert, die müssen also alle gespeichert werden. Und durch eine ausreichend hohe Länge der Zufallszahl muss die Wiederholwahrscheinlichkeit beim Sender vernachlässigbar klein werden. Was spricht dagegen?
Karl K. schrieb: > Der > Empfänger kann die Nachricht entschlüsseln und den Inhalt von Klartext > und entschlüsseltem Text vergleichen. Stimmt er überein, stammt die > Nachricht vom Sender mit dem richtigen Schlüssel. Siehe alle anderen Beiträge oben! Nur dass deine Idee empfindlich gegen Reply-Attacken ist.
Karl K. schrieb: > Der Empfänger muss nur sicherstellen, dass er bereits empfangene > Zufallszahlen nicht wieder akzeptiert, die müssen also alle gespeichert > werden. Und durch eine ausreichend hohe Länge der Zufallszahl muss die > Wiederholwahrscheinlichkeit beim Sender vernachlässigbar klein werden. > > Was spricht dagegen? Dass du die alle speichern musst, was a) den Rechenaufwand und b) den Speicherbedarf linear mit der Anzahl der Gesamt-Öffnungsvorgänge steigen lässt. Geht schon, aber mit einem 4 kB EEPROM wirst du vermutlich nicht lange Spaß dran haben. Da musst du schon was größeres verbauen.
Alex W. schrieb: > Siehe alle anderen Beiträge oben! Sie braucht aber weder synchron laufende Uhren noch einen inkrementierenden Zähler. > Nur dass deine Idee empfindlich gegen > Reply-Attacken ist. Nicht, wenn sich der Empfänger empfangene Codes merkt. Brauchbar nur für "geringe" Anzahl von Übertragungen, wobei gering bei einer Zufallszahl von 64bit schon einige zig tausend sein dürften.
Karl K. schrieb: > Sie braucht aber weder synchron laufende Uhren noch einen > inkrementierenden Zähler. Ok, bau es so! Hast Recht!
Karl K. schrieb: > Sie braucht aber weder synchron laufende Uhren noch einen > inkrementierenden Zähler. Dafür dann halt Speicher. Das ist nicht besser.
Karl K. schrieb: > Nicht, wenn sich der Empfänger empfangene Codes merkt. Brauchbar nur für > "geringe" Anzahl von Übertragungen, wobei gering bei einer Zufallszahl > von 64bit schon einige zig tausend sein dürften. Doch, deine Ausführung ist im Vergleich sogar besonders anfällig. Man kann sich beliebig viele funktionierende Sendungen abfangen und zurücklegen, solange der Empfänger diese nicht empfängt und damit nicht als gebraucht vermerken kann.
Jemand schrieb: > Karl K. schrieb: >> Nicht, wenn sich der Empfänger empfangene Codes merkt. Brauchbar nur für >> "geringe" Anzahl von Übertragungen, wobei gering bei einer Zufallszahl >> von 64bit schon einige zig tausend sein dürften. > > Doch, deine Ausführung ist im Vergleich sogar besonders anfällig. Man > kann sich beliebig viele funktionierende Sendungen abfangen und > zurücklegen, solange der Empfänger diese nicht empfängt und damit nicht > als gebraucht vermerken kann. Das ist ein sehr gutes Argument gegen diese Variante, ja. Dasselbe Argument gibt es übrigens auch gegen die Variante mit den Zählern, die Hops nach vorne erlauben ...
:
Bearbeitet durch User
Jemand schrieb: > Man > kann sich beliebig viele funktionierende Sendungen abfangen und > zurücklegen... Stimmt. Also doch Schrott.
Nicht wirklich. Bei UC mit Uhrenquarz mit Temperaturcompensation meistens durch wdt und 12 sec Zeitfenster wird ein (Unix time /12) Gültigkeit von 36 sec angenommen wenn derselbe Handsender innerhalb der letzten 9.1 Tage (16bit Überlauf) verwendet wurde, ansonsten wird 82Sec Zeitfenster (9x) gecheckt. Bei 3 Telegrammen die Gültig sind und unterschiedliche Zähler aufweisen und innerhalb 24sec ankommen wird zuerst 32 und dann 128 Zeiteinheiten (12sec) ausgewertet.. Dies wenn keine erfolgreiche Aktion in den vergangenen ca 9 Tagen war, ansonsten wird der Bereich nur auf +-7 Zeitfenster ausgeweitet. Die OSC deviation wird natürlich auch gespeichert und berücksichtigt.
Bei den VPN-Token von RSA ist die Rede von einem Seed der bei der Herstellung eingebrannt wird und dem VPN-Gateway bekannt gemacht und einem Nutzer zugeordnet werden muss. Das ist wahrscheinlich der Startwert für ein großes LFSR das jede Minute einmal weiter zählt und dessen Hash als sechsstellige Ziffer angezeigt wird. Dieser Hash ist dann Teil des Passworts beim Login. Das Gateway wird mit demselben Startwert dieselbe Folge an Hashwerten ausrechnen und unter Berücksichtigung von maximal erlaubten Taktunterschieden in der Liste nachschauen. Vermutlich wird dabei auch implizit die Uhr synchronisiert. Zusätzlich gibt es im internen Netzwerk eine Webinterface wo man ein Token synchronisieren kann. Dazu muss man drei aufeinanderfolgende Hashwerte eingeben. Die Lösung für den Batteriewechseln ist dort ganz simpel. Geht gar nicht da verklebt und zusätzlich eingebautes Verfallsdatum. An sich sinnvoll aber dass dieselbe Hardware mit 3, 4 oder 5 Jahren Laufzeit zu entsprechend steigenden Preisen zu verkaufen ist Geldmacherei. Für den Garagentoröffner müsste man noch eine Seriennummer o.Ä. zur Identifizierung mitsenden. Da der Code nicht händisch eingegeben werden muss kann und sollte der Hash schneller erneuert werden. Für privat würde man bestimmt die Batterie wechselbar machen aber muss dann auch jedes Mal den Key neu anlernen.
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.