6
$\begingroup$

It seems to be common-practice for a signature protocol to include the algorithmID and params (if any) in the data being signed.

For example:

  • RSA PKCS#1 v1.5 includes the digest alg in the data being signed. See RFC 2318 section 10.1.2.
  • JWT / JWS includes "protected headers" in the data being signed (which under most JWS serialization schemes includes the alg ids). See RFC 7515 section 5.1.
  • XMLDSig includes a SignedInfo, which includes a SignatureMethod, in the signed content. See W3C xmldsig sec 5.4.
  • PGP v4 includes the public-key algorithm and hash algorithm in the signed data. See RFC 4880 section 5.2.3.
  • X.509 TBSCertificate includes the signature alg and params. See RFC 5280 sec 4.1.
  • CMS added an extension via RFC 6211 specifically to address algorithm substitution attacks by explicitly including the digestAlgorithm and signatureAlgorithm signed content.

The only counter-examples I could find are that signature primitives since PKCS#1 v1.5 don't seem to do this anymore (and I think also ECSDA, but didn't find citation), and older versions of protocols that have since "fixed" this "problem".

  • DSA (FIPS 1866-4 section 4.6) does not explicitly include the hash alg id in the signed content.
  • RSA-PSS (see RFC 3447)
  • PGP v3 does not hash over the public-key algorithm or hash algorithm (but was updated in v4 to do so). See RFC 4880 section 5.2.2.
  • The original CMS did not sign over the message-disest attribute. See RFC 5652 section 5.4. This was later fixed with the extension defined in RFC6211, see above.

But why is it needed?

Reference:

  • RFC 6211: Schaad, J. Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute. RFC 6211, DOI 10.17487/RFC6211, April 2011,< http://www. rfc-editor. org/info/rfc6211, 2011

In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. ... This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process.

However ...

Reference:

  • Kaliski, Burton S. "On hash function firewalls in signature schemes." Cryptographers’ Track at the RSA Conference. Springer, Berlin, Heidelberg, 2002.

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, yes, of course, if the attacker is manipulating the signed content through a forgery attack, then you can't rely on the integrity of the signed content (d'uh).


Question

So, my question boils down to: all of these specs go to a fair amount of effort to protect the signature alg and params inside the signed content. Why? Is there any security reason to do this? Is there anything cryptographically wrong with a fully-detached signature which does not include any signature metadata in the signed content?

$\endgroup$
5
  • 1
    $\begingroup$ CMS does not include the digestAlgorithm in SignedData, nor the digestAlgorithm or signatureAlgorithm in SignerInfo, in the data covered by the signature; see 5652 #5.4. (SignedData is data-after-signing, not to-be-signed.) RFC 6211 defines an option to add them -- if you use SignedAttrs which nearly everyone does now although formally it's still optional -- but doesn't really explain why, only referencing the possibility of a hash alg with params. OTOH ESS RFC2634+5035 provides and ETSI CAdES (RFC6211) requires a signedattr binding the signing cert which partially constrains ... $\endgroup$ Jun 1 at 2:44
  • $\begingroup$ ... the algs. PGP v3 signature (which you linked) does NOT cover the pubalg and hashalg octets (read that text carefully) but v4 (which everyone now uses for other reasons) does. $\endgroup$ Jun 1 at 2:46
  • $\begingroup$ Thanks @dave_thompson_085 for the corrections. I have edited them in to my question. The fact that PGP and CMS initially did not have this protection, and then subsequently added it just deepens my confusion and curiosity at this question. $\endgroup$ Jun 1 at 15:51
  • $\begingroup$ UPDATE: I posted the RFC 6211 part of this question to the mailing list of the IETF LAMPS working group (the body that owns that standard). Does 6211 actually do what it claims to? $\endgroup$ Jun 1 at 21:33
  • $\begingroup$ UPDATE: on further digging, RSA-PSS does an HMAC-y thing with the hash function, so is probably immune to algorithm substitution attacks in all practical senses, but for reasons un-related to this question. $\endgroup$ Jun 1 at 21:49
1
$\begingroup$

all of these specs go to a fair amount of effort to protect the signature alg and params inside the signed content. Why?

