We point out a newly discovered flaw in the S/MIME specification, which forms the basis for the secure exchange of emails based on X.509 certificates and is implemented by all major email clients. Specifically, we show that the claim of S/MIME to reach message integrity through signatures is not reached. The result is that an attacker may perform what we refer to as a "message takeover attack". In its simplest form, it leads to the disclosure of the content of a signed and encrypted message. With the cryptographic layer being broken, the concrete exploitability depends on the strictness of an S/MIME conforming client's MIME parsing.

This section explains the concept of the message takeover attacks against S/MIME very briefly. For those readers familiar with all the involved technologies this might already be sufficient information in order to understand the principle, for all others it serves as a reference to come back to after having read the remainder of this post.

The following figure shows the procedure of the message takeover attack.

The setting is that Alice wants to send a signed and encrypted email with secret content to Bob using S/MIME. As it is the common standard today, her email client produces the email in the signed-then-encrypted format. Eve, the attacker, blocks the original email from Alice to Bob (1). She captures the message, and removes the signature within the encrypted message which is possible due to the missing integrity protection of the S/MIME encryption (3). Then she applies an outer signature on the message (4) using her own certificate, which results in the also valid encrypted-then-signed S/MIME format. She sends this email to Bob (5), who replies to it with the message history (6), and Eve learns the secret content of the email.

S/MIME, building on the CMS standard, relies on what is referred to as "naive sign & encrypt", meaning that messages are protected by a combination of digital signature and encryption, based on public-key certificates. Here, S/MIME is especially flexible, in that it allows any order and any nesting of signature and encryption.

Fifteen years ago, Don Davis has already summarized a number of shortcomings in S/MIME and other standards that rely on naive sign & encrypt. One point of critique was that S/MIME messages that are encrypted-then-signed, are vulnerable to a trivial form of message takeover attacks. Here, Alice sends an encrypted-then-signed message to Bob, Eve blocks the message, removes the outer signature, replaces it with her own signature and forwards it to Bob.

In this way, even in the setting where Bob only accepts signed emails, Eve is capable to inject messages to him as originating from her which were originally authored, signed, and encrypted by Alice. This potentially leads to a number of practical attacks, however, here we only point out that if Bob replies to the message, i.e. to Eve’s email account, with the message history, possibly in an encrypted email, Eve learns the contents of the message from Alice to Bob. Bob might also disclose other information based on the believed legitimation of Eve which he might conclude from her allegedly displayed knowledge in the forged email.

As a consequence, today's email clients usually produce messages only in the sign-then-encrypt format, probably in the believe that this solves the problem. In the following we learn that this is not the case. First, however, we look in some more detail into how S/MIME realizes encryption.

The encryption in S/MIME is done using a block cipher, i.e. 3DES or AES, in CBC mode. This is a bad decision since this scheme does not at all protect the integrity of the ciphertext. As we see in the following, very targeted manipulations are possible on CBC ciphertexts. At the time of writing of the early versions of the S/MIME specification, the necessity of integrity protection of encrypted messages was not known, however, in the meantime, since about the year 2000, it became known that for the protection against certain active attacks, encryption schemes need this feature in order to achieve confidentiality of the messages in real world scenarios. This is for instance achieved by using what is referred to as authenticated encryption.

However, the S/MIME standard, even in its latest version from 2010, ignores this development. Instead, it explicitly states "It is important to note that sending enveloped but not signed messages does not provide for data integrity." As we learn today, this is a wrong claim. But even without the knowledge of the non-trivial message takeover attacks against sign-then-encrypt, which are introduced in the following, it is also a mistake to rely on signatures for the message integrity. The reason is that it unnecessarily reduces the usability of the scheme, since thereby even an entity that merely wishes to send integrity protected encrypted messages needs a certificate that is recognized by the recipient.

