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.
-
-
Presumably, only for ECC...ah, because only ECC has params significant/agile in this manner?
- 7 more replies
New conversation -
-
-
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
-
Could be, the PoC I saw was explicitly cloning the serial so I assumed that much was needed.
- 2 more replies
New conversation -
-
-
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?
-
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.
End of conversation
New conversation -
-
-
Why are the params not part of the serial?
-
What do the params have to do with the serial? The serial is just an arbitrary serial number.
- 1 more reply
New conversation -
-
-
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?
-
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!
- 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.