Erfahrungsbericht: Umstellung auf lokale Schlüssel vermittels hmip_user.conf

[hce]

Da mich das Thema Rekeying ja schon lange beschäftigt, habe ich nun endlich eine meiner zwei Installationen auf lokale Keys bzw. Keys in Software umgestellt, wie in viewtopic.php?f=31&t=78091 beschrieben, und möchte nun mal meine Erfahrungen beschreiben.

Zunächst mal, es handelt sich zwar um eine produktiv genutzte Installation, aber nur eine kleine, mit deren Ausfall ich umgehen kann. Da mir bis heute nicht klar ist, was bei diesem "Rekeying" passiert, habe ich ein paar Tests durchgeführt. Ich habe mir zu diesem Zwecke eine zweite CCU3 gekauft und Raspberrymatic darauf installiert.

0. Ich habe unmittelbar zu Beginn meiner Tests ein Backup der CCU angelegt.

1. Ich habe auf dei originale CCU3 eine hmip_user.conf angelegt und dort lokale, (hoffentlich ausreichend) zufällig generierte Keys eingetragen und die CCU neugestartet. Die Folge war, dass die CCU mit sämclichen HmIP-Geräte nicht mehr kommunizieren konnte. Ich habe mindestens 10 Minuten gewartet, innerhalb derer kein einziges HmIP-Gerät erreichbar war.

2. Ich habe das zuvor angelegte Backup wieder eingespielt und die CCU neu gestartet. Daraufhin konnte die CCU problemlos mit den Geräten kommunizieren.

3. Ich habe wieder Schlüssel in hmip_user.conf angelegt und ein Backup angefertigt, dann die Datei wieder entfernt. Ich habe auf der neu gekauften CCU3 das so angefertigte Backup incl. Keys in hmip_user.conf eingespielt. Die HmIP-Geräte wurden daraufhin *nicht* erkannt.

4. Ich habe der neuen CCU Zugang vollen zum Internet freigegeben, neugestartet und gewartet. Die HmIP-Geräte konnten trotzdem nicht erkannt werden.

5. Ich habe die neue CCU komplett resettet, eine frische hmip_user.conf angelegt, wieder mit frischen Schlüsseln. Dann habe ich die sgtin.map angelegt und mit via Smartphone gescannten SGTIDs+DLKs (Device Local Keys) gefüllt. Dann die CCU wieder neu gestartet.

6. Ich habe die HmIP-Aktoren und -Sensoren zukzessive resettet und an die neue CCU neu angelernt.

7. Nachdem alle Aktoren an die neue CCU angelernt waren, habe ich die alte CCU wieder gestartet, incl. Internetzugang und geschaut, was passiert. Ein Rekeying fand nicht statt; zumindest waren die Geräte auch nach längerer Wartezeit nicht mehr erreichbar.

8. Ich habe die neue CCU wieder in Betrieb genommen, hier waren die Geräte nach wie vor erreichbar.

9. Ich habe die neue CCU gebackupt und das Backup in die alte eingespielt. Die alte CCU hatte hierbei keinen Internetzugang. Beim Einspielen des Backups kam die Fehlermeldung, dass die Keyserver unbekannt seien. Ich habe die alte CCU anschließend gebootet, das Backup war trotzdem eingespielt. Die HmIP-Geräte waren von der alten CCU aus nun erreichbar. -> Erfolg!

10. Ich habe die neue CCU gestartet und die Geräte waren auch von hier aus noch erreichbar.

Nun steht mir das gleiche für die große Installation bevor.

=> Ich würde mir einen dicken, fetten Hinweis beim Raspberrymatic-Download wünschen, dass man mit den Backups alleine ohne Cloud nichts anfangen kann. Oder, die hmip_user.conf-Funktionalität direkt aktiviert.

[hce]

Heute habe ich noch einen kleinen Versuch mit der kleinen meiner beiden HmIP-Installationen (s.o.) durchgeführt:

Kurz zur Begrifflichkeit: "Schlüssel in Software" meint, dass die Schlüssel auf der CCU3 in Konfigurationsdateien liegen; Schlüssel in Hardware meint Schlüssel, die im Funkmodul liegen.

Ich hatte diese Installation ja auf CCU3 A laufen, ganz normal, mit Schlüssel in Hardware (ohne angelegte hmip_user.conf). Von dieser Installation habe ich tägliche Backups. Vor ein paar Tagen habe ich ja Keys in Software gesetzt (in hmip_user.conf) und alle Sensoren/Aktoren auf CCU3 B angelernt. Dann zum Test CCU3 B gebackupt und dieses Backup in CCU3 A eingespielt.

