HM-SEC-SD-2 neu

mgernoth · 10 Mai 2016, 13:52:07

Hi,

Zitat von: mgernoth am 10 Mai 2016, 12:12:52
Ich denke, dass alle Geräte sich den letzten Wert der bekannten Absender merken. Damit ist das Bootstrap-Problem gelöst, ich konnte von meiner Zentralen-ID mit Counter-Wert 0 das erste Frame erfolgreich senden, danach musste ich inkrementieren.

Anscheinend muss der Counter nur inkrementiert werden, wenn die gleiche Nachricht (mit gleicher EventID, Byte 2 der Payload) nochmals gesendet wird.

Dies hier war ein echter SD2 (in dem Fall der Team Leader):

Code Auswählen


2016-05-10 13:25:16.407: 13 03 14 41 4901F5 4901F5 01030000 0002 572DF464 (Sensor, AES: good, key: ...)
2016-05-10 13:28:02.629: 13 04 14 41 4901F5 4901F5 01049600 0002 2847ACD8 (Sensor, AES: good, key: ...)
2016-05-10 13:29:33.028: 13 05 14 41 4901F5 4901F5 01050000 0002 A7471FE5 (Sensor, AES: good, key: ...)
2016-05-10 13:35:24.478: 13 06 14 41 4901F5 4901F5 01060000 0002 311E758D (Sensor, AES: good, key: ...)

EDIT: Scheint ein Generationszähler zu sein. Nach einem Reboot des SD2 wurde der Counter inkrementiert:

Code Auswählen


2016-05-10 14:49:36.081: 13 01 14 41 4901F5 4901F5 01019600 0003 730ECE47 (Sensor, AES: good, key: ...)

Viele Grüße
Michael

MarcelK · 10 Mai 2016, 20:06:01

Zitat von: mgernoth am 10 Mai 2016, 13:52:07
Ich denke, dass alle Geräte sich den letzten Wert der bekannten Absender merken.

Also sendet jeder SD-2 jetzt mit seiner eigenen ID? Beim alten war es doch so dass alle die ID des Teams hatten, oder hab ich das falsch verstanden? (Hab bisher weder alt noch neu)

ZitatAnscheinend muss der Counter nur inkrementiert werden, wenn die gleiche Nachricht (mit gleicher EventID, Byte 2 der Payload) nochmals gesendet wird.

Auch das stimmt mit meinem Code überein, da dort das EventID Byte als LSB mitgerechnet wird.

ZitatEDIT: Scheint ein Generationszähler zu sein. Nach einem Reboot des SD2 wurde der Counter inkrementiert:

Und dann hatte auch nur dieser eine den neuen Zähler oder haben sich alle anderen angepasst?

Viele Grüße, Marcel

mgernoth · 10 Mai 2016, 23:42:37

Hi,

Zitat von: MarcelK am 10 Mai 2016, 20:06:01
Also sendet jeder SD-2 jetzt mit seiner eigenen ID? Beim alten war es doch so dass alle die ID des Teams hatten, oder hab ich das falsch verstanden? (Hab bisher weder alt noch neu)

Jein. Die neuen (alte habe ich auch nicht, daher weiss ich es nicht) senden mit ihrer ID als Empfänger und der Adresse des Teamleaders als Absender. Wahrscheinlich aus Stromspargründen.

Zitat
Und dann hatte auch nur dieser eine den neuen Zähler oder haben sich alle anderen angepasst?

Nur der eine.

Viele Grüße
Michael

martinp876 · 11 Mai 2016, 09:03:37

SDS im Team senden "im Namen des Teams" Alarme u.ä.
Daher ist bei alarm oder teamcall der Absender das Team. Das Telegramm ist ein broadcast oder Multicast, somit müssen alle Empfänger prüfen ob sie betroffen sind. Die Empfängeradresse ist erst mal egal.
Nun wird die Empfängeradresse doch gesetzt um zu erkennen, wer es war. SDS machen damit m.w. nichts, oder kaum etwas. Die zentrale kann aber auswerten wer es war.

Das Verfahren ist identisch zu den alten SDs.

Mit Strom sparen hat es nichts zu tun sonder rein mit dem Protokoll. Im Prinzip ist das bei allen anderen Aktoren/Sensoren identisch. Ein Sensor sendet einen Multicast mit seiner Adresse und alle Aktoren prüfen, ob einer ihrer Kanäle aktiv werden müsste. Anders wäre ein longpress zum dimmen mehrerer aktores durch einen Sender nicht simultan möglich.

martinp876 · 11 Mai 2016, 11:00:59

hier nein paar Beispiele für das AES.

Code Auswählen

