[Opendnssec-user] Security of SoftHSM

[Bud P. Bruegger]

> Agreed. Requirement #1: a secure connection between the proxy and the
> server (SSL, preferably also support client authentication).
>
> Roland

Security of a Soft (H) Security Module is indeed intriguing.

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?

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.  

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?


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?

* Unless we find procedures for guaranteeing un-clonability, the whole
  thing falls apart

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

  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.  

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.  

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.

> But first we need a good list of requirements. Maybe you want to
> start on that work? We can assist you more when we have SoftHSM v2.
> 
> // Rickard

Well, I hope this is a useful contribution to defining the
requirements..

best cheers
-b