[Opendnssec-user] Security of SoftHSM
Roland van Rijswijk
roland.vanrijswijk at surfnet.nl
Thu Jun 17 07:35:50 UTC 2010
Bud P. Bruegger wrote:
Here are some links w.r.t. homomorphic algorithms:
I recently saw a talk by this guy: http://www.win.tue.nl/~berry/
And read some of these:
> Obvioulsy, it is not possible to keep anyone from using it whatever way
> they want. But an HSM (soft or hard) is valid as something you have
> only when only the legitimate user can get at it. Your probably
> wouldn't want to leave your digital signature smartcard at a hotel desk
> for the night; and you may seriously consider revoking certificates
> should your smartcard have disappeared for some time. This, no matter
> that it is protected by a PIN ;-)
> So we have to be very careful to underline that an SSL-connection with
> client authentication is only a valid solution for "sole control" if
> the client cert is on a secure storage device (HSM). This may become
> easy in the (near?) future using Trusted Computing Modules...
Ah, I think I now understand what you're saying. I'm not arguing that
the client authentication for the SSL connection supplies the security
for the solution. The only reason we need the SSL connection is to
protect the real authentication mechanism (in this case the user PIN) in
transit. Using client authentication makes it possible to tie devices
together (you could even include the IP address of the client in its
certificate to strengthen this tie). But the client certificate would
not be the authenticator to the (Soft)HSM. The same is true for all
network based HSMs have worked with.
>>> In a scenario where access to the HSM is physically restricted, I
>>> frankly don't see advantages. So this means, the most
>>> straight-forward way (maybe some kind of RPC) is as good as anything
>>> more complicated. (Or actually better, since simple things have
>>> less bugs).
>>> Where really a physical separation isn't possible, then my first
>>> reaction would be why have an HSM (s.th. you have) in the first
>>> place if your usage translates it into s.th. you know?
>> Ah, that is not strictly true. In case of problems you always have the
>> ability to physically disconnect the machine running (Soft)HSM from
>> the network and as I said above, if developed and configured
>> correctly, the remote user would be able to use key material but not
>> extract it.
> But you're right in the sense that s.th. you know cannot be revoked (or
> taken offline). So damage control is much easier--comparable to a soft
>>> But if someone really wants to use it that way, maybe a VPN would be
>>> the solution and the protection of the channel and mutual
>>> authentication wouldn't be a requirement for the PKCS#11 proxy...
>> Hmmm... I'm not a fan of using a VPN in this case. That would make
>> setting stuff up much harder and would complicate things for the user.
> Wouldn't it be good if bad use would be difficult?
In this case, in my opinion, no. We should strive to make it both easy
to deploy as well as hard to do wrong. In the end, the responsibility is
always with the end user.
> but you can generate and store your own keys on it, delete them
> (instead of physically removing the TPM) if you want and revoke the
> corresponding certificate..
True, but the added value of a TPM - I think - is only that the key
processing is done in a more hardened environment and it becomes harder
to extract key material. In effect, you have a built-in smart card,
which you will still need to unlock using something like a PIN.
> Hmm. I'll have to look at my new laptop and see whether it has a TPM in
> it. It seems it also has a SIM slot and I'm wondering whether it was
> possible to find a SIM and middleware that lets you store assymetic
It is usually not possible to access the PC/SC interface of SIM slots in
a laptop. And SIM cards are usually locked by the operator preventing
creation of additional card structures and/or keys. If you do find a way
to access the PC/SC interface you could - of course - order a regular
smart card (i.e. not a SIM) in SIM 11.11 form factor (punch out card).
-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl
More information about the Opendnssec-user