Hi zusammen,
ich habe für die Jarolift TDEF Funk-Motoren (
Link), von denen ich 10 Stück mehr als zufrieden im Einsatz habe, CUL-FW und FHEM erweitert. Dazu war es nötig CUL-FW die Keeloq-Verschlüsselung bei zu bringen sowie die zugehörigen Rolling-Code Idess zu implementieren (aktuell im FHEM Modul). Beides läuft nun super. Ich würde das gerne auch Euch allen zu Verfügung stellen, sehe aber rechtliche Probleme:
1. KEELOQ Patent
Die Implementierung der Verschlüsselung selbst in der CUL-FW ist relativ unkritisch, da das wohl nicht geschützt ist. Ich nutze eine eine GPL Implementierung von Jiri Pittner, zu finden
hier.
Kritisch ist die Methode, die als Rolling-Code beschrieben wird, nämlich die Tatsache dass es in jedem Telegramm einen Zähler gibt, der mit verschlüsselt wird, und nur wenn der Zähler jedes Mal inkrementiert wird akzeptiert der Empfänger die Telegramme (stark vereinfacht, die Datenblätter zur Keelog-Hardware bei Microchip sind ausfürhlicher, wenn's Euch interessiert:
Keeloq Website).
Hier habe ich Bedenken. Welcher Rechtlichen Aspekte hat eine Implementierung in GPL???
2. KEELOQ Key von Jarolift
Zentraler Dreh- und Angelpunkt von Keeloq ist der private Hersteller-Key. Dieser ist unter normalen Umständen nur durch Side-Channel-Attacks zu bekommen, eine Rückrechnung aus den Funktelegrammen ist nahezu unmöglich (machbar sicherlich, aber der Aufwand ist enorm). Side-Channel-Attacks sind nicht ohne weiteres mal schnell gemacht, der Aufwand ist ebenfalls immens. Durch die Medien ging da mal ein Paper der Uni Bochum, die den Schlüssel aus einem Stromaufnahmeprofil zurück gerechnet haben (vgl.
Wikipedia-Artikel bzw.
Paper).
Allerdings hat Jarolift bei einem Ihrer Produkte ein Sicherheitsleck und es war kein großes Problem an den Schlüssel zu kommen.
Das Problem ist aber, dass ich im Moment weder bereit bin das Leck zu beschreiben noch den Schlüssel her zu geben, da das ja dann auch meine Sicherheit verringern würde (OK, das sind "nur Rollläden", aber immerhin). Es ist also mit meiner Implementierung erst mal nichts anzufangen. Ich würde aber - wenn es ein CUL-FW Release geben würde, dass die Software enthält, jederzeit diese um den Schlüssel angereichert auf mir eingeschickte Hardware flashen und dann halt die FUSE-Bits auf "nicht auslesbar" setzen.
Oder habt ihr andere Ideen wie man den Schlüssel schützen könnte? Eine Idee wäre einen "Schlüssel-Sfotware" auf einen eigenen mini-µC zu bauen (am besten einen PIC, dann bekommt man sogar die Keeloq-Lizenz kostenlos), der nichts anderes tut als Keys zu berechnen und die Verschlüsselungen durchzuführen (er bekommt ein verschlüsseltes Paket und liefert ein entschlüsseltes zurück, mehr macht meine CUL-FW Implementierung nicht). Dieser könnte als "Erweiterungsboard" an einen Cuno oder gar eigenständig mit USB an FHEM angebunden werden. Quasi als Dongle (wie z.B. der
PIC-Stick). Allerdings ist das schon fast soviel Aufwand wie einen "Jarolift CUL / JUL" zu bauen.
Und nun los: Fragt, gebt Tipps, meldet Bedarf an oder zerreißt mich für meine Ansichten ;-) Viele Grüße
Markus