SixML - Security

Verschlüsselung von SixML-Nachrichten

Um die Privatsphäre zu wahren bzw. den unauthorisierten Zugriff auf Geräte zu unterbinden, können sämtliche SixML-Nachrichten auch verschlüsselt übertragen werden. Um den Aufwand für Geräte und Klienten zu minimieren wird dafür ein symmetrisches Verfahren genutzt. Im aktuellen Standard sind zwei gültige Algorithmen definiert (TripleDES und AES). Geräte und Klienten müssen zum Nachrichtenaustausch deshalb Kenntnis von einem gemeinsamen Schlüssel haben; im einfachsten Fall benutzen alle Teilnehmer des lokalen Netzes den gleichen Schlüssel.

Es ist möglich, innerhalb des lokalen Netzes Nachrichten nur für bestimmte Schnittstellen zu verschlüsseln (z.B. nur in einfach belauschbaren Funknetzen im 868 MHz Bereich). In diesem Fall ist das Gateway für das transparente Ver- und Entschlüsseln von Nachrichten zuständig.

Schlüsselverwaltung auf den Geräten

Schlüssel werden auf den Geräten über den KeyManagement-Dienst verwaltet. Dieser bietet im Normalfall lediglich Lesezugriff auf Schlüssel-Metadaten, um z.B. zu ermitteln, ob ein Gerät einen bestimmten Schlüssel kennt oder nicht. Jedes Gerät nutzt pro ZoneID maximal einen Schlüssel, z.B. zum Verschlüsseln von Event-Nachrichten. Nach manueller Freigabe z.B. über einen Taster können dem KeyManagement-Dienst für 2 Minuten neue Schlüssel zugewiesen werden (über Events des ZoneManagement-Dienstes, siehe folgende Abschnitte), die aktuelle ZoneID kann geändert werden bzw. der Schlüssel für ausgehende Nachrichten kann gewählt werden.

Schlüsselverwaltung im KeyMaster

Schlüssel werden über eine KeyID identifiziert, welche innerhalb des lokalen Netzes eindeutig ist. Der Router, ein RaspberryPi oder genau ein anderes Gerät agieren hierfür als lokaler KeyMaster. Der KeyMaster implementiert den ZoneManagement-Dienst, der das lokale Netz verwaltet und dafür eine mit hoher Wahrscheinlichkeit eindeutige ZoneID generiert. An Nachrichten, welche das lokale Netz verlassen (die also z.B. über einen CommTransceiverHTTP oder ein Gateway geleitet werden), wird diese ZoneID angehängt, um die eindeutige Identifizierung des Schlüssels im Zielnetzwerk zu garantieren (ZoneID:KeyID).

Schlüsselgenerierung

Die Generierung und Verwaltung von Schlüsseln im KeyMaster erfolgt nicht über appicals, sondern z.B. über eine Weboberfläche oder ähnliches. Es gibt also keinen appicals-Dienst, der z.B. neue Schlüssel erstellen oder löschen kann. Damit soll die Ausnutzung von möglichen Sicherheitslücken erschwert werden.

Das Gerät mit dem ZoneManagement-Dienst generiert zufällige Schlüssel. Dafür muss eine kryptographisch sichere Zufallszahlengenerierung zum Einsatz kommen.

Schlüsselverteilung vom KeyMaster zu den Geräten

Schlüssel werden über Ereignisse des ZoneManagement-Dienstes bekannt gemacht. Dieser Dienst erhält immer die reservierte ServiceID 254. Über eine Taste am Gerät oder eine GUI wird die Übertragung der Schlüssel gestartet. Das Gerät mit dem ZoneManagement-Dienst darf Schlüssel nur über schwer belauschbare Schnittstellen übertragen, also z.B. über NFC, CAN, Seriell, Infrarot oder optisch über Hell-Dunkel-Muster. Zusätzlich muss die Akzeptanz solcher Nachrichten am Gerät z.B. über eine mechanische Taste freigegeben werden. Das Gerät speichert die empfangenen Schlüssel, über den KeyManagement-Dienst des Zielgerätes kann der KeyMaster den erfolgreichen Empfang überprüfen.

Schlüssel können auch über Mobilgeräte verteilt werden. So ist es vorstellbar, dass ein Mobiltelefon oder Tablet die Schlüssel vom Router empfängt und anschließend selbst über einen lokalen ZoneManagement-Dienst die Schlüssel an im Haus verteilte Geräte überträgt.

Replay-Attacken

Um Replay-Attacken zu unterbinden, enthält jede verschlüsselte Nachricht das aktuelle Datum und die aktuelle Uhrzeit. Geräte und Klienten dürfen nur auf verschlüsselte Nachrichten reagieren, deren Datum nicht mehr als 10 Sekunden in der Vergangenheit und nicht mehr als 60 Sekunden in der Zukunft liegt. Zusätzlich sind Nachrichten vom gleichen Absender zu ignorieren, deren Datum älter ist als das der zuletzt empfangenen gültigen Nachricht. Da SixML-Dienste keine Aktionen bereitstellen dürfen, welche bei Mehrfachempfang zu Fehlverhalten führen, sind kurzfristige Replay-Attacken durch die genannten Bedingungen ausgeschlossen. Netzteilnehmer ohne eigene Uhr erhalten das aktuelle Datum bei Bedarf über einen ClockService. Die Event-Nachrichten dieses ClockServices müssen verschlüsselt sein, um als Quelle für das Date-Tupel in Frage zu kommen.

