Wovor schützt eigentlich das Rekeying?

HMIP lokale Installation

Moderator: Co-Administratoren

hce

Wovor schützt eigentlich das Rekeying?

Beitrag von hce » 24.09.2023, 23:09

Hallo Zusammen,
Das HmIP-"Rekeying" wurde hier schon viel diskutiert, dabei ging es aber immer um das Einspielen von Backups und der Abhängigkeit von den eQ3-Keyservern. ich habe aber noch keine Diskussion darüber gefunden, welchen Zugewinn an Sicherheit es eigentlich bringt, beziehungsweise was die Bedrohungsszenarien in der Sicherheitsanalyse gewesen sein könnten, vor denen der Hersteller eQ3 sich vermittels dieses "Rekeyings" schützen wollte. (Ich schreibe Rekeying in Anführungszeichen, da mir noch nicht ganz klar ist, was da überhaupt passiert, und ob es wirklich ein Rekeying im kryptologischen Sinne ist)

Die Frage nach Sinn und Zweck des "Rekeyings" ist eine, die mir seit längerem durch den Kopf geht. Vielleicht gibt es hier im Forum ja neben den folgenden noch weitere Ideen.

Folgende Überlegung: Ich habe einige HmIP-Aktoren und Sensoren an eine CCU3/RM angelernt. Irgendein Key (NWK?) liegt nur im Funkmodul. Ich mache nächtliche Backups auf einen an die CCU3 angesteckten USB-Stick, diese Backups enthalten aber prinzipbedingt nicht diesen NWK des Funkmoduls, da dieser sich zwar benutzen, nicht aber auslesen lässt.

a) Ein Einbrecher bricht bei mir ein und klaut mir den Stick von meiner CCU. Nun spielt er das Backup auf seine eigene CCU. Das kann er erstmal nicht nutzen, da er den NWK meines Funkmoduls nicht kennt. Aber dank der Keyserver von eQ3 kann er nun ein "Rekeying" durchführen, und bekommt nun doch Zugriff auf alles.

-> Abhilfe würde schaffen, dass man bei eQ3 seine Geräte bei Verlust des Backups "blacklisten" oder auf bestimmte Funkmodule beschränken lassen kann. Bietet der Hersteller so eine Funktion an? Würde das skalieren? Wie würde denn ein Kunde mit hunderten von SGTINs/Devices seine Eigentümerschaft effizient und automatisierbar nachweisen?

b) Jemand nutzt ein 0day in meinem Router und ein weiteres in meiner CCU3/RM. Nun hat er Zugriff auf die dort abgelegten Keys und kopiert sie sich. Anschließend kommt er mich besuchen und will mit diesen Keys mein HmIP-Alarmsystem abschalten. Aber das kann er nicht, weil er nämlich trotz aller 0days den NWK aus dem Funkmodul nicht herausbekommen hat. Deshalb kontaktiert er die eQ3-Keyserver und bekommt dank Rekeying nun doch Zugriff auf mein HmIP-System.

-> Gleiche Anmerkung wie bei a)

c) Ein Auditor kommt vorbei und fragt: "Liegen da Schlüssel im Klartext auf einem auslesbaren Speicher?" Der Anwender sagt: "Nein, das ist alles brav in einem HSM abgelegt." Der Auditor denkt sich: "Wunderbar!", rückt sich sein Klemmbrett zurecht, macht ein Häkchen auf seiner Checkliste und geht weiter.

Meinungen zu meinen Ideen a - c?

Weitere Ideen? :-)

Xel66
Beiträge: 14277
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 599 Mal
Danksagung erhalten: 1527 Mal

Re: Wovor schützt eigentlich das Rekeying?

Beitrag von Xel66 » 25.09.2023, 09:13

Die Funkmodule haben neben den Key eine eigene feste, für den Anwender nicht änderbare, Seriennummer (vergleichbar einer MAC) und diese ist als Kommunikationspartner den angemeldeten Geräten bekannt. Darum können Geräte auch nur an einer Zentralinstanz angemeldet sein. Der Key wird u.a. auch aus der Seriennummer des Funkmoduls abgeleitet. Somit sind die Gedankengänge a bis c obsolet, weil sie von falschen Voraussetzungen (ausschließliche Abbildung in Software) ausgehen.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

frd030
Beiträge: 3693
Registriert: 14.07.2019, 20:49
System: CCU
Hat sich bedankt: 863 Mal
Danksagung erhalten: 561 Mal

Re: Wovor schützt eigentlich das Rekeying?

Beitrag von frd030 » 25.09.2023, 09:50

Nichtsdestotrotz könnte man einen neuen Schlüssel auch auf der CCU3 selbst erzeugen.
Das öfter gehörte Argument, dass die Rechenleistung nicht ausreiche, galt vielleicht für die CCU1 oder die CCU2.

