EnOcean Rolling Code PoC Implementierung

[JanS]

Hallo,

ich hätte eine EnOcean Rolling Code Implementierung in Perl abzugeben. Wohlgemerkt nur ein PoC der bei Tests entstanden ist. Bei Interesse bitte kurze Rückmeldung hier, da ich dazu sicher noch ein paar Erklärungen abgeben müsste (Stichwort eigene EUL Firmware mit HEX Output).


Grüße,
Jan

[klaus.schauer]

Die Ideen rund um die neuen Security Optionen würden mich sehr interessieren.

[JanS]

Gut, dann schau ich mal, dass ich evtl. den Code die Tage -zumindest ein wenig- salongfähiger mache, kann aber nicht zur viel versprechen, da ich dass in einem anders gelagerten Projekt noch in der Mache habe.

Voraussetzungen für Tests sind außer einem EnOcean Empfänger noch ein PTM215 oder kompatibles Modul, z.B. Eltako FMH4. Ich tue mir so spontan etwas schwer Einlerntelegramme von meinem PTM215 zur Verfügung zu stellen, da mit der Vertraulichkeit dieser das System steht und fällt.
Ich helfe auch gerne beim Integrieren in dein FHEM Modul mit, möchte mich aber aus Zeitmangel nicht zu tief in die Details der FHEM Schnittstellen oder Deines Moduls einarbeiten.

Vorschlag meinerseits: Besorg dir ein PTM215 und dann gehts los.
Der Code hat mich ca. 1,5 Tage gekostet mit Tests. Wenn du ein PTM215 verfügbar hast, dann schätze ich den Integrationsaufwand in Dein Modul auch so in der Größenordnung von 1-2 Tagen ein. Wichtigste Neuerung dürfte ein persistenter Speicherort für die Crpytoparameter (Sender ID, Rolling code counter, private Key und ein paar Parameter sein).

Grüße,
Jan

[klaus.schauer]

An dem Schalter scheitert es nicht. Der liegt hier rum. Dann bin ich ja mal gespannt.

[Zephyr]

Würde mich ebenfalls interessieren, da bei mir in den nächsten zwei Wochen etliches Equipment von EnOcean ankommt.
Ich will auf dieses System u.a. weil es eine Verschlüsselung bietet.

Viele Grüße
Zephyr

[JanS]

Ok
Bin dran es etwas aufzuhübschen und werde dann hier eine Funktion nach der anderen als Perl Source abliefern. Bin leider etwas landunter und will nicht einfach eine Ladung Code hier abkippen die keiner blickt Abgesehen davon hab ich ja auch ein bisschen Stolz

Generell schon mal eine Zusammenfassung für diejenigen die sich nicht das Whitepaper von EnOcean antun wollen.

Soweit imir bekannt gibt es an Rolling Code fähigen Sendern bislang nur das PTM215 Modul, welches z.B. in den Tastern von Eltako verbaut. Andere Module sind mir nicht bekannt, jedoch gibt die Spezifikation deutlich mehr her, als derzeit genutzt wird. Rolling Code fähige Fenster/Türkontakte habe ich sowohl bei Eltako also auch EnOcean einfach mal angefragt. Antwort war in etwa: "Mhja geplant, aber keine Ahnung wann."

So was geht also mit den PTM215 Modulen und was nicht? Die Module kommen standardmäßig im normalen Modus daher, d.h. EEP F6-02-01. Um den Rolling Code Modus zu aktivieren sind beide Taster einer Seite (A oder B) zu drücken und danach der "Energy Bow" zu drücken, loszulassen und nochmal zu drücken. Dadurch werden zwei Dinge bewirkt, 1.) wechselt das PTM215 dadurch in den Rolling Code Modus und EEP D2-03-00, 2.) werden zwei Secure Teach in Telegramme versendet, dazu gleich mehr. Ein Wechsel zurück in den "normalen" Modus ist jederzeit möglich; einafch alle 4 Taster drücken und den "Energy bow" betätigen. Man zerschiesst sich also nichts dauerhaft.

Die zwei Einlerntelegramme übetragen die nötigen Infos für die Verschlüsselung, aus Längengründen aufgeteilt in zwei Telegramme(es werden also beide benötigt!). Hier gibt es einen kleinen Haken...
Es werden, neben einer kleinen Menge Protokollinfos, zum einen der aktuelle Wert des Rolling Code Zählers übertragen (16bit beim PTM215), als auch der zur Verschlüsselung verwendete "Private Key"(128bit) wie in EnOcean nennt. Das bedeutet konkret, lauscht jemand in diesem Moment mit, dann hat er alle nötigen Infos um die Telegramme zu fälschen! Es sind Gegenmassnahmen in der Spezifikation vorgesehen, dazu werden der Zählerwert und der Schlüssel zusätzlich mit einem Preshared Key(PSK) verschlüsselt, welcher dem Empfänger bekannt sein muss. Dies kann beim Teach-In angezeigt werden, wie das allerdings funktioniert, ist mir nicht klar. Die Spezifikation sagt dazu nur, dass ein 16Byte langer Code plus CRC8 Checksumme auf dem Sender vermerkt werden könnte. Ich habe eine Anfrage an EnOcean gestellt, was es damit auf sich hat. Der PTM215 auf jeden Fall signalisiert "kein PSK", es geht also alles im Klartext durch die Luft.

Diese beiden Werte (Zähler und Schlüssel) sind auch die wichtigsten zu speichernden Informationen pro SenderID. Es gibt noch ein paar weitere Parameter, aber die sind kaum der Rede Wert. Der Zählerwert wird bei späteren Schalttelegrammen nicht mehr übertragen, es muss als empfängerseitig mitgezählt werden (und gespeichert!). Die Spezifikation sieht ein Fenster von 128 Zählerwerten vor, um bei verlorenen Telegrammen wieder aufsynchronisieren zu können. Um das Telegram prüfen zu können, wird ein 3 byte langer CMAC Wert übertragen, welcher kryptographisch erzeugt wird, hierfür wird wieder der "Private Key" des Senders, der Zählerwert und ein bisschen AES128 und XOR Bitschubserei gebraucht.

Ist die Nachricht, durch Verifikation des MAC, als echt und korrekt eingestuft worden, kann man sich an die Verschlüsselung machen, hierfür wird de "Private Key" ein EnOcean weiter "Public Key" und der, evtl. erst gesuchte, Zählerwert benötigt. Veschlüsselt werden beim PTM215 gigantische 4Bit(übertragen in einem Byte), welche mit viel Padding in eine VAES getaufte Verschlüsselung gesteckt werden. Die Interpretation dieser 4Bit findet sich in  EEP D2-03-00, zusammen mit Übersetzungstabellen nach EEP EEP F6-02-01.