Because

  1. In many cases, signature alg and params are positively needed to prevent attack. That's the case for X.509 signature alg and params in a certificate that describe what algorithms and parameters the certified public key is intended to be used with (rather than what signature alg and param certifies the certificate). If that signature alg and params were not certified, whatever gives this information could be changed. At the very least that would invoke behaviors not analyzed from a security standpoint, in practice often leading to attack: downgrade to a legacy protocol; DSA public key passed an RSA one, and factored by an adversary, then used to sign.
  2. Case 1 tends to include a lot of situations where alg and params are functionally needed to automatically select alg and params. Everyone likes when things just work, and are secure.
  3. Danger only comes when signature alg and params describe how their own integrity is protected, and there's nothing else that securely does such description. That's the genuine pitfall the question's Kaliski&Burton quote is about. It's not common AFAIK (Update: self-reference does occur in X.509 certificates. However AFAIK that's never a security issue, because the signature alg and params are redundantly specified in the certification's authority certificate, or because the certificate is self-signed thus inherently trusted). There's >750 words in ISO/IEC 9796-2:2010 sections 6c thru 6e (not in the linked preview) dealing with that potential issue.
  4. Signature alg and params do help diagnostic when something does not work, including in case 3 (but as a corollary of Murphy's law, they are missing when most needed).
  5. In some cases including 3, the practice of including signature alg and params at least plausibly improves security by forcing magic constants that implementations check. Arguably, that applies to RSASSA-PKCS1-v1_5 (which, when using common hashes, lacks a convincing security reduction under Chosen Message Attack).
  6. If things are safe without signature alg and params, and the signature alg and param are actually checked, then their addition is unlikely to harm security; at worse, it gives an unwarranted feeling of extra security.
  7. Standard designers think signature alg and params is best security practice, and that's true except in case 3 (but again, that mistake is not so common). With time, this has the potential to become a universal if circular argument.

I just don't known enough about CMS to tell if the efforts in RFC 6211 are needed, useful, or sufficient. Fortunately, that's not directly asked!


Is there any cryptographic reason to sign over the signature algID and params (used to make the signature)

Not if the signature scheme is secure (EUF-CMA). In theory, it could help some less than perfect signature scheme by adding redundancy to a signed message (see 5) if said signature algID and params are checked; or further weaken such weak scheme by allowing more leeway in the message, if they are not. I don't know a practical case where that makes a significant difference.

$\endgroup$
11
  • $\begingroup$ I actually don't think #1 is true; take for example the cert protecting this page: crt.sh/?id=4535950925, the CA signature carries an algorithm of sha256WithRSAEncryption, but the SubjectPublicKey Algorithm is just rsaEncryption, which is restricted by the KeyUsage to signatures, but nowhere does it say what hash functions or RSA scheme (PKCS#1v1.5, OAEP, PSS) it is allowed to be used with. $\endgroup$ Jun 1 at 17:50
  • $\begingroup$ @MikeOunsworth: my understanding is that the SubjectPublicKey is understood to mean the purpose of the certified public key, thus is not self-referential; and rsaEncryption at least unambiguously states that's an RSA PKCS#1 public key (rather than something totally unrelated to RSA), which does contribute to security. From memory, I think rsaEncryption in this context is often understood to mean RSA signature (not encryption) per RSASSA-PKCS1-v1_5, but I would not bet the house on that, much less that there's no exception. Attributes in X.509 certificate are a notorious jungle. $\endgroup$
    – fgrieu
    Jun 1 at 18:12
  • $\begingroup$ rsaEncryption is your generic container for "here follows a modulus and an exponent". I was actually wrong; the cert I linked to has Key Usage: Digital Signature, Key Encipherment, so in fact that public key can be used for any RSA-based signature or (hybrid) encryption cipher suite; it's not even restricted to signatures. $\endgroup$ Jun 1 at 19:32
  • $\begingroup$ So that means, at least for signatures associated with X.509 certificates, you are in your case #3 100% of the time: the sig alg and params are never carried with the public key, and always carried either in the signed content, or in some sort of signature metadata object. (for X.509 certificates themselves: both; the sigAlg info is copied both inside the TBSCertificate, and outside it!). $\endgroup$ Jun 1 at 20:21
  • 1
    $\begingroup$ @Mike+ the Stack cert, like in practice all TLS certs, has ExtendedKeyUsage set to allow use (of the key in SPKI) only for TLS (the expanded names on crt.sh say WWW TLS = HTTPS but in practice it can be any TLS), and the algorithms usable in TLS are defined by the TLS specifications and conveniently(?) crossreferenced in several IANA registries. For example TLS1.3 never uses RSA encryption but lower protocols can. $\endgroup$ Jun 2 at 0:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.