Ahmed Serhrouchni ENST’Paris CNRS PKI et Certification Ahmed Serhrouchni ENST’Paris CNRS

Plan La cryptographie asymétrique. Infrastructure à Clé publique (PKI). Modèle de Confiance. Structure du Certificat numérique. Conclusion

Cryptographie asymétrique et gestion des clés Problèmes: Distribution des clés Obtenir la clé publique d’une autre entité Distribuer sa propre clé publique Révocation Révoquer une clé publiée Déterminer si une clé publiée est valide ou non

Distribution des clés publiques 1. Alice envoie sa clé publique à Bob Alice  Bob 2. Mallet intercepte la clé et la remplace avec sa propre clé Alice  Bob  Mallet / 3. Mallet peut décrypter tout le trafic et générer des signatures falsifiées

Distribution des clés publiques (suite) Une autorité de certification (CA) résout ce problème: Alice envoie sa clé publique au CA Alice prouve qu’elle détient la clé privée correspondant à la clé publique envoyée Le CA vérifie l’identité d’Alice Le CA signe l’ensemble: clé publique et identité d’Alice avec sa clé privée, le document signé est appelé certificat Quand Bob reçoit le certificat d’Alice, il est sûr que la clé qui y est certifiée est celle d’Alice

C’est quoi un certificat numérique ? Structure de données liant différents éléments au moyen de la signature d’une autorité de confiance Le groupe de travail SPKI a développé un standard pour les certificats numériques focalisant l’autorisation plutôt que l’authentification. Un certificat SPKI relie une autorisation à une clé publique, sans exiger nécessairement l’identité du détenteur de la clé privée correspondante. Néanmoins, un hash de la clé publique peut être utilisé comme un identificateur unique du détenteur de la clé. SPKI offre une simplicité par rapport au standard X.509 en offrant un schéma d’encodage moins riche que la notation ASN.1 utilisée par X.509.

