EnOcean Secure: wie gebe ich den initialen Sicherheitsschlüssel (PSK) ein ?

Begonnen von IPWF, 04 März 2023, 18:56:23

Vorheriges Thema - Nächstes Thema

IPWF

Hallo,

meine Frage bezieht sich (noch) nicht auf ein konkretes Gerät, sondern zunächst allgemein auf die EnOcean-Verschlüsselung bei RORG=31 (secure telegram with encapsulation).
Die Perl-Kryptographie-Module sind installiert. Im Logfile steht "EnOcean Cryptographic functions available", also soweit alles vorbereitet.
Mit "define <DeviceName> EnOcean <EnO-ID>" habe ich schon mal ein "leeres" Gerät angelegt.

Der initiale Sicherheitsschlüssel (PSK) liegt als String vor (32 Zeichen = 16 byte hex).
Dieser muß der SmartHome-Software (hier also FHEM) mitgeteilt werden, bevor der eigentliche Einlernprozeß gestartet wird.
Doch wie mache ich das? Mit welchem Befehl bzw. welcher Prozedur kann ich FHEM diesen PSK mitteilen ?
FHEM auf Hardkernel ODROID-N2+ mit Ubuntu 22.04 LTS
Funkschnittstelle EnOcean

klaus.schauer

Der von EnOcean festgelegte private Schlüssel ist in den Routinen des EnOcean-Moduls bereits eingearbeitet.

Geräte werden verschlüsselt ausschließlich über ein spez. Anlernprotokoll automatisiert mit allen notwendigen Parametern (Attributen) angelernt. Eine manuelle Einrichtung eines Devices ist im EnOcean-Protokoll weder vorgesehen noch möglich. In der commandref gibt es ein Kapitel zur Verschlüsselung. Dort wird der Ablauf beschrieben.

IPWF

Hallo,
danke für die prompte Antwort.
Das entsprechende Kapitel in der commandref (und auch im Wiki) habe ich gelesen, aber irgendwie passt das nicht zu meinem Fall, da es sich offenbar auf einen anderen Gerätetyp bezieht.
Dann sollte ich mich wohl doch auf ein konkretes Gerät beziehen:

Es geht um den eFenstergriff AutoLock der Fa. Hoppe. Dieser verfügt über ein motorisches Schloß, außerdem übermittelt er den Status des Griffs (offen/gekippt/geschlossen, wie bei den SecuSignal-Griffen dieses Herstellers.
Der AutoLock verwendet das EEP D2-06-40, welches m.W. leider noch nicht von FHEM unterstützt wird (ich hoffe, das ändert sich bald). Mir geht es hier aber erst mal nur um die Verschlüsselung. Zum Gerät selbst sollte ich wohl besser einen eigenen Thread aufmachen, oder ?

Der Hersteller legt diesen Geräten einen Aufkleber mit einem QR-Code bei, welcher den PSK enthält. Diesen habe ich ausgelesen.

Zum Ablauf des Anlernens gibt Hoppe folgenden Hinweis :
"Der Entschlüsselungsvorgang läuft folgendermaßen ab:
a) EURID und PSK des AutoLock an GW geben (per QR-Scan, nicht per EnOcean Funk!) und GW in Einlernzustand versetzen.
b) Am AutoLock TeachIn auslösen, die zugehörige Message wird mit PSK verschlüsselt.
c) GW entschlüsselt Teach-In Message des Autolock mit Hilfe des PSK und entnimmt daraus PK des AutoLock für TX-Richtung zu GW.
d) GW erzeugt PK für TX-Richtung zu AutoLock, verpackt diese in die Teach-In Antwort und verschlüsselt mit PSK.
e) AutoLock decodiert diese Message mit dem PSK, entnimmt der Antwort EURID und PK des GW und merkt sich diese Infos.
f) Ab diesem Zeitpunkt erfolgt die Kommunikation zwischen AutoLock und GW ausschließlich mit Hilfe der beiden ausgetauschten PSKs und ab jetzt wird auch der RLC genutzt und überwacht."

Dieser Ablauf scheint doch etwas anders zu sein als von Dir beschrieben, oder verstehe ich da was falsch ?
FHEM auf Hardkernel ODROID-N2+ mit Ubuntu 22.04 LTS
Funkschnittstelle EnOcean

klaus.schauer

Bei den beschriebenen Funktionen scheint es sich um eine firmenspezifische Erweiterung von Hoppe zu handeln. Sowohl das Anlernen als auch Funktionen des spätere Betrieb insbesondere die (zentrale) Freigabe einer Fensteröffnung sind nicht Bestandteil der EnOcean-Standards. Die EEP-Beschreibung D2-06-40 http://tools.enocean-alliance.org/EEPViewer/profiles/D2/06/40/D2-06-40.pdf ist so dürftig, sodass ich nicht erkennen kann, wie man das funktionsfähig im EnOcean-Modul abbilden kann, schade.

