EnOcean Rolling Code PoC Implementierung

Begonnen von JanS, 11 Mai 2014, 19:44:38

Vorheriges Thema - Nächstes Thema

JanS

Naja nicht so ganz...
Jetzt wird $rlc_algo zweimal mt 1 verglichen und wenn "633EDF0A8E" der finale Private Key sein sollte, dann ist auch da was gehörig falsch gelaufen.
Die teach-in Routine sollte auch Part1-<SEND_ID> und Part2-<SEND_ID> liefern, wenn also die Logausgaben nicht umgebaut wurden, dann ist auch das falsch. Sollte nämlich zweimal die ID deines PTM215 dort stehen.
Was wird genau in $telegram übergeben?

klaus.schauer

Schade eigentlich! Die Ausgabewerte der Routine gehen inhaltlich unverändert ins LOG. Ich habe die Ausgabeformatierung nur an die sonst übliche Darstellung angepasst. Im LOG jetzt auch die an die Teach-In Routine übergebenen Daten:


2014.05.17 20:08:20 2: TCM set TCM_0 teach 600
2014.05.17 20:08:30 1: EnOcean Unknown device with ID FEFF91C3 and RORG STE, please define it.
2014.05.17 20:08:30 2: autocreate: define EnO_STE_FEFF91C3 EnOcean FEFF91C3 EnOcean:1:35:244BF432BA3770929C:FEFF91C3:00:01FFFFFFFF4F00
2014.05.17 20:08:30 2: EnOcean EnO_STE_FEFF91C3 sec_parseTeachIn Input RORG: 35 DATA: 244BF432BA3770929C
2014.05.17 20:08:30 2: EnOcean EnO_STE_FEFF91C3 teach-in EEP D2-03-00 Rocker A Manufacturer: no ID
2014.05.17 20:08:30 2: EnOcean EnO_STE_FEFF91C3 secure teach-in part1: BA377092
2014.05.17 20:08:30 2: autocreate: define FileLog_EnO_STE_FEFF91C3 FileLog ./log/EnO_STE_FEFF91C3-%Y.log EnO_STE_FEFF91C3
2014.05.17 20:08:31 2: EnOcean EnO_STE_FEFF91C3 sec_parseTeachIn Input RORG: 35 DATA: 40A4633EDF0A8E876793E764
2014.05.17 20:08:31 2: EnOcean EnO_STE_FEFF91C3 secure teach-in part2: 876793E7



Internals:
   CFGFN
   DEF        FEFF91C3
   IODev      TCM_0
   NAME       EnO_STE_FEFF91C3
   NOTIFYDEV  global
   NR         488
   STATE      ???
   TYPE       EnOcean
   Readings:
     2014-05-17 20:08:30   teach-in        EEP D2-03-00 Manufacturer: no ID
Attributes:
   IODev      TCM_0
   dataEnc    VAES
   key        633EDF0A8E
   macAlgo    3
   rlc        F432
   rlcAlgo    2,++
   rlcTX      false
   room       EnOcean
   subType    switch.00


Die Ausgaberoutinen für EEP D2-03-00 und EEP D2-03-10 (Fenstergriff) sind fertig. EEP D2-03-10 lässt sich dabei gleich mit abhandeln.

JanS

Wenn ich mir die Logs so anschaue, dann fehlt im Radio Telegram der komplette Rest nach dem Key, d.h. ID und Status; klar dass das dann in die Hose geht. ;-)
Das solltest du nicht abschneiden, da die Teach-in Routine das auswertet. Es ist zwar derzeit nicht kryptographisch relevant, aber wer weiss. Generell ist die Routine so designed, dass sie komplette Radio Telegramme verarbeitet.
Gibt es einen vernünftigen Grund, weswegen Du das Radio Telegram zurechtstutzt?
Ich habe nur begrenzt Zeit im Moment, den Code komplett doppelt schreiben ist momentan nicht drin.

klaus.schauer

Wer nach dem "kompletten Data Payload" fragt, bekommt von mir das DATA-Feld. Da haben wir wohl aneinander vorbei geschrieben. Zu dem Zeitpunkt, bei dem die Routine aufgerufen wird, sind bereits alle Teile des Telegramms fein säuberlich getrennt. Da macht es wenig Sinn, alles wieder einzupacken und nochmals alles auseinander zu nehmen. Sei es drum.. ich habe es im Programmaufruf wieder zusammengepackt. Ergebnis:


