Comme Steffen l'a déjà dit, le talon d'Achille de votre sécurité est de vous assurer que vous parlez à Joe, et que Joe est sûr qu'il vous parle. Si l'échange de clé initial est compromis, le tiers pourra lire vos messages, les rechiffrer et les envoyer à Joe, et vice versa.

La crypto n'a pas d'importance à moins que vous ne résolviez ce problème. C'est pourquoi dans le monde HTTPS, il existe une entité spéciale appelée CA (autorité de certification). L'autorité de certification doit s'assurer que Google ne peut pas obtenir de certificat pour Facebook, etc. Ainsi, à moins qu'une autorité de certification non autorisée n'émette le certificat, vous pouvez accéder à Google et être sûr que vous êtes sur Google.

Le transfert de clé initial est le plus critique, et cela peut être fait de plusieurs manières:

• en personne
• par message hors bande (tweet, publication Instagram, courrier postal)
• parrainé par un ami en commun (vous Connaissez Bill, faites enregistrer sa clé, et Bill vous connaît tous les deux et partage les deux clés)

Après cet échange, votre configuration est assez solide.

S'ils décident de manipuler mon e-mail initial, en changeant la clé que j'ai envoyée à Joe, la réponse de Joe sera illisible par moi, car elle n'est plus chiffrée à l'aide de ma clé publique, mais de la clé interceptée par Google. Cela signifie que Joe et moi n'aurons aucune conversation au-delà de cet e-mail initial ...

Tant que vous pouvez être sûr qu'ils ne peuvent qu'intervenir le courrier initial alors c'est vrai. Mais s'ils peuvent également gérer les e-mails suivants au milieu, ils pourraient simplement déchiffrer le message de Joe car il leur a été chiffré et peuvent le chiffrer à nouveau pour vous car ils connaissent votre clé publique.

Pour configurer une communication sécurisée pour le courrier électronique, vous devez déjà disposer d'un autre canal de communication sécurisé pour échanger ou au moins vérifier la clé publique, car sinon un MITM pourrait simplement réclamer ces identités et personne ne pourrait le détecter.

Cette approche est très sécurisée dès que vous pouvez faire confiance au fournisseur de messagerie (à savoir, Google).

Toutes les autres réponses sur les attaques MITM sont vraies en général. Dans ce cas particulier, lorsque vous travaillez avec le même fournisseur, des considérations supplémentaires peuvent être apportées avec succès.

1. On ne peut pas (facilement) se faire passer pour Joe

Depuis une dizaine d'années, n'importe qui peut vous envoyer un e-mail spécialement conçu en provenance d'un "gars nommé Joe", ou même de donaldjaytrump @ whitehouse .gov avec ce qui semble être la clé publique de Joe. Les plus petits fournisseurs (très, très, petits serveurs de messagerie) peuvent ne pas appliquer la politique SPF.

Dans le même fournisseur de messagerie, et c'est vrai pour Gmail, des vérifications supplémentaires sont effectuées pour garantir personne ne peut falsifier une adresse d'expéditeur Gmail. Il faut pirater le compte de Joe, ce qui est hors de portée.

En bref, supposer que Joe ne peut pas être piraté est suffisant pour dire que Joe ne peut pas être usurpé par un tiers malveillant et par courrier venant de Joe vient vraiment de Joe du compte de messagerie de Joe.

2. Vous (devez) faire confiance à votre propre fournisseur

Puisque vous utilisez le même fournisseur, je dois supposer que vous lui faites confiance. Peu importe à quel point Google, dans ce cas particulier, est digne de confiance, du point de vue de la sécurité, il reste un vecteur d'attaque. Le fournisseur doit être suffisamment malhonnête pour changer la clé publique de Joe avec une clé publique falsifiée pour interrompre la communication sécurisée.

Ce que je veux dire, c'est que le seul acteur capable de briser la sécurité de votre conversation est Google Inc. eux-mêmes, car à la fois du point 1 et parce que les e-mails ne quittent pas leurs propres systèmes.

Répondre à vos préoccupations

