Elliptical curves - Uwe Gradenegger

List of certificate use cases for which compatibility with elliptic curve (ECC)-based keys is known

As computing power becomes increasingly available, the need to use stronger cryptographic keys also increases. Often there is a need (for example, because the keys have to be protected by a trusted platform module) to use elliptic curves (ECC) based keys to be used. For their use, it is essential that compatibility with the intended use cases is ensured.

Below is a list of use cases for which I am aware of compatibility.

Requesting certificates with elliptic curve based keys fails when using Microsoft Platform Crypto Provider

Assume the following scenario:

A certificate template is configured to elliptic curves based keys to be used.
In addition, the certificate template is configured to use the Microsoft Platform Crypto Provider to use the private key with the Trusted Platform Module (TPM) of the device.
The certificate request fails with the following error message:

Error: The requested operation is not supported. 0x80090029 (-2146893783 NTE_NOT_SUPPORTED)

On Windows Server 2016, the error message "No provider was specified for the store or object. 0x80092006 (-2146885626 CRYPT_E_NO_PROVIDER)" is issued with otherwise identical behavior.

Basics: Elliptic curves with regard to their use in the public key infrastructure

With Windows Vista and Windows Server 2008, the Cryptography API: Next Generation (CNG) was introduced into the Windows systems.

This term refers to a collection of modern cryptographic functions. Among other things, the CNG enables the use of certificates that use keys based on elliptic curves (also called Elliptic Curve Cryptography, ECC) with the Microsoft Certification Authority and the Windows operating system.

Basics: Cryptographic Service Provider (CSP) and Key Storage Provider (KSP)

Since Windows NT 4.0, the Cryptographic Service Provider (CSP) has been part of the CryptoAPI.

The purpose is that an application does not have to worry about the concrete implementation of key management, but can leave this to generic operating system interfaces. It is also intended to prevent cryptographic keys from being loaded into memory in the security context of the user/application being used (a fatal security incident based precisely on this problem was the Heartbleed incident).

For example, it makes no technical difference to the certification authority software how its private key is protected - whether in software or with a hardware security module (HSM), for example. The call of the private key is always identical for the certification authority.

With Windows Vista and the introduction of Cryptography Next Generation (CNG) as a replacement for CryptoAPI, Key Storage Providers (KSP) were introduced.

The key algorithm of certificate requests is not checked by the certification authority's policy module

Assume the following scenario:

A certificate template is configured to use elliptic curve based keys (e.g. ECDSA_P256).
As a result, a minimum key length of 256 bits is configured.
Nevertheless, certificate requests that use other ECC curves or RSA-based keys are also signed.

Basics: key algorithms, signature algorithms and signature hash algorithms

When planning a public key infrastructure, the question arises as to which cryptographic algorithms it should use.

The main principles are explained below.

What key lengths should be used for certificate authorities and certificates?

When planning a public key infrastructure, the question naturally arises as to which key lengths should be selected for certification authority and end certificates.