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

[hce]

Ich habe mal beim Hersteller nachgefragt, ob er gedenkt, die Möglichkeit, Keys in Software zu setzen irgendwann auszubauen. Als Antwort bekam ich:

Leider können wir zu dieser Funktion keine Auskunft geben, da es sich hier um eine Besonderheit für den Entwickler
und in dessen Testumgebung handelt und nicht für Endkunden bestimmt und damit dokumentiert ist.

Für den Wechsel eines Funkmoduls bzw. das Einspielen eines Backup in einer anderen CCU3 ist unabhängig davon, immer
eine Internetverbindung und Austausch über den Keyserver nötig.

[hce]

Also nur der Vollständigkeit halber: Der zweite Absatz in der Hersteller-Antwort ist offensichtlich falsch. Ich habe ja meine Tests ausführlich beschrieben, andere hier im Forum haben das ebenso.

Wenn ich so drüber nachdenke, halte ich es für sehr sinnvoll, eine entsprechende Funktion in Raspberrymatic einzubauen, um das ganze von der GUI aus einfach bedienbar zu machen. Auch, um dem Hersteller klarzumachen, dass der Community dieses Feature wichtig ist und wir keine Lust auf Abhängigkeiten von externen Keyservern oder anderen Single Points of Failure haben.

Mein Vorschlag wäre, das als ersten Schritt bei der Einrichtung von neuen Installationen als Option anzubieten mit entsprechender Erläuterung. Im Workflow zum Beispiel unmittelbar nach dem Setzen eines initialen Admin-Passworts. Die Erläuterungstexte kann ich gerne formulieren, falls gewünscht.

[jmaus]

Wenn ich so drüber nachdenke, halte ich es für sehr sinnvoll, eine entsprechende Funktion in Raspberrymatic einzubauen, um das ganze von der GUI aus einfach bedienbar zu machen. Auch, um dem Hersteller klarzumachen, dass der Community dieses Feature wichtig ist und wir keine Lust auf Abhängigkeiten von externen Keyservern oder anderen Single Points of Failure haben.

Ich bin da ganz bei dir. Unabhängig davon wie eQ3 das sieht, halte ich die Möglichkeit einer Option des kompletten local key betriebes für durchaus eine interessante zukünftige Option für die WebUI. Das würde noch mehr den "NoCloud" Ansatz unterstreichen den RaspberryMatic klar präferiert. Trotzdem denke ich muss man das sehr gut planen und auch entsprechend umsetzen um da nicht Verwirrung bei Otto-Normal-Anwender zu verursachen. Auch müsste man sich nochmal detailliert gedanken darum machen wie man einen möglichen Umstieg von Keyserver -> localKey genau betreut bzw. diesen dann in der WebUI entsprechend begleitet und auch dort dokumentiert.

Kurzum: Das wird keine schnelle Sache werden die mal in ein paar Tagen umgesetzt sein wird, sondern eher eine Sache von Wochen bis Monaten. Und dazu bedarf es dann eben ein entsprechendes GitHub Ticket, PullRequest, usw.

Mein Vorschlag wäre, das als ersten Schritt bei der Einrichtung von neuen Installationen als Option anzubieten mit entsprechender Erläuterung. Im Workflow zum Beispiel unmittelbar nach dem Setzen eines initialen Admin-Passworts. Die Erläuterungstexte kann ich gerne formulieren, falls gewünscht.

Ja, der erste Ansatz sollte sein den Installationswizard der ja bei einer frischen Installation aufpoppt, dahingehend um die Logiken zu erweitern damit man dort die Wahl zwischen KeyServer und LocalKey treffen kann und dann auch irgendwo die SGTIN+KEY mapping tabelle editiert werden kann bzw. vielleicht auch teilautomatisch generiert werden kann (weil man den KEY ja ohnehin beim manuellen Anlernen eingeben wird).

[hce]

[...]Auch müsste man sich nochmal detailliert gedanken darum machen wie man einen möglichen Umstieg von Keyserver -> localKey genau betreut bzw. diesen dann in der WebUI entsprechend begleitet und auch dort dokumentiert.

Hmm, das geht eigentlich nur, wenn man zwei CCUs hat. Man lernt einen Aktor/Sensor nach dem anderen auf der alten ab und lernt ihn auf der neuen an. Mit nur einer CCU bliebe eigentlich nur, ein Backup anzulegen, die CCU zu resetten, Keys in Software zu aktivieren und dann die Aktoren/Sensoren einen nach dem anderen zu resetten und neu anzulernen.

Ja, der erste Ansatz sollte sein den Installationswizard der ja bei einer frischen Installation aufpoppt, dahingehend um die Logiken zu erweitern damit man dort die Wahl zwischen KeyServer und LocalKey treffen kann und dann auch irgendwo die SGTIN+KEY mapping tabelle editiert werden kann bzw. vielleicht auch teilautomatisch generiert werden kann (weil man den KEY ja ohnehin beim manuellen Anlernen eingeben wird).

Man kann das Mapping auf den QR-Codes aufbauen. Ich habe meine QR-Codes alle eingescannt und dann in die sgtin.map eingetragen. So habe ich mir das aufwändige Abtippen der Keys+SGTINs erspart. Man muss nur folgendes im gescannten QR-Code ersetzen:

Code: Alles auswählen

DLK durch =
EQ01SG durch nix

Mit sed z.B. so:

Code: Alles auswählen

