CUL / Homematic und AES

Begonnen von Leeloo_Dallas, 24 Juni 2016, 16:40:18

Vorheriges Thema - Nächstes Thema

Leeloo_Dallas

Hallo zusammen,

da der grundsätzliche Rahmen für meine Alarmanlage (https://forum.fhem.de/index.php/topic,54292.0.html) fertig ist und bereits über mehrere Wochen stabil läuft, würde ich jetzt gerne die AES-Encryption der zugeordneten Homematic-Komponenten nutzen und diese aktivieren.
Beim Einlesen in die Thematik sind jedoch noch ein paar Fragen offen, über die ich mich gerne austauschen würde.

Zur besseren Einordnung:
- FHEM läuft auf einem RaspPi mit einem Busware-CUL
- Integriert werden sollen fürs erste die Homematic- Fensterkontakte, -Handsender
- einen eigenen kmKey habe ich bisher nicht vergeben

zu den Fragen:
A)
Im Wiki steht:
ZitatAb Werk ist ein einheitlicher Standard-Schlüssel hinterlegt. Dieser ist in allen HM-Geräten gleich und muss somit vom User geändert werden um einen sinnvollen Schutz zu erreichen.
a1) Wo und in welcher Form ist dieser Standard-Schlüssel bei den HM-Devices hinterlegt bzw. für mich einzusehen/ersichtlich?
a2) Muss ich diesen Schlüssel kennen, um einen eigenen Schlüssel einzutragen?

B)
Im Wiki steht:
ZitatDer System-Schlüssel wird von der Zentrale bzw. dem HMLAN Konfigurator auf alle gepairten HomeMatic Geräte verteilt
aber auch
ZitatDer erste Schritt ist, einen Schlüssel (key) zu vergeben und ihn in alle gepairten Geräte zu übertragen.
b1) Wird der Schlüssel nach dem Setzen an alle Geräte übertragen?
b2) Auch an die, die nichts mit der Alarmanlage zu tun haben?
b3) bzw. wie ist die erste Aussage jetzt genau zu verstehen?

C)
Laut Wiki können drei Schlüssel vergeben werden  (hmKey hmKey2 hmKey3).
c1) Kann mir jemand ein Beispiel nennen, wann 3 Schlüssel benötigt werden?
c2) Bzw. wenn ist es sinnvoll all diese Schlüssel zu nutzen?

Schon mal Danke für Feedback.

Gruß
Leeloo
Greatz Leeloo

Leeloo_Dallas

Da bisher kein Feedback kam, habe ich die Fragen nochmals präzisiert.
Greatz Leeloo

LuckyDay

a1 , nicht ersichtlich , aber bekannt im Internet
a2 , beim erstmaligen ändern nicht, aber wenn du deinen eigenen setzt und du vergisst ihn, kannst du nicht mehr ändern, das ist die gefahr bei erwerb von gebrauchten device , wo der schlüssel nicht bekannt ist. da hilft nur einschicken zu elv, gegen bares ändern die wieder auf orginal.

Leeloo_Dallas

@fhem-hm-knecht => Danke !!!

Besonders die Antwort auf "a2" hilft weiter, denn ich wollte nicht einfach so loslegen ohne genau zu wissen was ich da tue.

Kennst Du auch die Antworten zu "B" und "C".

THX

Greatz Leeloo

Bennemannc

Hallo,

Zu B) bei Fhem musst Du den Schlüssel aktiv übertragen, das passiert nicht automatisch. Ich habe auch ein "Mischsystem" wichtiges läuft mit eigenen Schlüssel, das andere mit Standard. Es können (soweit ich weiß) auch nicht alle HM Geräte AES.

Zu C) benötigt wird eigentlich nur einer. Wenn es mehrere gibt, kann das die Zentrale bzw. das Gerät auswählen welchen es sendet.

Gruß Christoph
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

Leeloo_Dallas

Ok, Danke für die Antworten. Jetzt ist das Bild klarer.


Vorschlag:
Zur besseren Verständlichkeit, wäre es sinnvoll diesen Satz im Wiki anzupassen.

von:
ZitatDer System-Schlüssel wird von der Zentrale bzw. dem HMLAN Konfigurator auf alle gepairten HomeMatic Geräte verteilt.

in:
ZitatDer System-Schlüssel kann von der Zentrale bzw. dem HMLAN Konfigurator, nach manueller Auswahl, auf die ausgewählten und gepairten HomeMatic Geräte verteilt werden.

Andere Vorschläge?
Greatz Leeloo

Bytechanger

Es gibt doch ausgiebige Wiki-Beiträge (hmKey erstellen, übertragen, etc.)
Ich habe mich für meine Alarmanlage auch eingelesen.
Ich nutzte ebenfalls Fensterkontakte und nutze AES.

