FHEMWiki - Benutzerbeiträge [de]

AES Encryption

2016-11-22T08:37:03Z

Mgernoth: /* Aktivieren, Einrichten, Umgang in FHEM */

=Grundlagen=
Anders als der Name vermuteten 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 autorisierter 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 Schü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 Verschüsselung bei Sender und Empfänger gleich, kennen bei 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 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.

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. Es kann ein [[HMLAN Konfigurator]], [[HM-CFG-USB USB Konfigurations-Adapter]], seit dem 28.6.2015 ein [[CUL]]-kompatibles Gerät oder seit dem 18.07.2016 eines der neuen eq3 Sendemodule [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi]] / [[HM-LGW-O-TW-W-EU Funk-LAN Gateway]] genutzt werden. Die Kommunikation auf Signaturbasis ist im Abschnitt [[#Ablauf|Ablauf]] beschrieben. Damit die AES-Kommunikation mit einem dieser Module 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 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 "[https://git.zerfleddert.de/hmcfgusb/AES/ Dissecting HomeMatic AES]" beschrieben. Henryk Plötz hat die Sicherheit des Kommunikationsprotokolls in "[https://blog.ploetzli.ch/2015/on-the-security-of-aes-in-homematic/ 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öchstenm 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 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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2016-11-22T08:35:26Z

Mgernoth: /* Aktivieren, Einrichten, Umgang in FHEM */ aesKeyNbr hinzugefügt

=Grundlagen=
Anders als der Name vermuteten 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 autorisierter 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 Schü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 Verschüsselung bei Sender und Empfänger gleich, kennen bei 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 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.

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. Es kann ein [[HMLAN Konfigurator]], [[HM-CFG-USB USB Konfigurations-Adapter]], seit dem 28.6.2015 ein [[CUL]]-kompatibles Gerät oder seit dem 18.07.2016 eines der neuen eq3 Sendemodule [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi]] / [[HM-LGW-O-TW-W-EU Funk-LAN Gateway]] genutzt werden. Die Kommunikation auf Signaturbasis ist im Abschnitt [[#Ablauf|Ablauf]] beschrieben. Damit die AES-Kommunikation mit einem dieser Module 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 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 "[https://git.zerfleddert.de/hmcfgusb/AES/ Dissecting HomeMatic AES]" beschrieben. Henryk Plötz hat die Sicherheit des Kommunikationsprotokolls in "[https://blog.ploetzli.ch/2015/on-the-security-of-aes-in-homematic/ 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öchstenm 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, das Reading gibt den im Funkprotokoll angeforderten Schlüssel wieder, welcher den '''doppelten''' Wert des eigentlichen Schlüsselindex hat. Weiterhin muss beachtet werden, dass das Reading '''aesKeyNbr''' nur angepasst, 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 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.

[[Kategorie:HomeMatic Components]]

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2016-09-08T19:22:18Z

Mgernoth: Bild hinzugefügt

{{Infobox Hardware
|Bild=HM-LGW-O-TW-W-EU-2.jpg
|Bildbeschreibung=HomeMatic Funk-LAN Gateway
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=5V DC
|HWPowerConsumption=0,8W
|HWPoweredBy=DC-Buchse
|HWSize=116x150x34mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway|HM-LGW-O-TW-W-EU(-2) Funk-LAN Gateway]] ist ein [[Interface]] zu [[HomeMatic]] Geräten, ähnlich dem [[HM-CFG-LAN LAN Konfigurations-Adapter|LAN Konfigurations-Adapter]]. Die folgende Beschreibung bezieht sich sowohl auf HM-LGW-O-TW-W-EU als auch auf HM-LGW-O-TW-W-EU-2 (wenn nicht anders angegeben).

== Features ==
(Noch zu ergänzen)
* ...

== Hinweise zum Betrieb mit FHEM ==
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi|Funkmodul für Raspberry Pi]].

Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.

=== Definition ===

define meinLGW HMUARTLGW 192.168.42.23
attr meinLGW lgwPw LGWPasswort
attr meinLGW hmId xxxxxx

=== Firmware ===

Es sollte darauf geachtet werden, dass die beiden Firmware-Versionen des Funk-LAN Gateway aktuell sind (aktuell: Applikation: 1.4.1, LAN: 1.1.5). LAN-Firmwareversionen < 1.1.5 haben Stabilitätsprobleme.

Die Applikationsfirmware kann direkt aus Fhem aktualisiert werden, für die Aktualisierung der LAN-Firmware wird entweder der [http://www.eq-3.de/service/downloads.html?id=53 HomeMatic Netfinder] (Java, läuft unter Linux/OSX/Windows, [https://github.com/eq-3/occu/raw/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/hm-lgw-o-tw-w-eu_update.eq3 passendes Firmware-Image v. 1.1.5]) oder die eQ-3 Tools unter Linux benötigt. Die eQ-3 Tools liegen nur in 32bit vor, weshalb auf einem x86_64 System (amd64) noch die 32bit Kompatibilitätsbibliotheken ''libc6-i386'' und ''lib32stdc++6'' installiert werden müssen.

(Im folgenden "NEQ0218723" durch die eigene Seriennummer des Funk-LAN Gateway ersetzen und "geheimesLGWPasswort" durch das LGW-Passwort. Falls die Verschlüsselung deaktiviert wurde, dann das -k komplett weglassen.

=== Vorbereitung des LAN-Firmwareupdates mit den eQ-3 Tools ===

Installation der Kompatibilitätsbibliotheken (nur auf x86_64/amd64 ohne konfiguriertes Multiarch):
$ sudo apt-get install libc6-i386 lib32stdc++6

Auschecken und Vorbereitung der eQ-3-Tools:
$ git clone https://github.com/eq-3/occu
...
$ cd occu
$ sudo ln -s $(pwd)/firmware /firmware

Auf arm:
$ cd arm-gnueabihf/packages-eQ-3/LinuxBasis/bin

Auf x86 bzw. x86_64:
$ cd X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin (auf X86/X86_64)

Wieder gemeinsam auf allen Plattformen:
$ chmod 755 eq3configcmd

=== Update der LAN-Firmware mit den eQ-3 Tools ===

Um das Update durchzuführen, muss man sich im Verzeichnis ''occu/arm-gnueabihf/packages-eQ-3/LinuxBasis/bin'' bzw. ''occu/X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin'' befinden.

$ LD_LIBRARY_PATH=../lib:../../RFD/lib ./eq3configcmd update-lgw-firmware -u ../../../../firmware/hm-lgw-o-tw-w-eu_update.eq3 -console -l 1 -s NEQ0218723 -k 'geheimesLGWPasswort'
2016/07/28 09:25:24.264 <Info> LAN Gateway Firmware Update...

2016/07/28 09:25:24.265 <Info> Gateway NEQ0218723
2016/07/28 09:25:26.273 <Info> Gateway type is eQ3-HM-LGW-App
cryptEnabled true2016/07/28 09:25:33.313 <Info> Updating firmware....

2016/07/28 09:25:38.467 <Info> Update performed. Waiting for gateway to get ready.

=== Update der Applikationsfirmware mit Fhem ===

1. Firmware herunterladen
wget https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/coprocessor_update_hm_only.eq3
2. Flashen der neuen Firmware aus Fhem
fhem> set meinLGW updateCoPro /path/to/coprocessor_update_hm_only.eq3

=== Logbeispiel ===

== Bekannte Probleme ==
Das LGW hat (anders als das UART-Modul) keine eigene ''hmId'' (das Reading ''D-HMIdOriginal'' ist auf FFFFFF gesetzt). Es muss also mit
:<code>attr meinLGW hmId xxxxxx</code>
eine nach den in der [http://fhem.de/commandref.html#hmId commandref] definierten Regeln gewählte Id gesetzt werden.

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funk-lan-gateway.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]

Datei:HM-LGW-O-TW-W-EU-2.jpg

2016-09-08T19:21:22Z

Mgernoth: HM-LGW-O-TW-W-EU-2

HM-LGW-O-TW-W-EU-2

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2016-09-08T19:13:22Z

Mgernoth:

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2016-09-08T19:10:17Z

Mgernoth: HM-LGW-O-TW-W-EU-2 erwähnt

HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi

2016-09-03T17:56:01Z

Mgernoth: /* Firmware Update HM-MOD-RPI-PCB */ Applikationsfirmwareupdate jetzt über Fhem

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=HomeMatic Funkmodul für Raspberry Pi
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=1,8–3,6 V DC
|HWPowerConsumption=50 mA max.
|HWPoweredBy=RasPi
|HWSize=19x41x14mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi]] ist eine Zusatzplatine, die auf die GPIO-Schnittstelle des [[Raspberry Pi]] aufgesteckt werden und damit als [[Interface]] zu [[HomeMatic]] Geräten dienen kann.

== Features ==
(Noch zu ergänzen)
* ...

== Hinweise zum Betrieb mit FHEM ==
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das "neue" [[HM-LGW-O-TW-W-EU Funk-LAN Gateway|Funk-LAN Gateway HM-LGW-O-TW-W-EU]].

Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.

=== Vorbereitung serielle Schnittstelle unter Jessie===
Diese Beschreibung gilt für Jessie Version 27.05.2016.
Die Grundlagen findet man hier: [[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]

Die Datei /boot/config.txt um diese Zeile ergänzen

<pre>enable_uart=1</pre>

Beim PI 3 zusätzlich diese Zeilen ergänzen

<pre>dtoverlay=pi3-miniuart-bt
core_freq=250</pre>

In der Datei /boot/cmdline.txt diesen Eintrag löschen:
<pre>console=serial0,115200 </pre>

Den Dienst serial-getty deaktivieren

<pre>systemctl disable serial-getty@ttyAMA0.service</pre>

Bei PI 3 den hciuart Service modifizieren: In der Datei /lib/systemd/system/hciuart.service zweimal ttyAMA0 gegen ttyS0 austauschen.

<pre>sed -i s/ttyAMA0/ttyS0/ /lib/systemd/system/hciuart.service</pre>

Der Benutzer fhem muss Mitglied in der Gruppe dialout sein!
Beim PI 3 kann man wegen Timingproblemen den Start von FHEM etwas verzögern. Dazu die /etc/init.d/fhem um sleep 10 am Anfang ergänzen.

Das System unbedingt neu starten!

=== Vorbereitung serielle Schnittstelle unter Wheezy===
Diese Beschreibung gilt für Wheezy Version Stand 26.07.2016.

Die Datei /boot/config.txt um diese Zeile ergänzen

<pre>enable_uart=1</pre>

In der Datei /boot/cmdline.txt diesen Eintrag löschen:

<pre>console=ttyAMA0,115200</pre>

Die Datei sollte dann den folgenden Inhalt aufweisen:

<pre>dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait</pre>

Den Dienst serial-getty deaktivieren

in der Datei /etc/inittab wie folgt die Zeile (ziemlich am Ende) mit einer # auskommentieren

<pre># T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100</pre>
Mit folgendem Befehlen überprüfen, dass kein getty auf der Schnittstelle läuft
<pre>ps -A |grep getty
cat /etc/inittab</pre>
{{Randnotiz|RNText=Tipp: Sollte der HM-MOD-RPI-PCB nach der Einrichtung immer wieder den Status zwischen init und disconnect wechseln, alle aufgeführten Punkte erneut kontrollieren! reboot nicht vergessen!}}

Der Benutzer fhem muss Mitglied in der Gruppe dialout sein! Bitte prüfen:
<pre>groups fhem</pre>

'''Das System unbedingt neu starten!'''

=== Kontrolle ===
Berechtigungen der Schnittstelle kontrollieren
<pre>ls -l /dev/ttyAMA0</pre> liefert die Ausgabe unter Jessie
<pre>crw-rw---- 1 root dialout 204, 64 Jul 27 23:39 /dev/ttyAMA0</pre>
bzw. unter wheezy
<pre>crw-rw---T 1 root dialout 204, 64 Aug 9 18:07 /dev/ttyAMA0</pre>

=== Definition in FHEM===
<pre>define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId xxxxxx</pre>
=== Logbeispiel ===

=== Firmware Update HM-MOD-RPI-PCB ===

1. Firmware herunterladen
wget https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/HM-MOD-UART/coprocessor_update.eq3
2. Flashen der neuen Firmware aus Fhem
fhem> set myHmUART updateCoPro /path/to/coprocessor_update.eq3

== Bekannte Probleme ==
Ein {{Link2Forum|Topic=41203|Message=340320|LinkText=Beitrag}} aus dem genannten Forenthread: ''Das Ding ist anscheinend wirklich einfach das Funkmodul aus der CCU2 (wird zumindest in der eQ-3 SW als CCU2 angesprochen) und spricht ein für Fhem vollkommen neues Protokoll.''

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]
[[Kategorie:Raspberry Pi]]

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2016-09-03T17:53:01Z

Mgernoth: /* Update der Applikationsfirmware aus Fhem */

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2016-09-03T17:51:35Z

Mgernoth: /* Hinweise zum Betrieb mit FHEM */ Applikationsfirmwareupdate jetzt über Fhem

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2016-08-30T16:10:40Z

Mgernoth: /* Vorbereitung des Firmwareupdates */

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=HomeMatic Funk-LAN Gateway
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=5V DC
|HWPowerConsumption=0,8W
|HWPoweredBy=DC-Buchse
|HWSize=116x150x34mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway]] ist ein [[Interface]] zu [[HomeMatic]] Geräten, ähnlich dem [[HM-CFG-LAN LAN Konfigurations-Adapter|LAN Konfigurations-Adapter]].

