vccu-Buttons-expectAES nach neuesten Erkenntnissen

Ralli · 20 Juni 2015, 09:27:04

Hallo Martin und Michael,

wäre nach den neuesten AES-Erkenntnissen es nun nicht möglich, für die vCCU einzubauen, dass die virtuellen Kanäle wahlweise AES-Signatur vom gepeerten Device anfordern?

Das würde einiges vereinfachen und sicherer machen - Stichwort Fernbedienungen bzw. 6-fach-Taster, mit denen bspw. Alarmfunktionen aktivert und deaktiviert werden.

mgernoth · 20 Juni 2015, 12:46:02

Hallo Ralli,

Zitat von: Ralli am 20 Juni 2015, 09:27:04
wäre nach den neuesten AES-Erkenntnissen es nun nicht möglich, für die vCCU einzubauen, dass die virtuellen Kanäle wahlweise AES-Signatur vom gepeerten Device anfordern?

Das hat Martin eigentlich schon eingebaut. Dafuer gibts das Attribut aesCommReq, das man am jeweiligen Geraet setzen kann. Das sollte dann dann zum Reading aesCommToDev fuehren.

Gruss
Michael

Ralli · 20 Juni 2015, 13:27:48

Hallo Michael,

das ist mir bekannt - funktioniert aber in der jetzigen Implementierung m.W. nur zwischen dem IO, welches AES kann, und dem Device, oder? Ich meine aber nun nicht zwischen IO und Device sondern zwischen vCCU und Device.

Denn momentan funktioniert das z.B. mit einem HM-PB-6-WM55 nicht so richtig. Denn für den bekomme ich kein trig_aes_...-Reading in dem Channel der vCCU, obwohl aesCommReq gesetzt ist.

Code Auswählen


Internals: 
   DEF        654321
   IODev      HMLAN0 
   NAME       SZ_6fach_Ralf 
   NR         296 
   NTFY_ORDER 50-SZ_6fach_Ralf 
   STATE      SZ_6fach_Ralf_Btn_1 Short 
   TYPE       CUL_HM 
   channel_01 SZ_6fach_Ralf_Btn_1 
   channel_02 SZ_6fach_Ralf_Btn_2 
   channel_03 SZ_6fach_Ralf_Btn_3 
   channel_04 SZ_6fach_Ralf_Btn_4 
   channel_05 SZ_6fach_Ralf_Btn_5 
   channel_06 SZ_6fach_Ralf_Btn_6 
   Readings: 
     2015-02-15 13:30:18   CommandAccepted yes 
     2015-02-15 13:30:15   D-firmware      1.2 
     2015-02-15 13:30:15   D-serialNr      LEQxxx
     2014-12-14 10:34:17   PairedTo        0x123456 
     2014-12-14 10:34:17   R-pairCentral   0x123456
     2014-12-14 10:34:17   RegL_00:        02:01 0A:12 0B:34 0C:56 18:00 00:00 
     2015-02-15 13:30:20   aesCommToDev    ok 
     2015-02-15 13:30:17   aesKeyNbr       02 
     2015-02-15 13:30:20   aesReqTo        CCU 
     2015-06-17 22:16:32   battery         ok 
     2014-12-14 07:45:46   sabotageAttack  ErrIoAttack cnt:10 
     2015-06-17 22:16:32   state           SZ_6fach_Ralf_Btn_1 Short 
   Helper: 
     mId        00A9 
     rxType     28 
     Io: 
       newChn     +2FBBC6,01,01,1E 
       rxt        2 
       vccu       CCU 
       p: 
         2FBBC6 
         01 
         01 
         1E 
       prefIO: 
         HMLAN0 
         HMLAN1 
         HMLAN2 
         HMLAN3 
     Mrssi: 
       mNo 
     Prt: 
       bErr       0 
       sProc      0 
     Q: 
       qReqConf 
       qReqStat 
     Role: 
       dev        1 
   Role: 
Attributes: 
   IODev      HMLAN0 
   IOgrp      CCU:HMLAN0,HMLAN1,HMLAN2,HMLAN3 
   aesCommReq 1 
   autoReadReg 4_reqStatus 
   expert     2_full 
   firmware   1.2 
   model      HM-PB-6-WM55 
   room       Schlafzimmer 
   serialNr   LEQxxx
   subType    remote 
   webCmd     getConfig:clear msgEvents

