Fragen zu AES: Zentrale <-> IO-Device

[Leeloo_Dallas]

Sorry, habe eine weitere Fragen zur AES und den Erläuterung im Wiki und er CommandRef.

Zusammenfassung:
Auszug Wiki A):

Zentrale <-> IO-Device
Homematic unterstützt AES auf dieser Strecke, dies ist in FHEM allerdings nicht implementiert. Nutzt man eine CCU(2) anstelle von FHEM als Zentrale, kann hier AES aktiviert werden. Wenn FHEM die Zentrale ist, muss im HMLAN Konfigurator die Netzwerkseitige AES-Verschlüsselung über die HM-PC-Software abgeschaltet werden, sonst kann FHEM nicht mit dem HMLAN Konfigurator kommunizieren.

Auszug Wiki B)

IO <-> Gerät
Dieses Teilstück kann mit AES gesichert werden. Es kann ein HMLAN Konfigurator, HM-CFG-USB USB Konfigurations-Adapter oder seit dem 28.6.2015 ein CUL-kompatibles Gerät genutzt werden

Auszug CommandRef C):

aesCommReq wenn gesetzt wird HMLAN/USB AES signature anfordern bevor ACK zum Device gesendet wird.
Die Funktion abeitet aktuell nur mit HMLAN/USB.

Fragen:
Wann gilt nun diese Aussage?
Auszug Wiki D):

Aktivieren, Einrichten, Umgang in FHEM
Die Zentrale kann ebenfalls eine AES-Signatur von einem Gerät anfordern, so sie einen Trigger empfängt. Hierzu ist im Device (und evtl. entsprechendem Kanal) eines Geräts das Attribut aesCommReq auf 1 zu setzen

Kann "aesCommReq 1 " nur gesetzt werden, wenn FHEM die Zentrale ist und HMLAN/USB verwendet werden, also nicht bei Einsatz von FHEM und einem CUL (z.B. Busware-CUL)?
Stimmt diese Restriktion noch ?

Gruß
Leeloo

[frank]

die cul-familie kann kein aes, sondern fhem übernimmt hier die aes-signierung.
eigentlich sollten alle aes-aspekte auch mit cul funktionieren.
allerdings sind timingprobleme mit cul grundsätzlich möglich, die durch zusätzliche aes-nutzung sicherlich nicht besser werden. 

mir scheint es, dass du eher ein theoretiker bist. ich würde es einfach probieren und schauen, ob es funktioniert. falls nicht, würde ich das forum nach "aesCommReq" durchsuchen, um zu sehen, ob es ein grundsätzliches problem damit gibt.

[Bytechanger]

Hallo,

