Benutzer-Werkzeuge

Webseiten-Werkzeuge


signieren2.0


Übertragungen signieren

Mit der neuen Version der MySensors Bibliothek 2.0 wurden einige wesentlichen Änderungen eingeführt. Die Vorgehensweise zur Nutzung des Signierens hat sich geändert und wird im folgenden beschrieben. Der (englische) Originaltext ist hier zu finden.

Die Vorgehensweise zur Inbetriebnahme eines Funknetzwerkes mit (Hardware-)Signatur gliedert sich in folgende Schritte:

  1. Schlüssel erzeugen und Gateway damit konfigurieren
  2. Weitere Netzwerkknoten mit dem erzeugten Schlüssel konfigurieren
  3. Anwendungen auf Gateway und Knoten aufspielen

Anwendung

Das Signieren ist standardmäßig deaktiviert. Zum aktivieren wird das gewünschte Backend (Software oder Hardware) gewählt und entweder global in der MyConfig.h angegeben oder im eigenen Sketch. Dazu wird für das Hardware Backend MY_SIGNING_ATSHA204 angegeben oder MY_SIGNING_SOFT für die Software Variante.

Also erstes wird also das gewünschte Backend angegeben:

//#define MY_SIGNING_SOFT
#define MY_SIGNING_ATSHA204
#include <MySensor.h>
...

Die Angabe des Backends muss vor dem include der MySensor.h erfolgen. In einem Netzwerk können die Hard- und Software Variante gemischt zum Einsatz kommen.
Über das Flag MY_SIGNING_REQUEST_SIGNATURES fordert eine Node die signierte Kommunikation mit dem Gateway an. Wenn dieses Flag auf dem Gateway gesetzt ist, kommuniziert es mit allen Nodes, die Signieren erfordern, nur noch über signierte Nachrichten. Ein Node kann drei verschiedene Betriebsmodi hinsichtlich Signieren haben:

  1. Kein Signieren erforderlich (kein Backend angegeben)
  2. Signieren wird unterstützt, es werden aber auch unsignierte Nachrichten angenommen
  3. Signieren wird unterstützt und nur signierte Nachrichten werden verarbeitet

Als nächstes muss das gewählte Backend konfiguriert werden. Für das Hardware Backend muss der PIN angegeben werden, an dem der Chip angeschlossen ist. In der MyConfig.h sind dafür ein Standard (PIN 3) eingetragen, dieser kann aber im Sketch überschrieben werden:

#define MY_SIGNING_ATSHA204
#define MY_SIGNING_ATSHA204_PIN 4
#define MY_SIGNING_REQUEST_SIGNATURES
#include <MySensor.h>

Beim Software Backend muss ein analoger PIN verwendet werden, der völlig unbeschaltet ist. Nur so funktioniert der Zufallszahlen Generator bzw. werden auch tatsächlich zufällige Werte erzeugt. Auch hier gibt es einen Standard PIN (7), dieser kann mit Setzen von MY_SIGNING_SOFT_RANDOMSEED_PIN im Sketch verändert werden.

#define MY_SIGNING_SOFT
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
#define MY_SIGNING_REQUEST_SIGNATURES
#include <MySensor.h>

Für beide Backends ist es erforderlich eine Personalisierung durchzuführen. Diese wird im folgenden beschreiben. Ein Beispiel Sketch für die Verwendung eines Nodes der signieren erfordert ist zu finden in SecureActuator.ino.

Vor der ersten Verwendung eines Chips zum Signieren muss dieser personalisiert werden. Dies ist kein einfacher Vorgang und etwas umständlich sowie nicht ungefährlich. Ein falsch geschriebene Konfiguration kann den Chip unbrauchbar machen. Zur Vereinfachung dieses Prozesses gibt es einen Hilfe-Sketch: SecurityPersonalizer.ino. Die zum Signieren relevanten Werte werden in den Chip geschrieben (bei der Software Variante werden diese Werte im EEPROM des Prozessors gespeichert).

Personalisierung

Die einzelnen Prozess-Schritte:

  • Konfiguration in den Chip schreiben und Konfiguration sperren
  • (Optional) Erzeugen und zwangsläufiges schreiben eines HMAC Schlüssels
  • (Optional) Dauerhaftes Sperren des Chips (kein Nachträgliches Ändern mehr möglich!)

Vor ersten Anpassungen der Konfiguration wird der Sketch direkt ausgeführt. Das verwendete Device muss eine serielle Konsole zur Ausgabe haben. Ist dieser Test erfolgreich geht es weiter. Die Art der Personalisierung muss festgelegt werden. Default-PIN an dem der SHA204 angeschlossen wird: A3. Dies kann über Angabe von MY_SIGNING_ATSHA204_PIN geändert werden.
Als erstes wird „LOCK_CONFIGURATION“ aktivert um die Konfiguration des ATSHA204 zu sperren. Die restlichen Einstellungen im Sketch lassen wir auf Standard, diese sind für unsere Zwecke passend. Der Zufallsgenerator wird so ebenfalls aktiviert und ermöglicht dem Sketch einen PSK zu generieren falls erforderlich. Nun kann der Sketch übersetzt und auf den Arduino geschrieben werden. Als nächstes wird über „USER_KEY“ festgelegt ob ein eigener (bereits in Verwendung befindlicher) Schlüssel genutzt wird und falls ja, wird dieser aus „user_key_data“ gelesen und verwendet.
Falls nicht wird über den RNG (Zufallszahlengenerator) ein neuer PSK generiert. Der Schlüssel wird in der seriellen Konsole angezeigt wenn er generiert ist. Diesen Key gut aufheben, er wird dann für die weiteren Devices im Drahtlosnetzwerk benötigt. Der Key wird in den Chip geschrieben außer „SKIP_KEY_STORAGE“ ist gesetzt. Solange die „Data Zone“ des Chips nicht gesperrt ist, kann immer wieder ein neuer Key geschrieben werden. Atmel gibt an, dass der Key nicht ausgelesen werden kann auch wenn dieser Bereich nicht gesperrt ist. Zur Erhöhung der Sicherheit kann die „Data Zone“ gesperrt werden. Für Devices ohne serielle Konsole kann „SKIP_UART_CONFIRMATION“ aktiviert werden um Rückfragen beim Programmieren zu vermeiden. Dies ist mit Vorsicht zu verwenden da auch beim Sperren der Konfiguration keine Möglichkeit besteht, den Vorgang abzubrechen! Sinnvolle Verwendung dieser Option ist um schnell eine größere Anzahl von Devices zu Personalisieren.

