Trusted certificate authority Certigna leaks its private key | Hacker News Reader

Trusted certificate authority Certigna leaks its private key

thinq.co.uk

41 pointsghalfacree27 comments

This would actually be a problem.... if the private key was good for anything. Certigna's response says it is not:

"Certigna has issued a response claiming that the file represented a 'test' certificate that had long since expired. "The private key available on the server corresponds to a test certificate used on our website certigna.fr," the company claimed. "It is impossible to generate new valid user certificates from this key. Moreover, it is encrypted and is an SSL certificate expired since July 2010. This key does not affect our infrastructure security. The Certigna SSL authority’s private key is stored in HSM (Hardware Security Module) and hence can never be recovered. This useless file has been removed."

Just some sensationalist reporting without proper fact-checking, then. Again.

Somebody stole a key from a Certificate authority server? Sensationalist? yeah, sounds pretty sensational.

"They only stole junk from my house. So Your stuff is safe, somehow"

Anyway, they Did fact-check - and the company didn't respond. So they reported what appeared to be a significant breach. Then, when the company responded, they reported that too. Which has a name, which is "Responsible Journalism"

Beware of metaphors when trying to understand computer issues. What happened (assuming this is the truth) is that a useless key was left on a public server in a public directory, and it could be downloaded by anybody, at which point it is useless. There is no helpful physical analogue to this situation. Just understand it as it is directly, it's not that complicated.

Your metaphor clouds the issue, it does not bring understanding. "Breaking in" to a computer network doesn't give you access to a "whole house", and what occurred wasn't a break in, there's no part of that metaphor that actually helps you understand the situation.

At best this shows a bit of carelessness, but then, a useless, expired key doesn't necessarily require much care in handling, either. The only damage here is PR, if what the company says is true.

Except the key is apparently worthless, and thus it makes sense nobody was very particular about securing it properly. More like "They only stole the old bicycle I left unlocked in my front yard."

Making sure that the leaked private key matches the CA's public key isn't particularly difficult. This is still poor fact checking - company's response, or lack thereof, notwithstanding.

I don't think it's a good analogy. You have procedures for protecting sensitive data. This was not sensitive data, even if it appeared to be to a naive viewer, so the procedures were not followed. This does not imply anything about the security of sensitive data.

That level of blurring is almost certainly insufficient to actually redact the information, as discussed in http://dheera.net/projects/blur.php (discussed here http://news.ycombinator.com/item?id=1939607)

No unblurring required. Just some 3DES brute forcing. http://pastebin.com/aJ5rzVY0

I don't think so, it'd take way too long to dictionary attack/bruteforce the missing 64 x 9 characters of the blurred image. Which gives 64 ^ (64 x 9) combinations judging from the base64 encoding.

That is assuming you have the blurring algorithm and font perfect.

No - we already know that the same blurring algorithm was used for all the characters. The font can be found and matched quickly and you only need to calibrate the blur for one character. The blurring algorithm will give you a pixel perfect representation for character match so its more on the order of 64 * 600 (600 is the approx number of chars blurred). This could be cracked in a day or less by someone motivated enough.

How do you know that blurring one character produces the same effect as blurring two characters close together?

You don't need to know this. You make an image of the text for every combination possible, apply the blur algorithm, and see which one is a pixel-perfect match for to the image on the web site.

Or rather, you don't do this, you write a program to do it :)

But you'll have to go through 64 ^ (64 x 9), combinations which will take years which was what I said in the first post.

What prevents you from doing it with only 5 letters at a time?

Of course, "just revoke" doesn't actually work: serving a outdated certificate revocation list, or preventing a connection to the OCSP ("is this cert revoked?") server causes browsers to trust "revoked" certificates. Worse, lots of software doesn't even bother to do this check. This is why the browsers hardcoded a list of compromised certificates last time.

This is even worse, though, because a lot of "real" certificates depend on this CA. Also, there are no logs to make a blacklist of "bad" certificates, so you can't just revoke a handful...

"a lot of "real" certificates depend on this CA"

How many? did you estimate from sequential serial number allocation?

I am surprised (even if it turns out this is "just" an encrypted webserver key) that they aren't using hardware keys: (a) it's their core business (b) they appear competent (CTO posts to technical mailing lists) (c) they have a /29 so aren't just a single IP on an inaccessible low-end VPS.

ssllabs.com gives them a C rating.

I don't think this leak has included their own certificate authority key to allow you to generate your own key signed by the CA (which thinq claims), just the private key for the website, but it's certainly embarrassing for them.

They seem to have modified all the files in the directory overnight, and removed the offending www.certigna.fr files from http://www.certigna.fr/crl/ (unless the website has an archived directory that the thinq.co.uk writer was looking at)

Well, unfortunately there are also other .pem files in the list.

But that doesn't mean their CA trusted root key has been disclosed - sure, the pem files could contain their trusted root key, but they normally wouldn't.

For example, the file named certigna.pem exists on most Linux machines, it's the public key not the private one, look at the ca-certificates package on debian.

You can find the Certigna's explanations at http://www.certigna.fr/archives/2984

Bad show, thinq, that I had to read right through this story to get to the bit that says 'all of the forgoing is a crock of shit'.

I'm not terribly familiar with private key formats, but it appears to be encrypted (the `Proc-Type` and `DEK-Info` lines). Is the `localKeyID` the password used to encrypt?

(1) Yes, the key is encrypted.

(2) This is not necessarily the private key used to sign other certificates.

(3) If they're lucky, this is a private key only used for their web server. OR, this key is an intermediate key. In which case they can invalidate it, create a new one, and reissue certificates for all the affected customers.

I'm not sure either.

If it is encrypted, it would at least buy some time to replace all the certificates signed by this private key. Depending on the strength of the encryption key, obviously.

Just by looking at the PEM's number of lines you can tell it's a 1024 bit key.

That's the private key itself. I was somewhat unclear in my wording. We (I and the grandparent poster) were wondering if the private key was encrypted with a passphrase.

Good point. The strength of the private key isn't relevant. Only the encryption used to protect the key.

Reply on news.ycombinator.com