Eigene ETS Produktdatenbanken erzeugen

[jolt]

Hallo Zusammen,

hat jemand schon einmal ernsthaft versucht eigene ETS Produktdatenbanken zu erzeugen? Ich würde gerne meine Arduino Projekte vernünftig in die ETS Software integrieren.

Die freebus / selfbus VD Dokumentation kenne ich. Wo an welcher Stelle scheitern selbstgebaute Product DBs? Ich konnte auf die Schnelle keine größeren Fallstricke erkennen, will aber vermeiden dass ich hier unnötig Zeit an etwas verschwende, an dem sich andere schon die Zähne ausgebissen haben

Grüße,
Florian

[vento66]

Die ETS akzeptiert nur signierte Produktdatenbanken. Also musst Du KNX Member sein, und deine Datenbank extern zertifizieren lassen. Kostet halt ein paar Tausender, dann funktionierts aber. Also am besten keine Zeit darin verschwenden.

[tuxedo]

Du musst die .knxprod-Datei entsprechend "signieren". Dazu brauchst du einen Schlüssel/ein Zertifikat, das du als nicht KNX-Member nicht besitzt.
Einfach gesagt: Dein vorhaben kannst du vergessen. Einzig das missbrauchen bestehender VD-Dateien ist "machbar". Aber etwas eigenes das mit ETS zusammen funktioniert geht nicht.

Schau doch mal in den Arduino KNX Thread hier im DIY Bereich. Ich hab da für den Arduino ein ETS-Ersatz gebastelt der das einigermaßen komfortabel löst. Ist aber noch im Alpha-Stadium.

[jolt]

Euren Flamewar habe ich natürlich schon gelesen. Ich will es wie gesagt in der ETS haben.

Das mit der Signierung ist übrigens nur teilweise richtig. Die knxprod zu signieren, ist eine Frage von ein paar Zeilen openssl Code, soweit habe ich das schon hinbekommen. Ich frage mich halt nur ob ich noch weiter forschen soll oder ob es irgendwo noch andere Hürden gibt, die ich bisher übersehen habe...

[tuxedo]

Das ist ja toll dass du das mit OpenSSL signieren kannst. Aber deine Signierung wird der ETS nicht passen. Wäre ja sonst sinnlos. Aber sag bescheid wenn du's geknackt hast.

[jolt]

Bescheid

[tuxedo]

Na und was willst du jetzt noch wissen? Und erhellst du uns jetzt noch mit ein paar Details?

[jolt]

Spaß bei Seite, eine gültige Signatur zu erzeugen ist kein Problem. Das macht die ETS jedes mal wenn man ein VD importiert. Die Infos liegen alle da. Code kann ich gerne zur Verfügung stellen.

[tuxedo]

Okay, jetzt sind wir etwas schlauer. Was noch fehlt ist deine eigentliche Frage/dein eigentliches Problem, und für die Cracks unter uns die sich das mal anschauen wollen der Code.

[jolt]

Na und was willst du jetzt noch wissen? Und erhellst du uns jetzt noch mit ein paar Details?

Sorry, deine Frage ist mir durchgerutscht. Konkret würde ich gerne wissen ob sich jemand näher mit den XML Files beschäftigt hat.

knx_master.xml scheint immer das gleiche zu sein, da brauchen wir also nicht dran.

.signature ist erforscht, das kann man mit den ETS Daten erzeugen

catalog.xml scheint "nur" XML zu sein, ich kann jedenfalls nichts erkennen.

<product id>.xml hier scheint es einen Hash zu geben der das ApplicationProgram umfasst. Das müsste man noch näher erforschen.

hardware.xml Hier wird es spannend, es gibt hier eine RegistrationSignature, wenn ich das bisher richtig verstanden habe, wird diese über den gleichen RSA Key erzeugt wie die Product Signature.

Wie gesagt, ist noch etwas Forschungsaufwand nötig, alles was es an Vorerkenntnissen irgendwo gibt, wäre hilfreich.

Danke!

[tuxedo]

Bzgl. signierung dachte ich bisher die XML Daten in der knxprod werden signiert. D.h. wenn man etwas an den XML Daten ändert, ist die Signierung dahin?!

Die XML Daten habe ich mir schon etwas angetan. Ist machbar, aber nicht sooooo easy. Es werden an allen Ecken und Enden Quer-Verweise mit IDs verwendet. Das macht es schnell aufwendig. Dokumentiert habe ich das aber noch nicht. Man kann sich aber recht einfach "durchhangeln". Anfassen musst du aber - wenn ich mich recht erinnere - unter'm Strich mehr als eine Datei.

[jolt]

Es werden von allen Dateien im Zip SHA1 Summen gebildet, die dann an einander gehängt werden. Daraus wird dann wieder eine SHA1 Summe erzeugt und diese Signiert. Das soll offensichtlich die Dateien vor Manipulation schützen.

