Die Umsetzung kann über folgende Möglichkeiten realisiert werden:

1. Software Verschlüsselung über die mysensors lib
2. Hardware Verschlüsselung mit Hardware Atmel ATSHA204

Bei dem Konzept geht es prinzipiell darum, die Herkunft der Nachricht zu verifizieren und zugleich sicherzustellen, dass der Inhalt nicht verfälscht wurde. Es sollen also Authentizität und Integrität sichergestellt sein, Vertraulichkeit spielt erstmal keine Rolle. Dies wird durch eine in die Nachricht eingefügte Signatur erreicht. Diese Signatur ist bei jeder übermittelten Nachricht anders, auch wenn der übermittelte Befehl immer der gleiche ist.
Um dies zu erreichen, könnte man einen Zähler in die Signatur einzubauen. Diese Vorgehensweise ist aber nicht sicher da vorhersagbar. Um diese Vorhersagbarkeit zu verhindern, kommt eine zufällige Komponente ins Spiel. Dazu wird eine einmalige Zufallszahl erzeugt die Sender und Empfänger austauschen. Durch belauschen dieses Austausches könnte so natürlich die Übertragung wieder manipuliert werden. Deshalb haben Sender und Empfänger einen sogenannten pre-shared key den nur diese beiden kennen und der niemals übertragen wird. Nun gibt es wieder die Möglichkeit, den Empfänger daran zu hindern, die verschlüsselte Nachricht zu empfangen und eine gefälschte Nachricht mit der „richtigen“ Signatur zu übertragen. Deshalb startet am Empfänger ein Timer sobald eine Zufallszahl vom Sender angefordert wird. Der Empfänger weiß, dass eine Nachricht kommt und nur wenn diese innerhalb des Zeitfensters ankommt wird sie auch akzeptiert. Ansonsten wird sie verworfen. Diese Vorgehensweise ist erforderlich um zu verhindern, dass jemand Befehle in der Homeautomation manipuliert.
Wichtig: Bei der Nutzung der Bibliothek von mysensors.org werden die übertragenen Daten nicht verschlüsselt! Der Schwerpunkt liegt klar in der Vermeidung von Manipulation der übertragenen Daten und Befehle! Ein Mitlesen der übertragenen Daten (z.B. Temperatur) ist also theoretisch jederzeit möglich.

Zum Nachrichten signieren kommt eine starke Hash-Funktion in Verbindung mit einem HMAC-Code zum Einsatz. Diese Kombination bietet einen hohen Schutz.Die Umsetzung erfolgt entweder mit separater Hardware oder auch rein Software basiert. Die Hardwarelösung ist dabei zu bevorzugen da sie mehr Sicherheit bietet. Hierbei werden die Keys und Daten optimal geschützt, die erforderlich sind um die Signatur zu berechnen.
Als Hardware kommt ein Atmel ATSHA204A Chip zum Einsatz. HMAC und SHA256 Hashing können mit diesem Chip umgesetzt werden. Zusätzlich bietet die Bibliothek eine Umsetzung dieser Funktionalität in Software. Mit den Nachteilen, dass dies Speicher und Performance fordert sowie auf Kosten der Sicherheit geht. Der HMAC-Schlüssel ist in der Software gespeichert und mittels Memory Dump kann dieser ausgelesen werden.

Als erstes muss das Signieren aktiviert werden. Dies geschieht in der MyConfig.h der MySensors Bibliothek. Dazu muss MY_SIGNING_FEATURE aktiviert werden, also die Kommentare am Anfang der Zeile entfernt werden.
Dann wählt man das zu verwendende Verfahren, also Hardwarelösung oder per Software. Dazu dient der Verweis signer im eigenen Sketch, welcher dann als drittes Argument übergeben wird (Beispiele zeigen echtes ATSHA ohne Whitelisting):

#include <MySigningAtsha204.h> bzw. #include <MySigningAtsha204Soft.h>

Die komplette Initialisierung im Sketch sieht so aus für die Hardwarelösung:

#include <MySigningAtsha204.h>
MyTransportNRF24 radio;  //NRFRF24L01 radio driver
MyHwATMega328 hw; //Select AtMega328 hardware profile
MySigningAtsha204 signer; //Select HW ATSHA signing backend
MySensor gw(radio, hw, signer);

