Kryptografie-Policy 2026: Cipher Suites, DH Groups und PFS Empfehlungen

Eine belastbare Kryptografie-Policy 2026 ist mehr als eine Liste „starker Algorithmen“. Sie ist ein verbindlicher Standard für Cipher Suites, DH Groups und PFS-Vorgaben (Perfect Forward Secrecy), der über Teams, Plattformen und Produkte hinweg konsistent funktioniert – inklusive klarer Migrationspfade für Legacy und einer Strategie für Krypto-Agilität. In der Praxis scheitert Kryptografie selten an „zu schwachen Bits“, sondern an heterogenen Einstellungen, inkonsistenten Defaults, unkontrollierten Fallbacks (z. B. TLS 1.2 mit CBC), nicht überprüfter Interoperabilität oder fehlender Rotation/Revocation in der PKI. Gleichzeitig haben sich die Erwartungen an 2026 verändert: TLS 1.3 ist in vielen Richtlinien verpflichtender Standard, IKEv2 ist der Default für IPsec, und Organisationen müssen parallel die Post-Quantum-Transition zumindest planen, weil Standards und Roadmaps bereits konkretisiert wurden. NIST und BSI veröffentlichen dazu konkrete Leitlinien, die sich als Grundlage für eine unternehmensweite Baseline eignen, etwa NIST SP 800-52r2 zu TLS sowie die aktuelle BSI TR-02102-2 (TLS). Dieser Artikel liefert eine praxisnahe Policy 2026: welche Cipher Suites Sie standardisieren sollten, welche DH-Gruppen (FFDHE/ECP) sinnvoll sind, wie Sie PFS konsequent umsetzen, welche Legacy-Mechanismen Sie verbieten sollten und wie Sie das Ganze so formulieren, dass Betrieb, Audit und Interoperabilität nicht leiden.

Zielbild 2026: Krypto-Agilität und wenige, getestete Standards

Eine gute Kryptografie-Policy ist bewusst „schmal“: Sie erlaubt wenige, getestete Optionen, statt jede theoretisch sichere Kombination freizugeben. Das reduziert Fehlkonfigurationen und macht Testing sowie Troubleshooting realistisch. Gleichzeitig braucht 2026 eine klare Krypto-Agilität, weil neue Anforderungen (z. B. Post-Quantum-Algorithmen) in den nächsten Jahren in Protokollprofile einfließen. Für TLS ist TLS 1.3 als moderner Standard in RFC 8446 spezifiziert. Für die Übergänge und Mindeststärken liefert NIST SP 800-131A Rev. 2 konkrete Transition-Guidance.

• Standardisieren: Pro Protokoll (TLS, IPsec/IKE) eine bevorzugte Konfiguration („MUST“), eine begrenzte Kompatibilitätskonfiguration („SHOULD“) und wenige befristete Legacy-Ausnahmen („MAY, timeboxed“).
• Verbieten: Unsichere oder unnötige Optionen explizit (z. B. TLS 1.0/1.1, RSA Key Exchange, 3DES, MD5, SHA-1 für Signaturen).
• Messbar machen: Policy muss durch Scanner, CI/CD-Checks oder Konfig-Audits verifizierbar sein (Drift Detection).
• PFS als Default: Forward Secrecy ist nicht optional; sie reduziert Schaden bei späterem Key-Leak.

Policy-Teil 1: TLS 1.3 Cipher Suites 2026

TLS 1.3 vereinfacht Cipher-Suite-Auswahl deutlich: Die Suites umfassen nur noch AEAD + Hash, während Key Exchange und Signaturen separat verhandelt werden. Das macht eine Policy einfacher und reduziert Legacy-Fallen. TLS 1.3 ist in RFC 8446 definiert. In europäischen Profilen werden für TLS 1.3 häufig die AES-GCM- und AES-CCM-Suites als Baseline geführt; zugleich wird darauf hingewiesen, dass CHACHA20 in TLS 1.3 genutzt werden kann. Ein Beispiel ist das EU-Profil „Common Services Network and Transport Security“, das sich auf BSI TR-02102-2 und NIST SP 800-52r2 bezieht und CHACHA20 als optional benennt (EU CSN Transport Security Profil).

