Citation: Les Certificats Afin de pallier ce défaut, l'idée est d'utiliser des "objets" garantissant qu'une clé publique présentée appartient bien à son légitime propriétaire. Ce sont les certificats. En première approche, on peut considérer un certificat comme l'association d'une identité et d'une clé publique, le tout signé par la clé privée d'une autorité. Ces certificats pourront être vérifiés par la clé publique de cette autorité qui la diffuse le plus largement possible via un certificat. Les certificats sont normalisés par la norme X509 qui définit des champs de bases (X509) ainsi que des extensions (X509v3) : code: Champs de base : version de la norme X509 utilisée objet (nom distingué du détenteur du certificat et de la clé privée associée) émetteur (nom distingué de l'autorité ayant signé ce certificat) numéro de série du certificat algorithme de signature date de début de validité du certificat date de fin de validité du certificat clé publique signature numérique Les noms distingués sont en fait des enregistrements contenant de nombreuses informations comme le nom courrant (CN pour Common Name), l'organisation (O), le pays (C pour Country), l'adresse e-mail (E), une description (D) Ces certificats ont également des extensions, notamment keyUsage et extendedKeyUsage (EKU). Ces deux extensions permettent de préciser le rôle du certificat et de la clé privée associée. Exemples rôle pour KeyUsage : digitalSignature, keyEncipherment, dataEncipherment, keyCertSign, cRLSign, ... Exemples de rôle pour extendedKeyUsage : serverAuth, clientAuth, codeSigning, emailProtection, ipsecEndSystem, ... Ces certificats sont codés au format binaire ASN.1 : c'est le format DER. Les extensions généralement utilisées sont .cer ou .der. Il existe aussi le format PEM utilisant le codage en base 64 avec des délimiteurs. L'extension généralement utilisée est .pem Exemple de délimiteurs : code: ----BEGIN RSA PRIVATE KEY---- ----END RSA PRIVATE KEY---- ----BEGIN CERTIFICATE---- ----END CERTIFICATE---- ----BEGIN CERTIFICATE REQUEST---- ----END CERTIFICATE REQUEST---- -----BEGIN X509 CRL----- -----END X509 CRL----- Enfin, il existe un autre format, le PKCS#12, qui est un codage binaire incluant un certificat, sa clé privée associée et optionnellement d'autres certificats. Le fichier peut être chiffré à l'aide d'une passphrase. Ce format est utilisé par les IGC pour distribuer les certificats et les clés privées à leurs clients. L'extension utilisée est .p12 ou .pfx

Citation: Les Infrastructures à Gestions de Clés (IGC) Une autorité est donc un organisme qui va donner à ses utilisateurs des certificats qui permettent de les identifier. Ces certificats pourront etre vérifiés par la clé publique de cette autorité qui diffuse le plus largement possible son propre certificat. À propos de l'autorité, il faut distinguer plusieurs entités, même si dans le cadre du TP, elles sont confondues. Chaque autorité a un rôle précis. L'autorité d'enregistrement est l'entité qui enregistre la demande de certificat. Elle est chargée de vérifier l'identité du demandeur ainsi que la correspondance entre la clé publique présentée et sa clé privée. Ce rôle est donc très important puisque c'est sur ces vérifications que repose la confiance que l'on accorde à l'autorité. L'autorité de certification délivre le certificat en signant la requête présentée par l'autorité d'enregistrement. Il est évident que la clé privée de cette autorité, celle qui signe les certificats, doit être conservée de manière extrêmement sécurisée puisque c'est sur ce secret que repose toute l'infrastructure technique de l'IGC. Enfin, les services de publications mettent les certificats à la disposition des utilisateurs ; ils doivent également publier les listes de révocations contenant une liste de certificats invalidés pour diverses raisons (vol ou perte de clé privée en général). Ces trois services sont en général assumés par la même entité, appelée autorité de confiance. C'est sur la base de cette autorité que l'on construit une IGC. La création d'une IGC commence par la création du certificat de cette autorité. Pour cela, on commence par générér un biclé et l'identité de l'IGC. Le certificat de l'IGC est ensuite signé avec la clé privée associée à la clé publique contenue dans le certificat. Ce certificat est donc auto-signé. Ensuite, l'autorité doit diffuser largement et de façon fiable ce certificat notamment en l'intégrant dans les outils qui l'utiliseront. Une fois que l'autorité est créée, son travail consiste à fournir des certificats à ses clients. Pour cela, on procède en deux temps. On commence par générer un biclé et une identité pour le client. La clé publique et l'identité sont contenus dans une requête. Cette requête doit être présentée à l'autorité pour être signée. Dans un deuxième temps, l'autorité signe cette requête (en y ajoutant des extensions). On obtient alors le certificat de l'utilisateur (l'association entre son identité et sa clé publique) signé avec la clé privée de l'autorité. Il ne reste plus qu'à délivrer au client son certificat et la clé privée associé. Ainsi, lors d'une communication sécurisée, les interlocuteurs n'échangeront pas leur clé publique mais leur certificat. La vérification de ce certificat avec la clé publique du certificat de l'autorité (largement diffusé) garanti la non falsification des certificats. Les utilisateurs devront alors prouver qu'ils possèdent la clé privée associée au certificat présenté.

Citation: OpenSSL Openssl est un package logiciel incluant une librairie assez complète de cryptographie, un programme (openssl) qui permet d'utiliser la plupart des fonctionnalités de la librairie et un script (CA) pour automatiser les traitements compliqués. Il est configuré via un fichier nommé openssl.cnf Voici quelques exemples d'utilisation de cette boîte à outils. La syntaxe est la suivante : openssl < type de traitement > [ arguments spécifiques ... ] Le premier argument spécifie le type d'opération que l'on souhaite effectuer (génération d'une clé, hashage d'un document, ...), puis suivent les arguments spécifiques à l'opération demandée. Les pages de manuel sont très bien documentées. code: #Génération d'une bi-clé RSA de 1024 bits protégée par 3DES: openssl genrsa -out macle -des3 1024 #Génération d'une requête de certificat au format PEM pour la clé générée : openssl req -new -key macle -outform PEM -out requete.pem #Chiffrement symétrique d'un document en AES 128 avec une clé dérivée d'un mot de passe : openssl enc -aes-128-cbc -in montexte -out textechiffre -salt -e -k MotDePasse #Affichage textuel des données d'un certificat : openssl x509 -in MonCertificat -text