[Cryptography] HSM's

[Thierry Moreau]

Jerry Leichter wrote:
> On Jan 18, 2014, at 1:07 PM, Bill Frantz wrote:
>>> Open question:  What do people think of the production of big important
>>> keys using the old compliance method of "must use a HSM" now ?
>> I have always looked at HSMs as black boxes built by people I don't trust. If I built it I would feel different, but you should be uncomfortable using my HSM. Getting mutually suspicious people to trust the same HSM is an interesting social/technical problem.
> I'd look at this differently:  Is there a construction that preserves the good properties of HSM's (potential for a very small attack surface) without the bad ones (you either have to trust a sealed box that someone else built, or be willing to create it yourself from scratch)?  If you look at this as analogous to network routing - where there is great utility in using the large number of "black box" routers out there to communicate, even if you don't trust any of them - then something akin to the construction of a mix suggests itself.  That is, could you define a standard interface to an HSM with the property that it's "securely composable":  You can combine a bunch of HSM's and get something with the same interface, but such that as long as at least one of the HSM's lives up to its security properties, the whole ensemble does?  Can you, under some assumption like "each box may be separately cheating, but they don't cooperate" get something even stronger?
> 
> It seems to me that such a thing should be possible, but it would take some work to actually formalize (a) the relevant security properties; (b) the HSM interface; and only then (c) the proof that what you have is, indeed, securely composable.
>                                                         -- Jerry

That's nice to dream of a "Multi-Party Computing HSM" (such concepts 
might already exist in the academic literature). But at the end of the 
journey, one party will be faced with the same initial dilemma: trust 
some vendor or build your own (OK each party *independently* faces the 
dilemma).

I once thought that there was substance in an HSM (assuming the HSM API 
could be made "secure" ...).

The more I think about it, the more I see the whole concept a mere 
social issue: irrespective of the technology, you end up trusting a -- 
socially acceptable -- organization operating the HSM.

For an off-line HSM (one used in occasional "key ceremonies") the 
practical solution looks like a controlled Linux kernel plus minimal 
crypto utilities with multi-party key injection and secure destruction 
respectively opening and closing the key ceremony. Pick up the oldest 
hardware that supports your software. Side channel vulnerabilities 
handled by selecting the facilities where the ceremony occurs (more or 
less inhibiting paranoia operating here). The HSM concept turns into an 
organizational trust issue because the parties doing the key injections 
are now a critical point.

For an on-line HSM, you end up trusting the host applications making use 
of the HSM services, again a dependency on the operating organization.

A final note: Anyone aware of an HSM vendor that did not follow NIST 
advice in their engineering? Maybe the HSM concept is just dead after 
the Snowden revelations.

-- 
- Thierry Moreau