Ahmed Serhrouchni ENST’Paris CNRS

Présentation au sujet: "Ahmed Serhrouchni ENST’Paris CNRS"— Transcription de la présentation:

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

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

3 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

4 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

5 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

6 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.

7 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

8 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

9 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.

10 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

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

12 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

13 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

14 Structure d’un certificat X.509

15 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

16 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 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

17 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

18 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 Protection 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.

19 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 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.

20 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…

21 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 …

22 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…

23 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.

24 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

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

26 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

27 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:

28 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 et récupérer la distribution de apache incluant la librairie openssl (très rapide à installer)

29 Commandes à utiliser Genrsa Req CA Smime X509 Rsa pkcs12

30 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)

31 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.