RFM12 Protokoll

[Markus P. (neo_1990)]

Hallo Community,

versuche gerade theoretisch (also auf Papier) ein Netzwerkprotokoll für 
RFM12 Module zu entwerfen.

Dabei sollen mehrere Microcontroller, die verschiedene Aufgaben in der 
Wohnung übernehmen, miteinander kommunizieren.

Ansätze bisher:
IDLE: Unitname wird gesendet, alle anderen Units speichern den IDLE.

GIVE: Fordert Befehl an. (zb. Messwert vom Terrarium, oder Licht 
einschalten)
RSPNS: Antwort auf GIVE mit enthaltenem Messwert.
OK: Bestätigt den Empfang von RSPNS.

GIVE, RSPNS und OK-Nachrichten werden mit einer msgID miteinander 
Verknüpft.

Derzeit komme ich leider bei der Verschlüsselung nicht weiter:
Den Sendestring (z.b. GIVE:Unitname|temperatur|123) mit einem private 
Key zu verschlüsseln, und beim Empfänger wieder entschlüsseln sollte ja 
nicht so das Problem werden, jedoch bereitet mir die Abhörsicherheit 
noch Kopfzerbrechen:

Angenommen ein verschlüsselter IDLE-Befehl wird abgefangen, d.h. auch 
abgefangene GIVEs können gesendet werden. Auch wenn der Angreifer mit 
den enthaltenen Werten der RSPNS-Befehle nichts anfangen kann, könnte er 
- rein theoretisch - durch angefangene GIVEs recht viel anrichten.

Lösungsansatz1:
Sobald eine GIVE-RSPNS-OK Prozedur abgeschlossen ist, wird die msgID 
gespeichert und gesperrt. Nachteil: Wenn der Speicherplatz am MC aus 
ist, müssen die msgIDs gelöscht werden, womit die gesperrten Nachrichten 
wieder gültig werden -> LECK!

Lösungsansatz2:
Alle Units halten Datensätze an gültigen msgIDs parat. Für jede 
GIVE-RSPNS-OK Prozedur wird eine ID verwendet und danach gelöscht, 
ausserdem wird ein Befehl gesendet, um die verwendete msgID auch auf 
allen anderen Units zu löschen.
Wenn keine msgIDs mehr vorhanden sind, muss ein neuer Stack an IDs 
ausgehandelt werden -> kompliziert und fehleranfällig.

Vielleicht kann mir jemand weiterhelfen.
Vielen Dank,
Markus

[Sauger (Gast)]

Mahlzeit,

solange 007 nicht unter deinem Sofa wohnt vergesse Verschlüsselung, der 
Aufwand lohnt sich nicht. Die Reichweite der Module ist für einen 
Angriff zu gering. Konzentriere dich auf ein robustes Protokoll.

MfG

[Markus P. (neo_1990)]

Ich hab jetzt vor, jede GIVE-RSPNS-OK Routine mit Sendezeit und ID zu 
versehen. Nach OK oder Fehler wird die ID für x-Minuten gesperrt. Wenn 
jetzt ein Befehl abgefangen und nochmal eingefunkt wird, wird er nur 
angenommen, wenn die ID nicht gesperrt ist, und der Befehl in einem 
gewissen Zeitfenster (x-Minuten) erstellt wurde.

Ergo: Die msgIDs sind nur innerhalb der LifeTime einer GIVE-RSPNS-OK 
Routine relevant, da "tote" Nachrichten generell nicht angenommen 
werden. Tote IDs können verworfen werden (-> es müssen immer nur wenige 
bis gar keine IDs gespeichert werden)

Wenn jetzt aber Befehle im Klartext übertragen werden, können - 
theoretisch zumindest - können einfach eine beliebige "lebende" ID und 
der aktuelle Timestamp verwendet werden, und schon ist das System offen 
für alle Befehle.

Deshalb will ich alle Befehle durch einen XTEA-Algo laufen lassen, um 
die Authentizität der Befehle zu garantieren.

Vielen Dank!

[Kay M. (Firma: nix-firma) (k-martinen)]

Das interessiert mich auch. Magst du darüber weiter berichten wie dein 
Projekt fortschreitet?

[Markus P. (neo_1990)]

Hallo Kay,

Version 2 wurde hier (Beitrag "CMNCATE: Netzwerkprotokoll") 
diskutiert. Ein großes Problem war unter anderem die Kollisionsfreiheit, 
weshalb Version 2 auch scheiterte.
In Version 3 werde ich auf ein zentrales System bauen welches Tokens 
austeilt und so Frames von A nach B Routet.
Sobald's News gibt, werde ich mich hier wieder melden.

Viele Grüße,
Markus

[Moby (Gast)]

Version3 ist wohl auch gescheitert? Warum bloß alles so kompliziert? Ich 
hab mir die serielle Funkbrücke mit RFM12 aus der Projektesammlung 
geschnappt und nun fragt die Zentrale schlicht alle Aktoren/Sensoren 
reihum ab die darauf mit einer Rückmeldung reagieren. In den bekannten 
Pausen im Funkverkehr ist auch noch genug kollisionsfreier Platz für 
spontane Ereignismeldungen.