also, Wiki A bezieht sich auf die Verbindung FHEM mit IO-Gerät, also HMLan / HM-Cfg-Usb / CUL, usw.
Hier findet KEINE Verschlüsselung statt. Ist i.d.R. auch nicht notwendig, da sich dieses Gerät im "vertrauenswürdigen" Netz befinden sollte (also direkt am FHEM-Gerät oder per Lankabel im heimischen Netz.

Ich habe beide Geräte über eine VCCU im Einsatz. Also einen CUL und eine HMLAN.
Dabei geht AES ganz gut.

Grundsätzlich funktioniert es so:
Gerät ist mit Zentrale (FHEM) gepairt.
Es meldet FHEM also einen Zustand, FHEM (sobald aesCommReq als Attribut gesetzt) fordert eine Bestätigung beim Gerät, das Gerät schickt eine AES-Signierte Bestätigung
FHEM setzt das mitgeteilte Ereignis um und Bestätigt dass auch dem Gerät, dass mit ACK reagiert (grüne Lampe bestätigt z.B. bei Fensteröffner).

Also aesCommReq befindet sich nur in FHEM und beeinflusst das Verhalten von FHEM.

Bei meinen Fensterkontakten sieht es ohne AES so aus, dass bei Zustandsänderung kurz das grüne LED leuchtet.
Ist AES aktiviert. Dann leuchtet es orange, während die Signaturprüfung in FHEM stattfindet, meldet FHEM OK zurück, leuchtet der Fensterkontakt dann grün.


Die Geräte können aber auch mit anderen Geräten gepeert werden. Dann läuft die Kommunkation anders (wie im auch im Wiki beschrieben), aber dass ist ja nicht Bestandteil der Frage.

Greets

Byte

[Leeloo_Dallas]

Hallo zusammen.

ich kann Euch beruhigen. Nein, ich bin wirklich kein Theoretiker. Grundsätzlich gehe ich pragmatisch an Aufgaben und Probleme heran.
Erst wenn ich mit der Praxis und der Theorie nicht mehr weiterkomme oder Unklarheiten und ggf. Wiedersprüche entdeckte, wende ich mich mit Fragen an andere.
Im speziellen Fall "FHEM-Forum" erst dann, wenn ich mir ganz sicher bin, dass ggf. auch andere von meinen Fragen und Anregungen profitieren können.

Zurück zur Theorie, um die Praxis für nachfolgende transparenter zu machen.
=> Text zur Ergänzung/Anpassung des Wiki
...
Grundsätzlich unterstützt die Zentrale (FHEM) alle AES-Aspekte. Also:
Zentrale <-> IO-Device
IO <-> Gerät
Gerät <-> Gerät
Einschränkung: Bei Verwendung eines CUL kann es zu Timeing-Problemen kommen. Ggf. ist genau zu Prüfen,  wann ein Gerät zwingend (z.B.: Alarm-/Sicherheit) mittels AES mit der Zentrale kommunizieren soll (siehe dazu atrr aesCommReq 1).
...

Stimmt es so?
Wenn es passt, dann rein ins Wiki. Es kann nur Helfen.

Gruß
Leeloo

[Otto123]

mir scheint es, dass du eher ein theoretiker bist.

Hallo Frank

kann aber auch sein, das in der commandref oder im Wiki noch etwas falsch/alt steht. Dann wäre es ja auch schön es zu korrigieren 

Immerhin konnte die cul Stick Family ja vor einiger Zeit noch gar kein AES, jetzt kann sie es immerhin mit Hilfe von FHEM 

Wiki ändern könnte ich machen ...
Allerdings ist die Aussage noch in der commandref für CUL_HM drin

aesCommReq wenn gesetzt wird HMLAN/USB AES signature anfordern bevor ACK zum Device gesendet wird.
Die Funktion abeitet aktuell nur mit HMLAN/USB.

Die müsste eventuell durch Martin geändert werden

Gruß Otto

[Leeloo_Dallas]

Ergänzung:  Vielleicht hilft diese Info zusätzlich.

Das Setzen von "aesCommReq 1" führt aktuell zur folgenden Meldung/Funktionsweise beim ConfigCheck:

Meldung:

Code Auswählen Erweitern

configCheck done:
aesCommReq set, IO not compatibel
    IR_KontaktHM__EG_Eingang
    IR_KontaktHM__EG_Kueche
    IR_KontaktHM__EG_Wohnzimmer
    RemoteHM_Leeloo
Funktion:
-die IR-Fensterkontakte melden Ihren Status.
-der Remote-Handsender kann keinen Schaltbefehl mehr absetzen.

[martinp876]

Aes zwischen cpu und io geht nicht.
Aes zwischen cul und device pruefe ich. Also aescomreq. Geht bei hmlan und usb.
Cul muss wie Otto gesagt hat nachgegogen werden.
Device zu device ist eh eine eq3 angelegenheit.

[Otto123]

Aes zwischen cul und device pruefe ich. Also aescomreq. Geht bei hmlan und usb.

Und dann wird ja die Frage aufkommen: HMUART? --> also HM-MOD-RPI-PCB und HM-LGW-O-TW-W-EU 
Jetzt wo es den HM-CFG-USB nicht mehr gibt? wird das ja zunehmend interessant.

[mgernoth]

Hi,

Aes zwischen cul und device pruefe ich. Also aescomreq. Geht bei hmlan und usb.

aescomreq mit CUL sollte funktionieren. Hat es zumindest damals, als ich es implementiert habe.

Und dann wird ja die Frage aufkommen: HMUART? --> also HM-MOD-RPI-PCB und HM-LGW-O-TW-W-EU 

Da gehts auch.

Viele Grüße
  Michael

[Leeloo_Dallas]

Hi,

CUL <-> Device ; also "aesCommReq 1" scheint nicht zu gehen, da ein ConfigCheck mit gesetztem

Code Auswählen Erweitern

attr xxx aesCommReq 1 z.Zt. zumindest bei folgenden Devices     
- HM-SEC-SCo
- HM-SEC-MDIR-2
- HM-RC-Sec4-2
ein

Code Auswählen Erweitern

aesCommReq set, IO not compatibel

meldet.

Schönes WE.

Gruß
Leeloo

[martinp876]

Dann ist es sicher nur der check, nicht das verhalten.
Wird bei gelegenheit korrigiert.

[Leeloo_Dallas]

=> Coding:
OK, Danke. Sag einfach Bescheid, wenn Du soweit bist.

=> Wiki:
Ich glaube wir hätten dann alle Infos zusammen und das Wiki könnte bereits dahingehend angepaßt/geändert werden.

[Leeloo_Dallas]

Moin zusammen,

da mit dem Software-Stand von heute noch keine Anpassung zu erkennen ist, wollte ich nochmals nachhacken damit es nicht in Vergessenheit gerät.
Kann jemand die Änderungen am ConfigCheck vornehmen?
Ich bin leider noch nicht soweit um hier eingreifen zu können.

LG
Leeloo