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

[Russ Housley <[e-mail]>]

Mike:

The AlgorithmIdentifier for the KEK is input to the KDF.

The suggestion that it also include AlgorithmIdentifier for the CEK will not solve the problem, at least not for the other flavors of RecipientInfo.  I'd like to come up with one solution for all of the flavors.

Russ

> On Oct 27, 2023, at 2:32 PM, Mike Ounsworth <Mike.Ounsworth=[e-mail]> wrote:
> 
> Pausing WGLC to study this seems prudent.
>  
> If I’m reading the draft correctly, currently the KEK is derived from an HKDF which includes in its input the DER-encoded value of:
>  
>       CMSORIforKEMOtherInfo ::= SEQUENCE {
>         wrap KeyEncryptionAlgorithmIdentifier,
>         kekLength INTEGER (1..65535),
>         ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
>  
> Falko and Johannes are proposing to also include contentEncryptionAlgorithm.
>  
> My understanding is that this would be a pretty big abstraction layer violation in CMS since the *RecipientInfo’s job is to transport the CEK material, not to dictate its use. For example, the KEMRecipientInfo structure does not carry the contentEncryptionAlgorithm identifier. In fact, you have to recurse all the way up to EncryptedContentInfo in RFC 5652 to find it, and passing it all the way down into the *RecipientInfo KEK derivation would be a major API overhaul.
>  
> Worth thinking about though.
>  
> ---
> Mike Ounsworth
>  
> From: Spasm <[e-mail] <mailto:[e-mail]>> On Behalf Of Russ Housley
> Sent: Friday, October 27, 2023 9:55 AM
> To: Falko Strenzke <[e-mail] <mailto:[e-mail]>>
> Cc: Roman D. Danyliw <[e-mail] <mailto:[e-mail]>>; LAMPS <[e-mail] <mailto:[e-mail]>>; Johannes Roth <[e-mail] <mailto:[e-mail]>>
> Subject: [EXTERNAL] Re: [lamps] AD review of draft-ietf-lamps-cms-kemri-05
>  
> 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.
>  
> 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.
>  
> 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.
>  
> Russ
>  
> 
> 
> On Oct 27, 2023, at 4:50 AM, Falko Strenzke <[e-mail] <mailto:[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:
> choose CBC-IV as G₀ arbitrarily
> 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:
> {Pᵢ | Pᵢ = Dₖ-CBC(Gᵢ) = Dₖ (Gᵢ) ⊕ Gᵢ₋₁ for all i = 1 … n}
> The attacker receives the plaintext {Pᵢ} and computes
> {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ₜ)
> 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
> the guess Gᵥ = Tᵥ ⊕ Cᵥ for the key stream block is correct
> 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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/spasm
> -- 
> MTG AG
> Dr. Falko Strenzke
> Executive System Architect
> 
> Phone: [phone]
> E-Mail: [e-mail] <mailto:[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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/spasm
> -- 
> 
> MTG AG
> Dr. Falko Strenzke
> Executive System Architect
> 
> 
> Phone: [phone]
> E-Mail: [e-mail] <mailto:[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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/spasm
>  
> Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. _______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/spasm