[PATCH] AES fuer CUL/COC/... (culfw-Geraete)

Begonnen von mgernoth, 20 Juni 2015, 12:59:58

Vorheriges Thema - Nächstes Thema

mgernoth

Hallo,

dies ist die Fortsetzung meines Patches aus dem AES Reverseengineering-Thread.

Im Anhang findet sich ein Patch gegen 10_CUL_HM.pm, der es erlaubt, AES-geschuetzte Geraete zu schalten.
Sollten diese Geraete einen eigenen Schluessel benutzen (empfohlen), dann muss dieser in einer VCCU definiert (attr hmKey) und das culfw-Geraet dieser als IO zugewiesen sein.

Status:

  • Meiner Meinung nach fuer die Aufnahme in Fhem bereit :-)

Was funktioniert:

  • Schalten und konfigurieren eines Geraets mit Standardschluessel oder eigenem Schluessel
  • Uebertragung eines neuen Schluessels an ein Geraet (assignHmKey) (Im Augenblick landet der neue Schluessel im Klartext im Log, um ein Geraet bei evtl. Fehlern wiederbeleben zu koennen!)
  • Ueberpruefung der crypto-Response im ACK eines geschalteten Geraets

Was funktioniert nicht:

  • Anforderung einer Signatur eines Senders (aesCommReq), hier weiss ich nicht, wo ich im Code ansetzen muss. Das sollte spaeter aufbauend auf diesem Patch implementiert werden.

Voraussetzungen:

  • Das Perl-Modul Crypt::Rijndael muss installiert sein (Debian: libcrypt-rijndael-perl)

Ueber Rueckmeldung wuerde ich mich freuen, da ich das bisher nur in meinem Setup getestet habe.

EDIT: assignHmKey implementiert, doppeltes ACK behoben
EDIT2: Logging verbessert
EDIT3: Ueberpruefung der crypto-Response im ACK implementiert
EDIT4: Eigene Funktion zur Keyabfrage implementiert
EDIT5: Loglevel zum Grossteil auf 5 gestellt, assignHmKey landet noch mit Level 2 im Log. Dokumentation angepasst.
EDIT6: assignHmKey dokumentiert

Gruss
  Michael

Ralli

Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

mgernoth

#2
Hallo,

ich denke die aktuelle Version koennte in Fhem aufgenommen werden. Die noch fehlende Unterstuetzung fuer aesCommReq ist meiner Ansicht nach ein groesserer Aufwand, der spaeter auf dieser Implementierung aufbauen sollte.

Gruss
  Michael

Ralli

Eine Frage zum assignHmKey:

Muss der Key genau so mittels


set Device assignHmKey abcdefghijklmn...


gesetzt werden, wie der hmKey auch in der vCCU definiert ist?

Also wenn

attr vCCU hmKey 01:abcdefghijklmn...

dann

set Device assignHmKey abcdefghijklmn...

?
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

mgernoth

Hi,

Zitat von: Ralli am 21 Juni 2015, 11:44:56
Eine Frage zum assignHmKey:

Muss der Key genau so mittels


set Device assignHmKey abcdefghijklmn...


gesetzt werden, wie der hmKey auch in der vCCU definiert ist?

Nein, assignHmKey bekommt keinen Parameter, es uebertraegt immer den aktuellsten Schluessel aus der VCCU (hoechster Schluesselindex). Verhaelt sich beim CUL wie auch beim HMLAN gleich.

Also einfach:


set Device assignHmKey


Gruss
  Michael

Ralli

#5
Danke.

Ich habe bei drei Rollo-Aktoren die Besonderheit, dass nach einem Stromausfall die Konfiguration weg war. Nach dem Neu-Konfigurieren inkl. Aktivieren der Verschlüsselung bleibt die aesKeyNbr auf 00. Allerdings lassen sie sich mit dem einzig in der vCCU definierten Key 01:abc... steuern.

