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
L’authentification des correspondants
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
Microsoft 365 Tenant Resilience
Face aux failles de résilience des tenants M365 (configurations, privilèges, sauvegarde). Découvrez 5 piliers pour durcir, segmenter et surveiller vos environnements afin de limiter l’impact des attaques. Prioriser vos chantiers cyber et améliorer la résilience de vos tenants Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Le trilemme de la souveraineté : le coût caché du cloud qui freine l’IA en Europe
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Semperis : gouverner l’identité à l’ère des agents IA
- Analyse Patch Tuesday Mars 2026
Articles les + lus
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
À la une de la chaîne Tech
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
