Comment prévenir une crise MITM sur le serveur

Question

Deux clients Alice et Bob utilisent un serveur pour vous connecter et d'échanger des messages via le serveur. En connexion, ils ont tous deux envoyer leurs clés publiques pour être stockées sur le serveur. Quand Alice veut parler à Bob, elle enrypts une clé symétrique avec la clé publique de Bob et il envoie à Bob via le serveur.

Comment puis-je faire en sorte que le serveur ne fait pas sa propre clé publique paire et l'envoyer à Alice au lieu de la clé publique de Bob. De cette façon, le serveur va d'abord déchiffrer ce que Alice a envoyé et chiffrer à nouveau en utilisant la vraie clé publique de Bob.

Merci

Answer 1

Depuis Alice et Bob ne peut pas faire confiance au serveur, ils doivent trouver une autre façon de confirmer les clés de chacun. Une possibilité est compter sur une autre partie. Si Bob fait confiance Candice (et connaît la clé publique de Candice), qui connaît Alice, Candice peut signer la clé publique d'Alice puis envoyer la version signée à Bob. Ceci est appelé web de confiance .

Answer 2

En ayant le certificat de Bob signé par un tiers de confiance (Verisign, votre société, un réseau de confiance, etc.), ou en ayant Bob envoyer son certificat à Alice par un chemin sécurisé séparé hors bande (lui tendant une clé USB clé en personne, par exemple).

Ces deux dans le vif de ce que le certificat de Bob est censé signifier. Vous faites confiance seulement que le certificat de Bob est le certificat de Bob parce que quelqu'un vous avez confiance a certifié il. Ce « quelqu'un » peut être Bob lui-même ou un tiers de confiance qui signe le certificat de Bob. Vous ne pouvez jamais faire confiance à ce autant que vous faites confiance au certificateurs.

Answer 3

En cryptographie, vous êtes ce que vous savez. Si vous voulez éviter MITM, alors Alice doit avoir une idée de qui « Bob » est, ce qui signifie que Bob doit savoir un élément de données qu'un attaquant ne sait pas. Ici, votre attaquant est le serveur, qui est idéalement situé pour monter une attaque.

La question est: qui est Bob? Comment est le serveur "non-Bob"?

peut être définie, par exemple, « Bob » comme: « Bob est un être humain qui a un permis de conduire avec « Bob » écrit dessus ». Ou: « Bob est ce gars-là, j'ai rencontré dans un bar et bu une bière avec »

.

L'utilisation de la cryptographie asymétrique vous permet de réduire le problème à une question de confiance dans une clé publique. Alice utilisera ce qu'elle croit être la clé publique de Bob. Par conséquent, Alice n'a besoin que d'une certaine façon de vous assurer que la clé publique, elle a en effet est la propriété de Bob. La propriété d'une clé publique est définie par le contrôle de la clé privée correspondante: la clé publique de Bob est la clé pour laquelle la clé privée est sous le contrôle exclusif de Bob (par exemple, que Bob sait que la clé ou la clé privée est un jeton matériel - une carte à puce -. que Bob conserve dans son portefeuille)

La solution de base est d'avoir un échange direct de la clé publique. Quand Alice a rencontré Bob dans un bar, ils se donnaient leurs clés publiques. Ainsi, Alice peut faire confiance à la clé publique de Bob « par définition ». Pour un échange plus facile (surtout après quelques bières), Alice et Bob peuvent échanger seulement des « empreintes », à savoir des valeurs de hachage calculées sur les clés publiques. Ces valeurs sont plus courtes que les clés publiques (par exemple 128 bits, au lieu de plus d'un millier de bits pour un RSA typique clé publique) et sont suffisantes pour vérifier que un matchs à clé publique donnée. Dans cette configuration, le serveur dispose d'un dépôt pour les clés publiques et Alice et Bob ne recalcule les empreintes digitales pour vous assurer que le serveur ne joue pas des jeux bidon.

Une solution plus avancée, ce qui réduit la nécessité pour la consommation d'alcool directe, est d'utiliser des certificats . Un certificat est une boîte qui contient une identité (par exemple un nom, tel que « Bob ») et une clé publique. La boîte est signée par un autorité de certification (CA): le CA affirme que la clé publique appartient vraiment à Bob, en appliquant sa signature. Si Alice connaît le CA clé publique, elle peut alors vérifier la signature sur le certificat, et gagner ensuite la confiance dans le lien entre la clé publique et l'identité contenue dans le certificat.