== Features ==
(Noch zu ergänzen)
* ...

== Hinweise zum Betrieb mit FHEM ==
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi|Funkmodul für Raspberry Pi]].

Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.

=== Definition ===

define meinLGW HMUARTLGW 192.168.42.23
attr meinLGW lgwPw LGWPasswort
attr meinLGW hmId xxxxxx

=== Firmware ===

Es sollte darauf geachtet werden, dass die beiden Firmware-Versionen des Funk-LAN Gateway aktuell sind (aktuell: Applikation: 1.4.1, LAN: 1.1.5). LAN-Firmwareversionen < 1.1.5 haben Stabilitätsprobleme. Beide Firmware-Versionen können mit den eQ-3-Tools unter Linux aktualisiert werden. Sollte das Update auf einem x86_64 System (amd64) erfolgen, müssen noch die 32bit Kompatibilitätsbibliotheken ''libc6-i386'' und ''lib32stdc++6'' installiert werden.

(Im folgenden "NEQ0218723" durch die eigene Seriennummer des Funk-LAN Gateway ersetzen und "geheimesLGWPasswort" durch das LGW-Passwort. Falls die Verschlüsselung deaktiviert wurde, dann das -k komplett weglassen.

=== Vorbereitung des Firmwareupdates ===

Installation der Kompatibilitätsbibliotheken (nur auf x86_64/amd64 ohne konfiguriertes Multiarch):
$ sudo apt-get install libc6-i386 lib32stdc++6

Auschecken und Vorbereitung der eQ-3-Tools:
$ git clone https://github.com/eq-3/occu
...
$ cd occu
$ sudo ln -s $(pwd)/firmware /firmware

Auf arm:
$ cd arm-gnueabihf/packages-eQ-3/LinuxBasis/bin

Auf x86 bzw. x86_64:
$ cd X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin (auf X86/X86_64)

Wieder gemeinsam auf allen Plattformen:
$ chmod 755 eq3configcmd

=== Update der LAN-Firmware ===

Um das Update durchzuführen, muss man sich im Verzeichnis ''occu/arm-gnueabihf/packages-eQ-3/LinuxBasis/bin'' bzw. ''occu/X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin'' befinden.

$ LD_LIBRARY_PATH=../lib:../../RFD/lib ./eq3configcmd update-lgw-firmware -u ../../../../firmware/hm-lgw-o-tw-w-eu_update.eq3 -console -l 1 -s NEQ0218723 -k 'geheimesLGWPasswort'
2016/07/28 09:25:24.264 <Info> LAN Gateway Firmware Update...

2016/07/28 09:25:24.265 <Info> Gateway NEQ0218723
2016/07/28 09:25:26.273 <Info> Gateway type is eQ3-HM-LGW-App
cryptEnabled true2016/07/28 09:25:33.313 <Info> Updating firmware....

2016/07/28 09:25:38.467 <Info> Update performed. Waiting for gateway to get ready.

=== Update der Applikationsfirmware ===

Um das Update durchzuführen, muss man sich im Verzeichnis ''occu/arm-gnueabihf/packages-eQ-3/LinuxBasis/bin'' bzw. ''occu/X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin'' befinden.

$ LD_LIBRARY_PATH=../lib:../../RFD/lib ./eq3configcmd update-coprocessor -u -f -c -l 0 -d ../../../../firmware -s NEQ0218723 -k 'geheimesLGWPasswort'
2016/07/28 09:33:03.791 <Debug> firmware filename is: coprocessor_update_hm_only.eq3

cryptEnabled true2016/07/28 09:33:05.801 LanConnection::connect
2016/07/28 09:33:05.802 LanConnection::connect done
2016/07/28 09:33:05.805 <Info> Lan Device Information:
Protocol-Version: 1
Product-ID: eQ3-HM-LGW
Firmware-Version: 1.1.5
Serial Number: NEQ0218723

2016/07/28 09:33:06.007 LanConnection::connect
2016/07/28 09:33:06.008 LanConnection::connect done
2016/07/28 09:33:06.010 <Info> Lan Device Information:
Protocol-Version: 1
Product-ID: eQ3-HM-LGW
Firmware-Version: 1.1.5
Serial Number: NEQ0218723

2016/07/28 09:33:07.516 <Debug> (NEQ0218723) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in application.
2016/07/28 09:33:07.516 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:07.517 <Debug> CCU2CoprocessorCommandMod::isResponseStatusOk(): System status OK
2016/07/28 09:33:07.517 <Debug> CCU2CommControllerMod::handleIncomingResponse() System response OK
2016/07/28 09:33:07.517 <Debug> (NEQ0218723) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in application.
2016/07/28 09:33:07.535 <Debug> deliver firmware...
2016/07/28 09:33:11.036 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2016/07/28 09:33:11.037 CoprocessorUpdate::startBootloader()
2016/07/28 09:33:11.039 <Debug> (NEQ0218723) CCU2CommControllerMod::startCoprocessorBootloader(): Trying to start coprocessor bootloader
2016/07/28 09:33:11.040 <Debug> CCU2CommControllerMod::sendSystemCommand(): Start Application / Bootloader
2016/07/28 09:33:11.044 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:11.044 <Debug> CCU2CoprocessorCommandMod::isResponseStatusOk(): System status OK
2016/07/28 09:33:11.044 <Debug> CCU2CommControllerMod::handleIncomingResponse() System response OK
2016/07/28 09:33:13.149 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:13.149 <Debug> (NEQ0218723) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in bootloader.
2016/07/28 09:33:13.540 <Debug> CoprocessorUpdate::startBootloader():Coprocessor entered bootloader.
2016/07/28 09:33:14.090 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:14.090 <Debug> CCU2CoprocessorCommandMod::isResponseStatusOk(): System status OK
2016/07/28 09:33:14.090 <Debug> CCU2CommControllerMod::handleIncomingResponse() System response OK
...
2016/07/28 09:33:21.138 <Info> Firmwareupdate successfull

2016/07/28 09:33:21.139 LanConnection::disconnect
2016/07/28 09:33:21.141 Closing socket 3
2016/07/28 09:33:32.144 <Debug> Wait for disconnect timed out
...

Das "Wait for disconnect" kann man mit CTRL-C abbrechen.

=== Logbeispiel ===

== Bekannte Probleme ==
Das LGW hat (anders als das UART-Modul) keine eigene ''hmId'' (das Reading ''D-HMIdOriginal'' ist auf FFFFFF gesetzt). Es muss also mit
:<code>attr meinLGW hmId xxxxxx</code>
eine nach den in der [http://fhem.de/commandref.html#hmId commandref] definierten Regeln gewählte Id gesetzt werden.

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funk-lan-gateway.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2016-08-30T16:09:27Z

Mgernoth: /* Hinweise zum Betrieb mit FHEM */ Definition hinzugefügt, Firmwareupdate erweitert

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=HomeMatic Funk-LAN Gateway
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=5V DC
|HWPowerConsumption=0,8W
|HWPoweredBy=DC-Buchse
|HWSize=116x150x34mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway]] ist ein [[Interface]] zu [[HomeMatic]] Geräten, ähnlich dem [[HM-CFG-LAN LAN Konfigurations-Adapter|LAN Konfigurations-Adapter]].

== Features ==
(Noch zu ergänzen)
* ...

== Hinweise zum Betrieb mit FHEM ==
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi|Funkmodul für Raspberry Pi]].

Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.

=== Definition ===

define meinLGW HMUARTLGW 192.168.42.23
attr meinLGW lgwPw LGWPasswort
attr meinLGW hmId xxxxxx

=== Firmware ===

Es sollte darauf geachtet werden, dass die beiden Firmware-Versionen des Funk-LAN Gateway aktuell sind (aktuell: Applikation: 1.4.1, LAN: 1.1.5). LAN-Firmwareversionen < 1.1.5 haben Stabilitätsprobleme. Beide Firmware-Versionen können mit den eQ-3-Tools unter Linux aktualisiert werden. Sollte das Update auf einem x86_64 System (amd64) erfolgen, müssen noch die 32bit Kompatibilitätsbibliotheken ''libc6-i386'' und ''lib32stdc++6'' installiert werden.

(Im folgenden "NEQ0218723" durch die eigene Seriennummer des Funk-LAN Gateway ersetzen und "geheimesLGWPasswort" durch das LGW-Passwort. Falls die Verschlüsselung deaktiviert wurde, dann das -k komplett weglassen.

=== Vorbereitung des Firmwareupdates ===

Installation der Kompatibilitätsbibliotheken (nur auf x86_64/amd64 ohne konfiguriertes Multiarch):
$ apt-get install libc6-i386 lib32stdc++6

Auschecken und Vorbereitung der eQ-3-Tools:
$ git clone https://github.com/eq-3/occu
...
$ cd occu
$ sudo ln -s $(pwd)/firmware /firmware

Auf arm:
$ cd arm-gnueabihf/packages-eQ-3/LinuxBasis/bin

Auf x86 bzw. x86_64:
$ cd X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin (auf X86/X86_64)

Wieder gemeinsam auf allen Plattformen:
$ chmod 755 eq3configcmd

=== Update der LAN-Firmware ===

Um das Update durchzuführen, muss man sich im Verzeichnis ''occu/arm-gnueabihf/packages-eQ-3/LinuxBasis/bin'' bzw. ''occu/X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin'' befinden.

$ LD_LIBRARY_PATH=../lib:../../RFD/lib ./eq3configcmd update-lgw-firmware -u ../../../../firmware/hm-lgw-o-tw-w-eu_update.eq3 -console -l 1 -s NEQ0218723 -k 'geheimesLGWPasswort'
2016/07/28 09:25:24.264 <Info> LAN Gateway Firmware Update...

2016/07/28 09:25:24.265 <Info> Gateway NEQ0218723
2016/07/28 09:25:26.273 <Info> Gateway type is eQ3-HM-LGW-App
cryptEnabled true2016/07/28 09:25:33.313 <Info> Updating firmware....

2016/07/28 09:25:38.467 <Info> Update performed. Waiting for gateway to get ready.

=== Update der Applikationsfirmware ===

Um das Update durchzuführen, muss man sich im Verzeichnis ''occu/arm-gnueabihf/packages-eQ-3/LinuxBasis/bin'' bzw. ''occu/X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin'' befinden.

$ LD_LIBRARY_PATH=../lib:../../RFD/lib ./eq3configcmd update-coprocessor -u -f -c -l 0 -d ../../../../firmware -s NEQ0218723 -k 'geheimesLGWPasswort'
2016/07/28 09:33:03.791 <Debug> firmware filename is: coprocessor_update_hm_only.eq3

cryptEnabled true2016/07/28 09:33:05.801 LanConnection::connect
2016/07/28 09:33:05.802 LanConnection::connect done
2016/07/28 09:33:05.805 <Info> Lan Device Information:
Protocol-Version: 1
Product-ID: eQ3-HM-LGW
Firmware-Version: 1.1.5
Serial Number: NEQ0218723

2016/07/28 09:33:06.007 LanConnection::connect
2016/07/28 09:33:06.008 LanConnection::connect done
2016/07/28 09:33:06.010 <Info> Lan Device Information:
Protocol-Version: 1
Product-ID: eQ3-HM-LGW
Firmware-Version: 1.1.5
Serial Number: NEQ0218723

2016/07/28 09:33:07.516 <Debug> (NEQ0218723) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in application.
2016/07/28 09:33:07.516 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:07.517 <Debug> CCU2CoprocessorCommandMod::isResponseStatusOk(): System status OK
2016/07/28 09:33:07.517 <Debug> CCU2CommControllerMod::handleIncomingResponse() System response OK
2016/07/28 09:33:07.517 <Debug> (NEQ0218723) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in application.
2016/07/28 09:33:07.535 <Debug> deliver firmware...
2016/07/28 09:33:11.036 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2016/07/28 09:33:11.037 CoprocessorUpdate::startBootloader()
2016/07/28 09:33:11.039 <Debug> (NEQ0218723) CCU2CommControllerMod::startCoprocessorBootloader(): Trying to start coprocessor bootloader
2016/07/28 09:33:11.040 <Debug> CCU2CommControllerMod::sendSystemCommand(): Start Application / Bootloader
2016/07/28 09:33:11.044 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:11.044 <Debug> CCU2CoprocessorCommandMod::isResponseStatusOk(): System status OK
2016/07/28 09:33:11.044 <Debug> CCU2CommControllerMod::handleIncomingResponse() System response OK
2016/07/28 09:33:13.149 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:13.149 <Debug> (NEQ0218723) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in bootloader.
2016/07/28 09:33:13.540 <Debug> CoprocessorUpdate::startBootloader():Coprocessor entered bootloader.
2016/07/28 09:33:14.090 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:14.090 <Debug> CCU2CoprocessorCommandMod::isResponseStatusOk(): System status OK
2016/07/28 09:33:14.090 <Debug> CCU2CommControllerMod::handleIncomingResponse() System response OK
...
2016/07/28 09:33:21.138 <Info> Firmwareupdate successfull

2016/07/28 09:33:21.139 LanConnection::disconnect
2016/07/28 09:33:21.141 Closing socket 3
2016/07/28 09:33:32.144 <Debug> Wait for disconnect timed out
...

Das "Wait for disconnect" kann man mit CTRL-C abbrechen.

=== Logbeispiel ===

== Bekannte Probleme ==
Das LGW hat (anders als das UART-Modul) keine eigene ''hmId'' (das Reading ''D-HMIdOriginal'' ist auf FFFFFF gesetzt). Es muss also mit
:<code>attr meinLGW hmId xxxxxx</code>
eine nach den in der [http://fhem.de/commandref.html#hmId commandref] definierten Regeln gewählte Id gesetzt werden.

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funk-lan-gateway.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2016-08-25T20:35:34Z

Mgernoth: /* Hinweise zum Betrieb mit FHEM */ Informationen zum Firmwareupdate hinzugefügt

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=HomeMatic Funk-LAN Gateway
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=5V DC
|HWPowerConsumption=0,8W
|HWPoweredBy=DC-Buchse
|HWSize=116x150x34mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway]] ist ein [[Interface]] zu [[HomeMatic]] Geräten, ähnlich dem [[HM-CFG-LAN LAN Konfigurations-Adapter|LAN Konfigurations-Adapter]].