Infrastructure à clé publique (PKI) D’après le standard X.509: CA Répertoire Utilisateur final Publie / Publie la révocation Demande / Émet La méthode la plus utilisée pour gérer la révocation de certificats est de maintenir une liste de révocation de certificats CRL (Certificate Revocation List), qui est une liste de certificats révoqués signée et périodiquement publiée par le CA ou par une autorité autorisée par le CA. Quand un système utilisant un certificat veut vérifier la validité d’un certificat, il ne vérifie pas uniquement la validité de la signature du CA ayant signé le certificat mais saisit également une liste de révocation récente et vérifie que le numéro de série du certificat n’appartient pas à cette liste de révocation [2]. Le mot récent varie avec la politique de sécurité locale : un CA émet une CRL périodiquement (chaque heure, chaque jour ou chaque semaine Mais: Le CA doit vérifier les détails de chaque utilisateur Risques pour la sécurité du CA

Infrastructure à clé publique (suite) CA Répertoire Utilisateurs finaux Publie / Publie la révocation Demande / Émet RA Autorité d’enregistrement (RA) Intermédiaire entre  détenteur de clé et CA Vérifie les requêtes des utilisateurs et les transmet au CA Le niveau de vérification dépend de la politique de certification (CPS) mise en œuvre

Composants d’une PKI Principaux Complémentaires Autorité de certification CA Autorité d’enregistrement RA Annuaire de publication Administrateurs Complémentaires Base de données Serveur d’horodatage. Serveur HTTP, SMTP, POP.

Modèle de confiance dans X.509 Infrastructure hiérarchique Possibilité de certification entre 2 CAs appartenant à des arbres différents, c’est la co-certification CA1 1 3 5 2 CA2 CA1 co-certifie CA2 1 3 5 4 2 Du moment qu’une seule autorité de certification ne peut certifier toutes les clés publiques du monde, plusieurs PKIs permettent aux CAs de certifier d’autres CAs. Il en découle des modèles de confiance où des CAs délèguent leur confiance à d’autres CAs. il existe deux types de certificats à clé publique : ·         Certificats pour des utilisateurs finaux : End Entity Certificates ; ·         Certificats pour CAs : CA Certificates. Un certificat pour un utilisateur final est un certificat issu par un CA à un sujet qui n’est pas un émetteur de certificats à clé publique. Un certificat pour CA est un certificat issu par un CA à un sujet qui est lui même un CA et par conséquent est capable d’émettre des certificats à clé publique. Les certificats de CAs Modèle Hiérarchique : Les autorités de certification sont rangées sous forme d’une hiérarchie sous un CA root. Chaque utilisateur devrait connaître la clé publique du CA pour permettre la vérification des certificats en suivant le chemin de certification depuis le CA root. La structure hiérarchique a plusieurs avantages incluant la possibilité de tracer la structure des grandes organisations et d’avoir des stratégies de vérification très simples. 1 CA Utilisateur final

Certificats X.509 Principal format utilisé pour les certificats Norme: ITU-T X.509, ou ISO/IEC 9594-8 Versions successives: 1988 : v1 1993 : v2 = v1 + 2 nouveaux champs 1996 : v3 = v2 + extensions

Structure d’un certificat X.509 Version (V1) Serial Number (V1) Signature Algorithm Identifier (V1) (pour la signature de l’émetteur du certificat) Issuer (V1) (Nom X500 du CA) Validity (V1) (Dates début et fin du certificat) Subject (V1) (Nom X500 du détenteur) SubjectPublicKeyInformation (V1) (Identificateur de l’algorithme et clé publique) IssuerUniqueIdentifier (V2) SubjectUniqueIdentifier (V2) Extensions (V3) Signature digitale du CA Clé privée du CA Génération de la signature

Structure d’un certificat X.509 IssuerUniqueIdentifie identifie de façon unique la clé utilisée par le CA pour signer le certificat (cas où le CA a utilisé plusieurs clés depuis sa mise en œuvre) SubjectUniqueIdentifier Différencie entre plusieurs clés publiques, issues par le même CA, appartenant à un même détenteur

Structure d’un certificat X.509

Extensions d’un Certificat X.509 Le concept d’origine des certificats X.509 est de relier l’identité d’une entité à une clé publique Nouvelles situations: besoin d’avoir d’autres informations que l’identité Solution: Introduction de blocks de données pouvant supporter n’importe quel type d’informations pour satisfaire des besoins locaux

Extensions d’un Certificat X.509 (suite) Rajout de nouveaux champs sans la modification de la définition ASN.1 d’un certificat Permettre le rajout d’extensions selon le besoin des implémentations L’identificateur d’une extension est défini selon ITU-T Rec. X.660 | ISO/IEC 9834-1 Identificateur Extension1 Flag critique (1 ou 0) Valeur Extension1 Identificateur Extension2 Flag critique (1 ou 0) Valeur Extension2 Identificateur Extension3 Flag critique (1 ou 0) Valeur Extension3

Extensions d’un Certificat X.509 (suite) Les extensions sont classées en 4 catégories: Les extensions d’information sur la clé et la politique de sécurité Les extensions d’informations sur le détenteur et l’émetteur Les extensions de contraintes sur le chemin de certification Les extensions de révocation

Extensions d’information sur la clé et la politique de sécurité Key Usage: définit l’utilisation de la clé certifiée digitalSignature nonRepudiation keyEncipherment keyAgreement keyCertSign/cRLSign Extended Key Usage: autres cas d’utilisation ServerAuthentication clientAuthentication codeSigning emailProtection timeStamping a)      DigitalSignature : La clé peut être utilisée pour signer des données générales, par exemple pour garantir l’authenticité ; b)      NonRepudation : La clé peut être utilisée pour signer un message qui ne doit pas être répudié plus tard; c)      KeyEncipherment : la clé peut être utilisée pour échanger une clé de session; d)      DataEncipherment : la clé peut être utilisée pour chiffrer des données générales ; e)      KeyAgreement : la clé est utilisée dans un contexte comme Diffie-Hellman pour l’agrément plutôt que l’échange d’une clé de session. Les deux derniers champs encipherOnly et decipherOnly n’ont une signification que si KeyAgreement est TRUE; f)       KeyCertSign : la clé peut être utilisée pour signer des certificats ; g)      CRLSign : la clé peut être utilisée pour signer des CRLs  h)      encipherOnly : Ce bit n’a une signification que si le bit KeyAgreement  est TRUE. Il signifie que la clé sur laquelle les entités se sont mises en accord peut être utilisée uniquement pour chiffrer les données envoyées au détenteur du certificat ; decipherOnly : Ce bit n’a une signification que si le bit KeyAgreement  est TRUE. Il signifie que la clé sur laquelle les entités se sont mises en accord peut être utilisée uniquement pour déchiffrer les données envoyées par le détenteur du certificat.