Zum Grund des Herstellers das Berechnen zentral zu machen, mußt Du bei ihm selber erfragen. Ich vermute, es hängt mit der Cloud Lösung zusammen, da der Schlüssel die Kommunikation mit den HmIP Geräten absichert.

hce

Re: Wovor schützt eigentlich das Rekeying?

Beitrag von hce » 25.09.2023, 11:30

frd030 hat geschrieben:
25.09.2023, 09:50
Nichtsdestotrotz könnte man einen neuen Schlüssel auch auf der CCU3 selbst erzeugen.
Das öfter gehörte Argument, dass die Rechenleistung nicht ausreiche, galt vielleicht für die CCU1 oder die CCU2.
Denke ich viel zu kompliziert und der Grund für diesen Keyserver ist eigentlich ganz banal und letztlich nur ein "ugly hack"?

Um symmetrische Schlüssel zu erzeugen, braucht man aber keine hohe Rechenleistung. Hier reicht es, wenn man (guten) Zufall hat. Der Zufall eines raspis dürfte ausreichend gut sein, und über das Funkmodul könnte man sich noch "echte" Entropie dazuholen...
frd030 hat geschrieben:
25.09.2023, 09:50
Zum Grund des Herstellers das Berechnen zentral zu machen, mußt Du bei ihm selber erfragen. Ich vermute, es hängt mit der Cloud Lösung zusammen, da der Schlüssel die Kommunikation mit den HmIP Geräten absichert.
Ha! Wir erfolgreich das wohl sein wird? Der Hersteller ignoriert ja sogar Bugreports nach allen Regeln der Kunst, von "nicht reproduzierbar" bis "bitte über Fachpartner einreichen!", bis man in einem Video nachweist, dass es den Bug gibt, und auch dann kommt auch nicht viel mehr als "ja mei".

Ich hatte gehofft, hier in der Community ein bisschen zu "brainstormen". Vielleicht kommen uns ja noch Ideen und das Rätsel wird irgendwann gelöst :-)

frd030
Beiträge: 3693
Registriert: 14.07.2019, 20:49
System: CCU
Hat sich bedankt: 863 Mal
Danksagung erhalten: 561 Mal

Re: Wovor schützt eigentlich das Rekeying?

Beitrag von frd030 » 25.09.2023, 11:47

hce hat geschrieben:
25.09.2023, 11:30
Ich hatte gehofft, hier in der Community ein bisschen zu "brainstormen". Vielleicht kommen uns ja noch Ideen und das Rätsel wird irgendwann gelöst :-)
Ja, der Support ist -äh- "legendär".
Das "Rätsel" wird ohne den Hersteller nicht lösbar sein, alles andere ist m.E. kein "brainstormen", sondern wilde Spekulation und Rumraterei, IMHO.

Xel66
Beiträge: 14277
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 599 Mal
Danksagung erhalten: 1527 Mal

Re: Wovor schützt eigentlich das Rekeying?

Beitrag von Xel66 » 25.09.2023, 11:53

Welches Rätsel? Das initiale Keying kann man auch lokal erledigen, sonst gingen ja die manuellen Anlernvorgänge mit KEY und STGIN nicht. Das Rekeying automatisiert den Vorgang bei einem Wechsel des Funkmoduls (kommt im Regelfall bei einem CCU3-Nutzer eher selten vor). Ist also eher eine Komfortangelegenheit. Zu dem ganzen Thema gab es auch schon mal einen Thread. Ein neuer wird eher keine neuen Fakten zutage fördern.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

hce

Re: Wovor schützt eigentlich das Rekeying?

Beitrag von hce » 29.09.2023, 15:13

frd030 hat geschrieben:
25.09.2023, 11:47
hce hat geschrieben:
25.09.2023, 11:30
Ich hatte gehofft, hier in der Community ein bisschen zu "brainstormen". Vielleicht kommen uns ja noch Ideen und das Rätsel wird irgendwann gelöst :-)
Das "Rätsel" wird ohne den Hersteller nicht lösbar sein, alles andere ist m.E. kein "brainstormen", sondern wilde Spekulation und Rumraterei, IMHO.
Na ja, so ganz stimme ich da nicht zu.

Man kann sich ja Gedanken machen, wie man selbst so ein System implementieren würde, basierend auf dem Allgemeinwissen, das über Krytographie verfügbar ist und dem Halbwissen, das wir über das HmIP-System haben:

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.
2) Es gibt pro Aktor/Sensor einen DLK (Device Local Key), der auch dem Kunden mitgeteilt wird
3) Man kann ein Backup erstellen, aber Einspielen auf anderem Funkmodul geht nur mit eQ3-Keyserver
4) Beim Anlernen passiert irgendein Handshake und vermutlich wird ein Session Key ausgehandelt
5) Laut Hersteller kann selbiger einen für den Reset gesperrten Aktor/Sensor nur durch Firmware-Flash resetten, also nicht "over the air"
6) Das zentrale Funkmodul kann nicht nur mit dem FLK verschlüsselte Daten senden/empfangene Daten mit dem FLK entschlüsseln, sondern es tut das auch für Daten, die über andere Funkmodule kommen, z.B. über den HAP
7) Ich bin mir inzwischen ziemlich sicher, dass der "Security Key", den man auf der Zentrale setzen kann, keinen neuen abgeleiteten Session Key auf die Devices propagiert, sondern lediglich die Zentrale zusätzlich schützen soll.