Leider habe ich in letzter Zeit die Erfahrung gemacht, dass die Firmen sich zunehmend ihr eigenes Universum bauen. Da ist das EnOcean-Protokoll nur noch das Basis-Transportmedium. In Fhem kann man das nicht mehr verlässlich abbilden.

IPWF

Die EEP-Beschreibung D2-06-40 beschreibt ja nur das Format des einen Datenbytes, welches die gerätespezifischen Daten überträgt. Alles andere drumrum entspricht dem EnOcean-Standard für RORG=D2 (VLD) und ist in der allgemeinen EEP-Dokumentation beschrieben. Aus meiner Sicht stellt dieses Profil sogar einen besonders einfachen Fall dar.

Welche Informationen bräuchtest Du denn für die Umsetzung ?
Ich kann Dir gerne entsprechende Dokumente zusaammenstellen und habe auch Kontakt zu einem Entwickler bei Hoppe, bei dem ich ggf. nachfragen könnte. Er hat mir gegenüber schon mal angedeutet, daß Interesse an einer Umsetzung in FHEM bestünde.

Ich bin gern bereit, einen Beitrag zur Umsetzung zu leisten. Mir ist das sehr wichtig, weil ich aufgrund einer Schwerbehinderung meine bisherigen Fenstergriffe nicht mehr serlbst auf- und zuschließen kann. Die AutoLock-Griffe wären da eine große Hilfe. Ich habe die schon seit einiger Zeit hier liegen und versuche, die irgendwie ansteuern zu können. Ich kann auch gern hier Tests an den Geräten durchführen, wenn ich damit helfen kann.

Noch eine organisatorische Frage: da es nun ja um diese konkreten Fenstergriffe geht, ist es unter der Überschrift "EnOcean Secure: ..." vielleicht off-topic; soll ich dazu lieber einen eigenn Beitrag eröffnen, damit es später im Forum leichter zu finden ist ?
FHEM auf Hardkernel ODROID-N2+ mit Ubuntu 22.04 LTS
Funkschnittstelle EnOcean

klaus.schauer

Ein VLD-Telegramm zu codieren ist nicht das Problem. Solange ich aber keine vollständige Beschreibung der Kommunikations- und Verfahrenslogik habe, kann ich weder die Umsetzbarkeit noch den Aufwand abschätzen. Wenn die Fa. Hoppe Interesse an einer Integration in Fhem hat, kann mich der Entwickler gerne unmittelbar ansprechen oder mir Kontaktdaten zukommen lassen.

Unabhängig davon könnte ich mich leider frühestens ab Mai/Juni der Sache annehmen.

kassi

Der Kernpunkt hier scheint mir die Verwendung eines PSK (Pre-Shared Key) zu sein, durch den die Übertragung des eigentlichen Sicherheitsschlüssels (PK = Private Key) im Secure Teach-in (SEC_TI) Telegramm verschlüsselt wird. Dadurch wird verhindert, dass der PK bei der Übertragung von SEC_TI abgehört werden kann. Das Verfahren ist in Kapitel 5.2.3 der EnOcean Alliance Security Specification (die haben wir gerade komplett überarbeitet, damit sie leichter verständlich ist) beschrieben:
https://www.enocean-alliance.org/sec/

Der Knackpunkt ist wie gesagt, dass der Gateway den PSK kennen muss, denn sonst kann es nicht den PK entschlüsseln.
Gängiges Verfahren zur Anlage des PSK im Gateway ist QR Code Scan via Gateway App auf dem Handy.
Alternativ einen normalen QR Code Scanner verwenden und dann manuell eintippen.

Ich kenne das spezifische Produkt nicht, aber falls der QR Code der EnOcean Alliance Labelling Specification (Kapitel 4.1):
https://www.enocean-alliance.org/productid/
entspricht, dann müsste der PSK mit dem Präfix "14Z" gekennzeichnet sein.

Vielleicht hilft das ja.

Viele Grüße,
Matthias

klaus.schauer

Wenn wirkliche Fachleute sprechen, dann scheine auch ich es zu verstehen. Die PSK-Option hatte ich bisher ausgeblendet. Da hatte ich die Fa. Hoppe wohl zu Unrecht in Verdacht. Mal sehen, wie ich das einbauen kann. Danke für den Tipp.

kassi

Fairerweise muss ich sagen, dass ich PSK in Europa auch nur sehr selten sehe  :)

IPWF

Dem AutoLock-Griff liegt ein Label mit einem QR-Code bei.
Im QR-Code finden sich folgende Informationen, durch folgende Trennzeichen getrennt:
30S: EURID (Die letzten 8 Stellen)
1P:  Product-ID
30P: Artikel-Nr.
10Z: 00
14Z: PSK (= initialer Sicherheitsschlüssel)
33L: HOPPE-Webseite

Ausgelesen sieht das dann so aus:
30S0000xxxxxxxx+1P005C0000000A+30P11869331+10Z00+14Zxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx+33Lhttp://www.hoppe.com
FHEM auf Hardkernel ODROID-N2+ mit Ubuntu 22.04 LTS
Funkschnittstelle EnOcean