AES Encryption - Versionsgeschichte

AndreasMohr: Typos/Spelling

2018-01-10T22:13:53Z

Typos/Spelling

Martinp876 am 29. Dezember 2017 um 10:28 Uhr

2017-12-29T10:28:45Z

← Nächstältere Version		Version vom 29. Dezember 2017, 12:28 Uhr
Zeile 103:		Zeile 103:
	*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.		*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]]		[[Kategorie:HomeMatic Components\|2Info]]

MGu: Typo und Formatierung

2017-06-18T17:06:54Z

Typo und Formatierung

Änderungen zeigen

Krikan: FHEM(R)

2017-01-24T17:25:30Z

FHEM(R)

← Nächstältere Version		Version vom 24. Januar 2017, 19:25 Uhr
Zeile 36:		Zeile 36:
	Die Kommunikation auf Signaturbasis ist im Abschnitt [[#Ablauf\|Ablauf]] beschrieben.		Die Kommunikation auf Signaturbasis ist im Abschnitt [[#Ablauf\|Ablauf]] beschrieben.

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

Zeile 75:		Zeile 75:
	* 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.		* 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		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.		* 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 Geraet aesCommReq 1
	attr Schalter aesCommReq 1		attr Schalter aesCommReq 1

Ph1959de: Forenlink korrigiert; Schreibweise HomeMatic korrigiert

2017-01-23T14:53:12Z

Forenlink korrigiert; Schreibweise HomeMatic korrigiert

← Nächstältere Version		Version vom 23. Januar 2017, 16:53 Uhr
Zeile 1:		Zeile 1:
	=Grundlagen=		=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.		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.		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.

Zeile 19:		Zeile 19:
	*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.		*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.		*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.		*Letztlich gibt es noch die Geräte-Geräte Schnittstelle für die direkte Kommunikation der HomeMatic-Geräte untereinander.

	== Zentrale <-> Frontend ==		== Zentrale <-> Frontend ==
Zeile 25:		Zeile 25:

	== Zentrale <-> I/O-Device ==		== Zentrale <-> I/O-Device ==
	~~Homematic~~ unterstützt auf dieser Strecke prinzipiell eine AES-Verschlüsselung, dies ist in FHEM allerdings nicht überall implementiert. Nutzt man stattdessen eine originale ~~Homematic~~ CCU2-Zentrale, kann hier AES aktiviert werden. Wenn FHEM die Zentrale ist, muss im [[HMLAN Konfigurator]] die netzwerkseitige AES-Verschlüsselung über die HM-PC-Software abgeschaltet werden, sonst kann FHEM nicht mit dem [[HMLAN Konfigurator]] kommunizieren.		HomeMatic unterstützt auf dieser Strecke prinzipiell eine AES-Verschlüsselung, dies ist in FHEM allerdings nicht überall implementiert. Nutzt man stattdessen eine originale HomeMatic CCU2-Zentrale, kann hier AES aktiviert werden. Wenn FHEM die Zentrale ist, muss im [[HMLAN Konfigurator]] die netzwerkseitige AES-Verschlüsselung über die HM-PC-Software abgeschaltet werden, sonst kann FHEM nicht mit dem [[HMLAN Konfigurator]] kommunizieren.
	Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway]] kann mit und ohne LAN AES genutzt werden (Konfiguration mit Lankonfigurator/Netfinder von eq3). Für LAN AES muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein.		Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway]] kann mit und ohne LAN AES genutzt werden (Konfiguration mit Lankonfigurator/Netfinder von eq3). Für LAN AES muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein.

Zeile 37:		Zeile 37:

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

	Bei CUL Kompatiblen Geräten kann es zu Timingproblemen kommen. Für CUL Geräte ist für HomeMatic generell die ~~[https://forum.fhem.de/index.php/topic,~~31421~~.0.html~~\|TS Firmware] angeraten!		Bei CUL Kompatiblen Geräten kann es zu Timingproblemen kommen. Für CUL Geräte ist für HomeMatic generell die {{Link2Forum\|Topic=31421\|LinkText=TS Firmware}} angeraten!

	Beim Einsatz von AES-CBC, z.B. dem Rauchmelder HM-SEC-SD-2, wird generell das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) benötigt!		Beim Einsatz von AES-CBC, z.B. dem Rauchmelder HM-SEC-SD-2, wird generell das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) benötigt!
Zeile 54:		Zeile 54:
	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 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.		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==		==Sicherheit==