== Features ==
(Noch zu ergänzen)
* ...

== Hinweise zum Betrieb mit FHEM ==
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi|Funkmodul für Raspberry Pi]].

Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.

=== Firmware ===

Es sollte darauf geachtet werden, dass die beiden Firmware-Versionen des Funk-LAN Gateway aktuell sind (aktuell: Applikation: 1.4.1, LAN: 1.1.5). LAN-Firmwareversionen < 1.1.5 haben Stabilitätsprobleme. Beide Firmware-Versionen können mit den eQ3-Tools unter Linux aktualisiert werden:

(Im folgenden "NEQ0218723" durch die eigene Seriennummer des Funk-LAN Gateway ersetzen und "geheimesLGWPasswort" durch das LGW-Passwort. Falls die Verschlüsselung deaktiviert wurde, dann das -k komplett weglassen.

=== Vorbereitung des Firmwareupdates ===

$ git clone https://github.com/eq-3/occu
...
$ cd occu
$ sudo ln -s $(pwd)/firmware /firmware
$ cd arm-gnueabihf/packages-eQ-3/LinuxBasis/bin (auf ARM) bzw. cd X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin (auf X86/X86_64)
$ chmod 755 eq3configcmd

=== Update der LAN-Firmware ===

$ LD_LIBRARY_PATH=../lib:../../RFD/lib ./eq3configcmd update-lgw-firmware -u ../../../../firmware/hm-lgw-o-tw-w-eu_update.eq3 -console -l 1 -s NEQ0218723 -k 'geheimesLGWPasswort'
2016/07/28 09:25:24.264 <Info> LAN Gateway Firmware Update...

2016/07/28 09:25:24.265 <Info> Gateway NEQ0218723
2016/07/28 09:25:26.273 <Info> Gateway type is eQ3-HM-LGW-App
cryptEnabled true2016/07/28 09:25:33.313 <Info> Updating firmware....

2016/07/28 09:25:38.467 <Info> Update performed. Waiting for gateway to get ready.

=== Update der Applikationsfirmware ===

$ LD_LIBRARY_PATH=../lib:../../RFD/lib ./eq3configcmd update-coprocessor -u -f -c -l 0 -d ../../../../firmware -s NEQ0218723 -k 'geheimesLGWPasswort'
2016/07/28 09:33:03.791 <Debug> firmware filename is: coprocessor_update_hm_only.eq3

cryptEnabled true2016/07/28 09:33:05.801 LanConnection::connect
2016/07/28 09:33:05.802 LanConnection::connect done
2016/07/28 09:33:05.805 <Info> Lan Device Information:
Protocol-Version: 1
Product-ID: eQ3-HM-LGW
Firmware-Version: 1.1.5
Serial Number: NEQ0218723

2016/07/28 09:33:06.007 LanConnection::connect
2016/07/28 09:33:06.008 LanConnection::connect done
2016/07/28 09:33:06.010 <Info> Lan Device Information:
Protocol-Version: 1
Product-ID: eQ3-HM-LGW
Firmware-Version: 1.1.5
Serial Number: NEQ0218723

2016/07/28 09:33:07.516 <Debug> (NEQ0218723) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in application.
2016/07/28 09:33:07.516 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:07.517 <Debug> CCU2CoprocessorCommandMod::isResponseStatusOk(): System status OK
2016/07/28 09:33:07.517 <Debug> CCU2CommControllerMod::handleIncomingResponse() System response OK
2016/07/28 09:33:07.517 <Debug> (NEQ0218723) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in application.
2016/07/28 09:33:07.535 <Debug> deliver firmware...
2016/07/28 09:33:11.036 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2016/07/28 09:33:11.037 CoprocessorUpdate::startBootloader()
2016/07/28 09:33:11.039 <Debug> (NEQ0218723) CCU2CommControllerMod::startCoprocessorBootloader(): Trying to start coprocessor bootloader
2016/07/28 09:33:11.040 <Debug> CCU2CommControllerMod::sendSystemCommand(): Start Application / Bootloader
2016/07/28 09:33:11.044 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:11.044 <Debug> CCU2CoprocessorCommandMod::isResponseStatusOk(): System status OK
2016/07/28 09:33:11.044 <Debug> CCU2CommControllerMod::handleIncomingResponse() System response OK
2016/07/28 09:33:13.149 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:13.149 <Debug> (NEQ0218723) CCU2CommControllerMod::handleIdentifyEvent(): Coprocessor is in bootloader.
2016/07/28 09:33:13.540 <Debug> CoprocessorUpdate::startBootloader():Coprocessor entered bootloader.
2016/07/28 09:33:14.090 <Debug> CCU2CoprocessorCommandMod::CCU2CoprocessorCommandMod(): System frame
2016/07/28 09:33:14.090 <Debug> CCU2CoprocessorCommandMod::isResponseStatusOk(): System status OK
2016/07/28 09:33:14.090 <Debug> CCU2CommControllerMod::handleIncomingResponse() System response OK
...
2016/07/28 09:33:21.138 <Info> Firmwareupdate successfull

2016/07/28 09:33:21.139 LanConnection::disconnect
2016/07/28 09:33:21.141 Closing socket 3
2016/07/28 09:33:32.144 <Debug> Wait for disconnect timed out
...

Das "Wait for disconnect" kann man mit CTRL-C abbrechen.

=== Definition ===

=== Logbeispiel ===

== Bekannte Probleme ==
Das LGW hat (anders als das UART-Modul) keine eigene ''hmId'' (das Reading ''D-HMIdOriginal'' ist auf FFFFFF gesetzt). Es muss also mit
:<code>attr meinLGW hmId xxxxxx</code>
eine nach den in der [http://fhem.de/commandref.html#hmId commandref] definierten Regeln gewählte Id gesetzt werden.

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funk-lan-gateway.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]

AES Encryption

2015-09-23T13:56:13Z

Mgernoth: /* IO Gerät */ Benötigtes Perl-Modul hinzugefügt

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|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 "[https://git.zerfleddert.de/hmcfgusb/AES/ Dissecting HomeMatic AES]" beschrieben. Henryk Plötz hat die Sicherheit des Kommunikationsprotokolls in "[https://blog.ploetzli.ch/2015/on-the-security-of-aes-in-homematic/ 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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-09-23T13:53:17Z

Mgernoth: /* Ablauf */ Link zu henryks Sicherheitsanalyse hinzugefügt

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|Ablauf]] beschrieben.

=== 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 "[https://git.zerfleddert.de/hmcfgusb/AES/ Dissecting HomeMatic AES]" beschrieben. Henryk Plötz hat die Sicherheit des Kommunikationsprotokolls in "[https://blog.ploetzli.ch/2015/on-the-security-of-aes-in-homematic/ 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.

[[Kategorie:HomeMatic Components]]

HM-CFG-USB USB Konfigurations-Adapter

2015-09-22T07:58:29Z

Mgernoth: /* Einrichtung unter Linux */ Falschen Hinweis zu Debian entfernt

{{Infobox Hardware
|Bild=platzHalter.png
|Bildbeschreibung=todo
|HWProtocol=HomeMatic
|HWType=Interface/Gateway
|HWCategory=HomeMatic
|HWComm=868,3MHz
|HWChannels=
|HWVoltage=
|HWPowerConsumption=
|HWPoweredBy=USB-Bus
|HWSize=
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]

|HWManufacturer=HomeMatic
}}
Der [[HomeMatic]] '''USB Konfigurations-Adapter''' ist ein USB-Stick, der außer zur Konfiguration von HomeMatic Komponenten auch als [[Interface]] zwischen Fhem und HomeMatic Geräten benutzt werden kann. Er existiert in zwei Versionen: der älteren HM-CFG-USB und der neueren HM-CFG-USB2. Die folgenden Beschreibungen gelten für beide Versionen, es sei denn, es ist ausdrücklich eine spezifische Version genannt.

== Einbindung in Fhem ==
Im Fhem-Forum wird die Einbindung als Interface in diesem {{Link2Forum|Topic=13071}} beschrieben und diskutiert. Im {{Link2Forum|Topic=13071|Message=79872|LinkText=Eröffnungsbeitrag}} wird eine gut funktionierende HMLAN-Emulationssoftware [https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb hmland] von ihrem Entwickler vorgestellt, um den HM-CFG-USB in Fhem zu integrieren. Die HMLAN-Emulationssoftware muss zunächst kompiliert und installiert werden. Anschließend wird der HM-CFG-USB (üblicherweise auf localhost) genau wie [[HM-CFG-LAN LAN Konfigurations-Adapter|HMLAN]] in Fhem eingebunden.

=== Einrichtung unter Linux ===
Die Schritte zur Kompilierung und Installation hat der hmland-Entwickler sowohl auf der [https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb hmland-Internetseite] in Englisch (kurz) als auch im oben genannten {{Link2Forum|Topic=13071|Message=79872|LinkText=Eröffnungsbeitrag}} in Deutsch (ausführlich) dargestellt. Die dort gemachten Angaben werden auch bei Bedarf aktualisiert und sind deshalb der beste Anlaufpunkt für Kompilierung und Installation.

Die nachfolgenden Angaben in diesem Abschnitt sind rein zu Informationszwecken (noch) enthalten:

Zunächst muss die HMLAN-Emulationssoftware kompiliert werden. Analog zu [https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb dieser Beschreibung] ist die Vorgehensweise die folgende (in Debian/Ubuntu/Raspbian):
cd /opt/
apt-get install build-essential libusb-1.0-0-dev make gcc git-core
git clone git://git.zerfleddert.de/hmcfgusb
cd hmcfgusb
make

Danach kann der Dienst zu Testzwecken gestartet werden (in /opt/hmcfgusb):
:<code>./hmland -p 1234 -D</code>

==== Start als Daemon ====
Um den hmland als Daemon mit dem Betriebsystem automatisiert zu starten, kann ein init-script genutzt werden. In diesem {{Link2Forum|Topic=13071|Message=190887}} ist ein Skript zur automatischen Einrichtung von hmland als Daemon über init mit Installationsanweisung enthalten. Dieses Skript enthält zudem auch die Befehle zum Download, Kompilierung und Installation von hmland, so dass fast keine manuellen Eingriffe notwendig sind.

