Beitrag
von hce » 24.09.2023, 10:27
Hallo,
Ich hoffe, es ist okay, wenn ich das alte Thema nochmal "ausgrabe"; ich habe eine Nachfrage bzw. einige Überlegungen zu dem ganzen.
Erstmal, ich würde die Keys immer lokal generieren und keinen Online-Generator benutzen, denn bei letzterem weiss man nie so genau, wie zufällig das alles wirklich ist. Wenn man direkt auf der Kommandozeile vom Raspberrymatic ist, kann man zum Beispiel mit diesem Befehl die Keys generieren:
dd status=none bs=1k count=1 if=/dev/random | sha512sum | cut -c -32 | tr [:lower:] [:upper:]
Zur Erklärung, das liest 1kB "starken" Zufall von /dev/random, berechnet einen Hashwert daraus, nimmt die ersten 32 Zeichen und wandelt die Buchstaben darin in Großbuchstaben um. Man könnte das auch noch in ein Script einbauen, das gleich die komplette Datei aufbaut.
So, nun eine Frage, wenn ich es richtig verstanden habe, dann muss ich *nicht* proaktiv alle HmIP-Geräte anlernen, nachdem ich einen eigenen Key /etc/config/crRFD/hmip_user.conf gesetzt habe, sondern es reicht, dies beim Funkmodulwechsel zu tun, korrekt?
Falls ja, hieße das, dass die Keyserver eigentlich nicht viel tun, sondern nur der Zentrale die neuen Master Keys des aktuellen Funkmoduls mitteilen, die dann aber nicht gespeichert werden, sondern nur genutzt werden, um die Gerätekeys auf der CCU "umzuverschlüsseln"? Dann müssten die Keyserver aber auch den Key des alten Funkmoduls mitteilen, sonnst würde das ja nicht klappen.
Wahrscheinlicher wäre es aus meiner Sicht, dass man den Keyservern jeden einzelnen Eintrag in /usr/local/etc/config/crRFD/data schickt, also einen pro HmIP-Gerät, und diese Keyserver dann den Geräte-Key mit dem Key des alten Funkmoduls entschlüsseln und mit dem des neuen verschlüsseln und zurückschicken. Aber was das bringen sollte, ist mir trotzdem noch nicht ganz klar. Denn dann könnte man zwar die Gerätekeys nicht "unwrappen", aber man könnte sie auf ein beliebiges Funkmodul "umverschlüsseln" lassen.
Und: Wie spielt denn bei dem ganzen der lokal festgelegte "Security Key" rein, ohne den man ja, einmal festgelegt, ein Backup ebenfalls nicht wieder einspielen kann?
=> Was ist denn das Schutzziel dieses Rekeyings? Welche Bedrohungsszenarien will man denn hier begegnen? Mir fällt akut nichts plausibles ein...