Exemplarisch der Kanal 6 (sign on, gepeerter Kanal der vCCU erfordert kein AES):

Code Auswählen


Internals: 
   DEF        65432106 
   NAME       SZ_6fach_Ralf_Btn_6 
   NR         303 
   NTFY_ORDER 50-SZ_6fach_Ralf_Btn_6 
   STATE      Short (to CCU) 
   TYPE       CUL_HM 
   chanNo     06 
   device     SZ_6fach_Ralf 
   peerList   CCU_Btn6, 
   Readings: 
     2014-12-14 10:49:00   CommandAccepted yes 
     2014-12-14 10:34:28   R-CCU_Btn6-expectAES off 
     2014-12-14 10:34:28   R-CCU_Btn6-peerNeedsBurst off 
     2014-11-15 13:43:30   R-dblPress      0 s 
     2014-12-14 07:42:51   R-longPress     1 s 
     2014-12-14 10:34:25   R-sign          on 
     2014-12-14 10:34:25   RegL_01:        04:70 08:01 09:00 00:00 
     2014-12-14 10:34:28   RegL_04:CCU_Btn6 01:00 00:00 
     2015-06-18 18:19:04   peerList        CCU_Btn6, 
     2014-12-14 10:37:15   state           Short (to CCU) 
     2014-11-15 14:41:48   trigDst_CCU     noConfig 
     2014-12-14 10:37:15   trigger         Short_3 
     2014-12-14 10:37:15   trigger_cnt     3 
   Helper: 
     Role: 
       chn        1 
Attributes: 
   model      HM-PB-6-WM55 
   peerIDs    00000000,12345606,

Code Auswählen


Internals: 
   DEF        12345606 
   NAME       CCU_Btn6 
   NR         282 
   NTFY_ORDER 50-CCU_Btn6 
   STATE      set_press long 
   TYPE       CUL_HM 
   chanNo     06 
   device     CCU 
   peerList   SZ_6fach_Nocheiner_Btn_6,SZ_6fach_Ralf_Btn_6, 
   Readings: 
     2015-02-15 13:30:19   CommandAccepted yes 
     2015-06-18 18:19:01   peerList        SZ_6fach_Nocheiner_Btn_6,SZ_6fach_Ralf_Btn_6, 
     2014-12-14 08:51:24   state           set_press long 
     2014-12-14 10:37:15   trigLast        SZ_6fach_Ralf_Btn_6 :short 
     2014-12-14 10:37:15   trig_SZ_6fach_Ralf_Btn_6 short 
     2014-12-14 07:49:59   trig_SZ_6fach_Nocheiner_Btn_6 short 
     2014-12-14 08:51:25   trigger_cnt     3 
   Helper: 
     Role: 
       chn        1 
Attributes: 
   model      CCU-FHEM 
   peerIDs    65432106,65432206, 
   webCmd     press short:press long

Nun kann ich aber kein aesCommReq in der vCCU nur für einen Kanal setzen, den kann ich ja immer nur für das ganze Device setzen. Muss ich das nun auf die vCCU setzen, geht das überhaupt?

Hier das funktionierende Gegenbeispiel, der Kanal 7 der vCCU ist mit einem Kanal eines HM-PB-2-FM gepeered - auch hier erwartet zwar laut Reading der gepeerte Kanal der vCCU kein AES, klappt aber:

Code Auswählen


Internals: 
   DEF        12345607 
   NAME       CCU_Btn7 
   NR         283 
   NTFY_ORDER 50-CCU_Btn7 
   STATE      ??? 
   TYPE       CUL_HM 
   chanNo     07 
   device     CCU 
   peerList   GEN_Rollo_Zentral_Runter, 
   Readings: 
     2014-12-14 10:35:46   CommandAccepted yes 
     2015-06-18 18:19:01   peerList        GEN_Rollo_Zentral_Runter, 
     2015-05-31 05:37:28   trigLast        GEN_Rollo_Zentral_Runter :short 
     2015-05-31 05:37:28   trig_GEN_Rollo_Zentral_Runter short 
     2015-05-31 05:37:31   trig_aes_GEN_Rollo_Zentral_Runter ok:10 
   Helper: 
     Role: 
       chn        1 
