AES Encryption

Anders als der Name vermuteten lässt, handelt es sich beim HM-AES-Encryption Modus ("BidCos") nicht um tatsächlich encrypteten Funkverkehr, sondern um das Einschalten eines Signingrequest-Modus (AES-Challenge-Response (CR)). Hierbei muss ich der Sender durch einen AES kodierten Key authentifizieren. Der Empfänger wird das Kommando nur ausführen, wenn die Authentifizierung korrekt ist. Der eigentliche Datenverkehr ist in Klartext und kann immer gemonitort / abgehört werden, jedoch wird das Ausführen von Kommandos nicht autorisierter Quellen unterbunden.

Kommunikationsstrecken

Der Betrieb von Home Automation bedarf unterschiedliche Kommunikationspfade. Von der eigentliche Zentrale aus gibt es einen Weg zum Eingabeterminal (web-interface auf PC, Smartphone o.ä.), die Zentrale-Frontend-Schnittstelle. Weiter gibt es einen Weg zum IO Gerät (HMLAN,HMusb, CUL, CUN(O)) welches die Brücke zur Funk-strecke oder Kabel-strecke herstellt. Das ist die FHEM-IO Schnittstelle. Nun kommt die IO-Geräte Strecke, die Funkstrecke. Letztlich ist da noch die Geräte-Geräte Schnittstelle für die Direkt-Kommunikation der Geräte untereinander.

Zentrale <-> Frontend

AES wird hier nicht genutzt. Diese Schnittstelle muss der User durch andere Verfahren sichern, wie Tunnel, secure login und Ähnliches. Es wird im AES Kontext nicht weiter betrachtet.

Zentrale <-> IO-Device

Homematic könnte AES auf dieser Strecke unterstützen, FHEM kann dies allerdings nicht. Nutzt man eine CCU2 anstelle von FHEM als Zentrale kann hier AES eingeschaltet werden. Wenn FHEM die Zentrale ist, muss im HMLAN Konfigurator als IO-Device AES über die HM-PC-Software abgeschaltet werden, sonst kann FHEM nicht mit dem HMLAN Konfigurator kommunizieren.

Es sind 2 Schnittstellen zu betrachten: Nutzt man ein USB Interface besteht i.a. keine Sicherheitslücke. Man muss sicherstellen, dass niemand in die Zentrale eindringen kann. So man ein IO-Device am LAN (Etherrtnet) nutzt (HMLAN Konfigurator) muss das LAN entsprechend gesichert sein. Entsprechende Verfahren (z.B. VLAN, Firewalls,...) werden hier nicht weiter besprochen.

IO <-> Gerät

Dieses Teilstück kann mit AES gesichert werden. Es muss ein HMUSB oder HMLAN genutzt werden. Eine CUL/CUNO unterstützt kein AES. Die Kommunikation ist wie weiter unten beschrieben auf Signaturbasis. Die AES-Keys müssen von der HM-PC-Software in den Geräten gesetzt werden.

Gerät <-> Gerät

AES kann für die Kommunikation zwischen den Geräten eingeschaltet werden. Hierbei werden Trigger von Sensoren (z.B. Tasten) vom Empfänger durch AES-signatur überprüft. Dies kann je Kanal an/abgeschaltet werden. Ein 2-kanal schalter kann auf einen Kanal AES nutzen und auf dem 2. nicht

Ablauf

Bei eingeschalteter AES-Signatur wird das Kommando nicht sofort ausgeführt. Der Empfänger sendet eine Signatur-request an den Sender zurück, welchen dieser mit seinem AES-Key kodieren und rücksenden muss. Nur wenn die Antwort korrekt ist wird das Kommando ausgeführt und der Empfänger quittiert mit einem ACK an den Sender. Die AES Challenge-Response Antwort wird mit dem System-Schlüssel erzeugt. Der Systems-Schlüssel wird von der Zentrale bzw. dem HMLAN Konfigurator auf alle gepairten HomeMatic Geräte verteilt. Ab Werk ist ein einheitlicher Standard-Schlüssel hinterlegt. Dieser ist in allen HM-Geräten gleich und muss somit vom User geändert werden um einen sinnvollen Schutz zu erreichen.

AES sichert, wenn eingeschaltet

das Ändern der Gerätekonfiguration
das Auslösen von Triggern (Tasten, Sensoren,...)

Aktivieren, Einrichten, Umgang in FHEM

Zuerst muss ein Schlüssel vergeben werden. FHEM unterstützt nicht das Verteilen des Schlüssels auf die HM Komponenten. Hierzu ist die HM Konfigurationssoftware (HM-PC-Software) notwendig oder eine CCU.

