HM-SEC-SD-2 neu

[MarcelK]

ich nehme schwer an, dass das diesmal RFChannel::performCBCAuthentification(BidcosFrame&) ist (siehe rfd aus alter CCU2-FW).

IIRC war das so:

Code Auswählen Erweitern


x = 49 <sender> <empfaenger> xx yy zz 00 00 00 00 00 05
xx,yy,zz waren IIRC 3 andere Bytes aus dem Frame


Das ganze wird AES verschlüsselt, dann mit irgendwas ver-Xored und dann nochmal verschlüsselt. Mit was ver-Xored wurde, weiss ich nicht mehr, hab ich mir auch nicht aufgeschrieben damals

Ich hab das nicht weiterverfolgt, da ich dann (komplett ohne Disassembler) den "richtigen" Algorithmus gefunden hatte...

Dieses std::string verseuchte ARM C++ Compilat zu lesen ist ungefähr so witzig wie ne Wurzel-Behandlung. Ich hab ihn trotzden mal in Pseudo-Code umgeschrieben und immerhin stimmt er bisher mit Deinen Erkenntnissen überein  (xx=Frame[FrameSize - 6], yy=Frame[FrameSize -5], zz=Frame[0] (Länge?) BTW). Kann nur hoffen dass es auch wirklich was mit dem SD-2 zu tun hat... werd's checken sobald man mir mal ein paar vollständige Frames zeigt.

Beste Grüße, Marcel

[martinp876]

Kein Unterschied. Nur alarmon/off und teamcall funktionieren nicht.
Edit:
Repeat ist neu. Du kannst,wie in der Anleitung des SD beschrieben, Einige als Repeater konfigurieren. Eq3 beschränkt das in der Anleitung auf max 3 im Team. Sicher kann man mehr eintragen. Ich kann mir vorstellen, dass es zu Problemen mit der funklast führen kann, sollten 5 und mehr SDS anfangen zu wiederholen.
In hm configcheck ist die Prüfung noch nicht drin.

Ich halte es für sinnvoll (intelligent) ein template dafür zu erstellen. Warum? Ist doch nur ein Register? Weil ein template einfach zu verwalten, eine config Prüfung zulässt und eine Wiederherstellung ermöglicht.
Ich werde einen Vorschlag machen, evtl in wiki, mal sehen.

[Bytechanger]

Also, ich habe keinen Unterschied zu einem Teamleader des alten Teams, dort steht

Altes Team

Code Auswählen Erweitern

Internals:
   DEF        11111201
   NAME       Rauchmelder_Team
   NR         211
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   device     TeamDev
   peerList   OG_Flur_RM,K_Party_RM,K_Waesche_RM,
   sdTeam     sdLead
   Readings:
     2016-02-19 16:58:07   eventNo         0C
     2016-02-19 16:58:07   level           1
     2016-05-06 17:29:12   peerList        OG_Flur_RM,K_Party_RM,K_Waesche_RM,
     2016-02-19 16:58:07   smoke_detect    none
     2016-05-06 17:29:12   state           off
     2016-02-19 16:57:57   teamCall        from TeamDev:1
     2016-02-19 16:58:07   trigger_cnt     12
   Helper:
     fkt        sdLead
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Role:
       chn        1
       vrt        1
     Tmpl:
Attributes:
   alarmDevice Sensor
   alarmSettings alarm7,|Rauchmelder_Team:.*smoke-Alarm.*|RauchAlarm|on
   devStateIcon off:general_ok *:secur_alarm
   group      Rauchmelder Teamleader
   icon       secur_smoke_detector
   model      virtual_1
   peerIDs    3BCCCC01,3BCF0601,3BCF1301,
   room       Rauchmelder,Überall
   webCmd     teamCall:alarmOn:alarmOff

TeamLeader SD2

Code Auswählen Erweitern

Internals:
   DEF        11111301
   NAME       Rauchmelder_Team2
   NR         514
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   device     TeamDevSD2
   peerList   K_Treppe_RM2,OG_Anna_RM2,OG_Linus_RM2,K_Bastelkeller_RM2,OG_Schlafzimmer_RM2,OG_Maja_RM2,EG_Kueche_RM2,EG_Buero_RM2,EG_Wohnzimmer_RM2,
   sdTeam     sdLead
   Readings:
     2016-05-06 17:29:12   peerList        K_Treppe_RM2,OG_Anna_RM2,OG_Linus_RM2,K_Bastelkeller_RM2,OG_Schlafzimmer_RM2,OG_Maja_RM2,EG_Kueche_RM2,EG_Buero_RM2,EG_Wohnzimmer_RM2,
     2016-05-07 08:47:48   state           off
   Helper:
     fkt        sdLead
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Role:
       chn        1
       vrt        1
     Tmpl:
Attributes:
   alarmDevice Sensor
   alarmSettings alarm7,|Rauchmelder_Team2:.*smoke-Alarm.*|RauchAlarm|on
   devStateIcon off:general_ok *:secur_alarm
   group      Rauchmelder Teamleader
   icon       secur_smoke_detector
   model      virtual_1
   peerIDs    47316A01,47343701,487DB901,487EBB01,487F0B01,487F9B01,4882DA01,48F0F801,48FDC801,
   room       Rauchmelder
   webCmd     teamCall:alarmOn:alarmOff

Daher verstehe ich es nicht??
Dort ist Kein smokeDetect...

Greets

Byte

[martinp876]

Werde ich prüfen. Ich habe einen alarm ausgelöst, der wird vom Team gemeldet. Damit wird er entsprechend verarbeitet. Da ihr dies wahrscheinlich nicht gemacht habt kommt da auch nichts.
Ich werde wohl den zustand aller Mitglieder prüfen müssen um den zustand des Teams abzubilden.
Wenn ein alarm kommt sollte es funktionieren auch bei einem Test. Schon gedrückt?

[Bytechanger]

OK, dass wars!
Kommunikationstest durchgeführt, jetzt steht da auch smokeDetect!
Ist etwas verwirrend.
Danke!

Greets

Byte

[Bytechanger]

Ist es richtig, dass beim Reichweitentest ein "smoke-Alarm" im notify erscheint?
Bei mir ist beim Reichweitentest nun der volle Alarm an SMS, WhatsApp, etc rausgegangen, da
das notify: .*smoke-Alarm.* gegriffen hat!

Greets

Byte

[martinp876]

Bin gerade am überarbeiten. Es sind noch Funktionen des alten SD genutzt worden insbesondere wenn man den virtuellen lead genutzt hat.
Kommt heute noch ein Update.

so, ist eingechecked
Hier auch mein Vorschlag für ein Template welches den Repeater steuert.

Code Auswählen Erweitern

set hm templateDef sd2Rep repeat "SD2 setup repeater (1) or not (0)" devRepeatCntMax:p0
set hm templateSet sd4 sd2Rep 0 0
set hm templateSet sd5 sd2Rep 0 1


also sd4 ohne, sd5 mit repeater.

[MarcelK]

ich nehme schwer an, dass das diesmal RFChannel::performCBCAuthentification(BidcosFrame&) ist (siehe rfd aus alter CCU2-FW).

Hallo Michael,

Treffer Ich kann jetzt zumindest bestätigen dass Martins Beispiel mit dem Default-Key und dem CBC Mechanismus signiert wurde. Fraglich sind weiterhin die Bytes "00 03" vor der Signatur. Sie sind Teil des IV, aber werden ansonsten soweit ich das sehe nicht ausgewertet. Key-Nummer find ich daher fraglich. Aber mangels weiterer Beispiele und Hardware muss der Rest der Analyse warten.

Besten Gruß, Marcel

[mgernoth]

Hi Marcel,

Treffer Ich kann jetzt zumindest bestätigen dass Martins Beispiel mit dem Default-Key und dem CBC Mechanismus signiert wurde.

Super, klasse

Fraglich sind weiterhin die Bytes "00 03" vor der Signatur. Sie sind Teil des IV, aber werden ansonsten soweit ich das sehe nicht ausgewertet. Key-Nummer find ich daher fraglich.

Ich nehme an, dass das ein Counter ist. Da gibts irgendwelche get/set CBC counter Methoden.

Aber mangels weiterer Beispiele und Hardware muss der Rest der Analyse warten.

Ich kann Beispiele liefern, die sind aber mit meinem Key signiert...
Kannst Du mir bitte evtl. den Algorithmus zukommen lassen (oder irgendwo beschreiben)?

Viele Grüße
  Michael

[MarcelK]

Kannst Du mir bitte evtl. den Algorithmus zukommen lassen (oder irgendwo beschreiben)?

Hallo Michael,

alles klar, ich hab meine Arbeit jetzt mal hier beschrieben: http://www.kilgus.net/2016/05/10/homematic-cbc-authentication/. Der Algorithmus steht für Ungeduldige am Ende