The symmetric encryption that is used by S/MIME capable email clients is generally a block cipher in CBC-mode, typically triple-DES, thus having a block size of 8 bytes, together with PKCS#7 padding. The latter means that the final block is filled up with one or more padding bytes, the value of each of which is the equal to the number of padding bytes. In the cryptographic layer, the only possibility to achieve an invalid ciphertext would be an invalid padding in the final block. The CBC-decryption is given by the definition

p_i = D(c_i ) xor c_i-1,

where the p_i and c_i , i ∈ {1 ,..., n} are the sequences of plaintext and ciphertext blocks, respectively, D(x) is the block cipher decryption, and c₀ is the initialization vector (IV). Accordingly, the following manipulations of CBC-ciphertexts are possible:

1. Any number of leading blocks can be removed without any effect on the decryption result of the remaining blocks. The IV of the message is updated to the last removed block.
2. Any part of the message can be freely moved to any position in the ciphertext in portions of full blocks. At any such seam resulting from the moving of a sequence of blocks, the first block of the appended sequence will decrypt to some pseudorandom content, the remaining blocks of the appended sequence will decrypt to their original plaintext.
3. Bit flips can be introduced in arbitrary blocks in p_i by applying the corresponding bit flips to c_i-1 . As a side-effect, the content of p_i-1 will be pseudorandom. Together with partially known plaintext, this allows an attacker to create a block of fully controlled content. Introducing bit flips in the first message block p₁ does not lead to any pseudorandom plaintext block.
4. The padding block can be kept intact by keeping the last two blocks of the ciphertext in that position.

As we have noted above, the trivial message takeover attacks only work against the encrypt-then-sign message format, and are mitigated today by clients composing messages in the sign-then-encrypt format. The new result presented here is the possibility of message takeover attacks against signed-then-encrypted messages. They are carried out as follows. In the setting where Alice is going to send a signed-then-encrypted email to Bob, Eve, the attacker, first contacts Alice in order to receive a signed and encrypted email from her. In this way, Eve learns the exact message format used by Alice. Note that the signature is usually contained in the MIME message of type "multipart/signed" as an attachment. Furthermore, Eve knows what email client is used by Bob. She now determines what manipulations she needs to perform on the ciphertext in order for Bob's email client to not recognize the signature any more. This could involve modifications such as simply stripping off the signature attachment, which is usually at the end of the message. Furthermore, she can block-wise move any part of the message to the beginning. She can render any formatting tags invalid through bit flips. Some of these modifications demand to know the length of the individual message parts in the actual attack. Note that in the case that an email contains only the usual text/plain, text/html and signature parts, with the length of the latter known, the length of the other two parts might be deducible from the overall length quite accurately.

Once Eve has determined the necessary modifications, she is ready for the actual attack. She blocks the signed-then-encrypted message from Alice to Bob and performs the modifications on the ciphertext as determined in the previous step. She then applies an outer signature to the ciphertext with her own key and forwards the message to Bob. As described for the trivial message takeover attacks above, Bob will now presume that Eve authored the message and potentially reply to it and thus disclose secret information.

It is up to Eve to decide whether she keeps intact the text of the message or whether she introduces modifications before signing it. To achieve targeted modifications, a certain amount of known plaintext will be necessary. Note that she might even be interested in corrupting the message in part, in order to provoke a reply with history from Bob to a message which does not suggest a reply otherwise.

We tested the attack as described above against a few clients and found that Thunderbird 71.0 is vulnerable to it as it displays the forged message as validly signed by Eve. Details of the attack and the identity of the vulnerable client will be disclosed in an upcoming research paper. However, basically all clients will be susceptible to ciphertext modifications that result in the inner signature not being recognized any more.

The above concludes the overview of the technical aspects of the attack. What remains is to understand under which conditions this type of attack is applicable. If Alice and Bob have not been in contact before, it is easy for Eve to assume the identity of Alice before Bob. In a realistic scenario Bob could be a journalist or a lawyer, and Alice an informer or a new client who initially contacts Bob via an email which already contains confidential information.

