CryptoAPI - Uwe Gradenegger

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.

Basics of online responders (Online Certificate Status Protocol, OCSP)

Certificates usually have a "CRL Distribution Points" extension that tells an application where the certificate's associated Certificate Revocation List (CRL) can be found.

This is like a telephone directory: It contains all the serial numbers of certificates that have been recalled by the certification authority (and are still valid). Every application that checks the revocation status must download and evaluate the entire revocation list.

As the size increases, this procedure becomes increasingly inefficient. As a rule of thumb, 100,000 recalled certificates already correspond to approx. 5 MB file size for the revocation list.

The Online Certificate Status Protocol (OCSP) was developed for this purpose (under the leadership of ValiCert): It is similar to a directory assistance service where applications can request the revocation status for individual certificates, thus eliminating the need to download the entire CRL. OCSP is available in the RFC 6960 specified.

Google Chrome and Microsoft Edge do not check certificate revocation state

More and more companies are using the Google Chrome browser or the new Chromium-based Microsoft Edge (codename Anaheim) on.

When distributing one of these two browsers, it should be noted that they sometimes behave differently from other browsers in terms of certificates.

Besides the fact that Chromium, unlike Internet Explorer and the previous Edge (codename Spartan) the RFC 2818 enforces, it also behaves in the Checking blocking information different.

Basics: Finding certificates and validating the certification path

In order to determine whether a certificate has been issued by a certification authority that has been classified as trustworthy, a trust chain must be formed. To do this, all certificates in the chain must be determined and checked. Microsoft CryptoAPI builds all possible certificate chains and returns those with the highest quality to the requesting application.

Basics: Checking the revocation status of certificates

If a valid, unexpired certificate is to be withdrawn from circulation, it must be revoked. For this purpose, the certification authorities maintain corresponding revocation lists in which the digital fingerprints of the revoked certificates are listed. They must be queried during the validity check.

Combination online responder (OCSP) with delta CRL and revocation list distribution point (CDP) without delta brevocation list for increased resilience

OCSP responses from a Microsoft OCSP resonder are valid for exactly as long as the underlying revocation list. In some scenarios, you may want to reduce OCSP validity times by using delta CRLs. At the same time, however, no delta CRL should be used for the revocation lists entered in the CDP paths in order to enable a fallback to a CRL with a longer validity.

Effects of the failure of the online responder (OCSP) on the verification of the revocation status of a certificate

The following section examines how the revocation status check behaves if the online responder should fail. Depending on the configuration of the certificates issued, the behavior can vary considerably.

What impact does the expiry of the revocation list of one of the higher-level Certification Authorities have on the Certification Authority?

Unfortunately, in practice it happens from time to time that the revocation list of a higher-level certification authority expires and a renewal does not take place. This can also happen as planned, for example when an old hierarchy is decommissioned.

View and clear the revocation list address cache (CRL URL Cache).

All applications that use the Microsoft Cryptographic Application Programming Interface Version 2 (Crypto API Version 2, CAPI2) have a mechanism for caching certificate revocation information (Certificate revocation lists and OCSP-answers).

Thus, there is no guarantee that, for example, a newly published blacklist will be used by participants before the previous blacklist, which is still in the cache, has expired.

The following describes how to view and influence the blacklist cache.

Public Key Infrastructures (PKI) basics

A public key infrastructure comprises all components (hardware, software, people and processes) required for the use of digital certificates. A PKI consists of one or more certification authorities (CA). The tasks of a PKI include:

Ensuring the authenticity of keys, i.e. establishing a traceable link between a key and its origin to prevent misuse.
Revocation of certificates, i.e., ensuring that decommissioned or compromised (e.g., stolen) keys can no longer be used.
Guarantee of liability (non-repudiation), i.e., the owner of a key cannot deny that it belongs to him.
Enforcement of policies, i.e. standardized procedures for the use of certificates.

Domain controller does not check extended key usage on smart card login

Anyone who wants to use the smartcard logon function in their company would be well advised to ensure that their certification authority has the strongest possible security hardening. This includes some essential measures:

Removing all unnecessary certification authority certificates from the NTAuthCertificates object in Active Directory: Each certification authority located in this store is authorized to issue smartcard logon certificates in Active Directory for the complete forest.
Use qualified subordinationRestricting the certification authority certificates so that they are only trusted for the extended key usages actually issued. In the event of a compromise of the certification authority, the damage is then limited to these extended key usages. The "Smart Card Logon" Extended Key Usage would then only be present in the certification authority certificate of the certification authority that actually issues such certificates.

What is interesting about these thoughts, however, is that the domain controllers do not check the extended key usages at all when logging in via smartcard.