On 26/04/2011 19:16, Anders Rundgren wrote: > As far as I know not a single HSM (even those who cost $20 000) > out there is able to certify that keys actually were created > inside of the HSM!!! A $10-$20 SKS always attests the origin > of created keys using a built-in device key and certificate. Then you have to trust that certificate, trust that it's been installed securely, trust who issued it... Quite a lot of things you can't control, don't you think? What about a "virgin" device that the first time you turn it on generates a new key and only accepts "set params", "generate new key", "get self-signed cert" and "store this cert" until *you* store a cert? You can do it on an offline PC, booted from a CD. You have full control. Fear TEMPEST attacks? Just use a jammer and do some random data transfer to other USB devices...
If the device doesn't accept "store key" command, then all keys it uses must have been generated locally :) > With a planned addition to KeyGen2 you will be able to put > certificates in devices (servers, routers, etc) using a > SCEP-like process that (due to the device certificate) can > be performed [securely] without an enrollment password. I still miss the sense of SCEP. Must study it... But I fear it just shifts security perimeter to another entity. > SKS is a "simple smartcard". That it looks complex is because > provisioning is really 10 times as complex as performing an > "RSA Sign". IIUC, just because "you" are using the wrong security perimeter at the wrong time. *If* you can *securely* load a single cert on the HSM, then all is easy (even easier than RSA, if you want). If you can't, *nothing* can be trusted. If, at initialization, you store a second certificate for administrator (even if I'd prefer weights for a Tree Parity Machine to be used as a shared symmetric key generator, to have perfect forward secrecy even in case of compromise), you're OK and can administer securely the HSM from anywhere. And since you're working inside a trusted perimeter, you don't need convoluted protocols that only delegate security to another party. BYtE, Diego. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