sed -i bak -e 's/EQ01SG//' -e 's/DLK/=/' sgtin.map

[Baxxy]

das geht eigentlich nur, wenn man zwei CCUs hat

Genau... "eigentlich".

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.

Mit sed die sgtin.map ins richtige Format zu rücken ist eine sehr gute Idee. Ich hatte das noch "händisch" gemacht.
Mein Workflow:
Mit dem Handy alle QR-Codes einscannen und dann als Email an mich schicken.
Am PC die Mail als Textdatei gespeichert und mit "Suchen und Ersetzen" ins rechte Licht gerückt. Dann in die sgtin.map übertragen.
Als Freund der Ordnung habe ich meine sgtin.map dann noch aufgehübscht:

Code: Alles auswählen

#***Schaltaktoren***
#PSM 		A0D2
xxx=yyy
#--------------------------------------------------------
#***Rolladenaktoren***
#BROLL		31E8
xxx=yyy
#--------------------------------------------------------
#***MOD-Platinen***
#MOD-OC8 	E4A8
xxx=yyy
#--------------------------------------------------------

Da ich auch manchmal faul bin und "kurzweilige Testsysteme" nicht extra "präparieren" will blocke ich auf den "Keyserver-losen" Systemen den Keyserver mittels Einzeiler in der rc.local. So kann ich auf anderen Testsystemen immer noch "per Internet und Keyserver" anlernen.

Code: Alles auswählen

echo "127.0.0.2 secgtw.homematic.com" >> /var/etc/hosts

[hce]

So, jetzt habe ich noch ein bisschen mit meiner kleinen HmIP-Installation (ca. 10 Aktoren/Sensoren) experimentiert.

Test 1:

Ich habe zwei Basisstationen parallel laufen lassen. Ich konnte mit beiden Basisstationen die Aktoren steuern, allerdings nicht ganz problemlos: Wenn ich mit Basisstation A einen Aktor gesteuert hatte, dann ließ sich dieser für mehrere Sekunden nicht mit Basisstation B steuern. Sobald ich von Station A keine Befehle mehr sendete, ließ sich der Aktor dann auch mit Basisstation B steuern, dafür konnte ich ihn dann vorübergehend mit Basisstation A nicht mehr steuern. Ansonsten gab es keine negativen/dauerhaften Beeinträchtigungen.

Test 2:

Ich den Backbone.Key und den Network.Base.Key auf jeweils 001122334455... geändert und die CCU3 rebooted. Dies beeinflusste *nicht* die Fähigkeit der CCU3, mit den Aktoren/Sensoren zu kommunizieren. Lediglich der Network.Key scheint eine Rolle zu spielen. Wird dieser auch nur um ein Bit geändert, so schlägt die Kommunikation zwischen CCU3 und Aktoren/Sensoren anschließend fehl.


Ich schrieb in einem vorherigen Beitrag etwas zu AES-CTR. Ich bin mir inzwischen aber ziemlich sicher, dass AES im CBC-Mode benutzt wird. Test 1 spricht dafür, denn wenn es da einen Counter gäbe, dürfte eine Basisstation mit einem älteren Zustand einen zu alten Counter nutzen und dann nicht mehr kommunizieren können, kann sie aber. Beim CTR-Mode hat man auch das Problem, dass der gleiche Counter keine zweimal benutzt werden darf. Das sicherzustellen, dürfte gerade bei Aktoren/Sensoren schwierig sein, wo die Batterie gewechselt werden/jederzeit der Strom ausfallen kann. Bei CBC braucht man dagegen für jede Nachricht einen IV, der zufällig sein muss, das können aber moderne Kryptocoprozessoren auch auf embedded Hardware, von daher sollte das kein Problem sein.

Ich werde mir als nächsten Schritt mal überlegen, wie ich so ein Protokoll designen würde und dann meine Vermutungen hier veröffentlichen.

[Roland M.]

Hallo!

Wenn ich mit Basisstation A einen Aktor gesteuert hatte, dann ließ sich dieser für mehrere Sekunden nicht mit Basisstation B steuern.

Das scheint mir aber in Richtung allgemeiner HmIP-Probleme a la "Partner antwortet nicht schnell genug" zu gehen.

Ich habe einen HmIP-BDT, der über die Tastenwippe vier weiter FDT ansteuert (also inkl. sich selbst 5 DV). Auf Tastendruck werden alle Geräte angesteuert, aber 3-4 s danach funktioniert kein weiterer Tastendruck, die Geräte-LED quittiert auch mit Rot. Bei nur zwei oder drei FDT (kann mich nicht mehr genau erinnern) ist diese Eigenschaft nicht gegeben. Ich konnte das auch mit anderen Schaltaktoren reproduzieren.


Roland

[hce]

Hallo Roland,

Das scheint mir aber in Richtung allgemeiner HmIP-Probleme a la "Partner antwortet nicht schnell genug" zu gehen.

Halte ich in meinem Fall für unwahrscheinlich; ich habe es gerade nochmal mit einer einzigen Basisstation getestet: 10 mal hintereinander ein- und ausgeschaltet; ich konnte das Relais jeweils klacken hören. Der "Test-Aktor" ist ein HmIP-SCTH230 mit eingebautem Relais.

Ich tippe eher auf ein Routing-Issue; trotz gleichen Schlüssels muss der Aktor ja wissen, an welche SGTIN der Basisstation er seine Nachrichten jetzt adressieren muss. Oder so...