Heute habe ich folgenden Versuch gemacht:

Ich habe ein zwei Wochen altes Backup von CCU3 A auf CCU3 B eingespielt. Dieses Backup ist *vor* der Umstellung auf Schlüssel in Software. Die CCU3 B hatte den ganzen Versuch über vollen Internetzugang. Die CCU3 B habe ich zunächst resettet. Beim anschließenden Einspielen des alten Backups musste die CCU3 B erkennen, dass das Backup mit anderen Hardware-Keys (denen von CCU3 As Funkmodul) durchgeführt wurde. Also ist anzunehmen, dass sie beim Prüfen des Backups die eQ3-Keyserver kontaktiert hat, jedenfalls hat der Check recht lange gedauert (mehrere Minuten) Anschließend kam das "ok", Backup kann eingespielt werden. Ich bestätigte, und das Backup wurde eingespielt.

Die CCU3 B bootete wenige Minuten später wieder. Auffällig war, dass das Booten sehr lange gedauert hat, fast 5 Minuten. In dieser Zeit konnte ich mich auch per ssh nicht auf der CCU3 B einloggen. Danach kam das System vollständig hoch. Ich habe 12 Minuten lang versucht, beliebige HmIP- Aktoren zu steuern, das misslang. Anschließend habe ich wieder das aktuellste Backup eingespielt, und prompt konnten sämtliche HmIP-Aktoren und Sensoren wieder angesprochen werden. Das (vermutlich) versuchte und gescheiterte Rekeying hat also nichts "kaputt gemacht".

Mein Fazit: Es scheint einiges dafür zu sprechen, dass der Hersteller mit seiner Aussage, dass er einen für den Reset gesperrten Aktor/Sensor nur vermittels neuerlichem Aufspielen der Firmware, nicht jedoch OTA entsperren kann, die Situation korrekt geschildert hat.

Ich vermute, in den Backups sind die DLKs der Aktoren/Sensoren drin, sowie langlebige Session-Keys. Diese Session-Keys nützen dann erstmal nichts ohne die FLKs im Funkmodul, oder alternativ ohne die ("Master"-)Keys in Software, die man in hmip_user.conf schreibt. Da durch das Neu-Anlernen der Sensoren/Aktoren aber zwischenzeitlich neue Session Keys ausgehandelt worden sein dürften, halfen die alten Session-Keys+Herstellers Rekeying-Server nicht mehr weiter.

Das finde ich eine wirklich positive Nachricht und all meine Beobachtungen sprechen bisher dafür, dass Herstellers Keyserver die Funkmodule in Software simuliert, darüber hinaus aber auch nicht "privilegierter" ist. -> Solange ein Aktor/Sensor angelernt ist, hilft weder Kenntnis des DLKs, noch Vollzugriff auf den Keyserver, um diesen Sensor/Aktor zu "übernehmen".

Noch eine Anmerkung: Ein Forennutzer war so freundlich, mir einen kurzen Mitschnitt aus der Kommunikation zwischen seiner CCU und dem Keyserver zu zeigen. Dort habe ich unter anderem 104 bits lange als "nonce" titulierte Werte gesehen. Meine Vermutung ist, dass es sich hierbei eigentlich um IVs handelt, und da diese kürzer sind, als die genutze AES-Keylänge von 128 bits, könnte das darauf hindeuten, dass AES in einem Counter-Mode genutzt wird. Das würde bedeuten, dass die Zentrale mit jedem Sensor/Aktor 2^(128-104) == 2^24 == 16777216, also gut sechzehneinhalb Millionen Nachrichten austauschen kann, bevor ein Rekeying erfolgen muss. Finde ich eine spannende Frage, ob/wie das dann abliefe, ob das vollautomatisch passiert oder man den Aktor/Sensor neu anlernen muss.

Bleibt noch zu sagen, es wäre so viel schöner, wenn diese Informationen vom Hersteller kämen als dass man sie sich mühsam selbst in der Community zusammenreimen muss...

[hce]

So, früher als geplant habe ich nun dieses Wochenende genutzt, um meine große HmIP-Installation auf Keys in Software umzustellen. Wie groß ist die Installation? Wordcount auf sgtin.map sagt 103 Zeilen. Also eigentlich eher medium als wirklich groß, würde ich sagen. (Aber jetzt, nachdem das hier alles geklappt hat, ist meine Motivation, wieder mehr von diesem Hersteller zu kaufen, deutlich gestiegen, vielleicht werden es demnächst also deutlich mehr.) Neben der CCU3 gibt es hier noch zwei HmIP-HAPs.

