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