Announcement: there is an English version of this forum on 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
Wenn du eine Basisstation hast und eine Signatur ausreicht, würde vielleicht auch die Verwendung eines Nonce Sinn machen.
Angehängte Dateien:
-
RollingCode2_1_.jpg
29,5 KB, 146 Downloads
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.
Thread beobachten
Seitenaufteilung abschalten