m:13 1441 AFFE02 490215 01139600000307B9ACB4
m:13 1441 AFFE02 490215 011397000003B38503F6
m:14 1441 AFFE02 490215 0114960000034916089C
m:14 1441 AFFE02 490215 011497000003019AAC82
m:15 1441 AFFE02 490215 011596000003AEF83F38
m:15 1441 AFFE02 490215 011597000003506AA539
m:12 1441 AFFE02 44E347 011200000004962684B4
m:01 1441 490215 490215 010196000004D4F59F69
m:02 1441 490215 490215 01020000000420D35D9A
m:03 1441 490215 490215 01039600000423B66907
m:04 1441 490215 490215 010400000004B647AFB8
m:05 1441 490215 490215 01059600000407EED62D
m:06 1441 AFFE02 490215 01069700000443DCC4D0
m:07 1441 AFFE02 490215 010796000004D8E22421
m:07 1441 AFFE02 490215 0107970000049D6F0DDE
m:08 1441 AFFE02 490215 010896000004F354B58F
m:08 1441 AFFE02 490215 010897000004A402E38F
m:09 1441 AFFE02 490215 01099600000447DA9DDB
m:0A 1441 AFFE02 490215 010A0000000417F1482F
m:0B 1441 AFFE02 490215 010B96000004A87B4A2A
m:0C 1441 AFFE02 490215 010C00000004A5D9D5C5
m:13 1441 AFFE02 44E347 01139600000421A4BFA4
m:13 1441 AFFE02 44E347 011397000004FF7C48E8

mgernoth · 15 Mai 2016, 13:51:15

Hallo,

im Anhang mal eine erste Implementierung der AES CBC-Signatur in 10_CUL_HM.pm. Funktioniert soweit, dass ich aus Fhem einen TeamCall ausloesen kann, Alarm habe ich nicht getestet (Sonntag...).

~~Problem ist noch der Generationencounter, der muesste irgendwo (pro Team/global/?) gespeichert werden und immer beim Ueberlauf der msgNo bzw. beim Fhem-Neustart inkrementiert werden.~~ Was passiert, wenn der Counter bei 65535 ankommt, weiss ich nicht...

EDIT: Habe gerade eine Idee fuer den Generationencounter, Anhang nochmals entfernt
EDIT2: Generationencounter als Reading aesCBCCounter implementiert, wird nur inkrementiert, wenn es wirklich sein muss
EDIT3: Aufruf von CUL_HM_parseSDteam_2 hinzugefuegt

Viele Gruesse
Michael

MarcelK · 15 Mai 2016, 14:32:59

Zitat von: mgernoth am 15 Mai 2016, 13:51:15
im Anhang mal eine erste Implementierung der AES CBC-Signatur in 10_CUL_HM.pm. Funktioniert soweit, dass ich aus Fhem einen TeamCall ausloesen kann, Alarm habe ich nicht getestet (Sonntag...).

