Hallo,
im Vorfeld habe ich schon den Wiki Artikel durchgearbeitet und exemplarisch meinen Fensterkontakt ver-AES-t.
Das klappte ganz gut. Da ich einige Dinge noch nicht verstanden habe und mir im Wiki nicht immer ganz klar gewesen ist, was Client/Server Sender/Empfaenger seitig so passiert hier meine Fragen:
1. Setze ich beim HM-SEC-RHS aesCommReq=1, so erwartet die FHEM Zentrale, dass der Fenterkontakt den AES Key kennt, wenn Nachrichten ZUR FHEM Station gesendet werden. Kommunikation:
i) HM-SEC-RHS -> FHEM (Befehl unverschluesselt)
ii) FHEM -> HM-SEC-RHS (Antworte richtig, dann mache ich Deinen Befehl)
iii) HM-SEC-RHS -> FHEM (sendet den Challenge Response mit dem AES Key verschluesselt)
iv) FHEM akzeptiert den Befehl
2. Sollte der Key im HM-SEC-RHS ein falscher sein, so kann ich doch einfach aesCommReq=0 machen und alles ist i.O., oder?
Angenommen ich aendere den Key in FHEM kann ich doch den Key ueberbuegeln, oder?
3. Setze ich jedoch sign on, so kann ich von FHEM zum HM-SEC-RHS nur noch verschluesselt senden. Ein vergessen des Keys wuerde dann das Geraet unbrauchbar machen, richtig?
4. Jetzt die Graetchen Frage fuer mich: Warum macht es Sinn, einen Fensterkontakt mit AES ausszustatten? Wenn ich es richtig sehe, kann er ja nicht angesprochen werden (Punkt 3). Vor allem verstehe ich nicht, warum diese ab Werk schon AES an haben. (Das SEC im Name).
Macht es nicht nur Sinn, bei Devices die etwas Schalten koennen mit AES auszustatten? Sei es z.B. Jalos im Erdgeschoss, damit die hmId nicht durch eine nicht erlaubte andere "FHEM Station" geschaltet werden koennen.
Oder Schalter an sich. Wenn jemand die Id eines Schalters kennt, kann er diese Spoofen und Aktionen ausfuehren.
Habe ich bei meinen Vermutungen etwas uebersehen? Liege ich in einigen Punkten falsch? Bitte um Korrektur und Aufklaerung!
Danke!!
Nachdem ich es immer noch nicht ganz durchschaut habe, versuchte ich mich heute noch mehr einzuarbeiten.
Ich habe meine Jalos auf AES umgestellt.
Dazu habe ich set assignHmKey und sign on gesetzt.
Interessanterweise macht die Reihenfolge keinen Unterschied.
Daher Frage
1) Ist der Default Key von Homematic im FHEM hinterlegt? und ist dies der aesKeyNbr 00??
Nachdem ich etwas Traffic auf den Aktor gelegt hatte sprang dieser auf aesKeyNbr 02 hoch. Ist dies mein eigener Key?
2. ich habe das Attr aesCommReq gesetzt. Allerdings bekam ich keinen Key Error in der VCCU. Weiß jemand warum?
Macht dies überhaupt Sinn beim Jalo Aktor oder ist das eher für Fernbedienungen und Schalter....?
DANKE!
Hi,
ich bin jetzt kein Spezialist AES betreffend...
...also was den genauen Ablauf, Register, etc. angeht...
Aber soweit ich mich erinnere ist es keine Verschlüsselung, sondern Signierung...
Also mitlesen geht weiterhin, allerdings wird erkannt, dass die Nachricht/Befehl von jemand vertauenswürdigem kommt...
Key-Nr 02 müsste dein eigener sein, es ist immer 2x verwendeter Schlüssel oder so.
Also Key 1 wird tatsächlich verwendet, angezeigt wird die 2...
Ja, der Sinn bei einem Sensor ist etwas fragwürdig...
Aber ist wohl deshalb voreingestellt weil es zu den Geräten für Sicherheit/Einbruch/Alarm gehört...
Ohne AES könnte jemand ein Funkkommando absetzen, welches sofort nach dem echten Öffnen ein "closed" sendet und somit die Alarmanlage vielleicht gar nicht erst anschlägt oder gleich wieder ruhig wird...
Wie Realistisch das ist???
Allerdings ließe sich das auch mit einem Störsender, der einfach das "open" platt macht auch erreichen...
Bei einem Aktor, am Ende noch einer der die Tür etc. öffnet sieht das schon deutlich anders aus...
Nicht exakt was du alles wissen wolltest...
...aber schon mal ein Anfang...
Gruß, Joachim
Hallo Joachim,
schon mal Danke fuer die ersten Antworten :)
Vom Prinzip her habe ich es auch so verstanden. Es wird nur der Ursprung der Quelle verifizert durch das AES.
Zitat von: MadMax-FHEM am 19 November 2016, 18:41:02
Ohne AES könnte jemand ein Funkkommando absetzen, welches sofort nach dem echten Öffnen ein "closed" sendet und somit die Alarmanlage vielleicht gar nicht erst anschlägt oder gleich wieder ruhig wird...
Wie Realistisch das ist???
Leider ziemlich realistisch. Du brauchst nur eine CUL Dich vor ein Haus stellen und einen Sniffer laufen lassen.
Wenn Du die Base-HMid hast und einen Schalter mitsniffst, kannst Du sehr leicht den Befehl Spoofen und in den drahtlosen Bus schicken.
KNX ist vom Prinzip her genauso angreifbar. Nur, dass man dort zwar erstmal die 2 Kabel braucht (KNX Tuerklingel, Tempfuehler ...), aber dafuer gibt es dieses Challenge Response Signing nicht.
Mir ist halt noch etwas unklar, wie FHEM es genau implementiert hat.
Ich wuerde es allerdings sehr gerne verwenden. Vorzugsweise an den Buttons, da die ja alle moeglichen Funktionen bei mir schalten...
Was bringt z.B. AES im Tuerschloss, wenn die Fernbedienung ohne AES arbeitet...
Mit wie realistisch meinte ich welcher "Normal-Einbrecher" hat schon solches Equipment...
...und wer wirklich was hat zum Sichern und ernsthaft sichern will sollte über Funk noch mal nachdenken... ;-)
Dass es so "einfach" geht is scho klar... ;-)
Weil Störsender würde verm. auch reichen und da ist AES dann grad egal...
Echt, das gibt's?
Also Türöffner der auf FB ohne AES o.ä. reagiert und die Tür aufmacht???
Den würde ich ja wohl mal nicht nehmen...
WinMatic und KeyMatic machen das aber nur mit AES und ist (soweit ich weiß) auch nicht zu deaktivieren...
Vielleicht/hoffentlich meldet sich noch ein "AES-Spezialist" bzgl. der anderen Fragen...
Gruß, Joachim
Achja: AES ohne eigenen Schlüssel bringt nix, weil der Standard-Homematic-Key ist "bekannt"...
Jo klar, Störsender hebelt natürlich eine ganze Alarmanlage aus.
Naja die Einbrecher rüsten ja auch immer mehr nach. Und wenn man überlegt, dass gewisse Hauselektrik ein paar Jahre halten sollte und jetzt auf dem Markt so richtig in Schwung kommt, "könnte" das Thema Sicherheit eines Tages doch mehr in den Fokus rücken.
Man kann doch sicher die Keymatic mit der Station pairen und von dort aus öffnen, oder?
Der Weg dahin ist dann via AES, aber wenn ich einen Trigger habe, der der Station sagt: "Mach die Tür" auf und dieser Trigger nicht via AES sendet, sehe ich das als Risiko.
Oder mache ich mir da zuviel Gedanken?
Wird die Keymatic direkt via Peering FB->Keymatic angesprochen, ist das mit AES safe.
Ja, AES Profis her mit Euch :) Ihr werdet gebraucht :)
Zitat von: SofB am 23 Oktober 2016, 18:30:08Warum macht es Sinn, einen Fensterkontakt mit AES ausszustatten?
Es macht, wie du bereit erkannt hast, keinen Sinn.
AES brauchst du nur zwingend bei allen Geräten die sicherheitsrelevant sind: Keymatic, Winmatic und Alarmanlagen.
Logischerweise dann auch bei allen Triggern auf die diese Geräte direkt oder indirekt reagieren.
ZitatMan kann doch sicher die Keymatic mit der Station pairen und von dort aus öffnen, oder?
Der Weg dahin ist dann via AES, aber wenn ich einen Trigger habe, der der Station sagt: "Mach die Tür" auf und dieser Trigger nicht via AES sendet, sehe ich das als Risiko.
Oder mache ich mir da zuviel Gedanken?
Wird die Keymatic direkt via Peering FB->Keymatic angesprochen, ist das mit AES safe.
Wenn du über die "Station" also FHEM gehst - mit einem DOIF oder notify, dann sollte die Fernbedienung auch mit AES arbeiten. Dann musst du aber auch darauf achten, dass du nicht auf das short oder long der Fernbedienung triggerst, denn das kommt immer, egal ob die Fernbedienung den richtigen aesKey kennt oder nicht. Dann solltest du z.B. auf 'aesCommToDev ok' triggern, da dass nur kommt wenn die die AES-Signierung geklappt hat.
Ah, super, Danke für eure Hinweise!
Dass es dann vom Button Channel ein anderes Event gibt habe ich nicht gemerkt.
Wenn beim Button aesCommReq 1 ist, muss dann trotzdem sign on gesetzt sein? Ich habe das sign on bisher so verstanden, dass fhem zum device verschlüsselt. Das beträfe dann doch nur das ACK?
Das wiki beschreibt sehr gut AES. Bei diesen Punkten ist es leider nicht ganz genau.
Ich habe weiter geforscht...
scheinbar kann man sign on und aesCommReq unabhaengig voneinander betreiben.
Je nachdem um welche Direction es geht.
sign on = zentrale-> device
aesCommReq = device-> zentrale
Ich habe daher bei meinem 6fach Wandtaster sign on deaktviert und arbeite nur mit aesCommReq.
(zur Info vom Log her sieht es genauso aus, wenn ich sign on noch an habe, daher gehe ich davon aus, dass sign on bei Device->Zentrale keinerlei Bedeutung spielt.)
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer aesCommToDev: pending
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer battery: ok
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer CMDs_done
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer MultiTaster_Haustuer_Btn_05 Short
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer_Btn_05 trig_aes_VCCU: ok:12
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer_Btn_05 Short (to VCCU)
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer_Btn_05 trigger: Short_13
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer_Btn_05 trigger_cnt: 13
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer aesCommToDev: fail
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer_Btn_05 trig_aes_VCCU: fail:13
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer battery: ok
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer CMDs_done
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer MultiTaster_Haustuer_Btn_05 Short
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer_Btn_05 Short (to VCCU)
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer_Btn_05 trigger: Short_13
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer_Btn_05 trigger_cnt: 13
2016-11-20 15:07:49 CUL_HM MultiTaster_Haustuer aesCommToDev: pending
2016-11-20 15:07:50 CUL_HM MultiTaster_Haustuer aesCommToDev: ok
So richtig ist mir allerdings nicht klar, ob aes nun funktioniert oder nicht.
Die VCCU scheint ja hier Fehler zu werfen: trig_aes_VCCU: fail:13
Zitat von: automatisierer am 19 November 2016, 21:18:29
Wenn du über die "Station" also FHEM gehst - mit einem DOIF oder notify, dann sollte die Fernbedienung auch mit AES arbeiten. Dann musst du aber auch darauf achten, dass du nicht auf das short oder long der Fernbedienung triggerst, denn das kommt immer, egal ob die Fernbedienung den richtigen aesKey kennt oder nicht. Dann solltest du z.B. auf 'aesCommToDev ok' triggern, da dass nur kommt wenn die die AES-Signierung geklappt hat.
Gibt es da wirklich keinen eleganteren Weg? Wenn ich auf 'aesCommToDev ok' triggere, kann ich ja nicht mehr zwischen den unterschiedlichen Events (z. B. short, long) unterscheiden. Wie macht ihr das? Ich bin bis jetzt eigentlich davon ausgegangen, dass FHEM die Events nur wirft und die Readings setzt, wenn die Signierung korrekt war.
Grüße
Leo
Da hab ich mich noch nicht mit beschäftigt, da ich es nicht benötige. So arbeitet HM nunmal - der Befehl wird unverschlüsselt gesendet und anschließend wird überprüft ob der Sender den AES Key kennt - sofern es der Aktor denn verlangt...
2016-11-23 07:34:01.590 CUL_HM Flur_fs_Hand CMDs_done
2016-11-23 07:34:01.590 CUL_HM Flur_fs_Hand Flur_fs_Hand_Btn_01_unlock Short
2016-11-23 07:34:01.638 CUL_HM Flur_fs_Hand_Btn_01_unlock Short (to vccu)
2016-11-23 07:34:01.638 CUL_HM Flur_fs_Hand_Btn_01_unlock trigger: Short_3
2016-11-23 07:34:01.638 CUL_HM Flur_fs_Hand_Btn_01_unlock trigger_cnt: 3
2016-11-23 07:34:01.795 CUL_HM Flur_fs_Hand_Btn_01_unlock trig_aes_vccu: fail:3
2016-11-23 07:34:01.834 CUL_HM Flur_fs_Hand aesCommToDev: fail
2016-11-23 07:34:01.874 CUL_HM vccu_Btn5 trig_aes_Flur_fs_Hand_Btn_01_unlock: fail:3
Das 'Short' kommt bevor aes überprüft wird und auch bei einem 'aes fail'.
Man könnte notify/DOIF eventuell so bauen, dass auf das 'Short' und auf aes 'ok' geprüft wird.
Zum Beispiel für meine Events:
DOIF (["^Flur_fs_Hand$:^aesCommToDev:.ok$"] and [?Flur_fs_Hand_Btn_01_unlock] eq "Short (to vccu)") (set bla blub)