Wo ein CISO die Post-Quanten-Migration beginnt: das kryptografische Inventar

Wenn ein Vorstand einen CISO nach Post-Quanten-Kryptografie fragt, springt das Gespräch meist sofort zu Anbietern und Algorithmen.

Ich verstehe, warum. Sie sind greifbar. Aber jeder ernsthafte Migrationsplan, den ich kenne, beginnt an einer weniger aufregenden Stelle: mit einem Inventar, wo Kryptografie tatsächlich eingesetzt wird.

Die koordinierte Roadmap der Europäischen Union für den Übergang sagt dasselbe. Ihre ersten Meilensteine, fällig bis Ende 2026, betreffen das Verständnis der Exposition und die Planung, nicht den Austausch von Algorithmen.

Warum das Inventar schwieriger ist, als es klingt

Kryptografie ist überall und nirgends. Sie steckt in Protokollen, Bibliotheken, Hardwaremodulen, Cloud-Diensten, Embedded-Geräten und Produkten Dritter. Kaum eine Organisation hat je eine vollständige Liste gebraucht.

Eine Tabelle mit Zertifikaten ist ein Anfang. Sie sagt Ihnen nicht:

• welche Anwendungen welche Schlüsselaustauschverfahren aushandeln;
• welche Bibliotheken in welchen Versionen sie umsetzen;
• welche Geräte Firmware mit welchem Signaturverfahren prüfen;
• welche durch diese Mechanismen geschützten Daten lange vertraulich bleiben müssen;
• von welchem Lieferanten Sie abhängen, um irgendetwas davon zu ändern.

Deshalb setzt sich der Begriff CBOM, kryptografische Stückliste, durch: eine strukturierte Beschreibung kryptografischer Bestandteile, im selben Geist wie eine SBOM für Softwarekomponenten. CycloneDX zum Beispiel unterstützt sie.

Was ein nützliches Inventar enthält

Für jeden kryptografischen Einsatz würde ich mindestens erfassen:

1. Wo er ist: System, Anwendung, Gerät oder Dienst.
2. Was er tut: Schlüsselaustausch, Verschlüsselung, Signatur, Identität, Integrität.
3. Welcher Algorithmus und welche Schlüssellänge, und ob er quantenanfällig ist.
4. Wer ihn umsetzt: eigener Code, Open-Source-Bibliothek, Hardwaremodul, Lieferant.
5. Was er schützt, und wie lange dieser Schutz halten muss.
6. Wie er sich ändern lässt: Konfiguration, Software-Update, Firmware-Update, Hardwaretausch oder gar nicht.
7. Wer verantwortlich ist.

Die letzten beiden Felder lassen die meisten Inventare weg, und gerade sie machen aus einer Liste einen Plan.

Beziehungen zählen mehr als Einträge

Ein Inventar ist eine Liste von Dingen. Eine Migration ist eine Abfolge von Änderungen an Dingen, die voneinander abhängen.

Wenn eine Zertifizierungsstelle ihren Signaturalgorithmus ändert, welche Geräte können neue Zertifikate nicht mehr prüfen? Wenn eine Bibliothek aktualisiert wird, welche Produkte enthalten sie? Wenn ein Gerät eine neue Signatur nicht prüfen kann, welches Update muss zuerst kommen?

Aus einer flachen Liste lassen sich diese Fragen nicht beantworten. Man braucht ein Modell der Beziehungen. Das ist der Kern dessen, was wir bei Shorium bauen, und der Grund, warum ich es ebenso als Design- wie als Sicherheitsproblem sehe: Menschen müssen die Folgen einer Entscheidung sehen, bevor sie sie treffen. Mehr in Warum ich Shorium aufbaue.

Eine pragmatische Reihenfolge

Für den Start braucht es keine perfekte Abdeckung. Eine Reihenfolge, die funktioniert:

1. Mit langlebigen Daten und langlebigen Produkten beginnen. Alles, was über 2035 hinaus vertraulich bleiben muss, und jedes Gerät, das dann noch im Feld ist. Siehe harvest now, decrypt later.
2. Nutzen, was schon da ist. Zertifikatsverwaltung, Netzwerkscans, Code-Repositories, SBOMs und Einkaufsunterlagen zeigen jeweils einen Teil des Bildes.
3. Lieferanten früh fragen. Deren Post-Quanten-Roadmaps begrenzen Ihre. Nehmen Sie die Frage schon jetzt in Verträge und Verlängerungen auf.
4. Nach Änderbarkeit einteilen. Trennen Sie, was sich per Konfiguration ändern lässt, von dem, was ein Release braucht, und von dem, was neue Hardware erfordert. Die letzte Gruppe bestimmt Ihren realen Zeitplan.
5. Lebendig halten. Ein Inventar, das einmal im Jahr aktualisiert wird, ist falsch, wenn Sie es brauchen. Verbinden Sie es mit den Prozessen, die Systeme verändern.

Was man dem Vorstand sagt

Der Vorstand braucht keine Algorithmennamen. Er braucht drei Dinge: wie exponiert die Organisation ist, wie lange eine Migration realistisch dauert und welche Entscheidungen jetzt nötig sind, damit sie nicht länger wird.

Ein gutes Inventar beantwortet alle drei. Deshalb kommt es zuerst.