Ein tieferer Einblick in die Unterstützung von Post-Quanten-Kryptografie in der Control Plane von Red Hat OpenShift 4.20

Das Zeitalter des Quantencomputings steht vor der Tür. Mit seiner immensen Rechenleistung ist es eine erhebliche Bedrohung für die kryptografischen Grundlagen unserer digitalen Welt. In diesem Artikel untersuchen wir die neue Unterstützung von Post-Quanten-Kryptografie (PQC) in Red Hat OpenShift 4.20. Der Schwerpunkt liegt auf der Verbesserung der Kernkomponenten der Kubernetes Control Plane: API-Server, Kubelet, Scheduler und Controller Manager. Es fehlt etcd, das eine ältere Version von Go verwendet.

Die Bedrohung durch Quantencomputer

Die heute weit verbreiteten Public Key-Kryptografiesysteme wie RSA und ECC (Electronic Cure Cryptography) bilden die Basis für eine sichere Online-Kommunikation. Diese Systeme sind jedoch anfällig für Angriffe von großen Quantencomputern, die die mathematischen Probleme, die diesen Algorithmen zugrunde liegen, mit alarmierender Geschwindigkeit lösen können. Dies hat zu Angriffen geführt, bei denen Angreifende heute verschlüsselten Datenverkehr aufzeichnen, um ihn in Zukunft zu entschlüsseln, sobald sie Zugang zu einem leistungsstarken Quantencomputer haben. Die gleiche Herausforderung besteht auch bei Daten im Ruhezustand, wenn es Angreifenden gelingt, jetzt eine Kopie zu erstellen, um sie später zu entschlüsseln.

Um dieser Bedrohung zu begegnen, hat sich der PQC-Bereich entwickelt, in dem neue kryptografische Algorithmen entwickelt werden, die gegen Angriffe von klassischen und Quantencomputern resistent sind.

PQC in Kubernetes und OpenShift

Red Hat OpenShift ist eine von der Cloud Native Computing Foundation (CNCF) zertifizierte Distribution von Kubernetes, und Kubernetes ist in der Programmiersprache Go geschrieben. Der Weg zur Unterstützung von PQC in OpenShift beginnt daher mit Go.

Das Release Go 1.24 stellte einen wichtigen Meilenstein dar, denn hier wurde die Unterstützung des hybriden Schlüsselaustauschmechanismus X25519MLKEM768 eingeführt. X25519MLKEM768 ist ein hybrider Schlüsselaustausch, bei dem das klassische X25519 (Diffie-Hellman mit Ellipsenkurve) mit ML-KEM-768 (dem Post-Quanten-Algorithmus) kombiniert wird. Das endgültige gemeinsame Secret wird aus beiden Mechanismen kombiniert abgeleitet. Reines ML-KEM basiert vollständig auf gitterbasierter Kryptografie für die Quantenwiderstandsfähigkeit. X25519MLKEM768 bietet Ihnen die Quantenwiderstandsfähigkeit von ML-KEM und die klassische Sicherheit von X25519 gleichzeitig.

Der hybride Ansatz ist derzeit wirklich robuster. ML-KEM wurde erst im August 2024 standardisiert, was bedeutet, dass es in kryptografischer Hinsicht als „neu“ gilt. Wenn jemand einen unerwarteten klassischen Angriff auf die Gitterannahmen von ML-KEM entdeckt (keine Quanten-, sondern normale Kryptoanalyse), würden reine ML-KEM-Bereitstellungen unterbrochen. Mit dem Hybrid hat immer noch X25519 die Führung.

Das resultierende gemeinsame Secret für eine TLS-Session (Transport Layer Security) bietet die erwartete Sicherheitsstufe, solange mindestens einer der Komponentenalgorithmen ungebrochen bleibt. Dies bietet eine robuste und zukunftskompatible Möglichkeit, PQC in das IT-Ökosystem einzuführen.

Anwendung von PQC auf die OpenShift Control Plane

Bei der Unterstützung von PQC in OpenShift 4.20 geht es nicht um die Konfiguration spezifischer PQC-Flags für jede Kubernetes-Komponente. Stattdessen geht es um die Stärke der TLS-Kommunikation zwischen diesen Komponenten, die durch die zugrunde liegende Version von Go und seine kryptografischen Libraries ermöglicht wird.

So verbessert die Unterstützung von PQC die Sicherheit der Kommunikation zwischen den Kernkomponenten von OpenShift (der etcd-Status wird unten separat erläutert):

