Re: [lamps] AD review of draft-ietf-lamps-cms-kemri-05

[Fabian Ising <[e-mail]>]

Hello all,

Our recent paper "Content-Type: multipart/oracle - Tapping into Format 
Oracles in Email End-to-End Encryption" [1] might make this attack 
slightly more feasible. We show that in some MUAs it is possible for an 
active attacker to decrypt single (CBC) plaintext blocks by watching the 
flow pattern of TLS-encrypted IMAP communication for some clients 
*without any user interaction* (albeit with a lot of queries). If I 
understand the attack described by Falko correctly, that's exactly the 
kind of decryption oracle needed to perform this attack.

We also show an attack against a receiver (Google's hosted S/MIME 
solution) enforcing inner S/MIME signatures on incoming messages (a 
possible countermeasure discussed later in this thread) in Appendix A of 
the paper.

In general, the paper shows several techniques that might be able to 
strip or weaken requirements for user interaction from such attacks.

[1] https://www.usenix.org/system/files/usenixsecurity23-ising.pdf 
<https://www.usenix.org/system/files/usenixsecurity23-ising.pdf>

Am 27.10.23 um 10:50 schrieb Falko Strenzke:
>
> Johannes and I hereby disclose a novel AEAD-to-CBC downgrade attack 
> against state-of-the-art CMS. This is a summary of what we are 
> planning to publish in an upcoming research paper. We disclose it now 
> as we think it is likely that knowledge of this attack will help the 
> WG to understand the relevance of key separation between legacy block 
> cipher modes and AEAD modes and thus hopefully decides to incorporate 
> this measure in the KEM-RI draft.
>
>
>     Inverse CBC Decryption Oracle Attack on Low Entropy AEAD Blocks in CMS
>
> The described attack applies to the modes CCM and GCM that both use 
> CTR encryption. The attack allows to the attacker to determine the 
> content of a low entropy plaintext block in a CMS GCM or CCM (AEAD) 
> encrypted message. The preconditions for the attack are:
>
>   * The victim supports also CMS CBC decryption and reveals CBC
>     decrypted messages to the attacker. The plaintext messages that
>     victim reveals in the attack are meaningless “garbage”. This
>     assumption underlies attacks described in literature [1], [2].
>   * The attacker has sufficiently much information about one plaintext
>     block of the target AEAD ciphertext, so that the number of
>     necessary guesses (each having the size of the block cipher block
>     size) fits into such a CBC message that the victim decrypts for him.
>
> The attacks is referred to as an inverse oracle attack because it uses 
> the block decryption operation of the victim to attack the block 
> encryption operation of the original message. This implies that the 
> attack is limited to verifying guesses for low entropy blocks in the 
> target plaintext. Such attacks have, to the best of our knowledge, not 
> been described previously in the literature. Formally, this means that 
> CMS AEAD does not achieve CCA2 security in the presence of a CBC 
> decryption oracle.
>
> The attack could for instance realistically be used to reveal the 
> value of a secret code with a few digits within an otherwise known 
> message.
>
>
>       Description of the Attack
>
> In the following, let Eₖ(X) and Dₖ(X) denote the AES block encryption 
> and decryption under the key /k/ and Dₖ-CBC(Xᵢ) the AES-CBC decryption 
> under key /k/ of the plaintext block Xᵢ.
>
>   * Generate the set of /n/ guesses {Tᵢ} for /i/ ∈ {1 … /n/} for the
>     target plaintext block at position /t/ in the original AEAD
>     ciphertext. The corresponding ciphertext block in the target CTR
>     ciphertext is labelled Cₜ.
>   * Compute the corresponding set of guessed key stream blocks {Gᵢ |
>     Gᵢ = Tᵢ⊕ Cₜ for all i = 1 … /n/}
>   * Creation of the CBC ciphertext as the oracle input:
>       o choose CBC-IV as G₀ arbitrarily
>       o Form the CBC ciphertext as the sequence of the guess blocks
>         {Gᵢ | for all i = 1 … /n/}
>   * Then the CBC decryption oracle will compute the sequence of
>     plaintext blocks:
>       o {Pᵢ | Pᵢ = Dₖ-CBC(Gᵢ) = Dₖ (Gᵢ) ⊕ Gᵢ₋₁ for all i = 1 … /n/}
>   * The attacker receives the plaintext {Pᵢ} and computes
>       o {Xᵢ | Xᵢ = Pᵢ ⊕ Gᵢ₋₁ for all i = 1 … /n/}
>   * Let Hₜ be the counter block at position /t/ in the AEAD
>     ciphertext, i.e., for the correct guess of the target key stream
>     block Gᵥ at index /v/ we have Gᵥ = Eₖ(Hₜ)
>       o the counter blocks are publicly known, since GCM and CCM both
>         directly use the public nonces in the counter block
>   * Note that for the correct guess we have Xᵥ = Dₖ (Gᵥ) ⊕ Gᵥ₋₁ ⊕ Gᵥ₋₁
>     = Dₖ(Gᵥ) = Hₜ
>   * Thus, if the attacker finds for any of the {Xᵢ} that Xᵥ = Hₜ then
>       o the guess Gᵥ = Tᵥ ⊕ Cᵥ for the key stream block is correct
>       o and thus the corresponding guess Tᵥ for the plaintext block is
>         correct
>
>
>       Effect of CBC Padding Check
>
> CBC is used in CMS together with PKCS#7 padding. Thus an application 
> that enforces correct padding will make the attack more difficult. The 
> attacker has no way to enforce a correct padding or to influence the 
> length of the padding. But a correct padding of length 1 appears with 
> probability 1/256. Multi-user attacks would be one way to compensate 
> the resulting low success property of the attack.
>
> ------------------------------------------------------------------------
>
> [1] Katz, J., Schneier, B.: A Chosen Ciphertext Attack Against Several 
> E-Mail En- cryption Protocols. In: 9th USENIX Security Symposium 
> (USENIX Security 00), Denver, CO, USENIX Association (August 2000)
>
> [2] Jallad, K., Katz, J., Schneier, B.: Implementation of 
> Chosen-Ciphertext Attacks against PGP and GnuPG. In Chan, A.H., 
> Gligor, V., eds.: Information Security, Berlin, Heidelberg, Springer 
> Berlin Heidelberg (2002) 90–101
>
> Am 24.10.23 um 14:30 schrieb Falko Strenzke:
>>
>> We are aware that the document draft-ietf-lamps-cms-kemri 
>> <https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kemri/> is 
>> already in the AD review and thus far progressed in its process of 
>> finalisation. We have a good reason to propose a modification to this 
>> document still at this late stage. Both the suggested change and the 
>> reason for it are explained in the following.
>>
>>
>>       Proposed change
>>
>> We propose to include the algorithm identifier of the symmetric 
>> scheme used for the payload encryption, i.e., the 
>> contentEncryptionAlgorithm, in CMSORIforKEMOtherInfo.
>>
>>
>>       Reason for the proposed change
>>
>> The reason is, besides it generally being best practice to include 
>> such contextual information into the key deriviation, that there is 
>> the threat of AEAD-to-CBC cross-mode / downgrade attacks against 
>> state-of-the-art CMS. The KEM-RI draft has the opportunity to remove 
>> this potential weakness at least for KEMs and thus we strongly 
>> suggest to make this change. Including the contentEncryptionAlgorithm 
>> in the key derivation ensures that one arrives at different content 
>> encryption keys if the contentEncryptionAlgorithm is changed (for 
>> instance) from AEAD to CBC.
>>
>> Please note that also the OpenPGP crypto-refresh 
>> <https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/> 
>> incorporates a key derivation – that deviates in its parameters from 
>> what we propose here and is only used in the case of AEAD – that 
>> ensures key separation for the newly introduced AEAD and the legacy 
>> CFB encrypted data packets.
>>
>> - Falko Strenzke and Johannes Roth
>>
>> Am 11.10.23 um 21:58 schrieb Roman Danyliw:
>>> Hi!
>>>
>>> I performed an AD review of draft-ietf-lamps-cms-kemri-05.  Thanks for this very important update to CMS.  This document is in good shape.  As the below are minor, I'll advance this to IETF LC and ask that this feedback be resolved concurrently.
>>>
>>> ** Section 2.  Editorial. Should the distribution of the recipient’s public key be made explicit?
>>> OLD
>>>     In advance, each recipient uses KeyGen() to create a key pair, and
>>>     then obtains a certificate [RFC5280] that includes the public key.
>>>
>>> NEW
>>>
>>> In advance, each recipient uses the KEM KeyGen() function to create a key pair, and then may obtains a certificate [RFC5280] that includes this newly generated public key.  This public key or associated certificate is them made available.
>>>
>>> ** Section 2.  Editorial.  Recommendation for several sections.  When a KEM function, KeyGen()/Encapsulate()/Decapsulate() is mentioned, referred to is as a “KEM <insert function name>”.  For example, s/Encapsulate() function/KEM Encapsulate() function/
>>>
>>> ** Section 3.
>>>        The
>>>        RecipientIdentifier provides two alternatives for specifying the
>>>        recipient's certificate [RFC5280]
>>>
>>> Isn’t the correct reference for the two mechanisms in RecipientIdentifier (i.e., issuerAndSerialNumber and subjectKeyIdentifier) provided by RFC5652?
>>>
>>> ** Section 3.  Editorial
>>>      The issuerAndSerialNumber alternative identifies the
>>>        recipient's certificate by the issuer's distinguished name and the
>>>        certificate serial number; the subjectKeyIdentifier identifies the
>>>        recipient's certificate by a key identifier.
>>>
>>> Is there a missing “or” between these two options?  Both don’t need to be present in the RecipientIdentifier structure.
>>>
>>> ** Section 3.  Process question.
>>>        Note that this requirement expands the original purpose of the ukm
>>>        described in Section 10.2.6 of [RFC5652]; it is not limited to
>>>        being used with key agreement algorithms.
>>>
>>> Does this imply that this RFC should formally “update” RFC5652?
>>>
>>> ** Section 6.1.  Since SMIME-CAPS is being used in the formal definition of the KEY-ALGORITHM class, RFC 5912 needs to be a normative reference.  RFC5912 is informational, but it already in the DOWNREF registry.
>>>
>>> ** Section 6.1. As an aside, what is the SMIME link to KEMs?
>>>
>>> ** Section 7.
>>>     The choice of the KDF SHOULD be made based on the security level
>>>     provided by the KEM.  The KDF SHOULD at least have the security level
>>>     of the KEM.
>>>
>>> What is the nuance being conveyed between these two sentences?  What additional considerations exist beyond what is spelled out in the second sentence?  This construct is repeated in the next paragraphs for key-encryption algorithms too.
>>>
>>> ** Section 7.  Typo. s/used to by the/used by the/
>>>
>>> Regards,
>>> Roman
>>> _______________________________________________
>>> Spasm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spasm
>> -- 
>>
>> *MTG AG*
>> Dr. Falko Strenzke
>> Executive System Architect
>>
>> Phone: [phone]
>> E-Mail: [e-mail]
>> Web: mtg.de <https://www.mtg.de>
>>
>>
>> ------------------------------------------------------------------------
>>
>> MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
>> Commercial register: HRB 8901
>> Register Court: Amtsgericht Darmstadt
>> Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
>> Chairman of the Supervisory Board: Dr. Thomas Milde
>>
>> This email may contain confidential and/or privileged information. If 
>> you are not the correct recipient or have received this email in error,
>> please inform the sender immediately and delete this email. 
>> Unauthorised copying or distribution of this email is not permitted.
>>
>> Data protection information: Privacy policy 
>> <https://www.mtg.de/en/privacy-policy>
>>
>>
>> _______________________________________________
>> Spasm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spasm
> -- 
>
> *MTG AG*
> Dr. Falko Strenzke
> Executive System Architect
>
> Phone: [phone]
> E-Mail: [e-mail]
> Web: mtg.de <https://www.mtg.de>
>
>
> ------------------------------------------------------------------------
>
> MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
> Commercial register: HRB 8901
> Register Court: Amtsgericht Darmstadt
> Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
> Chairman of the Supervisory Board: Dr. Thomas Milde
>
> This email may contain confidential and/or privileged information. If 
> you are not the correct recipient or have received this email in error,
> please inform the sender immediately and delete this email. 
> Unauthorised copying or distribution of this email is not permitted.
>
> Data protection information: Privacy policy 
> <https://www.mtg.de/en/privacy-policy>
>