bzw. für die Software Variante:

#include <MySigningAtsha204Soft.h>
 
MyTransportNRF24 radio;  // NRFRF24L01 radio driver
MyHwATMega328 hw; // Select AtMega328 hardware profile
 
// ACHTUNG! Zur Sicherheit unbedingt den Wert von soft_serial auf einen willkürlichen Wert ändern!
uint8_t soft_serial[SHA204_SERIAL_SZ] = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09};
MySigningAtsha204Soft signer(true, 0, NULL, soft_serial);  // Select SW ATSHA signing backend
 
MySensor gw(radio, hw, signer);

Beide Varianten können in einem Netzwerk gemischt verwendet werden.

Im zweiten Schritt erfolgt die Konfiguration des gewählten Backends (in der MyConfig.h).
Bei der Hardware Variante muss der PIN in der Variable MY_ATSHA204_PIN angegeben werden, an dem der Signatur-Chip angeschlossen ist. Diese Konfiguration erfolgt ebenfalls in der Myconfig.h. Der default PIN ist A3.
Für die Software Variante muss ebenfalls ein PIN angegeben werden. An diesen PIN darf nichts angeschlossen sein und es muss ein Analog PIN sein. Der undefinierte Zustand wird vom Zufallsgenerator zur Erzeugung der Zufallszahlen genutzt und verhindert dass die Signatur kompromittiert wird! Der default PIN ist A7 und wird in MY_RANDOMSEED_PIN angegeben.

Im dritten Schritt erfolgt die Konfiguration des verwendeten Backends. Kommt die Software-Variante zum Einsatz muss ein 32bit breiter Schlüssel in der MyConfig.h gewählt werden. Empfohlen werden zufällig gewählte Zahlenkombinationen, es kann aber auch eine Zeichenfolge sein. Der Schlüssel ist im Sketch hinterlegt und wird bei der Initialisierung des MySigningAtsha204Soft-Objekts ausgelesen.
Kommt die Hardware zum Einsatz muss diese vor dem ersten Einsatz personalisiert werden. Dies kann ein komplizierter und umständlicher Prozess sein! Die Konfiguration, welche auf den Chip geschrieben wird, ist im Fehlerfall nicht mehr änderbar! Um diesen Prozess zu vereinfachen gibt es einen Sketch in libraries/MySensors/examples/Sha204Personalizer/sha204_personalizer.ino.
Der Vorgang des Personalisierens umfasst:

• Schreiben der Konfiguration und Sperren des Chips
• Optional erzeugen und schreiben eines HMAC Schlüssels
• Optional sperren des Datenbereichs (zur Absicherung gegen Auslesen des PSK)

Als erstes sollte man den Sketch zum Testen ohne Anpassungen ausführen, am besten auf einem Board mit aktivierten Debug Ausgaben über die serielle Konsole. Ist hier alles in Ordnung muss man sich für die Art der Personalisierung entscheiden. Folgende Optionen gibt es: Zum Sperren der Chip Konfiguration wird im Sketch LOCK_CONFIGURATION aktiviert. Die dadurch geschriebenen Standard Werte sind für unsere Zwecke passend. Das aktiviert auch den Zufallszahlengenerator um einen PSK automatisch zu erzeugen falls dies benötigt wird.
Als nächstes legt man fest ob man einen vorhandenen Schlüssel benutzt oder ein neuer erzeugt werden soll. Ein vorhandener wird über die Variable USER_KEY_DATA angegeben. Ansonsten wird über den RNG ein neuer Schlüssel erzeugt und auf der seriellen Konsole ausgegeben. Dieser Schlüssel wird dann für alle Boards im Netzwerk verwendet.
Der Schlüssel wird solange auf den Chip geschrieben bis SKIP_KEY_STORAGE aktiviert wird. Solange der Datenbereich nicht gesperrt ist kann jederzeit ein neuer Schlüssel geschrieben werden. Atmel empfiehlt den Datenbereich zu sperren um ein Maximum an Sicherheit zu gewinnen. Angeblich ist der PSK aber auch dann nicht auslesbar wenn der Datenbereich nicht gesperrt ist. Das Sperren ist also optional und hat halt den Nachteil, dass eine einmalige Sperre den Chip sperrt für ein nachträgliches Ändern des PSK!
Ist keine serielle Ausgabe vorhanden kann SKIP_UART_CONFIRMATION gesetzt werden wobei dann natürlich USER_KEY_DATA vorhanden sein muss. Ist die Konsolenausgabe vorhanden muss das Sperren des Datenbereichs vom Benutzer bestätigt werden. Wie gesagt, das Sperren des Datenbereichs ist nicht widerrufbar!
Vorgehensweise nochmal in Stichpunkten:
Konfiguration des Sketch (Erstes Device - noch kein PSK vorhanden):

