On 01/07/2011 09:25 AM, Anders Rundgren wrote: > Slightly off-topic but I guess some of you guys have more insight in > HSMs than most other people have :-) > > In a recent project there were a requirement for frequent and *automated* > renewals of certificates. The renewal procedure is based on creating > a self-signed request which is then signed by the original key. > > It appears that the new key cannot (for a *remote* CA) be guaranteed to > have been created and residing in the HSM which means that even if you > use a rigorous "key ceremony" for the initial key you will almost be down at > the "soft token" level after the very first renewal :-) Correct. If you actually change keys, you won't know that the new key is in the HSM simply because the old key signed it.
If you are just renewing certificates, you could accept the old key and know it's in a token. There is a scheme used by non-hsm tokens like coolkey, in which the key gen includes a proof of location element (a signed hash of the key with a shared secret between the HSM and the issuing authority) and the key import is handled with a secret key known only to the HSM and the issuing authority. In these schemes the CA is a trusted part of the infrastructure (It could fake the HSM, and only the CA can verify that the token was actually in an HSM). You could modify this to use some sort of pki instead of symmetric keys. All of these schemes imply some trusted HSM infrastructure, and currently would be HSM specific (I know of know published standards for handling this kind of operation). bob > Comments? > > Anders > _______________________________________________ > opensc-devel mailing list > [email protected] > http://www.opensc-project.org/mailman/listinfo/opensc-devel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
