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

[Falko Strenzke <[e-mail]>]

Hi Russ,

Am 27.10.23 um 16:54 schrieb Russ Housley:
> Falko and Johannes:
>
> If I understand this attack correctly, the attacker intercepts a 
> CMS Authenticated-Enveloped-Data content that uses either AES-CCM or 
> AES-GCM as specified in RFC 5084.  Then, the attackers turns it into a 
> "garbage" CMS Enveloped-Data content that uses AES-CBC that is 
> composed of the guess blocks.  This gets sent to the victim, and the 
> victim shares the result of the decryption with the attacker.  If any 
> of the plaintext blocks match Ht, then the attacker learns the 
> plaintext for that block. Please let me know if anything is incorrect.
Yes, more or less. The plaintext still needs to be transformed by the 
attacker prior to matching Ht, but that is just a minor detail. 
Otherwise, your description is correct.
>
> The draft-ietf-lamps-cms-kemri draft cannot offer any defense here. 
>  The key under attack is the content-encryption key (CEK).  The 
> KEMRecipientInfo (like all other flavors of RecipientInfo) is about 
> transferring the CEK to one or more recipient.  You are seeking a way 
> to integrity protect the CEK algorithm identifier.  Historically, that 
> is done by signing the ciphertext.  RFC 2634 talks about the reasons 
> that an originator might want to use a sign-encrypt-sign triple wrapper.

How is sign-encrypt-sign going to help? The attacker is creating a 
completely new ciphertext and doesn't have to care for existing 
signatures on the original ciphertext (outer he removes, inner is just 
ignored when crafting the new ciphertext). If he sees a necessity, he 
can apply an outer signature on his crafted message (an inner he cannot, 
of course) with his own key. I think it is generally a misconception 
that signatures can be used for integrity protection of the ciphertext. 
The creation of an outer signature is completely independent of the 
creation / modification of the ciphertext.

The only thing that I see that could work is if the recipient insists on 
inner signatures for any message generally. But that would likely have 
huge impact on interoperability and would not be consistent with the 
existing CMS standard.

>
> I will give some thought to ways  to integrity protect the CEK 
> algorithm identifier without an additional layer of signature.
>
> Are you able to make a presentation about this attack at the LAMPS 
> session at IETF 118?  Remote presenters can be accommodated.

Yes, I will be in Prague and can give a short presentation.

- Falko

>
> Russ
>
>
>> On Oct 27, 2023, at 4:50 AM, Falko Strenzke <[e-mail]> 
>> wrote:
>>
>> 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>
>>
>> _______________________________________________
>> 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>