E



OTA Anforderungen

Ein Update ist notwendig, wenn entweder im zugrunde liegenden Betriebssystem ein Fehler oder eine Angriffsmöglichkeit gefunden wurde, wenn eine neue Version eingespielt werden muss oder die Applikationen, die auf dem Gerät aktiv sind, Updates benötigen. Ob ein Update durchzuführen ist, kann das Endgerät durch eine Anfrage beim Updateserver erfahren, durch eine Nachricht vom Server (beispielsweise bei einem kritischen Update), durch eine Benutzeraktion oder durch irgendeine andere Aktion.

Ein gutes Updatesystem kann diese Funktionalität zur Verfügung stellen und damit dazu beitragen, viel Geld zu sparen.

Flexibilität

Ein Updatesystem sollte alle Komponenten eines Embedded Systems austauschen können. Dazu zählen der Bootloader, Kernel, rootfs, binäre Dateien für Flashkomponenten, Software für weitere CPUs, sowohl bei heterogenen Systemen als auch bei einer kaskadieren-den Struktur (Gateway), und die Anwendung(en) selber. Und es sollte aus einem Update-Container nur die Komponenten entnehmen, die für die eigene Hardware benötigt wer-den. Das System sollte (mit minimalen Anpassungen) an unterschiedliche CPU-Architekturen, Speichermedien, Speicherlayouts (UBIFS, eMMC, HDDs, ...) usw. anpassbar sein.

Ob die Applikation Teil des OS Image ist oder eine eigenständige Partition und damit un-abhängig updatebar ist, sollte die Entscheidung des Nutzers sein und nicht vom Update-system festgelegt werden. Wir haben in unserem Standardlayout (siehe Bild 1) eine eigene Partition hierfür vorgesehen.

Es sollte ferner unterschiedlichste Medien für die Datenübertragung nutzen können – sei es ein USB-Stick, eine SDcard oder das Internet in Form eines Kabels, WiFi oder LTE / 5G. Und es sollte den Fall unterstützen, dass das Embedded Gerät nicht ständig erreichbar ist und es daher identische Geräte mit unterschiedlichen Software Ständen geben kann.

Ein Update muss ohne einen Eingriff eines Bedieners auskommen, auch im Falle, dass ein Update File (Container) nicht vollständig oder fehlerhaft übertragen wurde oder der Spei-cher nicht ausreichend ist. Kann das Update nicht gestartet werden, muss ein Zurückge-hen auf ein bekanntes, funktionales Image (roll-back) automatisch durchgeführt werden.

Um all diese Anforderungen erfüllen zu können muss ein Update atomar sein, d.h. entweder ganz oder gar nicht.

Ein Update darf das System nicht beeinflussen, also beispielsweise eine Anwendung stoppen oder ihre Ausführung verzögern. Um dies zu ermöglichen, haben sich zwei Ansätze herausgebildet: A/B Update (symmetrisches Update) oder Android Update, auch asym-metrisches Update genannt, mit einer „normalen" und einer Update Instanz des Systems.

Update Ansätze

A/B Update – hier wird das Update in die nicht aktive Partition geschrieben und anschlie-ßend der Bootloader so geändert, dass er auf diese Partition zeigt. Diese neu geschriebene Partition wird beim nächsten Bootvorgang gestartet – und damit ist ersichtlich, dass dieser Ansatz einen Neustart benötigt, damit das Update wirksam werden kann. Als Nachteil kann man hier möglicherweise den großen Speicherbedarf sehen, da ja ständig zwei komplette Abbilder vorhanden sein müssen. Der große Vorteil ist, dass dadurch auch immer ein lauffähiges Abbild vorhanden ist.

 

Bild 3: Default memory layout at symmetric update

 

 

 

 

 

 

 

 

 

Asymmetrisches Update mit einer Produktiv- und einer kleinen Update-Partition – hier ist der Speicherbedarf geringer, jedoch ist die Auszeit deutlich größer, da während des eigentlichen Update Vorgangs das Produktivsystem inaktiv ist.

 

Bild 4: Standardlayout asymmetrisches Up-date

 

 

 

 

 

 

 

 

 

Delta Update

Unabhängig davon, ob symmetrisch oder asymmetrisch, sollte es möglich sein, die zu übertragene Datenmenge zu begrenzen. Gerade wenn die Anbindung über Bandbreiten begrenzte Kanäle erfolgen muss. Delta-Updates (differenzielle) limitieren die Größe der zu übertragenden Daten. Und auch den auf dem Gerät benötigten Speicherplatz für das Update.

 

 

 

 

 

 

Picture 5a: Delta Update                                                      Picture 3b: Delta Update principle

Bandbreite optimiert

Deduplizierung verringert die Datenmenge noch weiter. Und die Verpackung in gleich große Chunks optimiert die Auslastung der Netze der CDNs (content delivery provider).

Resultat:
Minimaler Datentransfer, minimaler Zeitbedarf, minimale Kosten

 

Roll-Back

In beiden Fällen wird der Erfolg des Updates durch einen Watchdog überprüft. Startet das System nach einem Update nicht, so wird nach einer einstellbaren Anzahl von Versuchen beim A/B Update auf die letzte lauffähige Version gewechselt. Bei einem asymmetrischen Update kann das Update-System neu gestartet werden, ggfs. mit einer entsprechenden Meldung an den Nutzer.

On-device check

Bevor ein Update File komplett geladen wird, sollte überprüfbar sein, ob es zur Hardware passt und ob es eine neue, aktualisierte Version der Software enthält. Der komplette Download eines Update Containers erfolgt erst bei positiv erfolgter Prüfung. Dies spart unnötigen Datentransfer und eliminiert die Gefahr des Downgrading durch Übermittlung eines veralteten Updates.

