11

From my understanding of PGP email, the following is possible:

Alice sends a message to Bob. Then Bob can take that exact same message and send to Carol while making it seem to Carol like it is from Alice to her.

This could be prevented if the standard were to also sign the recipients along with the email.

My question is: is there a standard practice to protect against such replay attacks?

  • So Bob is recieving the message, not changing / reading it (since encrypted) and then forwarding it to Carol, without her noticing, that there was someone in the middle? There seems to be no direct attack involved here, except for Bob knowing, that Alice has sent Carol a message at a certain time and with a certain size. – hamena314 Apr 1 '16 at 11:30
  • If the message is encrypted for Bob, then no, Carol would notice. By not being able to read it. – Tobi Nary Apr 1 '16 at 11:34
  • Isn't it the case that when Bob decrypts the message, when he decrypts the message, he gets the message and the signature, he can then encrypt it with Carol's public key, but the signature from Alice still remains? – user45150 Apr 1 '16 at 11:38
  • @user45150, nope. – Tobi Nary Apr 1 '16 at 11:40
  • 2
    Note that what you are describing isn't really a replay attack, but rather a variation of an impersonation attack. – a CVn Apr 1 '16 at 11:41
13

Your argument is valid, with Sign & Encrypt method, the 2 layers are independent and this gives you (as Bob) the ability to re-encrypt Alice's message while the signature is still in place and forward it to Carol.

One other option would be to Encrypt then Sign but there's also a vulnerability in this approach. Bob or any eavesdropper can remove the signature and add his own signature. Without knowing the contents of the encrypted message he can impersonate himself as the sender of the message.

There are numerous discussions on SE so I won't get into them. e.g: Should we sign-then-encrypt, or encrypt-then-sign?

The solution has to add a binding between the signature and the encryption layer because the vulnerability lies in the gap where these two independent layers are.
And as you said we could add the recipient's address into the encrypted part of the message.

In this Page (Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML ) in section 5, five repair options are proposed:

  1. Sign the recipient's name into the plaintext
  2. Encrypt the sender's name into the plaintext
  3. Incorporate both names
  4. Sign again the signed-&-encrypted message
  5. Encrypt again the signed ciphertext.

For Naming Repairs solutions:

Perhaps part of the reason naïve Sign & Encrypt seems secure is that with many common payload messages, S&E is secure. For example, even if Alice just signs and encrypts the text ``Dear Bob, The deal is off. Regretfully, Alice,'' then Alice's message is secure, albeit only accidentally so. The presence of names under both crypto layers is crucial, but including both names is not strictly necessary

Using Sign/Encrypt/Sign:

Inner Signature: "Alice wrote the plaintext;"
Encryption: "Only Bob can see the plaintext;"
Outer Signature: "Alice used key B to encrypt."

Using Encrypt/Sign/Encrypt:

First Encryption: "Only Bob sees the plaintext;"
Signature: "Alice wrote the plaintext and the ciphertext;"
Outer Encryption: "Only Bob can see that Alice wrote the plaintext and ciphertext."

You can also find the analysis of cost/benefit under that link, the simplest repair is adding recipient's address to the plaintext and then Sign and Encrypt.

Going back to your main question, there seems to be no standard implementation for PGP clients to add/verify recipients address in the ciphertext, so one could go ahead and manually add/verify the address into the message body.

  • 3
    Bah, you beat me to it, can you at least use the *pretty* picture I made? i.stack.imgur.com/NXihC.png – Mike Ounsworth Apr 1 '16 at 12:13
  • @MikeOunsworth In the "pretty" picture you made lies another vulnerability, while the replay attack is no longer valid, an eavesdropped can remove Alice's signature and sign it under his own name claiming that he's the sender of the email. – Silverfox Apr 1 '16 at 12:21
  • aww but, .... good point :-( – Mike Ounsworth Apr 1 '16 at 12:26
3

This is prevented by simply, using proper human communication.

Normally, you begin a message with like:

"Hello Bob
Nice to hear from you again.
bla bla bla"

Thus Carol, would easily to detect this disrepiancy since the message is not adressed to him/her, and would of course ask Alice "Did you send this to me? Then you have the wrong adress." and Alice would say "No, I didn't send it to you, the message must have been leaked and replayed."

Note that the "Hello Bob" should be part of the signed portion, and thus is inmodifiable by the attacker.

If you don't know the name or intended recipient of the mail, then its normal to make the content stand out in a specific way to make it clear that its intended for someone specific, so if the message lands in the wrong inbox, the receiver will understand the message was not intended for her.

A example, could be if you are sending a message to "support@random_isp.com"

"Hello.
My broadband account just got suspended, my RandomISP customer number is 153424.
Could you check my account details if the latest bill payment has arrived and whats happened if not."

If this mail would land in your inbox, it would be clear that its not intended or sent to you.


Also note that theres other systems like SPF and DKIM, which will verify and prevent the usage of the sender's email adress, which would in this case also give away any replay attempt, since the sender email would not match the public key that correspond to the private key the mail was signed with.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.