Possibilité de truquer la clé publique de quelqu'un
Je sais comment fonctionne la cryptographie à clé publique; (très) simplifié:
Alice prend la clé publique de Bob et envoie un message chiffré avec ladite clé et l'envoie à Bob.
Bob et seulement Bob peuvent décrypter le message, car il est le seul à posséder la clé privée concurrente.
Scénario (également simplifié):
J'infecte en quelque sorte l'appareil d'Alice et remplace la clé publique "stockée" de Bob par ma propre clé publique. Après avoir chiffré son message avec ma clé publique et l'envoyer, j'intercepte le message et je peux maintenant le déchiffrer avec ma clé privée. Je pourrais alors jouer le rôle de l'homme du milieu.
Edit: Nous supposons que nous ne pouvons en quelque sorte que changer les clés publiques et ne pas lire le message en clair.
Mes questions sont:
- Comment Alice connaît-elle la clé publique de Bob?
- Est-il possible de tromper quelqu'un (ou l'appareil lui-même) afin qu'ils pensent, par exemple, qu'ils envoient le message à Bob mais qu'en réalité, ils cryptent le message avec la clé publique de quelqu'un d'autre?
- Comment contourner ce problème?
Comment Alice connaît-elle la clé publique de Bob?
Il existe plusieurs façons pour Alice de vérifier la clé publique de Bob, chacune avec ses avantages et ses inconvénients.
Direct et en personne
Il s'agit probablement de l'approche la plus sûre. Alice et Bob se rencontrent en personne, échangent et éventuellement signent leurs clés publiques. Cela rendrait pratiquement impossible pour quiconque d'altérer ce processus.
L'inconvénient devrait être évident: cette approche n'est pas réalisable pour quiconque ne se rencontre pas en personne régulièrement. Les gens du monde entier devraient investir des sommes considérables pour pouvoir se rencontrer, juste pour échanger des clés.
Via le serveur de Bob
Bob possède un serveur Web, sécurisé par un TLS approprié, et y propose sa clé publique en téléchargement. Bien que cela soit beaucoup plus pratique que de rencontrer Bob en personne, cela comporte également un risque de compromis.
Si Eve pouvait accéder au serveur de Bob et générer sa propre paire de clés, elle pourrait remplacer la clé publique de Bob par la sienne. Cela deviendrait apparent une fois que les gens auraient essayé d'envoyer des messages à Bob et qu'il ne serait pas en mesure de les décrypter, mais à ce stade, il était peut-être déjà trop tard.
Via un serveur de clés
Au lieu d'héberger la clé lui-même, Bob télécharge sa clé sur un serveur de clés et s'y connecte simplement. Ceci est très similaire à l'approche précédente, mais migre le risque de Bob vers celui qui contrôle le serveur clé.
De plus, un attaquant pourrait créer une fausse clé publique au nom de Bob ("Evil Bob"), et créer en outre de fausses clés publiques pour les amis de Bob, créant un faux réseau de confiance autour de "Evil Bob".
Via la "messagerie directe"
Une approche naïve serait d'envoyer un message à Bob sur Twitter, WhatsApp ou des plateformes similaires, lui demandant sa clé publique. Le problème ici est que vous ne pouvez pas vraiment vérifier si c'est bien lui. Un attaquant aurait pu accéder à son compte et distribuer de fausses clés publiques pour "Evil Bob".
Les systèmes VoIP pourraient être meilleurs, mais ne sont pas aussi parfaits que les gens pourraient le penser.
Est-il possible de tromper quelqu'un, afin qu'il utilise une fausse clé publique?
Oui, comme détaillé ci-dessus. Tout scénario dans lequel Bob ne vous donne pas directement et personnellement la clé pourrait être compromis.
Il existe cependant des protections. Les gens peuvent signer la clé de Bob, garantissant ainsi Bob. Plus ces connexions sont étroitement imbriquées, plus il devient difficile de truquer une clé. Néanmoins, c'est possible.
Comment Alice peut-elle se protéger contre la modification par Eve de la clé publique de Bob sur son appareil?
L'hypothèse est qu'Eve a pu exploiter l'appareil d'Alice afin de modifier la clé privée de Bob.
Ce scénario est difficile, mais pas impossible. Chaque clé a une empreinte digitale, en fait deux empreintes digitales: "longue" et "courte", qui identifient la clé. Si Alice devait se souvenir de la longue empreinte digitale, il serait impossible pour Eve de créer une collision et d'insérer une clé qu'elle contrôle et qui est suffisamment similaire pour qu'Alice la confonde avec une clé légitime.
Si elle mémorise seulement l'empreinte digitale "courte", alors cela devient techniquement faisable , bien que des clés de grande valeur soient probablement ciblées avant des gens ordinaires comme Alice et Bob.
Un web de confiance aiderait également dans ce cas, car même si un faux web de confiance était généré, Alice ne ferait confiance à aucune de ces clés, car elle aurait besoin de sa propre clé privée pour la signer (et Alice l'a protégée clé avec un mot de passe aléatoire fort que Eve ne connaît pas).
Si Alice conserve la clé publique de son correspondant dans une base de données, une feuille de calcul, un document texte; alors il est possible que votre scénario fonctionne.
Cependant, la plupart (y compris Alice, espérons-le) ne feraient confiance qu'aux clés publiques qui ont été certifiées authentiques. Il existe actuellement deux méthodes principales par lesquelles cela est fait:
Certifié par une autorité centrale
La clé publique est certifiée par une organisation spécialement mise en place pour cette tâche - elles sont appelées Autorités de certification (CA).
L'AC aura vérifié les informations d'identification de Bob quand il leur a demandé de certifier sa clé publique. Bob peut ensuite envoyer sa clé publique certifiée (communément appelée certificat) à Alice et à ses nombreux autres amis/collègues.
Si Alice approuve uniquement les clés publiques qui ont été certifiées par des autorités de certification approuvées, votre scénario échoue maintenant. Vous ne pouvez pas vous faufiler dans votre clé publique car elle n'a pas été certifiée et par conséquent Alice ne lui fera pas confiance.
Vous pouvez contacter l'autorité de certification avec votre clé publique, mais ils certifieront seulement qu'elle vous appartient - pas à Bob (ou Alice, ou à quelqu'un d'autre).
Cette méthode est utilisée par les autorités de certification commerciales qui signent les certificats utilisés pour affirmer l'identité des ressources sur Internet (comme ce site). Les organisations peuvent également exploiter leurs propres autorités de certification.
Certifié par des amis et/ou collègues
Une alternative à la méthode ci-dessus consiste pour Alice à confirmer avec des amis/collègues qui correspondent déjà avec Bob si sa clé publique est authentique. Ils le sauront en confirmant avec d'autres, ou en confirmant avec Bob lui-même (peut-être une réunion en face à face). De cette façon, la confiance se propage comme une toile d'araignée, ce qui fait que ce concept est appelé web-of-trust .
Cette dernière méthode est utilisée par Pretty Good Privacy et Gnu Privacy Guard.
L'AC n'est cependant pas la clé du problème. Dans votre scénario, vous avez compromis l'appareil d'Alice, ce qui signifie que vous pouvez configurer son appareil pour qu'il approuve les clés publiques certifiées par une autre autorité de certification - la vôtre. Vous pouvez maintenant certifier que votre clé publique est masquée, car Bob et Alice lui feraient confiance sans le savoir.
Cependant, les autorités de certification prennent tout leur sens lorsque nous nous écartons légèrement de votre question et considérons que "Bob" n'est pas une personne, mais plutôt une nouvelle ressource sur un réseau extrêmement vaste tel qu'Internet. Dans de tels cas, le modèle Web-of-Trust ne fonctionnerait pas simplement en raison de l'ampleur du problème de gestion de toutes les clés publiques.
En d'autres termes, une autorité de certification ne serait pas très avantageuse dans un scénario qui consiste en une seule relation un à un, comme Alice et Bob dans votre question, car cela modifie simplement le test qu'Alice fait implicitement à partir de Est-ce que je fais confiance à la clé publique de Bob? à Ai-je confiance que mon appareil n'a pas été configuré pour faire confiance à des autorités de certification supplémentaires?
Cependant, dans une relation un-à-plusieurs, comme Internet, une autorité de certification supprimera l'obligation de vérifier en quelque sorte chaque clé publique avant utilisation et la remplacera par une vérification de la configuration de votre appareil (ce que nous faisons tous sans aucun doute! ).
Bien sûr, dans le monde réel, si vous comprenez avec succès l'appareil d'Alice, que vous changiez la clé publique de Bob est sans importance dans l'ensemble.