Und das wars als Überblick, ich hoffe das gibt schon mal einen Überblick darüber was zu erwarten ist. Meine Programmiererehre zwingt mich nur, das noch mal in Ruhe durchzuschauen, nicht das sich fiese Fehler in den kryptographischen Funtionen eingeschlichen haben; die haben mich ganzschön Nerven gekostet, das will ich anderen ersparen.

Ich denke morgen Abend werfe ich die ersten Schnipsel, wenn nicht sogar schon alles, hier ab. Laufen tut es "anscheinend" seit Sonntag Mittag, bin permanent am Testen. Wenns gut läuft sind nur durch Klaus noch ein paar Anpassungen an Datenformaten zu erledigen.

[Zephyr]

Öhm... Dann besorge ich mal testweise einen PTM215.

[thghh]

Frage.

Was erhofft ihr euch durch die Verschlüsselung?

Das ist doch nur Marketing, weil der Wettbewerb bisher auf der fehlenden Verschlüsselung rumgeritten ist.

Ich wäre ja schon froh, wenn das Funksignal vom EG in den Keller gehen würde und selbst wenn jemand dieses auf der Strasse mitlesen sollte, um die ID zu missbrauchen was kann passieren? Licht ein- und ausschalten?

@ Zephyr

Wenn du deine Geräte bekommst achte auf die Produktionswoche. Nur darüber wird entschieden ob Verschlüsselung oder nicht besonders beim FAM14

[JanS]

Was erhofft ihr euch durch die Verschlüsselung?

Authorisierung und Authentifizierung, wie von jeder vernünftig umgesetzten Verschlüsselung.

Das ist doch nur Marketing, weil der Wettbewerb bisher auf der fehlten Verschlüsselung rumgeritten ist.

Die Umsetzung ist sehr ordentlich, deutlich besser als z.B. bei Homematic und deutlich über den Vorwurf eine Marketingnummer zu sein erhaben.

Ich wäre ja schon froh, wenn das Funksignal vom EG in den Keller gehen würde...

Bei mir reicht das Funksignal eines PTM215 vom 3.OG bis auf die Straße und hinters Haus, mit -91dBm in diesem Fall.
Empfänger ist ein Busware EUL mit 3dbi Antennenstummel, also nix wildes. Für schiwerige Fälle gibt es Repeater die sogar hierrarchisch strukturierbar sind.

...und selbst wenn jemand dieses auf der Strasse mitlesen sollte, um die ID zu missbrauchen was kann passieren? Licht ein- und ausschalten?

Ja, Licht, Heizung Aktoren für größere Verbraucher, die Rolläden etc.
Kannst gerne auch deine Haustüre offen stehen lassen, zwingt dich ja keiner zum Abschließen.

Wenn du deine Geräte bekommst achte auf die Produktionswoche. Nur darüber wird entschieden ob Verschlüsselung oder nicht besonders beim FAM14

Ja guter Hinweis, gilt aber nur für die Empfänger/Aktoren, das PTM215 kann es immer.

[JanS]

Ok, hier die gesäuberte teach-in Verarbeitung, mehr habe ich heute nicht geschafft...

Dieser Funktion muss die komplette Data Payload eines ESP3 RADIO Telegrams als HEX String übergeben werden.
Als Ergebnis wird ein Perl HASH mit Infos befüllt, welches dann von den eigentlichen Routinen zu Entschlüsselung verwendet wird.

@Klaus: Das kannst du schon komplett zum Testen von Teach-in Logik  und persistentem Store verwenden. Du solltest bei einem PTM215 danach einen 2Byte/4HEX-Chars langen Wert für den RLC bekommen und einen 16Byte/32 HEX-Chars langen Wert für den Key. RLC_ALGO muss als "2,++", MAC_ALGO als "3" und RLC_TX als "false" herauskommen.

[Zephyr]

Frage.

Was erhofft ihr euch durch die Verschlüsselung?

Frage.

Du hast bestimmt auch nichts zu verbergen?

Ansonsten aber vielen Dank für den Hinweis. Ich mache mich die Tage mal auf die Suche nach entsprechenden Heizungsaktoren. Aber hat jemand von euch einen Hinweis? Ach, vergesst es. Falscher Thread dafür.

Viele Grüße
Zephyr

[JanS]

Ok hier kommt der Rest (inkl. teach-in).

Das Gesamtkonstrukt unterstützt derzeit primär die PTM215 Module. Mehr ist machbar und an vielen Stellen im Code auch bereits vorgesehen, allerdings ist dafür entweder die Spezifikation noch etwas ungenau oder schlichtweg nichts zum Testen verfügbar.
Ich schätze da wird es in Zukunft also noch mehr geben.

So dann warte ich mal die Fragen ab, die sich bei der Implementierung evtl. ergeben. Sollte aber relativ straight-forward sein. Verbesserungsvorschläge, vor allem für die ganze Bitschubserei in generateMAC() & Co werden dankend angenommen.


Grüße,
Jan

[klaus.schauer]

Das Teach-In habe ich eingebaut... Perfekt!

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        FEFF91C3
   IODev      TCM_0
   NAME       EnO_STE_FEFF91C3
   NOTIFYDEV  global
   NR         508
   STATE      ???
   TYPE       EnOcean
Attributes:
   DATA_ENC   VAES
   IODev      TCM_0
   KEY        633EDF0A8E
   MAC_ALGO   3
   RLC        F426
   RLC_ALGO   3,++
   RLC_TX     false
   room       EnOcean
   subType    STE


Code Auswählen Erweitern


2014.05.15 06:36:59 2: TCM set TCM_0 teach 600
2014.05.15 06:37:08 1: EnOcean Unknown device with ID FEFF91C3 and RORG switch, please define it.
2014.05.15 06:37:08 2: autocreate: define EnO_switch_FEFF91C3 EnOcean FEFF91C3 EnOcean:1:F6:70:FEFF91C3:20:03FFFFFFFF3C00
2014.05.15 06:37:08 2: autocreate: define FileLog_EnO_switch_FEFF91C3 FileLog ./log/EnO_switch_FEFF91C3-%Y.log EnO_switch_FEFF91C3
2014.05.15 06:39:31 1: EnOcean Unknown device with ID FEFF91C3 and RORG STE, please define it.
2014.05.15 06:39:31 2: autocreate: define EnO_STE_FEFF91C3 EnOcean FEFF91C3 EnOcean:1:35:244BF426BA3770929C:FEFF91C3:00:01FFFFFFFF3900
2014.05.15 06:39:31 2: EnOcean EnO_STE_FEFF91C3 Secure Teach-In OK: Part1-BA377092
2014.05.15 06:39:31 2: autocreate: define FileLog_EnO_STE_FEFF91C3 FileLog ./log/EnO_STE_FEFF91C3-%Y.log EnO_STE_FEFF91C3
2014.05.15 06:39:31 2: EnOcean EnO_STE_FEFF91C3 Secure Teach-In OK: Part2-876793E7

   1. Integration des Teach-In Moduls
