|
@marcan42 | |||||
|
So it's not that Windows uses the wrong curve parameters or anything like that, it's that at some point the key used to index into a validated cert cache is (serial, pub) when it should be (serial, pub, params).
As they say, one of the hardest problems in CS is caching.
|
||||||
|
||||||
|
Hector Martin
@marcan42
|
16. sij |
|
To clarify the Windows crypto fail: The problem isn't in signature validation. The problem is the *root store/cache*. CryptoAPI considers an (attacker-supplied) root CA to be in the trust store if its public key and serial match a cert in the root store, Ignoring curve params.
|
||
|
|
||
|
Dan Kaminsky
@dakami
|
17. sij |
|
Presumably, only for ECC...ah, because only ECC has params significant/agile in this manner?
|
||
|
|
||
|
Hector Martin
@marcan42
|
17. sij |
|
Yup.
|
||
|
|
||
|
Rohit Mothe
@rohitwas
|
17. sij |
|
Maybe I'm missing something but based on my tests it seems that even the serial doesn't need to be the same? Just a public key match seems enough to trigger it
|
||
|
|
||
|
Hector Martin
@marcan42
|
17. sij |
|
Could be, the PoC I saw was explicitly cloning the serial so I assumed that much was needed.
|
||
|
|
||
|
Kevin Hill
@CyborgTribe
|
17. sij |
|
Is it easier to find params that generate an arbitrary pub key than to find a pub key given the params? Aren't both roughly just at hard? What am I missing?
|
||
|
|
||
|
Hector Martin
@marcan42
|
17. sij |
|
What you're trying to find is the private key given the public key. You cannot find the original private key for the original params, but you can trivially craft parameters in such a way to make a private key of 1 "happen" to correspond to the original public key.
|
||
|
|
||
|
Tavian Barnes
@tavianator
|
16. sij |
|
Why are the params not part of the serial?
|
||
|
|
||
|
Hector Martin
@marcan42
|
16. sij |
|
What do the params have to do with the serial? The serial is just an arbitrary serial number.
|
||
|
|
||
|
Conrado Gouvea
@conradoplg
|
17. sij |
|
I wonder why does it even touch the supplied CA certificate. Shouldn't it simply get the CA certificate from the trusted store, keyed by the signer Subject/KeyID listed in the child certificate?
|
||
|
|
||
|
James Forshaw
@tiraniddo
|
17. sij |
|
I'd suspect it's because the chain verification is distinct from whether the chain is trusted by policy. Therefore you supply the full chain with the bogus cert, which checks out okay. Then the trust is checked, it compares AuthKeyIDs and find a matching trusted root. Job done!
|
||
|
|
||