FHEM Forum

FHEM - Hausautomations-Systeme => Homematic => Thema gestartet von: mycroft2k am 13 Oktober 2014, 18:33:17

Titel: Vorsicht AES Trügerische Sicherheit mit vccu
Beitrag von: mycroft2k am 13 Oktober 2014, 18:33:17
RC4_Handsender2_Btn01 gepairt mit ccu_Btn3

Auswertung
define RC4_Handsender2_B1 notify ccu_Btn3:trig_aes_RC4_Handsender2_Btn01:.ok.* set Tor1 on

Fernbedinung RC4 Normal Senden AES OK (Event Monitor)
Zitat
2014-10-13 16:51:51 CUL_HM RC4_Handsender2 battery: ok
2014-10-13 16:51:51 CUL_HM RC4_Handsender2 RC4_Handsender2_Btn01 Short (to ccu)
2014-10-13 16:51:51 CUL_HM RC4_Handsender2 CMDs_done
2014-10-13 16:51:51 CUL_HM RC4_Handsender2_Btn01 Short (to ccu)
2014-10-13 16:51:51 CUL_HM RC4_Handsender2_Btn01 trigger: Short_21
2014-10-13 16:51:51 EIB Tor1 on
2014-10-13 16:51:51 CUL_HM ccu_Btn3 trig_aes_RC4_Handsender2_Btn01: ok:1A
2014-10-13 16:51:51 CUL_HM ccu_Btn3 trig_RC4_Handsender2_Btn01: short
2014-10-13 16:51:51 CUL_HM ccu_Btn3 trigLast: RC4_Handsender2_Btn01 :short
2014-10-13 16:51:51 CUL_HM RC4_Handsender2 aesCommToDev: ok

Mitgeschnittene Pakete per Funk Senden 1 Versuch AES fail Befehl wird ausgeführt
Zitat
2014-10-13 16:52:55 CUL_HM RC4_Handsender2 battery: ok
2014-10-13 16:52:55 CUL_HM RC4_Handsender2 RC4_Handsender2_Btn01 Short (to ccu)
2014-10-13 16:52:55 CUL_HM RC4_Handsender2 CMDs_done
2014-10-13 16:52:55 CUL_HM RC4_Handsender2_Btn01 Short (to ccu)
2014-10-13 16:52:55 CUL_HM RC4_Handsender2_Btn01 trigger: Short_26
2014-10-13 16:52:55 EIB Tor1 on
2014-10-13 16:52:55 CUL_HM ccu_Btn3 trig_aes_RC4_Handsender2_Btn01: ok:1B
2014-10-13 16:52:55 CUL_HM ccu_Btn3 trig_RC4_Handsender2_Btn01: short
2014-10-13 16:52:55 CUL_HM ccu_Btn3 trigLast: RC4_Handsender2_Btn01 :short
2014-10-13 16:52:55 CUL_HM RC4_Handsender2 aesCommToDev: fail

Mitgeschnittene Pakete per Funk Senden 2 Versuch AES fail Befehl wird nicht ausgeführt
Zitat
2014-10-13 16:54:09 CUL_HM RC4_Handsender2 battery: ok
2014-10-13 16:54:09 CUL_HM RC4_Handsender2 RC4_Handsender2_Btn01 Short (to ccu)
2014-10-13 16:54:09 CUL_HM RC4_Handsender2 CMDs_done
2014-10-13 16:54:09 CUL_HM RC4_Handsender2_Btn01 Short (to ccu)
2014-10-13 16:54:09 CUL_HM RC4_Handsender2_Btn01 trigger: Short_27
2014-10-13 16:54:09 CUL_HM ccu_Btn3 trig_aes_RC4_Handsender2_Btn01: fail:1C
2014-10-13 16:54:09 CUL_HM ccu_Btn3 trig_RC4_Handsender2_Btn01: short
2014-10-13 16:54:09 CUL_HM ccu_Btn3 trigLast: RC4_Handsender2_Btn01 :short
2014-10-13 16:54:09 CUL_HM RC4_Handsender2 aesCommToDev: fail

Hab das ganze auch bei einen Kollegen probiert der war ganz überrascht das ich sein Tor auf machen kann
geht zwar nur einmal aber das reicht ja um rein zukommen.

Wenn man dann auf der FB drückt wird der erste Befehl nicht angenommen erst beim zweiten mal wird
die Aktion dann ausgeführt.
so wie das ganze aussieht wird immer der letzte trig_aes ausgewertet der ja noch OK war!

