Wovor schützt eigentlich das Rekeying?

[hce]

1) Es gibt ein zentrales Funkmodul pro HmIP-Installation mit einem FLK (Funkmodul Local Key), der verwendet werden kann aber nicht muss (letzteres wissen wir dank jerome&co seit Anfang des Jahres, Stichword hmip_user.conf), und der auch nicht ausgelesen werden kann.

Genau dieser ist meinem Verständnis nach der Grund wieso der Keyserver bei eQ3 überhaupt existiert. Dort gibt es eben eine "Liste" aller FLK die quasi im Funkmodul "eingebrannt" sind und die auch nicht wie du schon korrekt sagst auslesbar sind.

Gut, dann sind wir schon zwei, die es so sehen; vielleicht ist die Idee dann ja nicht komplett abwegig.

Und es hieße auch, dass man sich mit dem Setzen eines Keys in Software vermittels hmip_user.conf nicht nur das Rekeying und damit die Abhängigkeit von Cloudservern erspart, sondern möglicherweise auch, dass man den Hersteller damit von der eigenen HmIP-Installation "aussperrt". Auch dieses fände ich einen wünschenswerten Umstand. Wobei das vielleicht schon immer der Fall war, aber das weiss bis jetzt nur der Designer des Protokolls, und der schweigt sich leider konsequent aus.

Diese sind also quasi wie der private key der in symmetrischen Verschlüsselungsverfahren üblich ist. Und davon abgeleitet wird dann quasi der public key erzeugt der wiederum dazu genutzt um die Kommunikation zwischen den Geräten zu verschlüsseln.

Hmm, dass HmIP asymmetrische Verfahren nutzt, wäre mir neu. Die Schlüssellängen sprechen für AES. Man kann aber auch mit rein symmetrischen Verfahren hohe Sicherheit erreichen; es hätte auch den Vorteil, dass man vielleicht sogar PQ-sicher ist.

Und ja, natürlich könnte all das problemlos auf der CCU/RaspberryMatic selbst stattfinden, dafür müsste der Keyserver ja quasi einfach diesen private key ausliefern und dann könnte dieses rekeying komplett lokal ablaufen. Aber aus historischen Gründen hat eQ3 das eben so umgesetzt - auch weil damals mit der CCU2 die Rechenpower wirklich sehr bescheiden war, aber sicherlich auch einfach weil die gesamte Keyserver Infrastruktur ohnehin wegen der Cloudlösung ja schon da war.

Ich verstehe das Argument mit der Rechenpower nach wie vor nicht -- wir reden hier ausschließlich von AES, dort sind die Schlüssel so schnell erzeugt, wie man Zufall sagen kann %} Bei RSA würde ich zustimmen, insbesondere beim Erzeugen neuer Schlüsselpaare ist die benötigte Rechenleistung nicht unerheblich, aber die wären dann auch deutlich länger, als das, was wir bei HmIP sehen. Selbst für Verfahren wie etwa EdDSA sind die Schlüssel zu kurz. Und es gäbe aus meiner Sicht auch protokolldesigntechnisch keinen Grund für ein asymmetrisches Verfahren.

Spätestens seit dem Beitrag von jp112sdl/Baxxy sollte aber auch klar sein das die große Sorge unberechtigt sein sollte ggf. mit einem Haufen Elektroschrott da zu stehen wenn morgen eQ3 alle Keyserver abschaltet und das Funkmodul stirbt. Schon jetzt kann man ja eben mit dem aufgezeigten eintragen eines eigenen Keys es erreichen das die Keyserver komplett aus dem Spiel sind. Man verliert eben lediglich den Komfort das das bei einem Wechsel auf ein anderen Funkmodul mit einem anderen private key dann automatisch geht und man muss eben selbst dann ggf Hand anlegen. So zumindest meinem aktuellen Verständnis nach.