• Enable LOCK_CONFIGURATION
• Disable LOCK_DATA
• Enable SKIP_KEY_STORAGE
• Disable SKIP_UART_CONFIGURATION
• Disable USER_KEY_DATA

Den Sketch nun ausführen und den angezeigten Schlüssel in der seriellen Konsole gut aufbewahren. Er wird auch für die weiteren Nodes benötigt. Nun wird der Sketch umkonfiguriert:

• Enable LOCK_CONFIGURATION
• FALLS GEWÜNSCHT: Enable LOCK_DATA → Vorsicht!!
• Disable SKIP_KEY_STORAGE
• Enable SKIP_UART_CONFIGURATION
• Enable USER_KEY_DATA (den PSK in der Variable user_key_data hinterlegen)

Den so konfigurierten Sketch auf allen Nodes ausführen, mehr ist dann nicht mehr zu tun um das Signieren der Nachrichten auf allen Devices im Netzwerk zu aktivieren.

Von allen Devices im Netzwerk kann die Seriennummer der Chips gespeichert werden. Geht so ein vertrauliches Device verloren kann es aus der Liste gelöscht werden und stellt somit keine Gefahr mehr dar. Die Seriennummer wird beim Personalisieren in der Konsole angezeigt.
In einem MySensors Netzwerk fordert ein Node das Signieren von Nachrichten beim Gateway an. Durch Nutzung von MySigningAtsha204 und MySigningAtsha204Soft wird dieses Anfordern automatisch aktiviert. Dieses Standardverhalten kann aber auch deaktiviert werden um das Signieren von Nachrichten auszuschaltten. Dies kann für ein Node erforderlich sein das keine signierten Nachrichten erfordert aber die Möglichkeit haben soll, die Nachrichten wie ein Gateway zu verifizieren.
Beispiel für ein Node das Hardware-ATSHA nutzt und Signieren erfordert:

#include <MySigningAtsha204.h>
MyTransportNRF24 radio;  // NRFRF24L01 radio driver
MyHwATMega328 hw; // Select AtMega328 hardware profile
MySigningAtsha204 signer; // Select ATSHA204A physical signing circuit
MySensor gw(radio, hw, signer); 

Beispiel für ein Gateway mit der optionalen Nutzung von Signieren der Kommunikation mit Nodes:

#include <MySigningAtsha204Soft.h>
MyTransportNRF24 radio;  // NRFRF24L01 radio driver
MyHwATMega328 hw; // Select AtMega328 hardware profile
uint8_t soft_serial[SHA204_SERIAL_SZ] = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09};
MySigningAtsha204Soft signer(false, 0, NULL, soft_serial);  // Select ATSHA204A software signing backend
MySensor gw(radio, hw, signer); 

Wenn ein Node Signieren erfordert verwirft er alle unsignierten Nachrichten an ihn, genauso verfährt das Gateway. Der Unterschied ist, dass das Gateway nur von ihm bekannte Nodes signierte Nachrichten erfordert welche wiederum selber signierte Nachrichten erwarten. (?)
Ein Node kann einem anderen mitteilen, dass er nur signierte Nachrichten erwartet. Dazu überträgt eine interne Nachricht des Typs I_REQUEST_SIGNING welche TRUE als boolean für payload übermittelt. Alle Netzwerkknoten speichern in einer Tabelle dauerhaft im EEPROM welche Knoten Signieren erfordern und welche nicht.

Der vorstehende Inhalt stammt aus einem Artikel bei http://www.mysensors.org und wurde von mir aus dem Englischen übersetzt. Deshalb Vorsicht, ich übernehme keine Garantie für eine korrekte Übersetzung! Das ganze findet sich hier im Original.