Der erste Schritt ist, einen Schlüssel (key) zu vergeben und ihn per HM-SW in alle gepairten Geräte zu übertragen. Im System kann mehr als ein Key aktiv sein, was schon wegen der Änderungsprozedur notwendig ist. Ändert man den key und ein Gerät ist gerade nicht aktiv kann/muss das System den vorigen key noch nutzen.

Der User muss sich den Schlüssel zwingend merken. Er kann nicht resetet werden! Im Zweifelsfall muss das Gerät kostenpflichtig von eQ3 rückgesetzt werden.
Der key muss dem IO Gerät bekannt gemacht werden. Es wird als Attribut gesetzt, wobei 5 keys eingetragen werden können (hmKey hmKey2 hmKey3 hmKey4 hmKey5). Der Key wird MD5 kodiert - man kann ihn in Klartext oder bereits kodiert eingeben. FHEM kodiert in, wenn er in Klartext eingegeben werden sollte. FHEM speichert das Attribut ausschließlich kodiert.
Eine AES Signatur muss von Empfänger angefordert werden. Dementsprechend wird die Nutzung auch dort eingeschaltet. Eingeschaltet wird durch das Setzen des Registers sign auf on. Es wird für jeden Kanal des Geräts separat gesteuert.
Ein Sender, der mit einem Empfänger gepeert ist sollte wissen, ob dieser AES nutzen wird. Das Register expectAES ist hierbei auf on zu setzen.
Die Zentrale kann ebenfalls eine AES Signatur von einem Gerät anfordern, so es einen Trigger empfängt. Hierzu ist im Device eines Geräts das Attribut aesCommReq auf 1 zu setzen.

Nachteile, Einschränkungen

AES-Signatur wird von HMLAN und HMUSB unterstützt, nicht aber von CUL und CUN(O).
Die zusätzliche Kommunikation führt zu einer Verzögerung von etwa 200ms je Vorgang.
Die erhöhte Nachrichtenlast schlägt sich in der Auslastung der IO Geräts nieder. Wenn zwischen Zentrale und dem Gerät AES-Signatur genutzt wird reduziert sich die Kapazität je Stunde des IOs.
Jedes Kommando und seine Bestätigung wird unverschlüsselt übertragen, so dass Beobachter von außen den Zustand jedes Aktors durch mitlesen des Funkverkehrs ermitteln können. Dies trifft auch bei selbst gesetztem Schlüssel zu.
Ein Sicherheitsgewinn ist nur gegeben, wenn ein eigener System-Sicherheitsschlüssel genutzt wird.

Hinweise

Eine Steigerung der Sicherheit ergibt sich nur, wenn man den werksseitig vorgegeben Schlüssel ändert. Solange Angreifern dieser unbekannt bleibt, ist ein Fremdschalten oder die Änderung der Konfiguration nicht mehr möglich, wohl aber ein Ermitteln des aktuellen Schaltzustandes.

Wurde ein eigener Schlüssel vergeben der nicht mehr bekannt ist und wird dann die Zentrale zurückgesetzt oder ausgetauscht ohne dass die Komponenten vorher auf Werkseinstellung zurückgesetzt wurden sind die entsprechenden Komponenten nicht mehr verwendbar. Die Geräte müssen kostenpflichtig eingeschickt und rückgesetzt werden.

WICHTIG: den eigenen Sicherheitsschlüssel gut und sicher aufbewahren.

Wenn ein Gerät mit gesetztem eigenem Sicherheitsschlüssel an eine andere/neue Zentrale anlernen soll, wird während des Anlernvorgangs nach dem eigenen Sicherheitsschlüssel gefragt. Dieser muss also bereits in der neuen Zentrale vorliegen.

Die AES-Signierung kann mit einigen Ausnahmen in jedem HM-Gerät separat je Kanal aktiviert/deaktiviert werden. In einigen Geräte wie z.B. KeyMatic kann die AES-Signierung nicht abgeschaltet werden. Diese Geräte kommunizieren immer AES-Signiert.

Bekannte Probleme

Durch Fehler in der Firmware einiger Aktoren/FW Versionen (HM-LC-Sw1-Pl und HM-LC-SW2-PB-FM) werden Toggle-Kommandos vor Eintreffen des Signingpaketes geschaltet. Beim HM-LC-SW1-PL mit Firmware Version 1.9 konnte dieses Verhalten nicht mehr reproduziert werden.
Die Schlüsselimplementation der CCU in älteren Firmwareversionen (vor 1.504) ist mit Bugs behaftet. Es ergeben sich Risiken selbst dann, wenn der Schlüssel bekannt ist. So darf der Schlüssel z.b. keinesfalls ein "&" enthalten. Gelegentlich wird auch berichtet, dass garantiert richtig eingegebene Schlüssel bei Systemwechseln nicht akzeptiert wurden. WICHTIG: Keine Sonderzeichen im eigenen Sicherheitsschlüssel verwenden.