[RWE-Smarthome] Funksicherheit von RWE SmartHome

[Tessi]

Hmm, für mich ist das dasselbe, sorry. RWE-SH ist weniger gut dokumentiert, ok, das verleitet Laien dazu der Marketing-Abteilung den Sums mit AES zu glauben, aber ich erkenne technisch sonst keinen grossen Unterschied..

Ich kenne die Interna längst nicht so gut. Das Homematic und SH sich sehr ähnlich sind, den Verdacht hatte ich schon länger. Aber bislang war mein Kenntnisstand der, das das alte FS20 unidirektional ohne jegliche Quittung arbeitet, HM und SH dagegen bidirektional mit Quittung (wie auch KNX), was in meinen Augen ein doch schon nicht zu verachtender Sicherheitsgewinn bezüglich der Ausführung von Kommandos ist.

[megaharry]

Ich kenne die Interna längst nicht so gut. Das Homematic und SH sich sehr ähnlich sind, den Verdacht hatte ich schon länger. Aber bislang war mein Kenntnisstand der, das das alte FS20 unidirektional ohne jegliche Quittung arbeitet, HM und SH dagegen bidirektional mit Quittung (wie auch KNX), was in meinen Augen ein doch schon nicht zu verachtender Sicherheitsgewinn bezüglich der Ausführung von Kommandos ist.

Ja , FS20 ist unidirektional, und z.B. bei den Heizungsreglern gibt das massiv Probleme, wäre mir persönlich zu nervig.

[MarkusS]

Homematic verwendet ein von EQ3 selbst gestricktes Protokoll namens BidCoS (Bidirectional Communication Standard). Die werben damit

Das Signal kann AES-Verschlüsselt (Advanced Encryption Standard) übertragen werden und ist damit auf einem der höchsten Sicherheitsniveaus.

Quelle HomeMatic (das findet sich so auch irgendwo bei EQ3/Homematic direkt Neue Funk-Alarmzentrale BidCoS). Weiterhin gerüchtet es dass dieser AES-Kram nur bei "sicherheitsrelevanten" Komponenten wie dem Türöffner überhaupt eingesetzt wird.

Da AES Encryption wird einigermassen glaubwürdig beschrieben dass es sich defacto nicht um eine Verschlüsselung sondern um ein AES-verschlüsseltes Challenge-Response-Verfahren handelt, der eigentlich Payload sei unverschlüsselt.

Für die RWE Smarthome-Komponenten wurde ein "neues" Protokoll namens CosIP (Control over Secure IPv6) gebaut. Was man mit Sicherheit sagen kann ist dass das nicht mit BidCoS kompatibel ist. Was da tatsächlich "secure" und "IPv6" ist bleibt rauszufinden. Momentan sind die Komponenten noch nicht sehr weit verbreitet und relativ neu und Leute die über das nötige Messequipment und das Know How und Zeit und Lust zum Reverse Engineering von so was verfügen stehen leider auch nicht an jeder Strassenecke.

Ich denke dass es nur eine Frage der Zeit ist bis man auch in "Hackerkreisen" auf die Sachen aufmerksam wird und und sich ernsthaft damit beschäftigt. Zumindest gibt es da Leute die in jahrelanger Kleinarbeit DECT und GSM auseinandernehmen können bis kein Stein mehr auf dem anderen ist ...

[Tessi]

um ein AES-verschlüsseltes Challenge-Response-Verfahren handelt, der eigentlich Payload sei unverschlüsselt.

So ein Quark! Wenn ich schon einen verschlüsselten Kanal für die Challenge und die Response aufgebaut habe, kann ich auch die Daten darüber senden, Wird anderswo doch auch gemacht.

[MarkusS]

Dann treten wir extra für Dich den Quark nochmal breit:

Anders als der Name vermuteten lässt, handelt es sich bei HMs ("BidCos") AES Encryption Modus nicht um tatsächlich encrypteten Funkverkehr, sondern um das Einschalten eine Signingrequest-Modus (AES Challenge-Response (CR)). Hierdurch soll sichergestellt werden, dass der Funkbefehl auch tatsächlich von der Zentrale kommt, die ihn vorgeblich gesendet hat.
Details

Wenn AES-Encryption eingeschaltet wird, führt ein Aktor einen empfangengen Befehl nicht sofort aus, sondern fragt bei der Zentrale zurück, diese muss dann mit einer Bestätigung antworten. Erst dann wird der Befehl tatsächlich ausgeführt.
Der Funkverkehr selbst ist nicht verschlüsselt.