2014.05.17 21:31:27 2: TCM set TCM_0 teach 60
2014.05.17 21:31:37 1: EnOcean Unknown device with ID FEFF91C3 and RORG STE, please define it.
2014.05.17 21:31:37 2: autocreate: define EnO_STE_FEFF91C3 EnOcean FEFF91C3 EnOcean:1:35:244BF458BA3770929C:FEFF91C3:00:01FFFFFFFF4A00
2014.05.17 21:31:37 2: EnOcean EnO_STE_FEFF91C3 sec_parseTeachIn Input RORG: 35 DATA: 244BF458BA3770929C
2014.05.17 21:31:37 2: EnOcean EnO_STE_FEFF91C3 teach-in EEP D2-03-00 Rocker A Manufacturer: no ID
2014.05.17 21:31:37 2: EnOcean EnO_STE_FEFF91C3 secure teach-in part1: FEFF91C3
2014.05.17 21:31:37 2: autocreate: define FileLog_EnO_STE_FEFF91C3 FileLog ./log/EnO_STE_FEFF91C3-%Y.log EnO_STE_FEFF91C3
2014.05.17 21:31:38 2: EnOcean EnO_STE_FEFF91C3 sec_parseTeachIn Input RORG: 35 DATA: 40A4633EDF0A8E876793E764
2014.05.17 21:31:38 2: EnOcean EnO_STE_FEFF91C3 secure teach-in part2: FEFF91C3



Internals:
   CFGFN
   DEF        FEFF91C3
   IODev      TCM_0
   NAME       EnO_STE_FEFF91C3
   NOTIFYDEV  global
   NR         491
   STATE      ???
   TYPE       EnOcean
   Readings:
     2014-05-17 21:31:37   teach-in        EEP D2-03-00 Manufacturer: no ID
Attributes:
   IODev      TCM_0
   dataEnc    VAES
   key        BA3770929C633EDF0A8E876793E764
   macAlgo    3
   rlc        F458
   rlcAlgo    2,++
   rlcTX      false
   room       EnOcean
   subType    switch.00

JanS

Das sieht doch schon deutlich besser aus. Auf den ersten Blick und zu später Stunde würde ich sagen, das Teach-In passt nun. :-)
Mit Data Payload meinte ich all das, was in einem ESP3 Type 1 RADIO Packet als "Data "bezeichnet wird. Von welcher Spezifikation des Data Feldes bist Du ausgegangen? Würde gerne verstehen ob ich da einen Teil einer höheren Prorokollebene evtl. außer acht gelassen habe.


klaus.schauer

In der ESP3 Beschreibung Kapitel 1.7.1 wird Data Payload als reine Nutzdaten beschrieben (in der Routine ist das $data), also ohne Sender ID und Status. Nach meinem Verständnis der Kryptofunktionen wird auch nur Data Payload und RORG modifiziert. Das wird m. E. auch in Security of EnOcean Radio Networks, Kapitel 4.1 Security for operation mode so beschrieben:

The security mechanism may transform the DATA and R-ORG fields of the non secure message. Other fields like the message sender ID, receiver ID, repeater counter are not affected or altered. The RLC and CMAC may be added. Not modified fields like sender ID, received ID or repeater counter are not depicted through the chapter when a message is represented.

Deswegen war ich letztlich auch überrascht, weshalb die Sender ID in der Secure Teach-In Routine eine Rolle spielt. Ich habe das dann aber nicht weiter hinterfragt.

JanS

Die feinere Strukturierung in Kapitel 1.71. habe ich glatt übersehen und mich nur auf die "grobe" Aufteilung eines Typ 1 Packets gestützt. Das erklärt dann so einiges. THX fürs Augen öffnen. ;-)
Der Absatz im Enocean Security Dokument ist mir bewusst, jedoch habe ich die ID in meinem PoC Code halt verwendet um die Zuordnung zum Sender herzustellen.
Ich schreibe parallel ja an einer non-FHEM Implementierung, ich werde mal versuchen das entsprechend umzustrukturieren, da mir deine Heransgehensweise nun einleuchtender erscheint. Dann wird das Einbauen für dich auch leichter.

klaus.schauer

Hier nochmal eine kleine Überarbeitung der Teach-In Routine. Ich habe dort die Ausgabe der Manufacturer ID noch verbessert.

Die Ausgabe des switch.00 sollte jetzt auch ok sein. Hier die RAW-Ausgabe mit den Daten noch vor der Entschlüsselung, siehe STATE:


