AWS KMS führt ML-KEM-Schlüsselpaare mit Encapsulate- und Decapsulate-APIs ein
Victoria Shinder1 Min. LesezeitAWS Key Management Service unterstützt jetzt ML-KEM, das von NIST als FIPS 203 standardisierte gitterbasierte Verfahren zur Schlüsselkapselung. AWS stellt es als Ersatz für den klassischen Schlüsselaustausch dar — Diffie-Hellman- und ECDH-Vereinbarung sowie RSA-Schlüsseltransport —, den NISTs Migrationsfahrplan IR 8547 vorsieht, und als Antwort auf „jetzt mitschneiden, später entschlüsseln“: Ein aufgezeichneter Schlüsselaustausch wird gebrochen, sobald ein ausreichend leistungsfähiger Quantencomputer existiert.
KMS bietet alle drei Schlüsselvarianten des Standards an: ML-KEM-512, ML-KEM-768 und ML-KEM-1024. Eine neue Encapsulate-API erzeugt mit dem öffentlichen Schlüssel ein zufälliges 32-Byte-Geheimnis samt Chiffretext; Decapsulate gewinnt das Geheimnis mit dem privaten Schlüssel daraus zurück. Die private Hälfte verlässt die HSMs von KMS nie, die nach FIPS 140-3 Level 3 validiert sind. Den öffentlichen Schlüssel kann man mit GetPublicKey exportieren, sodass Partner oder Clients die Kapselung lokal mit Bibliotheken wie AWS-LC, OpenSSL oder Bouncy Castle ausführen.
ML-KEM ist in allen Regionen mit KMS verfügbar, ausgenommen Middle East (UAE), Middle East (Bahrain) und die China-Regionen.
Was das bedeutet
Das nützliche Muster ist asymmetrisch: Wer den KMS-Schlüssel hält, muss nie einen privaten Schlüssel herausgeben, die Gegenseite braucht nur einen öffentlichen Schlüssel und eine gängige Bibliothek. Damit ist ein verwalteter Dienst ein vernünftiger Startpunkt für post-quantensicheren Schlüsselaustausch zwischen Diensten. Die ausgenommenen Regionen sind für alle mit Datenresidenz-Vorgaben am Golf oder in China wichtig — dort bleibt vorerst ein klassischer oder selbst betriebener Weg nötig.