Subject: [lamps] Does 6211 actually do what it claims to?

From: Mike Ounsworth <[email-masked]>
Date: Tue, 1 Jun 2021 21:26:48 +0000

This is maybe a dumb question coming from a relative PKIX newcomer.

RFC 6211 sets out to solve algorithm substitution attacks in CMS by including the digestAlgorithm, and either signatureAlgorithm or macAlgorithm in the digested-and-signed content.

Cheekily: does this actually solve algorithm substitution attacks?

Seems like a chicken-and-egg situation where, during signature verification, you are using the (currently unverified) content to tell you how to verify the content. In particular, 6211 puts the digest alg id inside the digest, and therefore it's fair game for manipulation during a hash collision attack. 

PKCS#1 v1.5 puts the digest alg id outside (ie next to) the digest in the signed data, which seems like it gets you out of the checken-and-egg situation because now you would need a collision in the signature primitive, not in the hash primitive (ie it's now the sig primitive protecting the hash primitive, rather than the hash primitive protecting itself). RSA-PSS internally does something that looks distinctly HMAC-y, so it's probably ok too but for different reasons.

Furthermore, a quote from Kaliski, Burton, 2002, "On hash function firewalls in signature schemes":

"Note that identifying the hash function in the message itself is not enough; it is likely as easy for an opponent to control the identifier as any other part of a message when forging a signature." 

.. which seems exactly what 6211 has done.

So, am I missing something, or are hash function substitution attacks only really solvable via the construction of the signature primitive, and not at the protocol layer? In which case, 6211 does not actually solve the problem that it set out to solve?

PS: I also posted this to stack exchange: https://crypto.stackexchange.com/q/90318/24012

---
Mike Ounsworth
Software Security Architect, Entrust

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 Jun 2021 16:51:02 -0400

Mike:

In CMS SignedData and AuthenticatedData, then algorithm identifiers are not covered by the signature or MAC, respectively.

RFC 6211 provides an signed attribute / authenticated attribute to provide this capability. 

      CMSAlgorithmProtection ::= SEQUENCE {
          digestAlgorithm         DigestAlgorithmIdentifier,
          signatureAlgorithm  [1] SignatureAlgorithmIdentifier OPTIONAL,
          macAlgorithm        [2] MessageAuthenticationCodeAlgorithm OPTIONAL }

In X.509 certificates, the signature algorithm appears twice.  One of them is covered by the issuer's signature.  RFC 6211 provides essentially the same thing.

Russ

> On Jun 1, 2021, at 5:26 PM, Mike Ounsworth <Mike.Ounsworth=[email-masked]> wrote:
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Mike Ounsworth <[email-masked]>
Date: Tue, 8 Jun 2021 15:14:18 +0000

Hi Russ,

Right. I'm not saying 6211 is any worse than bare CMS SignedData / AuthenticatedData. My question is: is it actually better? 

Here's my attack scenario. Say I'm setting out to do an algorithm substitution attack against a signer who uses, say, an ECDSA-SHA256 signature. For the sake of argument, let's assume that RIPEMD is critically broken and accepted by the verifier. I take a legitimate message-signature pair (m, s) from the victim. I compute a second message m' where SHA256(m) = RIPEMD256(m'). Therefore ECDSA-SHA256(m, s) and ECDSA-RIPEMD256(m',s) both appear valid under the victim's pubic key. I have a forged signature on m'.

I believe this is the attack that 6211 is purporting to prevent. I also believe that it does not prevent it; by putting the digestAlgorithm inside the message being digested, the signature s is only implicitly bound to the digestAlgorithm; as long as it's changed to digestAlgorithm=RIPEMD256 in the forged message m', the algorithm substitution will be undetectable.

I hope I'm missing something ..?

---
Mike Ounsworth

-----Original Message-----
From: Russ Housley <[email-masked]> 
Sent: June 2, 2021 3:51 PM
To: Mike Ounsworth <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: [EXTERNAL] Re: [lamps] Does 6211 actually do what it claims to?

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
Mike:

Russ

> PS: I also posted this to stack exchange: https://urldefense.com/v3/__https://crypto.stackexchange.com/q/90318/24012__;!!FJ-Y8qCqXTj2!Nuglq_FViyrunBEm50OHp1mJ7q-7zf2RRwpi_4xhIUEWMcolaQY93uEHNjWfmR1bf9VkMfuLgg$ 
> 
> ---
> Mike Ounsworth
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!Nuglq_FViyrunBEm50OHp1mJ7q-7zf2RRwpi_4xhIUEWMcolaQY93uEHNjWfmR1bf9WyADf3eQ$

---

From: Russ Housley <[email-masked]>
Date: Tue, 8 Jun 2021 12:17:48 -0400

It very much constrains the structure of the successful attack.

In your example:

- the RIPEMD160 OID needs to appear in the digestAlgorithm filed in the signed attribute defines in RFC 6211 attribute (and also in the unprotected SignerInfo digestAlgorithm field).
- the ECDSA-RIPEMD160 OID needs to appear in the signatureAlgorithm filed in the signed attribute defines in RFC 6211 attribute (and also in the unprotected SignerInfo signatureAlgorithm field).
- the RIPEMD160 hash value of the modified content is placed in the message-digest attribute.
- the RIPEMD160 has value computed over the signed attributes is input to the signature validation function.

The level of "broken" is quite significant here....

Russ

> On Jun 8, 2021, at 11:14 AM, Mike Ounsworth <Mike.Ounsworth=[email-masked]> wrote:
> 
> Hi Russ,
>