Folgende Änderungen habe ich zur Integration vorgenommen, geändertes Modul siehe Anlage:

   - Umbenennung des Moduls
   - Übergabeparameter jetzt $hash und $DATA
   - Rückgabewerte $err und $msg
   - Speicherung der Kryptoparameter als Attribute

Das Modul wurde in der Parse-Routine  integriert und wird nach Anlegen des Devices (autocreate) aufgerufen. Hierbei wird RORG = 35 >> subType = STE ausgewertet. RORG wird deshalb nicht mehr übergeben. Die Kryptoparameter werden jetzt im Fhem-Konfigurationsfile gesichert.

Code Auswählen Erweitern


if ($rorg eq "F6") {
... 
} elsif ($rorg eq "35" && $teach) {
     # Secure Teach-In
    ($err, $msg) = EnOcean_sec_parseTeachIn($hash, $data);
    if (defined $err) {
      Log3 $name, 2, "EnOcean $name Secure Teach-In ERROR: $err";
      return "";
    }
    Log3 $name, 2, "EnOcean $name Secure Teach-In OK: $msg";   
    CommandSave(undef, undef);
    return ""; 
}


Attribute werden i. d. R. nach der Art "subType" benannt. Es wäre schön, wenn die Namen der Kryptoparameter  gleich aufgebaut wären.

Zu Beginn des Teach-In wird dem Device per autocreate der subType = STE zugewiesen. Mit Abschluss des Teach-In Prozesses muss dann der "richtige" subType eingetragen sein. Hier müssen wir uns noch gemeinsam überlegen, wie wir es am besten machen. Ich habe mich noch nicht tief genug in das Krypto Teach-In eingearbeitet, um eine allgemeingültige Lösung - nicht nur für den subType = switch- parat zu haben. Z. B. könnte der EEP in der Form xx.yy.zz in einem zusätzlichen Rückgabewert $eep übergeben werden oder unmittelbar in der Teach-In Routine gesetzt werden, siehe  %EnO_subType.

In dem Internal $hash->{DEF} ist die SenderID des Devices  $hash->{NAME} gespeichert. In der  Teach-In Routine wird die SenderID auch extrahiert. Ich würde beide  Werte vergleichen und nur dann das Teach-In akzeptieren, falls beide Werte identisch sind. Ist sicher in kleines zusätzliches Sicherheitsmerkmal.

   2. Aufteilung in vier Routinen

Ich schlage vor, dass wir die gesamten Kryptoverfahren in vier Modulen kapseln. Das erleichtert die aufgabenteilige Betreuung. Ich gehe mal davon aus, dass Du die Kryptomodule dauerhaft betreuen und weiter ausbauen wirst!?

EnOcean_sec_convertToNonsecure
EnOcean_sec_convertToSecure
EnOcean_sec_createTeachIn
EnOcean_sec_parseTeachIn

Als nächstes stünde also EnOcean_sec_convertToNonsecure() an.

Ich würde für dieses Modul wieder die RORG = 30 und ggf. RORG = 31 auswerten. Übergeben wird

($err, $data, $rorg) = EnOcean_sec_convertToNonsecure($hash, $data, $rorg)

Rückgabewert $rorg = "32" ?

Siehe auch %EnO_rorgname:
...
"30" => "SEC",     # secure telegram
"31" => "ENC",     # secure telegram with encapsulation
"32" => "DEC",     # decrypted secure telegram
...

Bisher habe ich mich nur mit der Teach-In Routine befasst. Bitte gib mir eine Rückmeldung, wie wir weiter vorgehen. M. E. wäre es gut, wenn Du die Entschlüsselungsroutine entsprechend dem obigen Vorschlag anpassen würdest. Danach würde ich mich um die Integration kümmern.

[JanS]

Ok, hab ein paar Fehler wieder ausgebaut, die Abfrage auf rlc_algo == 2 war flöten gegangen und der Vergleich ob das zweite Telegram einem ersten gefolgt ist, verwendete einen anderen "KEY" ohne Punkt.
Generell funktioniert etwas in der Art "$attr{$name}{.RLC_ALGO} = '2,++';" nicht da kein Punkt im Key vorkommen darf. Da ich die genaue Nomenklatur für subTypes(?) in FHEM nicht kenne, schlag einfach etwas (funktionierendes) vor. Ich bin da leidenschaftslos.

Ich habe das R-ORG Feld wieder aufgenommen; Hintergund dazu ist, dass ich mir nicht sicher bin, ob wir es evtl. in Zukunft wieder brauchen werden. Daher wäre mein Vorschlag es einfach drinnen zu lassen.

Bezüglich der R-ORG Typen und EEPs.
Der R-ORG 0x30 ist nicht genau spezifiziert, soll bedeuten ein PTM215 schickt damit verschlüsselte Daten, welche nach EEP D2-03-00 zu interpretieren sind. Mir ist keine Möglichkeit bekannt wie man das näher unterscheiden können sollte, streng genommen müsste ich daraus einen R-ORG 0x32 machen, den Sinn dahinter sehe ich allerdings nicht. Es werden da auch nur 4bit daten übertragen beim PTM215 und keinerlei Identifizierungsmerkmale.
R-RORG 0x31 für Kapselung würde dechiffriert einen normalen R-ORG liefern, leider kann ich das aber wiederrum nicht testen.
Da wird sich in Zukunft evtl. etwas ändern, solange es aber keine Geräte die das unterstützen in freier Wildbahn gibt, macht es zu diesem Zeitpunkt keinen Sinn da viel zu implementieren.
Die Implementierung für den PTM215 seitens EnOcean wirkt ein wenig zurechtgeschustert, sobald mehr Geräte EnOcean Security unterstützen, wird bzw. muss sich da auch wieder was am Protokoll tun.

Ich hänge die reparierte Version des teach-ins an. Schau da bitte mal nach der Konvention für die Attributnamen im Hash, passe sie an und stell es wieder hier ein, dann baue ich die restlichen Routinen passend um.

Was die Pflege angeht, ich werde das pflegen, wenn es meine Zeit zulässt
Solange EnOcean nichts an der Spec ändert oder es mehr Geräte gibt, sehe ich das sehr entspannt.

[klaus.schauer]

Jetzt sollte es gehen. Die Teach-In Routine habe ich angepasst. Die Parameter $rorg $data werden getrennt übergeben. Dort wird jetzt auch für Switche ein EEP vergeben. Ergebnis des Teach-In:

Code Auswählen Erweitern


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


Code Auswählen Erweitern


