Update
Updates für Industrial Embedded Linux.
OTA-Updates für industrielle Geräte
Industrielle Embedded-Geräte brauchen vollständig automatisierte Update-Mechanismen, die ohne menschliches Eingreifen funktionieren. OTA-Update-Systeme müssen dabei unterschiedliche Speichermedien wie NAND- und NOR-Flash, eMMC und SD-Karten unterstützen.
Mit modernen SoC-Architekturen geht es zudem um mehr als den Austausch von Software. Aktuelle Embedded-Systeme vereinen heterogene Recheneinheiten: Applikationsprozessoren mit Linux, Echtzeitprozessoren mit RTOS, FPGAs mit eigenen Bitstreams und weitere Komponenten. Jede davon benötigt ein eigenes Update-Verfahren, und alle müssen in einen gemeinsamen, koordinierten Update-Prozess eingebunden sein.
In der Industrie kommt hinzu: Die Geräte haben oft keinen Bediener vor Ort oder werden in großen Stückzahlen ausgerollt. Fehler müssen deshalb automatisch erkannt und behoben werden.
Unser Industrial Grade Linux OS verfügt bereits über einen vorintegrierten A/B-Update-Mechanismus mit Rollback-Schutz. Dadurch müssen Entwicklungsteams weder den Update-Client noch die Server-Koordination und die Signatur-Pipeline von Grund auf selbst entwickeln.
A/B-Architektur für OTA-Updates
A/B-Updates haben sich in industriellen Anwendungen als De-facto-Standard etabliert, bei denen Zuverlässigkeit wichtiger ist als die zusätzlichen Speicherkosten. Die grundlegende Update-Architektur umfasst zwei miteinander verbundene Komponenten:
Update-Client
Ein Systemdienst auf dem Embedded-Gerät überwacht durch regelmäßiges Polling oder über Push-Benachrichtigungen, ob Updates verfügbar sind. Sobald ein Update erkannt wird, lädt der Client die Pakete herunter und führt vor der Installation eine erste Validierung durch, einschließlich der Überprüfung der Signatur. Anschließend führt der Client die Installation durch, verwaltet die Konfiguration, koordiniert Neustarts des Systems und führt Zustandsprüfungen durch, um den erfolgreichen Abschluss des Updates zu verifizieren.
Update-Server
Eine Management-Infrastruktur, die Update-Images speichert, den Gerätebestand verwaltet, Update-Kampagnen steuert und weitere Funktionen bereitstellt. Der Server authentifiziert die Geräte, stellt Update-Pakete bereit und bietet Mechanismen zur Steuerung des Rollouts, einschließlich schrittweiser Bereitstellungen.
Der Kommunikationsablauf
- Zunächst erhält der Update-Client vom Update-Server eine Push-Benachrichtigung, dass ein Update verfügbar ist.
- Der Server übermittelt Update-Metadaten, einschließlich Versionsinformationen und Paket-Prüfsummen.
- Der Client prüft die Kompatibilität und den verfügbaren Speicherplatz, bevor er das vollständige Update-Paket anfordert.
- Während des Downloads überprüft der Client die kryptografischen Signaturen.
- Nach der Installation auf der inaktiven Partition passt der Client die Bootloader-Konfiguration an und startet das System neu.
- Nach dem Neustart überprüft eine Zustandsüberwachung den erfolgreichen Abschluss des Updates. Falls das Update nicht erfolgreich war, wird automatisch ein Rollback auf die vorherige Version ausgelöst.
Delta-Updates
Ob A/B- oder asymmetrische Update-Strategie: Mit Delta-Updates (differenziellen Updates) lässt sich die übertragene Datenmenge in jedem Fall reduzieren. Statt vollständiger System-Images werden nur die binären Unterschiede zwischen aktuellem und neuem Image übertragen.
Dazu vergleicht der Server Quell- und Ziel-Image auf Blockebene, berechnet daraus einen differenziellen Patch und bündelt die Änderungen in einem kompakten Delta-Paket. Auf dem Gerät wendet der Update-Client diesen Patch auf die bestehende Installation an und erzeugt so das neue System-Image.
Dieser Ansatz bietet mehrere Vorteile:
70–90%
kleinere Updates als bei vollständigen Images, und damit schnellere Auslieferung, höhere Zuverlässigkeit bei eingeschränkten Netzwerkverbindungen und längere Lebensdauer des eMMC-Speichers durch weniger Schreibvorgänge
Sicherheitsarchitektur
OTA-Update-Systeme stellen eine kritische Angriffsfläche in Embedded-Geräten dar. Ein kompromittierter Update-Mechanismus ermöglicht die vollständige Kontrolle über das System.
Kryptografische Verifikation
- Signieren von Images: Jedes Update-Paket muss mit
asymmetrischen Verfahren (RSA-2048/4096 oder ECDSA) signiert werden.
Die privaten Schlüssel liegen in Hardware Security Modules (HSMs). Die
Geräte prüfen die Signaturen mit öffentlichen Schlüsseln, die in
unveränderlichem oder hardwaregeschütztem Speicher verankert sind (ROM, eFuses, TPM). - Chain of Trust: Der ROM-Bootloader prüft den sekundären Bootloader, dieser den Kernel und der Kernel das Root-Filesystem. So kann sich eine manipulierte Komponente nicht über einen Neustart hinweg festsetzen.
Sichere Kommunikation
Server und Gerät authentifizieren sich gegenseitig über TLS 1.3. Der Server prüft das Gerät anhand eines Client-Zertifikats, dessen Schlüssel geschützt gespeichert ist, etwa in einem Secure Element, einem TPM oder in OP-TEE. Das Gerät prüft den Server über Certificate Pinning und ist so auch gegen gefälschte oder unrechtmäßig ausgestellte Zertifikate geschützt.
Rollback-Schutz
- Anti-Rollback: Hardwarebasierte monotone Zähler verhindern Downgrade-Angriffe. Der Bootloader startet keine Firmware, deren Version unter der hinterlegten Mindestversion liegt. Den Zählerstand speichern zum Beispiel der sichere Speicher von ARM TrustZone, NV-Zähler im TPM oder OTP-Fuses des SoC. Erhöht wird er, sobald ein verifiziertes Update eine sicherheitsrelevante Lücke schließt.
- Replay-Schutz: Signierte Metadaten mit Versionsnummer und Ablaufdatum verhindern, dass Angreifer alte, gültig signierte Update-Pakete erneut einspielen.
Key-Management
Langfristige Deployments erfordern hierarchische Schlüsselstrukturen, bei denen Root-Schlüssel Zwischenzertifikate validieren, regelmäßig rotierte Zwischenschlüssel Update-Pakete signieren und gerätespezifische Schlüssel eine individuelle Sperrung ermöglichen.
Erfahren Sie mehr über unsere Embedded-Security-Lösungen oder die vorintegrierte IGLOS-Plattform.
Updates über den gesamten Produktlebenszyklus
Industrielle Embedded-Geräte sind oft 10–15 Jahre oder länger im Einsatz. Die Update-Strategie muss deshalb über den gesamten Produktlebenszyklus funktionieren.
Bereitstellungsstrategien
Schrittweise Rollouts
Klassifizierung von Updates
Ordnen Sie Updates nach ihrem Risiko ein, etwa als kritische Sicherheitspatches, Funktionserweiterungen oder Fehlerbehebungen, und legen Sie danach das Tempo der Verteilung fest. Kritische Sicherheitsupdates werden außerhalb der regulären Wartungszyklen beschleunigt ausgerollt, Feature-Updates in geplanten Wartungsfenstern.
Rollback-Verfahren
Jedes Update braucht eine automatische Rollback-Funktion. Legen Sie fest, was ein Rollback auslöst, zum Beispiel ein fehlgeschlagener Bootvorgang, eine fehlgeschlagene Zustandsprüfung oder ein Watchdog-Timeout. Die inaktive Partition behält die vorherige Version, bis das Update erfolgreich validiert ist.
Langzeit-Unterstützung
Langfristige Wartung
Embedded-Linux-Systeme in industriellen Umgebungen müssen oft 10–15 Jahre oder länger unterstützt werden. Dafür müssen Kernel, Treiber und Userspace-Komponenten über den gesamten Zeitraum gepflegt werden.
End-of-Life-Management
Legen Sie klare Regeln für das Support-Ende fest. Geräte am Ende ihres Lebenszyklus können letzte Sicherheitsupdates erhalten oder in einen abgesicherten Endzustand versetzt werden, zum Beispiel mit deaktivierten Netzwerkdiensten und gesperrten Schnittstellen.
Monitoring und Validierung
Auswertung im Feld
Daten aus dem Feld zeigen, wie erfolgreich Updates sind, welche Fehlermuster auftreten und wie sich die Versionen über die Geräte im Feld verteilen. Nach einem Update überwacht das System erfolgreiche Bootvorgänge, Zustandsprüfungen der Anwendungen und Performance-Kennzahlen. Automatisierte Systeme erkennen Auffälligkeiten und lösen bei Bedarf ein Rollback aus.
Entwickeln Sie Ihre Update-Lösung
Linutronix unterstützt Kunden in allen Phasen der Entwicklung von OTA-Update-Lösungen:
Architekturdesign
Konzeption von A/B- oder asymmetrischen Update-Architekturen, abgestimmt auf Ihre Hardwareplattform.
Integration in das Build-System
Einbindung in ELBE oder Yocto, damit Update-Pakete reproduzierbar entstehen.
Implementierung der Sicherheitsmechanismen
Kryptografische Verifikation, Secure-Boot-Integration und Konformität mit IEC 62443 und dem CRA.
Optimierung von Delta-Updates
Differenzielle Updates, die Bandbreite und Übertragungszeit reduzieren.