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

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

Michael, Respekt! Danke!

[mgernoth]

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

Code: [Auswählen]

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...

?

[mgernoth]

Hi,

Eine Frage zum assignHmKey:

Muss der Key genau so mittels

Code: [Auswählen]

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:

Code: [Auswählen]

set Device assignHmKey

Gruss
  Michael

[Ralli]

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)

[mgernoth]

Hallo Ralli,

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.

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.

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]

Danke, Michael - hat übrigens geklappt.

[mgernoth]

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).

[mgernoth]

Hi,

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