Aus Punkt 5 können wir schließen, dass
Xel66 hat geschrieben:
25.09.2023, 11:53
[...]Rekeying automatisiert den Vorgang bei einem Wechsel des Funkmoduls[...] Ist also eher eine Komfortangelegenheit.[...]
so nicht stimmen kann.

Nun überlege ich, wie würde ich ein solches System designen? Ich würde in jedem Falle einen zentralen Keyserver vermeiden wollen.

Problem ist, dass man eigentlich beide Funkmodule bräuchte, um die Aktoren/Sensoren vom alten auf das neue umzulernen. Und hmm, da kommt mir gerade ein Gedanke, nämlich der, dass der eQ3-Keyserver vielleicht die FLKs kennt und die Funktion des alten Funkmoduls übernhemen kann, während die Aktoren/Sensoren auf das neue umgelernt werden. Und vielleicht ist das schon des Rätsels Lösung.

Ich würde das trotzdem anders machen. Die Abhängigkeit von so einem Keyserver ist einfach zu groß...

Benutzeravatar
Baxxy
Beiträge: 11064
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 634 Mal
Danksagung erhalten: 2293 Mal

Re: Wovor schützt eigentlich das Rekeying?

Beitrag von Baxxy » 29.09.2023, 16:08

hce hat geschrieben:
29.09.2023, 15:13
3) Man kann ein Backup erstellen, aber Einspielen auf anderem Funkmodul geht nur mit eQ3-Keyserver
Hmm, das habe ich so nicht in Erinnerung, ist aber auch schon etwas her. Die Funkmodule selbst haben doch auch einen DLK, zumindest den Bausätzen RPI-RF-MOD und HmIP-RFUSB liegt der Aufkleber bei. Hast du die in die sgtin_map eingetragen?

7. hat keine Bedeutung für HmIP

hce

Re: Wovor schützt eigentlich das Rekeying?

Beitrag von hce » 30.09.2023, 07:31

Baxxy hat geschrieben:
29.09.2023, 16:08
hce hat geschrieben:
29.09.2023, 15:13
3) Man kann ein Backup erstellen, aber Einspielen auf anderem Funkmodul geht nur mit eQ3-Keyserver
Hmm, das habe ich so nicht in Erinnerung, ist aber auch schon etwas her.[...]
Nanu? Du hast doch einen großen Beitrag zu dem Thema im Original-Thread dazu ( viewtopic.php?f=31&t=78091 ) geschrieben.

Schön wäre es, wenn es nicht so wäre, dann gäbe es ja diese ganze Aufregung nicht.
Baxxy hat geschrieben:
29.09.2023, 16:08
Die Funkmodule selbst haben doch auch einen DLK, zumindest den Bausätzen RPI-RF-MOD und HmIP-RFUSB liegt der Aufkleber bei. Hast du die in die sgtin_map eingetragen?
In die sgtin_map nicht, aber in die hmip_user.conf als Network.Key. Das hat aber nicht geholfen.

Benutzeravatar
jmaus
Beiträge: 9925
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 467 Mal
Danksagung erhalten: 1920 Mal
Kontaktdaten:

Re: Wovor schützt eigentlich das Rekeying?

Beitrag von jmaus » 30.09.2023, 09:20

hce hat geschrieben:
29.09.2023, 15:13
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.
Dieser lange Satz erklärt doch bereits alles. 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. 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.

Und wenn man nun eben das Funkmodul wechselt passt der private key dieses anderen Funkmodul eben nicht mehr zu dem public key der für die aktuelle Verschlüsselung aktiv ist und das Funkmodul kann folglich die Kommunikation mit den Geräten nicht mehr vornehmen. Man müsste also quasi den private key des neuen Funkmodules haben um sich einen neuen public key zu erzeugen der dann für die weitere Kommunikation genutzt wird. Und genau hier kommt nun eben meinem Verständnis nach der Keyserver ins Spiel. Diesem wird eben mehr oder weniger das neue Funkmodul mitgeteilt und es kramt damit den private key raus und generiert diesen neuen public key und sendet ihn an die CCU.

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.

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.
RaspberryMatic 3.75.7.20240601 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Antworten

Zurück zu „HomeMatic IP mit CCU“