Musst Du / müsst Ihr diese "Besonderheit" im Code berücksichtigen? Wird ja sicherlich kein Einzelfall sein, wenn es bei mir schon bei drei Devices auftritt.

Ich habe gerade dann mal ein set Device assignHmKey durchgeführt - die aesKeyNbr bleibt bei diesen betroffenen Devices bei 00.

Edit: Und bei einem weiteren Batteriebetriebenen Device: muss sign auf jeden Fall on sein, damit der Keywechsel durchgeführt wird? Ich habe einen Drehgriffsensor, bei dem sign off und die aesKeyNbr 00 ist. Bei diesem hatte ich einen Werksreset durchgeführt und danach neu gepaired. Mit fhem neu angelernt, nicht mit Windowssoftware. Nun dann während sign off mal das set Drehgriff assignHmKey ausgeführt und danach ein getConfig - aesKeyNbr bleibt bei 00, keine Fehlermeldungen im Log. (vCCU mit 3 HMLAN und 2 HMUSB, momentan kein CUL eingebunden)
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

mgernoth

Hallo Ralli,

Zitat von: Ralli am 21 Juni 2015, 11:56:57
Ich habe bei drei Rollo-Aktoren die Besonderheit, dass nach einem Stromausfall die Konfiguration weg war. Nach dem Neu-Konfigurieren inkl. Aktivieren der Verschlüsselung bleibt die aesKeyNbr auf 00. Allerdings lassen sie sich mit dem einzig in der vCCU definierten Key 01:abc... steuern.

Loesche mal die Readings und fuehre eine Aktion durch, die signiert werden muss (also eine Bewegung des Rollos). Wenn danach wieder aesKeyNbr 00 auftaucht, dann werden die Aktoren mit dem Standardschluessel angesteuert, da auch der HMLAN aus diesem Feld den Schluessel bekommt, mit dem er die Nachricht signiert.

Zitat
Ich habe gerade dann mal ein set Device assignHmKey durchgeführt - die aesKeyNbr bleibt bei diesen betroffenen Devices bei 00.

aesKeyNbr wird nur aktualisiert, wenn eine Signatur durch das Geraet angefordert wird, da es nur dann den aktuellen Schluesselindex uebermittelt.

Zitat
Edit: Und bei einem weiteren Batteriebetriebenen Device: muss sign auf jeden Fall on sein, damit der Keywechsel durchgeführt wird?

Nein, der Schluessel wird schon uebertragen, aber aesKeyNbr wird nicht aktualisiert, da das Geraet keine Signatur anfordert.

Diskussionen zu assignHmKey am besten in diesem Thread: http://forum.fhem.de/index.php/topic,37787.0.html

Gruss
  Michael

Ralli

Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

mgernoth

#8
Hallo,

habe noch die Dokumentation zu assignHmKey hinzugefuegt (und die Wiki editiert)
@Martin: Haeltst Du den Patch fuer mergebar?

Viele Gruesse
  Michael

Ralli

Weil es gerade passt, dazu noch eine Frage:

Wenn bei einem Device mittels set sign on die AES-Signatur aktiviert wird, wird dann auch automatisch der aktuell höchste Schlüssel gepusht oder muss/soll das manuell noch geschehen? (Bei der Win-Software geschieht das m.W. automatisch).
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

mgernoth

Hi,

Zitat von: Ralli am 23 Juni 2015, 18:20:52
Wenn bei einem Device mittels set sign on die AES-Signatur aktiviert wird, wird dann auch automatisch der aktuell höchste Schlüssel gepusht oder muss/soll das manuell noch geschehen? (Bei der Win-Software geschieht das m.W. automatisch).

Automatisch wird nichts uebertragen, die Aktion muss immer manuell angestossen werden.

Viele Gruesse
  Michael

mgernoth

Hallo,

dank Martin ist die AES-Unterstuetzung fuer CUL und Konsorten jetzt in Fhem implementiert :-)

Viele Gruesse
  Michael