UNSERE Story

01

Aufgabe

Unser Kunde liefert ECU-Firmware für ein großes europäisches OEM-Programm. Im Rahmen der Secure-Boot-Implementierung des OEM prüft das Steuergerät beim Booten die Signatur jeder Binärdatei. Ist die Signatur ungültig oder fehlt sie, verweigert das Steuergerät die Ausführung.

Der Kunde benötigte eine Signaturinfrastruktur mit:

• einem hardwaregeschützten privaten Schlüssel, der weder Software noch Arbeitsspeicher zugänglich ist
• einem vollständigen Audit Trail darüber, wer Firmware wann signiert hat
• operativem Support
• einem Public Key im Raw-Format, das der Verifikationsmechanismus des Steuergeräts verarbeiten kann
• einem getesteten Disaster-Recovery-Mechanismus

02

Herausforderung

Signaturschlüssel werden häufig als Datei auf einem Server oder in einem Cloud Secrets Manager gespeichert. Das ist praktisch, birgt aber Risiken. Ein so gespeicherter Schlüssel kann kopiert, offengelegt oder aus einem Backup extrahiert werden. Wer eine Kopie erhält, kann damit eigene Firmware signieren, die das Steuergerät anschließend als authentisch akzeptiert.

Die Sicherheitsanforderungen des Kunden schlossen dieses Risiko aus. Der Schlüssel musste deshalb vollständig in dedizierter Hardware verbleiben.

Hardware Security Modules schützen den Schlüssel, sind jedoch komplex im Betrieb. Das Operations-Team musste Binärdateien regelmäßig innerhalb weniger Sekunden signieren können, ohne dafür HSM- oder PKI-Spezialwissen zu benötigen.

03

Lösung

Um den Schlüssel hardwaregeschützt zu halten, ohne die damit verbundene Komplexität an das Operations-Team weiterzugeben, entwickelten wir einen Ed25519-Signaturdienst auf Basis des YubiHSM 2 und stellten ihn auf einer dedizierten Signatur-VM bereit.

Die Mitarbeitenden erzeugen einen SHA-512-Hash der Firmware-Binärdatei und übertragen ihn per SSH an die VM. Der Service validiert den Hash und fordert beim HSM eine Signatur an. Das HSM führt die Signatur intern aus und gibt die Signatur zurück. Bevor diese die anfragende Person erreicht, schreibt der Service einen JSON-Audit-Eintrag in Syslog.

Während des gesamten Prozesses schützen drei voneinander unabhängige Ebenen den Schlüssel:

• Zugriff: SSH ForceCommand erlaubt genau einen Befehl und gewährt keinen Shell-Zugriff. Jede autorisierte Person verfügt über einen persönlichen SSH-Schlüssel. Um den Zugriff zu entziehen, muss lediglich eine Zeile entfernt werden.
• Betriebssystem: Der Service läuft unter einem eingeschränkten Benutzerkonto ohne Login-Shell.
• Hardware: Der Schlüssel wird auf dem YubiHSM 2 generiert und niemals im Klartext exportiert. Die für den Signaturvorgang verwendeten Credentials erlauben ausschließlich das Signieren. Für die Schlüsselverwaltung sind separate Admin-Credentials erforderlich.

Für Disaster Recovery haben wir den Schlüssel mit AES-256-CCM geschützt und auf einem zweiten YubiHSM 2 wiederhergestellt. Dieses erzeugt gültige Signaturen für denselben Public Key. Für den Failover muss lediglich das Backup-Gerät angeschlossen und eine Konfigurationszeile geändert werden.

04

Erfolge

Die produktiven Boot-Binärdateien des Kunden wurden signiert, verifiziert und ausgeliefert. Das Ergebnis:

• Keine Offenlegung des privaten Schlüssels außerhalb des HSM
• 100 % der Signaturvorgänge protokolliert, einschließlich Build-ID, Hash, Signatur und Zeitstempel
• Ein einziger Befehl zum Signieren, ohne dass HSM-Spezialwissen erforderlich ist
• 54 automatisierte Tests mit 87 % Code Coverage, durchgesetzt in der CI-Pipeline

Darüber hinaus unterstützte die Lösung die Anforderungen von ISO/SAE 21434 an Key Lifecycle Management und Audit Trails sowie die Anforderungen der UN R155 an authentifizierte Software-Updates.