6 ms·

Trusted certificate authority Certigna leaks its private key

41 points by ghalfacree 15y ago

Robin_Message 15y ago
That level of blurring is almost certainly insufficient to actually redact the information, as discussed in http://dheera.net/projects/blur.php http://dheera.net/projects/blur.php (discussed here http://news.ycombinator.com/item?id=1939607 http://news.ycombinator.com/item?id=1939607)
- verroq 15y ago
  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.
  - meric 15y ago
    What prevents you from doing it with only 5 letters at a time?
  - binarymax 15y ago
    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.
    - verroq 15y ago
      How do you know that blurring one character produces the same effect as blurring two characters close together?
      - jrockway 15y ago
        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 :)
        verroq 15y ago
        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.
- RichieB2B 15y ago
  No unblurring required. Just some 3DES brute forcing. http://pastebin.com/aJ5rzVY0 http://pastebin.com/aJ5rzVY0
mooism2 15y ago
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?
- wladimir 15y ago
  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.
  - pagekalisedown 15y ago
    Just by looking at the PEM's number of lines you can tell it's a 1024 bit key.
    - wladimir 15y ago
      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.
      - pagekalisedown 15y ago
        Good point. The strength of the private key isn't relevant. Only the encryption used to protect the key.
- pagekalisedown 15y ago
  (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.
  - deleted 15y ago
    [deleted]
JoachimSchipper 15y ago
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...
- deleted 15y ago
  [deleted]
- zwp 15y ago
  "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.
EwanToo 15y ago
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/ http://www.certigna.fr/crl/ (unless the website has an archived directory that the thinq.co.uk writer was looking at)
- yuhong 15y ago
  Well, unfortunately there are also other .pem files in the list.
  - EwanToo 15y ago
    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.
jvehent 15y ago
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."
- ordinary 15y ago
  Just some sensationalist reporting without proper fact-checking, then. Again.
  - JoeAltmaier 15y ago
    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"
    - slavak 15y ago
      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.
    - smackfu 15y ago
      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.
certigna 15y ago
You can find the Certigna's explanations at http://www.certigna.fr/archives/2984 http://www.certigna.fr/archives/2984
mpclark 15y ago
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'.

41 points by ghalfacree 15y ago

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

verroq 15y ago
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.
- meric 15y ago
  What prevents you from doing it with only 5 letters at a time?
- binarymax 15y ago
  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.
  - verroq 15y ago
    How do you know that blurring one character produces the same effect as blurring two characters close together?
    - jrockway 15y ago
      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 :)
      - verroq 15y ago
        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.
RichieB2B 15y ago
No unblurring required. Just some 3DES brute forcing. http://pastebin.com/aJ5rzVY0 http://pastebin.com/aJ5rzVY0

mooism2 15y ago

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?

wladimir 15y ago
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.
- pagekalisedown 15y ago
  Just by looking at the PEM's number of lines you can tell it's a 1024 bit key.
  - wladimir 15y ago
    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.
    - pagekalisedown 15y ago
      Good point. The strength of the private key isn't relevant. Only the encryption used to protect the key.
pagekalisedown 15y ago
(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.
- deleted 15y ago
  [deleted]

JoachimSchipper 15y ago

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...

deleted 15y ago
[deleted]
zwp 15y ago
"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.

EwanToo 15y ago

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/ http://www.certigna.fr/crl/ (unless the website has an archived directory that the thinq.co.uk writer was looking at)

yuhong 15y ago
Well, unfortunately there are also other .pem files in the list.
- EwanToo 15y ago
  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.

jvehent 15y ago

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."

ordinary 15y ago
Just some sensationalist reporting without proper fact-checking, then. Again.
- JoeAltmaier 15y ago
  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"
  - slavak 15y ago
    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.
  - smackfu 15y ago
    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.

certigna 15y ago

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

mpclark 15y ago

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'.