Cas Cremers

It looks like it exploits what Vaudenay warned against in 2004 : "Digital Signature Schemes with Domain Parameters" ( https://lasec.epfl.ch/pub/lasec/doc/Vau04b.pdf … )https://twitter.com/NSAGov/status/1217152211056238593 …

Pre-patch, a cert can be used if the hash of the public key matches one in the cert root, after which the parameters of the new cert get used, enabling Vaudenay's attack. The patch requires the curve parameters to be the same, preventing this attack.

This is ultimately similar to Pornin and Stern https://www.bolet.org/~pornin/2005-acns-pornin+stern.pdf … (2005). (Which we built on for https://ia.cr/2019/779  )

Based on what I know now, I think the attack fits into a single tweet, including references:

1. Find an ecc root cert C with pk 2. Apply Vaudenay|(Pornin&Stern) 2004 get C' with sk',params' for that pk 3. Create a normal code signing cert C'' with key pair (pk'',sk'') and sign software with sk'' 4. Sign C'' with sk' 5. Present software,C'',C' to windows' sigcheck64.exe

@kennyog @Dennis__Jackson @matthew_d_green @hyperelliptic

Can someone please confirm/deny if this degenerate version works? (It is still Vaudenay 2004 but with d' the identity) @kennwhite @saleemrash1d It would be easier to detect in logs of course.

1. Find an ecc root cert C 2. Create C' with the same public key and curve but set the generator to the public key of C 3. Create a normal signing cert C'' with key pair (pk'',sk'') and sign software/cert with sk'' 4. Sign C'' with sk=1 5. Ship software/cert with C'' and C'