• API-Server: Als zentraler Hub der Kubernetes Control Plane ist die gesamte Kommunikation zum und vom API-Server ein kritischer Sicherheitspunkt. Mit ML-KEM-fähigem TLS ist die Control Plane-Kommunikation vor Angriffen geschützt, die heute verschlüsselten Datenverkehr aufzeichnen und planen, diesen in der Zukunft zu entschlüsseln.
• Kubelet: Das Kubelet, das auf den einzelnen Knoten ausgeführt wird, kommuniziert mit dem API-Server, um Knotenstatus-Updates bereitzustellen und Pod-Spezifikationen zu empfangen. Diese Kommunikation umfasst nun einen hybriden PQC-Schlüsselaustausch für mehr Sicherheit, mit dem die Integrität und Vertraulichkeit dieses Links verifiziert werden kann.
• Scheduler und Controller-Manager: Der Scheduler und der Controller Manager interagieren kontinuierlich mit dem API-Server, um Planungsentscheidungen zu treffen und den Status des Clusters zu verwalten. Diese Interaktionen werden ebenfalls durch das ML-KEM-fähige TLS geschützt, um die Sicherheit der Logik und der Abläufe zu erhöhen, die Ihre Anwendungen am Laufen halten.

Die Perspektive von Red Hat

Obwohl viele Branchenvorschriften PQC erst 2035 vorschreiben, arbeiten wir aktiv an der Umstellung auf PQC. In dem aktuellen Artikel „So bereiten Sie Ihre Organisation auf die Quantenzukunft vor“ betonen wir, wie wichtig es ist, jetzt mit PQC zu beginnen. Darüber hinaus ist die Arbeit zur Integration von PQC in Red Hat Enterprise Linux (RHEL) ein starker Indikator für die Richtung von OpenShift. Die Integration von PQC-Funktionen in OpenShift 4.20 ist ein wichtiger Schritt nach vorn.

Die Go-Versionsinkongruenz

Eine wichtige Überlegung für Administrationsteams ist die Gefahr, dass verschiedene Komponenten in einem Cluster nicht übereinstimmen. Wenn beispielsweise ein mit einer ML-KEM-fähigen Go-Version erstellter kubectl-Client mit einem älteren API-Server kommuniziert, kann der TLS-Handshake unbemerkt auf einen klassischen kryptografischen Algorithmus heruntergestuft werden. Dies würde zum Verlust des PQC-Schutzes ohne explizite Warnung führen. Überprüfen Sie daher, ob die verschiedenen Komponenten in Ihrer OpenShift-Umgebung kompatible Versionen ausführen, die PQC unterstützen.

Wie sieht es mit etcd aus?

Während die Kernkomponenten der Control Plane von ML-KEM-fähigem TLS profitieren, ist die Entwicklung von etcd anders. Dies liegt an der besonderen Rolle und Entwicklungsphilosophie von etcd. Als endgültige Source of Truth für den gesamten Cluster sind die absoluten Prioritäten von etcd Stabilität, Datenintegrität und Performance. Das etcd-Projekt behält im Vergleich zu Kubernetes absichtlich einen konservativeren Go-Versionierungszeitplan bei. Während das Kubernetes-Projekt häufig das aktuellste Go-Release einführt, um neue Funktionen und Performance-Verbesserungen schnell nutzen zu können, legt das etcd-Team Wert auf Stabilität und bleibt für die stabilen Releases bei älteren, erprobten Go-Versionen. Diese gewollte Verzögerung hilft der breiteren Community dabei, potenzielle Probleme in einer neuen Go-Runtime gründlich zu prüfen, bevor sie in eine so kritische Komponente wie etcd eingeführt wird.

Das Fehlen einer sofortigen Unterstützung von PQC ist kein Versehen, sondern eine direkte Folge dieses stabilitätsorientierten Ansatzes. Bevor die in Go 1.24 eingeführten PQC-Algorithmen in etcd offiziell unterstützt werden können, muss diese Go-Version zunächst in die stabilen Release-Branches von etcd übernommen werden, die derzeit noch Go 1.23 verwenden. Dieser Prozess beinhaltet eine umfassende Validierung, um sicherzustellen, dass es keine negativen Auswirkungen auf das Pilot-Konsensprotokoll, die I/O-Latenz oder die Wiederherstellungsvorgänge gibt. Achten Sie auf die Unterstützung von quantensicheren Anwendungen in etcd in einer zukünftigen Version.

Die Zukunft

Die Integration von PQC in OpenShift 4.20 ist ein Beweis für den proaktiven Ansatz, den Red Hat bei der Entwicklung einer quantenfähigen Zukunft für cloudnatives Computing verfolgt. Während sich die PQC für digitale Signaturen und Zertifikate noch in der Anfangsphase befinden, ist die Implementierung des hybriden Schlüsselaustauschs in TLS ein wichtiger erster Schritt.