One of eMudhra's certificate authority private keys is the number 4.
Not a number that starts with 4, or the number 4 followed by a few hundred random digits, just, 4... Another one is 56, and another is 115. I know, because I recovered all of them from their
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.
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.
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.
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.
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