> Tech > Partager l’information en toute sécurité

Partager l’information en toute sécurité

Tech - Par Randy Franklin Smith - Publié le 24 juin 2010
email

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

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 gratuitement cette ressource

TOP 5 Modernisation & Sécurité des Postes Clients

TOP 5 Modernisation & Sécurité des Postes Clients

Pour aider les entreprises à allier les restrictions liées à la crise et la nécessaire modernisation de leurs outils pour gagner en réactivité, souplesse et sécurité, DIB-France lance une nouvelle offre « Cloud-In-One » combinant simplement IaaS et DaaS dans le Cloud, de façon augmentée.

Tech - Par Randy Franklin Smith - Publié le 24 juin 2010