Na ja. Ich finde den Beitrag super, absolut! Und wenn man davon rechtzeitig weiss, kann man sich darauf auch adäquat vorbereiten. Man setzt ganz am Anfang eigene Keys und hat seine Ruhe. Ich wusste aber selbst lange Zeit nichts von dieser versteckten Abhängigkeit. Und darf meine große Installation deshalb demnächst komplett neu aufsetzen.

[jmaus]

Na ja. Ich finde den Beitrag super, absolut! Und wenn man davon rechtzeitig weiss, kann man sich darauf auch adäquat vorbereiten. Man setzt ganz am Anfang eigene Keys und hat seine Ruhe. Ich wusste aber selbst lange Zeit nichts von dieser versteckten Abhängigkeit. Und darf meine große Installation deshalb demnächst komplett neu aufsetzen.

Wenn du das wirklich machst, würde ich vorschlagen du dokumentierst alles mal fein säuberlich und testest da auch dann am Anfang mal den Funkmodulwechsel mit solch einem selbst gewählten key, denn ganz so einfach/reibungslos wird das vmtl trotzdem nicht funktionieren. So zumindest meine Prognose.

Aber wenn du das ordentlich und detailliert genug dokumentierst, dann können wir das gerne mit ins RaspberryMatic Projekt mit aufnehmen. Und wer weiß, vllt ergibt sich ja auch ein sinnvoller Ansatz direkt in der WebUI dann eine Oberfläche bereitzustellen um solch einen eigenen Key selbst zu setzen und dann auch entsprechend den Wechsel zu einem anderen Funkmodul dann in diesem manuellen Anwendungsfall klar für jedermann zu dokumentieren und nicht nur für sich selber in einer privaten Notiz.

Abgesehen davon werd ich da aber auf so eine Umstellung auf manuelles Keying verzichten, nicht weil ich selbst den ausfand scheue, sondern weil ich selbst nicht paranoid genug bin oder ängstlich das im Fall der Fälle meine Hardware brach darlegt. Und ja, bisschen Faul bin ich auch, denn das automatische Anmeldungsverfahren ohne Eingabe der SGTIN und KEY ist schon arg geschickt

[hce]

Na ja. Ich finde den Beitrag super, absolut! Und wenn man davon rechtzeitig weiss, kann man sich darauf auch adäquat vorbereiten. Man setzt ganz am Anfang eigene Keys und hat seine Ruhe. Ich wusste aber selbst lange Zeit nichts von dieser versteckten Abhängigkeit. Und darf meine große Installation deshalb demnächst komplett neu aufsetzen.

Wenn du das wirklich machst, würde ich vorschlagen du dokumentierst alles mal fein säuberlich und testest da auch dann am Anfang mal den Funkmodulwechsel mit solch einem selbst gewählten key, denn ganz so einfach/reibungslos wird das vmtl trotzdem nicht funktionieren. So zumindest meine Prognose.

Mit einer kleinen Installation habe ich das schon gemacht und hier dokumentiert: viewtopic.php?f=60&t=80011

Also als bisheriges Fazit kann ich sagen, wenn man zu Beginn eigene Keys in hmip_user.conf setzt, hat man später keine Probleme mehr.

Die große Installation werde ich wohl eher so um die Weihnachtszeit rum umstellen, da fehlt mir momentan leider die Zeit zu.

[hce]

[...]Schon jetzt kann man ja eben mit dem aufgezeigten eintragen eines eigenen Keys es erreichen das die Keyserver komplett aus dem Spiel sind. Man verliert eben lediglich den Komfort das das bei einem Wechsel auf ein anderen Funkmodul mit einem anderen private key dann automatisch geht und man muss eben selbst dann ggf Hand anlegen. So zumindest meinem aktuellen Verständnis nach.

Es ist noch schöner: Man muss dann beim Wechsel des Funkmoduls gar nichts weiter tun. Denn so, wie es aussieht (experimentell mit 2 CCU3s überprüft), wird dann der Key des Funkmoduls einfach gar nicht erst genutzt. Man wechselt das Funkmodul also einfach und alles läuft einwandfrei weiter.