Funkmodul-Tausch ohne Online-Rekeying

[jp112sdl]

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.

Genau so ist es. Selbst der Key, der beim Online-Anlernen vom eQ-3 Frontend bezogen wird, hilft da nicht weiter.

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.

Sobald man anfängt, mit lokalem statischen Netzwerkkey zu arbeiten, hebelt man das beschworene Sicherheitskonzept aus.

Reverse-Engineering

ist ja so ein böses Wort.
Daher wäre es auch äußerst fragwürdig, ob man die Umwandlungsmethode KEY=>HEX überhaupt öffentlich einsetzen dürfte.

[Baxxy]

Den Hex-Key kann doch jede QR-Scanner App aus dem Aufkleber holen.
Das kann also nicht so kritisch sein.

[jp112sdl]

Den Hex-Key kann doch jede QR-Scanner App aus dem Aufkleber holen.

Stimmt, das hattest du mir ja mal geschickt (keine Sorge, hab random ein paar Stellen geändert):

Code: Alles auswählen

EQ01SG 3014F711A0001F58A9A1733C DLK 116E8E94661C5A76406A39E8D72DC66D

Ich frag mich, warum man den HEX-Wert nicht auch auf das Klebchen druckt, sondern das in nen Text-KEY umwandelt (und nach der Eingabe wieder intern zurück in HEX)

[Xel66]

Ich frag mich, warum man ...

Security by obscurity!?

Gruß Xel66

[jmaus]

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.

Sobald man anfängt, mit lokalem statischen Netzwerkkey zu arbeiten, hebelt man das beschworene Sicherheitskonzept aus.

Stimmt auch wieder. Sobald man die hmip_user.conf mit eigenen Keys füllt ist das im Grunde das gleiche. Müsste man nur vllt. überlegen ob man dann vielleicht nicht die backups in zukunft komplett oder zumindest in teilen dann verschlüsselt und nur entpacken lässt mit einem entsprechendem Backup Passwort. Im Grunde das gleiche wie das auch bei FritzBoxen inzwischen üblich ist. Wäre ohnehin nen recht nützliches Feature und wenn man vielleicht sich dafür entscheidet das heir beschriebene Verfahren umzusetzen könnte man das als "mandatory" einbauen und nur solche verschlüsselten Backups zulassen.

Reverse-Engineering

ist ja so ein böses Wort.
Daher wäre es auch äußerst fragwürdig, ob man die Umwandlungsmethode KEY=>HEX überhaupt öffentlich einsetzen dürfte.

Da mache ich mir ehrlich gesagt keine Sorgen drum. Das ist doch kein Rocket Science und eine simple Key->Hex konvertierung und mehr nicht. Und wenn wir das unter RaspberryMatic einbauen dann läuft das auch mit dem Segen von eQ3.

[jmaus]

Ich frag mich, warum man den HEX-Wert nicht auch auf das Klebchen druckt, sondern das in nen Text-KEY umwandelt (und nach der Eingabe wieder intern zurück in HEX)

Der key ist doch da mit "-" auf dem Klebchen angegeben, oder? Dann wird das vielleicht einfach ein simpler Trenner sein um die Eingabe für Otto-Normal-Menschen zu vereinfachen. Und deshalb kein Hex damit da auch andere Zeichen als nur 0-9 und a-f vorkommen. Im Grunde das selbe wie mit einer IBAN. Ohne die Trennstriche ist die einfach schwerer nacheinander einzugeben.

[jp112sdl]

Das ist doch kein Rocket Science und eine simple Key->Hex konvertierung und mehr nicht.

So simpel ist die Konvertierung leider nicht.
Im KEY werden z.B. nicht alle Buchstaben von A-Z verwendet und auch der ASCII-Wert des Zeichens selbst spielt bei der Konvertierung keine Rolle.
Es wurde von eQ-3 eine eigene Umwandlungsmethode gebaut

Insgesamt ist es aus meiner Sicht fraglich, in wie weit es sich lohnt, irgendwas für den HMIPSever-Offline-Betrieb in die WebUI einzubringen.

Wie oft wird der Online-Kontakt zum Frontend hergestellt?
So gut wie nie.
- Anlernen von Geräten
Ist die Online-Verbindung aus irgendwelchen Gründen nicht möglich, bleibt ja wie bereits implementiert, die Möglichkeit, lokal mit SGTIN und KEY anzulernen.
1x eintippen (oder einscannen) muss man die Zeichenfolgen so oder so.

- Funkmodul-Tausch
Kommt noch seltener vor.


Es sollte inzwischen auch klar sein, dass es nicht an der Verbindung zum eQ-3 Server liegt, wenn Geräte nach einem Funkmodul-Tausch (lange) nicht erreichbar sind.

Der erste Beitrag im Thread sollte auch in erster Linie dazu dienen, zu verdeutlichen, dass es im Notfall auch ohne eQ-3-Verfügbarkeit irgendwie weitergehen und man trotzdem ein Funkmodul / die Zentrale austauschen kann.

[hce]

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...