Alternativ ist auch der (umständlichere) manuelle Weg möglich:
<pre>
#!/bin/sh
### BEGIN INIT INFO
# Provides: hmland
# Required-Start: $localfs $syslog $remote_fs
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: hmland daemon
# Description: hmland daemon, Homematic USB Adapter on port 1234
### END INIT INFO

# simple init for hmland

pidfile=/var/run/hmland.pid
port=1234

case "$1" in
start|"")
chrt 50 /opt/hmcfgusb/hmland -d -P -l 127.0.0.1 -p $port 2>&1 | perl -ne '$|=1; print localtime . ": [hmland] $_"' >> /var/log/hmland.log &
;;
restart|reload|force-reload)
echo "Error: argument '$1' not supported" >&2
exit 3
;;
stop)
killall hmland
;;
status)
if [ ! -e $pidfile ]; then
echo "No pid"
exit 1
fi
pid=`cat $pidfile`
if kill -0 $pid &>1 > /dev/null; then
echo "Running"
exit 0
else
rm $pidfile
echo "Not running"
exit 1
fi

;;
*)
echo "Usage: hmland [start|stop|status]" >&2
exit 3
;;
esac
</pre>

Bei Distributionen, die Upstart einsetzen (z.B. xbian) kann folgendes Konfigurationsfile verwendet werden:
<pre>
# HMLAND

description "hmland"

start on starting fhem
stop on stopped fhem

respawn
expect fork

chdir /opt/hmcfgusb
exec /opt/hmcfgusb/hmland -d -l 127.0.0.1 -p 1234
</pre>

Die Datei sollte als "/etc/init/hmland.conf" angelegt werden. Mit dem Befehl
initctl reload-configuration
wird Upstart angewiesen, seine Konfiguration erneut einzulesen. Danach kann der neue Dienst
mit
service hmland start
gestartet werden. <code>hmland</code> wird jetzt immer vor Fhem gestartet und nach Fhem beendet.

==== Start über Fhem Startskript ====

Ausprobiert auf einem BBB mit Debian, eigentlich ist das alles von Betateilchen:

Zunächst hmland kompilieren wie oben beschrieben, bis zum make. Das muss erfolgreich durchgelaufen sein.

Dann geht es weiter:

sudo cp hmcfgusb.rules /etc/udev/rules.d/

Jetzt das Fhem Startskript anpassen (in den Blöcken 'start' und 'stop' muss quasi nur jeweils 1 Zeile eingefügt werden:

Damit editiert man das Fhem Startskript:
sudo nano /etc/init.d/fhem

Und so sollten die Blöcke anschließend aussehen (bitte nur jeweils die Zeile mit hmland einfügen)

'start')
echo "Starting fhem..."
/opt/hmcfgusb/hmland -d -p 1234
perl fhem.pl fhem.cfg
RETVAL=$?
;;

'stop')
echo "Stopping fhem..."
perl fhem.pl $port "shutdown"
RETVAL=$?
pkill hmland

So wird hmland vor Fhem gestartet und nach Fhem beendet. Letztlich erspart es Probleme mit den diversen Startskripten und ihren Rechten.

Es dauert nach dem Start von Fhem noch einige Sekunden, bis hmland fertig geladen ist. In dieser Zeit kann es zu fehlerhaften Einträgen im Logfile kommen.

=== Einrichtung unter Mac OS X ===
Wie unter Linux braucht man die HMLAN-Emulationssoftware hmland, die man aus Quelltexten erstellen muss. Dazu muss man die Bibliothek libusb installieren, entweder mit einem der Paketmanager wie Fink, MacPorts oder Homebrew oder direkt aus den Quellentexten (Beispiel: "fink install libusb1-shlibs libusb1"). Hat man wie bei Linux das Quelltextarchiv für hmland heruntergeladen und ausgepackt, müssen die Dateien Makefile und hmcfgusb.c angepasst werden.

Im Makefile muss man den Pfad zur libusb anpassen. Hat man libusb mit fink installiert, muss man, "/opt/local/" durch "/sw/" bei den CFLAGS und den LDFLAGS ersetzen und
das "-lrt" aus den LDLIBS entfernen. Die Library librt gibt es bei Mac OS X nicht und wird anscheinend auch nicht gebraucht. (Stimmt das eigentlich?)

In der Datei hmcfgusb.c muss man die Zeilen 130-134 mit dem Aufruf libusb_detach_kernel_driver auskommentieren oder löschen. Der geht nicht auf Mac OS X.

Nach den Änderungen in den zwei Dateien, kann man wie bei Linux den Dämon hmland mit dem Kommando "make" erzeugen und mit "./hmland" ausführen. Automatisches Starten beim Booten mit launchd ist noch nicht probiert.

Beim Start von hmland sollte man folgende Fehlermeldung in einer Endlos-Schleife erhalten:

Datum Zeit: Client 127.0.0.1 connected! 
Can't claim interface: Access denied (insufficient permissions) 
Can't find/open hmcfgusb! 
Datum Zeit: Connection to 127.0.0.1 closed! 

