Cas Cremers

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'

This degenerate case was just confirmed to work by @reaperhulk , thank you! (@kennyog @kennwhite )

When comparing a received cert to cached root certs, windows only compared the public keys, but not the parameters, and would therefore assume that a received fake root cert C' with different parameters was the same as a cached root cert C, using C' to verify the cert chain.