2014.05.16 21:00:28 2: TCM set TCM_0 teach 600
2014.05.16 21:00:39 1: EnOcean Unknown device with ID FEFF91C3 and RORG STE, please define it.
2014.05.16 21:00:39 2: autocreate: define EnO_STE_FEFF91C3 EnOcean FEFF91C3 EnOcean:1:35:244BF42ABA3770929C:FEFF91C3:00:01FFFFFFFF5000
2014.05.16 21:00:39 2: EnOcean EnO_STE_FEFF91C3 teach-in EEP D2-03-00 Rocker A Manufacturer: no ID
2014.05.16 21:00:39 2: EnOcean EnO_STE_FEFF91C3 secure teach-in part1: BA377092
2014.05.16 21:00:39 2: autocreate: define FileLog_EnO_STE_FEFF91C3 FileLog ./log/EnO_STE_FEFF91C3-%Y.log EnO_STE_FEFF91C3
2014.05.16 21:00:39 2: EnOcean EnO_STE_FEFF91C3 secure teach-in part2: 876793E7


Das EEP D2-03-00 (subType switch.00) muss ich noch bauen. Ist aber nur Fleißarbeit.

Falls wir derzeit davon ausgehen, dass ein RORG 32 nur von einem RORG D2 benutzt wird, ist die Rekonstruktion problemlos. Deshalb fürs Erste folgender Aufruf der Dekodierungsroutine:

Code Auswählen Erweitern


...
  my $name = $hash->{NAME};
  my $teach = $defs{$name}{IODev}{Teach};
  my $teachOut;
 
  if ($rorg eq "30" || $rorg eq "31") {
    ($err, $rorg, $data) = EnOcean_sec_convertToNonsecure($hash, $rorg, $data);   
    if (defined $err) {
      Log3 $name, 2, "EnOcean $name security ERROR: $err";
      return "";
    }
    if ($rorg eq "32") {
    # reconstruct RORG
    $rorg = "D2";
    }
  }

  # extract data bytes $db[x] ... $db[0]
  my @db;
  my $dbCntr = 0;
  for (my $strCntr = length($data) / 2 - 1; $strCntr >= 0; $strCntr--) {
    $db[$dbCntr] = hex substr($data, $strCntr * 2, 2);
    $dbCntr++;
  } 
...

Bitte $rorg = "32" zurückgeben. Dann ist auch für später die Zuordnung eindeutig.

Ich hoffe, es gelingt mit diesmal die letzte Fassung der Routine beizupacken. Die wäre dann auch lauffähig gewesen.

[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:

Code Auswählen Erweitern


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


Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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


Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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]

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:

Code Auswählen Erweitern


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


Code Auswählen Erweitern


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

Code Auswählen Erweitern


CommandSave(undef, undef)

gesichert und mit

Code Auswählen Erweitern


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

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

Code Auswählen Erweitern


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

abgelegt und mit

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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


Code Auswählen Erweitern


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]

Code Auswählen Erweitern

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.

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.

Gespeichert werden müssen alle Cryptoparameter, also all das was die Teach-In Routine in %attr ablegt.

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?

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

Code Auswählen Erweitern


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.

[klaus.schauer]

Ich habe jetzt erst einmal einen doppelten Boden für rlc eingebaut. Der Wert wird nun als Attribut und Reading gespeichert und jeweils der größte Wert verwendet. Das Speichern der Attribute in der Konfigurationsdatei muss explizit angestoßen werden und kann deshalb nach einem Neustart veraltet sein. Durch die zweifache Speicherung sollte aber der jeweils aktuelle Wert auch einen (unvorhergesehenen) Fhem Neustart überstehen.

Ich habe den Schalter mehrfach in Fhem neu angelernt. Der Fehler beim Empfang der Datentelegramme tritt sofort nach dem Anlernen auf. Mir ist aufgefallen, dass rlc bei jedem empfangenen Telegramm um 0x102 hochgezählt wird! Ist das ok? In der Routine EnOcean_sec_getRLC($) wird doch immer nur um 1 erhöht.

Beim Anlernen kann es passieren, dass das zweite Telegramm bei schlechten Empfangsverhältnissen nicht ankommt. In diesen Fällen wäre m. E. gut, wenn eine Fehlermeldung wegen eines falschen Keys erzeugt würde.

Ich werde mir die Routinen mal in aller Ruhe ansehen, vielleicht fällt mir was auf.

[JanS]

Ich habe jetzt erst einmal einen doppelten Boden für rlc eingebaut. Der Wert wird nun als Attribut und Reading gespeichert und jeweils der größte Wert verwendet. Das Speichern der Attribute in der Konfigurationsdatei muss explizit angestoßen werden und kann deshalb nach einem Neustart veraltet sein. Durch die zweifache Speicherung sollte aber der jeweils aktuelle Wert auch einen (unvorhergesehenen) Fhem Neustart überstehen.

Ja das ist ein Muss, der RLC muss stets dem im Sender entsprechen.

Ich habe den Schalter mehrfach in Fhem neu angelernt. Der Fehler beim Empfang der Datentelegramme tritt sofort nach dem Anlernen auf. Mir ist aufgefallen, dass rlc bei jedem empfangenen Telegramm um 0x102 hochgezählt wird! Ist das ok? In der Routine EnOcean_sec_getRLC($) wird doch immer nur um 1 erhöht.

Das ist schräg, du liegst richtig, der Wert sollte nur um 1 erhöht werden, und zwar mit jedem empfangenen Telegram für diesen Schalter.
EDIT: Und bis zu +128 dezimal wenn der RLC gesucht wird, also die Counter auseinander gelaufen sind, aber 258 passt nicht so ganz ins Konzept. Er könnte am Ende bei +255 landen, wenn press und release nicht gematcht haben, dann speicherst du aber vermutlich einen falschen RLC von Anfang an.
Evtl macht das sprinttf im getRLC Ärger, das ist mir schon lange ein Dorn im Auge.
So ausm Bauch raus kannst du mal Zeile 272 durch

Code Auswählen Erweitern

readingsSingleUpdate($hash, "rlc", unpack('H4',pack('n', $new_rlc)), 0);
ersetzen und Zeile 281 durch

Code Auswählen Erweitern

readingsSingleUpdate($hash, "rlc", unpack('H6',pack('N', $new_rlc)), 0);
EDIT: Und 273, 282 analog dazu.
Macht bei mir komischerweise keinen Ärger, aber wer weiss.

Beim Anlernen kann es passieren, dass das zweite Telegramm bei schlechten Empfangsverhältnissen nicht ankommt. In diesen Fällen wäre m. E. gut, wenn eine Fehlermeldung wegen eines falschen Keys erzeugt würde.

Gute Idee, da der Key immer 16byte (32 HEX Zeichen) lang sein sollte, kann man da leicht einen Check einbauen.

[klaus.schauer]

Mit den "etwas angepassten" Änderungen hat sich am Ergebnis nichts geändert. Die Parameter von pack und unpack sollten so richtig sein, aber bitte zur Sicherheit prüfen.

Beim wiederholten Anlernen wird richtig hochgezählt: F53E ... F540. Nach einem Telegramm ist rlc aber wieder F642.

[JanS]