Die Leuten von Fhem die das so beschreiben halte ich für ziemlich glaubwürdig, die Software die die um Homematic aussenrum bauen ist ziemlich gut und lässt vermuten dass die wissen was tun und sagen.

"Anderswo" ist für EQ3 - wie ich zwischenzeitlich gelernt habe, ich habe seit einigen Monaten mit Homematic beruflich zu tun - eher kein Argument.

[Tessi]

Ok, Danke.
Warum man es so "halbherzig" macht, werde ich mangels entsprechender Informatonen wahrscheinlich nie verstehen. Die Kunden scheint es ja auch nicht wirklich zu beunruhigen.
Ach wie einfach wäre doch vieles, wenn unsere Kunden auch so sorglos wären...

[makki]

Ich kenne die Interna längst nicht so gut.

Ich auch nicht im Detail, um das Gegenteil behaupten zu können, es ist mir auch ehrlichgesagt sekundär/wurscht sonst hätte ich beim Hausbau nicht C/E/eq3 durch KNX ersetzt (und KNX ist sicherheitsfrei, was ich damit nicht vom Tisch lasse, das ist falsch! aber dafür braucht man wenigstens Zugriff auf die Strippe..)

Aber ich bin mir da relativ sicher, das MarkusS und ich mit unseren Andeutungen nicht ganz falsch liegen, mit Verlaub, davon verstehen wir zuviel, um uns komplett zu irren.. Warum das mit dem angeblichen AES so auch technisch garnicht geht, also eine Lüge sein muss, hatte ich glaube ich auch schon nen Link zu ner Diplomarbeit dazu gepostet..

Ok, Danke.
Warum man es so "halbherzig" macht, werde ich mangels entsprechender Informatonen wahrscheinlich nie verstehen.

Ich auch nicht, ich sehe meine Aufgabe darin zu warnen und aufzuklären, das ist völlig brotlos, 90% sinnlos und 100% entnervend, die einzige Blume, die man sich 5-10J später davon kaufen kann, ist das man recht hatte

Ach wie einfach wäre doch vieles, wenn unsere Kunden auch so sorglos wären...

Mir wären Kunden lieber, die zuhören, ist aber selten, man muss ganz offen sagen, das es den meisten wurscht ist
Es setzt da mit den Jahren auch eine gewisse Abhärtung ein: wers nicht kapieren will, mein gott, für den reicht "AES" von der Marketing-Abteilung dann halt, was soll man machen

Makki

[Tessi]

(und KNX ist sicherheitsfrei, was ich damit nicht vom Tisch lasse, das ist falsch! aber dafür braucht man wenigstens Zugriff auf die Strippe..)

Eben, und dazu muss man in den meisten Fällen erst einmal in ein Gebäude eindringen/einbrechen. Dann aber habe ich größere Sorgen als das dadurch jemand vorübergehend Zugriff auf meinen Bus hatte... Per Funk aber können mich Kiddies aus der Nachbarschaft jahrelang terrorisieren und ich kann es am Ende nur schwer beweisen, wenn überhaupt je ermittelbar ist, wer es war. Da stelle ich dann doch erheblich größere Anforderungen an die Datensicherheit als bei der Übertragung durch ein lokales Kabelnetz.

Aber ich bin mir da relativ sicher, das MarkusS und ich mit unseren Andeutungen nicht ganz falsch liegen, mit Verlaub, davon verstehen wir zuviel, um uns komplett zu irren..

Ich traue Euch auf jeden Fall eine bessere Einschätzung der Situation zu, als derzeit mir.
Bei der momentanen Informationslage muss ich dann halt mit dem Rest-Risiko leben, das auch Ihr Euch irren könntet.

Warum das mit dem angeblichen AES so auch technisch garnicht geht, also eine Lüge sein muss, hatte ich glaube ich auch schon nen Link zu ner Diplomarbeit dazu gepostet..

Hm, den habe ich bisher übersehen/nicht gefunden...

Ich auch nicht, ich sehe meine Aufgabe darin zu warnen und aufzuklären, das ist völlig brotlos, 90% sinnlos und 100% entnervend

Also brotlos ja, sinnlos finde ich das nicht auch wenn vielleicht nur 1% zuhören und Konsequenzen ziehen, entnervend, nun ja, es ist ein wenig wie mit der Kindererziehung, nicht immer erfreulich, oft anstrengend, so manches mal vergeblich, aber trotz allem zwingend notwendig, sonst wird alles nur noch schlimmer. Also bitte nicht mit Warnen und Aufklären aufhören.

die einzige Blume, die man sich 5-10J später davon kaufen kann, ist das man recht hatte

