[149112] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] HSM's

daemon@ATHENA.MIT.EDU (Natanael)
Mon Jan 20 10:58:34 2014

X-Original-To: cryptography@metzdowd.com
In-Reply-To: <66955219-21CD-493F-BBB7-65019FE9D78F@lrw.com>
Date: Sun, 19 Jan 2014 09:22:55 +0100
From: Natanael <natanael.l@gmail.com>
To: Jerry Leichter <leichter@lrw.com>
Cc: Cryptography Mailing List <cryptography@metzdowd.com>,
	Bill Frantz <frantz@pwpconsult.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

--===============0094571493693860535==
Content-Type: multipart/alternative; boundary=047d7b86d6be69d24404f04e7b13

--047d7b86d6be69d24404f04e7b13
Content-Type: text/plain; charset=UTF-8

Den 19 jan 2014 06:43 skrev "Jerry Leichter" <leichter@lrw.com>:
>
> 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

Wouldn't that simply be a matter of using algorithms like Secure Multiparty
Computation among a number of devices that has a shares of a key split
among them using something like Shamir's Secure Sharing Scheme?

- Sent from my phone

--047d7b86d6be69d24404f04e7b13
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Den 19 jan 2014 06:43 skrev &quot;Jerry Leichter&quot; &lt;<=
a href=3D"mailto:leichter@lrw.com">leichter@lrw.com</a>&gt;:<br>
&gt;<br>
&gt; On Jan 18, 2014, at 1:07 PM, Bill Frantz wrote:<br>
&gt; &gt;&gt; Open question: =C2=A0What do people think of the production o=
f big important<br>
&gt; &gt;&gt; keys using the old compliance method of &quot;must use a HSM&=
quot; now ?<br>
&gt; &gt;<br>
&gt; &gt; I have always looked at HSMs as black boxes built by people I don=
&#39;t trust. If I built it I would feel different, but you should be uncom=
fortable using my HSM. Getting mutually suspicious people to trust the same=
 HSM is an interesting social/technical problem.<br>

&gt; I&#39;d look at this differently: =C2=A0Is there a construction that p=
reserves the good properties of HSM&#39;s (potential for a very small attac=
k 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)? =C2=
=A0If you look at this as analogous to network routing - where there is gre=
at utility in using the large number of &quot;black box&quot; routers out t=
here to communicate, even if you don&#39;t trust any of them - then somethi=
ng akin to the construction of a mix suggests itself. =C2=A0That is, could =
you define a standard interface to an HSM with the property that it&#39;s &=
quot;securely composable&quot;: =C2=A0You can combine a bunch of HSM&#39;s =
and get something with the same interface, but such that as long as at leas=
t one of the HSM&#39;s lives up to its security properties, the whole ensem=
ble does? =C2=A0Can you, under some assumption like &quot;each box may be s=
eparately cheating, but they don&#39;t cooperate&quot; get something even s=
tronger?<br>

&gt;<br>
&gt; 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, indee=
d, securely composable.<br>

&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Jerry</p>
<p dir=3D"ltr">Wouldn&#39;t that simply be a matter of using algorithms lik=
e Secure Multiparty Computation among a number of devices that has a shares=
 of a key split among them using something like Shamir&#39;s Secure Sharing=
 Scheme? </p>

<p dir=3D"ltr">- Sent from my phone</p>

--047d7b86d6be69d24404f04e7b13--

--===============0094571493693860535==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============0094571493693860535==--

home help back first fref pref prev next nref lref last post