Hab bei mir jetzt das mal vorübergehend drinnen stehen da konnte ich mit meinen mitgeschnitten Pakete den Befehl nicht mehr ausführen
Zitatdefine RC4_Handsender2_B1 notify ccu_Btn3:trig_RC4_Handsender2_Btn01:.short.* sleep 0.4;; {if (ReadingsVal("$NAME","trig_aes_RC4_Handsender2_Btn01","") =~ m/ok/){fhem "set Tor1 on"}}
Titel: Antw:Vorsicht AES Trügerische Sicherheit mit vccu
Beitrag von: martinp876 am 14 Oktober 2014, 21:45:10
Kannst du einmal rohmessages mitschneiden
Titel: Antw:Vorsicht AES Trügerische Sicherheit mit vccu
Beitrag von: mycroft2k am 15 Oktober 2014, 06:27:45
hätte das eingetragen aber in der logfile sehe ich keine Einträge
attr global verbose 1
attr global mseclog 1
attr HMLAN1 logIDs all,sys

hat man zwei HMLANs

Gibt man beiden HMLANs die gleiche hmId  aber unterschiedliche hmKey da der ccu den besten RSSI (HMLAN1) nimmt kann man den Fehler auch nachstellen
der mit den besten RSSI (HMLAN1) hat den richtigen hmkey (HMLAN1) der andere den falschen hmkey (HMLAN2) steckt man dann den HMLAN1 mit dem richtigen
hmkey(HMLAN1) aus wird einmalig der Befehl mit dem falschen HMLAN2 hmkey(HMLAN2) ausgeführt da AES erst später geprüft wird (meine Vermutung).

wie gesagt der Befehl wird nur einmal ausgeführt, steckt man HMLAN1 wieder an wird erst beim zweiten mal drücken der Befehl ausgeführt.
'CUL_HM ccu_Btn3 trig_aes_RC4_Handsender2_Btn01: fail:1C' der fail Eintrag ist aber noch vom falschen key
aber CUL_HM RC4_Handsender2 aesCommToDev: ok erst da ist nach meine Meinung AES überprüft.

ich glaub der entscheidender Punkt ist das 'CUL_HM RC4_Handsender2 aesCommToDev: ok' kommt erst dann war AES richtig.
aber die notify hat den alten Eintrag mit 'CUL_HM ccu_Btn3 trig_aes_RC4_Handsender2_Btn01: ok:1B' ausgewertet die ja noch richtig war wie HMLAN1 aktiv war
sieht man hier
Mit HMLAN2 (hmkey falsch)
Zitat
2014-10-15 05:52:55 CUL_HM RC4_Handsender2 battery: ok
2014-10-15 05:52:55 CUL_HM RC4_Handsender2 RC4_Handsender2_Btn01 Short (to ccu)
2014-10-15 05:52:55 CUL_HM RC4_Handsender2 CMDs_done
2014-10-15 05:52:55 CUL_HM RC4_Handsender2_Btn01 Short (to ccu)
2014-10-15 05:52:55 CUL_HM RC4_Handsender2_Btn01 trigger: Short_98
2014-10-15 05:52:55 EIB Tor1 on (hier wird der Befehl schon ausgeführt ob wohl die AES noch nicht geprüft ist)
2014-10-15 05:52:55 CUL_HM ccu_Btn3 trig_aes_RC4_Handsender2_Btn01: ok:1B (hier steht OK kann aber normal nicht sein da falscher KEY sieht man unter ccu_Btn3 nach steht hier fail:1C)
2014-10-15 05:52:55 CUL_HM ccu_Btn3 trig_RC4_Handsender2_Btn01: short
2014-10-15 05:52:55 CUL_HM ccu_Btn3 trigLast: RC4_Handsender2_Btn01 :short
2014-10-15 05:52:55 CUL_HM RC4_Handsender2 aesCommToDev: fail (hier steht fail das ist richtig da falscher hmkey (HMLAN2) und erst jetzt steht im ccu_Btn3 fail:1C)


mit der Auswertung jetzt warte ich ja 400ms und prüfe dann ob AES ok ist
define RC4_Handsender2_B1 notify ccu_Btn3:trig_RC4_Handsender2_Btn01:.short.* sleep 0.4;; {if (ReadingsVal("$NAME","trig_aes_RC4_Handsender2_Btn01","") =~ m/ok/){fhem "set Tor1 on"}}

