Grundlagen: Elliptische Kurven in Hinsicht auf ihre Verwendung in der Public Key Infrastruktur

Mit Windows Vista und Windows Server 2008 wurde die Cryptography API: Next Generation (CNG) in die Windows Systeme eingeführt.

Unter diesem Begriff wird eine Sammlung moderner kryptographischen Funktionen verstanden. Unter Anderem ermöglicht die CNG die Verwendung von Zertifikaten, welche auf elliptischen Kurven (auch Elliptic Curve Cryptography, ECC genannt) basierende Schlüssel verwenden, mit der Microsoft Zertifizierungsstelle und dem Windows Betriebssystem.

Gründe für die Verwendung von elliptischen Kurven

Während der ebenfalls mit der CNG implementierte SHA2 Hashalgorithmus schon lange zum de-facto Standard wurde, und sie sich auch auch bei Webseiten zunehmend durchsetzen, werden elliptische Kurven in Unternehmens-Public Key Infrastukturen bisher noch eher verhalten bis überhaupt nicht adaptiert.

Dabei gibt es jedoch gute Gründe für ihre Verwendung und baldige Adaption:

• Bei gleicher kryptographischer Stärke benötigen sie deutlich weniger Rechenleistung im Vergleich zu RSA-Schlüsseln. Dies kann sowohl beim Einsatz von leistungsschwachen Embedded Geräten (Stichwörter Mikrocontroller und Internet of Things) von großer Bedeutung sein, aber auch ganz alltagsrelevanten Einfluss haben. So steht mittlerweile fest, dass TLS/SSL Handshakes deutlich schneller ablaufen, sich somit die gefühlte Ladezeit von Webseiten dadurch verringert.
• Bei RSA steigt die zu ECC vergleichbare Sicherheit nur mit exponentiell steigender Schlüssellänge. Die aktuell immer noch als sinnvolles Maximum angesehenen 4096 Bit bringen im Verhältnis zu 2048 Bit nur ein geringes Plus an Sicherheit. Für eine zur symmetrischen Verschlüsselung von 256 Bit vergleichbare Sicherheit bräuchte man bereits 15.360 Bit große RSA Schlüssel, d.h. mit zunehmendem Bedarf an Schlüsselstärke wird RSA in absehbarer Zeit immer ineffizienter rechenintensiver in der Anwendung.
• Auch technische Gründe können für die Verwendung von ECC-Schlüssel sprechen. So spezifiziert der Trusted Platform Module (TPM) 2.0 Standard maximal 2048 Bit für RSA Schlüssel, erlaubt jedoch ECC-Schlüssel bis 384 Bit. Somit kann – wenn Schlüssel mit einem TPM geschützt werden sollen – eine Erhöhung der kryptographischen Stärke nur mit ECC-Schlüssel erreicht werden.

Nachfolgend ein Vergleich der kryptographischen Stärke von RSA und ECC Schlüsseln im Vergleich zu einem symmetrischen Verfahren wie AES.

Schlüssellänge (RSA)	Schlüssellänge (ECC)	Vergleichbare symmetische Schlüssellänge
1024	160	80
2048	224	112
3072	245	128
7680	384	192
15360	512 (521)	256

Mit dem Vergleich symmetischer und asymmetrischer Verfahren ist gemeint, dass die in der Tabelle als vergleichbar ausgewiesenen Schlüssellängen eine vergleichbare theoretische Resistenz gegenüber Brute Force Angriffen, also dem Durchprobieren aller Kombinationen, aufweisen.

Nachfolgend ein Vergleich des benötigten Rechenaufwandes zwischen RSA und ECC.

symmetrische Bitlänge	Rechenaufwand im Vergleich RSA vs ECC
80	3 : 1
112	6 : 1
128	10 : 1
192	32 : 1
256	64 : 1

Sicherheit von ECC und den verwendeten Kurven

Auf elliptischen Kurven basierende Schlüssel sind per se nicht "sicherer" oder "unsicherer" als auf RSA basierende Schlüssel, solange eine vergleichbare Schlüsselstärke (siehe oben) gewählt wird.

While at current security levels elliptic curves do not offer significant benefits over existing public key algorithms, as one scales security upwards over time to meet the evolving threat posed by eavesdroppers and hackers with access to greater computing resources, elliptic curves begin to offer dramatic savings over the old, first generation techniques.

The Case for Elliptic Curve Cryptography (National Security Agency, Archivlink)

Die verwendeten Kurven sind ebenfalls nicht per se "sicherer" oder "unsicherer" als andere, aber die Implementierungen in Software können sich unterscheiden: Manche Kurven sind einfacher, andere nur mit größerem Aufwand und höherer Anfälligkeit für Fehler sicher zu implementieren.

Standarisierung

NSA Suite B

Die in der von der National Security Agency (NSA) spezifizierte "Suite B"enthaltenen Algorithmen können als der kleinste gemeinsame Nenner zwischen PKI-Implementierungen, die ECC unterstützen, angesehen werden.

