> Tech > L’authentification des correspondants

L’authentification des correspondants

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Une communication cryptée ne peut pas avoir d'efficacité si on n'est pas totalement certain de l'identité de l'interlocuteur. A quoi servirait, en effet, de chiffrer une communication afin qu'elle ne puisse être interceptée, alors que l'on n'a pas vérifié que son interlocuteur est bien celui que l'on croit ? La

méthode qui consiste à  s’assurer de l’identité d’un interlocuteur s’appelle l’authentification, et utilise le système des clés publiques. Traditionnellement lorsqu’on prend un exemple de conversation cryptée, on utilise toujours les mêmes prénoms : Alice et Bob… ne dérogeons pas à  la règle et prenons un exemple de communication !Supposons qu’Alice veuille authentifier Bob. Pour ce faire, elle
envoi à  Bob un message aléatoire :

A -> B Message aléatoire

Bob utilise sa clé privée pour le crypter, et renvoie le message codé à  Alice.
Elle n’aura plus qu’à  le décoder en utilisant la clé publique de Bob (la manière
dont Alice a connaissance de la clé publique de Bob est décrite plus loin).

B -> A {Message Aléatoire} clé-privée-de-Bob

Si Alice peut décrypter le message en utilisant la clé publique de Bob, elle
est alors certaine de bien parler à  Bob. Un imposteur ne disposant pas de la
clé privée de Bob aurait-été incapable de chiffrer ce message de manière à  ce
qu’il soit décodable avec la clé publique de Bob.

Message transformé (ou Message Digest). De manière générale, il n’est
pas recommandé de crypter un message avec sa clé privée sans connaître exactement
la nature du message que l’on crypte. Puisque le propriétaire de la clé privée
est le seul à  pouvoir être l’auteur d’un message qui se décrypte avec sa clé
publique, le chiffrement d’un message dont on ne connaît pas la teneur pourrait
avoir des conséquences juridiques désastreuses si l’auteur du message d’authentification
était mal intentionné, et se servait du message codé comme  » preuve  » juridique
d’une transaction financière (par exemple). C’est pour cette raison que Bob
ne va en fait pas renvoyer le message original à  Alice, mais construire un message
transformé (message digest en anglais) qui possède les caractéristiques suivantes
:

· Quelle que soit la taille du message original (dans une certaine limite),
le message transformé à  une taille fixe prédéterminée appelé  » digest  » ou  »
hash  » (sorte d’algorithme de  » hashing « )

· La transformation est à  peu près impossible à  inverser. La seule méthode connue
pour obtenir le  » digest  » est de… connaître le message original !

· On ne peut pas trouver 2 messages qui donnent le même  » digest « 

Ainsi, Bob peut se protéger en calculant le digest du message d’Alice, puis
en le cryptant avec sa clé privée et en envoyant à  Alice le digest crypté. Elle
pourra décoder ce message en utilisant d’abord la clé publique de Bob, puis
en calculant elle même le digest de son message et en comparant les valeurs.
En réalité, pour plus de sécurité encore, Bob ne va même pas utiliser le message
original d’Alice, mais un message qui contient un en-tête précisant qu’il s’agit
d’un processus d’authentification, en plus du message d’Alice. Il enverra ce
message d’abord en clair (afin qu’Alice puisse elle même calculer le digest),
puis en le cryptant :

A -> B Message Aléatoire

B -> A Ceci est un digest : Message Aléatoire

B -> A { digest[Ceci est un digest : Message Aléatoire] } clé-privée-de-Bob

De cette façon, Alice peut vérifier que Bob est bien Bob, et Bob est absolument
certain de ne pas signer de message qu’il désapprouve..

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010