Super. Hatte diese Woche leider keine Zeit mehr mich mit dem Thema zu beschäftigen, aber das Prinzip des Teams (Toll, Ein Anderer Macht's) hat sich mal wieder bestätigt

Cheers, Marcel

Bytechanger · 18 Mai 2016, 20:45:55

Wird es bald eine über UPDATE abrufbare Version für den SD2 geben?

Greets

Byte

martinp876 · 18 Mai 2016, 21:10:48

Ja. Habe schon einmal getestet. Noch ein paar Kleinigkeiten.

martinp876 · 20 Mai 2016, 18:59:26

ist eingecheckt - testet einmal

mgernoth · 20 Mai 2016, 19:33:31

Hallo Martin,

Zitat von: martinp876 am 20 Mai 2016, 18:59:26
ist eingecheckt - testet einmal

Danke

Das hier erscheint mir falsch:

Code Auswählen


my $msg = "++1441$dst${dst}01${tstNo}9600";
...
my $msg = "++1441$dst${dst}01$tstNo${p}00";

Grund: Du setzt den Absender auf den Team-Leader und signierst die Nachricht. Alle anderen Geräte im Team merken sich den neuen Counter und akzeptieren keine Nachrichten vom "echten" Teamleader mehr (wenn er ein reales Gerät ist und sein Counter kleiner als der der Zentrale ist).

Ich denke, die einzige Chance Nachrichten abzusetzen und kein anderes Gerät auszuschliessen ist es, die Nachrichten unter der ID der Zentrale zu versenden und nicht unter der ID des Teams, also:

Code Auswählen


my $msg = "++1441$dst${id}01${tstNo}9600";
...
my $msg = "++1441$dst${id}01$tstNo${p}00";

Sonst werden evtl. echte Alarmmeldungen von den anderen Teamteilnehmern nicht mehr akzeptiert.

Viele Grüße
Michael

Bytechanger · 20 Mai 2016, 20:46:14

Hi,

kann man sich nun über UPDATE die Änderungen holen?
Nach UPDATE war aber alles wie bisher.
Ein druck auf teamCall odder alarmOn brachte jeweils eine Fehlermeldung ("Unknown argument teamCall, choose one of peerChan postEvent p ...")

@mgernoth: Nach dem Wiki sollte der TeamLeader aber ein virtuelles Gerät sein. Damit gäbe es dieses Problem doch nicht.
Und zumindest beim SD brauchte der TeamLeader nicht aktiv zu werden beim Alarm. Es wurde einfach die ID des TeamLeaders genommen, damit die TeamID individuell ist. Alle Geräte hörten dann auf diese ID.

Greets

Byte

martinp876 · 20 Mai 2016, 22:38:27

Update geht morgen, heute svn direkt.

Bei de. Adressen steht als Absender die teamid drin wenn es ein Teamkommando ist.
Als Empfänger der steht das sende device drin. Das ist bei SDs so.
Die Kommandos koennen nur vom teamlead ausgelöst werden, da sie nur dort eingetragen sind.
Also ist source und dest identisch. Das ist auch bei physikalischen SDs so. Also erst einmal alles korrekt. Die ID kommt nie rein, es sei denn der lead ist dein io oder die vccu.

Hast du das mit den msgcou tern getestet? Aus gutem Grund das Kommando nicht vorhanden.
Fuer mich steht eigentlich gleich ausser Frage, dass man einen virtuellen teamlead nehmen sollte

mgernoth · 20 Mai 2016, 23:15:32

Hallo Martin,

Zitat von: martinp876 am 20 Mai 2016, 22:38:27
Bei de. Adressen steht als Absender die teamid drin wenn es ein Teamkommando ist.
Als Empfänger der steht das sende device drin. Das ist bei SDs so.

Ja.

Zitat
Die Kommandos koennen nur vom teamlead ausgelöst werden, da sie nur dort eingetragen sind.
Also ist source und dest identisch. Das ist auch bei physikalischen SDs so. Also erst einmal alles korrekt. Die ID kommt nie rein, es sei denn der lead ist dein io oder die vccu.

Dann dürfen bei den SD2 keine physikalische Teamleads erlaubt werden, da dann der physikalische Leader keine korrekten Nachrichten mehr senden kann, die von den anderen Teammitgliedern akzeptiert werden. Dies ist die Replay-Protection des AES-CBC-Verfahrens!

D.h. wenn ich einmal einen Testalarm per Fhem auslöse, wird der nächste echte Alarm des Teamleaders von den Mitgliedern ignoriert werden!

Wir dürfen hier auf gar keinen Fall die Adresse eines physikalischen Gerätes als Absender (im Empfängerfeld) haben, da sonst echte Alarme untergehen!

Zitat
Hast du das mit den msgcou tern getestet?

Ja

Zitat
Aus gutem Grund das Kommando nicht vorhanden.

Bei mir hat es problemlos funktioniert, die Messages (allerdings habe ich nur Teamcall getestet) mit der ID meiner VCCU im Empfängerfeld abzusenden und alle Teammitglieder haben reagiert.

Code Auswählen


2016-05-15 17:30:13.219: 13 0C 14 41 4901F5 68EA13 01019600 0005 D6990152 (Sensor, AES: good, key: ...)

4901F5 ist die Adresse meines physikalischen Teamleads (und damit die Teamadresse), 68EA13 die meiner VCCU.

Zitat
Fuer mich steht eigentlich gleich ausser Frage, dass man einen virtuellen teamlead nehmen sollte

Wenn der Teamlead virtuell ist, dann ist es kein Problem, da die ID keinem realen Gerät entspricht.
Falls dem nicht so ist, dürfen aber auf keinen Fall Nachrichten mit der ID des physikalischen Leaders signiert werden!

Mir war nicht klar, dass ich auf jeden Fall einen virtuellen Lead benutzen sollte...

Viele Grüße
Michael

martinp876 · 21 Mai 2016, 08:57:13

Ok, verstanden. Da hast du sicher recht und es kann so nicht bleiben, da es sich herheitsrelevant ist.
Koennte auch auf den alten SD zutreffen.
Ich werde es durchsehen und die entsprechenden readings überprüfen.

Ich für meinen Teil käme nicht auf die Idee ohne virtuellen lead zu arbeiten - wenn das Team aus mehr als einem besteht. Symetrie, Struktur und Wartung.... nee. Nur um ein virtuelles device zu sparen. Wenn virtuelle device eine Berechtigung haben dann hier.
Aber natürlich kann man anderer Ansicht sein