[Cryptography] HSM's

[ianG]

On 19/01/14 22:49 PM, Thierry Moreau wrote:

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


That stuff ... I could never understand how it would work in a
complicated environment when we have live active inside and outside
attackers...

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


Right.

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


Yes, that's more or less what we developed at CAcert for creating new roots:

http://wiki.cacert.org/Roots/CreationCeremony


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


At CAcert I more or less decided I could not trust the HSMs, as
essentially they were unauditable.  I don't see that has changed, and
what I've heard of other CA practices is that they basically wing it in
this direction.  I guess some Auditors just nod off as soon as they hear
that an approved (?) HSM is used without even checking the circumstances
of the procurement and usage.

So we stuck with the "home grown" HSM concept which was to build a
machine, and lock it down in the secure rack.  This has the risk that
someone can sneak in and steal the root by opening it up.  My call was
that as the CA had covered pretty much all the other risk better, this
was an acceptable risk.  But in the future they should work to reduce
this one as well.

(Formal audit practices are both more stringent and more ropey.
Typically they say "must use a HSM" but no more, so it's a bit of a joke.)


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


:) A problem is that the only people who buy these are forced to buy
them.  So the only ones that are worth making are the ones that people
are forced to buy.  Which is the ones on a popular list somewhere.
Which of course then becomes a self-perpetuating myth, a barrier to
entry and an industrial support policy, all in one.



iang