Sollten in Zukunft Quantencomputer verfügbar werden, die eine für das Brechen von Verschlüsselung ausreichende Bitbreite und Verarbeitungsgeschwindigkeit bieten, ist bei IPSec vor allem die Diffie-Hellman-Schlüsselvereinbarung davon bedroht. Denn sollte diese gebrochen werden können, können damit auch früher aufgezeichnete Übertragungen nachträglich entschlüsselt werden. Deswegen ist der Schutz gegen zukünftige Angriffe per Quantencomputer auch heute schon wichtig.
Es ist dagegen keine Angriffsmöglichkeit mit Quantencomputern auf symmetrische Verschlüsselungsverfahren wie z.B. AES oder die Authentifizierung per Pre-Shared-Key bekannt.
![[Achtung]](../images/admon/caution.png) | Achtung |
|---|---|
Die Authentifizierung per Pre-Shared-Key in IKEv2 geschieht im Verbund mit der Diffie-Hellman-Schlüsselvereinbarung. Sie ist daher nicht gegen Angriffe per Quantencomputer geschützt. |
Es wurden komplett neue asymmetrische Verschlüsselungsverfahren, genannt Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), entwickelt, die Angriffen mit Quantencomputern standhalten. Die Nutzung deren mathematischer Konzepte für Kryptographie ist allerdings neu und wurde noch nicht über Jahrzehnte intensiv von Kryptologen auf Schwachstellen abgeklopft. Bei diesen Verfahren gibt es deswegen ein höheres Risiko, dass eine neue Schwachstelle gefunden wird als bei klassischen asymmetrischen Verfahren.
Ein weiterer Nachteil dieser neuen Verschlüsselungsverfahren ist, dass vergleichsweise große Datenmengen zur Aushandlung übertragen werden müssen. Dies bedeutet einen langsameren Verbindungsaufbau und eine höhere Empfindlichkeit gegenüber Übertragungsstörungen.
Ein gängiger Lösungsansatz ist daher klassische asymmetrische Authentifizierung und Schlüsselvereinbarung mit einem Pre-Shared-Key zu verbinden. Zum Überwinden des Schutzes müssten dann beide Verfahren geknackt werden. Gleichzeitig benötigt der zusätzliche Pre-Shared-Key kaum zusätzliche Datenübertragung oder Rechenzeit.
Dieses Verfahren wird Post-Quantum Pre-Shared Key (PPK) genannt und ist bei IKEv2 eine optionale Erweiterung, die vom Intra2net System unterstützt wird.
Neben dem PPK selbst muss dabei immer auch eine "PPK ID" konfiguriert werden. Diese muss auf beiden Seiten identisch hinterlegt werden und eindeutig für die Verbindung sein. Jede Verbindung sollte mit einem eigenen und nicht mehrfach verwendeten PPK gesichert werden.
Der PPK selbst sollte per Zufallsgenerator erzeugt werden um eine ausreichende Entropie zu besitzen. Hierfür bietet sich z.B. die entsprechende Schaltfläche in der Oberfläche des Intra2net Systems an.
Der PPK darf nicht bei der Konfiguration von unautorisierten Personen abgefangen oder aufgezeichnet werden können. Achten Sie daher darauf, ihn ausschließlich über ausreichend gesicherte Kanäle zu übertragen und verwenden z.B. keine unverschlüsselte E-Mail oder Telefon.