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)). Hierdurch soll sichergestellt werden, dass der Funkbefehl auch tatsächlich von der Zentrale kommt, die ihn vorgeblich gesendet hat.
Details
Wenn die AES-Signierung an einem HomeMatic-Gerät eingeschaltet wird, führt ein Aktor einen empfangenen Befehl nicht sofort aus, sondern fragt beim Absender zurück. Dieser muss dann mit einer Bestätigung antworten. Erst dann wird der Befehl tatsächlich ausgeführt. Die AES Challenge-Response Antwort wird dabei mit dem Systemschlüssel erzeugt. Der Systemschlüssel wird von der Zentrale bzw. dem HMLAN Konfigurator auf alle gepairten HomeMatic Geräte verteilt. Standardmäßig ist hier ab Werk ein einheitlicher Standardschlüssel hinterlegt. Dieser ist in allen HM-Geräten gleich. Der Standardschlüssel kann vom Nutzer geändert werden, jedoch bringt dies ggf. einige Nachteile mit sich. Es wird daher verschiedentlich empfohlen, den Schlüssel zumindest solange der werksseitig voreingestellte Schlüssel noch nicht bekannt ist, nicht zu verändern (Details siehe weiter unten).
Der Funkverkehr selbst ist nicht verschlüsselt.
Diese Methode soll die Sicherheit erhöhen, indem der Aktor selber nachfragen kann, ob der Funkbefehl auch tatsächlich von einem autorisierten Absender gekommen ist. Da aber alle HM-Geräte bei der Auslieferung den selben Standardschlüssel besitzen, könnte prinzipiell jede Zentrale (CCU) bzw. jeder HMLAN-Konfigurator mit der entsprechenden eingestellten HM-ID fremde Geräte mit Standardschlüssel steuern.
Es ist daher möglich, mit einem HMLAN-Konfigurator, der per FHEM die richtige HM-ID eingestellt hat, alle Aktoren einer fremden Installation zu schalten (die 3-Byte grosse HM-ID ist Bestandteil der Signingantwort), sofern der werksseitig voreingestellte Schlüssel nicht verändert wurde.
Um hier also einen echten Sicherheitsgewinn zu erzielen, muss daher zwingend ein eigener Systemschlüssel vergeben werden.
Nachteile der AES-Signierung Methode
Bis der Aktor schaltet, ist mehr Funkverkehr erforderlich. Anstatt 2 werden 4 Messages versendet (anstatt nach einer wird nach drei Messages geschaltet), die Verzögerung ist deutlich merkbar. Die Batteriebelastung ist ebenfalls höher. Jedes Kommando und seine Bestätigung wird unverschlüsselt versendet, so dass Beobachter von außen den Zustand jedes Aktors durch Mitlesen des Funkverkehrs kennen können. Dies trifft auch bei selbst gesetztem Schlüssel zu. Durch Fehler in der Firmware verschiedener Aktoren werden Toggle-Kommandos zumindest bei einigen Schaltern (HM-LC-Sw1-Pl und HM-LC-SW2-PB-FM) vor Eintreffen des Signingpaketes geschaltet. Bei einem Test einem HM-LC-SW1-PL mit Firmware Version 1.9 konnte dieses Verhalten allerdings nicht reproduziert werden. In dieser Version scheint der Bug nicht mehr existent zu sein. durch Nutzung des HMLAN-Konfigurators ggf. umgehen des Singnings bei der Nutzung des Standardschlüssels möglich (siehe oben). CUL und CUN(O) unterstützen die AES-Signierung nicht. Werden HM-Aktoren mit eingeschalteter AES-Signierung an eine CCU oder einem HMLAN-Konfigurator angelernt (gepairt), so können sie von einem CUL trotz gleicher HMID nicht gesteuert werden. Bei einem Wechsel der Zentrale bzw. des HMLAN-Konfigurators müssen alle Geräte an der neuen Zentrale bzw. dem HMLAN-Konfigurator wieder angelernt werden. Ein faktischer Sicherheitsgewinn ist nur gegeben, wenn ein eigener System-Sicherheitsschlüssel genutzt wird.
Erhöhung der Sicherheit durch Vergabe eines eigenen Schlüssels
Eine Steigerung der Sicherheit ergibt sich nur, wenn man den werksseitig vorgegeben Schlüssel ändert.
Solange Angreifern dieser unbekannt bleibt, ist ein Fremdschalten nicht mehr möglich (wohl aber ein Ermitteln des aktuellen Schaltzustandes durch Mitschneiden des Funkverkehrs, da der Funkverkehr selbst nicht verschlüsselt ist).
Das gesamte System ist in der Handhabung dann aber etwas aufwändiger. So ist es dann z.B. nicht möglich den Sicherheitsschlüssel in einzelnen Aktoren selbst zurückzusetzen. Nur die Zentrale bzw. der HMLAN-Konfigurator kann einen Schlüssel an alle angelernten Komponenten verteilen bzw. angelernte Module in den Werkszustand setzen (Schlüssel wird auf Werksschlüssel zurückgesetzt).
Wenn also ein eigener Schlüssel vergeben wurde und dieser später nicht mehr bekannt ist, dann die Zentrale zurückgesetzt wird (oder eine defekte gegen eine neue mit Werksschlüssel ausgetauscht wird) ohne dass die Komponenten vorher auf Werkseinstellung zurückgesetzt wurden, dann sind die entsprechenden Komponenten (Sensoren, Aktoren und Sender) erst einmal nicht mehr verwendbar. Wenn man also den selbst gesetzten Schlüssel vergessen / verloren hat, hilft nur noch ein Zurücksetzen beim Hersteller. Dabei fallen dann natürlich entsprechende Kosten an.
WICHTIG: den eigenen Sicherheitsschlüssel gut und sicher aufbewahren.
Wenn man ein Gerät mit gesetztem eigenem Sicherheitsschlüssel an eine andere/neue Zentrale anlernen möchte, so wird man während des Anlernvorgangs nach dem eigenen Sicherheitsschlüssel gefragt.
Da die Schlüsselimplementation der CCU in älteren Firmwareversionen (vor 1.504) z.T. mit Bugs behaftet ist, 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: Sicherheitshalber keine Sonderzeichen im eigenen Sicherheitsschlüssel verwenden.
Der AES-Signier-Schlüssel kann derzeit nicht von FHEM gesetzt werden, sondern muss im HMLAN Konfigurator per mitgelieferter HomeMatic-Software gesetzt werden.
Die AES-Signierung kann mit einigen Ausnahmen in jedem HM-Gerät separat aktiviert/deaktiviert werden. In einigen Geräte wie z.B. dem KeyMatic kann die AES-Signierung nicht abgeschaltet werden. Diese Geräte kommunizieren immer AES-Signiert mit der Zentrale bzw. dem HMLAN-Konfigurator.