However, even if Alice and Bob have been in contact before, the attack is still feasible, as Eve might for instance not even pretend to be Alice but just claim to be an intimate contact of her and seemingly proving so by forwarding information to Bob via the message takeover attack. Furthermore, if trying to assume Alice's identity, Eve might choose an email address closely resembling that of Alice or pretend that it is a different address of Alice. She can devise any conceivable social scheme by preceding the taken-over message by messages of her own, with the taken-over message functioning as the convincing proof of her claims to Bob.

From this variety of attack possibilities we conclude that the general use of S/MIME conforming clients is insecure. The remaining security assurance of S/MIME is that if Bob knowns the signer of the message to be trustworthy in the sense of not being malicious (and does not err in that), then he can be sure that the message was authored by that person and may reply to it without the risk of disclosing confidential information. In all other cases, this is not guaranteed.

The fundamental flaw leading to the attacks is within the S/MIME standard. The CBC ciphertext fails to reliably protect the signature and thus the concept of integrity protection through the signature collapses. The best repair would be to allow for the use of authenticated encryption, which is already specified in CMS and would lead to the detection of all modifications on the ciphertext. The message encrypted in this way should also contain a field with the sender address, which is verified by the recipient. This would also solve the usability problem pointed out above, in that integrity protection of encrypted messages would be independent of the existence of a signature and any type of malicious forwarding would be prevented. Since such a repair of the specification, not to speak of its widespread adoption in clients, will unlikely be available any time soon, we look at two other options. It is quite likely that some clients already implement them unintentionally and achieve protection at least against straightforward forms of the message takeover attack.

restricting the S/MIME format

One option is for the receiving client to consider only messages with inner signatures as validly signed. This a is valid countermeasure, since the attacker is incapable of producing signatures of unknown message content (if the content is known to him completely then he can simply forge the message from scratch). This solution cannot be backward compatible to the current S/MIME specification as there mere outer signatures are also considered valid. However, since to our knowledge basically all clients already produce emails in the proposed format, this incompatibility would probably hardly be relevant.

Note that already the possibility for Eve to only strip off signatures without the possibility of generating new ones is a drawback. With the countermeasure proposed here, this cannot be prevented. Accordingly, the countermeasure from the next section should be implemented in any case.

mitigation on the application layer: stricter MIME-parsing

In the previous section we discussed a measure necessary to achieve security on the cryptographic layer, which is the only sound solution. However, as that measure breaks compatibility with the current S/MIME specification, here we propose a mitigation on the application layer which retains compatibility to the S/MIME specification. Furthermore, these countermeasures also offer protection against attacks where Eve only strips off signatures and modifies the encrypted message without applying her own signature.

Before we come to the discussion of these measures, we wish to point out why mitigation on the application layer can never reliably compensate a broken cryptographic layer. First of all, application processing is generally far too complex to allow for systematic or formal security analysis, and thus the trust in the effect of such measures can never be as high as that in a sound cryptographic solution. Furthermore, application processing is subject to varying requirements, and thus the additional security mechanisms must be feared to be rather unstable from version to version. Another problem is that such mitigating measures will hardly find a suitable place in any specification. Since they are out of the scope of S/MIME, they cannot be included there, and since it is not the task of the MIME processing to enforce security goals of S/MIME, this is also not the right place.

Now we turn to the measures that should be implemented by clients functioning on the basis of the broken S/MIME specification when parsing the MIME content of an encrypted email:

1. Parsing should be as strict as possible. Any inconsistencies, like the lack of an inner signature in a mail that is headed by "Content-Type: multipart/signed", irregular boundary tags etc., should lead to the display of an invalid signature. The presence of a signature part ("Content-Type: application/pkcs7-signature") in the message should always lead to the interpretation of this as the message carrying an inner signature, even when it is not expected from the previous context, and also here any inconsistencies in the MIME message should lead to the signature shown as invalid.
   [Update: With the new attack variant, this countermeasure is further complicated.]