Internals:
   DEF        FEFF91C3
   IODev      TCM310_0
   LASTInputDev TCM310_0
   MSGCNT     28
   NAME       EnO_STE_FEFF91C3
   NOTIFYDEV  global
   NR         46
   STATE      RORG: D2 DATA: 0424A538 STATUS: 00 ODATA: 03FFFFFFFF4300
   TCM310_0_DestinationID FFFFFFFF
   TCM310_0_MSGCNT 28
   TCM310_0_PacketType 1
   TCM310_0_RSSI -67
   TCM310_0_ReceivingQuality excellent
   TCM310_0_RepeatingCounter 0
   TCM310_0_SubTelNum 3
   TCM310_0_TIME 2014-05-18 11:09:57
   TYPE       EnOcean
   Readings:
     2014-05-18 11:09:41   channelA        AI
     2014-05-18 11:09:41   channelB        B0
     2014-05-18 11:09:41   energyBow       pressed
     2014-05-18 11:09:57   state           RORG: D2 DATA: 0424A538 STATUS: 00 ODATA: 03FFFFFFFF4300
     2014-05-18 10:23:54   teach-in        EEP D2-03-00 Manufacturer: Multi user Manufacturer ID
Attributes:
   IODev      TCM310_0
   dataEnc    VAES
   key        BA3770929C633EDF0A8E876793E764
   macAlgo    3
   manufID    7FF
   rlc        F48E
   rlcAlgo    2,++
   rlcTX      false
   room       EnOcean
   subType    switch.00

JanS

#23
Ist "$attr" global oder wo kommt das her? Wie gesagt ich kenne nicht alle FHEM Interna und habe auch nicht die Zeit mich da komplett einzuarbeiten.
Wenn Du möchtest, dann schmeiß RORG und ID raus, solange ich weiss, mit welchem hash-key ich woher Daten lesen muss ist alles in Ordnung.
Der Fehler mit zweimal "($rlc_algo == 1)" war noch immer a Bord ;-)

Im Anhang mal auf die Schnelle ohne R-ORG,ID und Fehler. Du müsstest dafür R-ORG bei der Übergabe wieder entfallen lassen und die ID wieder abschneiden sonst gibt es Bruch.
In $telegram darf also nurnoch das stehen, was in ESP3 Kap 1.7.1. als "User Data" oder "Data Payload" bezeichnet wird.

EDIT: Dein private Key ist ein Byte zu kurz, was sich aber aus dem Code heraus nicht erklären lässt, es sei denn die doppelte Abfrage auf rcl_algo == 1 schlüge zu, was aber eigentlich nicht sein kann.

EDIT2: Gefunden, die Dekodierung der zweiten Message ging noch von R-ORG aus, Anhang gefixed.

klaus.schauer

Das scheint jetzt zu passen:


Internals:
   CFGFN
   DEF        FEFF91C3
   IODev      TCM_0
   NAME       EnO_STE_FEFF91C3
   NOTIFYDEV  global
   NR         498
   STATE      ???
   TYPE       EnOcean
   Readings:
     2014-05-18 14:04:58   teach-in        EEP D2-03-00 Manufacturer: Multi user Manufacturer ID
Attributes:
   IODev      TCM_0
   dataEnc    VAES
   key        BA3770929CA4633EDF0A8E876793E764
   macAlgo    3
   manufID    7FF
   rlc        F4C2
   rlcAlgo    2,++
   rlcTX      false
   room       EnOcean
   subType    switch.00



2014.05.18 14:04:46 2: TCM set TCM_0 teach 600
2014.05.18 14:04:57 1: EnOcean Unknown device with ID FEFF91C3 and RORG STE, please define it.
2014.05.18 14:04:57 2: autocreate: define EnO_STE_FEFF91C3 EnOcean FEFF91C3 EnOcean:1:35:244BF4C2BA3770929C:FEFF91C3:00:01FFFFFFFF4F00
2014.05.18 14:04:58 2: EnOcean EnO_STE_FEFF91C3 sec_parseTeachIn Input RORG: 35 DATA: 244BF4C2BA3770929C
2014.05.18 14:04:58 2: EnOcean EnO_STE_FEFF91C3 teach-in EEP D2-03-00 Rocker A Manufacturer: Multi user Manufacturer ID
2014.05.18 14:04:58 2: EnOcean EnO_STE_FEFF91C3 secure teach-in part1: EnO_STE_FEFF91C3
2014.05.18 14:04:58 2: autocreate: define FileLog_EnO_STE_FEFF91C3 FileLog ./log/EnO_STE_FEFF91C3-%Y.log EnO_STE_FEFF91C3
2014.05.18 14:04:58 2: EnOcean EnO_STE_FEFF91C3 sec_parseTeachIn Input RORG: 35 DATA: 40A4633EDF0A8E876793E764
2014.05.18 14:04:58 2: EnOcean EnO_STE_FEFF91C3 secure teach-in part2: EnO_STE_FEFF91C3


