PGP Man in the Middle Attack

By RSnake (October 04, 2004)

There is a fairly major hole in PGP that I have not seen published to date. PGP is based on IDEA and is an asymmetric public algorithm. The problem, as is true with most cryptographic implementations, is the implementation itself, not the algorithm.

Assume:
Alice = (message sender who has a compromised network)
Bob = (message recipient)
Cathy = (wo/man in the middle)

In a normal environment, under the best circumstances, Cathy is a MITM after the fact, and PGP is not vulnerable to MITM attacks:
  • Alice generates a public and a private key
  • Bob generates a public and a private key
  • Alice transmits her public key to MIT's PGP server attached to the name alice@company-a.com
  • Bob transmits his public key to MIT's PGP server attached to the name bob@company-b.com
  • Alice looks up Bob's public key and encrypts her message with it
  • Cathy attains MITM status and awaits message transmission
  • Alice transmit encrypted data
  • Cathy cannot read the email, and cannot modify it without changing the digital signature
  • Bob recieves the message, verifies the message against Alice's public key signature and is assured of it's validity.
However, because MIT's PGP server (and other servers and implimentations as well) does not do any verification this opens the door for MITM attacks.

Let's assume in this scenario that Cathy has access to either Alice's or Bob's network (classic MITM) before either start transmitting keys.

  • Alice generates a public and a private key
  • Bob generates a public and a private key
  • Alice transmits her public key to MIT's PGP server attached to the name alice@company-a.com
  • Bob transmits his public key to MIT's PGP server attached to the name bob@company-b.com
  • Cathy attains MITM status and generates her own keys also called alice@company-a.com and bob@company-b.com
  • Cathy sends Bob a message from Alice's account with a link to the PGP key server (with the fake alice@company-a.com key). MIT does not verify that those keys actually belong to Alice and Bob, and there would be no way to effectively do that without possible interception by Cathy by at least one, if not both of the users. MIT's PGP server (like all others I've seen) also does not use SSL, making additional MITM attacks possible.
  • Bob looks up the link, verifies that it's accurate, because it does in fact have Alice's email address in it, and then sends an email back to Alice with his real public PGP key
  • Cathy intercepts this message and sends Alice a link to the PGP key server (with the fake bob@company-b.com key)
  • Alice verifies this key does, in fact, belong to bob@company-b.com, even though it is fake and trusts it is valid
  • Alice encrypts her message with Cathy's fake bob@company-b.com key and sends it to bob@company-b.com
  • Cathy intercepts this message, decrypts it with her secret key, reads it, re-encrpyts it with Bob's real public key and sends it on from Alice's account
  • Bob recieves the email, decrypts it with his secret key and is not aware of message tampering.
As in all forms of symmetric key exchange, even asymmetric key exchange is fallable when it comes to key servers. You must trust that they key server itself is not compromised to give different keys depending on who sees it, and it must return the correct key in MITM attacks. This is less likely in an intra-corporate communication environment, but is much more likely in cross organizational cases, where a public key server is used.

The foundation of trust is another problem. If Bob looks at the certificate, it is possible that even it is signed by other people he knows (all of whom are being attacked in the same manner). Although this scenario is less likely, it is possible.

The basic issue is that the user must transmit a public key somewhere, and any location can be compromised. Consider another scenario where Bob puts his public key on a webserver that only he controls. When Alice connects to it from her compromised network, Cathy simply displays a different key to Alice. There is no easy way around this form of attack, other than out of band mechanisms, where Cathy has no control.

I have spoken with a few people about this who believe this is may only be a minor issue. However, being that the entire reason PGP was invented is to prevent eavesdropping, and this method allows for a 100% seamless MITM attack, and most importantly considering the widespread use of this application this is the largest issue today in any wide-spread asymmetric cryptographic implementation.

Note: Some people have commented that I am "ignorant" of the web of trust concept. Clearly these individuals have not read my paper (or at least not with an open mind). This is a hole in situations where you do NOT know the person or anyone they know. To quote myself, "In a normal environment, under the best circumstances, Cathy is a MITM after the fact, and PGP is not vulnerable to MITM attacks." This is only a vulnerability in new communications with people you don't know (or don't know well) and to whom you have no common friend.

Also it should be noted that the web of trust concept only works on keys that aren't new. How many times have you asked someone, "Please go install PGP." so that you could communicate with them securely? These are the users with whom communications are vulnerable. For instance, to my knowledge no one has ever signed any of my keys. I wouldn't have written this paper if I hadn't been able to do this myself bringing it beyond the theoretical and into the practical. To these individuals, please read the paper before you pass judgement.

Written in vim, W3C valid and UTF-8 encoded, for her pleasure.
All rights reserved, all wrongs observed.
© 2001-2014 RSnake