Otto123: /* I/O-Device Gerät */ TS Software als Hinweis hinzugefügt

2017-01-22T13:45:47Z

I/O-Device Gerät: TS Software als Hinweis hinzugefügt

← Nächstältere Version		Version vom 22. Januar 2017, 15:45 Uhr
Zeile 38:		Zeile 38:
	Es kann ein [[HomeMatic#Fhem_als_Zentrale\|HomeMatic]] IO oder ein [[CUL]] kompatibler Io genutzt werden.		Es kann ein [[HomeMatic#Fhem_als_Zentrale\|HomeMatic]] IO oder ein [[CUL]] kompatibler Io genutzt werden.
	Die Homematic Module und IOs können AES von sich aus. Für alle [[CUL]]-kompatiblen Geräte muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein.		Die Homematic Module und IOs können AES von sich aus. Für alle [[CUL]]-kompatiblen Geräte muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein.

			Bei CUL Kompatiblen Geräten kann es zu Timingproblemen kommen. Für CUL Geräte ist für HomeMatic generell die [https://forum.fhem.de/index.php/topic,31421.0.html\|TS Firmware] angeraten!

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

Otto123: /* I/O-Device Gerät */

2017-01-22T13:41:23Z

I/O-Device Gerät

← Nächstältere Version		Version vom 22. Januar 2017, 15:41 Uhr
Zeile 36:		Zeile 36:
	Die Kommunikation auf Signaturbasis ist im Abschnitt [[#Ablauf\|Ablauf]] beschrieben.		Die Kommunikation auf Signaturbasis ist im Abschnitt [[#Ablauf\|Ablauf]] beschrieben.

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

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

Otto123: /* I/O-Device Gerät */ Den aktuellem Stand angepasst

2017-01-22T13:36:53Z

I/O-Device Gerät: Den aktuellem Stand angepasst

← Nächstältere Version		Version vom 22. Januar 2017, 15:36 Uhr
Zeile 33:		Zeile 33:

	== I/O-Device <-> Gerät ==		== 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~~.		Dieses Teilstück kann mit AES gesichert werden.
			Die Kommunikation auf Signaturbasis ist im Abschnitt [[#Ablauf\|Ablauf]] beschrieben.

			Es kann ein [[#Fhem_als_Zentrale\|HomeMatic]] IO oder ein [[CUL]] kompatibler Io genutzt werden.
	Die Homematic Module und IOs können AES von sich aus. Für alle [[CUL]]-kompatiblen Geräte muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein.		Die Homematic Module und IOs können AES von sich aus. Für alle [[CUL]]-kompatiblen Geräte muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein.
	Beim Einsatz von AES-CBC, z.B. dem Rauchmelder HM-SEC-SD-2, wird generell das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) benötigt!		Beim Einsatz von AES-CBC, z.B. dem Rauchmelder HM-SEC-SD-2, wird generell das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) benötigt!

Otto123: /* Zentrale I/O-Device */ AES für LGW Modul nachgetragen

2016-12-19T10:32:01Z

Zentrale I/O-Device: AES für LGW Modul nachgetragen

← Nächstältere Version		Version vom 19. Dezember 2016, 12:32 Uhr
Zeile 25:		Zeile 25:

	== Zentrale <-> I/O-Device ==		== 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.		Homematic unterstützt auf dieser Strecke prinzipiell eine AES-Verschlüsselung, dies ist in FHEM allerdings nicht überall implementiert. Nutzt man stattdessen eine originale Homematic CCU2-Zentrale, kann hier AES aktiviert werden. Wenn FHEM die Zentrale ist, muss im [[HMLAN Konfigurator]] die netzwerkseitige AES-Verschlüsselung über die HM-PC-Software abgeschaltet werden, sonst kann FHEM nicht mit dem [[HMLAN Konfigurator]] kommunizieren.
			Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway]] kann mit und ohne LAN AES genutzt werden (Konfiguration mit Lankonfigurator/Netfinder von eq3). Für LAN AES muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein.

	Es sind 2 Schnittstellen zu betrachten:		Es sind 2 Schnittstellen zu betrachten:

Otto123: /* I/O-Device Gerät */

2016-11-29T12:49:40Z

I/O-Device Gerät

← Nächstältere Version		Version vom 29. November 2016, 14:49 Uhr
Zeile 32:		Zeile 32:

	== I/O-Device <-> Gerät ==		== 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.		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.
			Die Homematic Module und IOs können AES von sich aus. Für alle [[CUL]]-kompatiblen Geräte muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein.
			Beim Einsatz von AES-CBC, z.B. dem Rauchmelder HM-SEC-SD-2, wird generell das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) benötigt!

	==Gerät <-> Gerät==		==Gerät <-> Gerät==

← Nächstältere Version		Version vom 11. Januar 2018, 00:13 Uhr
Zeile 1:		Zeile 1:
	= Grundlagen =		= 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.		Anders als der Name vermuten lässt, handelt es sich beim HM (HomeMatic) AES-Encryption Modus des "BidCoS"-Protokolls nicht um verschlüsselten Funkverkehr, sondern um das Einschalten eines Signatur-Modus (AES-Challenge-Response (CR)). Hierbei muss sich der Sender durch das Signieren seiner Nachrichten mit einem allen Kommunikationspartnern bekannten AES-Schlüssel authentifizieren. Der Empfänger wird das Kommando nur ausführen, wenn die Authentifizierung korrekt ist.
	Die eigentliche Datenübertragung findet im Klartext statt und kann immer mitgelesen bzw. abgehört werden, jedoch werden keine Kommandos von nicht ~~autorisierter~~ Quellen ausgeführt.		Die eigentliche Datenübertragung findet im Klartext statt und kann immer mitgelesen bzw. abgehört werden, jedoch werden keine Kommandos von nicht autorisierten Quellen ausgeführt.

	Der AES-Encryption Modus sichert, wenn eingeschaltet		Der AES-Encryption Modus sichert, wenn eingeschaltet
Zeile 12:		Zeile 12:

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

	= Kommunikationsstrecken =		= Kommunikationsstrecken =
Zeile 29:		Zeile 29:

	Es sind 2 Schnittstellen zu betrachten:		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.		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.		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.

Zeile 36:		Zeile 36:
	Die Kommunikation auf Signaturbasis ist im Abschnitt [[#Ablauf\|Ablauf]] beschrieben.		Die Kommunikation auf Signaturbasis ist im Abschnitt [[#Ablauf\|Ablauf]] beschrieben.

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

Zeile 61:		Zeile 61:
	= Aktivieren, Einrichten, Umgang in FHEM =		= Aktivieren, Einrichten, Umgang in FHEM =
	== Zentrale ==		== 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 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.		** 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.		** 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.
	:: <code>attr VCCU hmKey geheimerSchluessel</code>		:: <code>attr VCCU hmKey geheimerSchluessel</code>
	*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.		*Der zweite Schritt besteht darin, den Schlüssel mit dem höchsten Index mit dem gerätespezifischen FHEM-Kommando ''assignHmKey'' an alle gepairten Geräte zu übertragen, mindestens aber an diejenigen, bei denen der AES-Encryption Modus eingeschaltet werden soll. Es ist aber auch möglich, diese Aktion mit der HM Konfigurationssoftware (HM-PC-Software) oder einer CCU durchzuführen.
	:: <code>set Geraet assignHmKey</code>		:: <code>set Geraet assignHmKey</code>
	:: <code>set Schalter assignHmKey</code>		:: <code>set Schalter assignHmKey</code>
Zeile 84:		Zeile 84:
	* Die zusätzliche Kommunikation führt zu einer Verzögerung von etwa 200ms je Vorgang.		* 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]]		* 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.		* 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.		* Ein Sicherheitsgewinn ist nur gegeben, wenn ein eigener System-Sicherheitsschlüssel genutzt wird.

	== Hinweise ==		== 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.		Eine Steigerung der Sicherheit ergibt sich nur, wenn man den werksseitig vorgegebenen Schlüssel ändert. Solange Angreifern der eigene Schlüssel unbekannt bleibt, ist ein Fremdschalten oder die Änderung der Konfiguration nicht mehr möglich, wohl aber ein Ermitteln des aktuellen Schaltzustandes.

	Wurde ein eigener Schlüssel vergeben der nicht mehr bekannt ist und wird dann die Zentrale zurückgesetzt oder ausgetauscht ohne die Komponenten vorher auf Werkseinstellung zurückzusetzen, sind die entsprechenden Komponenten '''nicht mehr verwendbar'''. Die Geräte müssen kostenpflichtig eingeschickt und zurückgesetzt werden.		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.
Zeile 101:		Zeile 101:
	== Bekannte Probleme ==		== 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.		* 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.		*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\|2Info]]		[[Kategorie:HomeMatic Components\|2Info]]