Zusammenfassung

Programmieren des (ersten) Master Devices (es ist noch kein PSK vorhanden!)

  • „LOCK_CONFIGURATION“ aktivieren
  • „LOCK_DATA“ deaktivieren
  • „SKIP_KEY_STORAGE“ aktivieren
  • „SKIP_UART_CONFIRMATION“ deaktivieren
  • „USER_KEY“ deaktivieren

Sketch ausführen und den in der seriellen Konsole angezeigten PSK gut aufbewahren.

Programmieren weiterer Devices

  • „LOCK_CONFIGURATION“ aktivieren
  • „LOCK_DATA“ aktvieren → optional! (PSK kann dann nicht mehr geändert werden!)
  • „SKIP_KEY_STORAGE“ deaktivieren
  • „SKIP_UART_CONFIRMATION“ aktivieren
  • „USER_KEY“ aktivieren
  • Den im ersten Schritt erzeugten PSK in „user_key_data“ ablegen

Den Sketch dann auf allen Devices ausführen die zum Drahtlosnetzwerk gehören sollen.

Hinweise

Der Sketch generiert außerdem einen AES-Schlüssel welcher zur Verschlüsselung des Funkverkehrs genutzt werden kann.

Grundsätzlich ist damit die Personalisierung abgeschlossen und die Geräte sind einsatzbereit um mit signierten Nachrichten umgehen zu können. Ein Netzwerkknoten, der eine Signatur erfordert, wird jede unsignierte Nachricht an ihn verwerfen. Das gilt auch für das Gateway. Der Unterschied beim Gateway ist, dass es nur signierte Nachrichten von ihm bekannten Netzwerkknoten verlangt welche wiederum signieren erfordern.
Ein Knoten kann einen anderen darüber informieren, dass er signierte Nachrichten erfordert. Dies wird durch Aktivieren von „I_SIGNING_PRESENTATION“ und das Bereitstellen von Flags wie payload getan. Dadurch gibt der Sender bekannt, dass er signierte Nachrichten Vorrang haben.
Alle Knoten und Gateways speichern im EEPROM eine Tabelle mit den Signatur Eigenschaften aller Netzwerkknoten. Ändert sich die Signaturvorgabe eines Knotens (benötigt künftig keine Signatur mehr) durch Neuprogrammieren, teilt der Knoten dies dem Gatway bei der ersten Präsenzmeldung mit.

Whitelisting

Sollte ein Device verloren gehen oder gestohlen werden, kann mit Hilfe dessen jederzeit die Kommunikation zum Drahtlosnetzwerk aufgebaut werden. Nachrichten können gelesen und geschickt werden. Eine Möglichkeit ist nun, in allen Devices den PSK zu tauschen. Wenn im Verschlüsselungs-Chip ATSHA die Data region gelockt wurde, ist das allerdings auch nicht mehr möglich! Ein weitere bzw. bessere Variante ist es, eine Liste der vertrauten Netzwerkknoten zu führen, sogenanntes Whitelisting.
Über das Whitelisting ist es möglich, so eine Liste mit vertrauten Netzwerkknoten zu führen. Sind Signieren und Whitelisting aktiviert, können nur Devices miteinander kommunizieren welche in der Whitelist stehen. So ist es möglich, bei Verlust oder Diebstahl ein Device aus der Liste zu löschen und so Missbrauch zu verhindern. In dieser Liste stehen die Seriennummern des Verschlüsselungs-Chips welche beim Personalisieren in der Konsole angezeigt werden (bei Software Verschlüsselung wird diese beim personalisieren generiert und angezeigt). Die Seriennummer wird dabei nie unverschlüsselt im Netzwerk übertragen. Sie wird in die Signatur eingebettet welche vom Sender kommt. Der Empfänger kann dann mithilfe des PSK diese Nummer extrahieren und in der Whitelist nachschauen, ob es sich um eine gültiges Device handelt. Aktiviert wird die Whitelist über MY_SIGNING_NODE_WHITELISTING. Die Parameter geben dann die gültigen Devices an. Beispiel:

#define MY_SIGNING_ATSHA204
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0x09,0x08,0x07,0x06,0x05,0x04,0x03,0x02,0x01}},\\
{.nodeId = 2,.serial = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09}}}
#include <MySensor.h>

Dieses Beispiel zeigt zwei eingetragene Knoten mit ihren Seriennummern. Beim Sender ist nichts weiter zu konfigurieren, Voraussetzung ist allerdings immer dass das Signieren aktiviert sein muss.

signieren2.0.txt · Zuletzt geändert: 2016/07/31 19:19 von admin