• TLS 1.3 MUST: TLS_AES_128_GCM_SHA256
• TLS 1.3 SHOULD: TLS_AES_256_GCM_SHA384
• TLS 1.3 MAY: TLS_CHACHA20_POLY1305_SHA256 (insbesondere für Clients ohne AES-Hardwarebeschleunigung; in TLS 1.3 standardisiert) (RFC 8446)

Policy-Teil 2: TLS 1.2 als Kompatibilitätsmodus (streng begrenzen)

Auch 2026 existieren Umgebungen, in denen TLS 1.2 für Interoperabilität benötigt wird. Die Policy sollte TLS 1.2 nicht pauschal verbieten, aber klar begrenzen: nur ECDHE (PFS), nur AEAD (GCM/CCM), kein RSA Key Exchange, keine CBC-Suites, keine Altlasten. Als Orientierung dient NIST SP 800-52r2, das TLS 1.2 mit FIPS-basierten Suites weiterhin fordert, aber TLS 1.3 als Pflichtsupport hervorhebt. Zusätzlich liefert die BSI TR-02102-2 konkrete TLS-Empfehlungen.

• TLS 1.2 MUST: ECDHE + AEAD (AES-GCM) + SHA-256/384 (je nach Suite), keine statischen Key Exchanges
• TLS 1.2 MUST NOT: RSA Key Exchange, DHE mit nicht-vetted Gruppen, CBC-Suites, RC4, 3DES, Export-Suites
• TLS 1.2 SHOULD: ECDSA-Zertifikate oder RSA mit ausreichender Schlüssellänge gemäß Unternehmens-Standard; Signaturen ohne SHA-1

DH Groups 2026: ECDHE als Default, FFDHE als kontrollierte Option

In der Praxis entscheidet die Wahl der Diffie-Hellman-Gruppe (DH Group) über Sicherheit, Performance und Interoperabilität. Für TLS (und oft auch für andere Protokolle) gilt: ECDHE ist der Regelfall; FFDHE ist sinnvoll als konservative Option oder für Umgebungen mit ECC-Restriktionen, aber nur mit vetted Gruppen. Für finite field Gruppen liefert RFC 7919 standardisierte, vordefinierte FFDHE-Parameter (z. B. 2048/3072/4096/6144/8192), die Interoperabilität und Sicherheit verbessern.

• Default: ECDHE mit etablierten Kurven (Policy muss konkret benennen, was in Ihrer Landschaft unterstützt wird)
• FFDHE MUST (wenn FFDHE): Nur vordefinierte Gruppen aus RFC 7919, keine „custom DH params“ ohne Governance
• FFDHE Minimum: 2048 Bit als Untergrenze; für höhere Sicherheitsanforderungen 3072+ (risikobasiert, Performance testen)

DH Groups für IKEv2/IPsec: MODP vs. ECP und die Praxis 2026

Für IPsec/IKE sind DH-Gruppen zentral, weil sie den PFS-Teil (Diffie-Hellman) für IKE SAs und Child SAs bestimmen. IKEv2 ist in RFC 7296 spezifiziert. Für elliptische Kurven-Gruppen in IKE/IKEv2 sind RFCs wie RFC 5903 relevant, die ECP-Gruppen (NIST-aligned) für IKE/IKEv2 beschreibt. In einer 2026-Policy sollten Sie definieren, welche DH Groups zulässig sind, und zwar getrennt nach:

• IKE SA (Initial Exchange): Gruppe für die IKE-Verhandlung
• Child SA (ESP): Gruppe für PFS auf dem Datenkanal

• IKEv2 MUST: PFS für Child SAs aktivieren (kein „PFS off“ als Standard)
• DH Group SHOULD: ECP-Gruppen nach RFC 5903 (wo interoperabel verfügbar), sonst MODP mit ausreichender Bitlänge
• DH Group MUST NOT: Veraltete, schwache Gruppen (z. B. sehr kleine MODP-Gruppen), sowie „unkontrollierte“ custom Gruppen ohne Review

PFS 2026: Wann es zwingend ist und was „richtiges PFS“ bedeutet