Übrigens es ist KEIN encryption! Die Befehle werden in Klartext übertragen, die Zentrale oder das Gerät fordern eine Signatur an, die über AES erstellt wird.
Stimmt die Signatur überein, wird der Befehl aktzeptiert, sonst verworfen!
Kein encryption! Jeder kann mitlesen welche Befehle übertragen werden...


Greets

Byte


Leeloo_Dallas

Wenn man sich meinen Beitrag sachlich durchliest, dann erkennt man recht schnell, dass ich mich eingelesen habe.
Auch erkennt man, dass ich aktiv daran mitarbeiten will, dass sich FHEM und das dazugehörige Wiki verbessert.
Ich motze nicht herum oder benehme mich irgendwie daneben. Ich will nur im Rahmen meiner Möglichkeiten helfen.

Das Wort (Encryption) habe ich nun aus der Überschrift meines Beitrags gelöscht. Das Wort war an dieser Stelle falsch und irreführend.

Es wäre schön, wenn Ihr beim Rest (Wiki etc.) auch konstruktive Diskusionen zulassen würdet.
Aus der aktuellen Reaktion nehme ich und ggf. auch andere mit, dass Fragen und Anregungen nur dann gemacht werden dürfen, wenn diese mit einem perfekten, theoretische sowie praktischen Hintergrund getroffen und bei Diskusionen fehlerfrei wiedergegeben werden.
Ob dadurch der kompletten Fhem-Gemeinschaft geholfen ist, ist fraglich.

Gruß
Leeloo
Greatz Leeloo

Grinsekatze

Ich gebe auch mal meine 50 Cent dazu - korrigiert, wenn ich irre.

Zum Thema FHEM/HM AES gibt's im Wiki ein guten Beitrag, der es ausführlich beschreibt (http://www.fhemwiki.de/wiki/AES_Encryption).

Ich habe selbst ein HMLAN und keinen CUL - vom Prinzip her ist das jedoch egal. Den HMLAN kaufte ich, da der CUL zu dieser Zeit noch nicht verschlüsselt mit etwa einer Key,- WinMatic oder den Rauchmeldern kommunizieren konnte. Das ist aber beim CUL offenbar inzwischen dank eines Firmware-Updates obsolete.

Wie schon zuvor erwähnt, ist FHEM nicht fähig AES-Encryption zu nutzen - der HMLAN prinzipiell schon. Daher muss man das ja auch bei Verwendung deaktivieren, damit ein HMLAN mit FHEM klappt.
Was Du ansprichst ist, wie erwähnt die Signierung, welche AES verschlüsselt ist. Dies wird von einigen HM-Komponenten benötigt (u.a. s.o.)

Um auf deine Fragen einzugehen:
Der Standard-AES-Key steht, zumindest beim HMLAN (und ich gehe auch davon aus, beim HMUSB) auf dem Gerät drauf - auf einem Aufkleber. Dieser Schlüssel gilt als unsicher, da er immer der selbe ist. So ist es relativ einfach, in Dein System einzudringen. Und wenn man erstmal drin ist, dann gibt es in der Regel immer irgendwo eine Möglichkeit auch die nächsten Türen aufzustoßen (aber das jetzt auszuführen ginge zu weit). Daher halte ich auch nichts von einem Mischbetrieb mit teils Standard und teils eigenem Key - abgesehen dass es keinen Sinn macht. Daher wird empfohlen, einen eigenen zu vergeben. Beim HMLAN geht es entweder mittels Windows-Software oder aus FHEM heraus durch Setzen eines weiteren Keys (attr HMLAN1 hmKey1 xxxxxx). Diesen darf man jedoch nicht verlieren / vergessen!

Es ist Sinnvoll / Notwendig, nach Vergabe eines neuen Schlüssels (z.B. hmKey1) die Geräte auch explizit anzuweisen, diesen neuen Schlüssel zu verwenden. Dabei verwenden natürlich alle Geräte diesen Schlüssel, sofern sie ihn benötigen. Dabei ist es egal, ob Du sie für eine Alarmanlage oder zu was auch immer benutzt.

Ich selbst halte nichts von 3 Schlüsseln! Temporär sind 2 notwendig, wenn Du den Schlüssel im laufenden Betrieb ändern willst. So benutzen die Geräte den alten und stellen nach und nach auf den neuen um (das passiert bei HM ja nicht alles auf einmal sondern in Abständen). Danach könnte man sicherlich den alten auch löschen.

Das Umstellen kann auf mehrere Arten erfolgen:
- Zu Beginn. Dann werden alle Geräte auf den verwendeten Key angelernt.
- Im Laufenden Betrieb: Der Key wird geändert und alle Geräte neu angelernt / gepaired (extrem mühselig).
- Im Laufenden Betrieb: Es wird ein weiterer Key vergeben. Die bereits vorhandenen Geräte werden angewiesen diesen Key zu nutzen / umzustellen. Neue Geräte werden auf den neuen Key gleich angelernt.