Zweck	Algorithmus	Stufe "Secret"	Stufe "Top Secret"
Verschlüsselung	Advanced Encryption Standard (AES)	AES-128	AES-256
Digitale Signatur	Elliptic Curve Digital Signature Algorithm (ECDSA)	ECDSA_P256	ECDSA_P384
Schlüsselaustausch	Elliptic Curve Diffie-Hellman (ECDH)	ECDH_P256	ECDH_P384
Prüfsummen	Secure Hash Algorithm (SHA)	SHA256	SHA384

Die Microsoft CNG hat die in der Suite B definierten Algorithmen implementiert. Das heißt aber im Umkehrschluss nicht, dass alle neu implementierten Algorithmen Teil der NSA Suite B sind.

Die secp521r1 Kurve (verwendet von ECDSA_P521 und ECDH_P521) ist somit nicht Teil der NSA Suite B. Das Gleiche gilt auch für den SHA512 Hashalgorithmus, siehe RFC 5759.

Wie man erkennen kann, strebt die NSA (mit Ausnahme beim AES Algorithmus) mit der Suite B eine maximale "Bitness" von 192 Bit an.

Commercial National Security Algorithm Suite" (CNSA)

Mittlerweile wurde die Suite B durch die "Commercial National Security Algorithm Suite" (CNSA) abgelöst. Diese umfasst auch wieder RSA mit entsprechend großen Schlüsseln (3072 Bit für Schutzklasse "Top Secret").

Die NSA distanziert sich mittlerweile aber auch aufgrund der aktuellen Fortschritte im Bereich der Quantenkryptographie von Bestrebungen, die Suite B bzw. CNSA einzusetzen und auf in absehbarer Zeit verfügbare quantenresistente Algorithmen zu setzen:

For those partners and vendors that have not yet made the transition to Suite B algorithms, we recommend not making a significant expenditure to do so at this point but instead to prepare for the upcoming quantum resistant algorithm transition.

Cryptography Today, National Security Agency (NSA)

Wir werden den großflächigen Einsatz elliptischer Kurven im Bereich von Unternehmens-PKIen somit vermutlich nicht mehr erleben.

Elliptische Kurven in Windows und Active Directory Certificate Services

Ein gravierender Faktor für den erfolgreichen Einsatz bestimmter Kurven ist die Unterstützung durch gängige Betriebssysteme und Kryptobibliotheken.

Für digitale Zertifikate sind mit den Microsoft Active Directory Certificate Services und dem Windows Betriebssystem folgende Algorithmen verwendbar:

Bezeichnung	Algorithmus	Standards
ECDH_P256 ECDH_P384 ECDH_P521	Elliptic Curve Diffie-Hellman key exchange algorithm	NIST SP800-56A
ECDSA_P256 ECDSA_P384 ECDSA_P521	Elliptic Curve Digital Signature Algorithm	NIST FIPS 186-2 ANSI X9.62

Die Algorithmen verwenden jeweils die NIST Kurven P256 (secp256r1), P384 (secp384r1) oder P521 (secp521r1). Siehe auch RFCs 3279 und 5480.

Zu beachten ist, dass jede Variante ein eigenständiger Algorithmus ist, d.h. etwas wie "RSA mit Schlüssellänge X" gibt es hier nicht. Vielmehr "ECDSA bzw. ECDH mit Kurve X".

Unterstützung ist nicht (…einmal im Windows-Ökosystem) überall gegeben

Obwohl Microsoft die elliptischen Kurven seit Windows Vista implementiert hat, sind sie nicht pauschal überall einsetzbar. Ob sie in der Windows-Welt verwendbar sind, hängt (neben der Endanwendung, die die Zertifikate verarbeiten soll) auch davon ab, ob die Schlüsselspeicherung möglich ist.

Einige Beispiele:

• Der Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) verwendet noch Cryptographic Service Provider (CSP), welche keine elliptischen Kurven unterstützen, für seine Registration Authority Zertifikate
• Das gleiche gilt für den NDES Connector für Microsoft Intune.
• Eine Verwendung von elliptischen Kurven in Verbindung mit einem Trusted Platform Module (TPM) ist erst seit Windows 10 21H2 und Windows 11 möglich.

Trennung zwischen Signatur- und Schlüsselaustauschverfahren

Eine interessante Besonderheit beim Einsatz von ECC-Schlüsseln ist der Umstand, dass keine hybriden Schlüssel (Signatur und Verschlüsselung) wie bei RSA verwendet werden können.

With Suite B, the ECC key for a given certificate can only be used for either signature or encryption, but not both. Be sure not to select the option for both Signature and Encryption. If both signature and encryption are selected, then only ECDH algorithms will be available and the key will only be valid for encryption.

Microsoft, Suite B PKI in Windows Server 2008 (Archivlink)

