[Natanael_L]

From what I read, x.509 allows the signer to specify the curve parameters along with the signature.

And yes, the bug here would be that Windows accepted parameters B without confirming they match A, it only checked that the public key was the same.

So you have official and trusted root / intermediate cert C1 which contains pubkey 1 and parameters A, which uses privkey 1 (secret obviously). When signing it doesn't usually specify parameters (just gets it from the trusted cert), the leaf certificate just contain the reference to the trusted cert and its public key and of course also contains the actual signature.

In the attack you reuse pubkey 1 but create parameters B and associated privkey 2, and using that you create a leaf cert that contain both the same references that an official signature would contain - except you also specify parameters B, and then supply the signature that validates only under parameters B, and then Windows accepts both the parameters and the signature.

[hannob]

That would make the attack plausible, but I wonder where these parameters are in practice.

I tried creating a cert with custom curve parameters here: http://dpaste.com/1Q2MYWF

It seems the parameter block is all part of "Subject Public Key Info". The signature is just a binary blob at the bottom. But openssl doesn't really break that down, does this signature have its internal encoding that allows supplying additional parameters?

And if that's the case: How does that make any sense? It sounds like just asking for trouble. (I mean... there never can be a situation where the parameters of the signature do not match the parameters of the key.)

[ASN1]

Try pasting your cert into https://lapo.it/asn1js/

You can see all the parts in the blob:

        OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key type)
        SEQUENCE (6 elem)
          INTEGER 1
          SEQUENCE (2 elem)
            OBJECT IDENTIFIER 1.2.840.10045.1.1 prime-field (ANSI X9.62 field type)
            INTEGER (256 bit) 1157920892373161954235709850086879078532699846656405640394575840079088…
          SEQUENCE (2 elem)
            OCTET STRING (32 byte) 0000000000000000000000000000000000000000000000000000000000000000
            OCTET STRING (32 byte) 0000000000000000000000000000000000000000000000000000000000000007
          OCTET STRING (65 byte) 0479BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798483A…
          INTEGER (256 bit) 1157920892373161954235709850086879078528375642790749043826051631415181…
          INTEGER 1

This will help you understand the ASN.1 encoding of a cert: http://luca.ntop.org/Teaching/Appunti/asn1.html

[benth]

The parent comment is wondering about the structure of the signature and if different curve parameters can be specified for it. How can explicit curve parameters be specified in an ECDSA signature? ecdsaWithSHA256, at least, is simply two bigints. There's no spot for specifying explicit parameters.

[tptacek]

This is answered upthread and in RFC 5480: the AlgorithmIdentifier has an ANY OPTIONAL field for parameters.

[benth]

Missed that. Thank you!

[shinigami]

Subject Public Key Info is just an Algorithm Identifier and the public key. The Algorithm Identifier is an OID and the parameters (ECParameters when using EC keys). It's these parameters that can contain the custom EC domain parameters.

The certificate signature is preceded by another Algorithm Identifier that specifies the signature algorithm (and the parameters), and so it seems that Microsoft is using this value instead of the parameters in the signer certificate Subject Public Key Info?