Leeloo_Dallas

#9
@Grinsekatze: Danke für die ausführlichen Erläuterungen.
So wird das allgemeine Verständnis zu diesem Themengebiet für viele Leser sicherlich verbessert.

Meine bisherige Interpretation zum Thema deckt sich (Stand heute) zumindest mit Deiner :)

Dass in Summe noch nicht alles klar ist/war zeigen u.a. die Verläufe dieser Threads:
- https://forum.fhem.de/index.php/topic,55101.0.html
- https://forum.fhem.de/index.php/topic,55104.0.html

Den letzten Absatz Deiner Erläuterungen,
Zitat- Im Laufenden Betrieb: Es wird ein weiterer Key vergeben. Die bereits vorhandenen Geräte werden angewiesen diesen Key zu nutzen / umzustellen. Neue Geräte werden auf den neuen Key gleich angelernt.
interpretiere ich nun (Stand heute) wie folgt:

Diese Vorgehensweise könnte ein User z.B. verwenden, wenn er mit geringem Aufwand den Default-Key aus seinem System "verbannen/entfernen" möchte.
Konkreter:
1) Er vergibt eine zweite Key-Definitionen. d.h. die bestehende Definition wird um eine weitere ergänzt.
attr VCCU hmKey geheimerSchluessel
attr VCCU hmKey2 geheimerSchluessel

2)durch diese Änderung gilt nun
a) alle Geräte mit einem gesetzten "Sign=on" erhalten quasi "automatisch", Sprich "ohne eigenes zu-tun", irgendwann den "hmKey2". Das macht FHEM automatisch.
b) alle "alten" Geräte die bisher kein "Sign=on" gesetzt hatten, können mit:
set Geraet sign on
für die AES-Signatur aktiviert werden. Danach erhalten diese ebenfalls irgendwann automatisch den "hmKey2".
c) Neue Geräte werden gleich auf den neuen hmKey2 angelernt; diese müssen jetzt nur auf "sign=on" gesetzt werden, wenn ein weitere Sicherheitsaspekt hinzukommen soll.

Zusätzlich gilt:
Die manuelle Eingabe von
set Geraet assignHmKey
kann zusätzlich für die Verteilung des neuen "hmKey2" genutzt werden. (ggf. wird der Prozess dadurch beschleunigt).
Greatz Leeloo

joshi04

Dass die Beschreibung im Wiki noch Potential hat, bei Allem um den Begriff "AES" (ob nun zwischen FHEM und HMLAN oder zwischen HMLAN und HM-Device), habe ich ebenfalls bereits festgestellt, mich da aber noch nicht rangetraut. Ein Grund dafür denke ich, ist das ungenaue Wording, dass ein und der selbe Begriff teilweise unterschiedlich verwendet wird, bzw. es für eine "Sache" mehrere Begriffe gibt. -> Dadurch nicht trivial und immer nur im Kontext zu verstehen. Das ist erstmal nur mein Eindruck aus der Erinnerung, da ich mich derzeit aktuell explizit nicht eingelesen habe (und auch nicht in die beiden Threads geschaut habe). Es müsste aber bereits alles Beschrieben sein, einmalig oder an mehreren Stellen verteilt.

Meine Empfehlung wäre, in der Beschreibung und Verwendung von Begrifflichkeiten sehr klar und deutlich ggf. mit Anführungszeichen zu sein und definitiv keine neuen Begriffe einzuführen als die, die auch z.B. die HM-Verwaltungssoftware (dieses ist garantiert nicht die richtige Bezeichnung) verwendet werden.
Ich hatte mich hier https://forum.fhem.de/index.php/topic,47739.msg395516.html#msg395516 ebenfalls schon einmal daran versucht, aber die Büchse "Wiki" dazu noch nicht aufgemacht, da ich hier deutlich mehr Potential sehe, auch was die gesamte Struktur der Thematik HM angeht. Ist derzeit halt gewachsen.
Allerdings glaube ich, dass es etwas komplexer ist als von Grinsekatze beschrieben. Ist der Schlüssel auf dem Aufkleber wirklich immer derselbe? Ich dachte, der Schlüssel für die AES-Signierung der Nachrichten zwischen I/O-Device und HM-Device wäre von Haus aus immer gleich, sonst würde der Aufkleber doch auch keinen Sinn ergeben und den braucht man ggf. für die Kommunikation der Win-Software mit dem HMLAN, um den anderen Schlüssel überhaupt erst konfigurieren zu können.

