Die heutige digitale Sicherheit stützt sich maßgeblich auf asymmetrische Verschlüsselungsverfahren wie RSA und ECC, die darauf basieren, dass bestimmte mathematische Operationen für klassische Computer praktisch nicht umkehrbar sind. Da Quantencomputer jedoch in der Lage sein werden, diese mathematischen „Einbahnstraßen“ durch technologische Abkürzungen zu überwinden, wird die Entwicklung und Implementierung der Post-Quanten-Kryptographie (PQC) wie ML-KEM unumgänglich.
Während die symmetrische Verschlüsselung durch den AES-Standard – insbesondere bei Verwendung einer 256-Bit-Verschlüsselung – weiterhin als weitgehend resistent gegen diese neuen Bedrohungen gilt, liegt das Hauptrisiko bei den asymmetrischen Protokollen. Da diese jedoch entscheidend für den sicheren Austausch von Schlüsseln zwischen Sendern und Empfängern sind, konzentriert sich die aktuelle Forschung und Umstellung vor allem auf diesen Bereich der Kryptographie
In diesem Beispiel wird der gesamte PQC Schlüsselerzeugungsprozess zwischen einem Server und einem Client als Linux Shell Script abgebildet. Das Script kann man leicht auf zwei Linux Systeme teilen und die die Dateien server_public.pem und ciphertext.bin zwischen den Systemen austauschen. Das Beispiel erfordert OpenSSL in Version 3.5+.
#!/usr/bin/bash -v
algo=“ml-kem-512″ # ~AES-128
algo=“ml-kem-768″ # ~AES-192
algo=“ml-kem-1024″ # ~AES-256
### SERVER side ###
# 1. Generate server PQC private key
# results:
# server_private.pem key
openssl genpkey -algorithm $ -out server_private.pem
# Extract public key
# results:
# server_public.pem key
openssl pkey -in server_private.pem -pubout ‑out server_public.pem
### CLIENT side ###
# 2. Encapsulation of secret_client.bin by the server_public key
# results:
# ciphertext.bin (to be transfered to the SERVER)
# secret_client.bin (the shared secret)
openssl pkeyutl -encap ‑pubin ‑inkey server_public.pem -out ciphertext.bin -secret secret_client.bin
### back to SERVER side ###
# 3. Decapsulation by the server
# results:
# secret_server.bin (the shared secret)
openssl pkeyutl -decap ‑inkey server_private.pem -in ciphertext.bin -secret secret_server.bin
# 4. Compare secret_client.bin & secret_server.bin
# tip: In real world the shared secret will never be used as password or encryption key itself.
# Instead, a KDF (key derivation function) will be used to generate a secure AES-key.
sha256sum secret_client.bin secret_server.bin
Die folgende Grafik zeigt den Informationsfluss zwischen dem SERVER und dem CLIENT, wobei die Schüsselgenerierung des privaten Schlüssels am Server nur einmalig erfolgt und beliebig viele Clients über openssl pkeyutl ein individuelles Shared Secret erzeugen, dass in Folge für die Session spezifische Verschlüsselung zwischen Server und Client verwendet werden kann.
Abbildung: ML-KEM Schlüsselgenerierung für ein einfaches PQC TLS
Hinweis: ML-KEM ist ausschließlich dafür für die Generierung eines gemeinsamen Geheimnisses geeignet, dass für die Verschlüsselung genutzt werden kann. Der Algorithmus besitzt keine Funktion, um eine digitale Signatur zu erstellen. Um ein X.509-Zertifikat zu signieren, benötigt man einen Signatur-Algorithmus einen sogenannten DSA (Digital Signature Algorithm). Für PQC ist das ML-DSA (ehemals Dilithium).
Hinterlasse einen Kommentar
Du musst angemeldet sein, um einen Kommentar schreiben zu können.