Robert Relyea wrote: > 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). Thanx Bob! It is a little funny that Dell, HP and IBM laptops already back in 2006 were equipped with built-in TPMs that can perform a "TPM_Certify" which attests created keys, while $10000 HSMs apparently still haven't this IMO rather fundamental capability! This feature also opens avenues for simplified initial enrollment since if you have (in the RA) registered the public key of the crypto module credential you can optionally accept remote initial requests without enrollment passwords. Shameless plug: Certified keys therefore seems to be a worthy successor to PKCS #10's PoP (Proof of Possession) which is the reason why my "brainchild" the SKS is heavily built on the concept of container attestations through' a specific "Provisioning API" which deals with most key life-cycle aspects. Anders > > bob >> Comments? >> >> Anders >> _______________________________________________ >> opensc-devel mailing list >> opensc-devel@lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel > > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