Nun ja, manches tun wir sogar für noch weniger - und wer weiß, wofür es eines Tages gut sein wird.

Mir wären Kunden lieber, die zuhören, ist aber selten, man muss ganz offen sagen, das es den meisten wurscht ist.

Was ich sagen wollte ist, einiges wäre für uns leichter und einfacher, wenn unsere Kunden auch so kritik- und ahnungslos alles akzeptieren würden, wie wir gerade Lust haben, es ihnen anzubieten.
Aber unsere Kunden lassen sich nicht von Marketing-Blabla einwickeln.

Es setzt da mit den Jahren auch eine gewisse Abhärtung ein: wers nicht kapieren will, mein gott, für den reicht "AES" von der Marketing-Abteilung dann halt, was soll man machen

Ich gehe ja eher davon aus, das es weniger um wollen, als um können geht. Manche Sachverhalte kann man Laien einfach nicht in einem überschaubaren Rahmen vermitteln. Ich verurteile da niemanden nur weil er dann keinen missionarischem Eifer an den Tag legt. Manchmal sind mit einer einfachen "Halbwahrheit" alle Beteiligten glücklicher...


Ich wundere mich am Ende einfach immer wieder nur, mit wie schlechten Produkten man manche Kunden zufrieden stellen kann...

[makki]

Ich wundere mich am Ende einfach immer wieder nur, ...

Ich mich schon auch, aber man gewöhnt sich daran, ausgelacht zu werden, wenn man über Security spricht - und man wird mit den Jahren pragmatischer..

Was ich meinte: http://publications.lib.chalmers.se/...ext/129176.pdf - da sind so ein paar hübsche Charts (6.4) drin, wie lange es auf einem uC dauert, eine vernünftige Signatur zu prüfen; ausserdem ist es IMHO eher verständlich geschrieben und auch im Detail das warum&wieso erklärt, also wens interessiert, der sollte das lesen und sich dann nochmal die Frage stellen, ob die Aussage "AES" der Marketing-Abteilung genügt..

Makki

[EIBel]

Absolut richtig

Lieber Makki,

meine Diplomarbeit ist schon eine ganze Weile her aber der Inhalt und das Resume bestätigten schon damals Deine Bedenken.
Auf die Sicherheitsprobleme hinzuweisen ist technisch völlig korrekt und fachlich notwendig. Man weiss eben nicht gerade seit gestern das Geräte mit zunehmender Verbreitung auch erst recht interessant werden für Hacker und Intruder..man stelle sich einen Wohnblock mit 30 Wohnungen mit RWE SmartHome und einen spasslustigen Skriptie vor und schon hat man den Salat.
Da es ja Leute gibt die mit sowas Ihre Wasserkocher für den Morgentee timern kann man damit ggf. auch ein Feuer auslösen. Also sind Bedenken hier nicht theoretsicher Unsinn sondern notwendige Informationsverteilung.

BTW: Da ich beruflich auch Firewalls mache kann ich selbst nur täglich erneut davor warnen wieviele Leute echt Nerven für ständiges Hacking haben.

Zu guter letzt liegt das material auch vor mir.... sehr überzeugend ist das SmartHome Paket von RWE nicht..da hilft auch kein Stromberg.

[Tessi]

Was ich meinte: http://publications.lib.chalmers.se/...ext/129176.pdf

Nette Lektüre...
Was man einzig noch sagen könnte:
Dort wurde einem "normalen" Controller die Kryptografie beigebracht. Das ist in der Tat ein ziemlicher Recourcenaufwand. Allerdings bekommt man verschiedenste Algorithmen auch in Hardware gegossen, das ist um ein vielfaches schneller bei deutlich geringerem Stromverbrauch. Wenn man es für eine Produktfamilie von vornherein vorsieht, ist so ein Extramodul im Controller auch nicht so teuer. Ob es auch Hardware für AES gibt habe ich jetzt aber nicht geprüft.

[StefanW]

Ob es auch Hardware für AES gibt habe ich jetzt aber nicht geprüft.

AES ist nicht das Problem. AES ist symmetrische Kryptografie und gegenüber der asymmetrischen so ca. 1000 fach schneller.

Der Knackpunkt ist, dass bei symmetrischer Kryptografie die Schlüssel zum Ver- und Entschlüsseln die gleichen sind, also mindestens beide Seiten - hier z.B. Sensor und Zentrale - im Besitz dieses einen Schlüssels ("shared Secret") sein müssen.