Beim wiederholten Anlernen wird richtig hochgezählt: F53E ... F540. Nach einem Telegramm ist rlc aber wieder F642.

Der RLC wird im ersten Teach-In Telegram übertragen, angenommen F53E.
Hochgezählt wird dann nach Empfang des ersten Nicht-Teach-In Telegrams, d.h. beim ersten normalen Tastendruck. Kann der MAC nicht verifiziert werden wird der RLC bis zu 128 Werte weitergezählt.
Da zwei Telegramme versendet werden (Drücken&Loslassen) also max 256.
Während dem Teach-In darf da nichts hochgezählt werden, du sollest den RLC auch im ersten Teach in Telegram sehen können, er startet mit dem dritten Byte.
Das sah in deinen Logs auch gut aus.

Ohne zusätzliche Debug Ausgaben ist das nicht zu finden, ich hing da auch ne Weile dran Ist sicher was ganz blödes...

EDIT: Zu 258 fällt mir ein 258=256+2, das wären zwei normale Aufrufe plus zwei nicht matchende Aufrufe, wird aufgrund irgendeines Fehler die Dekodierroutine mehrfach aufgerufen mit falschen Daten? Wie oft hast du den Taster betätigt, in Telegrammen gezählt?

[klaus.schauer]

Das LOG bildet eine komplette Tastenbetätigung ab. Bei einer Tastenbetätigung kommen ja immer zwei Telegramme z. B. BI und release.

Könntest Du mir die Stellen kennzeichnen, die geloggt werden sollen? Dann würde ich die entsprechenden Befehle einbauen.

[JanS]

Das LOG bildet eine komplette Tastenbetätigung ab. Bei einer Tastenbetätigung kommen ja immer zwei Telegramme z. B. BI und release.

Ich sehe derzeit einfach keine Möglichkeit wie zwei Telegramme eine Erhöhung des RLC um den Wert 258 bewirken können, 256 ja aber 258?
Das ist keine schrecklich komplizierte Sache und in der Regel liegt die Lösung auf der Hand, bin einigermaßen ratlos, wie sich dieses Verhalten erklären lassen sollte ohne dass EnOcean_sec_convertToNonsecure mindestens vier mal aufgerufen wird bzw. EnOcean_sec_convertToNonsecure eben 258 mal.
EDIT: Bin hinter die 258 gekommen, die routine zählt von 0 bis 128 nicht von 1, insofern passt das mit der Anzahl, bleibt die Frage warum kein passender MAC gefunden wird.

Könntest Du mir die Stellen kennzeichnen, die geloggt werden sollen? Dann würde ich die entsprechenden Befehle einbauen.

Ich brauche zum debuggen folgendes:
1.) Die rohen ESP3 Telgramme von Teach-In und Tastenbetätigung/release.
2.) Darauf folgend die Ausgabe der Nachricht und der MAC, da gibt es ein paar print Statements in der Routine EnOcean_sec_convertToNonsecure.

Code Auswählen Erweitern

#print "DATA: $data_enc\n";
#if ($expect_rlc == 1) { print "RLC: $rlc\n";};
#print "MAC: $mac\n";
3.) In EnOcean_sec_getRLC alle print Statements.
4.) In EnOcean_sec_generateMAC

Code Auswählen Erweitern

#print "Calculating MAC for data $data\n";
#print "CMAC ".unpack('H32', $cmac)."\n";


Das sollte fürs Erste reichen und auch gleich einigermaßen aufzeigen, was wie oft aufgerufen wird.

[klaus.schauer]

Die Ein- und Ausgabeparameter von EnOcean_sec_convertToNonsecure($$$) waren noch etwas strubbelig. Trotzdem ging es den Änderungen immer noch nicht, siehe LOG.

Warum wird MAC über $rorg.$data_enc.$rlc berechnet?

[JanS]

Ich vermisse im Log irgendwie den zweiten Teil des Teach-Ins, ist da was abhanden gekommen? Würde erklären warum nix geht

Ansonsten sieht das vom Rest her recht gut aus, kannst du bitte in Zeile 365 noch

Code Auswählen Erweitern

Log3 undef, 2, "EnOcean_sec_generateMAC cutted CMAC ".unpack('H32', $1);
einbauen?
RLC, Input für MAC ist alles i.O. Output des MAC Algorithmus checken wir noch.
Hmm evtl. noch in Zeile 300

Code Auswählen Erweitern

Log3 undef, 2, "EnOcean_sec_generateMAC private key ".unpack('H32', $private_key);
einbauen

Warum wird MAC über $rorg.$data_enc.$rlc berechnet?

Weil es in "Security of EnOcean Radio Networks" Kapitel 4.3.8.1 so steht.
Spaß beiseite, DATA und RLC macht noch Sinn, warum die Jungs den RORG drinne haben wollen ist mir auch nicht klar. Statische Daten erhöhen da jetzt nicht signifikant die Entropie des MACs.
Aber seis drum, wird laut Spec so gemacht und gut ist.

[klaus.schauer]

Das Teach-In ist bei dem gesendeten LOG tatsächlich nicht vollständig. Der Fehler trat aber auch bei einem vorherigen Test mit vollständigem Key auf. Dort fehlte aber noch eine LOG-Zeile. Ich mache nochmals einen Test mit den zusätzlichen LOG-Zeilen.

[JanS]

Ok, merkwürdig, wenn ich alle Telegramme sehe dann kann ich noch mehr sagen, aber eigentlich sieht das alles gut aus
EDIT: Die originalen Telegramme wären noch praktisch, wenn uns bald die Ideen ausgehen

[klaus.schauer]

So jetzt habe ich wieder alles zusammen. Habe auch noch eine Plausibilitätsabfrage für "key" eingebaut.

[JanS]

Ok, abgesehen davon dass ich die zweite Ausgabe der MAC vehunzt habe, was nicht weiter wild ist, sehe ich absolut nicht den Fehler.
Ich werde da Morgen noch mal in Ruhe drüber schauen, und es ggf. Abends einfach mal durch meinen Code laufen lassen.
Das ist gerade extrem mysteriös, ich habe das sogar mal auf nem PI getestet, d.h. Endian Fehler dürften es auch nicht sein.
Getestet habe ich auf nem 32bit x86 und nem PI, worauf hast Du das für diesen Log getestet?

[JanS]

Hat mir doch keine Ruhe gelassen, habs eben auf die Schnelle mal durch meinen Code gejagt....
Jetzt wirds allerdings schräg, ich kann es auch nicht dekodieren....
Von wann ist dein PTM215?
Wo gekauft?
Wo drin verbaut?

Entweder ist der buggy, oder er verwendet einen anderen Public Key?
Beides ist beunruhigend...

EDIT: Oder mein Mac Algo hat nen Fehler, ich guck morgen mal in Ruhe

[klaus.schauer]

Ich wars nicht. Der Taster ist aus einem EDK 350 Kit, den ich im August 2013 erhalten habe.

