|
@CasCremers | |||||
|
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'
|
||||||
|
||||||
|
|
Cas Cremers
@CasCremers
|
14. sij |
|
It looks like it exploits what Vaudenay warned against in 2004 : "Digital Signature Schemes with Domain Parameters" ( lasec.epfl.ch/pub/lasec/doc/… ) twitter.com/NSAGov/status/…
|
||
|
||
|
|
Cas Cremers
@CasCremers
|
14. sij |
|
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.
|
||
|
|
||
|
|
Cas Cremers
@CasCremers
|
14. sij |
|
This is ultimately similar to Pornin and Stern bolet.org/~pornin/2005-a… (2005). (Which we built on for ia.cr/2019/779 )
|
||
|
|
||
|
|
Cas Cremers
@CasCremers
|
15. sij |
|
Based on what I know now, I think the attack fits into a single tweet, including references:
|
||
|
|
||
|
|
Cas Cremers
@CasCremers
|
15. sij |
|
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
|
||
|
|
||
|
|
Cas Cremers
@CasCremers
|
15. sij |
|
|
||
|
|
Cas Cremers
@CasCremers
|
15. sij |
|
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.
|
||
|
|
||
|
|
Cas Cremers
@CasCremers
|
15. sij |
|
|
||
|
|
||
|
|
Cas Cremers
@CasCremers
|
16. sij |
|
@kennwhite Curve Validation Error pic.twitter.com/8XEQc9JYwf
|
||
|
|
||
|
|
Cas Cremers
@CasCremers
|
18. sij |
|
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.
|
||
|
|
||
|
|
Cas Cremers
@CasCremers
|
18. sij |
|
By choosing the right parameters for C', you can know the private key for C' -- even when you don't know the private key for C -- as Vaudenay noted in 2004.
|
||
|
|
||
|
3-5 30-50x elves in a trench coat
@leftpaddotpy
|
16. sij |
|
for context:
A defined curve has an order n [prime number] and a generator point G [point]
privKey ≡ random number [integer]
pubKey ≡ privKey * generator [scalar * point = point]
the part I don't quite get yet is where the generator/"curve" is stored and if it is modifiable
|
||
|
|
||
|
|
3-5 30-50x elves in a trench coat
@leftpaddotpy
|
16. sij |
|
because I thought the "curve" was a fixed thing, so which part is stored in the cert if any? can you have custom ones and it will still accept them?
source on terms: cryptobook.nakov.com/digital-signat…
|
||
|
|
||