Auch ein Start von hmland mit Superuser-Rechten ändert daran nichts. Damit das claim interface klappt, muss man eine codeless kext in den Ordner /Library/Extensions legen. Ich habe dieses (http://mspdebug.sourceforge.net/misc/ex430rf2500-kext.zip) herunter geladen. Damit es funktioniert, muss man aber in der Datei Info.plist des Bundle die Properties idProduct und idVendor ändern, entweder mit dem Property List Editor oder einem anderen Texteditor. Die beiden Properties sind etwas versteckt bei Information Property List → IOKitPersonalities → ComIntf. Bei DebugIntf und DeviceDriver scheint man es nicht ändern zu müssen, aber schaden kann es nicht. 

idProduct: 49167 
idVendor: 6943

Die Rechte des kext-Bundles müssen auch noch gesetzt werden:

chmod -R 755 ex430rf2500.kext
chown -R root:wheel ex430rf2500.kext

Danach die Datei ex430rf2500.kext in den Ordner /Library/Extensions legen und hmland sollte dann funktionieren.

Es kann sein, dass ab Mac OS X 10.9 der Trick mit dem codeless kext nicht mehr funktioniert, aber noch ist das nicht getestet oder bestätigt. Langfristig kann man vielleicht auch eine kext mit einem Treiber für den HM-CFG-USB USB erstellen

=== Einrichtung unter Windows ===
Bei der Einrichtung und vermutlich auch dem Betrieb unter Windows 8.1 sind wegen der erweiterten Energieverwaltungsfunktionen die von eQ-3 [http://www.eq-3.de/Downloads/eq3/pdf_FAQ/Funk-Konfigurationsdapter-USB_Windos_8.1.pdf zusammengestellten Tipps] zu befolgen.

== Bekannte Probleme ==
=== Verbindung zu neueren hmland-Versionen nicht stabil ===
Seit Version 0.100 meldet sich die HMLAN-Emulationssoftware als USB-Interface bei Fhem. Ältere Fhem-Versionen (vor dem 19.6.2015) brechen deshalb die Verbindung ab, da sie nur ein LAN-Interface erwarten.

Lösung: Kommandozeilenparameter <code>-I</code> dem hmland-Aufruf hinzufügen, dann meldet sich dieser wieder als LAN-Interface.

=== Stick nicht (mehr) ansprechbar ===
Zitat aus dem {{Link2Forum|Topic=32502|Message=249122|LinkText=Fhem-Forum}}:
:''... befürchte ich, dass dein Stick das Zeitliche gesegnet hat. Machen die Dinger leider sehr gerne... Ganz besonders beim Modus-Wechsel vom 10k- in den 100k-Modus, wenn man bei irgendeinem Device ein Firmwareupdate durchführt. Die gute Nachricht ist, dass der Fehler bei sämtlichen Händlern bekannt ist und anstandslos getauscht wird.''

=== Raspberry Pi ===
Der USB-Stack am Raspberry Pi ist für viele Probleme verantwortlich. Daher sieht man öfter Fehlermeldungen:
:<code>usb-transfer took more than 100ms (1039ms), this may lead to timing problems!</code>

Da das Timing bei Homematic wichtig ist führt das zu vielen Retransmits und zu unzuverlässigen Aktoren. Als Workaround kann man den USB-Stack auf die deutlich langsamere Version 1.1 stellen. Dazu fügt man folgenden Text am Anfang der Datei /boot/cmdline.txt ein:
:<code>dwc_otg.speed=1</code>

=== Windows ===
Die erweiterte Energieverwaltung unter Windows 8.1 kann dazu führen, dass der Adapter unerwünschterweise in den Stand-by Modus versetzt wird (siehe [[HM-CFG-USB USB Konfigurations-Adapter#Einrichtung unter Windows|Einrichtung unter Windows]]).

== Weitergehende Informationen ==
Es sind zwei Versionen des HM-CFG-USB im Umlauf:
* HM-CFG-USB-2: die aktuelle Version; Dokumentation derzeit (12/2013) nicht über die ELV-Artikelseite verfügbar, alternativ jedoch bei [http://files.voelkner.de/625000-649999/640558-an-01-ml-USB_FUNK_KONFIGURATIONSADAPTER_de_en.pdf Völkner]; Kennzeichen dieser Version:
** Größe: 28 x 84 x 11,5 mm
** Gewicht: 18 g
** Antenne innenliegend
* HM-CFG-USB: Vorgängerversion; Stand 12/2013 noch Restbestände im Handel verfügbar. Dokumentation ([http://files.voelkner.de/625000-649999/646462-an-01-ml-HM_Konfigurationsadapter_CFG_USB_de_en.pdf Völkner]); Kennzeichen:
** Anschluss per separatem USB-Kabel
** abstehende Stabantenne
** Größe: 40 x 90 x 25 mm
** Gewicht: 45 g

== Links ==
* Fhem-Forums {{Link2Forum|Topic=13071}}: HomeMatic USB Konfigurations-Adapter (HM-CFG-USB) in Fhem nutzen
* [http://www.elv.de/homematic-usb-konfigurations-adapter-1.html ELV Shopseite] zum HM-CFG-USB
* [http://www.eq-3.de/produkt-detail-zentralen-und-gateways/items/homematic-funk-konfigurationsadapter-usb.html eQ-3 Produktseite] zum "HomeMatic Funk-Konfigurationsadapter USB"; Downloads, technische Daten, etc.

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]
[[Kategorie:OSX]]

AES Encryption

2015-09-14T08:08:45Z

Mgernoth: /* Aktivieren, Einrichten, Umgang in FHEM */

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|Ablauf]] beschrieben.

=== 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 [https://git.zerfleddert.de/hmcfgusb/AES/ Dissecting HomeMatic AES] beschrieben.

== 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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-09-12T11:50:00Z

Mgernoth: /* Aktivieren, Einrichten, Umgang in FHEM */

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|Ablauf]] beschrieben.

=== 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 [https://git.zerfleddert.de/hmcfgusb/AES/ Dissecting HomeMatic AES] beschrieben.

== 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 der VCCU (CUL/HMLAN/HMUSB) bzw. dem IO Gerät (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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-09-12T11:47:26Z

Mgernoth: /* Aktivieren, Einrichten, Umgang in FHEM */

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|Ablauf]] beschrieben.

=== 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 [https://git.zerfleddert.de/hmcfgusb/AES/ Dissecting HomeMatic AES] beschrieben.

== 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 eQ3 rückgesetzt werden.
* Der Key muss der VCCU (CUL/HMLAN/HMUSB) bzw. dem IO Gerät (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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-09-12T11:43:27Z

Mgernoth: /* Kommunikationsstrecken */

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|Ablauf]] beschrieben.

=== 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 [https://git.zerfleddert.de/hmcfgusb/AES/ Dissecting HomeMatic AES] beschrieben.

== 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 resetet werden! Im Zweifelsfall muss das Gerät kostenpflichtig von eQ3 rückgesetzt werden.
* Der Key muss der VCCU (CUL/HMLAN/HMUSB) bzw. dem IO Gerät (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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-09-12T11:42:26Z

Mgernoth: /* Hinweise */

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|Ablauf]] beschrieben.

=== 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 [https://git.zerfleddert.de/hmcfgusb/AES/ Dissecting HomeMatic AES] beschrieben.

== 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 resetet werden! Im Zweifelsfall muss das Gerät kostenpflichtig von eQ3 rückgesetzt werden.
* Der Key muss der VCCU (CUL/HMLAN/HMUSB) bzw. dem IO Gerät (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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-09-12T11:39:11Z

Mgernoth: /* Ablauf */

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|Ablauf]] beschrieben.

=== 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 [https://git.zerfleddert.de/hmcfgusb/AES/ Dissecting HomeMatic AES] beschrieben.

== 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 resetet werden! Im Zweifelsfall muss das Gerät kostenpflichtig von eQ3 rückgesetzt werden.
* Der Key muss der VCCU (CUL/HMLAN/HMUSB) bzw. dem IO Gerät (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 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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-09-12T11:35:23Z

Mgernoth: /* Kommunikationsstrecken */ Überarbeitet

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|Ablauf]] beschrieben.

=== 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 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,...)
* das Schalten von Aktoren

Der genaue Ablauf des AES-Signaturverfahrens ist in [https://git.zerfleddert.de/hmcfgusb/AES/] beschrieben.

== 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 resetet werden! Im Zweifelsfall muss das Gerät kostenpflichtig von eQ3 rückgesetzt werden.
* Der Key muss der VCCU (CUL/HMLAN/HMUSB) bzw. dem IO Gerät (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 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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-09-12T11:18:30Z

Mgernoth: /* Nachteile, Einschränkungen */ Alle IOs können AES

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 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 kann ein HMUSB, HMLAN oder eine CUL/CUNO (seit dem 28.6.2015) genutzt werden. Die Kommunikation ist wie weiter unten beschrieben auf Signaturbasis.

=== 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 also auf einen 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 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,...)
* das Schalten von Aktoren

Der genaue Ablauf des AES-Signaturverfahrens ist in [https://git.zerfleddert.de/hmcfgusb/AES/] beschrieben.

== 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 resetet werden! Im Zweifelsfall muss das Gerät kostenpflichtig von eQ3 rückgesetzt werden.
* Der Key muss der VCCU (CUL/HMLAN/HMUSB) bzw. dem IO Gerät (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 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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-09-12T11:16:26Z

Mgernoth: /* Aktivieren, Einrichten, Umgang in FHEM */ Beispiele hinzugefügt

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 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 kann ein HMUSB, HMLAN oder eine CUL/CUNO (seit dem 28.6.2015) genutzt werden. Die Kommunikation ist wie weiter unten beschrieben auf Signaturbasis.

=== 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 also auf einen 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 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,...)
* das Schalten von Aktoren

Der genaue Ablauf des AES-Signaturverfahrens ist in [https://git.zerfleddert.de/hmcfgusb/AES/] beschrieben.

== 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 resetet werden! Im Zweifelsfall muss das Gerät kostenpflichtig von eQ3 rückgesetzt werden.
* Der Key muss der VCCU (CUL/HMLAN/HMUSB) bzw. dem IO Gerät (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==
* AES-Signatur wird von HMLAN Konfigurator, HMUSB, CUL und CUN(O) unterstützt.
* 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 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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-08-25T08:03:14Z

Mgernoth: Einleitung überarbeitet

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 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 kann ein HMUSB, HMLAN oder eine CUL/CUNO (seit dem 28.6.2015) genutzt werden. Die Kommunikation ist wie weiter unten beschrieben auf Signaturbasis.

=== 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 also auf einen 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 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,...)
* das Schalten von Aktoren

Der genaue Ablauf des AES-Signaturverfahrens ist in [https://git.zerfleddert.de/hmcfgusb/AES/] beschrieben.

== 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 resetet werden! Im Zweifelsfall muss das Gerät kostenpflichtig von eQ3 rückgesetzt werden.
* Der Key muss der VCCU (CUL/HMLAN/HMUSB) bzw. dem IO Gerät (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.
* 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.
* 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 (und evtl. entsprechendem Kanal) eines Geräts das Attribut '''aesCommReq''' auf 1 zu setzen.

== Nachteile, Einschränkungen==
* AES-Signatur wird von HMLAN Konfigurator, HMUSB, CUL und CUN(O) unterstützt.
* 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 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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-08-25T07:56:54Z

Mgernoth: /* Ablauf */ Link zu AES-Signaturverfahren hinzugefügt

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 kann ein HMUSB, HMLAN oder eine CUL/CUNO (seit dem 28.6.2015) genutzt werden. Die Kommunikation ist wie weiter unten beschrieben auf Signaturbasis.

=== 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 also auf einen 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 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,...)
* das Schalten von Aktoren

Der genaue Ablauf des AES-Signaturverfahrens ist in [https://git.zerfleddert.de/hmcfgusb/AES/] beschrieben.

== 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 resetet werden! Im Zweifelsfall muss das Gerät kostenpflichtig von eQ3 rückgesetzt werden.
* Der Key muss der VCCU (CUL/HMLAN/HMUSB) bzw. dem IO Gerät (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.
* 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.
* 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 (und evtl. entsprechendem Kanal) eines Geräts das Attribut '''aesCommReq''' auf 1 zu setzen.

== Nachteile, Einschränkungen==
* AES-Signatur wird von HMLAN Konfigurator, HMUSB, CUL und CUN(O) unterstützt.
* 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 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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-08-24T18:17:20Z

Mgernoth: /* Aktivieren, Einrichten, Umgang in FHEM */ Einrichtung klarer beschrieben

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 kann ein HMUSB, HMLAN oder eine CUL/CUNO (seit dem 28.6.2015) genutzt werden. Die Kommunikation ist wie weiter unten beschrieben auf Signaturbasis.

=== 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 also auf einen 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 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,...)
* das Schalten von Aktoren

== 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 resetet werden! Im Zweifelsfall muss das Gerät kostenpflichtig von eQ3 rückgesetzt werden.
* Der Key muss der VCCU (CUL/HMLAN/HMUSB) bzw. dem IO Gerät (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.
* 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.
* 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 (und evtl. entsprechendem Kanal) eines Geräts das Attribut '''aesCommReq''' auf 1 zu setzen.

== Nachteile, Einschränkungen==
* AES-Signatur wird von HMLAN Konfigurator, HMUSB, CUL und CUN(O) unterstützt.
* 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 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.

[[Kategorie:HomeMatic Components]]

HM-SEC-KEY KeyMatic

2015-08-24T18:09:28Z

Mgernoth: /* Hinweise zum Betrieb mit FHEM */ AES Informationen

== Features ==
Das Gerät dient zum motorgesteuerten Betätigen von Zylinderschlössern in Türen.

== Hinweise zum Betrieb mit FHEM ==
Der HM-SEC-KEY Keymatic verwendet ausschließlich die AES authentifizierte Kommunikation und kann mit dem [[HMLAN Konfigurator]] bzw. [[CUL]] gesteuert werden.

Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. An der KeyMatic muss dafür die Anlerntaste (Taste Schloss öffnen) betätigt werden.

Die KeyMatic-Unterstützung existiert derzeit in der aktuellen Entwicklerversion von FHEM

=== Sicherheitshinweis ===
Wenn die KeyMatic an einem aktiven HMLAN Konfigurator angelernt wurde, kann die entsprechende Tür per FHEM ver- / entriegelt bzw. geöffnet werden. Somit sollte das Netzwerk in dem FHEM läuft entsprechend gesichert sein. (Nicht nach Außen geöffnet, kein unsicheres WLAN usw.)

Die Verwendung eines eigenen [[AES Encryption#Aktivieren.2C_Einrichten.2C_Umgang_in_FHEM|AES Sicherheitsschlüssels]] ist dringend anzuraten, da ansonsten eine KeyMatic relativ einfach ferngesteuert werden kann.

=== FHEM Config-Auszug ===
Beispiel für die Konfiguration:

ssssss -> 6-Stellige hexadezimale Seriennummer. (Siehe Logfile: CUL_HM Unknown device CUL_HM_keyMatic_ssssss, please define it)
xxxxxxx -> Seriennummer (vom Aufkleber auf dem Gerät)

define keymatic CUL_HM ssssss
attr keymatic devInfo 010100
attr keymatic firmware 2.4
attr keymatic hmClass receiver
attr keymatic model HM-SEC-KEY-S
attr keymatic room Flur
attr keymatic serialNr JEQxxxxxxx
attr keymatic subType keyMatic
attr keymatic webCmd lock:unlock:open

== Mögliche Zustände ==
KeyMatic hat folgende Schaltzustände:

locked -> Der Riegel des Türschlosses ist an die vorher festgelegte Verschlussstellung gefahren (Tür verschlossen)
unlocked -> Der Riegel des Türschlosses ist "eingefahren" (Tür nicht verschlossen)
uncertain (locked / unlocked) -> Das Schloss wurde am Handrad gedreht. Die Schlossposition ist somit nicht mehr als "zuverlässig erkannt" gemeldet.
== Links ==
Anleitung [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-Sec-Key_UM_GE_eQ-3_081218.pdf] PDF

[[Kategorie:HomeMatic Components]]
[[Kategorie:Türschlosssteuerung]]

HM-Sec-SCo Tür-Fensterkontakt, optisch

2015-07-17T08:16:27Z

Mgernoth: /* Hinweis */ kompatible Gateways erweitert

{{Infobox Hardware
|Bild=HM-SEC-SCo.jpg
|Bildbeschreibung=HomeMatic Tür-Fensterkontakt, optisch
|HWProtocol=HomeMatic
|HWType=Sensor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=1
|HWVoltage=1,5 V DC
|HWPowerConsumption=max. 100 mA
|HWPoweredBy=Batterie (1x 1,5V LR03/Micro/AAA)
|HWSize=15x100x18mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

== Features ==
[[HomeMatic]] Funk-Tür-/Fensterkontakt zur optischen Erkennung von Tür- bzw. Fensteröffnungen oder -schließungen, z.B. zur Sicherheit oder um automatisch, bei vorhandenem [[HM-CC-RT-DN]], die Heizung herunter zu regeln, sobald ein Fenster oder eine Tür geöffnet wird.

== Hinweis ==
Das meiste zum [[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] Beschriebene zur Nutzung gilt auch für den HM-SEC-SCo.

Wird mit aktiviertem [[AES Encryption|AES]] ausgeliefert und kann nur mit Gateways, die AES unterstützen, gepaired werden ([[HM-CFG-USB USB Konfigurations-Adapter|HM-LAN-CFG]], [[HM-CFG-LAN LAN Konfigurations-Adapter|HM-USB-CFG]] und [[CUL]] (seit Juli 2015)).

== Betrieb mit FHEM ==

=== Event-Monitor ===

Wird z. B. das Fenster geöffnet, wird Folgendes vom Gerät übermittelt:
<pre>
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 11
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG trigDst_2573FB: noConfig
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG battery: ok
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG open
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG contact: open (to MyHMLAN)
</pre>

Beim Schließen wird Folgendes übermittelt:
<pre>
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 12
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG trigDst_2573FB: noConfig
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG battery: ok
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG closed
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG contact: closed (to MyHMLAN)
</pre>

=== fhem.cfg ===

Bei eingeschaltetem Autocreate werden die erforderlichen Definitionen beim Pairen selbstständig erstellt.

<pre>
define HM_Fensterstatus_BadEG CUL_HM 35E390
attr HM_Fensterstatus_BadEG IODev MyHMLAN
attr HM_Fensterstatus_BadEG actCycle 000:50
attr HM_Fensterstatus_BadEG actStatus dead
attr HM_Fensterstatus_BadEG autoReadReg 4_reqStatus
attr HM_Fensterstatus_BadEG expert 2_full
attr HM_Fensterstatus_BadEG firmware 1.0
attr HM_Fensterstatus_BadEG model HM-SEC-SCo
attr HM_Fensterstatus_BadEG peerIDs 00000000,
attr HM_Fensterstatus_BadEG room CUL_HM
attr HM_Fensterstatus_BadEG serialNr LEQxxxxxxx
attr HM_Fensterstatus_BadEG subType threeStateSensor
</pre>

=== Aktionen durchführen, wenn Fenster zu lange geöffnet ist ===

Mit der nachfolgenden DOIF-Definition wird ein Log-Eintrag erzeugt, eine Meldung auf der [[Enigma2 Receiver (Dreambox, VUplus etc.) steuern|Dreambox]] angezeigt, falls diese angeschaltet ist, und eine Nachricht per Prowl (funktioniert vermutlich nur unter Linux) verschickt.

Der Code ist hier so angegeben, wie er in der Weboberfläche nach einem Klick auf das [[Konfiguration|DEF-Feld]] übernommen werden kann. Das DOIF ist vorab zu definieren, zum Beispiel mit:
:<code>def DOIF_FensterOffenMsg DOIF ([HM_Fensterstatus_BadEG])</code>

<pre>
([HM_Fensterstatus_BadEG] eq "open") ({
Log 1, "Fenster seit mehr als 2 Stunden (7200 Sekunden) offen";;
system( "/path/to/prowl.pl -apikeyfile=/path/to/prowl-apikey -event=Info -notification='Fenster ist noch offen' &" );;
fhem( "set E2_Dreambox showText Fenster ist noch offen" ) if ReadingsVal("E2_Dreambox","state","") eq "on";;
})
DOELSE
</pre>

Damit der Code-Block erst nach 7200 Sekunden getriggert wird, ist noch Folgendes auszuführen:

:<code>attr DOIF_FensterOffenMsg wait 7200:0</code>

== Bekannte Probleme ==
Teilweise (siehe Diskussion im {{Link2Forum|Topic=33264|LinkText=Forum}}) werden die Fensterkontakte regelmäßig wiederkehrend als "dead" angezeigt. Grund ist, dass beim Anlernen ein actCycle von 50 Minuten eingetragen wird, während die Kontakte auch gerne mal länger brauchen, um sich bei der Zentrale zu melden.
<pre style="width:500px;">
2015-01-31_17:57:39 Fstr_AusgTerrasse alive: yes
2015-01-31_17:57:39 Fstr_AusgTerrasse battery: ok
2015-01-31_17:57:39 Fstr_AusgTerrasse sabotageError: off
2015-01-31_17:57:39 Fstr_AusgTerrasse closed
2015-01-31_17:57:39 Fstr_AusgTerrasse contact: closed (to HMLAN1)
2015-01-31_18:54:09 Fstr_AusgTerrasse Activity: dead
2015-01-31_18:58:03 Fstr_AusgTerrasse alive: yes
2015-01-31_18:58:03 Fstr_AusgTerrasse battery: ok
2015-01-31_18:58:03 Fstr_AusgTerrasse sabotageError: off
2015-01-31_18:58:03 Fstr_AusgTerrasse closed
2015-01-31_18:58:03 Fstr_AusgTerrasse contact: closed (to HMUSB)
2015-01-31_19:04:09 Fstr_AusgTerrasse Activity: alive
</pre>

Um Abhilfe zu schaffen, den actCycle auf 01:05 setzen:
:<code>attr <HM-SEC-SCo> actCycle 001:05</code>

Save config nicht vergessen.

== Links ==
* Anleitung [http://www.eq-3.de/Downloads/eq3/pdf_produkte/130873_HM-Sec-SCo_UM_GE_eQ-3_20141013_web.pdf PDF]
* Datenblatt [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Tuer-Fensterkontakt-optisch_130297_Produktdatenblatt_V1.1.pdf PDF]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Kontaktsensor (optisch)]]

AES Encryption

2015-07-12T12:14:48Z

Mgernoth: /* Aktivieren, Einrichten, Umgang in FHEM */ aesCommReq auch in einem Kanal gueltig

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 kann ein HMUSB, HMLAN oder eine CUL/CUNO (seit dem 28.6.2015) genutzt werden. Die Kommunikation ist wie weiter unten beschrieben auf Signaturbasis.

=== 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 also auf einen 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 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,...)
* das Schalten von Aktoren

== Aktivieren, Einrichten, Umgang in FHEM ==
*Zuerst muss ein Schlüssel vergeben 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.
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 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 3 Schlüssel eingetragen werden können (hmKey hmKey2 hmKey3). 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 (und evtl. entsprechendem Kanal) eines Geräts das Attribut '''aesCommReq''' auf 1 zu setzen.

== Nachteile, Einschränkungen==
* AES-Signatur wird von HMLAN Konfigurator, HMUSB, CUL und CUN(O) unterstützt.
* 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 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.

[[Kategorie:HomeMatic Components]]

HM-CFG-LAN LAN Konfigurations-Adapter

2015-07-01T16:13:13Z

Mgernoth: /* CUL/CUN(O) */ AES

[[Datei:HM-CFG-LAN.jpg|thumb|right|HomeMatic LAN Konfigurations-Adapter]]
== Vorbemerkungen ==
Der HomeMatic Konfigurations-Adapter LAN ([http://www.eq-3.de/produkt-detail-zentralen-und-gateways/items/hm-cfg-lan.html HM-CFG-LAN]), kurz HMLAN Konfigurator, ist ein Schnittstellengerät (IO) ohne wesentliche Intelligenz. Die Aufgabe ist, ein Interface von der Zentrale zu den Geräten bereitzustellen. Ein HMLAN Konfigurator selbst steuert keine Geräte, es überträgt nur Nachrichten in beide Richtungen.

=== Alternativen ===
Alternativen zu einem HMLAN Konfigurator sind [[HM-CFG-USB USB Konfigurations-Adapter]], [[CUN]], [[CUNO]] und [[CUL]].

==== HMUSB ====
Ein HMUSB hat nahezu identische Eigenschaften wie ein HMLAN Konfigurator. Der wesentliche Unterschied ist die Anbindung über USB anstatt Ethernet. Es hat sich erwiesen, dass USB eine bessere Latenz hat als LAN - also eine kürzere Verzögerung. Damit hat ein HMUSB leichte Vorteile zu HMLAN Konfigurator, was aber in den bei Weitem meisten Fällen durch die interne Timing Kalkulation abgefangen wird. Zudem können über den HMUSB (ab Version 2) auch Firmware-Updates OTA (over-the-air, also per Funkverbindung) auf entsprechende HM-Geräte (z.B. den HM-CC-RT-DN) durchgeführt werden.

Dafür bietet der HMLAN Konfigurator mit seinem Netzwerkanschluss Vorteile bei der Platzierung und bei der Ansteuerung (teilweise Timing-Probleme beim Anschluss von USB-Geräten an langsamere Raspberries und beim Durchschleifen von USB an fhem in einer virtuellen Maschine).

==== CUL/CUN(O) ====
* Die Devices liefern keine eigenen Zeitstempel, wodurch eine Timingkorrektur durch FHEM nicht möglich ist. Je nach Systemgeschwindigkeit kann dies zu Problemen, Nachrichten wiederholen und ggf. auch Nachrichtenverlust führen
* Da USB kurze Reaktionszeiten und geringe Timingschwankungen hat ist der Einsatz von [[CUL]] und [[CUNO]] mit HM möglich. Die Timingschwankungen der Ethernet-schnittstelle hingegen können in FHEM nicht ausgeglichen werden. Daher kann der Einsatz der [[CUNO]] über Ethernet '''nicht empfohlen''' werden.
* lazyConfig (ein Übertragungsmode) wird nicht unterstützt

=== Funktionen ===
==== AES ====
siehe [[AES Encryption]].

==== Übertragungsmodus ====
Es werden alle HM-Modi unterstützt. Diese sind Always, Burst, Wakeup und Config. Weiter gibt es lazyConfig und conditionalBurst. Siehe [[HomeMatic]] für Details.

==== KeepAlive ====
Der HMLAN Konfigurator baut eine Verbindung zur Zentrale über das LAN Interface auf. Der HMLAN Konfigurator erwartet alle 30 Sekunden eine keep-alive Nachricht von der Zentrale. Sollte diese ausbleiben, baut der HMLAN Konfigurator die LAN-Verbindung ab. Das führt zu einem Disconnect, der in State gemeldet wird. Die Verbindung wird automatisch wieder aufgebaut.
FHEM sendet den keep-alive alle 25 Sekunden, was einen 5 Sekunden Puffer einräumt. In Internals '''msgKeepAlive''' kann man sehen, wie hoch die maximale Verzögerung der Zentrale beim Senden war und wie viel Puffer (in Sekunden) noch verfügbar war.
Die Wiederholrate von 25 Sekunden des keep-alive kann mit dem Attribut '''wdTimer''' reduziert werden, was den Puffer erhöhen. Es wird jedoch dringend geraten, im Problemfall die Ursache der Verzögerung zu suchen und zu eliminieren.

==== Nachrichtenübertragung - Performance ====
* Mit Internal '''msgParseDly''' kann man ablesen, welche Verzögerung eine Nachricht vom Empfang im HMLAN Konfigurator bis zur Verarbeitung in der Zentrale hat.
* Der HMLAN Konfigurator hält sich an den Funkstandard, der einem Sender eine maximale Sendezeit je Stunde erlaubt. Wird dieser Wert überschritten, stellt der HMLAN Konfigurator das Senden ein. Empfangen wird weiter. Ist eine Kapazität von 90% erreicht, wird im Reading '''cond''' '''Warning-HighLoad''' gemeldet. Bei cond '''ERROR-Overload''' wird das Senden eingestellt ist.

==== Loggen/Mitschneiden ====
Es stehen die üblichen Funktionen des Attribute '''verbose''' zu Verfügung. Darüber hinaus gibt es die Attribute hmProtocolEvents und logIDs. Siehe auch [[Homematic Nachrichten sniffen|Homematic Nachrichten sniffen]].

== Vorbereitung ==
[[Datei:HMLAN_CONFIG_IP_AES.png|300px|thumb|right|HomeMatic Lan-Interface Configurator]][[Datei:HMLAN_CONFIG_AES.png|300px|thumb|right|HomeMatic Konfigurator]]
Bevor man den HMLAN mit Fhem nutzen kann, müssen noch Einstellungen vorgenommen werden. Dazu braucht man Software die bei [http://www.eq-3.de/software.html HomeMatic] in der Version 1.512 (Stand 19. Dezember 2013) herunter zu laden ist und nach der Installation mit der Verknüpfung "HomeMatic-Lan-Interface konfigurieren" oder "HomeMatic-Komponenten konfigurieren" gestartet wird und unter Windows läuft. Für andere Betriebssystem (siehe Anhang im Beitrag {{Link2Forum|Topic=11506|Message=67417|LinkText=Anleitung für OS X}}) braucht man eine Windows-Emulation. Dem HMLAN liegen zwei Konfigurationsprogramme bei, bitte darauf achten, das richtige zu verwenden. Wenn das Konfigurationsprogramm den HMLAN-Konfigurator nicht findet, sollten alle nicht benutzten Netzwerkinterfaces vorübergehend deaktiviert werden, siehe {{Link2Forum|Topic=10933|Message=62960|LinkText=Beitrag im Fhem Forum}} und [[HM-CFG-LAN_LAN_Konfigurations-Adapter#Bekannte_Probleme|bekannte Probleme]].

=== Firmware ===
Die aktuelle Firmware Version des HMLAN Konfigurators ist 0.964 (Stand November 2014). Ein Update ist unter ''"Update Firmware"'' mit der ''"HomeMatic Lan-Interface Configurator"'' Software möglich.

=== IP Adresse ===
Der HMLAN Konfigurator ist ähnlich wie der CUN(O) ein Netzwerkgerät. Er beherrscht DHCP und bezieht bei einem im Netzwerk erreichbaren DHCP Servers von diesem eine IP-Adresse. Da Fhem zwecks Kommunikation die IP-Adresse wissen muss, ist es sinnvoll, dem HMLAN Konfigurator eine statische Adresse zuzuweisen.
* mit der auf der CD mitgelieferten ''"HomeMatic Lan-Interface Configurator"'' Software unter ''"Change IP Settings"'' oder
* im DHCP-Server eine feste IP-Adresse zuzuweisen (sofern dies vom gegeben DHCP Server als Konfigurationsoption unterstützt wird).

=== AES Encryptet LAN Communication ===
Wichtig ist, dass vor Verwendung die "AES Encryptet LAN Communication" abgeschaltet wird, da diese FHEM nicht unterstützt. Dies ist unter ''"Change IP Settings"'' der ''"HomeMatic Lan-Interface Configurator"'' Software möglich. AES auf dem LAN ist zu unterscheiden von HMLAN auf der Funktschnittstelle. siehe [[AES Encryption]].

== Einbindung in FHEM ==
Der HMLAN-Konfigurator muss in FHEM [[Konfiguration|konfiguriert]] werden. Das erfolgt mit diesen Befehlen:
:<code>define HMLAN1 HMLAN <IP Adresse>:1000</code>
:<code>attr HMLAN1 hmId 123ABC</code>
Der Name (im obigen Beispiel ''HMLAN1'') kann frei vergeben werden. Standard IP-Port des HMLAN-Konfigurators ist 1000.

HMLAN kennt mehrere Attribute ([http://fhem.de/commandref.html#HMLAN commandref]).
Wichtig ist es, die '''hmId''' zu vergeben. Diese ist ein 3-Byte hexadezimal-Wert, somit eine 6-stellige Zeichenfolge in '''Großbuchstaben'''. 000000 und FFFFFF sind ungültig.
Wenn HM-Geräte mit der Zentrale gepairt werden, wird ihnen diese hmId eingetragen. Wechselt man die hmId müssen '''alle''' damit gepairten Geräte neu gepairt werden.

Die Adresse wird in Grossbuchstaben eingegeben, siehe [[HMLAN_Konfigurator#Bekannte_Probleme|"Bekannte Probleme"]].

Ein '''gleichzeitiger''' Zugriff von Fhem und der HomeMatic-Software auf den HMLAN-Konfigurator ist nicht möglich, da letzterer nur eine Verbindung zulässt. Wollen Sie temporär z.B. mit der Windows-Software von HomeMatic zugreifen, ist Fhem zu deaktivieren.
Sinnvoll ist es, die hmId mit der der PC-Software gleichzusetzen. Dann kann man von beiden Zentralen alternativ zugreifen ohne pairen zu müssen.

=== Nutzung mehrere IOs ===
==== Empfangen ====
Man kann an einem FHEM mehrere IOs (HMLAN/USB, CUL/CUNO) betreiben. Generell empfangen alle IOs von allen Geräten in ihrem Empfangsbereich - unabhängig von der hmId.

==== Senden ====
An ein Gerät wird nur über das IO gesendet, das in Internals->IODev angezeigt wird. Nutzt man mehrere IOs sollte im HM Device das Attribut IODev auf das gewünschte IO setzen. Ansonsten sucht FHEM zufällig ein IO aus.

==== hmId bei mehreren IOs ====
Man kann allen IOs die gleiche HMId setzen. Das erlaubt die wahlfreie Umschaltung des Sende-IOs für das Device. Sollte man unterschiedliche hmIds wählen simuliert dies mehrere Zentralen. Das Device, an das man sendet, muss über ein IO angesprochen werden, mit einer hmId auf die das Device gepairt ist. Wenn mehrere IOs verwendet werden sollen, empfiehlt sich die Verwendung einer [[Virtueller Controller VCCU|VCCU]], ansonsten kann es zu Problemen ("<code>Unknown code</code>", Angriffsmeldungen, Probleme beim Pairen, ...) kommen.

=== Attribute ===
* '''hmId''': Adresse, die das IO auf der Funkstrecke nutzt. Es ist ein 3-byte hexwert (6 Zeichen) in Großbuchstaben.
* '''hmkey, hmkey2..5''': bis zu 5 AES keys, die auf der Funkstrecke genutzt werden. Siehe [[AES Encryption]]
* '''hmLanQlen''' legt fest, wie viele Nachrichten parallel gesendet werden dürfen, also auf wie viele Antworten die Zentrale parallel warten darf. Ein Wert von 1 ist max defensiv, erzeugt aber eine höhere Verzögerung. Wählt man einen höheren Wert kann es zu Nachrichten-Wiederholunge kommen.
* '''hmProtocolEvents''': alle Nachrichten werden dekodiert ausgegeben. Diese Einstellung benötigt einige Performance insbesondere bei höheren Level. Man sollte es vorsichtig nutzen.
* '''logIDs''': zeichnet Rohmessages auf und bietet die genaueste Methode bei der Fehlersuche. Da Nachrichten undekodiert ausgegeben werden ist es im Wesentlichen für Spezialisten von Bedeutung. Man gibt eine Komma getrennte Liste von IDs an, die geloggt werden sollen. Mit '''all''' werden alle IDs aufgezeichnet. '''sys''' zeichnet zusätzlich Systemmessages auf. '''sys,all''' somit alles.
* '''respTime''': Antwortzeit des HMLAN auf ein keep-alive kann hier eingestellt werden. Normalerweise sollte das HMLAN in einer Sekunde der Zentrale antworten. Sollte dies nicht passieren, wird die Message wiederholt. Der Wert sollte nur in Ausnahmefällen verändert werden.

=== Readings ===
* '''Xmit-Events''': Anzahl der Ereignisse
* '''cond''': aktueller Zustand des IO.
** ok
** Warning-HighLoad: 90% der 1h sendekapazität sind erreicht
** ERROR-Overload: 100% der sendekapazität sind erreicht, '''das IO sendet nicht mehr'''
** timeout
** disconnected: die Verbindung FHEM /IO ist unterbrochen
** Overload-released: das IO ist aus ERROR-Overload zurück im Sendebetrieb
** init: Das IO wurde neu initialisiert.
* '''prot_ERROR-Overload''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_Warning-HighLoad''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_disconnected''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_init''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_ok''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_timeout''': Anzahl des Events, Zeitstempel des letzten Auftretens

=== Internals ===
* '''XmitOpen''': 1 = HMLAN ist sende bereit
* '''assignedIDs''': HMIDs der HM Devices, die über dieses IO bedient werden
* '''assignedIDsCnt''': Anzahl der zugewiesenen HMIds von FHEM
* '''assignedIDsReport''': Anzahl der HMIds, die das HMLAN angibt zu bedienen. Die Zahl sollte identisch sein mit assignedIDsCnt
* '''msgKeepAlive''': dlyMax: maximale Verzögerung, die ein keep-alive hatte. bufferMin: der minimale Zeitpuffer, der übrig blieb, bis das keep-alive zu spät gekommen wäre. Der Puffer sollte 2 oder größer sein, sonst könnte man gelegentlich disconnects bekommen.
* '''msgLoadEst''': Funkbelastung des HMLAN. Der Wert wird über 1 Stunde akkumuliert. Sollten 100% erreicht sein, wird das HMLAN den Sendebetrieb einstellen. Der Wert ist eine Hochrechnung in FHEM. Es ist möglich, dass das HMLAN mehr belastet ist. Die 10 min werte zeigen die Belastung in den letzten 10min Perioden an.
* '''msgParseDly''': Verzögerung der Message Verarbeitung vom Empfang im IO bis zur Verarbeitung in FHEM. Eine Verzögerung kann durch Prozesse an LAN, durch FHEM Prozesse oder sonstige Prozesse/Applikationen der CPU hervorgerufen werden.

== Pairen von Geräten ==
Jedes HM Geräte muss vor Verwendung mit der HM-Zentrale gepairt werden. Dabei wird die hmId des gewählten IOs in das Device programmiert. Ändert man die hmId des IO, mit man das Device anspricht, muss man das Device neu pairen.
Alle Geräte haben eine eigene Seriennummer, die nicht änderbar ist. Details zum Pairen auf der Seite [[HomeMatic Devices pairen]].

== Bekannte Probleme ==
Selten lehnt der HMLAN-Konfigurator ohne erkennbaren Grund nach monatelangem störungsfreiem Betrieb die Verbindung ab:

Opening HMLAN1 device 192.168.168.60:1000
192.168.168.60:1000 connection refused
Der HMLAN-Konfigurator kann aber über die mitgelieferte Konfigurationssoftware problemlos erreicht werden. Der Zustand lässt sich auch durch einen Reboot des HMLAN-Konfigurators (oder Fhem) nicht beheben, wohl aber durch eine Aktualisierung der Firmware des HMLAN-Konfigurators, selbst wenn die installierte Version aktuell ist.

Wenn das Konfigurationsprogramm Probleme hat, den HM-CFG-LAN LAN Konfigurations-Adapter zu finden, sollten alle nicht benutzten Netzwerkinterfaces vorübergehend deaktiviert werden. Vereinzelt gibt es Hinweise darauf, dass es unter Windows 7 eventuell nicht reicht, die Netzwerkverbindungen im "Netzwerk- und Freigabecenter" zu deaktivieren, sondern ein Deaktivierung der Netzwerkadapter im Gerätemanager erforderlich ist.

== Verbesserung der Antennenleistung ==

Die Sende- und Empfangsleistung kann man verbessern. Details [[Trick_der_Woche#HM_LAN_Konfig-Adapter_Antenne_verbessern|hier]].

== Wechsel von CUL zu HMLAN ==
Sollten Sie ein [[CUL]] als IO für Homematic-Geräte eingesetzt haben und jetzt einen Wechsel auf den HMLAN Konfigurator planen, hält sich der Aufwand in Grenzen:

* deaktivieren Sie das CUL in der ''fhem.cfg''.
* konfigurieren Sie den HMLAN Konfigurator '''von Hand'''
* Ändern sie das Attribut IODev aller HM-Devices vom Namen der CUL auf den Namen des HMLAN
* sollte sie das Attribut IODev nicht nutzen (nicht empfohlen) achten sie darauf, dass im fhem.cfg das IO vor allen HM-devices definiert wird. Eine automatischen Zuweisung des IO zu den Devices ist sonst nicht möglich.
** der HMLAN '''muss''' die gleiche ''hmId'' wie das bisherige CUL erhalten. Ansonsten müssen alle Geräte neu gepairt / angelernt werden.
** AES muss im HMLAN abgeschaltet werden.
* verbinden Sie den HMLAN Konfigurator mit ihrem Netzwerk und ziehen das CUL aus der USB-Buchse.
* geben Sie in der FHEM-Befehlszeile ''shutdown restart'' gefolgt von <Enter> (nicht "save") ein (evtl. reicht auch ein ''rereadcfg'').
* kontrollieren Sie im Event-Monitor und in den HM-Device-Logs von Fhem die Kommunikation.

Bitte beachten: Falls dem CUL keine explizite hmId per Attribut zugewiesen wurde, wird diese ID aus "F1<FHT-ID>" zusammengebaut. Die hmId muss auf dem HMLAN explizit gesetzt werden.

== Links ==
* [http://www.eq-3.de/software.html Software] für den Konfigurationsadapter von der eQ-3 Site
* [[Trick_der_Woche#HM_LAN_Konfig-Adapter_Antenne_verbessern|HM LAN Konfig-Adapter Antenne verbessern]]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]

HM-CFG-USB USB Konfigurations-Adapter

2015-06-30T12:35:59Z

Mgernoth: /* Bekannte Probleme */ Kompatibilitaetsprobleme neuer hmland, altes Fhem mit Loesung beschrieben

{{Infobox Hardware
|Bild=platzHalter.png
|Bildbeschreibung=todo
|HWProtocol=HomeMatic
|HWType=Interface/Gateway
|HWCategory=HomeMatic
|HWComm=868,3MHz
|HWChannels=
|HWVoltage=
|HWPowerConsumption=
|HWPoweredBy=USB-Bus
|HWSize=
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]

|HWManufacturer=HomeMatic
}}
Der [[HomeMatic]] '''USB Konfigurations-Adapter''' ist ein USB-Stick, der außer zur Konfiguration von HomeMatic Komponenten auch als [[Interface]] zwischen Fhem und HomeMatic Geräten benutzt werden kann. Er existiert in zwei Versionen: der älteren HM-CFG-USB und der neueren HM-CFG-USB2. Die folgenden Beschreibungen gelten für beide Versionen, es sei denn, es ist ausdrücklich eine spezifische Version genannt.

== Einbindung in Fhem ==
Im Fhem-Forum wird die Einbindung als Interface in diesem {{Link2Forum|Topic=13071}} beschrieben und diskutiert. Im {{Link2Forum|Topic=13071|Message=79872|LinkText=Eröffnungsbeitrag}} wird eine gut funktionierende HMLAN-Emulationssoftware [https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb hmland] von ihrem Entwickler vorgestellt, um den HM-CFG-USB in Fhem zu integrieren. Die HMLAN-Emulationssoftware muss zunächst kompiliert und installiert werden. Anschließend wird der HM-CFG-USB (üblicherweise auf localhost) genau wie [[HM-CFG-LAN LAN Konfigurations-Adapter|HMLAN]] in Fhem eingebunden.

=== Einrichtung unter Linux ===
Die Schritte zur Kompilierung und Installation hat der hmland-Entwickler sowohl auf der [https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb hmland-Internetseite] in Englisch (kurz) als auch im oben genannten {{Link2Forum|Topic=13071|Message=79872|LinkText=Eröffnungsbeitrag}} in Deutsch (ausführlich) dargestellt. Die dort gemachten Angaben werden auch bei Bedarf aktualisiert und sind deshalb der beste Anlaufpunkt für Kompilierung und Installation.

Die nachfolgenden Angaben in diesem Abschnitt sind rein zu Informationszwecken (noch) enthalten:

Zunächst muss die HMLAN-Emulationssoftware kompiliert werden. Analog zu [https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb dieser Beschreibung] ist die Vorgehensweise die folgende (in Debian/Ubuntu/Raspbian):
cd /opt/
apt-get install build-essential libusb-1.0-0-dev make gcc git-core
git clone git://git.zerfleddert.de/hmcfgusb
cd hmcfgusb
make

(Unter Debian ist "build-essentials" nicht als Paket vorhanden, dieser Schritt kann entfallen.)

Danach kann der Dienst zu Testzwecken gestartet werden (in /opt/hmcfgusb):
:<code>./hmland -p 1234 -D</code>

==== Start als Daemon ====
Um den hmland als Daemon mit dem Betriebsystem automatisiert zu starten, kann ein init-script genutzt werden. In diesem {{Link2Forum|Topic=13071|Message=190887}} ist ein Skript zur automatischen Einrichtung von hmland als Daemon über init mit Installationsanweisung enthalten. Dieses Skript enthält zudem auch die Befehle zum Download, Kompilierung und Installation von hmland, so dass fast keine manuellen Eingriffe notwendig sind.

Alternativ ist auch der (umständlichere) manuelle Weg möglich:
<pre>
#!/bin/sh
### BEGIN INIT INFO
# Provides: hmland
# Required-Start: $localfs $syslog $remote_fs
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: hmland daemon
# Description: hmland daemon, Homematic USB Adapter on port 1234
### END INIT INFO

# simple init for hmland

pidfile=/var/run/hmland.pid
port=1234

case "$1" in
start|"")
chrt 50 /opt/hmcfgusb/hmland -d -P -l 127.0.0.1 -p $port 2>&1 | perl -ne '$|=1; print localtime . ": [hmland] $_"' >> /var/log/hmland.log &
;;
restart|reload|force-reload)
echo "Error: argument '$1' not supported" >&2
exit 3
;;
stop)
killall hmland
;;
status)
if [ ! -e $pidfile ]; then
echo "No pid"
exit 1
fi
pid=`cat $pidfile`
if kill -0 $pid &>1 > /dev/null; then
echo "Running"
exit 0
else
rm $pidfile
echo "Not running"
exit 1
fi

;;
*)
echo "Usage: hmland [start|stop|status]" >&2
exit 3
;;
esac
</pre>

Bei Distributionen, die Upstart einsetzen (z.B. xbian) kann folgendes Konfigurationsfile verwendet werden:
<pre>
# HMLAND

description "hmland"

start on starting fhem
stop on stopped fhem

respawn
expect fork

chdir /opt/hmcfgusb
exec /opt/hmcfgusb/hmland -d -l 127.0.0.1 -p 1234
</pre>

Die Datei sollte als "/etc/init/hmland.conf" angelegt werden. Mit dem Befehl
initctl reload-configuration
wird Upstart angewiesen, seine Konfiguration erneut einzulesen. Danach kann der neue Dienst
mit
service hmland start
gestartet werden. <code>hmland</code> wird jetzt immer vor Fhem gestartet und nach Fhem beendet.

==== Start über Fhem Startskript ====

Ausprobiert auf einem BBB mit Debian, eigentlich ist das alles von Betateilchen:

Zunächst hmland kompilieren wie oben beschrieben, bis zum make. Das muss erfolgreich durchgelaufen sein.

Dann geht es weiter:

sudo cp hmcfgusb.rules /etc/udev/rules.d/

Jetzt das Fhem Startskript anpassen (in den Blöcken 'start' und 'stop' muss quasi nur jeweils 1 Zeile eingefügt werden:

Damit editiert man das Fhem Startskript:
sudo nano /etc/init.d/fhem

Und so sollten die Blöcke anschließend aussehen (bitte nur jeweils die Zeile mit hmland einfügen)

'start')
echo "Starting fhem..."
/opt/hmcfgusb/hmland -d -p 1234
perl fhem.pl fhem.cfg
RETVAL=$?
;;

'stop')
echo "Stopping fhem..."
perl fhem.pl $port "shutdown"
RETVAL=$?
pkill hmland

So wird hmland vor Fhem gestartet und nach Fhem beendet. Letztlich erspart es Probleme mit den diversen Startskripten und ihren Rechten.

Es dauert nach dem Start von Fhem noch einige Sekunden, bis hmland fertig geladen ist. In dieser Zeit kann es zu fehlerhaften Einträgen im Logfile kommen.

=== Einrichtung unter Mac OS X ===
Wie unter Linux braucht man die HMLAN-Emulationssoftware hmland, die man aus Quelltexten erstellen muss. Dazu muss man die Bibliothek libusb installieren, entweder mit einem der Paketmanager wie Fink, MacPorts oder Homebrew oder direkt aus den Quellentexten (Beispiel: "fink install libusb1-shlibs libusb1"). Hat man wie bei Linux das Quelltextarchiv für hmland heruntergeladen und ausgepackt, müssen die Dateien Makefile und hmcfgusb.c angepasst werden.

Im Makefile muss man den Pfad zur libusb anpassen. Hat man libusb mit fink installiert, muss man, "/opt/local/" durch "/sw/" bei den CFLAGS und den LDFLAGS ersetzen und
das "-lrt" aus den LDLIBS entfernen. Die Library librt gibt es bei Mac OS X nicht und wird anscheinend auch nicht gebraucht. (Stimmt das eigentlich?)

In der Datei hmcfgusb.c muss man die Zeilen 130-134 mit dem Aufruf libusb_detach_kernel_driver auskommentieren oder löschen. Der geht nicht auf Mac OS X.

Nach den Änderungen in den zwei Dateien, kann man wie bei Linux den Dämon hmland mit dem Kommando "make" erzeugen und mit "./hmland" ausführen. Automatisches Starten beim Booten mit launchd ist noch nicht probiert.

Beim Start von hmland sollte man folgende Fehlermeldung in einer Endlos-Schleife erhalten:

Datum Zeit: Client 127.0.0.1 connected! 
Can't claim interface: Access denied (insufficient permissions) 
Can't find/open hmcfgusb! 
Datum Zeit: Connection to 127.0.0.1 closed! 

Auch ein Start von hmland mit Superuser-Rechten ändert daran nichts. Damit das claim interface klappt, muss man eine codeless kext in den Ordner /Library/Extensions legen. Ich habe dieses (http://mspdebug.sourceforge.net/misc/ex430rf2500-kext.zip) herunter geladen. Damit es funktioniert, muss man aber in der Datei Info.plist des Bundle die Properties idProduct und idVendor ändern, entweder mit dem Property List Editor oder einem anderen Texteditor. Die beiden Properties sind etwas versteckt bei Information Property List → IOKitPersonalities → ComIntf. Bei DebugIntf und DeviceDriver scheint man es nicht ändern zu müssen, aber schaden kann es nicht. 

idProduct: 49167 
idVendor: 6943

Die Rechte des kext-Bundles müssen auch noch gesetzt werden:

chmod -R 755 ex430rf2500.kext
chown -R root:wheel ex430rf2500.kext

Danach die Datei ex430rf2500.kext in den Ordner /Library/Extensions legen und hmland sollte dann funktionieren.

Es kann sein, dass ab Mac OS X 10.9 der Trick mit dem codeless kext nicht mehr funktioniert, aber noch ist das nicht getestet oder bestätigt. Langfristig kann man vielleicht auch eine kext mit einem Treiber für den HM-CFG-USB USB erstellen

=== Einrichtung unter Windows ===
Bei der Einrichtung und vermutlich auch dem Betrieb unter Windows 8.1 sind wegen der erweiterten Energieverwaltungsfunktionen die von eQ-3 [http://www.eq-3.de/Downloads/eq3/pdf_FAQ/Funk-Konfigurationsdapter-USB_Windos_8.1.pdf zusammengestellten Tipps] zu befolgen.

== Bekannte Probleme ==
=== Verbindung zu neueren hmland-Versionen nicht stabil ===
Seit Version 0.100 meldet sich die HMLAN-Emulationssoftware als USB-Interface bei Fhem. Ältere Fhem-Versionen (vor dem 19.6.2015) brechen deshalb die Verbindung ab, da sie nur ein LAN-Interface erwarten.

Lösung: Kommandozeilenparameter <code>-I</code> dem hmland-Aufruf hinzufügen, dann meldet sich dieser wieder als LAN-Interface.

=== Stick nicht (mehr) ansprechbar ===
Zitat aus dem {{Link2Forum|Topic=32502|Message=249122|LinkText=Fhem-Forum}}:
:''... befürchte ich, dass dein Stick das Zeitliche gesegnet hat. Machen die Dinger leider sehr gerne... Ganz besonders beim Modus-Wechsel vom 10k- in den 100k-Modus, wenn man bei irgendeinem Device ein Firmwareupdate durchführt. Die gute Nachricht ist, dass der Fehler bei sämtlichen Händlern bekannt ist und anstandslos getauscht wird.''

=== Raspberry Pi ===
Der USB-Stack am Raspberry Pi ist für viele Probleme verantwortlich. Daher sieht man öfter Fehlermeldungen:
:<code>usb-transfer took more than 100ms (1039ms), this may lead to timing problems!</code>

Da das Timing bei Homematic wichtig ist führt das zu vielen Retransmits und zu unzuverlässigen Aktoren. Als Workaround kann man den USB-Stack auf die deutlich langsamere Version 1.1 stellen. Dazu fügt man folgenden Text am Anfang der Datei /boot/cmdline.txt ein:
:<code>dwc_otg.speed=1</code>

=== Windows ===
Die erweiterte Energieverwaltung unter Windows 8.1 kann dazu führen, dass der Adapter unerwünschterweise in den Stand-by Modus versetzt wird (siehe [[HM-CFG-USB USB Konfigurations-Adapter#Einrichtung unter Windows|Einrichtung unter Windows]]).

== Weitergehende Informationen ==
Es sind zwei Versionen des HM-CFG-USB im Umlauf:
* HM-CFG-USB-2: die aktuelle Version; Dokumentation derzeit (12/2013) nicht über die ELV-Artikelseite verfügbar, alternativ jedoch bei [http://files.voelkner.de/625000-649999/640558-an-01-ml-USB_FUNK_KONFIGURATIONSADAPTER_de_en.pdf Völkner]; Kennzeichen dieser Version:
** Größe: 28 x 84 x 11,5 mm
** Gewicht: 18 g
** Antenne innenliegend
* HM-CFG-USB: Vorgängerversion; Stand 12/2013 noch Restbestände im Handel verfügbar. Dokumentation ([http://files.voelkner.de/625000-649999/646462-an-01-ml-HM_Konfigurationsadapter_CFG_USB_de_en.pdf Völkner]); Kennzeichen:
** Anschluss per separatem USB-Kabel
** abstehende Stabantenne
** Größe: 40 x 90 x 25 mm
** Gewicht: 45 g

== Links ==
* Fhem-Forums {{Link2Forum|Topic=13071}}: HomeMatic USB Konfigurations-Adapter (HM-CFG-USB) in Fhem nutzen
* [http://www.elv.de/homematic-usb-konfigurations-adapter-1.html ELV Shopseite] zum HM-CFG-USB
* [http://www.eq-3.de/produkt-detail-zentralen-und-gateways/items/homematic-funk-konfigurationsadapter-usb.html eQ-3 Produktseite] zum "HomeMatic Funk-Konfigurationsadapter USB"; Downloads, technische Daten, etc.

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]
[[Kategorie:OSX]]

AES Encryption

2015-06-28T10:25:38Z

Mgernoth: CUL/CUNO unterstützen jetzt AES

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 kann ein HMUSB, HMLAN oder eine CUL/CUNO (seit dem 28.6.2015) genutzt werden. Die Kommunikation ist wie weiter unten beschrieben auf Signaturbasis.

=== 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 also auf einen 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 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,...)
* das Schalten von Aktoren

== Aktivieren, Einrichten, Umgang in FHEM ==
*Zuerst muss ein Schlüssel vergeben 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.
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 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 3 Schlüssel eingetragen werden können (hmKey hmKey2 hmKey3). 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 Konfigurator, HMUSB, CUL und CUN(O) unterstützt.
* 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 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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-06-24T08:49:41Z

Mgernoth: Aktoren werden auch gesichert

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.

=== 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 also auf einen 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 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,...)
* das Schalten von Aktoren

== Aktivieren, Einrichten, Umgang in FHEM ==
*Zuerst muss ein Schlüssel vergeben 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.
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 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 3 Schlüssel eingetragen werden können (hmKey hmKey2 hmKey3). 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 Konfigurator 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-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 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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-06-23T16:05:53Z

Mgernoth: Keys koennen auch von Fhem gesetzt werden

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.

=== 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 also auf einen 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 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 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.
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 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 3 Schlüssel eingetragen werden können (hmKey hmKey2 hmKey3). 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 Konfigurator 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-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 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.

[[Kategorie:HomeMatic Components]]

AES Encryption

2015-06-23T16:05:10Z

Mgernoth: assignHmKey beschrieben

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 also auf einen 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 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 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.
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 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 3 Schlüssel eingetragen werden können (hmKey hmKey2 hmKey3). 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 Konfigurator 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-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 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.

[[Kategorie:HomeMatic Components]]