Verschlüsselungsschema

Nachrichten werden im Cipher Block Chaining Mode (CBC) verschlüsselt. Der nötige Initalisierungsvektor wird für jede Nachricht aus Zufallszahlen (pseudozufällig genügt) neu erzeugt und innerhalb der Nachricht im entsprechenden Tupel unverschlüsselt mit übertragen.

Struktur verschlüsselter Nachrichten

Es werden nicht alle Bestandteile der Nachricht verschlüsselt. Sowohl der Nachrichtentyp als auch die Routinginformationen (Access- und Response-Entities) werden nicht verschlüsselt, um ein Weiterleiten von Nachrichten durch Gateways zu ermöglichen, welche den Schlüssel der Nachricht nicht kennen. Die Tupel KeyID, ZoneID und InitializationVector müssen ebenfalls unverschlüsselt übertragen werden.

Es liegt im Ermessen des Geräts bzw. Klienten, Discovery-, Description-, Control- bzw. Event-Nachrichten zu verschlüsseln. Ein Gerät, welches sich selbst als sicherheitskritisch einstuft, kann alle Nachrichten verschlüsseln und auch nur auf verschlüsselte Nachrichten reagieren. Ebenso kann ein Klient Anfragen verschlüsseln, wenn er die Privatsphäre innerhalb verbundener Netze wahren möchte. Ein weiteres mögliches Verhalten ist das unverschlüsselte Übertragen von Discovery- und Description-Nachrichten und die Verschlüsselung von Control- und Event-Nachrichten (z.B. für einen Feueralarmsensor). Es ist ebenfalls zulässig, nur solche Description-, Control- und Event-Nachrichten zu verschlüsseln, welche sich auf sicherheitsrelevante Dienste beziehen.

Die Antwort auf verschlüsselte Nachrichten muss stets verschlüsselt sein und den gleichen Schlüssel wie die Anfrage benutzen. Kennt das Gerät den anfragenden Schlüssel nicht, wird die Nachricht still verworfen.

Vorgehensweise Verschlüsselung

Eine verschlüsselte Nachricht wird durch folgenden Algorithmus aus einer unverschlüsselten Nachricht erstellt:

Beispiele

Für die Beispiele werden folgende Schlüssel verwendet.

DES-Key: '12345678' { 49, 50, 51, 52, 53, 54, 55, 56 }
DES-IV: '12345678' { 49, 50, 51, 52, 53, 54, 55, 56 }

Eine verschlüsselte Announcement-Nachricht hat dann den folgenden Aufbau.

		DeviceAnnouncement, KeyID, InitializationVector, Encrypted

12-0-5-1-01-7-8-49-50-51-52-53-54-55-56-3-32-173-106-226-55-232-91-00-57-09-212-28-143-216-88-18-29-106-157-192-233-123-167-10-100-180-238-217-160-140-45-235-112-0

1 Byte                                  12                                      DeviceAnnouncement
  1 Byte                                0                                       No payload
1 Byte                                  5                                       KeyID
  1 Byte                                1                                       
  1 Byte                                01                                      1
1 Byte                                  7                                       InitializationVector
  1 Byte                                8                                       
  8 Bytes                               49-50-51-52-53-54-55-56                 0x31-32-33-34-35-36-37-38
1 Byte                                  3                                       Encrypted
  1 Byte                                32                                      
  32 Bytes                              173-106-226-55-232-91-00-57-09-212-...  0xAD-6A-E2-37-E8-5B-00-39-09-D4-1C-8F-D8-58-12-1D-6A-9D-C0-E9-...
1 Byte                                  0                                       EndOfPacket

Entschlüsselt hat diese Announcement-Nachricht den folgenden Aufbau.

DeviceAnnouncement, KeyID, InitializationVector, SDLVersion, DeviceID, DeviceDescriptionDate, DeviceFlags*, ServiceTypeList*, ServiceExtendedTypeList*, TimeStamp

1 Byte                                  12                                      DeviceAnnouncement
  1 Byte                                0                                       No payload
1 Byte                                  5                                       KeyID
  1 Byte                                1                                       
  1 Byte                                01                                      1
1 Byte                                  7                                       InitializationVector
  1 Byte                                8                                       
  8 Bytes                               49-50-51-52-53-54-55-56                 0x31-32-33-34-35-36-37-38
1 Byte                                  2                                       SDLVersion
  1 Byte                                2                                       
  2 Bytes                               01-00                                   1.0
1 Byte                                  42                                      DeviceID
  1 Byte                                1                                       
  1 Byte                                20                                      0x14 (20)
1 Byte                                  41                                      DeviceDescriptionDate
  1 Byte                                5                                       
  5 Bytes                               07-221-07-09-00                         9.7.2013
1 Byte                                  45                                      DeviceFlags
  1 Byte                                2                                       
  2 Bytes                               00-04                                   DirectIDs; EncryptionSupport; 
1 Byte                                  46                                      ServiceTypeList
  1 Byte                                4                                       
  4 Bytes                               50-03-02-20                             DigitalOutput;Persistence;Attribute;ServiceManagement
1 Byte                                  4                                       TimeStamp
  1 Byte                                4                                       
  4 Bytes                               81-219-215-121                          09.07.2013 11:27:21
1 Byte                                  0                                       EndOfPacket