mikrocontroller.net

Forum: PC-Programmierung AES Verschlüsselung, frage so Vorhersehbarkeit


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Christian (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 Moderator
Autor: Dussel (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Wunschlos Glücklicher (Gast)
Datum:

Bewertung
-10 lesenswert
nicht lesenswert
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.

Autor: Crypto-noob (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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?

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
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.

Autor: Walter T. (nicolas)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: test (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen W. (Firma: MED-EL GmbH) (wissenwasserj)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
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.

Autor: test (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Nosnibor (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Fitzebutze (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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).

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: test (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann die Uhrzeit ja neu synchronisieren bei jedem Öffnen.

Autor: Krypto-Schüler (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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ß.

Autor: test (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Dennis R. (dennis_r93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Hermann K. (r2d2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: test (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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 ;-)

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven B. (scummos)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: RAc (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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/

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: seere (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: RAc (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Sven B. (scummos)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: RAc (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 ...

Autor: RAc (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: chris (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: RAc (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Alex W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
;-)

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: RAc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo S. (urschmitt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
;-)

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Alex W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: RAc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Alex W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dussel (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: RAc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: B. Jacob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: RAc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: RAc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Brummbär (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: RAc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: RAc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Yammi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Yammi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS das mit dem Entschlüsselungsverfahren hatte nicht ich entwickelt, 
sondern das tauchte im Netz mal irgendwann als öffentliche 
Abschlussarbeit einer NRW-Hochschule auf.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Udo S. (urschmitt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Yammi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Verfahren sieht mir doch sehr stark nach KEELOQ aus ;)

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man braucht keine Verschlüsselung, ein guter hash reicht völlig aus.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Ruediger A. (Firma: keine) (rac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris R. (emigraen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
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

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Alex W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex W. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Karl K. schrieb:
> Sie braucht aber weder synchron laufende Uhren noch einen
> inkrementierenden Zähler.

Ok, bau es so! Hast Recht!

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Sie braucht aber weder synchron laufende Uhren noch einen
> inkrementierenden Zähler.

Dafür dann halt Speicher. Das ist nicht besser.

Autor: Jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jemand schrieb:
> Man
> kann sich beliebig viele funktionierende Sendungen abfangen und
> zurücklegen...

Stimmt. Also doch Schrott.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.