Forum: Mikrocontroller und Digitale Elektronik Rolling Code für NRF24 Funkstrecke


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.
von Michael (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich plane bei mir einige NRF24 Module einzusetzen, um Sensordaten von 
batteriebetriebenen Sensoren an die Basis zu senden (alle paar Minuten). 
Im Moment läuft dies komplett unverschlüsselt, was ich gerne ändern 
würde.

Dabei geht es mir gar nicht so sehr um die Verschlüsselung (der Nachbar 
darf gerne die Temperatur mitlesen können) als um die Sicherheit, dass 
die Nachricht wirklich von meinem Knoten kommt. (Glaube das nennt man 
dann Authentizität?!)

Ich würde dabei gerne eine reine Softwarelösung einsetzen (also keine 
HCS300 Keeloq Chips o.ä.).

Meine Frage wäre daher wieso nicht einfach folgende Möglichkeit 
vorstellbar wäre:

Ich verschlüssel 16 Bytes Daten mit AES128. Damit könnte kein Angreifer 
ein eigenes Telegramm verschicken... er könnte aber durchaus ein bereits 
gesendetes erneut senden. Wenn ich von den 16 Bytes nun 2 als 
Counterwert verwende, den ich bei jeder Übertragung erhöhe, könnte der 
Master nur Telegramme mit aktuellen Inkrement zulassen (bzw. noch einige 
zukünftige falls mal Übertragungen fehlschlagen) und daher wäre ein 
wiederholtes Senden durch einen Angreifer zwecklos.

Die reine Inkrementierung als Rolling-Code-"Algorithmus" ist natürlich 
extrem trivial, jedoch erfolgt diese ja vor der Verschlüsselung. Daher 
wäre die Frage, ob aus den verschlüsselten Daten von Inkrement 1 bis X 
(die man ja durchaus abgreifen könnte) Rückschlüsse möglich sind oder ob 
es andere Aspekte gibt, die gegen eine solche Lösung sprechen.

Die Lösung erscheint mir vom Bauchgefühl her zu einfach als dass sie 
sicher funktionieren könnte... aber mir fällt auch nichts ein, was 
dagegen sprechen würde.

Würde mich über ein kurzes Feedback freuen.

Grüße
Michael

von EinStudent (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn du eine Basisstation hast und eine Signatur ausreicht, würde 
vielleicht auch die Verwendung eines Nonce Sinn machen.

von Chris (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Beispiel eines Rolling code 66
DISC sind einfach die 10 MSB bits der serial number.
Damit wird geprüft ob die Entschlüsselung korrekt war.
OVR sind der Overflow des 16bit counter, ist also in Wirklichkeit ein
18 bit counter.

Hier gibt es folgende Keys:
SEED1(4), SEED2(4), SN(28), MFC(64)

SEED(8) ist ein zufälliger Wert, z.B. der Timer Wert wenn der
Benutzer das erste mal die Taste betätigt.

Beim Pairing werden einfach brute force alle 256 SEEDS durchprobiert und
das gefundene SEED abgespeichert, zusammen mit den anderen Daten.
Je TX braucht es 12 Bytes.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
Michael schrieb:
> und daher wäre ein
> wiederholtes Senden durch einen Angreifer zwecklos.

Allerdings musst du auch damit rechnen, das mal ein eigenes Telegramm 
nicht durchkommt. Ein stures Inkrementieren ohne Fallback ist also 
schlecht. Ab dem ersten nicht richtig empfangenen Telegramm wäre die 
Verbindung invalidiert.

von Michael (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Allerdings musst du auch damit rechnen, das mal ein eigenes Telegramm
> nicht durchkommt. Ein stures Inkrementieren ohne Fallback ist also
> schlecht. Ab dem ersten nicht richtig empfangenen Telegramm wäre die
> Verbindung invalidiert.

Das Problem haben ja glaube ich mehrere Algorithmen. Soweit ich weiß 
wird es dadurch gelöst, dass man nicht nur den nächsten Code akzeptiert, 
sondern die nächsten n Codes. Wird auch diese Grenze überschritten 
benötigt man zwei aufeinanderfolgende richtige Codes, was sich ja auch 
umsetzen lassen würde. Zudem habe ich ja beim NRF24 eine bidirektionale 
Übertragung mittels AKN, wodurch ich theoretisch auch noch einiges 
abfangen könnte.

Chris schrieb:
> Beispiel eines Rolling code 66

Wenn ich das richtig sehe ist das ziemlich genau das Keeloq Telegramm 
von Microchip. Abgesehen vom Disc Teil sind das ja einfach 4 bit Payload 
und 18bit Counter (so ähnlich sähe mein Telegramm ja auch aus). Dabei 
garantiert Microchip aber, dass der Wechsel nur eines Bits mindestens 
50% der Bits des verschlüsselten Telegramms verändert (Avalanche 
Effect)... meine Frage ist ja genau das... wenn ich die exakt gleiche 
Payload mittels AES verschlüssele (weil der Microchip Alogrithmus ja 
nicht bekannt ist).... werden dann auch bei einer Änderung um 1 bit 
(Inkrementierung) mindestens 50% der verschlüsselten Bits verändert? 
Laut Wikipedia ("Lawineneffekt") sollte das nahezu erfüllt sein...

Nur warum verwendet man dann nicht einfach AES? Warum baut man extra 
Chips ein, die mit nicht linearen Rolling Codes werben wenn AES das 
selbe erfüllt? (Mal abgesehen von den notw. Ressourcen für AES) Kann man 
vielleicht doch Rückschlüsse bei mehreren Inkrementierungen ableiten?

Vielleicht kann mich da ja einer aufklären. Finde es als Neuling in dem 
Thema schwer zu durchblicken.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
Die ganze Idee hinter den Rolling Codes ist, daß Du nur einen Sender und 
einen Empfänger brauchst und keine Transceiver auf beiden Seiten. Das 
ist in der Massenherstellung von Schlüsselsendern etc. billiger.

Du hast hier aber Transceiver. Das macht einiges einfacher und Du musst 
Dich nicht um die Probleme mit dem Verlust der Synchronisierung des 
Rolling Codes etc. kümmern.

Ich würde folgendes Vorschlagen:

Es gibt einen Pre-Shared-Key (PSK) zwischen Sensor und Zentrale. Also 
ein Geheimnis was beide Seiten kennen.

1. Der Sensor erzeugt ein Nonce, einen zufälligen Wert

2. Der Sensor nimmt das Nonce und verwendet einen kryptografisch 
sicheren, non-reversiblen Hash wie z.B. SHA2-256 um aus der 
Nachrichten-ID (hier Start-Anfrage), dem Nonce und dem PSK eine Signatur 
zu erzeugen

3. Der Sensor sendet eine Start-Anfrage zusammen mit seinem Nonce und 
der Signatur

4. Die Zentrale empfängt die Anfrage, prüft die Signatur und wenn ok, 
antwortet sie auch mit einem Nonce, der Nachrichten-ID Antwort und einer 
Signatur über die Daten, den PSK sowie das Nonce des Sensors.

5. Der Sensor empfängt die Antwort-Nachricht und prüft ob die Signatur 
stimmt und das Nonce verwendet wurde, was er vorher erzeugt hat

6. Der Sensor sendet die Nachrichten-ID Sensordaten, die eigentlichen 
Daten und eine Signatur, diesmal über die Nachrichten-Id, die Daten, den 
PSK und das Nonce der Zentrale

7. die Zentrale empfängt die Nachricht und prüft die Signatur sowie ob 
ihr vorher versendetes Nonce verwendet wurde

Durch die Verwendung der Nonces bekommst Du das Problem der 
Replay-Angriffe in den Griff. Da beide Seiten jeweils ein Nonce erzeugen 
und die Signatur der Gegenseite prüfen, ist das auch gegen 
Man-in-the-Middle-Angriffe geschützt.

von Michael (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Ich würde folgendes Vorschlagen

Das klingt nach einer guten Idee und ich brauche dafür nur Zufallszahlen 
und Sha. Das werde ich mal ausprobieren.

Vielen Dank für die Rückmeldungen.

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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