also how the everloving fuck was this not found earlier?
is there nobody that just generated private keys 0-65k, put them into public keys, encoding them with all kinds of encodings and b64 offsets, and.... googling them?????
omfg the plot might thicken it is onto something really funny
there is not yet enough evidence to prove this but there's a really interesting precedent:
eMudhra issued invalid CRL signatures a year ago.
now that we know that they were all super small scalars, we can trivially just generate all private keys in the 0-65535 search space to verify if they indeed used a different key
THAT DOESNT YIELD A SINGLE MATCH.
THE KEY THEY ACCIDENTALLY USED TO SIGN THE CRLS IS NOT A BROKEN ONE.
here's where the conspiracy hat can be put on: what if they accidentally fixed their system to use the proper private keys, which seemed to be sane and was unnoticed because it was right and just quickly rolled back their systems once mozilla pointed it out
it is trying its best to bruteforce the key that was used to sign the "invalid" CRLs as we speak but the search has yielded not a single hint yet.
this theory can't be definitively proven, but it can be definitively proven by reproducing the key, and that doesnt seem to happen with its attempts so far
CALLLLLLLLLLLLLLLLLLLLLLLED ITTTTTTTTTTTTTTTTTTTTTTTTTTT
The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys.
also, this entire ordeal could have been prevented by SIMPLY NOT TESTING IN PROD, and this testing in prod was APPROVED BY EVERYONE INVOLVED
there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)
(emphasis mine; source)
eMudhra should, under no circumstances, ever be trusted again
from some rudimentary attempts to verify their story with a soft hsm, it seems to all check out. a plausible story does not mean that there was no malice behind it, but if they fucked around with wrapping, they may genuinely have done this as a honest mistake with many, many preventable steps
it is actually plausible that this was an honest mistake aber den salat haben wir jetzt trotzdem
the only thing really giving it the creeps is this sentence:
d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root
by looking at the notBefore fields, we can see that they are not created in batch:
15:35:09 DV TLS G3C
15:37:41 OV TLS G3C
15:39:31 EV TLS G3C
15:54:08 DV TLS G3B
16:00:12 OV TLS G3B
16:03:31 EV TLS G3B
16:08:27 OV CS G3B
16:38:40 OV CS G3C
so, was this mistake made in a script somewhere, or did a human make this mistake 8 times?
it seems more plausible for this mistake to happen once in its opinion, and not 8 times
@49016 That feels like what one would see if the mistake was encoded in the plan for a signing ceremony and then everyone involved faithfully followed the plan without engaging brain properly
@49016 well looking at e.g. https://github.com/badkeys/badkeys/issues/38 people (reasonably!!) thought this type of checking was unnecessary
"No, I am not aware of such examples in the wild and I agree that it's very likely that the cost of adding such coverage isn't justified at all."
another 100% quote in hindsight:
"I think 1,2,3 as private keys are far less plausible."
notably leaving open that using 4 as your private key was more plausible.