[Opendnssec-user] Security of SoftHSM

[Roland van Rijswijk]

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.

> An XOR is a (very) poor man's encryption.  But no matter how good the
> encryption (why not use that of how it is stored on the file system in
> the first place), sooner or later it has to be decrypted for
> processing.  More particularly, the keys have to be decrypted before
> passing them to the crypto library--and that is visible in memory.  

Yes and no. The implementation we have now XORs using a randomly
generated blob that is regenerated every time the key is used and
remasked. This basically means that it is a one-time pad which is not
poor man's encryption at all but in fact the only provably secure
encryption method (look it up on Wikipedia). The weakness is that the
random blob is also stored in memory, and we try to mitigate that
somewhat by attempting to vary the location in memory that it is stored at.

> So my questions:
> * is the effort worth-while, just for shortening the time of exposure?
> * if so, why not use a real encryption instead of XOR?

We do use real encryption. All sensitive data is stored encrypted using
a 256-bit AES key. But at run-time, we will need to decrypt data which
means that the key needs to be in memory. To have an extra layer of
security (which arguably is obfuscation and thus security by obscurity)
we do the XOR.

> Now back to protecting the communications of the pkcs#11 proxy:
> 
> I think a first step would be to agree on a threat scenario, maybe
> based on a usage assumption.
> 
> If you look at a smartcard-based digital signature, it can only be
> created by whom has 
> * something you have (an unclonable HSM/Smartcard/secure storage device)
> * something you know (a PIN, password, pass phrase).
> 
> There are some basic assumptions in this approach, namely:
> 
> * the legitimate owner of the HSM has sole control (or when lost,
>   revokes the whole thing)
> 
> * something you know exists only in a private memory (our heads) and is
>   transmitted to the HSM through some protected channel that aren't
>   accessible to anyone/thing else. Obvioulsy, writing your PIN on some
>   post-it, or writing it on some disk (no matter how obfuscated),
>   violates the basic assumptions of this approach..
> 
> So what is it that we are doing with an S(not H)SM?

SoftHSM uses password-based encryption (PKCS #5/RFC 4880) to derive a
256-bit AES key. This key is used to encrypt a second randomly generated
(on token initialisation) 256-bit AES key (the reason for having a
two-tiered model is that you can change the PIN without having to
re-encrypt all the data on the token). This is a secure way of
protecting the data in SoftHSM and the security can be upgraded
gradually by increasing the number of hash iterations used to derive the
key from the passphrase and it is also possible to change the hash
algorithm (currently SHA-256 is used).

> * 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. We are also considering - for a future version -
replacing the PIN/SO PIN by a USB crypto token.

> * Since it is an application is using the S(h)SM, the secret (PIN) used
>   cannot really be all that private (it is somewhere on the disk, not
>   in a private head), and surely cannot take the same role it does in a
>   human-smartcard scenario.

Not necessarily; the application could have a PIN entry agent (apache
supports this for instance). OpenDNSSEC, however, currently does not
have this feature. In my opinion, this is an application designer choice
or a user choice and is not something that can/should be mitigated in
SoftHSM.

>   In a human-smartcard scenario, if the card is lost, unless you also
>   steal the secret (PIN), the card is useless.  The lost card is enough
>   to motivate a revocation--the secret only protects exploits in the
>   limited time window from when the HSM/token is lost to when it is
>   revoked.
>   (And on top of this, it expresses user-consent to sign a specific
>   document; something that isn't applicable to automatic signatures by
>   applications.)
> 
> So in my book, "user PINs" have very little value in the security
> scenario of S(h)SMs since they are neither private, nor express any
> consent, nor can effectivley prevent exploits of a compromized HSM.  

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.

> Instead, the security of an S(h)SM depends on the degree in which we
> can achieve "sole control" of the S(h)SM by the application that is
> supposed to used it--no matter whether it is used locally or remotely.
> 
> I believe we're getting very physical when we talk of sole control;
> the only way to getting sole control to a public network resource is via
> a trusted HSM owned by the user and verified e.g. via TLS client cert
> auth (as you suggested). But if applications need their own HSM, the
> S(h)SM idea is really mute anyhow..
> 
> I think it is much more realistic to think that sole control comes
> through exclusive physical access.  I imagine for example, that the
> S(h)SM is a host in a (pad)locked case with the only normal way of
> access exposes the PKCS#11 functionality.  Whoever wants to "tamper"
> with the security device (e.g. legitimate upgrade and security fixes of
> the O.S.) needs privilidged access (the key to the pad-lock that is
> locked away in a safe) that is only possible when authorized,
> controlled (at least 2 persons), logged, and audited..
> 
> Sole control of remote access comes from sole control of the channel to
> talk to the S(h)SM, a separate network (subnet), if possible
> through a separate NIC, definitely no routing from the outside
> world.  

How about the good old cross-cable or even serial cable? :-)

> This is not an S(h)SM somewhere in the cloud, but a S(h)SM in a tightly
> controlled physical/operational environment.  
> 
> The alternative in my mind is only an HSM (smartcard) to grant secure
> access to an S(h)SM--an approach which seems to beats the purpose.

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.

Cheers,

Roland

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