Symmetrisches Schlüsselmaterial sollte zum einen regelmäßig getauscht werden und zum anderen ist symmetrische Kryptografie nicht wirklich für das signieren einer Nachricht (also als Herkunftsnachweis) geeignet. Klar läßt es sich irgendwie missbrauchen aber dann ist es auch nicht mehr richtig sicher weil es am Ende irgendeinen gemeinsamen Schlüssel geben muss.

Und hier wird nun die asymmetrische Kryptografie benötigt: Einmal um auf sicheren Weg den Schlüssel für die symmetrische Kryptografie zu vereinbaren und für den fortlaufenden Wechsel desselben als auch für das Signieren der Kommunikation als Herkunftsnachweis - zur gegenseitigen Authentifizierung der Kommunikationsteilnehmer.

Die Sicherheit der asymmetrische Kryptografie beruht letztlich darauf, dass ein bestimmter Rechenprozess in der einen Richtung "leicht" und in der Gegenrichtung nicht (oder nur extrem aufwändig) ausgeführt werden kann.

Damit asymmetrische Kryptografie sicher ist, muss - im Vergleich zur symmetrischen Kryptografie) mit sehr viel längeren Schlüsseln (> 1024 Bit) oder komplexen Algorithmen (Elliptic Curve) gearbeitet werden- beides stellt die für solche Produkte üblichen 8 Bit Microcontroller vor große Herausforderungen was Speicherplatz und Rechenzeit betrifft. Wie im von Makki verlinkten Dokument gezeigt wurde, geht dies in die zig Sekunden.

Darauf basiert die Annahme - und weil seitens RWE nur von AES die Rede ist, also von einem nur für Verschlüsselung aber nicht für Signatur brauchbaren Algorithmus - dass in solchen batteriebetriebenen Funkprodukten sehr vermutlich nicht genügen Ressourcen verfügbar sind, um jede Nachricht (oder jeden Schaltbefehl) mit asymmetrischer Kryptografie einzeln zu signieren. Und dass daher auch die Sicherheit gegen unbefugte Nutzung nur eingeschränkt oder gar nicht vorhanden ist.


Für alle die Verschlüsselung und Authentifizierung (Signatur) gerne durcheinander bringen:

- Die Verschlüsselung schützt davor, dass andere mitlesen können, welcher Schaltbefehl / Sensorwert gesendet wurde.

- Aber erst die Authentifizierung schützt davor, dass der Schaltbefehl nicht von einer unautorisierten Seite kommt - oder schlicht nach Aufzeichnung einfach neu gesendet wird (Reply-Attacke).


Dies ist jetzt nur ein kurzer Abriss zur Übersicht, im Detail ist das deutlich komplexer und es braucht noch Hash-Algorithmen sowie Funktionen zur sicheren Erzeugung des Schlüsselmaterials aus wirklich zufälligen Seeds (z.b. aus Widerstands- oder atmosphärischem Rauschen).

mfg

Stefan Werner

[Tessi]

Grundsätzlich hast Du recht, und wenn Schlüssel öffentlich ausgetauscht werden müssen, machen symmetrische Verfahren keinen Sinn.
Wegen des hohen Rechenaufwandes werden die asymmetrischen Verfahren dann letztlich aber auch nur zur Authentifizierung und zum Austausch eines symmetrischen Session-Schlüssels verwendet...

Aber wenn man die Geräte im Nahfeld (unter 0.5m) die Schlüssel abgleichen läßt (oder gleich über eine Kabelverbindung statt Funk), wobei abhören praktisch nicht möglich ist, dann kann man auch mit symmetrischen Schlüsseln allein relativ sicher arbeiten. Die Authentifizierung erfolgt, indem man Zufallswerte austauscht, die der jeweils andere dann verschlüsselt zurücksendet. Passen eigene Verschlüsselung und Antwort jeweils zusammen kennt das Gegenüber das gemeinsame Geheimniss - mehr beweisen asymmetrische Verfahren im Rahmen einer Authentifizierung auch nicht. Initialisiere ich nun einen Bitstream-Generator mit den eben ausgetauschten Zufallswerten, kann ich damit gleich die weitere Kommunikation verschlüsseln. Sollte jemand tatsächlich per Zufall bei der Authentifizierung ohne Kenntnis des Schlüssels eine richtige Antwort gegeben haben (weil durch irgendeinen dummen Zufall schon mal die selben Zufallszahlen verwendet wurden und das abgehört wurde), fällt spätestens jetzt durch Protokollfehler auf, das irgendwas nicht stimmt. Denn das nach den selben Seeds für die Authentifizierung auch noch identisch Daten ausgetauscht werden ist doch schon extrem unwahrscheinlich.

