Infrastructure à clé publique

L'infrastructure à clé publique (ICP) est le système d'autorités de certification, de certificats numériques et de politiques qui lie les clés publiques à des identités vérifiées, permettant à des parties qui ne se sont jamais rencontrées de se faire confiance mutuellement quant à leurs clés.

Definition

Une infrastructure à clé publique est l'ensemble des rôles, des politiques, du matériel et des logiciels nécessaires pour créer, distribuer, stocker, valider et révoquer les certificats numériques qui lient les clés publiques à des identités.

Scope

Ce sujet couvre les composants et le fonctionnement de l'ICP : les certificats X.509, les autorités de certification et les chaînes de confiance, l'émission et la validation des certificats, la révocation (listes de révocation de certificats (CRL), protocole de vérification de certificat en ligne (OCSP)) et les mécanismes de transparence. Il aborde le modèle de confiance sous-jacent à l'ICP web et ses alternatives (réseau de confiance). Il exclut les algorithmes de signature numérique utilisés par les certificats et les protocoles de canal sécurisé (TLS) qui consomment les certificats, ces deux aspects étant traités séparément.

Core questions

• Comment une partie de confiance s'assure-t-elle qu'une clé publique appartient à une identité particulière ?
• Comment les chaînes de certificats et les autorités racines établissent-elles une confiance hiérarchique ?
• Comment les certificats sont-ils validés et comment la révocation est-elle gérée lorsque les clés sont compromises ?
• Quels modes de défaillance (compromission d'AC, émission erronée) menacent le modèle de confiance ?
• Comment des mécanismes tels que la Transparence des Certificats améliorent-ils la responsabilisation ?

Key concepts

• certificat X.509
• autorité de certification (AC)
• chaîne de confiance et magasin de racines
• demande de signature de certificat
• révocation de certificat (CRL, OCSP)
• Transparence des Certificats
• réseau de confiance
• compromission d'AC et émission erronée
• épinglage de certificat

Key theories

Chaîne de confiance hiérarchique

La confiance est enracinée dans un petit ensemble d'autorités de certification racines auto-signées préinstallées chez les clients ; celles-ci signent des AC intermédiaires, qui signent des certificats d'entité finale, de sorte qu'un client peut vérifier n'importe quel certificat en validant la chaîne jusqu'à une racine de confiance.

Révocation et transparence

Étant donné que les clés peuvent être compromises ou les certificats mal émis, l'ICP fournit des mécanismes de révocation (listes de révocation de certificats et OCSP) et, de plus en plus, des journaux d'audit publics (Transparence des Certificats) afin que les certificats mal émis puissent être détectés et révoqués.

Mechanisms

Un demandeur génère une paire de clés et soumet une demande de signature de certificat ; l'autorité de certification (AC) vérifie l'identité du demandeur ou le contrôle du domaine et émet un certificat X.509 liant la clé publique à cette identité, signé avec la clé privée de l'AC. Une partie de confiance valide un certificat en vérifiant la chaîne de signature jusqu'à une racine de confiance, la période de validité, le nom et le statut de révocation (via une CRL ou OCSP). La Transparence des Certificats (Certificate Transparency) enregistre publiquement tous les certificats émis afin que les propriétaires de domaines puissent détecter les émissions non autorisées.

Clinical relevance

L'ICP web est ce qui donne un sens au cadenas dans les navigateurs : chaque connexion HTTPS repose sur un certificat émis par une AC pour authentifier le serveur. L'émission automatisée et gratuite (Let's Encrypt) a conduit à une adoption quasi universelle du HTTPS. L'ICP sous-tend également la signature de code, le courrier électronique sécurisé, la signature de documents et l'identité des appareils d'entreprise. Les défaillances des AC (la violation de DigiNotar en 2011) ont un impact mondial, c'est pourquoi la transparence et la révocation sont importantes.

Evidence & guidelines

Les certificats X.509 et la révocation sont décrits dans la RFC 5280 ; la Transparence des Certificats dans la RFC 6962 ; l'OCSP dans la RFC 6960. Les exigences de base du CA/Browser Forum régissent les AC publiquement fiables. Le protocole ACME (RFC 8555) automatise l'émission. Les bonnes pratiques privilégient les certificats de courte durée, le renouvellement automatisé et le recours à la surveillance de la Transparence des Certificats.

History

Le concept de certificat a été proposé dans la thèse de Loren Kohnfelder au MIT en 1978. X.509 est issu de l'effort de répertoire X.500 à la fin des années 1980 et est devenu la base de l'ICP web à mesure que SSL/TLS se répandait dans les années 1990. Les compromissions répétées d'AC et les émissions erronées (Comodo et DigiNotar en 2011) ont exposé la fragilité de la confiance inconditionnelle envers les AC, ce qui a conduit à la Transparence des Certificats et à une gouvernance plus stricte des AC, tandis que Let's Encrypt (2015) a démocratisé l'émission de certificats.

Key figures

• Loren Kohnfelder
• Whitfield Diffie
• Ross Anderson
• Ben Laurie

Seminal works

• stallings2017
• rfc5280
• anderson2020

Frequently asked questions

Que vérifie réellement une autorité de certification ?

Pour les certificats courants validés par domaine, l'AC confirme uniquement que le demandeur contrôle le domaine (par exemple, en répondant à un défi). Elle ne garantit pas la légitimité de l'organisation. Les certificats à plus haute assurance impliquent davantage de vérifications d'identité, mais la plupart des certificats web n'attestent que du contrôle du domaine.

Que se passe-t-il si une autorité de certification est compromise ?

Un attaquant pourrait émettre des certificats frauduleux pour n'importe quel site, permettant l'usurpation d'identité. Les défenses incluent la révocation et la non-confiance envers l'AC, les journaux de Transparence des Certificats qui révèlent les certificats non autorisés, et des durées de vie courtes des certificats qui limitent la fenêtre d'utilisation abusive.