Attributes: 
   model      CCU-FHEM 
   peerIDs    ABCDEF01, 
   webCmd     press short:press long

Code Auswählen


Internals: 
   DEF        AABBCC01 
   NAME       GEN_Rollo_Zentral_Runter 
   NR         493 
   NTFY_ORDER 50-GEN_Rollo_Zentral_Runter 
   STATE      Short (to CCU) 
   TYPE       CUL_HM 
   chanNo     01 
   device     GEN_Rollo_Zentral_Device 
   peerList   CCU_Btn7, 
   Readings: 
     2015-05-05 15:32:19   CommandAccepted yes 
     2015-05-05 16:06:57   R-CCU_Btn7-expectAES off 
     2015-05-05 16:06:57   R-CCU_Btn7-peerNeedsBurst off 
     2015-05-05 15:06:20   R-longPress     0.4 s 
     2015-05-05 15:16:47   R-sign          on 
     2015-05-05 16:06:56   RegL_01:        04:10 08:01 30:03 00:00 
     2015-05-05 16:06:57   RegL_04:CCU_Btn7 01:00 00:00 
     2015-06-18 18:19:02   peerList        CCU_Btn7, 
     2015-05-31 05:37:28   state           Short (to CCU) 
     2015-05-31 05:37:31   trig_aes_CCU    ok:10 
     2015-05-31 05:37:28   trigger         Short_10 
     2015-05-31 05:37:28   trigger_cnt     10 
   Helper: 
     Role: 
       chn        1 
Attributes: 
   model      HM-PB-2-FM 
   peerIDs    00000000,12345607,

mgernoth · 20 Juni 2015, 17:56:15

Hi,

Zitat von: Ralli am 20 Juni 2015, 13:27:48
Denn momentan funktioniert das z.B. mit einem HM-PB-6-WM55 nicht so richtig. Denn für den bekomme ich kein trig_aes_...-Reading in dem Channel der vCCU, obwohl aesCommReq gesetzt ist.

Wenn aesCommReq im Geraet gesetzt ist, fuehrt das dazu, dass der HMLAN/HMCFGUSB darueber informiert wird, dass er fuer Events dieses Geraets eine AES-Signatur anfordern soll. Mehr kann man da nicht definieren (Kanaele kann man auch nicht angeben), das IO entscheidet in der Firmware selbst, wann es die Signatur anfordert...

Ich habe das auch schon gesehen und bisher noch kein richtiges Muster feststellen koennen, wann AES angefordert wird und wann nicht, mit der Konfiguration von expectAES im Geraet hat das aber sicher nichts zu tun, das sagt nur dem Geraet, dass es sich auf eine AES-Anfrage vorbereiten soll (das Geraet muss dafuer z.B. das Event aufheben).

Gruss
Michael

traxanos · 08 August 2015, 17:33:47

Ich habe das Problem auch. Ich hätte erwartet den virtuellen Button per sign zu sagen er soll die Anfragen signieren. Allerdings bekomme ich immer folgenden Fehler:

Code Auswählen

sign failed: supported register are pairCentral

Solange das nicht der Fall ist, hab ich nun wieder das expectAES auf jedem Button ausgeschaltet.

martinp876 · 09 August 2015, 07:26:35

virtuelle Devices haben keine Register.

traxanos · 09 August 2015, 18:23:37

Aber wie kann ich dem virtuellen Button mitteilen, seine Antworten gültig zu signieren? Den ein Taster wird die Anfrage immer mit Rot quittieren, da die Antwort nicht signiert ist.

mgernoth · 09 August 2015, 19:21:08

Hallo,

Zitat von: traxanos am 09 August 2015, 18:23:37
Aber wie kann ich dem virtuellen Button mitteilen, seine Antworten gültig zu signieren? Den ein Taster wird die Anfrage immer mit Rot quittieren, da die Antwort nicht signiert ist.

aesCommReq im entsprechenden Kanal des Geräts setzen. Das ist kein Attribut der vccu sondern des entsprechenden Geräts, da es sich auf jede Kommunikation mit diesem Kanal bezieht und nicht nur auf virtuelle Geräte der vccu.

Gruß
Michael

traxanos · 09 August 2015, 19:33:51

