Hallo Forum, ich benötige ein einfaches Funk-System mit einem Empfänger und einer oder mehreren Fernbedienungen. Die Fernbedienungen sollen bis zu 6 Tasten haben. Es soll im Prinzip nur übermittelt werden, welche Taste gedrückt ist. Mehrere Tasten gleichzeitig können erlaubt sein. Solange eine Taste gedrückt gehalten wird, soll periodisch eine entsprechende Nachricht übermittelt werden. Mit einem Timeout müsste der Empfänger bei Ausbleiben der Nachrichten in den Zustand "Taste nicht gedrückt" zurück fallen. Also gewünscht ist quasi ein Digitaleingang über eine Funkstrecke verlängert. Die Fernbedienungen sollen alle die gleichen Funktionen auslösen, ggf. ist eine Unterscheidung der Fernbedienungen aber trotzdem sinnvoll (An-/Ablernen bzw. Sperren oder Löschen). Die Fernbedienungen sind batteriebetrieben. Der Empfänger soll an einem Netzteilgespeisten System durch einen Mikrocontroller ausgewertet werden. Sind dafür die RFM69 Funkmodule geeignet? Es handelt sich nicht um eine hochkritische Anwendung, aber es soll trotzdem nur auf die angelernten Fernbedienungen reagiert werden und eine einfache replay Attacke soll möglichst auch verhindert werden. Würde dazu die integrierte AES Verschlüsselung der RFM69 Module ausreichen? Wie kann das Anlernen gelöst werden, da ein fester Key Verwendung findet? Im Prinzip wäre aber auch eine feste Programmierung je FB denkbar. Ich kenne mich mit AES nicht aus, führt es denn dazu, dass ein Funktelegramm immer anders aussieht, auch wenn ich z.B. immer wieder Taste 1 drücke? Oder müssen hier zusätzliche Maßnahmen zur AES Verschlüsselung getroffen werden? Über ein paar unterstützende Antworten würde ich mich freuen. Gruß Bernd
Wenn Du Bluetooth LE verwendest, findest Du eine ganze Reihe von µControllern, die das unterstützen. Ausserdem bekommst Du die Verschlüsselung umsonst oben drauf.
Das AES im RFM69 hat keinen Initialisierungsvektor. Meint. Wenn du 6 Bits hast, die du zyklisch sendest. xx010111 dann ergibt das verschlüsselt immer den gleichen Wert yyyAESyy Das ist nicht replay sicher. Du musst eigenhändig da etwas +mit+ verschlüsseln, was sich ändert. z.b. die Uhrzeit oder einen Zähler. Dann ändert sich der Wert in deinem AES verschlüsselten Frame jedes mal, auch wenn dein Payload gleich ist. Der Zähler darf dann nur in eine Richtung funktionieren. Kommt eine Nachricht mit einem kleineren Zähler oder einem zu großen... Replay erkannt. Der RFM69 kann das. Macht auch gleich das AES mit wenn du die Botschaft kurz hältst. Es gibt Arduino shields mit dem RFm69, damit umgehst du die ersten Probleme direkt und kannst los coden. Viel Erfolg
Hallo Bernd, das AES im RFM69 erzeugt aus einem leserlichen Text einen unleserlichen Text abhängig von den Werten, die in den 16 AES-Schlüsselregistern festgelegt sind, wobei ein gleicher Text bei gleichem Schlüssel immer den gleichen unleserlichen Text ergibt. Im Empfänger geschieht die genau umgekehrte Transformation. Die Textlänge ist immer auf 16er-Gruppen beschränkt, also 16, 32, 48 oder 64 Zeichen. Im Empfänger muß der gleiche Schlüssel eingestellt sein, wie im Sender, wobei man dem Empfänger einen neuen Schlüssel übermitteln könnte. Logische Kanäle lassen sich über sechs spezielle Bits realisieren, die im Datenpaket enthalten sind. Ein sinnvoll gestaltetes Datenpaket stellt der Programmierer zusammen. Somit kann das ganze Datenpaket entweder leserlich oder verschlüsselt übertragen werden. Die Zuordnung zu den Sendern würde ich fest im Programm verankern. MfG
Vielen Dank für die Antworten. Hatte ich mir fast gedacht, dass es so ist. Vielleicht ist ein unidirektionales Rolling Code Verfahren für 6 Tasten doch einfacher.
hier hatte ich mal so ein Projekt angefangen: Beitrag "RFM69 12-Kanal Fernbedienung" funktionierte, aber der 3D Druck kann noch verbessert werden. Im Moment ist mein Bastelreich noch in Kisten verpackt und ich kann da nicht dran weiterarbeiten. Bernd schrieb: > Solange > eine Taste gedrückt gehalten wird, soll periodisch eine entsprechende > Nachricht übermittelt werden. da gibt es noch den max Duty Cycle von 1 % bei 868 MHz, ein Dauersenden ist da nicht erlaubt.
Im Endeffekt willst du ja nur 2 Byte Senden. Das ist eine mini Payload. Security by Obscurity Vorschlag: Verschachteln von Bytes: Byte1:6 Bits zum Steuern von 6 Anlagen+2Random Bits Byte2: Zähler, (?umgekehrt polnische Notation) Wenn alle Türen auf sein sollen (1) und der Zähler nach dem Reset mit 0x00 startet: 11111100(1) 00000000(2) verschachteln 1010101010100000 damit die Übertragung n bissel abgesichert ist ein mal Redundanz dazu: 1010101010100000.0000010101010101 Wenn du das jetzt noch auf dem Modul AES verschlüsselst, ist das fertig. Da wären wir also bei 4 Bytes payload. 1 Byte Länge. Machen wir 5 Bytes Synchword und es sind 10. 10 Bytes sind bei 100kbs 1ms, für die Duty Cycle Rechnung. Der Zähler kann natürlich auch ein unsigned long sein statt einem Byte, bevor sich die Pfennigheimer wieder beschweren. Grüße
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.