Wie dem auch sei, mein Vorgehen war, wie schon bei der kleinen Installation, folgendes:

Ich ließ beide CCU3s parallel laufen, die alte und die neue. Die neue war komplett frisch aufgesetzt mit Raspberrymatic. Dann habe ich in /etc/config/crRFD zwei Dateien angelegt, hmip_user.conf:

Code: Alles auswählen

Network.Key=00000000000000000000000000000000
Backbone.Key=11111111111111111111111111111111
Network.Key.Base=22222222222222222222222222
SGTIN.LocalKey.MappingFile=/etc/config/crRFD/sgtin.map
Legacy.LogLocalKey=true

Selbstverständlich haben meine tatsächlichen Keys ein klein wenig mehr Entropie.

Dann noch sgtin.map:

Code: Alles auswählen

3014F711A000111111111111=53111111111111111111111111111111
3014F711A000222222222222=4A222222222222222222222222222222
3014F711A000333333333333=8C333333333333333333333333333333
3014F711A000444444444444=10444444444444444444444444444444
3014F711A000555555555555=D3555555555555555555555555555555

Man möge mir bitte verzeihen, dass meine SGTINs und DLKs beim Copy+Pasten leicht verschütt gegangen sind %}

Nach Anlegen dieser beiden Dateien habe ich die CCU3 neu gestartet.

Anschließend habe ich die Aktoren/Sensoren Gerät für Gerät an der alten CCU3 abgemeldet und an der neuen angemeldet. Hierbei musste ich nicht die Keys (DLKs) eingeben. Das ist echt komfortabel! Das war es schon, was die eigentliche Umstellung betrifft.

Dann noch die ise_ids in meinen diversen Scripts angepasst. (wobei ich meine statischen rust-binaries nicht wirklich als Skript bezeichnen würde, aber das ist ein anderes Thema) Und natürlich die Programme alle neu angelegt. -> Relativ viel Arbeit, aber dadurch konnte ich alles mal sauber neu machen und die über die Jahre dazugewonnene Erfahrung nutzen.

Lediglich die Homematic "Classic"-Rauchmelder habe ich nicht umgelernt; da mir mit Homematic Classic in der Vergangenheit Dinge abgestürzt sind, werde ich die auch nicht mehr umlernen. Die sind in ihrem Verbund autonom und werden in ein paar Jahren eh gewechselt.

Was ich jetzt im Gegensatz zu der kleinen Installation noch nicht getestet habe, ist, das Backup auf einer zweiten CCU3 einzuspielen und dort ohne Rekeying und sonstigen Blödsinn einfach sofort weiterzulaufen. Ich habe keine Zweifel, dass das ebenso wie bei meiner kleinen Installation problemlos funktionieren wird, werde einen Test jedoch auf die Weihnachtszeit verschieben.

[Baxxy]

Bei mir laufen die ganzen Testsysteme (variabel 1-5) mit bis zu 5 verschiedenen Funkmodulen auch komplett abgenabelt vom eQ-3 Keyserver.

Wenn mal ein neues HmIP-Gerät dazukommt wird es in die sgtin.map aufgenommen und dann die Zentrale rebootet.
Anlernen dann der Bequemlichkeit halber "mit Internet", das läuft ja trotzdem komplett lokal ab.

[jmaus]

Danke erst einmal an hce für das Weiterverfolgen der Idee der Nutzung eigener/lokaler Funkmodulschlüssel. Finde das ganze nun inzwischen wirklich so interessant, das man doch wirklich mal überlegen könnte wie man die Unterstützung für so eine "Local-Key Installation" in der WebUI der RaspberryMatic ggf. Umsetzen bzw. direkt in RaspberryMatic supporten könnte.

Mir schwebt da neben dem automatischen anlegen der hmip_user.conf mit den entsprechenden generierten/frischen Schlüsseln auch noch vor ggf. das direkte Editieren der sgtin.map in irgendeiner brauchbaren Art&Weise dort umzusetzen (vllt auch einfach durch ein Zusatzfeld bei jedem Gerät sodass diese Infos dann via MetaData in der regadom landen?!?)

Die Frage wäre nur ob und wie man ggf. den Umstieg von einer Keyserver gebundenen Installation zu einer Local key Installation in irgendeinerweise ggf. via WebUI unterstützen könnte damit das ggf etwas einfacher bzw via ablaufplan umzusetzen ist. Und dann müsste auch noch bei einer frischen Installation im Installationswizard eben die Auswahl zwischen Keyserver vs local key Installation auswählbar machen damit ein Nitzer hier die Wahl treffen kann zwischen absoluter NoCloud Installation

[jmaus]