[JanS]

Wie gesagt bin vollkommen ratlos, der MAC Algorithmus kanns auch nicht sein, es sei denn die Spezifikation von EnOcean ist falsch. Die Operationen sind alle sauber, dein privtae Key erfodert im Gegensatz zu meinem das XORen mit cons_Rb gemäß Spec und das ist auch stimmig als 0x00..87. Da hat EnoCean nichts neues erfunden. XORen tue ich an vielen Stellen, das passt also auch...

Die naheliegendste Vermutung ist derzeit, dass dein PTM215 irgendwie anders tickt als meiner, evtl. ein "Vorserienmodell". Oder eben EnOcean verwendet einen andere const_Rb Wert als in der Spec angegeben.
Beides ist unmöglich herauszufinden, willkommen in der Welt der Kryptographie.
Einzige Idee aktuell, versuch einen neueren PTM215, meiner ist von diesem Monat und  in einem Eltako FMH4 zu Hause.

[klaus.schauer]

Ob der Taster defekt ist, kann ich natürlich schwer einschätzen. Dagegen spricht aber, dass der Taster sauber in der EnOcean DolphinView Advanced angelernt und die verschlüsselten Telegramme dekodiert werden. Dort wird auch automatisch das richtige EEP zugeordnet. Das hat mich auf die Idee mit der festen Anlernprozedur zu EEP D2-03-00 Manufacturer: Multi user Manufacturer ID gebracht.

Hier die Ergebnisse aus DolphinView Advanced

Internals:
   CFGFN
   DEF        FEFF91C3
   IODev      TCM310_0
   NAME       EnO_STE_FEFF91C3
   NOTIFYDEV  global
   NR         49
   STATE     
   TYPE       EnOcean
   Readings:
     2014-05-22 06:07:35   rlc             F566
     2014-05-22 06:07:35   teach-in        EEP D2-03-00 Manufacturer: Multi user Manufacturer ID
Attributes:
   IODev      TCM310_0
   dataEnc    VAES
   key        BA3770929CA4633EDF0A8E876793E764
   macAlgo    3
   manufID    7FF
   rlc        F566
   rlcAlgo    2,++
   rlcTX      false
   room       EnOcean
   subType    switch.00

Die Teach-In Daten aus Fhem und dem Analysetool passen m. E. zusammen. Die empfangenen Daten werden dort sauber dekodiert und der RLC hochgezählt.

[JanS]

Ja wenn Dolphin das sauber entschlüsseln kann, dann spricht das gegen ein Problem mit dem PTM215; jedoch spricht es für ein Problem mit der Spezifikation.
Der EnOcean public key ist beim MAC nicht beteiligt, das ist mir gestern Abend entfallen, also bleibt rein const_Rb oder etwas generelles. Den private Key konntest Du ja mit DolphinView bestätigen.
Die Bitschiebeoperationen scheinen auch nicht das Problem zu sein, sonst könnte ich ja nichts verifizieren oder entschlüsseln.

Da EnOcean mir auf technische Fragen nicht antwortet, können wir aus derzeitiger Sicht das Thema komplett beerdigen; was auch meine "Installation" betrifft.
Totaler Mist, aber besser es jetzt schon zu merken als später. Ich werd mir noch mal andere MAC Implementierungen angucken, ob mir was auffält aber ich habe bei dem Thema wenig Hoffnung.

EDIT: Wenn du Lust hast, kannst du mal meine MAC Implementierung mit http://www.ietf.org/rfc/rfc4493.txt vergleichen, dass ist das was EnOcean sogar in die Spec ge-copy&pasted hat.

[JanS]

Ich habe gerade den Subkey Teil des Algorithmus gegen die Testvektoren aus dem RFC verglichen: Passt, sprich L, K1 und K2 erstelle ich korrekt, auch in Bezug auf XOR mit const_Rb.
Ich checke nochmal Padding und sonstiges Gelump, allerdings ist das Key unabhängig, sprich es müsste zwangsweise auch bei mir schief gehen. AES(und jeder andere gescheite Algorithmus) hat die nette Eigenschaft, dass bei einem Bit Input Änderung gleich eine ganze Lawine von Output Änderungen entsteht.

[klaus.schauer]

Ich habe bei EnOcean nachgefragt und auf den Artikel im Forum verwiesen. Leider fällt es den Fachleuten dort schwer, mit den Informationen aus dem Forum, das Problem zu erkennen. Könntest Du Zitat "Kurz die Situation (welche Module mit SW Version) darstellen und wo das Problem liegt oder welche Fragen es gibt."

[JanS]

Ich implementiere gerade den vollständigen AES-CMAC Algorithmus neu und vergleiche jeden Schritt mit den Testvektoren aus dem RFC (http://www.ietf.org/rfc/rfc4493.txt).
Das ganze packe ich dann in deinen FHEM Code, bzw. teste es mit deinen Daten erneut.
Mein Bauchgefühl ist derzeit, das EnOcean die Subkeys K1 und K2 falsch bzw. nicht nach RFC4493 berechnet, was bei meinem private Key nicht zum tragen kommt, da für diesen keine XOR Operation mit const_rb (0x00000000000000000000000000000087) erforderlich ist.

Ich führe es ASAP hier genauer aus.

[JanS]

Gut dann mal los, meine Neuimplementierung von AES-CMAC  liefert exakt die gleichen Werte wie mein erster Wurf, und diese Implementierung ist nun gegen die Testvektoren im RFC geprüft und somit zu 100% korrekt.

Welche Module/Software ich benutze, was soll ich dazu sagen???

Ich werde es mal schrittweise hier auflisten, die Entwickler von EnOcean sollten damit eigentlich klarkommen; und auch kommentieren können was nicht korrekt ist.

Für das Teach-In kommen folgende ESP3 Telegramme von deinem PTM215:
55000F07012B35244BF564BA3770929CFEFF91C30001FFFFFFFF4C00B5
5500120701183540A4633EDF0A8E876793E764FEFF91C30001FFFFFFFF4A00B1
Folgende Infos extrahiere ich daraus:
1.) RLC 16bit lang, wird bei jedem Senden inkrementiert und ist 'F564'
2.) Der RLC wird nicht bei jedem Telegram übertragen
3.) Als Verschlüsselung kommt VAES zum Einsatz
4.) Der MAC ist 3Byte lang
5.) Der Private Key lautet "ba3770929ca4633edf0a8e876793e764"

L, K1 und K2 für AES-CMAC müssen für diesen private Key sein:

Code Auswählen Erweitern

L  ec82b91d8c3ffb0f4030d266e4080ea2
K1 d905723b187ff61e8061a4cdc8101dc3
K2 b20ae47630ffec3d00c3499b90203a0f


Das sollte von EnOcean mal zuallerrest verifiziert werden, sofern die Infos aus dem Teach-In korrekt sind.

