Hi,
ich habe einen Button auf dem ich sign = off eingerichtet habe, dürften sich doch die Readings nicht verändern beim Tastendruck. Wenn ich jetzt ein DOIF oder notify auf diesen Button lege, würde doch der Button ausgewertet. Somit ist die Signierung doch voll für die Katz, oder?
Internals:
BNO 2
BNOCNT 3
DEF 31823606
NAME Schalter.Reserve2_Btn_06
NR 94
NTFY_ORDER 50-Schalter.Reserve2_Btn_06
STATE Short (to vCCU)
TYPE CUL_HM
chanNo 06
device Schalter.Reserve2
peerList vCCU_Btn1,
Readings:
2015-08-04 23:29:05 R-dblPress 0 s
2015-08-04 23:29:05 R-longPress 0.4 s
2015-08-08 17:34:40 R-sign off
2015-08-08 17:31:31 R-vCCU_Btn1-expectAES off
2015-08-08 17:31:31 R-vCCU_Btn1-peerNeedsBurst off
2015-08-08 17:34:40 RegL_01: 04:10 08:00 09:00 00:00
2015-08-08 17:34:41 RegL_04:vCCU_Btn1 01:00 00:00
2015-08-08 17:34:41 peerList vCCU_Btn1,
2015-08-08 17:35:16 state Short (to vCCU)
2015-08-04 23:38:26 trigDst_vCCU noConfig
2015-08-08 17:35:16 trigger Short_9
2015-08-08 17:35:16 trigger_cnt 9
Helper:
peerIDsRaw ,26EBD701,00000000
Role:
chn 1
Shadowreg:
Role:
Attributes:
aesCommReq 1
model HM-PB-6-WM55
peerIDs 00000000,26EBD701,
Wenn das Device keine Signatur anfordert (sign = off), dann führt das Device doch logischerweise auch alles ohne Signatur aus...
Es geht darum, das die vCCU normal per aesCommReq eine AES-Sigantur voraussetzt, aber das Device diese nicht sendet. Dennoch wird von der vCCU die Daten verarbeitet. Damit könnte also der Nachbar meiner vCCU reden ohne die korrekte Signatur zu haben. Das ist wäre somit ein Sicherheitsloch in vCCU (FHEM).
Woher weißt du, dass das Device keine Signatur sendet? ("sign = off" ist nur für Befehle an das Device)
Hast du mal versucht, was passiert, wenn du den Key in der vCCU um ein Zeichen veränderst?
Habt ihr die aktuelle SW ?
Da hat sich etwas getan.
Ihr müsst in der entity das attr aescommreq setzen. Ein sich gibt es bei der vccu nicht. Macht auch keinen Sinn da man AES nicht allg. Einschaltet sondern je Kanal.
Hi martin, ich habe die aktuelle SVN Version drauf. Wie gesagt wenn ich einen Kanal habe der nicht signiert (sign=off), aber dieser Kanal aesCommReq=1 gesetzt hat, dann dürfte der Trigger auch nicht auslösen. Sonst kann ich mir das AES auch komplett schenken. Denn so kann jeder dem FHEM sagen das er eine Aktion ausführen soll.
Alternativ habe ich versucht, dass Ganze über den virtuellen Button der vCCU zu realisieren, aber dieser scheint überhaupt kein AES Support zu haben, dann dort kann ich nichtmal sagen, dass alle Antworten signiert werden. Daher bekommt der Pushbutton seine Anfragen nicht gültig quittiert und leuchtet rot. Aber ein Notify oder DOIF reagiert auf die Anfrage.
Für mich sieht das aus, als würden die Readings immer akzeptiert werden. So ist aktuell keine sichere Nutzung von Homematic-Geräten mit FHEM möglich. Lediglich die Geräte untereinander können ordentlich signiert kommunizieren.
Hallo,
Zitat von: traxanos am 09 August 2015, 18:21:08
Wie gesagt wenn ich einen Kanal habe der nicht signiert (sign=off), aber dieser Kanal aesCommReq=1 gesetzt hat, dann dürfte der Trigger auch nicht auslösen. Sonst kann ich mir das AES auch komplett schenken. Denn so kann jeder dem FHEM sagen das er eine Aktion ausführen soll.
Wieso?
sign ist (wie schon von Virsacer geschrieben) nicht für diese Richtung zuständig, hier gilt nur das aesCommReq-Attribut und das expectAES-Register im Gerät, damit es eine Rückmeldung über das ausbleiben von AES geben kann.
Zitat
Alternativ habe ich versucht, dass Ganze über den virtuellen Button der vCCU zu realisieren, aber dieser scheint überhaupt kein AES Support zu haben, dann dort kann ich nichtmal sagen, dass alle Antworten signiert werden. Daher bekommt der Pushbutton seine Anfragen nicht gültig quittiert und leuchtet rot. Aber ein Notify oder DOIF reagiert auf die Anfrage.
Dann hast Du aesCommReq raus, aber expectAES im Gerät noch an. Du musst aesCommReq setzen, siehe anderer Thread.
Zitat
Für mich sieht das aus, als würden die Readings immer akzeptiert werden. So ist aktuell keine sichere Nutzung von Homematic-Geräten mit FHEM möglich. Lediglich die Geräte untereinander können ordentlich signiert kommunizieren.
Nein, das funktioniert schon. Ändere doch mal (wie auch von Virsacer vorgeschlagen) kurz Deinen AES-Schlüssel in der VCCU, dann kommen (wenn aesCommReq im Gerät und Kanal gesetzt ist) keine Events mehr duch und auch sowas wie getConfig funktioniert nicht mehr.
Gruß
Michael
Auch hier muss ich wie im anderen Thread schon geschrieben wider sprechen. Ich kann auch den Key verändern und alle Triggers werden von FHEM wie schon geschrieben verarbeitet. Solange der Key falsch ist kann ich lediglich nicht mehr mit dem Device sprechen (z.B. getConfig) aber alle Werte vom Device werden verarbeitet und dass ist somit eine Sicherheitslücke in FHEM.
Hast du denn auch in den Channels "aesCommReq" gesetzt?
Bei mir passiert dann nämlich nix mehr, so wie es sein soll ;)
Nur nochmal fürs Protokoll:
"sign" ist etwas irreführen und müsste eigentlich eher "requestSignature" heißen, denn dieses Register bewirkt, dass das Device für Befehle eine Signatur anfordert und nur akzepiert, wenn diese gültig ist.
"aesCommReq" bedeutet, dass die vCCU eine Signatur vom dem Gerät anfordert, bei dem dieses Attribut gesetzt ist und Daten auch nur akzeptiert, wenn die Signatur gültig ist.
Wenn ein Empfänger eine Signatur anfordert, generiert der Sender auch eine und beide Richtungen sind komplett unabhängig voneinander...
Ja ich habe auf jedem Channel aesCommReq aktiviert!
Ich habe das übrigens anders verstanden. "Sign" sagt das ein Request signiert wird. expectAes, sagt das die Response signiert sein muss. Und aesCommReq sagt das die vCCU eine Signatur anfordert.
Hallo,
Zitat von: traxanos am 09 August 2015, 20:21:15
Ja ich habe auf jedem Channel aesCommReq aktiviert!
Und auf dem Geraet selbst?
Zitat
Ich habe das übrigens anders verstanden. "Sign" sagt das ein Request signiert wird.
Nein, sign sorgt dafuer, dass das Geraet eine Signatur anfordert. Bei einem Taster normalerweise nur fuer Configaenderungen, Reset und sowas.
Zitat
expectAes, sagt das die Response signiert sein muss. Und aesCommReq sagt das die vCCU eine Signatur anfordert.
Ja.
Und jetzt was ganz anderes:
- Fhem ist aktuell?
- Da auch ein HMCFGUSB im Einsatz ist: hmland ist aktuell (0.101)? Da gabs auch ein Problem, dass zu sowas fuehren kann.
Viele Gruesse
Michael
Zitat von: mgernoth am 09 August 2015, 20:32:31
Und auf dem Geraet selbst?
Danke das war. Dauernd wird darüber gesprochen das die Konfiguration pro Kanal passiert.
Zitat von: mgernoth am 09 August 2015, 20:32:31
Und jetzt was ganz anderes:
- Fhem ist aktuell?
- Da auch ein HMCFGUSB im Einsatz ist: hmland ist aktuell (0.101)? Da gabs auch ein Problem, dass zu sowas fuehren kann.
Ja das hatte ich alle frisch kompiliert gehabt inkl. aktueller Firmware. FHEM wird bei mir ebenfalls täglich aktualisiert.
Was mich wundert warum es überhaupt ein sign auf den Channels gibt, denn Config und Co wird doch auf den Hauptdevice gemacht?
Zitat von: traxanos am 09 August 2015, 20:40:01
Danke das war. Dauernd wird darüber gesprochen das die Konfiguration pro Kanal passiert.
Es muss in beiden geschehen ;-)
Zitat
Was mich wundert warum es überhaupt ein sign auf den Channels gibt, denn Config und Co wird doch auf den Hauptdevice gemacht?
Es wirkt sich z.B. beim regSet aus, wenn entsprechende Kanaele betroffen sind.
Bei Schaltaktoren ist das kanalbezogene Attribut offensichtlicher, da es dann auch Schaltvorgaenge auf diesem Kanal betrifft.
Gruss
Michael
Trotzdem danke nochmal, auch wenn ich noch nicht alles 100% begriffen habe. Wenn ich mal mehr zeit habe, schau ich mir mal das Protokoll noch genauer an und dessen Implementierung.