Re: HSM outage causes root CA key loss
Jeffrey I. Schiller j...@mit.edu writes: Because of prior experience with a SafeKeyper(tm) (a very large HSM), I learned that when the only copy of your key is in an HSM, the HSM vendor really owns you key, or at least they own you! I thought the Safekeypers had a cloning mechanism (as do things like Chrysalis cards, although that proved to be not very secure when it was reverse- engineered), and the idea was that you cloned one into the other as a backup? Mind you at $x0,000 per device that's a good business for the HSM vendor. Weger, B.M.M. de b.m.m.d.we...@tue.nl writes: Suppose this happens in a production environment of some CA (root or not), how big a problem is this? I can see two issues: - they have to build a new CA and distribute its certificate to all users, which is annoying and maybe costly but not a security problem, - if they rely on the CA for signing CRLs (or whatever0 revocation mechanism they're using) then they have to find0 some other way to revoke existing certificates. The original article doesn't make this clear but what's involved here isn't really a PKI in the conventional sense but more something like a master-keyed system in the style of ATM networks. In the same marvellous repurposing of terminology that often occurs elsewhere in smart cards where, for example, a checksum becomes a signature, in this case the certificates are just a jumble of parameters, some stuffed inside the signature itself (via a sign- with-message-recovery mechanism instead of the usual sign-with-appendix) and the rest bound to it through a hash. The CA key is more an attestation key, there are no CRLs or certificate-checking in the conventional sense (you can get away with these name games by calling the stored data a card verifiable certificate, and if you have a certificate then what signs it is obviously a CA, so you get something that seems to be a PKI but isn't). So when you lose your master key as they did in this case and there isn't really a PKI there at all, it really is game over. Even if it was a real PKI, rolling over a root is an incredibly traumatic experience, which one trial found could only be done via a system rebuild (in plain english a reformat and reinstall of the whole PKI). This is why CA root certs have a 20-40 year lifetime, so you never end up in a position where you have to roll them over. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: HSM outage causes root CA key loss
Nicolas Williams nicolas.willi...@sun.com writes: This goes to show that we do need a TA distribution protocol (not for the web, mind you), and it needs to use PKI -- a distinct, but related PKI. ... and now you have two (probably unsolveable) problems instead of one. In addition because the second problem virtually never occurs, it'll receive little or no evaluation in the real world, and will either not work when it's needed or will break when it's not needed, allowing your main PKI to be compromised through it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: HSM outage causes root CA key loss
Jeffrey I. Schiller j...@mit.edu writes: Our current Server CA certificate will expire in 2026 (when hopefully it won't be my problem!). Thus the universal CA root cert lifetime policy, the lifetime of a CA root certificate is the time till retirement of the person in charge at its creation, plus five years :-). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: HSM outage causes root CA key loss
Hi, Our current Server CA certificate will expire in 2026 (when hopefully it won't be my problem!). Thus the universal CA root cert lifetime policy, the lifetime of a CA root certificate is the time till retirement of the person in charge at its creation, plus five years :-). This neglects the not entirely unlikely possibility that long before your retirement some clever person will have broken your cryptographic hash function or signature scheme. I once saw a document refering to a PKI with a proposed certificate lifetime of 100 years. Those people really care about their grandchildren. Grtz, Benne - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: HSM outage causes root CA key loss
http://www.heise.de/security/E-Gesundheitskarte-Datenverlust-mit-Folgen--/news/meldung/141864 reports that the PKI for their electronic health card has just run into trouble: they were storing the root CA key in an HSM, which failed. They now have a PKI with no CA key for signing new certs or revoking existing ones. Actually, for a couple of days now they didn't stop pointing out that they were still running the PKI in a test environment and that only 'a few hundred test cards' are affected... Just stupid nonetheless... :-\ Cheers, Stefan. -- Stefan Kelm sk...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstrasse 100 Tel: +49-721-96201-1 D-76133 Karlsruhe Fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: HSM outage causes root CA key loss
- Peter Gutmann pgut...@cs.auckland.ac.nz wrote: I haven't been able to find an English version of this, but the following news item from Germany: ... It is exactly for this reason that when we generated the root key for the U.S. Higher Education PKI we did it outside of an HSM and then loaded it into two HSMs. The raw key was then manually secret shared accross five CD's (three being the quorum) which were distributed to five individuals for safe keeping. Because CD's have 700 Mb of storage and the share secret is tiny, literally thousands of copies of it were written on each CD along with the source code of the secret sharing software (written in Python). In theory every few years we are supposed to take out the CD's and verify that they can be read. It's probably time to do that now :-) Because of prior experience with a SafeKeyper(tm) (a very large HSM), I learned that when the only copy of your key is in an HSM, the HSM vendor really owns you key, or at least they own you! -- Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice j...@mit.edu - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: HSM outage causes root CA key loss
At 5:58 PM +1200 7/13/09, Peter Gutmann wrote: I haven't been able to find an English version of this, but the following news item from Germany: http://www.heise.de/security/E-Gesundheitskarte-Datenverlust-mit-Folgen--/news/meldung/141864 http://www.h-online.com/security/Loss-of-data-has-serious-consequences-for-German-electronic-health-card--/news/113740 reports that the PKI for their electronic health card has just run into trouble: they were storing the root CA key in an HSM, which failed. They now have a PKI with no CA key for signing new certs or revoking existing ones. -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: HSM outage causes root CA key loss
Hi, reports that the PKI for their electronic health card has just run into trouble: they were storing the root CA key in an HSM, which failed. They now have a PKI with no CA key for signing new certs or revoking existing ones. Suppose this happens in a production environment of some CA (root or not), how big a problem is this? I can see two issues: - they have to build a new CA and distribute its certificate to all users, which is annoying and maybe costly but not a security problem, - if they rely on the CA for signing CRLs (or whatever revocation mechanism they're using) then they have to find some other way to revoke existing certificates. No need to revoke any certificate. Any other problems? Maybe something with key rollover or interoperability? Seems to me that for signing CRLs it's better to have a separate Revocation Authority (whose certificate should be issued by the CA it is revoking for); then revoking can continue when the CA loses its private key. The CA still may have revoking authority as well, at least to revoke the Revocation Authority's certificate... Grtz, Benne de Weger - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: HSM outage causes root CA key loss
At 11:09 PM +0200 7/14/09, Weger, B.M.M. de wrote: Any other problems? Maybe something with key rollover or interoperability? Bingo. Key rollover has been thinly tested in relying parties. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: HSM outage causes root CA key loss
On Tue, Jul 14, 2009 at 11:09:41PM +0200, Weger, B.M.M. de wrote: Suppose this happens in a production environment of some CA (root or not), how big a problem is this? I can see two issues: - they have to build a new CA and distribute its certificate to all users, which is annoying and maybe costly but not a security problem, Not a security problem? Well, if you have a way to do authenticated trust anchor distribution that doesn't depend on the lost CA, then sure, it's not a security problem. But that's just not likely, or at least there's no standard for authenticated TA distribution, yet. If you can do unauthenticated TA distribution without much trouble (as opposed to by, say, having to physically visit every host), then chances are you have no security to begin with. If there was such a standard you'd want to make real sure that you have separate keys for TA distribution than for your CA, with similar physical and other security safeguards. This goes to show that we do need a TA distribution protocol (not for the web, mind you), and it needs to use PKI -- a distinct, but related PKI. As long as both sets of hardware tokens don't die simultaneously, then you'll be OK. Add multiple CAs for TA distro and you get more redundancy. - if they rely on the CA for signing CRLs (or whatever revocation mechanism they're using) then they have to find some other way to revoke existing certificates. The only other ways are: distribute the new CA certs, and/or use OCSP (which must use a different cert than the CA). OCSP is the better answer, if you can get all apps to use it. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: HSM outage causes root CA key loss
Weger, B.M.M. de wrote: - if they rely on the CA for signing CRLs (or whatever revocation mechanism they're using) then they have to find some other way to revoke existing certificates. ... Seems to me that for signing CRLs it's better to have a separate Revocation Authority (whose certificate should be issued by the CA it is revoking for); then revoking can continue when the CA loses its private key. The CA still may have revoking authority as well, at least to revoke the Revocation Authority's certificate... Unfortunately those code paths seem rarely traveled/tested between implementations and even within a single implementations fraught with caveats; so one often ends up with a (sub) CA in the same chain as the cert one wants to revoke. Any other problems? Maybe something with key rollover or interoperability? Aye - and there is another area which is even less traveled than above. Dw - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
