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

[Mike Ounsworth <[e-mail]>]

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 <[e-mail]> 
Sent: June 2, 2021 3:51 PM
To: Mike Ounsworth <[e-mail]>
Cc: LAMPS <[e-mail]>
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:

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=[e-mail]> wrote:
> 
> 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://urldefense.com/v3/__https://crypto.stackexchange.com/q/90318/24012__;!!FJ-Y8qCqXTj2!Nuglq_FViyrunBEm50OHp1mJ7q-7zf2RRwpi_4xhIUEWMcolaQY93uEHNjWfmR1bf9VkMfuLgg$ 
> 
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!Nuglq_FViyrunBEm50OHp1mJ7q-7zf2RRwpi_4xhIUEWMcolaQY93uEHNjWfmR1bf9WyADf3eQ$