Viel Spaß, Marcel

[Bytechanger]

Oh,
klingt gut und hört sich an, als gäbe es bald eine Lösung zum Problem....

@martin876:  Das Repeater template verstehe ich nicht. Gibt es dazu noch eine Beschreibung?
Was ist mit "Template gemeint" ?

Code Auswählen Erweitern

Hier auch mein Vorschlag für ein Template welches den Repeater steuert.

Code: [Auswählen]

set hm templateDef sd2Rep repeat "SD2 setup repeater (1) or not (0)" devRepeatCntMax:p0
set hm templateSet sd4 sd2Rep 0 0
set hm templateSet sd5 sd2Rep 0 1
also sd4 ohne, sd5 mit repeater.

Stellt man damit über FHEM den Templatemodus ein und aus und kann ihn überwachen??


Greets

Byte

[mgernoth]

Hallo Marcel,

alles klar, ich hab meine Arbeit jetzt mal hier beschrieben: http://www.kilgus.net/2016/05/10/homematic-cbc-authentication/. Der Algorithmus steht für Ungeduldige am Ende

Wow, super. Vielen Dank

Ich habe das ganze mal schnell implementiert und ein paar Tests durchgeführt, wobei ich einen TeamCall auslösen und beenden konnte.

Dabei habe ich festgestellt, dass die zwei Bytes vor dem Ciphertext definitiv ein Replay-Counter sind. Meine SD-2 reagieren auf Kommandos nur, wenn der Counter höher als der zuletzt gesehene Counter eines Absenders (der in diesem Fall im Empfänger-Feld steht) ist.

Ich habe mal meine Perl-Implementierung angehängt, evtl. kann Martin da Teile übernehmen.

Viele Grüße
  Michael

[MarcelK]

Dabei habe ich festgestellt, dass die zwei Bytes vor dem Ciphertext definitiv ein Replay-Counter sind. Meine SD-2 reagieren auf Kommandos nur, wenn der Counter höher als der zuletzt gesehene Counter eines Absenders (der in diesem Fall im Empfänger-Feld steht) ist.

Gut, das deckt sich dann mit der Zeile

Code Auswählen Erweitern

if (iv <= this->AesCbcCounter) return 0; und macht auch Sinn. Die Frage ist dann natürlich wie man den Counter bootstrapt. Z.B auch wenn ein neuer SD-2 zur Gruppe hinzugefügt wird. Der muss ja dann auch wissen welche Zahl gerade aktuell ist.
Die CCU2 sichert den Wert in RFChannel::SaveToXml als "aes_cbc_cnt", der Initialwert wird im RFChannel Constructor auf "1" gesetzt, das dürfte vermutlich aber eh irgendwann überschrieben werden. Der Rest ist dummerweise nicht so einfach zu lesen und jetzt steht leider erstmal wieder bezahlte Arbeit an Vielleicht hast Du ja noch ne Idee.

Viele Grüße, Marcel

[mgernoth]

Hi,

Die Frage ist dann natürlich wie man den Counter bootstrapt. Z.B auch wenn ein neuer SD-2 zur Gruppe hinzugefügt wird. Der muss ja dann auch wissen welche Zahl gerade aktuell ist.

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.

Die anderen Geräte der Gruppe waren schon bei Counterwerten >= 3 und haben trotzdem meine Befehle akzeptiert.

Die CCU2 sichert den Wert in RFChannel::SaveToXml als "aes_cbc_cnt", der Initialwert wird im RFChannel Constructor auf "1" gesetzt, das dürfte vermutlich aber eh irgendwann überschrieben werden.

So etwas muss Fhem jetzt wohl auch machen. Es muss sich einen globalen Replaycounter (in der VCCU?) für eigene zu sendende Frames merken und die zuletzt gesehenen Werte der einzelnen Geräte in den jeweiligen Geräten.

Viele Grüße
  Michael

[Depechem]

Hallo @all.
Ich wollte die programmierer unter euch mal fragen.

Wird es auf absehbare Zeit(oder überhaupt) möglich sein die Alarme der SD-2 per FHEM zu quittieren(abzuschalten). So bin ich es von den SD gewöhnt und dies finde ich optimal.
Ich muss mir die nächsten 2 Wochen 3 neue Rauchmelder besorgen. Wenn möglich sollte der funktionsumfang mit fhem und dem Rauchmleder ähnlich dem alten SD sein.

Vielen Dank im voraus
Gruß Thomas