Zusätzlich gibt es einen Mechanismus für Application Code, der vermutlich dafür sorgen soll, dass kein Binär Müll in die Device hochgeladen wird. Und dann gibt es noch einen Signierungsmechanismus auf Device Ebene. Hier scheint es drei Zustände zu geben:

Unregistered. Keine Ahnung was das für ein Zustand ist.

Registered. Das ist der Zustand wenn man eine VD Datei importiert. Die ETS4 lädt solche Dateien jedenfalls ohne zu murren. Signatur wird offensichtlich mit dem gleichen Private RSA Key erzeugt wie die Gesamt Signatur.

Certified. Vermutlich für offiziell getestete Devices. Es gibt dafür keinen hinterlegten Private Key, der muss von außen in der ETS angemeldet werden. In der ETS gibt es aber einen Public Key mit dem die Signatur überprüft werden kann.

Theorie: Uns würde der Registered Modus reichen. Den können wir selbst signieren. Theoretisch, praktisch müsste man forschen welche Teile des XML gehasht werden.

Zum XML Selbst: Meine Idee wäre das wir die vorhanden Config Tools so erweitern, das man auch eine Product DB erzeugen kann. Damit das ganze DIY tauglich wird, können wir auf keinen Fall alle Leute in den XML Files herum editieren lassen.

Richtig krank ist allerdings das VD Format. Nachdem ich mir das Passwort für die Files besorgt hatte, dachte ich, ich bekomme Augenkrebs Wer sich immer nur so etwas ausdenkt... Jedenfalls habe ich mich dann ganz schnell auf das ETS4 Format beschränkt, in der Hoffnung hier etwas weniger denken zu müssen

[tuxedo]

Es werden von allen Dateien im Zip SHA1 Summen gebildet, die dann an einander gehängt werden. Daraus wird dann wieder eine SHA1 Summe erzeugt und diese Signiert. Das soll offensichtlich die Dateien vor Manipulation schützen.

So sieht's aus. Was ich an der Sache noch nicht verstehe: Beim tatsächlichen signieren: Wie bist du an den private key gekommen? Oder frisst die ETS im "registered" einfach alles, hauptsache irgendwie signiert?

Ich vermute mal dass die drei Zustände die Entwicklungsphase eines KNX Geräts abbilden. Registered wird der Zustand sein, den das Gerät hat, wenn es noch nicht durch die Konnex zertifiziert und getestet wurde. Müsste also durchaus ausreichend sein. Könnte mir aber vorstellen dass es in der ETS hierfür noch Restriktionen gibt.

Zum XML Selbst: Meine Idee wäre das wir die vorhanden Config Tools so erweitern, das man auch eine Product DB erzeugen kann. Damit das ganze DIY tauglich wird, können wir auf keinen Fall alle Leute in den XML Files herum editieren lassen.

FullACK ... Das XML Format ist schon recht komplex. Da sollte man ein Tool haben das das erzeugt.

Das VD-Format ist schon etwas "antiquiert"...


btw: Das XML Format verstehen und entschlüsseln ist eine Sache. Dem Arduino beibringen dass die ganzen ETS Kommandos ihn programmieren ist eine andere. Habe hier schon viel experimentiert. Das ganze verschlingt recht schnell recht viel Speicher im Arduino, was auch der Grund für eine "abgespeckte, nicht wirklich ETS konforme Speicherung der Daten" war. Auch haben sich Effekte ergeben die ich nicht genau erklären kann und die ich in mehrstündigen Debug-Sessions nicht gelöst bekommen habe. Ich vermute hier ein Timing-Problem. Der Arduino ist sicher schnell genug, aber irgendwas passt im Arduino-KNX Stack da noch nicht. D.h. hier ist auch noch einiges zu erledigen damit das ETS kompatibel werden kann (wenn man sich dadurch nicht den Speicher der Arduino zu voll stopft)

[jolt]

So sieht's aus. Was ich an der Sache noch nicht verstehe: Beim tatsächlichen signieren: Wie bist du an den private key gekommen? Oder frisst die ETS im "registered" einfach alles, hauptsache irgendwie signiert?

Die ETS akzeptiert nur Signaturen, die mit dem richtigen Private Key erzeugt wurden. Der Key ist in der ETS eingebaut und lässt sich wie folgt extrahieren:

<REMOVED>

Ich vermute mal dass die drei Zustände die Entwicklungsphase eines KNX Geräts abbilden. Registered wird der Zustand sein, den das Gerät hat, wenn es noch nicht durch die Konnex zertifiziert und getestet wurde. Müsste also durchaus ausreichend sein. Könnte mir aber vorstellen dass es in der ETS hierfür noch Restriktionen gibt.

Da alle importierten VD Datenbanken auch "nur" registered sind, gehe ich davon aus dass es keine weiteren Restriktionen gibt. Ist aber bisher nur Theorie.

