Firmware-Sicherheit & OTA für Fertigung & Automatisierung
An einer Automatisierungslinie ist die echte Angriffsfläche nicht die Firmware-Logik, sondern das unsignierte Image, das ein Dienstleister per USB flasht, und der nicht authentifizierte Modbus-Schreibzugriff, den niemand protokolliert hat. Wir sichern das Gerät selbst: einen in eFuses gebrannten Hardware-Vertrauensanker, einen OTA-Pfad, der nur gegengezeichnete verschlüsselte Images akzeptiert, und eine Befehlsebene, die nachweist, wer jeden Sollwert ausgelöst hat. Die Linie läuft weiter, vertraut aber nichts mehr, was sie nicht kryptografisch verifizieren kann.
Challenges specific to Manufacturing & Automation
Unsignierte Firmware, geflasht von jedem mit Kabel
Ohne Hardware-Vertrauensanker führt der Bootloader aus, was im Flash liegt, sodass das Laptop eines Dienstleisters oder ein getauschtes Modul Schadfirmware einschleusen kann, die auf dem HMI identisch zur Produktion aussieht.
OTA-Images reisen und ruhen im Klartext
Fehlt dem Update-Kanal die Signaturprüfung und die Verschlüsselung im Ruhezustand, kann ein Angreifer im Anlagen-LAN das Image abfangen, klonen oder ersetzen und Schadlogik an jede identische Steuerung der Linie verteilen.
Downgrade öffnet gepatchte Schwachstellen erneut
Ein Gerät, das jedes gültig signierte Image akzeptiert, lässt sich auf einen bekannt verwundbaren Build zurückrollen und macht so einen Sicherheitspatch rückgängig, während es jede Signatur- und Versionsprüfung des Betreibers besteht.
Sollwert-Schreibzugriffe ohne authentifizierten Ursprung
Flache OT-Protokolle erlauben jedem Host im Segment, einen Drehzahl-, Rezept- oder Aktorbefehl zu schreiben, sodass eine kompromittierte Engineering-Workstation den Prozess steuern kann, ohne nachzuweisen, wer die Änderung ausgelöst hat.
Kein manipulationssicherer Nachweis, wer was geändert hat
Werden Firmware-Updates, Konfigurationsänderungen und privilegierte Befehle nicht mit Identität und Integritätsschutz protokolliert, kann ein Forensik-Team nach einem Vorfall den Ablauf nicht rekonstruieren oder den überlebenden Aufzeichnungen vertrauen.
Steuerungen liegen in einem flachen, nicht vertrauenswürdigen Netz
Ohne Zonen- und Conduit-Grenzen erreicht ein infizierter Büro-PC SPS und Edge-Knoten direkt, sodass eine einzige abgephishte Anmeldung die gesamte Zelle freilegt statt nur einer segmentierten Montagestation.
How GizanTech solves them
- eFuse-Hardware-Vertrauensanker (Secure Boot v2). Den RSA-3072-Public-Key-Digest in ESP32-eFuses brennen und Secure Boot v2 aktivieren, damit der ROM-Bootloader jede Stufe kryptografisch verifiziert; ein manipuliertes oder unsigniertes Image hält beim Boot an, statt zu laufen, und erfüllt die Firmware-Integrität nach IEC 62443-4-2 CR 3.4.
- Signierte und AES-XTS-verschlüsselte OTA-Pipeline. Jedes Release mit einem Offline-Schlüssel in einem HSM/Yubico-Token signieren, den Flash mit AES-256-XTS verschlüsseln und Updates über gegenseitig authentifiziertes TLS ausliefern, sodass das Gerät nur ein gegengezeichnetes Image akzeptiert und das Binary bei Abfangen oder Auslesen nutzlos ist.
- Monotone Anti-Rollback-Durchsetzung. Jede OTA an einen Secure-Version-eFuse-Zähler koppeln, der nur hochzählt, sodass der Bootloader jedes Image mit einer Sicherheitsversion unter dem aktuellen Mindestwert des Geräts ablehnt und Downgrade-zu-verwundbar-Angriffe gemäß IEC 62443-4-2 CR 3.10 blockiert.
- Authentifizierter Befehlskanal mit RBAC. Sollwert- und Aktor-Schreibzugriffe in Authentifizierung pro Nachricht (signierte/HMAC-Payloads oder mTLS-Client-Zertifikate) mit rollenbasierter Autorisierung einbetten, sodass die Steuerung jeden Befehl ohne gültige Bediener- oder Ingenieur-Identität ablehnt und CR 1.1/1.2 sowie CR 2.1 erfüllt.
- Manipulationssicheres Audit-Logging an SIEM. Hash-verkettete, zeitgestempelte Datensätze für jedes Firmware-Update, jede Konfigurationsänderung und jeden privilegierten Befehl per Syslog/TLS an das Anlagen-SIEM senden, sodass jeder Eintrag integritätsgeschützt ist und eine gelöschte oder geänderte Zeile die Kette bricht und einen Alarm auslöst.
- Netzwerksegmentierung in Zonen und Conduits. Das Gerät hinter einem definierten Conduit mit Deny-by-Default-Firewall, dediziertem OT-VLAN und gebrokertem Nordbound-MQTT/TLS statt direkter Exposition auslegen und IEC 62443-3-3-Zoning anwenden, sodass ein kompromittierter IT-Host die Steuerung nicht erreicht.
| Sicherheitskontrolle | Mechanismus | IEC-62443-Referenz | Verhinderter Angriff / Risiko |
|---|---|---|---|
| Secure Boot | RSA-3072-Signatur, vom ROM gegen einen in eFuse gebrannten Schlüssel-Digest geprüft | 62443-4-2 CR 3.4 (Firmware-Integrität) | Schadhafte oder unsignierte Firmware per USB oder getauschtes Modul geflasht |
| Signierte + verschlüsselte OTA | Release-Signierung mit Offline-Schlüssel plus AES-256-XTS-Flash-Verschlüsselung über mutual TLS | 62443-4-2 CR 3.4 / CR 4.1 (Vertraulichkeit) | Abfangen, Klonen oder Ersetzen des Images im Anlagen-LAN |
| Netzwerksegmentierung | OT-VLAN hinter einem Deny-by-Default-Conduit mit gebrokertem Nordbound-Verkehr | 62443-3-3 SR 5.1 / SR 5.2 (Zonen & Conduits) | Laterale Bewegung von einem kompromittierten IT- oder Büro-Host |
| Befehlsautorisierung | HMAC pro Nachricht / mTLS-Client-Zertifikate mit rollenbasierter Zugriffskontrolle | 62443-4-2 CR 1.1, CR 1.2, CR 2.1 | Nicht authentifizierte Sollwert-, Rezept- oder Aktor-Schreibzugriffe |
| Audit-Logging | Hash-verkettete, zeitgestempelte Syslog/TLS-Datensätze, an das Anlagen-SIEM gestreamt | 62443-4-2 CR 2.8 / CR 2.9 (auditierbare Ereignisse) | Stille Manipulation und eine nicht rekonstruierbare Zeitleiste nach dem Vorfall |
| Anti-Rollback | Monotoner Secure-Version-eFuse-Zähler, vom Bootloader vor dem Swap geprüft | 62443-4-2 CR 3.10 (Least-Functionality / Downgrade) | Downgrade auf einen bekannt verwundbaren Firmware-Build |
Go deeper
Firmware Security & OTA for other industries
Frequently asked questions
Verlangsamt Secure Boot v2 unsere Produktionslinie oder die Bootzeit?
Nicht nennenswert. Die Signaturprüfung fügt nur beim Einschalten Dutzende Millisekunden hinzu, nicht im Betrieb, sodass die Taktzeit unberührt bleibt. Der Kompromiss ist betrieblich: Sind die eFuses gebrannt, ist das Gerät dauerhaft an Ihren Schlüssel gebunden, daher integrieren wir die Schlüsselbereitstellung in Ihren Flash-Schritt am Bandende statt im Feld.
Können wir OTA-Updates auch an Steuerungen senden, die mitten in der Schicht nicht gestoppt werden können?
Ja. Wir nutzen A/B-Partitionen, sodass das neue signierte, verschlüsselte Image im Hintergrund geschrieben und verifiziert wird; der Swap wird so gesteuert, dass er nur greift, wenn die Steuerung einen Leerlauf- oder sicheren Zustand meldet, mit automatischem Rollback zum vorherigen Slot, falls die Selbstprüfung nach dem Boot fehlschlägt.
Wie bildet sich das auf IEC 62443 für ein Audit oder einen Sicherheitsfragebogen eines Kunden ab?
Jede Kontrolle ist bestimmten Komponentenanforderungen zugeordnet: Secure Boot und signierte OTA auf CR 3.4, Anti-Rollback auf CR 3.10, Befehlsauthentifizierung auf CR 1.1 und 1.2 sowie Audit-Logging auf CR 2.8 und 2.9. Wir liefern die Kontroll-zu-Anforderungs-Matrix und Testnachweise, damit Ihr Team den Fragebogen beantworten kann, statt die Firmware zurückzuentwickeln.
Was passiert mit einem Gerät, wenn ein Angreifer den Flash-Chip tauscht oder ausliest?
Die AES-256-XTS-Flash-Verschlüsselung bindet die Inhalte an einen in eFuses gehaltenen Schlüssel, der den Chip nie verlässt, sodass ein ausgelesenes oder transplantiertes Flash-Image Chiffretext ist und nicht bootet. In Kombination mit Secure Boot ist weder das Auslesen der Firmware noch das Einschleusen einer modifizierten ohne den On-Die-Schlüssel machbar.
Können Sie das auf eine bereits ausgerollte Flotte nachrüsten oder nur auf neue Designs?
Beides, mit Einschränkungen. Neue Designs erhalten gebrannte eFuses und aktivierte Verschlüsselung in der Fertigung für vollen Schutz. Bei einer ausgerollten Flotte können wir Secure Boot und signierte OTA auf Einheiten mit noch ungebrannten eFuses per einmaligem gesicherten Update aktivieren; Einheiten in bereits unsicherem Zustand benötigen meist einen kontrollierten physischen Zugriff, um den Vertrauensanker sicher bereitzustellen.
Brechen authentifizierte Befehle unsere bestehende Modbus- oder MQTT-Integration?
Wir legen Authentifizierung und Autorisierung über Ihre Protokolle, ohne sie zu verwerfen: Der Nordbound-Verkehr wechselt zu gegenseitig authentifiziertem TLS mit signierten Payloads, während Legacy-Modbus hinter der Conduit-Grenze bleibt und über den gesicherten Knoten gebrokert wird, sodass die SPS- und SCADA-Integration weiterläuft, während die Vertrauensgrenze zum Gerät wandert.