lobsters score: 1 · tags: cryptography, security
deleted by creator
I’m very curious how this managed to happen. I suppose someone internally wrote their own certificate generation, but why?
score 1 · canonical
I can’t imagine the sequence of events which led to this buffoonery.
eMudhra have given their account of what happened on that ticket. It seems there was a bug in the script used during the ceremony, a second, weak key pair was created on the HSM, and having similar names a human error lead to the wrong keys being used for the CSR.
score 1 · canonical
Could it be a deliberate supply chain attack where they got shipped a prepared HSM?
score 1 · canonical
I’m surprised that it wouldn’t be standard practice to at least try to break the public key by looking for small private keys. Especially if you know you’re messing around with weak keys on the same HSM.
score 2 · canonical
I’m very interested in how an LLM broke it and why it tried (apparentely it only took seconds). Either that’s the well-known first step to do but no human does it only because it’s too dumb, or the information was somewhere out there.
If it took mere seconds, it means the information was in its training set. Actually, now I’m wondering if some website published example certificates with these “secret” keys and the LLM simply matched on them.
score 1 · canonical
Yeah, strange. If the LLM had access to tools or a shell, it might have ran a quick bruteforce script against common phrases? Other than that, yes - it must have been in the model already.
score 1 · canonical
The agent I tested with on Saturday was in a sandbox environment with dangerously skip permissions enabled. It had access to python’s cryptography package and its dependencies but nothing specific to CTFs or cryptanalysis.
score 1 · canonical
It wasn’t an LLM https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/JESKy8XoAgAJ
score 2 · canonical
There was a similar case — generalising from Debian OpenSSL incident seems to be not too hard for an entity with no issues spending energy on out-there checks just in case.
Of course, Debian incident was still using a PRNG on top of weak initialisation, but there were RSA keys so non-coprime distinct public keys were a giveaway.
I think some of the generic attack algorithms are slow but fast in the extreme cases (like here)? So running them with a timeout is a reasonable generalisation of «there are some weirdly weak keys around»
score 1 · canonical
That’s a good point. I’m well aware of this issue but OTOH it was 15 years ago and I din’t have it around in my mind; I had it not long ago while maintaining the openssl ubuntu package (as not to do the same) but not anymore once being from a different context. This could be enough that the first rationale step becomes to bruteforce a bunch of values even though it’s not a perfect match as the range of private keys didn’t start at 0 but at some time shifted by some amount.
score 1 · canonical
I am not a an expert, but if I recall correctly it can take some time to seed the random generator of choice with enough entropy. This used to be true especially after boot. Maybe when testing they couldn’t set the entropy threshold to zero and did not want to wait for it. Kind of common if you are spinning up build containers/vms in CI/CD. Hence an hard-coded trivial key. Lots of maybes…
score 1 · canonical
I’ve worked with a great many HSMs. And I’m having a hard time imagining one allowing this kind of weak key. I’d like to see more details on that part of the story before I believe it.
score 1 · canonical
There’s a vaguely plausible explanation in the mailing list discussion https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/ZRu1JvatAgAJ
However the use of dummy “reference” keys instead of resident keys isn’t entirely consistent with what eMudhra say on bugzilla about having two sets of “onboard” keys with similar labels, because of a wrap/unwrap process for exporting the keys to another HSM.
score 1 · canonical
Thanks for sharing that thread. I think Corey Bonnell’s posts track the closest to true for me, if these CAs were effectively disused.
eMudhra’s comments on bz muddy that quite a bit more, though; it’s not consistent with this one in particular.
score 1 · canonical
Glancing over the code, it looks like https://github.com/google/paranoid_crypto/blob/main/paranoid_crypto/lib/ec_single_checks.py#L91 could detect this issue. It also links to previous research: https://www.ise.io/research/ethercombing-finding-secrets-in-popular-places/ .
score 1 · canonical
Somebody on HN remarked that all the decimal numbers of the private keys have digits going from left to right on the keyboard, indicating that they might have been smashed in by hand.
I did a bit of quick math and you’d only expect to see this 1% of the time when generating 8 fully random 1-byte numbers. Is this unlikely enough to reject that null hypothesis? I don’t know, but it’s really fishy.
However, even if they were created that way by manual keysmashes, that doesn’t mean somebody at eMudhra did it. Maybe that’s how the reference valus were created by the author of a HSM integration library.
score 1 · canonical
I don’t doubt your theory. But there are lots of tests that should’ve caught this as we set up the things that used the HSM.
And some of those tests are part of the standards that get used with HSMs. NIST’s key generation tests aren’t perfect, but they’d have caught this. And those are the floor for HSMs being used in a reputable place.
score 1 · canonical
Perhaps the keys never were on the HSMs, but just plain files formatted by openssl?
score 1 · canonical
Wonder what we’d find if we spent a few minutes each on trying to brute force everyone’s public keys. Any volunteers?
score 1 · canonical
Part of the issue is that there are a lot of distinct ways to fuck up generating a private key, and by design you can’t exactly work backwards from the public one.
Usually things look fine, but weak entropy means you can somehow predict the private key. People haven’t really bothered trying single bytes, because generally keys are generated, and not input by hand.
score 1 · canonical
I was curious and checked the certificates from Mozilla’s CCADB, but only found the eMudhra keys again, so we can assume that the other keys are at least slightly better.
score 1 · canonical
Someone did this last night using the certificate transparency logs. No embarrassingly weak keys found.
score 1 · canonical