Die Auswahl des Schlüsselalgorithmus würde für gängige Anwendungsfälle also in etwa wie folgt aussehen:

Use Case	Algorithmenfamilie
Webserver	ECDSA
Codesignatur	ECDSA
KDC Authentifizierung	ECDSA
E-Mail Signatur	ECDSA
E-Mail Verschlüsselung	ECDH
Private Key Archivierung	ECDH
Key Recovery Agent	ECDH

Folgerichtig müsste man bei Umstellung von S/MIME von RSA auf elliptische Kurven nun zwei Zertifikate an die Benutzer herausgeben – eines zum signieren, eines zum Verschlüsseln (sofern man bisher nur eines für beide Zwecke verwendet hat).

Einschätzung zur Praxistauglichkeit

Stand heute (2022) verwenden die meisten Unternehmens-PKIen weiterhin den RSA Algorithmus für ihre Zertifizierungsstellen- und Endzertifikate. In den kommenden Jahren steht zumindest die Erhöhung der Schlüssellänge auf dem Plan.

In einigen Fällen, wie etwa wenn man private Schlüssel mit dem Trusted Platform Modul (TPM) des Endgerätes schützen möchte, wird man nicht darum herumkommen, auf elliptischen Kurven basierende Schlüssel einzusetzen, wenn man deren kryptographische Stärke erhöhen möchte (da TPM üblicherweise höchstens 2048 Bit starke RSA Schlüssel schützen können).

Auf der gegenüberliegenden Seite gibt es aber immer noch die Unsicherheit, ob alle an der PKI teilnehmenden Systeme mit auf elliptischen Kurven basierenden Schlüsseln umgehen können. Daher ist es vorerst illusorisch, mit einer rein auf diesen Schlüsselalgorithmen aufbauenden PKI arbeiten zu können.

Für Zertifizierungsstellen-Zertifikate wird man also auf absehbare Zeit weiterhin große RSA Schlüssel verwenden müssen, wenn man sich nicht den Luxus von zwei produktiven Zertifizierungsstellen-Hierarchien (einmal mit RSA-Schlüsseln, einmal mit ECC Schlüsseln) und den damit einhergehenden Nachteilen leisten möchte.

Auch die Tatsache, dass Standardisierungsbehörden wie die NSA mittlerweile von Investitionen in die Suite B Algorithmen abraten, unterstreicht diese These.

Möchte oder muss man sie dennoch einsetzen, ist es dennoch ratsam, sich an der Suite B zu orientieren, um größtmögliche Kompatibilität zu erreichen. Algorithmen, die nicht in der Suite B enthalten sind (namentlich SHA512 und die secp521r1 Kurve) sollten somit eher nicht eingesetzt werden.

Weiterführende Links

• Grundlagen: Cryptographic Service Provider (CSP) und Key Storage Provider (KSP)
• Grundlagen: Schlüsselalgorithmen, Signaturalgorithmen und Signaturhashalgorithmen
• Die Beantragung von Zertifikaten mit auf elliptischen Kurven basierenden Schlüsseln schlägt fehl, wenn der Microsoft Platform Crypto Provider verwendet wird
• Liste der Use Cases für Zertifikate, die bestimmte Cryptographic Service Provider (CSP) oder Key Storage Provider (KSP) benötigen

Externe Quellen

• Cryptography API: Next Generation (Microsoft)
• Cryptography API: Next Generation (Wikipedia)
• CNG Named Elliptic Curves (Microsoft)
• CNG Algorithm Identifiers (Microsoft)
• CNG Key Storage Providers (Microsoft)
• Was man über Kryptografie wissen sollte (Heise)
• Why is the P-521 elliptic curve not in Suite B if AES-256 is?
• ECC Compatibility (GlobalSign)
• Issue 478225: Chrome TLS no longer supports secp521r1 in elliptic curve certificates (Chromium Projekt)
• Stop advertising/support P-521 curve in Suite-B-only mode (Mozilla)
• SP 800-56A Rev. 3 / Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography (National Institute of Standards and Technology)
• FIPS PUB 186-4 / Digital Signature Standard (DSS) (National Institute of Standards and Technology)
• ANSI X9.62 / Public Key Cryptography for the Financial Services Industry: the Elliptic Curve Digital Signature Algorithm (ECDSA) (American National Standards Institute)
• The Case for Elliptic Curve Cryptography (National Security Agency, Archivlink)
• RFC 6318 – Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) (Internet Engineering Task Force)
• RFC 5759 – Suite B Certificate and Certificate Revocation List (CRL) Profile (Internet Engineering Task Force)
• RFC 5480 – Elliptic Curve Cryptography Subject Public Key Information (Internet Engineering Task Force)
• Comparing ECDSA vs RSA (SSL.com)
• Suite B PKI in Windows Server 2008 (Microsoft, Archivlink)
• Windows Enforcement of SHA1 Certificates (Microsoft)
• NSA Suite B Cryptography (Wikipedia)