2. The presence of invalid character codes should also lead to invalid signatures.
3. Furthermore, when the above measures detect an irregular MIME message, also the encryption result should be indicated as potentially manipulated.
4. It should also be considered not to display the contents of a message with such an irregular MIME structure at all, in order to prevent the user from disclosing information by replying to the message, or at least warn him when he attempts to do so.

It should be unnecessary to say that it is not possible to have any guarantee that implementation of these measures achieves reliable defence against attacks. However, the most straightforward attacks, i.e. the cutting off of the signature attachment will not function in that simple form any more.

"how could this happen?" – this was already asked by Davis in the view of his summary of known problems in S/MIME and other specifications relying on naive sign & encrypt fifteen years ago. Unfortunately, no improvements were made to the S/MIME specification since then. The main reason seems to be that the issue of "surreptitious forwarding", which is possible with sign-then-encrypt was considered out of scope of the protection goals (which is a valid point of view in our opinion), and that the trivial message takeover attacks are only possible with encrypt-then-sign, and consequently each client can choose the former secure option when composing messages.

The following is the complete security analysis of the problem of the order of the two operations offered by the S/MIME specification: "There are security ramifications to choosing whether to sign first or to encrypt first. A recipient of a message that is encrypted and then signed can validate that the encrypted block was unaltered, but cannot determine any relationship between the signer and the unencrypted contents of the message. A recipient of a message that is signed-then-encrypted can assume that the signed message itself has not been altered, but that a careful attacker may have changed the unauthenticated portion of the encrypted message." We are not even going to try and understand which trade-off is exactly attempted to be conveyed here. We simply note that effectively both statements about the achieved integrity of the message are wrong: with encrypt-then-sign, the signature can have been applied after the manipulation of the original ciphertext, and thus the "encrypted block" can very well have been altered. With sign-then-encrypt, we could indeed achieve integrity, but this is only in effect if the receiving client rejects encrypted-then-signed messages, which he is forbidden to do so by the S/MIME standard, as he is demanded to accept outer signatures as well, and furthermore rejects unsigned encrypted messages. Consequently, the last option for a conforming client would be to signal to the user the exact message format, who then has to decide what trust he places into the message. The latter is certainly an impossibility from a realistic point of view and only defers the decision of what is an acceptable message format and what is not.

The S/MIME specification enables a thicket of possibilities for senders to create messages, demands from the recipient generic processing of any such format, and devotes eight lines of text to the resulting "ramifications", shown to be wrong and ignoring the question in what way the receiving clients must commit to a specific message format and how they can remain compatible to the specification when doing so.

Of course there is still the "escape" for the S/MIME specification to be understood as implying a different meaning of integrity, namely one which only refers to the integrity of signed contents and not the contents as they were encrypted. However, in this case, first of all, this notion could not be differentiated from the notion of authenticity, and second, it would mean that the possibility of message takeover attacks is knowingly taken into account.

By now it should be needless to elaborate that a specification of a cryptographic message format does not benefit from such a great freedom in the order and nesting of operations. It burdens implementers with difficult decisions and, more importantly, it leads to complex security implications, which are, in the case of the S/MIME specification, not even rudimentarily addressed and flaws have obviously been overlooked.

The following diagram gives an overview of the different types of attacks that S/MIME messages are vulnerable to.

The main new insight is the possibility of message takeover attacks. The other attacks were more or less long known to be possible with S/MIME. The possibility of content manipulation of unsigned messages is even explicitly pointed out by the S/MIME specification. The application of a signature by the attacker to a message which was previously unsigned, which we refer to as the "apply signature attack", is trivial. The same applies to what we label "unsigned forwarding attack", i.e. the forwarding of potentially manipulated encrypted emails with a different sender address. The baseline is that S/MIME does not attempt to reach any other security goal than confidentiality for merely encrypted messages. However, as we pointed out, this does impair usability and consequently security considerably and thus we cover these issues in our overview as well. The new aspect to the content manipulation and unsigned forwarding attack is that they can also be applied if the sender signed his email.

