EFail mitigations for S/MIME

[Andre Heinecke]

Hi,

On Wednesday, May 16, 2018 4:15:45 PM CEST martijn.list wrote:
> On 15-05-18 14:31, Andre Heinecke wrote:
> > - Any hash over the plaintext.
> > 
> > To get such a hash we can most easily use a signature, regardless of any 
trust
> > in the signature. The hash does not need to be encrypted.
> > 
> > If we have no hash we won't offer to save a decrypted file from a GUI or 
show
> > it in an HTML enabled mail client. This would disallow encrypt, then sign
> > schemes but in practice everyone uses sign then encrypt anyway.
> 
> Adding a hash will not help in the general case because other S/MIME 
> clients will not support it.

I don't propose to extend the standard. I would only reuse the the hash of a 
multipart/signed part in an S/MIME mail or from a signature in the case of 
files.

> I have done some experiments with the "Generic exfiltration" attack and 
> have been able to replicate the attack. Injecting new blocks is easy. 
> However after every injected block, there is a block of random data. 
> This block of random data can be used to detect whether the message was 
> attacked with EFAIL in most cases. The S/MIME RFCs strongly suggest that 
> every MIME part should be 7-bit. If a decrypted message therefore 
> contains data > 127 or < 32 excluding CR/LF/TAB, the message might have 
> been injected with additional blocks. For the "Generic exfiltration" 
> EFAIL attack, you need at least 2 blocks of data so there will be at 
> least 32 bytes of random data. The changes that all those bytes fall 
> within the 7-bit range is slim so I think this check would work to 
> detect most (if not all) EFAIL attacks. The only problem you might run 
> into is if a sender encrypted a message containing 8-bit characters 
> (i.e., the message was not canonicalized to 7-bit).
> 
> I have written a short blog item about this here
> 
> https://www.ciphermail.com/blog/efail-how-to-detect-you-are-being-attacked.html
> 
> Any comments on whether this will work?

From your blog it sounds like this is only specified for multipart/signed 
inside the encrypted part. If it is signed can't you just check the signature 
and only show the signed parts?

Also for Gpg4win I'm thinking a bit about files. We offer through Kleopatra CMS 
file encryption, which would have similar problems :-/ .


Best Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180517/02f3a4e4/attachment.sig>