Design-Praxis / Embedded Software
OTA-Schnittstellen für µC-Apps
Fortsetzung des Artikels von Teil 4
Funktionale Sicherheit und Kommunikation
Entwicklungskompromiss: Software vs. Protokoll
Die OTA-Update-Lösung muss auch die Themen Security und Kommunikation adressieren. Viele Systeme, wie etwa das in (Bild 1, oben), enthalten ein Kommunikationsprotokoll in Hard- und Software für normales (nicht-OTA-Update-bezogen) Systemverhalten. Beispielsweise dem Austausch von Sensordaten. Damit besteht bereits eine drahtlose Kommunikationmethode (möglicherweise sicher) zwischen Server und Client. Kommunikationsprotokolle eines Embedded-Systems sind zum Beispiel Bluetooth Low Energy (BLE) oder 6LoWPAN. Manchmal unterstützen diese Protokolle Security und Datenaustausch, von der OTA-Update-Software während des Aktualisierungsprozesses.
Der Umfang der Kommunikationsfunktionalität, welche in die OTA-Update-Software implementiert werden muss, richtet sich letztendlich nach der Abstraktion des vorhandenen Kommunikationsprotokolls. Das vorhandene Kommunikationsprotokoll verfügt über Fähigkeiten zum Senden und Empfangen von Dateien zwischen Server und Client, welche die OTA-Update-Software für den Download-Vorgang auf einfache Weise nutzen kann.
Ist das Kommunikationsprotokoll jedoch primitiver und verfügt lediglich über Fähigkeiten zum Senden von Rohdaten, kann es erforderlich sein, dass die OTA-Update-Software die Übertragung aufteilt und Metadaten zusammen mit dem neuen Applikationsprogramm liefert. Dies gilt auch für die Security-Herausforderungen. Die OTA-Update-Software hat dann die Aufgabe, die über die Funkschnittstelle gesendeten Bytes für Vertraulichkeit zu entschlüsseln, falls das Kommunikationsprotokoll dies nicht unterstützt.
Schlussendlich richtet sich die Implementierung von Fähigkeiten wie individuelle Paketstruktur (Custom Packet Structure), Server/Client-Synchronisierung, Verschlüsselung und Schlüsslaustausch (Key Exchange) in die OTA-Update-Software nach dem, was das Kommunikationsprotokoll des Systems bietet sowie nach den Security- und Robustheits-Anforderungen.
Im nächsten Abschnitt wird eine komplette Security-Lösung vorgeschlagen,
die alle zuvor erwähnten Herausforderungen bewältigt und gezeigt, wie sich das Potenzial einer Hardware-Kryptografie-Peripherie eines Mikrocontrollers in dieser Lösung nutzen lässt.
Security-Herausforderungen bewältigen
Die angestrebte Security-Lösung muss die übertragene Applikation vertraulich behandeln, eventuelle Beschädigungen feststellen und überprüfen, dass die Quelle vertrauenswürdig ist, und keine böswillige Drittpartei. Diese Herausforderungen lassen sich mit kryptografischen Algorithmen meistern.
Speziell zwei kryptografischen Operationen, bekannt als Verschlüsselung (Encryption) und Hashing, können in der Security-Lösung verwendet werden. Die Verschlüsselung nutzt einen gemeinsamen Schlüssel (Passwort) zwischen Client und Server, um die drahtlos übertragenen Daten zu verschleiern. Ein spezieller Verschlüsselungstyp, welcher vom Crypto-Hardware-Beschleuniger des Mikrocontrollers unterstützt wird, heißt AES-128 oder AES-256, je nach Schlüsselgröße.
Zusammen mit den verschlüsselten Daten kann der Server eine Übersicht (Digest) senden, um die Unversehrtheit der Daten sicherzustellen. Die Übersicht wird durch Hashing des Datenpakets generiert – eine nicht umkehrbare mathematische Funktion, die einzigartigen Code erzeugt.
Falls ein Teil der Nachricht oder der Übersicht nach der Erzeugung vom Server modifiziert wird, etwa ein während der drahtlosen Kommunikation verändertes Bit, wird der Client die Modifikation bemerken, wenn er die gleiche Hash-Funktion am Datenpaket durchführt und mit der Übersicht vergleicht.
Jobangebote+ passend zum Thema
Ein spezifischer Hashing-Typ, den der Crypto-Hardware-Beschleuniger des Mikrocontrollers eventuell unterstützen kann, ist SHA-256. Bild 6 zeigt ein Blockdiagramm einer Crypto-Hardware-Peripherie im Mikrocontroller, bei der sich die OTA-Update-Software im Cortex-M4-Applikationslayer befindet.
Bild 6 zeigt auch die Unterstützung für geschützte Schlüsselspeicherung in der Peripherie. Diese kann in der OTA-Update-Software-Lösung genutzt werden, um die Schlüssel des Client sicher zu speichern.
Eine gängige Technik, mit der sich die abschließende Herausforderung der Authentifizierung meistern lässt, besteht im Einsatz einer asymmetrischen Verschlüsselung. Für diese Operation erzeugt der Server ein öffentliches/privates Schlüsselpaar. Der private Schlüssel ist nur dem Server bekannt, während nur der Client den öffentlichen Schlüssel kennt.
Mit dem privaten Schlüssel kann der Server eine Signatur eines bestimmten Datenblocks erzeugen – wie die Übersicht des Datenpakets, welches über die Luftschnittstelle versandt wird. Die Signatur wird zum Client übertragen und kann von diesem mit dem öffentlichen Schlüssel überprüft werden.
Damit kann der Client bestätigen, dass die Nachricht vom Server stammt und nicht von einer unseriösen Drittpartei. Den Ablauf zeigt Bild 7. Die durchgezogenen Linien repräsentieren Funktion Eingang/Ausgang und die gestrichelten Verbindungen zeigen die drahtlos übertragene Information.
Die meisten Mikrocontroller enthalten keine Hardware-Beschleuniger für diese asymmetrischen Verschlüsselungsoperationen. Allerdings können solche Funktionen mit Software-Bibliotheken, beispielsweise Micro-ECC, implementiert werden, die speziell auf Devices mit beschränkten Ressourcen abzielen. Die Bibliothek benötigt eine vom Anwender definierte Funktion zum Erzeugen von Zufallszahlen, welche sich mit der echten Zufallszahlengenerator-Hardware-Peripherie im Mikrocontroller implementieren lässt.
Die asymmetrischen Verschlüsselungsoperationen lösen zwar die Vertrauensfragen während der OTA-Aktualisierung, sind jedoch kostspielig hinsichtlich Verarbeitungszeit und verlangen, dass mit den Daten eine Signatur übertragen wird, was die Paketgröße erhöht. Man könnte diese Prüfung stets am Ende des Downloads mithilfe einer Übersicht des endgültigen Pakets oder der Übersicht der gesamten neuen Software-Applikation durchführen, doch könnten Dritte nicht vertrauenswürdige Software auf den Client laden, was nicht ideal ist. Idealerweise ist zu überprüfen, dass jedes erhaltene Datenpaket von einem vertrauenswürdigen Server stammt und zwar ohne den Overhead einer Signatur. Dies lässt sich mit einer Hash-Kette (Hash Chain) erreichen.
Eine Hash-Kette bindet die oben erläuterten Kryptografiekonzepte in eine Serie von Paketen ein, um sie mathematisch zusammenzubinden.
Wie Bild 8 zeigt, enthält das erste Paket (Nummer 0) die Übersicht des nächsten Pakets. Statt der tatsächlichen Software-Applikationsdaten stellen die Nutzdaten des ersten Pakets die Signatur. Das zweite Paket (Nummer 1) enthält einen Teil des Programms und die Übersicht des dritten Pakets (Nummer 2).
Der Client verifiziert die Signatur im ersten Paket und speichert die Übersicht, H0, zur späteren Nutzung zwischen. Sobald das zweite Paket eintrifft, zerlegt der Client die Nutzdaten und vergleicht sie mit H0. Bei Übereinstimmung kann der Client sicher sein, dass das nachfolgende Paket von einem vertrauenswürdigen Server stammt und zwar ohne zusätzliche Signaturprüfung.
Die aufwändige Aufgabe der Erzeugung dieser Kette bleibt dem Server überlassen und der Client muss beim Eintreffen jedes Datenpakets einfach zwischenspeichern und zerlegen (Cache and Hash), um sicherzustellen, dass Pakete unbeschädigt, integer und authentifiziert eintreffen.
- OTA-Schnittstellen für µC-Apps
- Das Wesen einer Software-Applikation
- Der Second-Stage Bootloader (SSBL)
- Entwicklungskompromiss: Die Rolle des SSBL
- Funktionale Sicherheit und Kommunikation
- Versuchsaufbau
- Ergebnisse
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Airbus Cyber Security
»Cyber-Security wird zunehmend als Enabler für das IoT gesehen«
Edge Computing
Rechnen, wo Rechenleistung gebraucht wird
Mobilfunkmodul mit µC
LTE-Modem und µC als System-in-Package
Mess- und Prüftechnik / IoT-Sensorknoten
Das Zephyr von vorne aufgezäumt
Systemdesign / Safety&Security
Updateszenarien für und mit Linux