Google connaît ma clé publique (mais pas celle de Joe, car elle est intégrée à l'objet blob chiffré). Cela n'a pas vraiment d'importance, n'est-ce pas? Ils ne peuvent rien faire avec ma clé publique? La seule chose pour laquelle il peut être utilisé est de crypter du texte dans un sens que je suis le seul à pouvoir décrypter, car je n'ai que la clé privée sur mon ordinateur?

En supposant une rupture du point 2, Google peut usurper l'identité de vous et modifier votre propre clé publique avec une clé qu'ils connaissent, et rechiffrer et signer à nouveau le message à leur gré.

Ils n'ont qu'une seule chance d'agir, et c'est votre premier e-mail "Bonjour Joe, ceci est ma clé publique ABCDEF"

S'ils décident de manipuler mon e-mail initial, changer la clé J'ai envoyé à Joe, alors la réponse de Joe sera illisible par moi, car elle n'est plus cryptée à l'aide de ma clé publique, mais de la clé interceptée de Google. Cela signifie que Joe et moi n'aurons aucune conversation au-delà de cet e-mail initial de ma part et de la première réponse de lui (que Google peut lire), mais après cela, rien ne se passe car je ne peux pas lire / décrypter sa réponse?

Google devra écouter et transcoder les messages que vous échangez. Si cela se produit, vous ne pourrez pas détecter l'attaque, car les deux ont initialement fait confiance à la mauvaise clé.

Exemple de courriel MITM (avec Alice, Bob, Charlie)

Charlie est un fournisseur de services de messagerie non autorisé

Alice (via Charlie):

Bonjour Bob, voici ma clé publique ABC983 (matériel clé attaché)

Charlie génère une nouvelle paire de clés et remplace le message

Bonjour Bob, ceci est ma clé publique ZZZ765 (matériel clé attaché)

Bob reçoit le texte, crypte un nouveau message avec la clé ZZZ765 , qui est une clé non autorisée, et stocke ZZZ765 dans sa banque de confiance. Envoie ensuite l'e-mail suivant à Charlie pour livraison

Ravi de vous rencontrer Alice, veuillez utiliser DEX258 comme clé.

--- Chiffré avec ZZZ765, signé avec DEX258 ---

Charlie intercepte l'e-mail, déchiffre en utilisant ZZZ765 pour obtenir le texte en clair, puis génère encore une nouvelle paire de clés.

Charlie livre l'e-mail suivant à Alice

Ravi de vous rencontrer Alice, veuillez utiliser FGN754 comme clé

--- Chiffré avec ABC983, signé avec FGN754 ---

Alice fera confiance à la clé non autorisée FGN754 dans leur magasin de confiance.

Les deux parties jureront qu'elles ont véritablement parlé chacune d'autres en toute sécurité jusqu'au jour où ils se rencontrent dans un bar, en personne.

À leur grande surprise, ils découvriront qu'ils ont utilisé les mauvaises clés et que les e-mails d'origine diffèrent de leur dossier "Messages envoyés". l'histoire

Dans votre scénario, la clé PGP que vous envoyez à Joe peut être manipulée pendant le transport, et Joe ne pourra pas la remarquer à moins que vous n'utilisiez l'une des approches de solution intégrées à PGP :

L'échange initial de clé publique est crucial, mais il existe des solutions. Pour les certificats X.509 (utilisés pour S / MIME), ce même problème est résolu à l'aide d'autorités de certification organisées de manière hiérarchique. Dans ce système, un certificat peut être approuvé s'il est signé par une autorité de certification approuvée. L'approche PGP est le Web de la confiance qui signifie plus ou moins que n'importe qui peut signer une clé, et si cette signature peut être approuvée ou non dépend de votre confiance personnelle dans le signataire.

Donc, pour postuler ce mécanisme à votre problème, si votre clé est signée par un tiers auquel Joe fait confiance, il est alors impossible de manipuler la clé en transit d'une manière qui passerait inaperçue car le manipulateur ne pas pouvoir signer la clé manipulée au nom du tiers. Notez que si la clé est signée par un tiers de confiance, elle peut être obtenue à partir de n'importe quelle source, et c'est ainsi que les serveurs de clés PGP sont censés fonctionner.

S'il n'y a pas de tiers de confiance par vous ou Joe, vous pouvez toujours envoyer votre clé publique à Joe, mais vous devrez vérifier que la clé reçue par Joe n'a pas été modifiée en cours de route d'une autre manière. Pour ce faire, vous pouvez lui indiquer l ' empreinte digitale de votre clé , mais vous devrez le faire sur un canal indépendant. Par exemple, il n'est pas inhabituel de publier l'empreinte digitale sur un site Web. À moins que ce site Web ne soit hébergé par Google, il est très improbable qu'il puisse être manipulé pour s'adapter à la clé manipulée.

Cela crée une opportunité unique pour un attaquant de MITM (homme au milieu) d'échanger votre certificat et d'en proposer un autre à la place. En théorie, ils pourraient intercepter et transférer chaque message que vous envoyez de nouveau chiffré avec la nouvelle clé de l'attaquant. Cependant, il existe plusieurs facteurs atténuants.

Si vous utilisez tous les deux le client de messagerie Web pour gmail, il y a peu de chances pour un attaquant de jouer avec votre e-mail, même si SMTP n'est pas vraiment très sécurisé.

Après l'échange de clés, vous saurez que vous envoyez un mail à la même personne , qu'elle soit attaquante ou légitime. C'est essentiellement une confiance lors de la première utilisation, il n'y a plus aucune possibilité d'attaque.

L'attaquant devrait essentiellement MITM tout si vos e-mails, s'ils étaient constamment perdus, ce serait un rouge flag.

Il y a des suggestions selon lesquelles la clé entière doit être échangée dans un canal sécurisé, c'est faux . Vous pouvez envoyer le bloc de clé publique par e-mail, puis appeler ou vous rencontrer en personne pour échanger l'empreinte numérique du certificat - un hachage sécurisé de la clé - afin de vérifier qu'elle est valide.

Comme d'autres l'ont souligné, dans votre scénario, Google est en mesure d'être un homme du milieu pour votre message initial envoyant votre clé publique à Joe. Une chose qui peut être utile est de publier votre clé publique dans plusieurs emplacements. Ainsi, vous publiez votre clé publique sur votre site Web (non hébergé par google), sur github et facebook et hacker news et reddit et stackexchange et sur plusieurs serveurs de clés publiques, ou sur un panneau d'affichage ou une annonce dans le New York Times ou un post dans un groupe de discussion anonyme ou un forum aléatoire ou autre (et en fait, des services comme keybase.io vous permettent de lier beaucoup de ces choses à votre clé publique pgp avec une signature vérifiable). Ensuite, vous pouvez lister tous les endroits où vous mettez votre clé publique et signer tout le message avec la même clé. Il est peu probable que Google, ou n'importe qui d'autre, puisse modifier tous ces endroits.

Cependant, étant donné que Google possède également une autorité de certification de confiance et que le navigateur Chrome de Google est également largement utilisé, si Google voulait vous cibler, il semble possible qu'il puisse faire en sorte que son navigateur fasse confiance à la version modifiée de n'importe quel site public. . Pour ce faire, ils devraient soit émettre un autre certificat à tous les sites tiers qui ont répertorié votre clé (et la transparence des certificats est conçue pour atténuer ce type d'attaque), soit faire un peu de post-téléchargement manipulation dans Chrome, et même cela serait facile à détecter en comparant la sortie dans Firefox et Chrome.

C'est exact. La clé publique est librement distribuable. Toute personne disposant de votre clé publique peut crypter les messages et vous les envoyer. Seule la clé privée (que vous ne devez jamais distribuer) peut décrypter les messages.

• Public Key = Encrypt
• Private Key = Decrypt

Cependant, la limitation est que si vous envoyez votre clé publique à quelqu'un, il ne peut crypter que les messages qui vous sont envoyés. Il s'agit d'un schéma de cryptage unidirectionnel et pas totalement sécurisé car n'importe qui peut intercepter et lire les messages non cryptés que vous envoyez à quelqu'un d'autre. Vous devrez également obtenir sa clé publique pour pouvoir chiffrer les messages que vous lui envoyez.

Un utilisateur peut intercepter un message chiffré mais il n’est pas possible de lire les messages chiffrés à l’aide de la clé publique dans la mesure où Je sais. Je pense que ce à quoi les autres font référence, c'est si vous communiquez avec Joe et qu'un troisième utilisateur, Sam, est présenté. Si Sam a votre clé publique, il pourrait potentiellement vous envoyer un message chiffré en faisant semblant d'être Joe. Vous savez probablement toujours que Sam n'est pas Joe parce que leurs clés publiques ne sont pas les mêmes et / ou que vous n'avez pas la clé publique de Sam. Si vous essayez de renvoyer un message chiffré à Sam, cela ne fonctionnera pas.

La plupart des utilisateurs occasionnels de messagerie n'ont pas de paire de clés privée / publique pour envoyer des e-mails chiffrés. Je suis sûr que même s'ils le faisaient, cela serait rapidement bloqué par leur fournisseur de messagerie et la NSA, car il n'est pas possible d'intercepter le message, de lire ce qu'il contient et de prendre le dessus sur eux.

Comme beaucoup de choses dans la vie, la réponse est oui et non .Pour vos questions:

1. Vous avez raison, il n'y a aucun problème à savoir que le monde connaît votre clé publique - c'est pourquoi elle s'appelle clé publique
2. Non, vous faux là-dessus. Étant donné que votre fournisseur de services contrôle votre service, il peut agir comme un parfait homme au milieu et intercepter toutes vos correspondances avec Joe. Maintenant, si votre fournisseur de services intercepte ces e-mails et les empêche d'atteindre votre boîte de réception alors que Joe croit qu'il est en relation avec vous et que les e-mails entre vous et lui sont privés, et que vous pensez qu'il ne se passe rien entre Joe et vous, eh bien .... maintenant Joe partage ses pensées privées avec quelqu'un qui n'est pas vous :(

Conclusion: Vous feriez mieux d'envoyer votre clé publique via un canal différent, un canal qui ne peut pas intercepter vos conversations.