Als Nachrichten von deinem PTM215 kommen:
1.) 55000A0701EB3000A9C8D7FEFF91C30003FFFFFFFF43001D
2.) 55000A0701EB300C05AA94FEFF91C30003FFFFFFFF430039
Ich extrahier daraus folgende Daten:
1.) RORG: 30 DATA: 00 CMAC: A9C8D7 ID: FEFF91C3
2.) RORG: 30 DATA: 0C CNAC: 05AA94 ID: FEFF91C3

Nun versuche ich also den AES-CMAC der ersten Nachricht zum Vergleich zu berechnen und komme auf folgende Ergebnisse:
AES-CMAC über die Daten "3000F564" als RORG+DATA+aktueller RLC (s.o.) mit private Key "ba3770929ca4633edf0a8e876793e764" ergibt "91bca6dfef406f2c10e497235ade13ca".
Der zu verwendendte Teil laut Spezifikation und Teach-in sind die ersten 3Bytes also "91BCA6" was nicht "A9C8D7" entspricht. Somit kann die Nachricht nicht validiert werden.

Da ich meine AES-CMAC Funktion nun schon zum zweiten Mal vollständig implementiert habe, gegen die Testvektoren aus dem RFC verglichen habe UND es mit meinem PTM215 funktioniert, komme ich zu folgendem Schluß:

EnOcean rechnet nicht mit const_Rb 0x00000000000000000000000000000087, welcher für meinen PTM215 Key nicht zum Tragen kommt da MSB von L und K1 0 sind.
ODER dein PTM215 macht etwas falsch. EDIT: Was wir ja vermutlich ausschließen können da DolphinView bei Dir kein Problem hat.

So, ich kann leider unmöglich noch mehr Informationen liefern, nur EnOcean kann noch etwas dazu sagen.
Evtl. kommt heute Nachmittag noch die versprochene FHEM Implementierung, ändert aber nichts am Ergebnis, beide Implementierungen kommen zum selben Ergebnis was den MAC angeht.

[JanS]

Ich hab den Fehler gefunden! Lag doch an meiner MAC Implementierung, war allerdings so fies, dass er sich bei den Testvektoren selbst rauscancelled. Ich hab bis jetzt nicht verstanden, warum...
Aber egal, füge mal bitte in secure_4.pl hinter Zeile 336 folgende Zeile ein und probiere es erneut:

Code Auswählen Erweitern

$k1_bit = unpack('B128', $k1);

EDIT: Für interessierte Mitleser, die Testvektoren des RFCs erzeugen einen Wert L mit nicht gesetztem MSB, dadurch lief mein Code nicht in den Zweig der K1 mit const_Rb XORed. Mein PTM215 nutzt einen private Key, der weder den Codepfad der XOR Operation von K1 noch K2 trifft. Beide Varianten erzeugten somit den einzigen relevanten Subkey K2 korrekt. Nur der private Key von Klaus PTM215 triggerte beide Codepfade und erzeugte somit in Konsequenz einen falschen K2.

Einen Dank an EnOcean, falls sich jemand die Mühe gemacht hat drüber zu schauen!

[klaus.schauer]

Ich bin froh, dass der Fehler wohl gefunden ist. Ich teste das heute Abend.

[JanS]

Bislang hat der Fix mit all deinen Logs die genügend Daten zum neu Testen enthielten geklappt, insofern kann man zuversichtlich sein.

[klaus.schauer]

Perfekt, super... hier der Beweis:

Code Auswählen Erweitern


Internals:
   DEF        FEFF91C3
   IODev      TCM310_0
   LASTInputDev TCM310_0
   MSGCNT     4
   NAME       EnO_STE_FEFF91C3
   NOTIFYDEV  global
   NR         40
   STATE      BI
   TCM310_0_DestinationID FFFFFFFF
   TCM310_0_MSGCNT 4
   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-22 20:33:42
   TYPE       EnOcean
   Readings:
     2014-05-22 20:23:27   channelA        A0
     2014-05-22 20:33:41   channelB        BI
     2014-05-22 20:33:42   energyBow       released
     2014-05-22 20:33:42   rlc             F5B4
     2014-05-22 20:33:41   state           BI
     2014-05-22 19:37:34   teach-in        EEP D2-03-00 Manufacturer: Multi user Manufacturer ID
Attributes:
   IODev      TCM310_0
   dataEnc    VAES
   key        BA3770929CA4633EDF0A8E876793E764
   macAlgo    3
   manufID    7FF
   rlc        F5B4
   rlcAlgo    2,++
   rlcTX      false
   room       EnOcean
   subType    switch.00


Herzlichen Dank für die Arbeit.

Ich habe noch kleinere Änderungen vorgenommen:

- Die LOGs stehen jetzt auf "debug" >> Bitte mal prüfen, was an LOGs und sonstigen print-Einträgen dauerhaft für eine Fehlersuche bei Supportanfragen drinbleiben soll.

- Die Ausgabeformatierung von EnOcean_sec_convertToNonsecure habe ich zurechtgebastelt. >> Bitte ggf. eine bessere Lösung wählen.

M. E. gibt es jetzt noch zwei Aufgaben:

- Umstellung oder Ablösung des Zusatzpaketes Crypt::Rijndael durch Routinen, die im -hoffentlich- Perl-Grundpaket enthalten sind. Wäre ganz wichtig, damit FHEM auf allen Plattformen insbesondere der FRITZ!Box sofort lauffähig ist.

- Kurze englische Beschreibung der neuen Kryptofunktionen und des Teach-In Verfahrens der PTM 215 für die commandref. Die Beschreibung der neuen Profile "switch.00" und "windowHandle.10" ist schon fertig.

Ich hoffe, dass ich dafür mit Deiner Unterstützung rechnen kann.

P. S. Ich habe rlc jetzt als verstecktes Reading eingerichtet.

[JanS]

Cool
Gut ich hab den Code noch mal überarbeitet und die MAC Generierung stärker modularisiert. Müsstest Du noch mal kurz checken, da ich das ausschließlich im Editor getan hab.
Ich habe die Debug Ausgaben auf das, im meinen Augen, notwendige Minimum zurechtgestutzt. Die Zukunft wird zeigen ob das reicht.

Die Ausgabeformatierung von EnOcean_sec_convertToNonsecure habe ich zurechtgebastelt. >> Bitte ggf. eine bessere Lösung wählen.

Was meinst Du damit? Ich verstehe die Frage nicht.

Umstellung oder Ablösung des Zusatzpaketes Crypt::Rijndael durch Routinen, die im -hoffentlich- Perl-Grundpaket enthalten sind. Wäre ganz wichtig, damit FHEM auf allen Plattformen insbesondere der FRITZ!Box sofort lauffähig ist.