%hash, %attr sind global.

In %attr werden mit $attr{$name}{<Parameter>} üblicherweise Deviceparameter abgelegt, die in der Fhem Konfiguration mit

CommandSave(undef, undef)

gesichert und mit

AttrVal($name, "<Parametername>", <Defaultwert des Attributes, falls nicht gesetzt>)

ausgelesen werden. Werte, die zur Laufzeit anfallen, werden als Readings mit

readingsSingleUpdate($hash, "<Readingname>", <Readingwert>, 1)

abgelegt und mit

ReadingsVal($name, "<Readingname>", <Defaultwert des Readings, falls nicht gesetzt>)

ausgelesen. Falls man dem Readingnamen einen Punkt voranstellt, wird die Anzeige des Wertes im Userunterface standardmäßig unterdrückt. Die Readings werden auch gesichert (state-File).

JanS

Okay sieht gut aus bei Dir. :-)
Anbei mein Crypto Code angepasst an FHEM aber ungetestet, aber ich denke Du packst das. ;-)
Ich hoffe, ich hab das alles richtig verstanden mit %hash und %attr.
Es wird RORG 32 und das decodierte Datenbyte bzw. -nibble zurückgeliefert, das passende EEP implementierst Du, korrekt?

klaus.schauer

1. Die Routinen habe ich übernommen. Waren ein paar kleine Flüchtigkeitsfehler drin, z. B. fehlendes =, '.  In der beiliegenden Datei aber hoffentlich alles berichtigt.

2. Ergebnis:


Internals:
   DEF        FEFF91C3
   IODev      TCM310_0
   NAME       EnO_STE_FEFF91C3
   NOTIFYDEV  global
   NR         38
   STATE      ???
   TYPE       EnOcean
   CHANGED:
     teach-in: EEP D2-03-00 Manufacturer: Multi user Manufacturer ID
   Readings:
     2014-05-18 21:07:48   teach-in        EEP D2-03-00 Manufacturer: Multi user Manufacturer ID
Attributes:
   IODev      TCM310_0
   dataEnc    VAES
   key        BA3770929CA4633EDF0A8E876793E764
   macAlgo    3
   manufID    7FF
   rlc        F4D2
   rlcAlgo    2,++
   rlcTX      false
   room       EnOcean
   subType    switch.00



2014.05.18 21:07:38 2: TCM set TCM310_0 teach 600
2014.05.18 21:07:48 2: EnOcean EnO_STE_FEFF91C3 sec_parseTeachIn Input RORG: 35 DATA: 244BF4D2BA3770929C
2014.05.18 21:07:48 2: EnOcean EnO_STE_FEFF91C3 teach-in EEP D2-03-00 Rocker A Manufacturer: Multi user Manufacturer ID
2014.05.18 21:07:48 2: EnOcean EnO_STE_FEFF91C3 secure teach-in part1: EnO_STE_FEFF91C3
2014.05.18 21:07:48 2: EnOcean EnO_STE_FEFF91C3 sec_parseTeachIn Input RORG: 35 DATA: 40A4633EDF0A8E876793E764
2014.05.18 21:07:48 2: EnOcean EnO_STE_FEFF91C3 secure teach-in part2: EnO_STE_FEFF91C3

2014.05.18 21:07:59 2: EnOcean EnO_STE_FEFF91C3 secure data RORG: 30 DATA: 07AA2807 ID: FEFF91C3 STATUS: 00
2014.05.18 21:07:59 2: EnOcean EnO_STE_FEFF91C3 security ERROR: RORG 07AA2807 unsupported
2014.05.18 21:07:59 2: EnOcean EnO_STE_FEFF91C3 secure data RORG: 30 DATA: 0258794B ID: FEFF91C3 STATUS: 00
2014.05.18 21:07:59 2: EnOcean EnO_STE_FEFF91C3 security ERROR: RORG 0258794B unsupported

Die Routine liefert leider beim Empfang der Nutzdaten Fehlermeldungen zurück.