Wenn mal ein neues HmIP-Gerät dazukommt wird es in die sgtin.map aufgenommen und dann die Zentrale rebootet.
Anlernen dann der Bequemlichkeit halber "mit Internet", das läuft ja trotzdem komplett lokal ab.

Was mich noch interessieren würde wäre ob es aber auch weiterhin das anlernen via Eingabe der SGTIN+KEY funktioniert auch wenn diese Infos dann nicht in der SGTIN.map steht?

[Black]

Auf jeden fall würde ich eine Wolkenfreie Möglichkeit massiv begrüssen

Black

[Baxxy]

ob es aber auch weiterhin das anlernen via Eingabe der SGTIN+KEY funktioniert auch wenn diese Infos dann nicht in der SGTIN.map steht?

Ja, das geht weiterhin problemlos.
Die eigenen Geräte in der sgtin.map zu pflegen würde ich aber bei einer "massentauglichen Umsetzung" voraussetzen.
So wird z.B. nach einem Gerätefirmware-Update das Gerät "reincludiert", dafür wird der Keyserver genutzt.
Ob es da Unterschiede gibt ob das Gerät lokal oder per Internet angelernt wurde kann ich nicht sagen.

Haben wir also keinen Keyserver und keinen DLK in der sgtin.map dürfte das problematisch werden.

Für einen kompletten "Neubeginn ohne Keyserver" hat @hce das ja nochmal sehr gut beschrieben.

Das Prozedere zum "Umswitchen" auf einem laufenden System ist identisch, nur das man nach dem anlegen der Dateien inklusive vollständig ausgefüllter sgtin.map und anschließendem Reboot eben alle IP-Geräte reincludieren also "drüberlernen" muss.

[jp112sdl]

Da das Thema gerade wieder Fahrt aufnimmt, nur der Hinweis, dass das mit der lokalen SGTIN Map nirgends dokumentiert und daher nur experimentell ist.

Möglicherweise verändert oder erweitert eQ-3 an dieser Methode in Zukunft mal etwas, so dass der aktuelle Workflow inkompatibel wird.

Dann muss sich jemand darum kümmern, diese Änderungen nachzuvollziehen und ggf. notwendige Anpassungen am (eigenen) System vornehmen, damit das mit den selbst ausgedachten Schlüsseln weiterhin funktioniert.

Möglicherweise sind Jens' Kontakte zu eQ-3 aber so gut, dass er bei sowas vorab informiert werden würde. Das kann ich nicht beurteilen.

[hce]

Da das Thema gerade wieder Fahrt aufnimmt, nur der Hinweis, dass das mit der lokalen SGTIN Map nirgends dokumentiert und daher nur experimentell ist.

Möglicherweise verändert oder erweitert eQ-3 an dieser Methode in Zukunft mal etwas, so dass der aktuelle Workflow inkompatibel wird.

Das ist ein guter Punkt. Da es sich nicht um Freie Software handelt, hat der Hersteller jederzeit die Möglichkeit, diese Funktionalität nach Gutdünken auszubauen. Er hätte zwar nichts davon. Nach meiner derzeitigen Einschätzung kann ein einmal mit "Keys in Software" angelerntes System ohne Unterstützung des Herstellers *nicht* mehr auf die Keys eines Funkmoduls umgelernt werden. Das heisst, nach einem Upgrade auf eine Version, die das Setzen von Keys nicht mehr erlaubt, würde das System dann brechen und man müsste alles neu anlernen.

Und da kann ich jetzt nur für mich sprechen: Selbst wenn das Umlernen auf die Keys eines Funkmoduls ginge, wollte ich das nicht. Das wäre für mich der Zeitpunkt, nicht mehr zu upgraden. Dann hätte ich keinen unmittelbaren Zugzwang und könnte (und würde!) auf ein anderes System migrieren, vorzugsweise eines mit offenen Standards.

In other news, es hat mir jetzt keine Ruhe gelassen: Ich habe jetzt auch meine große Installation mit zwei CCU3s getestet (der produktiven und der "fallback-CCU", auf die ich ein aktuelles Backup eingespielt hatte) und konnte meine Aktoren/Sensoren problemlos mit beiden bedienen (je eine CCU natürlich heruntergefahren). Bei meiner kleinen Installation werde ich demnächst nochmal testen, was passiert, wenn zwei CCUs gleichzeitig laufen.

Interessant auch: Die beiden HAPs wollten erst nicht, auch nicht, wenn beide CCU3s die gleiche IP-Adresse verwendeten. Nach einem Neustart (power cycle) der HAPs akzeptierten diese dann die jeweils "neue" CCU3.