Das ist ein größeres "Thema". Es gibt ein PP (Pure Perl) Modul namens Crypt::Rijndael_PP das ohne XS bzw. zu kompilierenden Code auskommt. Eine AES Implementierung, welche bei den üblichen Perl Distributionen mitgeliefert wird, gibt es meines Wissens nach nicht. Eine in das FHEM EnOcean Modul zu übernehmen ist "ein wenig" umfangreicher...

Kurze englische Beschreibung der neuen Kryptofunktionen und des Teach-In Verfahrens der PTM 215 für die commandref. Die Beschreibung der neuen Profile "switch.00" und "windowHandle.10" ist schon fertig.

Du meinst etwas in der Art:
--
This module also supports the secure operating mode of PTM215 based switches. To use this, you first have to start the teach in mode via "set TCM teach 600" and then doing the following on the PTM215 module:  1.) Remove the switch cover of the module 2.) Press both buttons of one rocker side (A0&A1 or B0&B1) 3.) While keeping the buttons pressed actuate the energy bow twice. This generates two teach-in telegrams which synchronize the TCM module with the PTM215. Both the FHEM Module and the PTM215 now maintain a counter which is used to generate a rolling code encryption scheme. Also during teach-in, a private key is transmitted to the TCM/FHEM. The counter value is allowed to desynchronize for a maximum of 128 counts, to allow compensating for missed telegrams, if this value is crossed you need to teach-in the PTM215 again. Also if your FHEM installation gets erased including the state information, you need to teach in the PTM215 modules again(which you would need to do anyway). As for the security of this solution, if someone manages to capture the teach-in telegrams, he can extract the private keay of the PTM215 module, so the added security isn't perfect but relies on the fact, that noone listens to you setting up your installation.
--

[klaus.schauer]

Danke für den Beschreibungstext. Ich werde ihn in die commandref einbauen.

Ich habe die geänderten Routinen übernommen. Leider sind diese nicht lauffähig. Bei einem angelernten Schalter ergibt sich wieder das gleiche Fehlerbild, wie vor der vorletzten Fassung:

Code Auswählen Erweitern


2014.05.26 19:10:51 2: EnOcean EnO_STE_FEFF91C3 security ERROR: Can't verify or decrypt telegram
2014.05.26 19:10:52 2: EnOcean EnO_STE_FEFF91C3 security ERROR: Can't verify or decrypt telegram


Neues Anlernen ist auch fehlerhaft:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        FEFF91C3
   IODev      TCM310_0
   NAME       EnO_SEC_FEFF91C3
   NOTIFYDEV  global
   NR         51
   STATE      ???
   TYPE       EnOcean
Attributes:
   IODev      TCM310_0
   rlcAlgo    2,++
   room       EnOcean
   subType    SEC


Code Auswählen Erweitern


2014.05.26 19:12:10 2: TCM set TCM310_0 teach 60
2014.05.26 19:12:16 1: EnOcean Unknown device with ID FEFF91C3 and RORG SEC, please define it.
2014.05.26 19:12:16 2: autocreate: define EnO_SEC_FEFF91C3 EnOcean FEFF91C3 EnOcean:1:30:0E284EDE:FEFF91C3:00:03FFFFFFFF3500
2014.05.26 19:12:16 2: EnOcean EnO_SEC_FEFF91C3 security ERROR: Secure mode messages without MAC unsupported
2014.05.26 19:12:16 2: autocreate: define FileLog_EnO_SEC_FEFF91C3 FileLog ./log/EnO_SEC_FEFF91C3-%Y.log EnO_SEC_FEFF91C3

Danach geht natürlich nichts mehr.

Code Auswählen Erweitern


2014.05.26 19:12:17 2: EnOcean EnO_SEC_FEFF91C3 security ERROR: Secure mode messages without MAC unsupported
2014.05.26 19:12:33 2: EnOcean EnO_SEC_FEFF91C3 security ERROR: Secure mode messages without MAC unsupported

Ich hatte leider in den letzten Tagen keine Zeit, mal einen vertieften Blick auf die Routinen zu werfen.

Die Ausgabeformatierung von EnOcean_sec_convertToNonsecure habe ich zurechtgebastelt.

Code Auswählen Erweitern


my $data_end = unpack('H32', $data_dec);
$data_end =~ /^.(.)/;

#print "MSG: $1\n";
return (undef, '32', "0" . uc($1));


Meine Formatierung "0" . uc($1) ist doch wohl eher eine Notlösung. Mir ist nicht klar, was in $data_end enthalten ist.

Wie machen wir mit den Perl Kryptomodulen weiter? Ich würde die neuen Funktionen gerne offiziell verteilen. Nur ohne eine einfache Lösung für Crypt::Rijndael macht das keinen Sinn.

Ich habe eben eine CPAN-Anleitung für die FRITZ!box 7390 gefunden... Falls ich mich entscheiden müsste, würde ich es nicht probieren. Das ist was für Perl-Insider. Für den "Normalnutzer" ist die Hürde zu hoch und das Fehlerrisiko einfach zu groß.

[JanS]

Wie gesagt, war nur ne schnelle Zusammenstellung aus meinen Tests um das Ganze zu modularisieren; funzt bei mir einwandfei. Evtl. sind ein paar Flüchtigkeitsfehler drinne, musst Du nicht zwangsweise so übernehmen, ist nur optional. Die Routinen sind mittlerweile sehr einfach und verständlich finde ich, dass mache ich jetzt mal von deinem Interesse abhängig, ob der modulare Code drinnen landet oder der "alte".

Was mich wundert, am Anlern-Code habe ich so bewusst garnichts geschraubt...

Meine Formatierung "0" . uc($1) ist doch wohl eher eine Notlösung. Mir ist nicht klar, was in $data_end enthalten ist.

Es wird lediglich ein Nibble(4Bit) übertragen, da kann also technisch 0..F drinnen stehen, laut EEP sogar noch weniger.

Wie machen wir mit den Perl Kryptomodulen weiter? Ich würde die neuen Funktionen gerne offiziell verteilen. Nur ohne eine einfache Lösung für Crypt::Rijndael macht das keinen Sinn.

Kryptografie ist nicht "einfach", wenn Du die Zeit hast AES/Rijndael in Perl neu zu implementieren, ich habe sie leider nicht. Und ein Freund von "ich packe alle Räder einfach neu erfunden in meinen Code" bin ich leider auch nicht.
Daher wäre mein Vorschlag ein anderer, wenn Crypt:Rijndael verfügbar ist, dann wird EnOcean Security unterstützt, sonst nicht.

Ich habe eben eine CPAN-Anleitung für die FRITZ!box 7390 gefunden... Falls ich mich entscheiden müsste, würde ich es nicht probieren. Das ist was für Perl-Insider. Für den "Normalnutzer" ist die Hürde zu hoch und das Fehlerrisiko einfach zu groß.

Für die FB würde es dann nicht unterstützt, auf einem normalen Rechner eben schon, evtl. mit den Paket Dependencies abgefrühstückt, da wird eh beim DEB paket was nachgezogen.