aesCommReq funktioniert scheinbar nicht richtig.

[traxanos]

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?

Code Auswählen Erweitern

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,

[Virsacer]

Wenn das Device keine Signatur anfordert (sign = off), dann führt das Device doch logischerweise auch alles ohne Signatur aus...

[traxanos]

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

[Virsacer]

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?

[martinp876]

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.

[traxanos]

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.

[mgernoth]

Hallo,

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.

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.

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

[traxanos]

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.

[Virsacer]

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

[traxanos]

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.

[mgernoth]

Hallo,

Ja ich habe auf jedem Channel aesCommReq aktiviert!

Und auf dem Geraet selbst?

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.

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

[traxanos]

Und auf dem Geraet selbst?

Danke das war. Dauernd wird darüber gesprochen das die Konfiguration pro Kanal passiert.

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?

[mgernoth]

Danke das war. Dauernd wird darüber gesprochen das die Konfiguration pro Kanal passiert.

Es muss in beiden geschehen

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

[traxanos]

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.