Schlüssel und ihre Ablage

Der Dienst erzeugt und verwahrt die Schlüssel, mit denen er rechnet. Die anfragende Seite erhält eine Kennung und, bei Schlüsselpaaren, den öffentlichen Schlüssel. Diese Seite beschreibt, wie lange ein Schlüssel lebt, wie er geschützt ist und welche Folgen das für den Betrieb hat.

• Schlüsselkennung (key_id): eine vorzeichenlose 32-Bit-Zahl, mit der eine Anfrage einen Schlüssel im Dienst benennt. Der Wert 0 ist keine gültige Kennung.
• Schlüsselablage: die Tabelle im Arbeitsspeicher des Dienstes, die Kennungen auf Schlüssel abbildet.
• Nonce: die 12 Byte lange Einmalzahl von AES-GCM. Dieselbe Nonce zweimal mit demselben Schlüssel verrät den Authentisierungsschlüssel und den Klartextunterschied beider Nachrichten.

1. Erzeugen. Eine Schlüsselerzeugung bildet das Schlüsselmaterial mit dem Zufallsgenerator von OpenSSL und legt es in der Ablage ab. Welche Schlüsselarten eine Bauform erzeugen kann, steht unter Bauformen im Vergleich.
2. Kennung vergeben. Der Dienst zieht die Kennung zufällig, nicht fortlaufend. Wer eine Kennung nicht kennt, kann sie deshalb nicht erraten, indem er hochzählt.
3. Benutzen. Signieren, Entkapseln und AES-Operationen nennen die Kennung. Der private Schlüssel verlässt den Dienst dabei nicht.
4. Öffentlichen Schlüssel abfragen. Für ML-DSA- und ML-KEM-Schlüssel gibt der Dienst den öffentlichen Schlüssel heraus. Für einen AES-Schlüssel scheitert dieselbe Anfrage.
5. Ende. Der Dienst kennt kein Löschen einzelner Schlüssel. Alle Schlüssel enden mit dem Prozess. Beim Freigeben überschreibt der Dienst das Schlüsselmaterial mit Nullen.

Weil der Dienst nichts dauerhaft speichert, sind nach einem Neustart alle Kennungen ungültig. Eine Anwendung, die Signaturen über einen Neustart hinweg prüfbar halten will, muss den öffentlichen Schlüssel selbst aufbewahren und nach dem Neustart neue Schlüssel erzeugen lassen.

Für jeden AES-Schlüssel merkt sich der Dienst die letzten 1024 Nonces, mit denen er verschlüsselt hat, und weist eine Verschlüsselung mit einer davon ab. Das fängt Programmierfehler ab, etwa eine Nonce, die fest im Code steht. Es ist kein vollständiger Schutz:

• Eine Nonce, die älter als die letzten 1024 ist, erkennt der Dienst nicht mehr.
• In der L4Re-Bauform liefert die anfragende Seite die Nonce. Sie ist für deren Einmaligkeit verantwortlich; ein Zähler oder 12 Byte Zufall aus einem geprüften Zufallsgenerator sind die üblichen Wege.
• Die Windows-Bauform erzeugt jede Nonce selbst mit 12 Byte Zufall. Nach NIST SP 800-38D sollte ein Schlüssel mit zufälligen Nonces höchstens 2³² Nachrichten verschlüsseln.

• Kurzlebige Schlüssel passen. Sitzungsschlüssel, Schlüssel für einen einzelnen Austausch und Schlüssel einer Vorführung sind für diese Ablage gedacht.
• Langlebige Signaturschlüssel passen nicht. Ein Schlüssel einer Zertifizierungsstelle oder ein Schlüssel, dessen Signaturen Jahre gelten sollen, gehört in ein Hardware-Sicherheitsmodul. Für Zertifizierungsstellen setzt ETSI EN 319 411-1 ein geprüftes kryptographisches Gerät voraus; ein Software-Prozess erfüllt das nicht.
• Der Prozess ist die Schutzgrenze. Wer den Speicher des Dienstprozesses lesen kann, liest die Schlüssel. Unter L4Re trennt der Mikrokern die Tasks; unter Windows schützt nur das Benutzerkonto, unter dem der Dienst läuft.

• Die Anfragen zum Erzeugen und Abfragen von Schlüsseln im Einzelnen; siehe Binärprotokoll der L4Re-Bauform und JSON-Protokoll der Windows-Bauform.

• NIST SP 800-38D: Galois/Counter Mode (GCM) and GMAC
• ETSI EN 319 411-1: Policy and security requirements for Trust Service Providers issuing certificates