Perfect Forward Secrecy bedeutet, dass ein später kompromittierter Langzeitschlüssel (z. B. RSA/ECDSA Private Key, PSK, Zertifikat) nicht automatisch die Entschlüsselung historischer Sessions ermöglicht. In Zeiten von „Harvest now, decrypt later“ ist das nicht nur Theorie, sondern ein handfestes Risiko, insbesondere für lang schützenswerte Daten. Für TLS ist PFS in TLS 1.3 implizit durch (EC)DHE-Mechanik vorgesehen (RFC 8446). Für IPsec ist PFS eine bewusste Konfiguration: DH für Child SAs aktivieren.

• TLS 1.3: PFS ist Standard, wenn TLS 1.3 korrekt genutzt wird
• TLS 1.2: Nur ECDHE/DHE erlauben, RSA Key Exchange verbieten (sonst kein PFS)
• IPsec/IKE: PFS für Child SAs als Default; Lifetimes so wählen, dass Rekey stabil bleibt und Schlüssel nicht unnötig lange leben

Cipher-Suite-Policy für IPsec: ESP-Algorithmen und Integrität

Für IPsec ist nicht „Cipher Suite“ im TLS-Sinn relevant, sondern die Auswahl von ESP-Transformen (Verschlüsselung/Integrität) und IKE-Transformen (PRF, Integrität, DH). ESP ist in RFC 4303 beschrieben. Eine 2026-Baseline sollte AEAD bevorzugen (z. B. AES-GCM), weil damit Verschlüsselung und Integrität zusammengefasst werden und Fehlkonfigurationen reduziert werden.

• ESP SHOULD: AEAD (z. B. AES-GCM) für Datenkanal
• ESP MUST NOT: Legacy-Kombinationen mit schwachen Hashes oder veralteten Ciphers (z. B. 3DES)
• IKE PRF/Integrity: Moderne Hash-basierte PRFs/Integritätsverfahren; SHA-1 vermeiden

Signaturen 2026: RSA und ECDSA pragmatisch standardisieren

In der Praxis ist die Signaturalgorithmik oft der Engpass für Interoperabilität. Eine Policy 2026 sollte daher nicht „alles“ erlauben, sondern wenige Profile definieren (z. B. ein Standardprofil und ein Kompatibilitätsprofil). NIST gibt Transition-Guidance in SP 800-131A Rev. 2.

• Empfehlung: ECDSA für neue Deployments, wenn Tooling und PKI sauber unterstützt werden
• Kompatibilität: RSA weiterhin möglich, aber nur mit ausreichender Schlüssellänge und ohne SHA-1
• Policy-Hygiene: Zertifikatsprofile strikt trennen (Server, Client, VPN-Gateway, Admin-Bastion), um Missbrauch zu reduzieren (RFC 5280)

BSI- und NIST-Bezug: Policy textlich so formulieren, dass Audits sie „lesen“ können

Viele Kryptopolicies scheitern daran, dass sie zu technisch oder zu vage sind. Für 2026 ist ein guter Ansatz, Ihre Policy an anerkannten Leitlinien auszurichten und diese als „Normbasis“ zu benennen, etwa:

• TLS: NIST SP 800-52r2 und BSI TR-02102-2
• Algorithm Transition: NIST SP 800-131A Rev. 2
• Protokollspezifikationen: RFC 8446 (TLS 1.3), RFC 7296 (IKEv2), RFC 7919 (FFDHE), RFC 5903 (ECP-Gruppen)

Das schafft E-E-A-T für die Policy: Sie ist nicht „Meinung“, sondern nachvollziehbar an Standardwerken orientiert.

Post-Quantum Reality Check 2026: Nicht „alles umstellen“, aber planen

Auch wenn klassische Kryptografie 2026 weiterhin der Standard ist, müssen Organisationen Krypto-Agilität für Post-Quantum vorbereiten. NIST hat 2024 erste Post-Quantum-Standards finalisiert (ML-KEM, ML-DSA, SLH-DSA) und dies öffentlich kommuniziert (NIST News zu finalen PQC-Standards). Zusätzlich hat die US-Defense-Seite 2025 ein Dokument zur CNSA 2.0 Algorithm Suite veröffentlicht, inklusive Transition-Timeline (CNSA 2.0 Algorithms (PDF)).

