Krypto-Agilität in der Firmware: Geräte entwerfen, die ihre Kryptografie wechseln können

Jeder kryptografische Algorithmus geht irgendwann in den Ruhestand. MD5 ist es. SHA-1 ist es. Für RSA und Elliptische-Kurven-Kryptografie gibt es inzwischen einen veröffentlichten Ausstiegsplan.

Für eine Webanwendung ist das Ausmustern eines Algorithmus ein Migrationsprojekt. Für ein Gerät im Feld kann es einen Rückruf bedeuten.

Krypto-Agilität ist die Fähigkeit, die von einem System verwendete Kryptografie zu wechseln, ohne das System neu zu entwerfen. Das klingt nach einer Bibliotheksfunktion. Bei Embedded-Produkten ist es eine Architekturentscheidung, und sie fällt sehr früh.

Wo Agilität meistens scheitert

Nach meiner Erfahrung scheitern Geräte selten am Algorithmus selbst, wenn sie ihre Kryptografie nicht wechseln können. Sie scheitern an einer Annahme an anderer Stelle.

• Der Bootloader prüft die Firmware mit einem festen Algorithmus und einem festen öffentlichen Schlüssel, eingebrannt in nur lesbaren Speicher.
• Das Partitionslayout reserviert genau den Platz für die heutige Signatur und kein Byte mehr.
• Das Update-Protokoll hat ein Nachrichtenformat, das keine größere oder zweite Signatur aufnehmen kann.
• Die Geräteidentität ist ein Zertifikat aus einer Kette, die sich nicht neu signieren lässt.
• Die Schlüssel liegen in einem Secure Element, das nur die Algorithmen seiner Generation unterstützt.

Jede dieser Entscheidungen war vernünftig, als sie getroffen wurde. Zusammen machen sie aus einem Krypto-Upgrade einen Hardwaretausch.

Designprinzipien

Diese Prinzipien wünsche ich mir für jedes neue vernetzte Produkt. Keines davon verlangt, heute einen Post-Quanten-Algorithmus auszuwählen.

1. Vertrauensbasis und Algorithmus trennen. Der unveränderliche Teil der Boot-Kette sollte so klein wie möglich sein und die nächste Stufe mit mehr als einem Verfahren prüfen oder an eine aktualisierbare Stufe übergeben können.

2. Platz lassen. Planen Sie Flash, RAM und Nachrichtengrößen für Signaturen und Schlüssel, die ein Mehrfaches der heutigen groß sind. Post-Quanten-Signaturen umfassen Kilobyte, nicht Byte.

3. Alles versionieren, was Kryptografie trägt. Firmware-Images, Manifeste, Zertifikate und Protokollnachrichten sollten angeben, welche Algorithmen sie verwenden, damit Alt und Neu während eines Übergangs nebeneinander bestehen können.

4. Doppelte Signaturen einplanen. Während einer Migration muss ein Update eventuell mit dem alten und dem neuen Verfahren signiert werden, damit jedes Gerät im Feld es prüfen kann. Entwerfen Sie das Manifest so, dass das möglich ist.

5. Schlüssel austauschbar machen. Halten Sie ein dokumentiertes, getestetes Verfahren bereit, um Signaturschlüssel und Vertrauensanker zu rotieren, einschließlich dessen, was mit Geräten passiert, die monatelang offline sind.

6. Abhängigkeiten kennen. Agilität ist unmöglich, wenn Sie nicht wissen, welche Komponente von welchem Lieferanten welche kryptografische Funktion umsetzt. Eine SBOM hilft; eine Landkarte der kryptografischen Beziehungen hilft mehr.

Die organisatorische Seite

Ein Gerät kann technisch agil sein und trotzdem feststecken, weil niemand weiß, wer entscheidet.

Ein Wechsel des Signaturalgorithmus betrifft Hardware, Firmware, Update-Backend, Fertigung, Zertifikatsverwaltung, Kundensupport und manchmal die Zertifizierung. Jedes Team hält einen Teil der Information. Sind die Abhängigkeiten dazwischen nicht sichtbar, beginnt jede Migration mit Wochen der Archäologie.

Genau daran arbeiten wir bei Shorium: die kryptografischen Abhängigkeiten in vernetzten Produkten zu modellieren, damit Teams vorher sehen, was eine Änderung betrifft. Die Idee des Trust Twin habe ich in Warum ich Shorium aufbaue erklärt.

Ein einfacher Test

Hier ist ein Test, den ich nützlich finde. Fragen Sie Ihr Team:

„Wenn wir den Algorithmus ersetzen müssten, mit dem wir die Firmware unseres ältesten noch unterstützten Produkts signieren: Was würden wir ändern, wer würde es tun, und wie lange würde es dauern?“

Ist die Antwort ein Plan, haben Sie etwas Agilität. Ist die Antwort Schweigen, wissen Sie, wo Sie anfangen.

Die Regulierung geht in dieselbe Richtung. Der Cyber Resilience Act erwartet, dass Produkte über ihren Support-Zeitraum sicher bleiben, und das NIST plant, die heutigen Public-Key-Algorithmen nach 2030 als veraltet einzustufen. Geräte, die jetzt entworfen werden, werden diesen Wandel erleben. Sie sollten dafür gebaut sein.