Dans l’article « Cachez bien vos secrets » (octobre 2005), je vous présentais le cryptage par clé partagée et par clé publique/privée. Je soulignais que le cryptage par clé partagée est adapté au cryptage de masse de grandes quantités de données, que le cryptage par clé publique/privée convient mieux pour échanger des informations entre des interlocuteurs, et que l’on peut combiner les deux avec bonheur.J’expliquais aussi comment on peut combiner le cryptage par clé publique/privée avec le hashing, pour créer des signatures numériques qui prouvent à la fois l’identité de l’envoyeur d’un message et le fait que les données n’ont pas été modifiées depuis leur signature. Le cryptage par clé publique/privée est un moyen souple et efficace de prouver l’identité et de partager des informations sécurisées entre des gens qui ne se connaissent peut-être pas.
Mais il y a un autre détail important : les utilisateurs doivent pouvoir obtenir les clés publiques d’autrui avec la certitude que la clé publique d’un utilisateur est vraiment la sienne et pas celle d’un imposteur. Pour instaurer cette confiance, on a besoin d’une infrastructure qui facilite la publication des clés publiques. Ca tombe bien, une telle technologie existe : c’est PKI (public key infrastructure).
Partager l’information en toute sécurité
PKI utilise des certificats émis par des serveurs appelés CA (Certification Authorities) pour se porter garant de l’authenticité d’un utilisateur et de sa clé publique. Avec PKI, deux correspondants qui ne se connaissent pas bien peuvent vérifier leurs identités respectives et échanger des informations en toute sécurité en faisant confiance à la CA. Une CA a sa propre paire de clés publique/privée : c’est la pierre angulaire de la sécurité PKI. Voyons un exemple. Pour que Bob tire parti de PKI, il doit obtenir de la part d’une CA, un certificat similaire à celui de la figure 1.
L’ordinateur de Bob génère une paire de clés publique/privée, puis contacte la CA. Bob doit ensuite s’authentifier auprès de la CA. (Voir l’encadré « Authentifier le demandeur d’un nouveau certificat » donne un aperçu du processus d’autorisation.) Par exemple, il fournit une identification qui peut inclure son nom, adresse électronique, société et département. Bob fournit sa clé publique à la CA, mais il ne partage jamais sa clé privée sauf si la CA procure des services de dépôt/sauvegarde (escrow/backup).
Ainsi, même la CA ne peut pas compromettre l’information protégée par la clé privée de Bob. Ensuite, la CA prend la clé publique et l’information d’identification de Bob et formate l’ensemble en un certificat, généralement d’après les PKCS (Public-Key Cryptography Standards) que RSA Laboratories définit. (Pour plus d’informations sur ces standards, allez ici) Enfin, la CA ajoute une signature numérique au certificat en faisant le hashing du certificat puis en cryptant le hash avec sa propre clé publique. Vous pouvez voir le hash crypté d’un certificat et l’algorithme hash de la CA utilisée (c’est-à-dire, sha1) dans les champs Thumbprint et Thumbprint algorithm du certificat que montre la figure 2. Le certificat résultant peut maintenant être publié dans des répertoires tels que AD (Active Directory) ou partagés par Bob avec d’autres intervenants.
Téléchargez cette ressource
Guide inmac wstore pour l’équipement IT de l’entreprise
Découvrez les dernières tendances et solutions IT autour des univers de Poste de travail, Affichage et Collaboration, Impression et Infrastructure, et notre dossier Green IT sur les actions engagés par inmac wstore pour réduire son impact environnemental
Les articles les plus consultés
- Chiffrements symétrique vs asymétrique
- Activer la mise en veille prolongée dans Windows 10
- Partager vos images, vidéos, musique et imprimante avec le Groupe résidentiel
- N° 2 : Il faut supporter des langues multiples dans SharePoint Portal Server
- Cybersécurité Active Directory et les attaques de nouvelle génération
