Eines meiner Hobbies ist Heimautomation, also quasi das Programmieren der eigenen vier Wände. Neben dem eigentlichen Zweck, dem Automatisieren immer wiederkehrender Vorgänge, ist das Anbinden der verschiedenen „Insel-Gewerke“ eine beständige Herausforderung und enormer Zeitfaktor, da hier oft keine Dokumentation der Schnittstelle(n) vorhanden ist.

Die Zeit der Kopplung

Da Mensch mit seiner Kopplungsproblematik meistens nicht alleine ist findet der geübte Google-Nutzer sehr oft eine Dokumentation bzw. den Quelltext einer (fast) fertigen Kopplung – erstellt von Enthusiasten, die hierfür in Web-Foren ihr Wissen, Hirn und Zeit zusammenschmeissen.

Manchmal findet man aber auch nichts, bzw. nur Ansätze die nicht weiter verfolgt wurden. So ging es mir mit dem Buderus Web-Gateway KM200. Es redet mit der zugehörigen App in Standards wie HTTP mit JSON bzw. XMPP, aber der Nutzinhalt aka Payload ist verschlüsselt, und keiner in der weltweiten Community hat herausgefunden wie diese Verschlüsselung genau funktioniert. OK, dachte ich mir, also bist Du jetzt mal an der Reihe damit anzufangen.

Belauschen kann man die „Gespräche“ zwischen App und Gateway auf dem Netzwerk z.B. mit der fantastischen Open-Source-Software Wireshark. Diese Mitschnitte zeigten mir, dass die verschlüsselten Daten bei einigen Aufruf-Adressen (welche unverschlüsselt übertragen werden) bestimmte Ähnlichkeiten aufwiesen. Setzte ich ein anderes Benutzerpasswort waren die Daten andere, aber die genannten Adressen wiesen erneut Ähnlichkeiten auf. Dies lässt auf einen zur Laufzeit generierten, vom Benutzerpasswort abhängigen Schlüssel und ein symmetrisches Verschlüsselungsverfahren schließen.

Also fragte ich bei der in der App angegebenen Kontaktadresse nach, wie ich denn die Payload entschlüsseln könne, und verschwieg auch nicht meinen bisherigen Kenntnisstand. Nach vier Tagen kam eine nichtssagende negative Antwort zurück. Damit hatte ich eigentlich gerechnet, aber eine positive Überraschung wäre ja auch mal nett gewesen.

Instrumentalisierung für Interoperabilität

Jetzt war also Beobachten der iOS-App angesagt. Hierfür eignet sich das exzellente Open-Source „Code-Instrumentalisierungs-Toolkit“ Frida ganz hervorragend. Wer sich mit den Richtlinien zur Programmierung unter iOS auskennt weiss, dass für symmetrische Verschlüsselung nur die Cryptografie-Bibliothek CCCrypt von Apple verwendet werden darf. Ein paar Hooks bei Aufruf und Verlassen der zentralen Crypto-Funktionen gesetzt und man weiss wie der Hase läuft, dann noch Aufruf- und Rückgabeparameter ausgeben lassen und diese Daten über den Wireshark-Mitschnitt zuordnen – fertig ist die Laube. Eigentlich ganz einfach, denn wie man Crypto richtig implementiert steht in jedem vernünftigen Lehrbuch zum Thema, und hier fand es offensichtlich Anwendung.

Nun hatte ich alle Fragmente in der Hand und implementierte damit eine Crypt- und eine Decrypt-Funktion, die beide auf Anhieb funktionierten. Wow! Weiterhin untersuchte ich den Netzwerkverkehr in verschiedenen Arbeitsphasen von App und Gatway (z.B. erste Passwortvergabe, Kommunikation mit zentralem Buderus-Server) und konnte feststellen, dass die Verschlüsselung hier ordentlich implementiert wurde. Warum ich das tat, dazu gleich näheres.

Security by Obscurity?

Der Dreh- und Angelpunkt einer symmetrischen Verschlüsselung (in diesem Fall AES) ist der Schlüssel (in diesem Fall mit 256 Bit Länge). Dieser besteht aus dem Benutzerpasswort (flexibel) und dem Gerätepasswort (fest, auf dem Gerät aufgedruckt), die zusammen mit einem Salt in einen MD5-Hash gewandelt und dann konkateniert werden. Dieses Verfahren stellt sicher, dass (derzeit) aus dem Schlüssel das Passwort nicht wieder hergestellt werden kann, auch wenn das Salt bekannt ist.

Die Schlüssel der weiteren Kommunikation werden nach ähnlichem Schema generiert, auch hier spielt das Salt seine zugedachte Rolle. Dies war ausschlaggebend für meine Entscheidung, meine Erkenntnisse inklusive des Salts zu veröffentlichen, denn es erfolgt damit an keiner Stelle eine Kompromittierung der Sicherheitsarchitektur.

Warme Semmeln

Meine Veröffentlichung im Community-Forum von IP-Symcon war ein Erfolg, denn viele Nutzer hatten ihr KM200 schon abgeschrieben bzw. ausgebaut, da ihnen eine Kopplung nicht gelungen war – jetzt war ihnen endlich eine sinnvolle Nutzung möglich. Schnell wurden hier Informationen von verschiedenen Heizungsinstallationen ausgetauscht um ein möglichst vollständiges Bild aller darstellbaren Parameter zu bekommen. Ich implementierte zu dem bereits funktionierenden Lesen noch das Schreiben von Parametern sowie das automatisierte Auslesen der gesamten Anlage, und postete mein Coding im Forum.

Dann kam das gute Wetter, und ich sass abends öfter auf der Terrasse als am Computer. Und dann kam die Bosch Thermotechnik GmbH und forderte den Forenbetreiber auf meine Postings zu löschen, wegen „Verletzung des Urheberrechts“.

Urheberrecht als Monopolgarant

Dass der Forenbetreiber bei dieser Drohkulisse prompt reagierte ist für mich absolut nachvollziehbar, das finanzielle Risiko bei einer Rechtsstreitigkeit mit Bosch ist schon immens. Aber jetzt war ich sauer. Ich habe mit meiner Arbeit eine Interoperabilität mit einer anderen Software hergestellt, was mir nach § 69e Abs. 1 UrhG auch zusteht. Nach Abs. 2 ist die Weitergabe an Dritte statthaft, wenn dies für mein Programm notwendig ist, was gegeben ist. Und da ein veröffentlichter Salt kein Sicherheitsrisiko darstellt trifft Abs. 3 auch nicht zu. Eine umfangreichere Stellungnahme habe ich im betroffenen Forum gepostet.

Hier wird von Bosch Thermotechnik GmbH offensichtlich versucht, das Urheberrecht als Instrument zur Monopolisierung ihrer Heizungsbedienungen zu mißbrauchen. Die Payload eines simplen Protokolls, welches übrigens in der App über eine Open Source Komponente implementiert wurde, wird mit 32 Byte „schützenswertem“ Salt verschleiert, damit man Konkurrenz außen vor halten kann – und eben auch den zahlenden Kunden.