AES Encryption

Grundlagen

Anders als der Name vermuten lässt, handelt es sich beim HM (HomeMatic) AES-Encryption Modus des "BidCoS"-Protokolls nicht um 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 werden keine Kommandos von nicht autorisierten Quellen ausgeführt.

Der AES-Encryption Modus sichert, wenn eingeschaltet

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

AES-Prinzip

Der Advanced Encryption Standard (AES) ist ein im Auftrag der US-Regierung entwickeltes symmetrisches Verschlüsselungsverfahren, bei dem sowohl Sender als auch Empfänger über die Kenntnis eines geheimen Schlüssels verfügen müssen. Das AES-Verfahren ist öffentlich bekannt und erfüllt damit ein wesentliches Kriterium sicherer Verfahren, nämlich ihre Überprüfbarkeit. Bis heute ist kein Verfahren bekannt, mit dem man eine AES-Verschlüsselung ohne Kenntnis des Schlüssels "knacken" kann. Es gibt auch keine Hinweise darauf, dass die NSA dazu im Stande sein könnte.

Signatur

Bei einer digitalen Signatur werden nicht Schlüssel verglichen, sondern das Ergebnis der Verschlüsselung bestimmter kurzer Datensätze. Ist das Ergebnis der Verschlüsselung bei Sender und Empfänger gleich, kennen beide den gleichen geheimen Schlüssel.

Kommunikationsstrecken

Der sichere Betrieb von Hausautomatisierungssystemen betrifft unterschiedliche Kommunikationspfade.

• Von der SmartHome-Zentrale gibt es einen Weg zum Eingabeterminal (Web-Interface auf PC, Smartphone o.ä.), die Zentrale-Frontend-Schnittstelle.
• Weiter gibt es einen Weg zum I/O-Gerät (HMLAN Konfigurator, HM-CFG-USB USB Konfigurations-Adapter, CUL, CUN, CUNO) welches die Brücke zur Funk- oder Kabelstrecke herstellt. Wenn FHEM die Zentrale bildet, ist das die FHEM-I/O-Schnittstelle.
• Es folgt die I/O-Geräte-Schnittstelle, die Funk- oder Kabelstrecke.
• Letztlich gibt es noch die Geräte-Geräte Schnittstelle für die direkte Kommunikation der HomeMatic-Geräte untereinander.

Zentrale ←→ Frontend

Diese Schnittstelle ist in der Regel eine internetbasierte Verbindung, meist in Form eines Aufrufes im Web-Browser. Hier muss durch eines der standardisierten Sicherheitsverfahren im Internet für sichere Kommunikation gesorgt werden: Virtual Private Network (VPN), verschlüsseltes WLAN und HTTPS sind gängige Methoden, die hier nicht weiter diskutiert werden sollen.

Zentrale ←→ I/O-Device

HomeMatic unterstützt auf dieser Strecke prinzipiell eine AES-Verschlüsselung, dies ist in FHEM allerdings nicht überall implementiert. Nutzt man stattdessen eine originale HomeMatic CCU2-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. Das HM-LGW-O-TW-W-EU Funk-LAN Gateway kann mit und ohne LAN AES genutzt werden (Konfiguration mit LAN Konfigurator/Netfinder von eq3). Für LAN AES muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein.

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 I/O-Device per LAN oder WLAN benutzen (HMLAN Konfigurator, CUN, CUNO) muss dieses Netz entsprechend gesichert sein. Entsprechende Verfahren (z.B. VLAN, Firewalls,...) werden hier nicht weiter besprochen.

I/O-Device ←→ Gerät

Dieses Teilstück kann mit AES gesichert werden. Die Kommunikation auf Signaturbasis ist im Abschnitt Ablauf beschrieben.

Es kann ein HomeMatic IO oder ein CUL kompatibler IO genutzt werden. Die HomeMatic Module und IOs können AES von sich aus. Für alle CUL-kompatiblen Geräte muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein.

Bei CUL Kompatiblen Geräten kann es zu Timingproblemen kommen. Für CUL Geräte ist für HomeMatic generell die TS Firmware angeraten!

Beim Einsatz von AES-CBC, z.B. dem Rauchmelder HM-SEC-SD-2, wird generell das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) benötigt!

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 eingeschaltetem AES-Encryption Modus wird ein Kommando durch den Empfänger nicht sofort ausgeführt. Der Empfänger sendet vielmehr einen Binärwert mit Signaturanforderung an den Sender (Challenge), welche dieser mit seinem bekannten AES-Schlüssel kodieren und zurücksenden muss (Response). Der Empfänger vergleicht diese mit einem Wert, den er selbst aus der Verschlüsselung mit seinem Schlüssel erhält. Nur wenn beide verschlüsselten Datenwerte übereinstimmen, wird das zuerst erhaltene 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.

Overhead

Es ist aus diesem Ablauf klar, dass der AES-Encryption Modus zu einer zusätzlichen Zeitverzögerung zwischen dem Absenden und dem Ausführen eines Kommandos führt. Im günstigen Fall kann diese etwa 200 ms betragen, in ungünstigen Fällen auch höher sein. Außerdem erhöht sich auf einer Funkstrecke mit AES-Encryption Modus die Funklast auf den dreifachen Wert. Wegen der 1%-Regel kann dies ein I/O-Gerät durchaus in die Überladung mit Befehlen steuern.

Es ist deshalb zu empfehlen, den AES-Encryption Modus nur für sicherheitskritische HomeMatic-Geräte einzuschalten, etwa für Türöffner. Auch der Hersteller eQ-3 gibt diese Empfehlung.

Sicherheit

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

Zentrale

• Der erste Schritt ist, in der virtuellen CCU von FHEM oder nur einem I/O-Device einen Schlüssel (Key) zu vergeben. In FHEM kann mehr als ein Schlüssel hinterlegt sein (Attribute hmKey, hmKey2, hmKey3), als aktiv wird aber nur der Schlüssel mit dem höchsten Index betrachtet, und nur dieser wird, wie unten beschrieben, an ein Gerät übertragen. Fügt man einen neuen Schlüssel hinzu und ein Gerät ist gerade nicht aktiv, kann/muss das System den vorigen Schlüssel noch nutzen.
  • Der Systemverwalter muss sich den Schlüssel unbedingt merken. Er kann nicht aus den Geräten gelöscht werden! Im Zweifelsfall muss das Gerät kostenpflichtig von eQ-3 zurückgesetzt werden.
  • Die Schlüssel werden 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

• Der zweite Schritt besteht darin, den Schlüssel mit dem höchsten Index mit dem gerätespezifischen FHEM-Kommando assignHmKey an alle gepairten Geräte zu übertragen, mindestens aber an diejenigen, bei denen der AES-Encryption Modus eingeschaltet werden soll. 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

Der aktuelle Schlüsselindex kann aus dem Reading aesKeyNbr des Geräts berechnet werden, wobei das Reading den im Funkprotokoll angeforderten Schlüssel wiederspiegelt, welcher den doppelten Wert des eigentlichen Schlüsselindex hat. Weiterhin muss beachtet werden, dass das Reading aesKeyNbr nur angepasst wird, wenn das Gerät eine Signatur anfordert, d.h. eine Schaltaktion ausgeführt oder ein Register geändert wird. Direkt nach dem assignHmKey hat das Reading noch einen veralteten Wert!

Geräte

• 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, dass 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 vorgegebenen 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.