Funkmodul-Tausch ohne Online-Rekeying

[jp112sdl]

Das Thema Rekeying stößt hier immer mal wieder auf, wenn jemand die Zentrale wechselt oder auch nur das Funkmodul austauscht.
Zudem steht auch des Öfteren die Frage im Raum, was passiert, wenn eQ-3 seine Server abschaltet und von HmIP nix mehr wissen will.

Nachdem ein Funkmodul-Wechsel erkannt wird, erfolgt durch den HMIPServer auf der CCU ein Rekeying (Schlüsselaustausch), bei dem eine Online-Verbindung zum eQ-3-Frontend secgtw.homematic.com vorausgesetzt wird.

Ist der Server mal nicht erreichbar, sei es durch Probleme bei eQ-3, beim DNS, beim eigenen Internetanbieter oder man betreibt eine Offline-Insellösung, steht man erstmal da wie Max in der Sonne - denn so lange das Rekeying nicht stattgefunden hat, ist keine Steuerung der HmIP-Geräte möglich.

Nachdem Jens ein paar Hinweise gegeben hat, habe ich das Szenario mal durchgespielt.

Dabei ist es letztlich ganz einfach:

• Man legt eine Datei /etc/config/crRFD/hmip_user.conf an und schreibt in diese

  Code: Alles auswählen

  Network.Key=00112233445566778899AABBCCDDEEFF
  Backbone.Key=FFEEDDCCBBAA99887766554433221100
  Network.Key.Base=00112233445566778899AABBCC
  

  Die Zahlenfolge ist hier willkürlich gewählt. Wichtig ist, dass die .Key ein 32-stelliger und die .Base ein 26-stelliger HEX-Wert sind.
• Die CCU muss neu gestartet werden (oder wahlweise nur der HMIPServer)

Wird nun ein notwendiger "Adapter exchange" (das Funkmodul wurde ausgetauscht) erkannt, der ein Rekeying zur Folge hat, wird zunächst versucht, den Frontend-Server zu kontaktieren. Schlägt es fehl, wird auf den lokalen Netzwerkschlüssel aus der hmip_user.conf zurückgegriffen.

Code: Alles auswählen

de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [RXTXPortMonitor(/dev/mmd_hmip)] Exchanging adapter from 3014F711A000041D699A50C0 to 3014F711A061A7D08999D6A6 ... 
de.eq3.cbcs.server.local.base.internal.HMIPTRXInitialResponseListener INFO  [vert.x-eventloop-thread-0] Adapter exchange successful.

...und das alles offline, alle HmIP Geräte (in meinem Fall nur eins) lassen sich wieder bzw. weiterhin steuern.

Das Anlernen der Geräte klappt nun jedoch leider nur lokal (was bei einer Insellösung ohne Internet oder der Geschäftsaufgabe von eQ-3 ohnehin nur der Fall wäre).

Dieser Beitrag dient in erster Linie dazu, den Leuten die Angst zu nehmen, dass man möglicherweise mit seiner Anlage bis zum Lebensende auf einer Zentrale bzw. einem Funkmodul festgenagelt ist.

[Baxxy]

Soo...
nach gefühlt endlosen Testsessions, Teamviewer-Sitzung und regen Gedankenaustausch mit Jérôme und X-Werksresets einiger IP-Aktoren/Sensoren
kommt hier nun die Anleitung für den "Worst-Case".

• Durchführung:

Wir generieren uns zunächst 3 random Hex Keys (2x 128 Bit und 1x 104 Bit) die wir dann wie folgt in die anzulegende '/usr/local/etc/config/crRFD/hmip_user.conf' kopieren und speichern.

Code: Alles auswählen

Network.Key=8509A93207CA52B5DD3D7BE95C4DE1BD
Backbone.Key=D5C10E84E6C92BC1B0E77708D69EA877
Network.Key.Base=5FB294FF0BA1DE0D206E7ABA2C

Ich habe dafür einen >> Online-Generator << benutzt.
Wichtig ist die Länge: 'Network.Key' & 'Backbone.Key' haben 32, 'Network.Key.Base' hat 26.
Ob Groß/Kleinschreibung relevant ist konnten wir nicht 100%ig klären, ich empfehle Großschreibung.

Als nächstes müssen wir dafür sorgen das der eQ-3 Keyserver definitiv nicht erreichbar ist (gilt für den Fall das ihr dem "Worst Case" zuvorkommen wollt). Entweder per Kindersicherung im Router, Firewall, Blocker oder ganz simpel über die WebUI.

Nun fahren wir das System herunter und wechseln zum neuen Funkmodul.
Der nächste Start dauert ein bisschen länger und RM meckert dann gleich wegen Internet und chrony-restart usw., alles egal denn das neue Funkmodul wurde offline "gerekeyed" und alle IP-Geräte funktionieren instant wie gewohnt.

Man kann der Zentrale nun wieder Internet / Keyserver - Zugang gewähren.
Nach dieser Aktion würde ich aber empfehlen neue Geräte nur noch lokal anzulernen.

• Kleine Warnung:

Wer nicht vorhat das Funkmodul zu wechseln sollte die Finger hiervon lassen. Der Versuch das gleiche Funkmodul offline zu "rekeyen" schlug hier mehrfach fehl und die Geräte mussten dann händisch reincludiert (lokaler Werksreset) werden weil sie nicht mehr mit der Zentrale kommunizieren wollten.

• Schöner Nebeneffekt:

Wenn man den Keyserver weiterhin blockt kann man nun problemlos auf den >> HB-RF-HAP << wechseln, und auch wieder zurück auf ein anderes Funkmodul.

Nähkästchen:
Ich hatte meine eigene Warnung (unabsichtlich) ignoriert und bei einem Testsystem mit 13 IP-Aktoren / Sensoren das Rekeying des gleichen Funkmoduls "versucht". Schlug fehl. Ergebnis war eine halbstündige "Reinclusions-Orgie" bis kurz vor'm DC-Limit.
Ließ sich alles bis auf einen HAP "retten". Den HAP musste ich einmal komplett rausschmeißen und konnte ihn dann wieder anlernen (hab's lokal gemacht). Das positive der Geschichte... Werksreset von IP-Geräten kann ich nun "im Schlaf".

Edit:
- Bit Angaben korrigiert

[jp112sdl]

3 random Hex Keys (2x 32bit und 1x 26bit)

Kleine Korrektur und Exkurs zu Bits und Bytes:
Eine Hexadezimalziffer hat den Wertebereich 0 - F oder in dezimal 0 - 15, das entspricht binär 0000 - 1111.
Sie belegt also 4 Bit.
Ein Byte besteht aus 8 Bit - somit aus einem Hexadezimalziffernpaar 00 - FF.

Macht hier

ein 32-stelliger HEX-Wert

von 16 Byte oder 128 Bit länge.
Oder bei 26 Hex-Zeichen dann 13 Byte bzw. 104 Bit.

Nach gefühlt endlosen Testsessions, Teamviewer-Sitzung und regen Gedankenaustausch mit Jérôme und X-Werksresets einiger IP-Aktoren/Sensoren
kommt hier nun die Anleitung für den "Worst-Case"

2 1/2 Stunden... waren sehr produktiv und dein Labor ist schon ganz schön gut ausgestattet

P.S.: Ich ergänze die Schlüsselkonfiguration in meinem ersten Beitrag gleich mal noch, so dass es dort auch komplett ist.

[jmaus]

Interessanterweise bin ich erst jetzt auf diesen Beitrag hier aufmerksam geworden. Trotzdem schon einmal euch Beiden vielen vielen Dank für die Analysen und sicherlich vielen Tests hierzu. Ich denke das sollte wirklich helfen das ganze CCU-System noch "cloud-loser" bzw. Hersteller unabhängiger zu machen - für den Fall der Fälle den wir hoffentlich nicht in all zu naher Zukunft haben werden.

Die einzige Frage die mir dazu noch einfallen würde, wäre: Ergibt es vielleicht jetzt bereits Sinn hierfür in RaspberryMatic eine Funktionalität in der WebUI einzubauen um es zu ermöglichen diese Keys direkt in der hmip_user.conf setzen zu können (vielleicht automatisiert?) und vielleicht auch den secgtw in der crRFD.conf des HMIPServer (parameter KeyServer.Gateway.URL) dann rauszunehmen um so eine Kontaktaufnahme zum eQ3 Server gänzlich zu unterbinden? Auch könnte man meinem Verständnis nach theoretisch mit den von euch gesammelten Infos ja eigentlich auch irgendwie ein Modus in RaspberryMatic schaffen um sich seine Zentrale cloud-less einzurichten, oder? D.h. seine Zentrale schon jetzt ohne jegliche Kontaktaufnahme zum secgtw von eQ3 zu betreiben - natürlich mit dem Hinweis das man dann für immer und ewig die SGTIN und den lokalen Key benötigen wird um Geräte anzulernen, usw.

[jp112sdl]

das ganze CCU-System noch "cloud-loser" bzw. Hersteller unabhängiger zu machen

Es ist sogar möglich, in der hmip_user.conf einen Parameter

Code: Alles auswählen

SGTIN.LocalKey.MappingFile=/etc/config/crRFD/sgtin.map

zu konfigurieren und dort ein Mapping im Format

Code: Alles auswählen

SGTIN=HEX-KEY 

zu hinterlegen.
Man muss halt jedoch den Key erst noch hexadezimal konvertieren.
So wird z.B. aus dem KEY 7EUMJU6HBM523YTF46N1B6YXUT HEX EDDD23B341742887ED3886A8566F777A
Sichtbar wir das im hmserver.log, wenn man

Code: Alles auswählen

Legacy.LogLocalKey=true

setzt und dann mal lokal mit KEY anlernt.

Jedenfalls kann man dann sogar OFFLINE die Funktion "Anlernen mit Internet" nutzen, um Geräte erneut anzulernen.

[Baxxy]

Da das Kätzchen nun aus dem Sack ist...

Mein größtes Testsystem läuft schon eine Weile ohne Keyserver - Anbindung.
Alle IP-Testgeräte sind in der sgtin.map hinterlegt.
Dazu hatte ich alle QR-Codes gescannt und die "Rohdaten" dann eingetragen.

[jmaus]

das ganze CCU-System noch "cloud-loser" bzw. Hersteller unabhängiger zu machen

Es ist sogar möglich, in der hmip_user.conf einen Parameter

Code: Alles auswählen

SGTIN.LocalKey.MappingFile=/etc/config/crRFD/sgtin.map

zu konfigurieren und dort ein Mapping im Format

Code: Alles auswählen

SGTIN=HEX-KEY 

zu hinterlegen.
[...]
Jedenfalls kann man dann sogar OFFLINE die Funktion "Anlernen mit Internet" nutzen, um Geräte erneut anzulernen.

Na aber hallo. Das sind ja mal interessante Neuigkeiten. Danke für das Nachforschen bzw. Reverse-Engineering. Das würde es ja dann in der Tat ermöglichen in der WebUI vielleicht irgendwelche Funktionalitäten einzubauen wo man den KEY (natürlich auf sicherem Wege) hinterlegen/eintragen kann um dann die zentrale nicht nur cloud-less sondern sogar ohne Notwendigkeit den SGTIN+Key einzugeben anlernen lassen kann. Wäre eben nur die berechtigte Frage des "Wie genau?" und natürlich auch die Frage nach der Sicherheit dieser Methode, denn immerhin würde man dann ja quasi den Key im Klartext im Filesystem der CCU (und damit auch in jedem Backup) mit ablegen. Und ob das kritisch ist, ob man das will oder wie man das ausreichend dann schützen könnte sollte man schon ausreichend mal überlegen/durchkauen.

Aber alleine schon die Möglichkeit die Zentrale mit eigenen Keys in hmip_user.conf auszustatten um so im Grunde vollkommen unabhängig von eQ3 zu sein wäre ja schon eine interessante Möglichkeit und wäre IMHO der Überlegung wert dies dann vielleicht in der WebUI der RaspberryMatic bzw. mit irgendwelchen config Variablen dem System beizubringen um so die Zentrale komplett Cloud-Less betreiben zu können.

[MichaelN]

Kann man diese Mapping Table automatisch aus einem laufenden System erzeugen?

[Xel66]

...im Grunde vollkommen unabhängig von eQ3 zu sein...

Nicht nur das. Somit verlieren HmIP-Geräte auch ihren Schrecken, im Fall der Fälle (eQ-3 würde hypothetisch die Lust am Betrieb der Server verlieren) mit seinen Geräten im Regen zu stehen und sie am System anlernen zu können. Ich will ausdrücklich nicht behaupten, dass dieses in nächster Zukunft zu erwarten wäre (dafür ist eQ-3 schon lang genug im Geschäft und anscheinend brummt der Laden, wenn ich mir die Lieferzeiten teilweise anschaue), aber es gibt ja mehrere Beispiele, bei denen der Hersteller die Cloudservices (z.B. Osram-Lightify, Koubachi) abgeschaltet hat und der Kunde dann teilweise mit Elektroschrott dastand. Insofern wäre eine einfache Integrationsmöglichkeit schon von Vorteil. Ich befürchte aber, dass einige "datenschutzsensible" Neueinsteiger anhand von dann auftauchenden YT-Videos ihr System ohne Keyserver aufsetzen, damit nicht zurechtkommen und zusätzlichen Supportaufwand generieren. Das war in der Vergangenheit immer so (man schaue sich nur regelmäßige Fragen zu virtualisierten CCUs an) und wird auch hier geschehen.

Gruß Xel66

[jmaus]

Kann man diese Mapping Table automatisch aus einem laufenden System erzeugen?

Nein, denn den KEY gibt es ja nur auf den kleinen Zetteln in der Geräteverpackung wo der QR-Code auch zu sehen ist und den man logischerweise auch immer aufheben und sicher verwahren sollte.