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."
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.
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.
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 :)
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...
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.
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)
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.
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?
(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.
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.
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.
"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."