[Opendnssec-user] Security of SoftHSM

[Bud P. Bruegger]

Hi Roland,

another round of discussion after some delay..

On Fri, 28 May 2010 12:26:51 +0200
Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> wrote:

> Hi Bud,
> 
> Bud P. Bruegger wrote:
> > Security of a Soft (H) Security Module is indeed intriguing.
> 
> Yes it is :-). In my opinion, it should be as secure as possible in
> software. This means sticking to some simple design and implementation
> rules, such as secure coding guidelines, keeping sensitive data in
> memory and in the clear only as long as it needs to be in order to do
> processing with it.
> 
> > Here some thoughts on how the network connection needs to be
> > protected (quote above) and also a comment on the design:
> > 
> > [from: http://trac.opendnssec.org/wiki/SoftHSM/Design]
> >> Secure data manager:
> > ...
> >> The token key is stored in memory during the time a token is logged
> >> in. To protect it against eavesdropping by snooping the memory of
> >> the SoftHSM v2 it is cloaked using a blob of random data that is
> >> used to XOR the actual key data
> > 
> > Hmmm.  I'm wondering about the effectiveness of this.  In an
> > Soft(h)SM, as opposed ot an HSM,  memory is potentially accessible
> > by other, potentially hostile, processes.  Thus the need for
> > protection--but is it possible?
> 
> 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.  

Say normally an RSA key is represented by integers (modulus and exp),
this could be mapped to some other representation, for example one where
every integer is randomly stored by two parts:

origInt = partA + partB

Now in memory, you have partA and partB, none of which is the key
itself and one of the two can be a random number...

Now we have to find an equivalent to the RSA algorithm that works on
partA and partB, obviously without reconstructing origInt...

In a simplistic example, a multiplication of two integers would map to
something like:

Say in "normal space" we mulitply the integers: i-1 * i-2 = i-3

In isomorphic space that would map to:

(partA-1, partB-1) *' (partA-2, partB-2)
 =  

((partA-1 * partA-2 + partA-1 * partB-2),
 (partB-1 * partA-2 + partB-1 * partB-2))

So also the result is a pair of integers and in no case, the actual
original integers (keys) appeared in memory/registers.  

The resulting pair can obviously be mapped back to "normal space".  

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

but anyhow, thinking about it is fun ;-)

> > * Unless we find procedures for guaranteeing un-clonability, the
> > whole thing falls apart
> 
> 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.  

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.  

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?

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?

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

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

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

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

Do I see things so much differently from others?

-b