Wie man die Schlüssel generiert, das ist eine ganz andere Sache. Ob sie wirklich schwerer zu knacken sind, wenn sie aus thermischem Rauschen gewonnen werden...

Im Prinzip sollte man jeden Schlüssel (auch asymmetrische) öfter mal wechseln. Bringt tatsächlich aber nur was, wenn er schon geknackt wurde, oder zumindest systematisch angegriffen wird, ansonsten ist jeder Wert gleich (un)sicher, egal wie lange man ihn schon verwendet.

[Vanguard]

Gott sei Dank sind wir mit unserer SmartHome Geschichte hier im KNX Forum geblieben.
Hier sind Leute unterwegs die mich schwer beeindrucken.

Was hier auf den letzten Seiten passiert ist für mich persönlich mehr als Weiterbildung
Ich lerne gerne dazu.

@Makki
Ich finde es schön, dass du weiterhin dabei bist.

@Smarthome Team
Hört gut zu ! ;o)
Wo steckt ihr eigentlich?

So, ich habe zu tun. Eben sind die nächsten SH-Geräte eingetroffen.
Installieren ist angesagt !

[StefanW]

Die Authentifizierung erfolgt, indem man Zufallswerte austauscht, die der jeweils andere dann verschlüsselt zurücksendet.

Eher eine schlechte Idee, weil dies dann eine Known-Plaintext-Attacke prinzipiell zulässt. Dies wurde schon benutzt um die ENIGMA im II. Weltkrieg oder WEP zu knacken.

Es gibt bereits Versuche, AES auf diese Weise zu brechen, also aus bekannten Plaintext (Dein in Klartext gesendeter Zufallswert) und bekanntem Ciphertext (den mit AES verschlüsselten Plaintext) den Schlüssel zu errechnen. Bisher ist es nicht öffentlich bekannt ob es bereits geschafft wurde - allerdings das Gegenteil, dass es nicht erreichbar ist auch nicht (weil der mathematische Beweis fehlt, dass es nicht doch möglich ist, das quadratische Gleichungssystem mit extrem vielen Unbekannten - mit dem ein AES beschrieben werden kann - zu lösen).

Aber das führt - auch für mich - zu weit und wir verlassen das Topic dieses Threads.

Passen eigene Verschlüsselung und Antwort jeweils zusammen kennt das Gegenüber das gemeinsame Geheimniss - mehr beweisen asymmetrische Verfahren im Rahmen einer Authentifizierung auch nicht.

Oh doch. Die meisten asymmetrischen Verfahren benötigen kein gemeinsames Geheimnis für die Authentifizierung, andere etablieren es auf sicherem Weg.

Wie man die Schlüssel generiert, das ist eine ganz andere Sache. Ob sie wirklich schwerer zu knacken sind, wenn sie aus thermischem Rauschen gewonnen werden...

Ja, weil ein Algorithmus keinen echten Zufall erzeugen kann. Mithin sind bei unechtem Zufall die generierten Seeds vorhersagbar und dies reduziert den Ansatz für eine Brute-Force-Attacke. Darüber ist schon sehr viel geknackt worden.

Erst durch tatsächlichen Zufall - wie es eine Reihe physikalischer Effekte ermöglichen - läßt sich eine zufällige Seed generieren. Sofern es richtig gemacht ist....

Im Prinzip sollte man jeden Schlüssel (auch asymmetrische) öfter mal wechseln.

Ansich ist es durchaus Sinn der asymmetrischen Verfahren dass deren Schlüssel nicht zu oft zu wechseln sind. Nehmen wir die Keypairs von Certificate Autorities, die müssen schon ein paar Jahre halten.


Für echte Sicherheit geht an wirklich zufälligen Seeds und an asymmetrischen Verfahren bei sauberer Implementierung (die keine Seitenkanalangriffe zuläßt) und hinreichender Schlüssellänge kein Weg vorbei.

Und dies läßt sich mit den Ressourcen von 8 Bit Microcontrollern nicht machen weil Zeit- und Energieverbrauch zu groß sind.


Bitte, wir sollten hier nicht zu tief einsteigen, davon hat der Thread nichts und ich auch nicht soviel Zeit. Es ging mir nur darum, die Aussage des von Makkis verlinkten Dokuments hinsichtlich des geäußerten Zweifels an der Sicherheit von batteriebetriebenen Funksensoren und Funkaktoren zu erläutern und dass es mit AES-in-Silicon nicht getan ist.

RWE ließt hier mit. Es wäre ein leichtes die Zweifel durch entsprechende Offenlegungen zu widerlegen. Die angeführte TÜV-Zertifizierung bezog sich auf das Rechenzentrum.

lg

Stefan