Zur Authentifizierung werden die ersten beiden Komponenten des Update Files geladen und ausgewertet. Dort finden sich die Informationen über die unterstütze Hardware und um welche Softwareversion(en) es sich beim Inhalt handelt. Desweitern findet man dort eine signierte Datei mit den Hashes aller Update-Images, die der Update Container mit sich führt – siehe hierzu auch Bild-4.

Pre- und Postprocessing

Vor bzw. nach dem eigentlichen Update sollte es möglich sein, bestimmte, vom Nutzer definierbare Operationen auszuführen. So ist es beispielsweise bei einem A/B Update notwendig, dass nach dem eigentlichen Update der Bootloader die Information bekommt, welche Partition als nächste zu booten ist.

Feedback

Nach einem Update sollte eine Rückmeldung möglich sein, damit der Update Server feststellen kann, ob das Update erfolgreich eingespielt wurde und die Informationen über das Gerät auf den aktuellen Stand bringen kann. Auch sollte der aktuelle Gerätestatus und ggfs. weitere Informationen abgefragt werden können.

Security

Zur Erhöhung der Sicherheit vor Manipulationen ist es empfehlenswert, dass der Update Container signiert und zusätzlich der Inhalt verschlüsselt werden kann. Die Signatur ist die Garantie dafür, dass der Inhalt auf dem Weg zum Gerät nicht manipuliert wurde (man-in-the-middle Angriffen). Und gleichzeitig dient es der Authentifizierung, also dem Nachweis, dass das Update von einer dazu autorisierten Stelle stammt. Unsere CMS-Signierung unterstützt mehr als eine Root-of-Trust (RoT) für die Verifizierung. Dies ermöglicht Konfigurationen mit mehr als einer Update-Signierungsinstanz, z.B. kann der OEM Lieferant ein Update liefern und auch ein weiterer Lieferant, der eine Anwendung geliefert hat. Beide Updates werden als gültig signiert erkannt und eingespielt.

Die Verschlüsselung verhindert das Mitlesen und erhöht den Sicherheitslevel, da nur derjenige, der im Besitz des korrekten Schlüssels ist, den Inhalt nutzen kann. Aus Performancegründen sollte für die Verschlüsselung ein symmetrisches Verfahren gewählt werden.

Ein derartiger Ansatz ermöglicht die Gewährung einer Datensicherheit auch dann, falls das Update beispielsweise lokal über einen USB-Stick eingespielt werden soll.

Nur den Transportweg mittels TLS zu verschlüsseln, ist nicht ausreichend. Hierbei könnte das Update nach dem Empfang im Klartext gelesen werden.

Sofern vorhanden, sollten HSM oder TPM Module bzw. geeignete Strukturen der SoCs wie Trusted Zone (inklusive der Nutzung von Trusted Execution Environment) für die sichere Verwahrung von Zertifikaten bzw. Schlüsseln zum Einsatz kommen. Die Verwendung von pkcs#11 vereinfacht die Nutzung aus dem Updateprogramm heraus.

 

 

GUI

Sollte das Gerät, welches ein Update bekommt, ein graphisches Benutzer-Interface (GUI) besitzen, so wäre es begrüßenswert, wenn die Update Prozedur dieses GUI für beispielsweise die Auswahl des Updates, die Einholung der Erlaubnis, das Update durchzuführen, die Darstellung des Prozesses und die Erfolgskontrolle genutzt werden könnte.

Den Ablauf eines Updates auf dem Gerät illustriert die nachstehende Zeichnung:

 

Bootzeit

Ein Updatesystem sollte keinen Einfluss auf die Bootzeit des Gerätes haben.

Secure / Measured Boot

Das Updatesystem muss auch in diesen Fällen funktional einsetzbar sein.

Multi-CPU Update und Gateway Funktionalität

Aktuelle Geräte bestehen oft aus mehr als nur einer Multi- oder Single-Core CPU. Auch besitzen moderne SoCs, sogenannte heterogene Multi-Core SoCs, mehr als eine CPU. Ein Update für diese Art von Geräten kommt mit einem Image nicht mehr aus Das Updatesystem muss die Images aus dem Updatefile extrahieren und an die richtigen Speicherstellen schreiben können.

Ähnlich, aber nicht identisch ist der Fall, wenn ein Gerät aus mehreren (unterschiedlichen) Komponenten besteht und diese auch ein Update erhalten sollen, aber keinen Zugang zum Server haben. Dann muss das Gerät mit Zugang um Update-Server als Gateway dienen. Dieses verteilt dann die entsprechenden Images an die unterlagerten Geräte. Voraussetzung hierfür ist, dass alle Geräte die gleiche Update Software verwenden.

Flottenmanagement

Ein Updatesystem sollte einfach mit einem Managementsystem zum automatischen Ausrollen von Updates integrierbar sein. Die Flexibilität unserer Lösung erlaubt die Anbindung an unterschiedliche Device Managementsysteme.

Werkzeug (Tooling)

Es sollte möglich sein, das Update File unabhängig vom Buildsystem zu erstellen. Und in einem weiteren Schritt dann zu signieren und ggfs. zu verschlüsseln.
Die Update Software für das Endgerät sollte sowohl in Debian wie auch in Yocto integrierbar sein.

Erweiterbarkeit

Zukünftige Anforderungen an ein Updatesystem sollten einfach integrierbar sein. Komplexe Sicherheitsanforderungen, wie sie Uptane erfüllt, sollten umsetzbar sein.

Wiederverkauf

Ein Updatesystem sollte einer Neutralisierung des Geräts bzw. dem Zurücksetzen in den Auslieferungszustand zum Zwecke des Wiederverkaufs nicht im Wege stehen.

 

>> zum Seitenanfang