OT:
Zitat von: Leeloo_Dallas am 30 Juni 2016, 12:33:58
Aus der aktuellen Reaktion nehme ich und ggf. auch andere mit, dass Fragen und Anregungen nur dann gemacht werden dürfen, wenn diese mit einem perfekten, theoretische sowie praktischen Hintergrund getroffen und bei Diskusionen fehlerfrei wiedergegeben werden.
Bitte fühle Dich nicht sofort angegriffen, auch wenn der Umgangston hier im Forum manchmal etwas rauher ist. Die Thematik ist mM ziemlich komplex und aus einem Post kann nie hervorgehen, auf welchem Wissensniveau sich der Autor bereits bewegt.
Ich sehe das immer als sportliche Herausforderung, erst wenn es keine Kritik mehr gibt, ist die Lösung auch eine gute. Aber das ist wohl auch ein gesellschaftliches Problem, denke ich.
FHEM und das Wiki braucht immer tatkräftige Helfer. Und gute Dokumentation muss wachsen und kann nie im 1. Schuss perfekt sein. Also dran bleiben. :)
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU

Leeloo_Dallas

#11
@joshi04: Danke für Deinen Einsatz

Da der Umgangston hier im Forum manchmal wirklich recht rau ist und auch des öfteren sehr elitär wirkt, wollte ich nur mal eine Lanze für die restliche Gemeinschaft brechen. Es können nicht alle zur Elite gehören und es kann nicht sein, dass deshalb der Druck für den Rest so groß wird, dass man sich nicht traut etwas zu schreiben.
Zitat...,, mich da aber noch nicht rangetraut.

Also keine Angst, noch sehe ich das sportlich, sonst wäre ich nicht mehr dran bzw. hier aktiv.
Auf gute Zusammenarbeit,

Gruß
Leeloo


Nachtrag:
Da seit 2 Wochen keine Rückmeldung/Korrektur gekommen ist, scheinen die Info im Thread wohl "reif fürs Wiki" zu sein.
Danke nochmals für die Unterstützung !!!

Greatz Leeloo

achim-e

Hi,

ich muss nochmal das Thema hochholen, irgendwie bekomme ich es bei mir nicht hin.

Ich habe einen CUL 868MHz USB-Stick an meinem Pi und in FHEM eine entsprechende VCCU definiert. Türkontakte und Bewegungsmelder sind mit der VCCU gepairt.

Die Devices, bei denen Sign:on ist, habe ich zunächst gecheckt, bei allen steht das Reading aesKeyNbr auf 00. Ist ja auch klar, da dies ja der Standard-AES-Key ist. Da im Reading laut Wiki der doppelte Wert drin steht, müsste also der Standard-Key die 0 haben.

Nun habe ich wie im Wiki beschrieben, mittels attr VCCU hmKey geheimerSchluessel einen neuen Schlüssel gesetzt. Ich gehe mal davon aus, dass dies dann der Key 1 ist. Nun habe ich bei den Devices mit set Geraet assignHmKey den neuen Key setzen wollen (sprich, pro Homematic-Device einmal den Befehl absetzen). Leider ändert sich auch nach ein paar Stunden das Reading aesKeyNbr nicht. Es bleibt auf 00, erwartet hätte ich (wegen Key 1) aber 02.

Mache ich etwas falsch? Ist hmKey ggf. der Standard-Code? Dann verstehe ich aber das Reading aesKeyNbr nicht so ganz (welche Werte sind denn dann dort gültig?).

Danke und viele Grüße
Achim

achim-e

Ich antworte mir mal selbst. Nach vielem Suchen habe ich gelesen, dass es anscheinend doch nicht 100% so geht wie es im Wiki beschrieben ist. Wenn ich nichts überlesen habe, fehlt im Wiki beim Punkt "Geräte" etwas Entscheidendes. Aktuell steht dort:
ZitatEine AES-Signatur muss vom Empfänger angefordert werden. Dementsprechend wird die Nutzung auch dort aktiviert. Dies wird durch das Setzen des Registers sign auf on erreicht, wobei es für jeden Kanal des Geräts separat gesteuert wird.
set Geraet sign on

Ist das Register aber schon auf on bevor der Schlüssel vergeben wird, muss man dieses nach der Umstellung manuell nochmal auf off stellen und dann wieder auf on. Erst danach stellen sich die Devices um auf den neuen Code!
Entsprechend wäre eine Ergänzung direkt nach  obiger Stelle aus dem Wiki:
ZitatBitte beachten: Steht das Register sign bereits auf on, so muss dieses vorher auf off gesetzt werden. Ansonsten wird der neue Code nicht übernommen!
set Geraet sign off

Leeloo_Dallas

Leider  bist Du nicht der einzige der darüber gestoplert ist. :(

(siehe dazu u.a. auch: https://forum.fhem.de/index.php/topic,55357.msg469966.html#msg469966 )

Gruß
Leeloo
Greatz Leeloo