Zitat
2014-10-15 06:16:23 CUL_HM RC4_Handsender2 RC4_Handsender2_Btn01 Short (to ccu)
2014-10-15 06:16:23 CUL_HM RC4_Handsender2 CMDs_done
2014-10-15 06:16:23 CUL_HM RC4_Handsender2_Btn01 Short (to ccu)
2014-10-15 06:16:23 CUL_HM RC4_Handsender2_Btn01 trigger: Short_115
2014-10-15 06:16:23 CUL_HM ccu_Btn3 trig_aes_RC4_Handsender2_Btn01: ok:21 (das ist ein alter Eintrag sieht man im ccu_Btn3 nach steht dort schon 22)
2014-10-15 06:16:23 CUL_HM ccu_Btn3 trig_RC4_Handsender2_Btn01: short
2014-10-15 06:16:23 CUL_HM ccu_Btn3 trigLast: RC4_Handsender2_Btn01 :short
2014-10-15 06:16:23 CUL_HM RC4_Handsender2 aesCommToDev: ok (hier wurde AES geprüft ccu_Btn3 hat jetzt den Eintrag ok:22)
2014-10-15 06:11:50 EIB Tor1 on
Titel: Antw:Vorsicht AES Trügerische Sicherheit mit vccu
Beitrag von: martinp876 am 18 Oktober 2014, 12:13:50
Zitathätte das eingetragen aber in der logfile sehe ich keine Einträge
du musst allen HMLAN das attribut setzen. die Logs kommen dann bei allen - sollte auch bei dir so sein.

Zitathat man zwei HMLANs
Gibt man beiden HMLANs die gleiche hmId  aber unterschiedliche hmKey
was soll das für einen sinn ergeben?

Zitatda der ccu den besten RSSI (HMLAN1) nimmt
korrekt - warum unterschiedliche keys?

Das gibt natürlich Probleme. Unabhängig, wer den besseren RSSI hat - die HMLAN reporten unterschiedlich schnell an die Zentrale. Das AES-"Ergebnis" ist natürlich unterschiedlich. Das Device sollte nur bei einem HMLAN "aktiviert" werden. schicke die Logs, dann werde ich es sehen. Ruhig etwas länger!
Auch wie du HMLAN zuweist - vccu? prefered?


Titel: Antw:Vorsicht AES Trügerische Sicherheit mit vccu
Beitrag von: mycroft2k am 18 Oktober 2014, 21:30:38
Zitathat man zwei HMLANs
    Gibt man beiden HMLANs die gleiche hmId  aber unterschiedliche hmKey

was soll das für einen sinn ergeben?
damit kann man den Fehler einfacher nachstellen / jeder kann so den Fehler einfach nachvollziehen.

Zitatda der ccu den besten RSSI (HMLAN1) nimmt
korrekt - warum unterschiedliche keys?
nur so sieht man das die AES Auswertung einen Fehler hat da falscher Key keine Berechtigung haben kann aber mit der normalen
Auswertung doch ausgeführt wird (nur einmal dann nicht mehr). Mir ist das eben durch Zufall aufgefallen wie ich mit den einen gerät die Funkdaten mitgeschnitten hab und dann gesendet hab das eben AES nicht richtig ausgewertet wird.

ansonsten hat natürlich HMLAN1/HMLAN2 den gleichen key.

vielleicht sollten wir mal telefonieren/skypen glaub da kann ich dir das besser erklären
Titel: Antw:Vorsicht AES Trügerische Sicherheit mit vccu
Beitrag von: martinp876 am 19 Oktober 2014, 15:26:39
wir können uns schon einmal unterhalten.
Besser ist aber, wenn du mir die Logs schickst (rohmessages). Dann kann ich mir dies im voraus einmal ansehen und auswerten.

wenn du zu den Rohmessages die Logs zu den betroffenen Devices einschaltest sollte alles dabei sein, was ich sehen will.

Titel: Antw:Vorsicht AES Trügerische Sicherheit mit vccu
Beitrag von: mycroft2k am 02 November 2014, 19:10:02
hab dir eine PN gesendet bin jetzt jetzt wiedermal dazugekommen da sonst ja alles sehr gut läuft
Titel: Antw:Vorsicht AES Trügerische Sicherheit mit vccu
Beitrag von: fiedel am 17 November 2014, 09:25:33
Hi ihr,

was ist denn hier nun rausgekommen? Ist AES nun "sischeee" wie die Rente vom Blüm, oder kann man sich den Aufwand sparen?

Gruß

Frank