[Opendnssec-user] Security of SoftHSM

[Roland van Rijswijk]

Hi Bud,

Quick response from Barcelona Airport: you seem to be more paranoid than
I am (that's a compliment) :-D

I'll take a closer look at your responses tomorrow or Friday and get
back to you.

Cheers,

Roland

Bud P. Bruegger wrote:
> 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
> 

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