• Policy 2026 SHOULD: „Crypto Agility“ als Pflicht definieren (Austauschbarkeit von Krypto-Parametern ohne Code-Rewrite)
• Policy 2026 SHOULD: Roadmap für PQC-Piloten (z. B. TLS/IPsec-Profil-Entwicklung, sobald Standards/Produkte stabil verfügbar sind)
• Policy 2026 MUST: Vermeiden, dass heute neue Systeme mit schwer austauschbaren Legacy-Algorithmen ausgerollt werden

Konkrete Policy-Formulierungen 2026: „MUST/SHOULD/MAY“ für die Praxis

Damit eine Kryptografie-Policy im Betrieb funktioniert, braucht sie klare, prüfbare Sätze. Ein praxistauglicher Policy-Kern kann so aussehen:

• TLS Version: TLS 1.3 MUST; TLS 1.2 MAY nur im Kompatibilitätsmodus und nur mit ECDHE + AEAD; TLS 1.0/1.1 MUST NOT.
• TLS 1.3 Suites: TLS_AES_128_GCM_SHA256 MUST; TLS_AES_256_GCM_SHA384 SHOULD; TLS_CHACHA20_POLY1305_SHA256 MAY gemäß RFC 8446.
• TLS 1.2 Key Exchange: RSA Key Exchange MUST NOT; nur (EC)DHE.
• DH Groups: ECDHE bevorzugt; FFDHE nur mit Gruppen aus RFC 7919.
• IKE: IKEv2 MUST gemäß RFC 7296; IKEv1 nur befristet und begründet.
• PFS: PFS MUST für IPsec Child SAs; TLS 1.2 nur mit ECDHE/DHE zulässig.
• PKI: Zertifikatprofile nach RFC 5280; Revocation-Strategie (OCSP/CRL) verbindlich, OCSP beschrieben in RFC 6960.

Interoperabilität und Legacy: Ausnahmen ohne „Policy-Drift“

2026 wird es weiterhin Legacy geben: alte Appliances, Partner, spezialisierte Clients. Eine gute Policy macht Ausnahmen möglich, aber kontrolliert. Das verhindert, dass „Legacy“ zur Dauerausrede wird.

• Timeboxing: Jede Legacy-Ausnahme hat ein Enddatum und einen Migrationsplan.
• Isolation: Legacy-Profile in separaten Zonen/VRFs, damit die schwächere Kryptografie nicht den gesamten Standard verwässert.
• Monitoring: Telemetrie, wie oft Legacy tatsächlich genutzt wird (Daten für Decommission).
• Dokumentation: Welche Systeme brauchen was – und warum?

Operationalisierung: Policy ohne Messbarkeit ist nur Text

Eine Kryptografie-Policy 2026 muss operationalisiert werden. Das bedeutet: technische Prüfungen, wiederholbare Templates und klare Verantwortlichkeiten. Für TLS können externe Testtools oder interne Scanner messen, ob TLS 1.3 aktiv ist und welche Suites verhandelt werden; für VPN/IPsec können Konfig-Audits (z. B. IKE-Proposals, DH-Gruppen, Lifetimes) automatisiert geprüft werden.

• Golden Templates: Standardkonfigurationen pro Plattform (VPN Gateway, Reverse Proxy, API Gateway)
• Compliance Checks: Regelmäßige Prüfungen auf Protokollversionen, Cipher Suites, DH Groups
• Change Control: Kryptografieänderungen sind Security-Changes (Canary, Rollback, Wartungsfenster)
• Crypto-Inventar: Wo wird welche Kryptografie eingesetzt? Ohne Inventar keine Migration.

• BSI TR-02102-2: Empfehlungen für TLS (aktuelle Version)
• NIST SP 800-52r2: Guidelines for TLS
• NIST SP 800-131A Rev. 2: Algorithm Transition Guidance
• RFC 8446: TLS 1.3
• RFC 7919: FFDHE Gruppen
• RFC 5903: ECP-Gruppen für IKE/IKEv2
• NIST: Finalisierte PQC-Standards (2024)
• CNSA 2.0 Algorithms (PDF, 2025)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.