Extensions d’information sur la clé et la politique de sécurité (suite) Private Key usage Period: définit les dates début et fin de validité de la clé privée Une signature peut être valide pour 10-20 années, mais la clé privée doit être utilisée uniquement pour 1 ou 2 années Ce champ indique la période d’utilisation de la clé privée correspondant à la clé publique certifiée. Ceci est applicable seulement pour les clés de signature digitale. Ce champ est utilisé uniquement quand la période d’utilisation de la clé privée est plus courte que celle du certificat contenant la clé publique correspondante.

Extensions d’information sur la clé et la politique de sécurité (suite) Certificate Policies Informations sur la politique du CA sous laquelle le certificat a été émis X.509 délègue à la politique du CA tout ce qui concerne la sémantique de confiance du certificat Plusieurs politiques servent pour protéger le CA de toute responsabilité « Verisign disclaims any warranties … Varisign makes no representation that any CA or user to which it has issued a digital ID is in fact the person or the organisation it claims to be… Verisign makes no assurances of the accuracy, authenticity, integrity, or reliability of information » Une politique de sécurité est un ensemble de règles qui indiquent l’usage accepté du certificat, il peut inclure par exemple : la communauté d’usage, les politiques d’authentification, la fréquence de mise à jour de la CRL…

Extensions d’informations sur le sujet et l’émetteur Alternative Name (Subject / Issuer) ou General Name Nom rfc822 (adresse mail) Nom DNS (Nom DNS d’une machine) uniformResourceIdentifier (URL) Adresse IP Adresse X.400 Nom EDI OID Toute autre forme de nom …

Extensions d’informations sur le sujet et l’émetteur (suite) Subject directory attributes Transporte une séquence d’attributs concernant le sujet du certificat: un rôle, une appartenance à un groupe, une autorisation, un numéro de téléphone…

Extensions de contraintes sur le chemin de certification Basic Constraints Précise si le certificat émis est un certificat de CA ou pas Si le certificat émis est un certificat de CA, une « Distance de certification » est définie Name Constraints utilisé dans les certificats de CAs indique un espace de noms où tous les noms des sujets ultérieurs dans le chemin de certification doivent figurer Policy Constraints Identification explicite de la politique de sécurité Basic Constraints: Cette extension indique si le détenteur du certificat peut agir comme un CA. Si c’est le cas, une contrainte sur la longueur du chemin de certification peut être aussi spécifiée. Name Constraints :Ce champ, qui doit être utilisé uniquement dans les certificats de CAs, indique un espace de noms à l’intérieur duquel tous les noms des sujets se trouvant dans les certificats ultérieurs dans un chemin de certification seront localisés. Policy Constraints : Ce champ spécifie des contraintes qui peuvent exiger une identification explicite de la politique de sécurité d’un certificat ou empêcher le mapping des politiques dans le reste du chemin de certification.

Extensions de révocation CRL Distribution Points identifie les points de distribution de la CRL Freshest CRL identifie la CRL qui a les informations les plus récentes

Expérimentation et mise en œuvre de la cryptographie Travaux Pratiques Expérimentation et mise en œuvre de la cryptographie

Travaux Pratiques Objectifs: Génération de clés publiques/privés Génération de certificat Signature numérique Chiffrement et signature au format smime Chiffrement symétrique

Outils à utiliser Openssl : libraire de cryptographie et de services liés à la signature et chiffrement Openssl supporte également un client et serveur SSL Développé initialement sous le nom de SSLeay par Eric Young Référence et documention: http://www.openssl.org

Comment installer openssl? Sur plateforme Unix récupérer la distribution sous format tar après désarchivage, la compiler puis installer Sur plateforme Windows aller sur le site de www.opensa.org et récupérer la distribution de apache incluant la librairie openssl (très rapide à installer)

Commandes à utiliser Genrsa Req CA Smime X509 Rsa pkcs12

Premier objectif que tout le monde doit atteindre Générer une paire de clés Générer un certificat auto signé Transmettre la clé publique à son correspondant (certificat) Signer un fichier avec sa clé privé, le chiffrer avec la clé du correspondant et le lui transmettre (le format du fichier est du smime)

Générer une clé privé au format pkcs12 Deuxième objectif Générer un certificat Générer une clé privé au format pkcs12 Importer cette clé au niveau du browser ou de Outlook express.