Da muss ich dir leider wider sprechen. Das Device erwartet eine Signierte Antwort und bekommt diese nicht, dabei muss das virtuelle Device eine signierte Antwort schicken was eben nicht gemacht wird. Daher wir auch vom Device die Antwort abgelehnt und mit einem roten Leuchten signalisiert.

Hier ein Listing des ersten Tasters

Code Auswählen

Internals: 
   BNO        69 
   BNOCNT     3 
   DEF        31823601 
   NAME       Schalter.Reserve2_Btn_01 
   NR         89 
   NTFY_ORDER 50-Schalter.Reserve2_Btn_01 
   STATE      Short (to vCCU) 
   TYPE       CUL_HM 
   chanNo     01 
   device     Schalter.Reserve2 
   peerList   vCCU_Btn1, 
   Readings: 
     2015-08-08 17:31:15   CommandAccepted yes 
     2015-08-04 23:32:12   R-dblPress      0 s 
     2015-08-04 23:32:12   R-longPress     0.4 s 
     2015-08-09 18:09:49   R-sign          on 
     2015-08-09 18:04:14   R-vCCU_Btn1-expectAES on 
     2015-08-09 18:04:14   R-vCCU_Btn1-peerNeedsBurst off 
     2015-08-09 18:09:49   RegL_01:          04:10 08:01 09:00 00:00 
     2015-08-09 18:09:51   RegL_04:vCCU_Btn1   01:80 00:00 
     2015-08-09 18:09:50   peerList        vCCU_Btn1, 
     2015-08-09 19:00:19   state           Short (to vCCU) 
     2015-08-04 23:35:40   trigDst_vCCU    noConfig 
     2015-08-09 19:00:19   trigger         Short_82 
     2015-08-09 19:00:19   trigger_cnt     82 
   Helper: 
     peerIDsRaw ,26EBD701,00000000 
     Role: 
       chn        1 
     Shadowreg: 
   Role: 
Attributes: 
   aesCommReq 1 
   model      HM-PB-6-WM55 
   peerIDs    00000000,26EBD701,

martinp876 · 09 August 2015, 20:11:26

Sich sagt dass AES angefordert werden soll. Bei einem virtuellen button ist sich daher irrelevant. Nur wenn man die Register aendern wollte wäre es gefragt. Er hat aber keine.
Beim aktor könnte man es einbauen um den Sender zu prüfen.

Verwendet man die virtuellen Kanäle der vccu klappt das schon. Mit aescomreq wird der Sender geprüft.
Für die anderen virtuellen Kanäle ist es bisher nicht eingeplant.

Machbar ist also schon jetzt alles über vccu

traxanos · 09 August 2015, 20:17:11

Ich nutze doch eine vCCU und ich habe aescomreq aktiviert. Dennoch werden die Trigger der Buttons ausgewertet. Und das ist ein Sicherheitsproblem. Auch wenn der KEY selber in der vCCU geändert wird (inkl. HMUSB und HMLAN).

traxanos · 09 August 2015, 21:42:19

Also wie im anderen Thread schon beschrieben geht es nun. Es musste auf dem Device zusätzlich auch das aesCommReq gesetzt werden (also 2x)

SofB · 19 November 2016, 18:12:38

Auch bei mir ist das Thema nun aktuell geworden.
Ich versuche dem 6x Wandtaster AES beizubringen.
Denn was bringen mir Jalo Aktoren, die nur verschlüsselt von der Zentrale angesprochen werden, wenn ich diese mit einem Knopf hoch und runter fahren kann....

Daher habe ich auf dem Gerät assignHmKey gesetzt und als Attr aesCommReq 1 gesetzt.
In jedem Channel (Buttons) habe ich Sign on gesetzt und aesCommReq 1.
Was ich vermisse, ist das Reading aesKeyNr. Ich kann nicht erkennen, ob mein Key 02 verwendet wird.
Auch habe ich nun den Nebeneffekt, dass Commands manchmal von der Zentrale doppelt ausgeführt werden.

Kann mir da jemand helfen?

Macht man überhaupt ein sign on auf einen Button?! Wenn ich es mir richtig überlege sorgt das doch nur dafür, dass der Button auf das ACK ein Sign erwartet, oder???

Nachtrag: R-VCCU_Btn1-expectAES steht auf off bei mir...