FullACK ... Das XML Format ist schon recht komplex. Da sollte man ein Tool haben das das erzeugt.

Das VD-Format ist schon etwas "antiquiert"...


btw: Das XML Format verstehen und entschlüsseln ist eine Sache. Dem Arduino beibringen dass die ganzen ETS Kommandos ihn programmieren ist eine andere. Habe hier schon viel experimentiert. Das ganze verschlingt recht schnell recht viel Speicher im Arduino, was auch der Grund für eine "abgespeckte, nicht wirklich ETS konforme Speicherung der Daten" war. Auch haben sich Effekte ergeben die ich nicht genau erklären kann und die ich in mehrstündigen Debug-Sessions nicht gelöst bekommen habe. Ich vermute hier ein Timing-Problem. Der Arduino ist sicher schnell genug, aber irgendwas passt im Arduino-KNX Stack da noch nicht. D.h. hier ist auch noch einiges zu erledigen damit das ETS kompatibel werden kann (wenn man sich dadurch nicht den Speicher der Arduino zu voll stopft)

Ein Problem dabei ist, dass der KNX Stack kein wirklicher Stack ist sondern eine KISS Klasse. Das Einbauen von Status behafteten Kommandos ist hier natürlich doppelt schwierig, hast du ja im Arduino Thread auch schon festgestellt. Ich habe angefangen einen Stack zu schreiben, der sich an das ISO Modell hält und auch die Namen aus der EIBA Spec verwendet. Hoffentlich lässt sich damit eine ETS Anbindung hinbekommen. Aber erst einmal müssen wir ja die DB in die ETS bekommen

[tuxedo]

Die ETS akzeptiert nur Signaturen, die mit dem richtigen Private Key erzeugt wurden.

Das dachte ich mir.

Der Key ist in der ETS eingebaut und lässt sich wie folgt extrahieren:

Damit verlagert sich das ganze zumindest in eine Grauzone... Wenn nicht sogar weiter in die "tief schwarze Zone".

Hab den passenden Abschnitt gerade nicht zur Hand. Aber wenn mich nicht alles täuscht, dann ist reverse-engineering Seitens der Konnex nicht gestattet wenn du die ETS offiziell nutzen möchtest (Stichwort AGB/EULA/Lizenz).

Auf der anderen Seite sind die schon selten dämlich (verzeiht diesen Ausdruck) wenn sie den Private Key in die Software einbauen. Ein Private Key heisst ja nicht umsonst PRIVATE Key.

Da alle importierten VD Datenbanken auch "nur" registered sind, gehe ich davon aus dass es keine weiteren Restriktionen gibt. Ist aber bisher nur Theorie.

Na dann passt das ja. Wüsste bis jetzt nicht dass es bei der verwendung "alter VD-Produktdatenbanken" in der neueren ETS Restriktionen gibt.

Ein Problem dabei ist, dass der KNX Stack kein wirklicher Stack ist sondern eine KISS Klasse.

Ja, die IMplementierung deckt die Einzelnen Layer des KNX nur unzureichend ab. Auf der anderen Seite ist die ganze KNX Telegramm-Layer Geschichte auch unnötig kompliziert, aber eben "historisch gewachsen".

Das Einbauen von Status behafteten Kommandos ist hier natürlich doppelt schwierig, hast du ja im Arduino Thread auch schon festgestellt.

Ach, das geht eigentlich. Viel schlimmer ist, dass manche Dinge einfach nicht funktionieren und der TPUart irgendwie auch keinen Fehler wirft oder Anhaltspunkt liefert woran es liegt. Da sucht man sich dann 'nen Wolf und landet bei Try&Error. Das hast du aber prinzipiell auch wenn du dich ans OSI Modell hälst.

Ich habe angefangen einen Stack zu schreiben, der sich an das ISO Modell hält und auch die Namen aus der EIBA Spec verwendet.

Löblich... Den Aufwand hatte ich bisher versucht zu vermeiden. Wäre aber für die Community super wenn die weitere Entwicklung "öffentlich" läuft. Github?

Hoffentlich lässt sich damit eine ETS Anbindung hinbekommen. Aber erst einmal müssen wir ja die DB in die ETS bekommen

Wieso nicht? Dem TPUart ist es egal wer mit ihm spricht. Hauptsache er spricht die gleiche Sprache.

Ich würde ehrlich gesagt einen Schritt weiter vorne ansetzen: Schauen dass der Stack sauber memread/memwrite sowie propread/propwrite kann. Der Rest (GA lesen/schreiben) ist pipikram. Erst wenn das läuft würde ich mir weiter Gedanken um die Ansteuerung via ETS machen. In einem ersten Schritt könnte man sogar versuchen sich wie ein existierendes KNX Gerät zu verhalten und GA-Einstellungen und Parameter via ETS entgegen zu nehmen. Wenn das klappt, dann versuchen eine eigene .knxprod ins Leben zu rufen.