The figure shows two entry points of the graph: signed-then-encrypted messages, with the subsequent process flow indicated by red arrows, and only encrypted messages, with processing indicated by orange arrows, from Alice (A) to Bob (B). The graph has four different exit points, i.e. types of forged emails that Eve sends to Bob.

The general processing flow in the attacks is as follows. With the possibility of Eve (E), the attacker, to remove inner signatures, she gets into the same position as an attacker who performs the forgery on merely encrypted messages. The next step is the potential modification of the content. By signing the resulting email, in case the original email was also signed, the message takeover attack is realized, otherwise the apply signature attack is realized. If the message remains unsigned, Eve may choose to forward it to Bob in her own name or retain Alice as the sender. The latter certainly usually only makes sense if she modified the content, otherwise she would forward an unmodified email (potentially just stripped off its signature). This results in the unsigned forwarding and content manipulation attacks, respectively.

The figure also shows the countermeasures and which steps in the attack process they prevent. The ad-hoc defence of strict MIME parsing may succeed in preventing the effective removal of inner signatures. The ideal countermeasure is the use of authenticated encryption (AE), in conjunction with the authenticated sender address in the ciphertext which is matched to the actual sender address. Without this additional measure, for unsigned messages, authenticated encryption only prevents those attacks where ciphertexts are manipulated, but not those where unmodified encrypted messages are forwarded by a malicious sender hoping for a reply that discloses secret information. Insisting on inner signatures, i.e. not accepting outer signatures, also prevents those attacks where the attacker applies his own signature.

It is certainly an interesting question to compare the situation of S/MIME with that of OpenPGP which also implements naive sign & encrypt. As OpenPGP plugins exist for many email clients, it is a possible alternative for secure email exchange. However, at least when we talk about large institutions the interchangeability between both schemes is not given. While S/MIME builds on public-key infrastructures, OpenPGP relies on direct trust, which demands a very different trust management scheme that does not scale with the number of users. But for small-scale users OpenPGP can certainly be an alternative to S/MIME.

The main differences between OpenPGP and S/MIME for our purposes are:

1. OpenPGP implements optional integrity protection of encrypted messages, but it does so in a faulty way which allows an attacker to downgrade messages to mere encryption without integrity protection (SEIP downgrade attack). Furthermore, it is reported that also here the signature can be stripped off.
2. OpenPGP does only allow sign-then-encrypt.

From this we understand that message takeover attacks are not possible against OpenPGP, since the attacker is not able to sign the encrypted messages. Accordingly, contrary to S/MIME, OpenPGP offers the advantage that when receiving a signed and encrypted email one may always be certain that the signer authored the message, and can make no mistake when replying with history.

The message takeover attacks bring users of S/MIME into a problematic situation. These attacks easily lead to information disclosure and are applicable in the strongest conceivable setting, i.e. when the sender produces the signed-then-encrypted format and the recipient only accepts signed and encrypted emails. This is the only setting in which S/MIME was so far believed to achieve reasonable security goals. How many users were aware of this restriction is another question pointing us to the impaired usability of S/MIME which deserves repair since a long time. The detailed look at S/MIME reveals it to be a sort of dinosaur, which survived despite its lack of support for modern state-of-the-art cryptography and took on a major role in our communication security architecture.

It is now up to vendors of email clients to come up with effective countermeasures for users to be able put sufficient trust into S/MIME protected emails. As has been discussed above, this is not a simple task. However, giving up S/MIME compliance in part and refusing outer signatures is at least a reliable means to repair trust in the strongest setting where the recipient insists on signatures and the sender applies them.

Furthermore, these results also potentially threaten other schemes built on naive sign & encrypt, like PKCS#7 and CMS. Since these are generic formats they must be assumed to be used in a large number of proprietary applications. The direct threat of information disclosure like in an email client through the reply-with-history feature will usually not be applicable to systems which process messages in an automated way, but they may very well be affected in other ways.