[Opendnssec-user] Security of SoftHSM

[Roland van Rijswijk]

Hey Bud,

Bud P. Bruegger wrote:
>> We strive to make it as hard as possible to snoop sensitive data from
>> memory, for instance by varying the memory location where key data is
>> stored, by zeroising memory that contained sensitive data and by
>> locking sensitive data into non-paged memory to make sure it's not
>> swapped out to disk.
> 
> I've given soft tokens quite a bit of thought in the past.  All these
> methods are probably quite effective, but they protect until the point
> where you actually calculate the RSA or similar on the CPU and then the
> key gets out in the clear.
> 
> I had written a very rough proof of concept where I avoided that the
> key ever comes out in the open.  The idea was to find an an equivalence
> (an isomorphism..) to another representation space in which to compute
> the crypto functions.  

That sounds very interesting, I've recently read some papers on these
kinds of tricks. Unfortunately, my mastery of algebra doesn't reach far
enough to be able to do something like this myself :-)

[snip]

> Not sure whether it's worth the effort since also this mapping is just
> an obfuscation and the recipe to crack it is present in the software
> that can be reverse engineered...

That's exactly the problem with pure soft tokens, no matter what you do,
if you have the source it is reverse engineerable. So the strength
relies on the strength of the chosen passphrase and the quality of the
PBE mechanism.

>> The procedure above guarantees non-clonability if the PIN or SO PIN
>> remains secret. 
> 
> Well, this is exactly what I mean.  This means, it is a "something you
> know", not a "something you have".  HSM should implement the "something
> you have" portion.  This _is_ possible also with a soft implementation,
> but it means that the _physical_ deployment must guarantee sole
> control.  

That is true. Only if sole control can be guaranteed can you used a soft
token as a "something you have".

> What I was saying is that we need to take this into account when
> talking about remote access to the (soft) HSM.  Physical isolation to
> achieve sole control is very different from protection with a PIN.  It
> is something you have (and other's can't get at), while protection with
> a PIN waters it all down to something you know.

It is always a combination of two factors right? But we as developers
don't have any control over how users treat physical access to a machine
running SoftHSM. If we set up remote access, that still means that the
remotely accessing parties can only *use* key material, not extract it
if it is set up properly. Still, adequate protection should be added to
the link as well as adequate firewalling on the machine running SoftHSM.

> Taking this into mind I believe has a strong impact on the requirements
> of the PKCS#11 proxy:  If the separation of the connection to the (soft)
> HSM is physical, then channel encryption (SSL) and client
> authentication (SSL client cert) are maybe not as important?

I don't agree with that. This would severely limit the applicability of
the PKCS #11 proxy in other scenarios. Note that vendors of
network-attached HSMs use similar mechanism (SSL based connectivity with
client authentication). I - for one - would not like to proscribe how
users used either SoftHSM or the P #11 proxy. We should offer advice on
the security limitations of different scenarios but it is up to the user
to decide what is appropriate for their situation (in my opinion).

> 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 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.

>> We are also considering - for a future version -
>> replacing the PIN/SO PIN by a USB crypto token.
> 
> That could possible used by the VPN...
> 
> And BTW, in the (near?) future, most hosts will have some kind of
> Trusted Platform Module that could possible be used for that purpose..

True, but you cannot physically remove a TPM :-)

> [snip]
> 
>> The only alternative is to use a second factor, such as a crypto
>> token, to secure the SoftHSM. It is disputable whether or not that
>> makes sense but it is certainly cheaper than purchasing a real HSM.
> 
> I think this makes sense where a single key gives access to a very
> large number of keys (where that is necessary).  But where I have
> doubts is performance.  An HSM and also softHSM is very performant in
> number of crypto operations per time.  A crypto token (smartcard/usb..)
> is typically very slow (due to the mini cpu on the chip).  To make this
> successful, a single authentication (signature of challenge) by the
> crypto token should be good for a large number of crypto operation on
> the HSM...

This could easily be mitigated by a two-tiered model. The physical key
unlocks a second key that can be stored in memory for speed purposes
(albeit as well protected as possible by masking, moving around in
memory, etc)

>> Keep in mind that a good secure PKCS #11 proxy can not only expose a
>> SoftHSM over the network but *any* PKCS #11 compliant token or HSM. So
>> it will allow you to turn a PCI card HSM into a network HSM.
> 
> This is great!  But I don't think the reasoning above is affected
> whether the HSM is soft or hard.  I think that once it is on dedicated
> hardware (doesn't share neither CPU nor memory), then there is little
> difference..
> 
> I was looking around the web quickly to see what eithernet attached
> HSMs offer for protection but didn't find anything in a first quick
> look.  

They all use SSL based solutions with client authentication. Some offer
additional protection by requiring separate physical tokens to
"activate" the HSM. Once activated, though, having a PIN is sufficient
-- keep in mind that these devices are used in automated set up, so that
is for pure convenience. Of course, the client authentication on the
link could be done using a PKI token, thus adding a second factor.

Cheers,

Roland

-- 
-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl