Hallo Liste,
da ich selbst nicht ganz sicher bin, ob das so richtig ist, bitte noch einmal zur Klärung bevor man es in die Wiki-Seite "AES Encryption" einträgt - der Text ist dort an manchen Stellen etwas unklar.
1. In einer VCCU kann man 3 verschiedene AES-Keys setzen, die Attribute dazu heißen hmKey, hmKey2 und hmKey3
2. Mit dem Befehl set <gerät> assignHmKey werden alle AES-Keys an das Gerät=Aktor übertragen. Kanalweise oder geräteweise ?
3. Mit dem Befehl set <gerät_kanal> sign on wird beim Aktorkanal die AES-Signatur angeschaltet - er fordert sie dann von jedem Sender (egal, ob es sich um die Zentrale oder einen Peer handelt) bei einem empfangenen Befehl an.
4.Welcher AES-Key vom Aktorkanal auf die Reponse des Senders passte, zeigt der Aktorkanal im Reading aesKeyNbr. Achtung, hier scheint eine Inkonsistenz in der Nummerierung vorzuliegen: Obwohl ich nur den ERSTEN hmkey gesetzt habe, behaupten alle Geräte(kanäle), es würde aesKeyNbr 02 verwendet.
Folgende Fragen sind für mich offen:
Wie kann man dafür sorgen, dass für ein bestimmtes Gerät ein bestimmter der 3 hmKeys verwendet wird?
Probiert jedes Gerät wirklich alle hmKeys aus, die ihm bekannt sind ?
LG
pah
Hallo,
Zitat von: Prof. Dr. Peter Henning am 04 Juli 2016, 17:07:44
1. In einer VCCU kann man 3 verschiedene AES-Keys setzen, die Attribute dazu heißen hmKey, hmKey2 und hmKey3
Ja
Zitat
2. Mit dem Befehl set <gerät> assignHmKey werden alle AES-Keys an das Gerät=Aktor übertragen. Kanalweise oder geräteweise ?
Nein, der Key mit dem höchsten Index wird übertragen. Der gilt fürs ganze Gerät. Ein Gerät kennt maximal zwei Schlüssel (HM Default, assigned) und benutzt immer nur den mit dem höchsten Index (HM Default: 00).
Zitat
3. Mit dem Befehl set <gerät_kanal> sign on wird beim Aktorkanal die AES-Signatur angeschaltet - er fordert sie dann von jedem Sender (egal, ob es sich um die Zentrale oder einen Peer handelt) bei einem empfangenen Befehl an.
Ja.
Zitat
4.Welcher AES-Key vom Aktorkanal auf die Reponse des Senders passte, zeigt der Aktorkanal im Reading aesKeyNbr. Achtung, hier scheint eine Inkonsistenz in der Nummerierung vorzuliegen: Obwohl ich nur den ERSTEN hmkey gesetzt habe, behaupten alle Geräte(kanäle), es würde aesKeyNbr 02 verwendet.
Der Wert in aesKeyNbr entspricht dem doppelten Index. Die Geräte fordern tatsächlich den doppelten Index an, liegt wohl daran, wie der Key intern im Gerät gespeichert wird. 02 ist der erste Benutzerschlüssel, 04 der zweite, ...
Zitat
Wie kann man dafür sorgen, dass für ein bestimmtes Gerät ein bestimmter der 3 hmKeys verwendet wird?
Nur den einen in der VCCU definieren und übertragen.
Ich würde davon aber abraten, da die IOs zwar 3 Schlüssel unterstützen (bis auf CUL, da sinds theoretisch 126), diese aber von eQ3 als current Key, old Key und temporary Key geführt werden.
-> 1 Key für die gesamte Installation. Mehrere Keys nur definieren, falls der Key geändert werden soll.
Zitat
Probiert jedes Gerät wirklich alle hmKeys aus, die ihm bekannt sind ?
Nein, nur den mit dem höchsten Index.
Viele Grüße
Michael
Hallo pah,
ich kann Dir zwar nicht alle Fragen beantworten, aber manche.
Zitat von: Prof. Dr. Peter Henning am 04 Juli 2016, 17:07:44
2. Mit dem Befehl set <gerät> assignHmKey werden alle AES-Keys an das Gerät=Aktor übertragen. Kanalweise oder geräteweise ?
Geräteweise. Von welchem Kanal dann jedoch AES-Signatur verwendet (angefordert) wird, steht auf einem anderen Blatt.
Zitat
3. Mit dem Befehl set <gerät_kanal> sign on wird beim Aktorkanal die AES-Signatur angeschaltet - er fordert sie dann von jedem Sender (egal, ob es sich um die Zentrale oder einen Peer handelt) bei einem empfangenen Befehl an.
Das kann man so pauschal nicht aussagen. Der Aktor entscheidet, bei welchem Befehl von welchem Sender er eine Signatur anfordert. Die Schaltsteckdose mit Meßkanal fordert z.B. bei eingeschalteter AES-Signatur bei einem einfachen Status-Request auf Kanal 1 keine AES-Signatur an. Bei einem "normalen" Schaltbefehl hingegen schon.
Zitat
4.Welcher AES-Key vom Aktorkanal auf die Reponse des Senders passte, zeigt der Aktorkanal im Reading aesKeyNbr. Achtung, hier scheint eine Inkonsistenz in der Nummerierung vorzuliegen: Obwohl ich nur den ERSTEN hmkey gesetzt habe, behaupten alle Geräte(kanäle), es würde aesKeyNbr 02 verwendet.
Der Empfänger gibt vor, auf welchem Index der erforderliche Key für die AES-Signatur liegt. Reading geteilt durch zwei ergibt den Index. Auf Index 0 liegt der fest implementierte Standardschlüssel.
Zitat
Wie kann man dafür sorgen, dass für ein bestimmtes Gerät ein bestimmter der 3 hmKeys verwendet wird?
Die Firmware des Aktors oder Sensors nimmt *immer* den Schlüssel auf dem zuletzt belegten Index. Die Firmware sieht m.W. nicht vor, mit verschiedenen Schlüsseln zu arbeiten. Ein mit einem aktuellen Schlüssel korrekt versehenes Gerät weist eine Signatur, die mit dem "alten" Schlüssel beantwortet wird, zurück bzw. fordert erneut an.
Zitat
Probiert jedes Gerät wirklich alle hmKeys aus, die ihm bekannt sind ?
Nein.
Edit: Michael, der Experte auf diesem Gebiet, war schneller 8).
Danke, ich werde das bei Gelegenheit in dem Wiki-Artikel präzisieren (es sei denn, jemand anders kommt mir zuvor).
LG
pah
Da stoße ich gleich mal mit ins Horn...
Ich habe mir folgendes gebastelt:
sub
addToAesFamily($){
my ($device) = @_;
fhem("set $device assignHmKey");
fhem("set $device sign on");
fhem("set $device getConfig");
}
Wenn ich das ausführe sollte das Gerät also z.B. mein HM-Sec-SC im Register sign auf on stehen oder nicht?
Wie träge ist das alles? durch das getConfig am Ende sollte es doch danach aktuell sein oder?
Das ist in der richtigen Reihenfolge.
Bei dem von Dir genannten Device wirst du aber wohl jeweils noch den Anlernknopf drücken müssen für jeden Befehl. Deswegen halte ich es nicht für sinnvoll, das in eine solche Sub zu bringen.
Stichwort: Wiki-Artikel präzisieren
Zum Thema AES konnte ich in den letzten Tagen/Wochen einige Infos zusammentragen. Diese Helfen ggf. bei der Aktualisierung des Wiki.
Da ich noch recht neu hier bin und es dabei einige Unstimmigkeiten gab, habe ich mich nicht selbst daran gemacht.
Hier die Links zu den Threads:
a) https://forum.fhem.de/index.php/topic,55101.0.html (https://forum.fhem.de/index.php/topic,55101.0.html)
b) https://forum.fhem.de/index.php/topic,55104.0.html (https://forum.fhem.de/index.php/topic,55104.0.html)
c) https://forum.fhem.de/index.php/topic,54939.0.html (https://forum.fhem.de/index.php/topic,54939.0.html)
d) https://forum.fhem.de/index.php/topic,43675.0.html (https://forum.fhem.de/index.php/topic,43675.0.html)
e) https://forum.fhem.de/index.php/topic,55133.0.html (https://forum.fhem.de/index.php/topic,55133.0.html)
Wie gesagt, vielleicht kommt ja dadurch mehr Licht ins Dunkel.
Schönes WE.
Gruß
Leeloo
Danke, aber bei mir ist schon Licht im Dunkel. ;D ;D
LG
pah
Mir ging es zwar eher um den Wissensstand aller Interessierten, dennoch "Nichts für Ungut " :D
Erwähnenswert wäre ja noch das Attribut aesCommReq.
Die Zentrale (FHEM) sollte es gesetzt haben, dann wird sie vom Sensor eine Bestätigung anfordern.
Verstehe es also als "sign on" der Zentrale...
Greets
Byte
Ja, in dem Zusammenhang gibt es nur noch eine kleine Unschärfe beim ConfigCheck.
siehe dazu: https://forum.fhem.de/index.php/topic,55101.msg468598.html#msg468598 (https://forum.fhem.de/index.php/topic,55101.msg468598.html#msg468598)
martinp876 ist aber bereits informiert und er fixt es wenn er Zeit dazu hat. :)
Schönes WE,
Gruß
Leeloo