[Opendnssec-user] Security of SoftHSM

[Bud P. Bruegger]

Hey Roland,

better late than never, here is a reply..

On Thu, 10 Jun 2010 12:46:14 +0200
Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> wrote:

> 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 :-)

Can you point me to the papers, very interesting!   If I find time,
I'll tell you more details of what I fiddled with..

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

I guess SoftHSM will be like many other crypto and security things:
lot's of people will use it in wrong ways and think they are now secure
and unattackable ;-)

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

Yes, this is the main motivator for separating it to a remote
(dedicated) CPU.

> Still, adequate protection
> should be added to the link as well as adequate firewalling on the
> machine running SoftHSM.

Yes, this part is like keeping your smartcard in your own pocket, not
letting everyone play with it... or in other words, treat it like a
credit card.   We have to do the same with the SoftHSM (or HSM for that
matter).

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

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

If the solution remains soft, then we create a grand illusion of
security that isn't there:  the 10kg titanium pad lock on an armored
door --  while the window next to the door is left open ;-)
 
> > 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
cert..

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

> >> 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 :-)

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

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

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

This would definitely be an interesting solution!

-b

> 
> Cheers,
> 
> Roland
>