CryptoAPI – Uwe Gradenegger

Les listes de blocage ne sont pas reconnues comme valides (uniquement) sous Windows (CRYPT_E_REVOCATION_OFFLINE)

Récemment, quelqu'un s'est adressé à moi avec un problème intéressant.

Une autorité de certification a été installée. Linux, c'est-à-dire (probablement) OpenSSL, sert de base. Les listes de blocage fonctionnent sur les clients Linux, mais ne sont pas acceptées par les systèmes Windows. Ici, le message d'erreur suivant apparaît toujours lorsque l'on vérifie les listes de blocage.

0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE) -- 2148081683 (-2146885613)
Text der Fehlermeldung: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.

En anglais, le message d'erreur est le suivant :

0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE) -- 2148081683 (-2146885613)
The revocation function was unable to check revocation because the revocation server was offline.

Continuer la lecture

Principes de base : fournisseur de services cryptographiques (CSP) et fournisseur de stockage de clés (KSP)

Seit Windows NT 4.0 gibt es im Rahmen der CryptoAPI die Cryptographic Service Provider (CSP).

Sinn ist, dass sich eine Anwendung nicht um die konkrete Implementierung der Schlüsselverwaltung kümmern muss, sondern dies generischen Betriebssystem-Schnittstellen überlassen kann. Ebenso soll hiermit vermieden werden, dass kryptographische Schlüssel im Sicherheitskontext des Benutzers/der verwendeten Anwendung in den Arbeitsspeicher geladen werden (ein fataler Sicherheitsvorfall, der genau auf diesem Problem basierte war der Heartbleed Vorfall).

Beispielsweise spielt es für die Zertifizierungsstellen-Software technisch keine Rolle, wie ihr privater Schlüssel geschützt ist – ob in Software oder beispielsweise mit einem Hardware Security Modul (HSM). Der Aufruf des privaten Schlüssel ist für die Zertifizierungsstelle immer identisch.

Mit Windows Vista und der Einführung der Cryptography Next Generation (CNG) als Ablösung für die CryptoAPI wurden die Key Storage Provider (KSP) eingeführt.

Continuer la lecture

Principes de base du répondeur en ligne (Online Certificate Status Protocol, OCSP)

Les certificats disposent généralement de l'extension „CRL Distribution Points“, qui permet d'indiquer à une application où se trouve la liste de diffusion associée au certificat. Liste de révocation des certificats (CRL) est à trouver.

Celui-ci ressemble à un annuaire téléphonique : On y trouve tous les numéros de série des certificats rappelés par l'autorité de certification (et encore valables). Chaque application qui vérifie le statut de révocation doit télécharger et évaluer la liste de révocation complète.

Plus la taille augmente, plus cette procédure devient inefficace. En règle générale, 100 000 certificats rappelés correspondent déjà à une taille de fichier d'environ 5 Mo pour la liste de révocation.

Le Online Certificate Status Protocol (OCSP) a été développé à cet effet (sous la direction de la société ValiCert) : Il s'agit d'un service d'information qui permet aux applications de demander le statut de révocation de certificats individuels, ce qui évite de devoir télécharger la CRL complète. OCSP est disponible dans le RFC 6960 est spécifiée.

Continuer la lecture

Google Chrome et Microsoft Edge ne vérifient pas l'état de révocation des certificats

De plus en plus d'entreprises utilisent comme navigateur par défaut sur la plateforme Windows le navigateur Google Chrome ou le nouveau Microsoft Edge basé sur Chromium (nom de code Anaheim).

Lors de la distribution de l'un de ces deux navigateurs, il convient de tenir compte du fait qu'ils se comportent en partie différemment des autres navigateurs en ce qui concerne les certificats.

Outre le fait que Chromium, contrairement à Internet Explorer et au précédent Edge (nom de code Spartan) qui impose le RFC 2818, il se comporte aussi en Vérification des informations de blocage différent.

Continuer la lecture

Principes de base : recherche de certificats et validation du chemin de certification

Um feststellen zu können, ob ein Zertifikat von einer als vertrauenswürdig eingestuften Zertifizierungsstelle ausgestellt wurde, muss eine Vertrauenskette (engl. Trust Chain) gebildet werden. Hierfür müssen alle Zertifikate in der Kette ermittelt und überprüft werden. Die Microsoft CryptoAPI bildet alle möglichen Zertifikatketten und liefert diejenigen mit der höchsten Qualität an die anfragende Anwendung zurück.

Continuer la lecture

Principes de base : vérification du statut de révocation des certificats

