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

[Falko Strenzke <[e-mail]>]

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>