3. In den Routinen wird wahrscheinlich noch ein Parameter geschrieben, der nicht durch Fhem gesichert wird. Jedenfalls wird nach einem Fhem Neustart überhaupt keine Ausgangsmeldung mehr generiert. Sobald ich aber den Schalter erneut anlerne, kommen die Ausgaben wieder.

4. Ich habe auf einem Raspberry das Modul Crypt::Rijndael für die Kryptofunktionen nachinstalliert. Fhem ist auf den FRITZ!Boxen weit verbreitet. Ist dort das Modul schon vorhanden oder gibt es Alternativen?

JanS

ERROR: RORG 07AA2807 unsupported
Deutet darauf hin, dass in den Übergabeparametern der Routine die Nutzdaten und RORG vertauscht sind. Das sind nämlich die Nutzdaten '07AA2807' die da als RORG ausgegeben werden. ;-)

Zitat3. In den Routinen wird wahrscheinlich noch ein Parameter geschrieben, der nicht durch Fhem gesichert wird. Jedenfalls wird nach einem Fhem Neustart überhaupt keine Ausgangsmeldung mehr generiert. Sobald ich aber den Schalter erneut anlerne, kommen die Ausgaben wieder.
Gespeichert werden müssen alle Cryptoparameter, also all das was die Teach-In Routine in %attr ablegt.

Zitat4. Ich habe auf einem Raspberry das Modul Crypt::Rijndael für die Kryptofunktionen nachinstalliert. Fhem ist auf den FRITZ!Boxen weit verbreitet. Ist dort das Modul schon vorhanden oder gibt es Alternativen?
Rijndael ist das, was im "Volksmund" als AES bekannt ist. Leider ist search.cpan.org gerade down, aber ich meine es gäbe noch eine "pure Perl" Implementierung davon. Ohne geht es leider nicht, zumindest ist es nicht trivial eine komplett unabhängige AES Implementierung aus dem Boden zu stampfen.

klaus.schauer

Die Eingabe war tatsächlich vertauscht, aber nun leider


2014.05.18 22:28:56 2: TCM set TCM310_0 teach 600
2014.05.18 22:29:23 2: EnOcean EnO_STE_FEFF91C3 sec_parseTeachIn Input RORG: 35 DATA: 244BF4D6BA3770929C
2014.05.18 22:29:23 2: EnOcean EnO_STE_FEFF91C3 teach-in EEP D2-03-00 Rocker A Manufacturer: Multi user Manufacturer ID
2014.05.18 22:29:23 2: EnOcean EnO_STE_FEFF91C3 secure teach-in part1: EnO_STE_FEFF91C3
2014.05.18 22:29:24 2: EnOcean EnO_STE_FEFF91C3 sec_parseTeachIn Input RORG: 35 DATA: 40A4633EDF0A8E876793E764
2014.05.18 22:29:24 2: EnOcean EnO_STE_FEFF91C3 secure teach-in part2: EnO_STE_FEFF91C3
2014.05.18 22:29:40 2: EnOcean EnO_STE_FEFF91C3 secure data RORG: 30 DATA: 0A189266 ID: FEFF91C3 STATUS: 00
2014.05.18 22:29:40 2: EnOcean EnO_STE_FEFF91C3 security ERROR: Can't verify or decrypt telegram


Ich werde mal genauer in der Teach-In Routine suchen, ob dort tatsächlich noch eine Variable ist, die nicht in %attr abgelegt wird.

JanS

Nun besser als nichts ;-)
Soweit ich das überblickt habe, müsste alles in %attr landen was wichtig ist.
Die Aussage sagt im Prinzip, dass er innerhalb des Suchfensters von 128 Codes keine passende MAC gefunden hat. Kann viele Ursachen haben, möglicherweise ist ein falscher Rolling Code Stand gespeichert(sah gut aus in deinem Teach-in Output), oder ein falscher Key(sah auch gut aus), oder irgendwelche Parameter/Attribute/Werte gehen irgendwo flöten. Oder du hast Daten von einem alten Teach-in gespeichert und zwischenzeitlich einen weiteren Teach-In am PTM215 durchgeführt.
Mein Code beinhaltet nen ordentliche Menge auskommentierte Debug prints, die müsstest du jetzt wohl oder übel in FHEM integrieren.

Altetnativ kann ich das auch mal in FHEM durchtesten, das kann aber ne ganze Weile dauern, da ich im Moment weder ne originale Firmware auf dem EUL hab, noch eine laufende FHEM Installation.