Soll ein gültiges, noch nicht abgelaufenes Zertifikat aus dem Verkehr gezogen werden, muss es widerrufen werden. Hierfür pflegen die Zertifizierungsstellen entsprechende Sperrlisten, in welchen die digitalen Fingerabdrücke der widerrufenen Zertifikate aufgelistet sind. Sie müssen bei der Gültigkeitsprüfung abgefragt werden.

Continuer la lecture

Combinaison d'un répondeur en ligne (OCSP) avec Delta CRL et un point de distribution de listes de révocation (CDP) sans liste de révocation Delta pour une résilience accrue

OCSP Antworten eines Microsoft OCSP Resonders sind genau so lange gültig wie die zugrunde liegende Sperrliste. In manchen Szenarien möchte man die Gültigkeitszeiten von OCSP verringern, indem man Delta CRLs verwendet. Gleichzeitig soll aber bei den in den CDP Pfaden eingetragenen Sperrlisten keine Delta CRL verwendet werden, um einen Fallback auf eine länger gültige CRL zu ermöglichen.

Continuer la lecture

Impact de la défaillance du répondeur en ligne (OCSP) sur la vérification du statut de révocation d'un certificat

Nous allons maintenant examiner comment se comporte la vérification du statut de blocage en cas de défaillance du répondeur en ligne. Selon la configuration des certificats délivrés, le comportement peut varier considérablement.

Continuer la lecture

Welchen Einfluss hat der Ablauf der Sperrliste einer der übergeordneten Zertifizierungsstellen auf die Zertifizierungsstelle?

Leider kommt es in der Praxis hin und wieder vor, dass die Sperrliste einer übergeordneten Zertifizierungsstelle abläuft und eine Erneuerung ausbleibt. Auch kann dies planmäßig, etwa bei Außerbetriebnahme einer alten Hierarchie geschehen.

Continuer la lecture

Consulter et supprimer le cache d'adresses des listes de blocage (CRL URL Cache)

Toutes les applications qui utilisent le Microsoft Cryptographic Application Programming Interface Version 2 (Crypto API Version 2, CAPI2) ont un mécanisme de mise en cache des informations de révocation des certificats (Listes de blocage des certificats et OCSP-réponses).

Il n'est donc pas possible de garantir, par exemple, qu'une liste de blocage nouvellement publiée sera utilisée par les participants avant que la liste de blocage précédente, qui se trouve encore dans la mémoire cache, n'ait expiré.

Nous décrivons ci-dessous comment consulter et influencer le cache de la liste de blocage.

Continuer la lecture

Principes de base des infrastructures à clés publiques (PKI)

Une infrastructure à clé publique comprend tous les composants (matériel, logiciel, personnes et processus) nécessaires à l'utilisation de certificats numériques. Une PKI se compose d'une ou de plusieurs autorités de certification (CA). Les tâches d'une PKI sont notamment les suivantes

garantir l'authenticité des clés, c'est-à-dire établir un lien compréhensible entre une clé et son origine afin d'empêcher tout abus
la révocation des certificats, c'est-à-dire s'assurer que les clés mises hors service ou compromises (par exemple volées) ne peuvent plus être utilisées
Garantie de l'obligation (non-répudiation), c'est-à-dire, par exemple, que le propriétaire d'une clé ne peut pas nier qu'elle lui appartient.
Imposer des directives (en anglais policies), c'est-à-dire des procédures standardisées pour l'utilisation des certificats.

Continuer la lecture

Les contrôleurs de domaine ne vérifient pas l'utilisation étendue de la clé lors de la connexion par carte à puce.

Quiconque souhaite utiliser la fonction Smartcard Logon dans l'entreprise a tout intérêt à veiller à ce que la sécurité de son autorité de certification soit aussi renforcée que possible. Cela implique quelques mesures essentielles :

Suppression de tous les certificats d'autorité de certification inutiles de l'objet NTAuthCertificates dans Active DirectoryChaque autorité de certification qui se trouve dans ce magasin est autorisée à émettre des certificats de connexion de carte à puce dans l'Active Directory pour l'ensemble de la structure.
Utiliser la subordination qualifiéeLimiter les certificats d'autorité de certification afin de ne leur faire confiance que pour les extended key usages effectivement délivrés. En cas de compromission de l'autorité de certification, le dommage est alors limité à ces Extended Key Usages. Le "Smart Card Logon" Extended Key Usage ne serait alors présent que dans le certificat d'autorité de certification de l'autorité de certification qui délivre effectivement de tels certificats.

Ce qui est intéressant dans ces réflexions, c'est que les contrôleurs de domaine ne vérifient pas du tout les Extended Key Usages lors de la connexion via carte à puce.

Continuer la lecture