AES Encryption

Anders als der Name vermuteten lässt, handelt es sich beim HM-AES-Encryption Modus ("BidCos") nicht um tatsächlich verschlüsselten Funkverkehr, sondern um das Einschalten eines Signatur-Modus (AES-Challenge-Response (CR)). Hierbei muss sich der Sender durch das Signieren seiner Nachrichten mit einem allen Kommunikationspartnern bekannten AES-Schlüssel authentifizieren. Der Empfänger wird das Kommando nur ausführen, wenn die Authentifizierung korrekt ist. Die eigentliche Datenübertragung findet im Klartext statt und kann immer mitgelesen bzw. abgehört werden, jedoch wird das Ausführen von Kommandos nicht autorisierter Quellen unterbunden.

Kommunikationsstrecken

Der sichere Betrieb von Hausautomatisierungssystemen betrifft 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 Konfigurator, HM-CFG-USB USB Konfigurations-Adapter, CUL, CUN, CUNO) welches die Brücke zur Funk- oder Kabel-strecke herstellt. Das ist die FHEM-IO-Schnittstelle. Dieser Schnittstelle folgt die IO-Geräte-Schnittstelle, die Funkstrecke. Letztlich gibt es noch die Geräte-Geräte Schnittstelle für die direkte Kommunikation der Geräte untereinander.

Zentrale <-> Frontend

AES wird hier nur als Teil einer anderen Sicherheitslösung genutzt. Diese Schnittstelle muss der User durch andere Verfahren, wie VPN-Tunnel, HTTPS, Challenge-Response Logins und ähnliches sichern. AES wird in diesem Kontext nicht weiter betrachtet.

Zentrale <-> IO-Device

Homematic unterstützt AES auf dieser Strecke, dies ist in FHEM allerdings nicht implementiert. Nutzt man eine CCU(2) anstelle von FHEM als Zentrale, kann hier AES aktiviert werden. Wenn FHEM die Zentrale ist, muss im HMLAN Konfigurator die Netzwerkseitige AES-Verschlüsselung ü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. kein Sicherheitsproblem. Man muss sicherstellen, dass niemand in die Zentrale eindringen kann. Sollte man ein IO-Device per LAN (Ethernet) benutzen (HMLAN Konfigurator, CUN, CUNO) 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 kann ein HMLAN Konfigurator, HM-CFG-USB USB Konfigurations-Adapter oder seit dem 28.6.2015 ein CUL-kompatibles Gerät genutzt werden. Die Kommunikation auf Signaturbasis ist im Abschnitt Ablauf beschrieben. Damit die AES-Kommunikation mit einem CUL genutzt werden kann, muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein.

Gerät <-> Gerät

AES kann auch für die Kommunikation zwischen den Geräten aktiviert werden. Hierbei werden Trigger von Sensoren (z.B. Tasten) durch den Empfänger durch Anforderung einer AES-Signatur überprüft. Dies kann je Kanal aktiviert bzw. deaktiviert werden: ein 2-Kanal Schalter kann also auf einem Kanal AES nutzen und auf dem anderen nicht.

Ablauf

Bei eingeschalteter AES-Signatur wird das Kommando nicht sofort ausgeführt. Der Empfänger sendet eine Signaturanforderung an den Sender zurück, welche dieser mit einem beiden Seiten bekannten AES-Schlüssel kodieren und zurü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 System-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,...)
• das Schalten von Aktoren

Der genaue Ablauf des AES-Signaturverfahrens ist in "Dissecting HomeMatic AES" beschrieben. Henryk Plötz hat die Sicherheit des Kommunikationsprotokolls in "On the Security of AES in HomeMatic" näher betrachtet.

Aktivieren, Einrichten, Umgang in FHEM

Der erste Schritt ist, einen Schlüssel (key) zu vergeben und ihn 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 resettet werden! Im Zweifelsfall muss das Gerät kostenpflichtig von eQ-3 zurückgesetzt werden.
• Der Key muss entweder der VCCU (CUL/HMLAN/HMUSB) oder den IO Geräten (nur HMLAN/HMUSB) bekannt gemacht werden. Er wird als Attribut gesetzt, wobei 3 Schlüssel eingetragen werden können (hmKey hmKey2 hmKey3). Der Key wird MD5 kodiert - man kann ihn im Klartext oder bereits kodiert eingeben. FHEM kodiert ihn, wenn er im Klartext eingegeben werden sollte. FHEM speichert das Attribut ausschließlich kodiert.

attr VCCU hmKey geheimerSchluessel

• Nun kann der Schlüssel auf die einzelnen Geräte übertragen werden. FHEM unterstützt mit dem Kommando assignHmKey das Verteilen des Schlüssels auf die HM Komponenten. Es ist aber auch möglich, diese Aktion mit der HM Konfigurationssoftware (HM-PC-Software) oder einer CCU durchzuführen.

set Geraet assignHmKey
set Schalter assignHmKey

• Eine AES-Signatur muss vom Empfänger angefordert werden. Dementsprechend wird die Nutzung auch dort aktiviert. Dies wird durch das Setzen des Registers sign auf on erreicht, wobei es für jeden Kanal des Geräts separat gesteuert wird.

set Geraet sign on
set Schalter_Btn_01 sign on

• 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. Hiermit kann der Sender überprüfen, ob tatsächlich eine AES-Transaktion stattgefunden hat und diese vom Gerät korrekt bestätigt wurde. Falls dies nicht der Fall ist, wird die Anfrage wiederholt bzw. dem Benutzer ein Fehler signalisiert.

set Schalter_Btn_01 regSet expectAES on Geraet

• Die Zentrale kann ebenfalls eine AES-Signatur von einem Gerät anfordern, so sie einen Trigger empfängt. Hierzu ist im Device (und evtl. entsprechendem Kanal) eines Geräts das Attribut aesCommReq auf 1 zu setzen. Damit die Signatur angefordert wird, muss das Attribut auf jeden Fall auch im Gerät gesetzt werden, auch wenn nur ein einzelner Kanal betroffen ist. Hiermit kann die Überprüfung für ein Gerät sehr schnell deaktiviert werden, indem nur das Geräteattribut wieder entfernt wird (z.B. nach Factory-Reset nötig, wenn das Gerät den eigenen Schlüssel noch nicht kennt). Sollte die Signaturüberprüfung fehlschlagen, verarbeitet Fhem den Befehl nicht.

attr Geraet aesCommReq 1
attr Schalter aesCommReq 1
attr Schalter_Btn_01 aesCommReq 1

Nachteile, Einschränkungen

• 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-Devices nieder. Wenn zwischen Zentrale und dem Gerät AES-Signatur genutzt wird reduziert sich das stündliche Sendekontingent des IO-Devices, siehe 1% Regel
• 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 der eigene Schlüssel 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 die Komponenten vorher auf Werkseinstellung zurückzusetzen, sind die entsprechenden Komponenten nicht mehr verwendbar. Die Geräte müssen kostenpflichtig eingeschickt und zurückgesetzt werden.

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

Wenn ein Gerät mit gesetztem eigenem Sicherheitsschlüssel an eine andere/neue CCU angelernt werden 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 (hauptsächlich Dimmer mit älteren Firmware-Versionen) 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.