La certification est la délégation de confiance. Alice délégués sa confiance à l'AC; soi-disant, l'autorité de certification (appelons-le Charlie) est allé au bar pour rencontrer Bob; par le certificat, Charlie dit Alice: « ouais, c'est vraiment la clé de Bob, il me l'a montré après sa troisième pinte ». Les choses deviennent un peu glauque ici, parce que la délégation de la confiance est pas facile (surtout si Charlie est l'habitude de beuveries). La délégation peut aller plus loin, lorsqu'un CA signe un certificat pour une autre CA. Ici, Charlie dit à Alice: « Je ne l'ai pas rencontré Bob, mais j'ai rencontré Daphné, qui aurait rencontré Bob et a agi comme une autorité de certification ». Alice, utilisant à la fois le certificat délivré par Charlie à Daphne, et le certificat délivré par Daphne à Bob, peut vérifier que chaîne de signatures.

Le point délicat est ici que si Alice sache Charlie et lui faire confiance dans sa capacité à identifier correctement Bob quand il le rencontre, même sous l'influence d'un gallon de Guinness, Alice ne sait pas Daphne. Dans la chaîne Alice-Charlie-Daphne-Bob, Alice doit non seulement la confiance que Charlie était fiable (il ne identifier Daphne correctement), mais aussi que Charlie était pas crédules, à savoir que Charlie aurait refusé de signer un certificat pour Daphné si Daphné était pas elle-même digne de confiance. Dans des situations pratiques, la confiance se dégrade rapidement lorsqu'elle est déléguée.

Lors de l'utilisation des certificats, il y a surtout deux structures possibles:

• CA hiérarchique: il y a un seul ou quelques « CA racine » qui sont connus par tout le monde par la construction. Un des délégués de CA to une autre CA (il signe un certificat avec, dans l'identité, un drapeau classique qui dit: « cette clé publique peut faire confiance aux fins de la vérification des signatures sur les certificats ») que dans un accord contractuel qui établit les responsabilités juridiques des deux CA en ce qui concerne la certification. Cela signifie que la délégation est formellement définie, et il arrive qu'il ne soit pas facile. Un contrat de certification avocat compatible, généralement appelé un "Énoncé de politique de certification" (CPS), est un long document de 200 pages.

• Web of Trust: tout le monde agit comme une autorité de certification En l'absence de « fiabilité formelle », le rendement de chaque chaîne individuels seulement une très petite quantité de confiance. Ceci est censé être compensé par un très grand nombre. Alice acceptera la clé de Bob seulement si elle peut vérifier plusieurs (nombreuses) chaînes distinctes qui conduisent à Bob, en passant par les participants distincts. Par exemple, Alice exigera la chaîne Charlie-Daphne-Bob, mais aussi les Élie-Fiona-Bob et les chaînes Gerald-Hillary-Ivan-Bob. Ils sont tous les ivrognes, mais ils peuvent être collectivement fiable, en ce qu'un Bob faux aurait à payer beaucoup de tours afin de corrompre un participant de chacune des chaînes que Alice utilise (si Alice a besoin < em> n chaînes avec des certificats distincts, l'attaquant doit corrompre au moins n participants).

l'entreprise de certification est surtout une question de procédure: qui est une autorité de certification, ce CA vérifie avant d'émettre (signature) un certificat, comment tout cela se tient d'un point de vue juridique, et ainsi de suite. Ces procédures sont complexes et doivent être pris en charge par des détails dans le format de certificat (comme le drapeau « cette clé publique est une clé de CA »). Les deux principaux formats standards actuellement définis sont X.509 et PGP . X.509 a beaucoup de soutien pour l'autorité de certification hiérarchique, et est un gâchis très embrouillée des normes, des formats, des pratiques et des comités. PGP (normalisé sous le nom de « OpenPGP ») n'a pas de soutien réel pour CA hiérarchique; il est destiné à être utilisé avec un Web de confiance. OpenPGP est plus simple que X.509 mais plus limité, surtout si vous souhaitez avoir une forte signification juridique derrière les certificats.

Pour un serveur de messagerie instantanée, tout cela est susceptible d'être surpuissant. La notion d'identité que Alice veut vraiment est sans doute une notion de répétition : « que Bob est le même Bob que celui que je bavardais avec hier ». Alice ne sait pas Bob l'avance, mais en parlant avec lui établit une fois son identité dans l'oeil d'Alice. Elle veut tout simplement pas se laisser berner par un autre Bob. Pour cela, un processus simple comme « le logiciel Alice enregistre la clé publique annoncée de tout nouveau bavardage, et l'utilise ensuite » fera l'affaire. Rappelez-vous que la question clé est de bien définir quelle notion d'identité que vous recherchez.

Answer 4

À moins que vous contrôlez le serveur que vous ne pouvez pas. À moins bien sûr que vous connaissez déjà la clé publique de Bob mais .... Je pense que vous êtes dans le problème de la poule et de l'oeuf ici.