<br><br>On Friday, January 30, 2015, Peter Gutmann <<a href="mailto:pgut001@cs.auckland.ac.nz">pgut001@cs.auckland.ac.nz</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Warren Kumari <<a href="javascript:;" onclick="_e(event, 'cvml', 'warren@kumari.net')">warren@kumari.net</a>> writes:<br>
<br>
>The keys (eventually) live in a widget in a security envelope, that gets<br>
>wrapped in e.g fine wire mesh and then dunked in epoxy with environmental<br>
>sensors for extreme cold, vibration, light, etc and integrated battery to<br>
>zeroize when it senses tamper. The standard "real" HSM type stuff.<br>
<br>
Do you have any idea just how *hard* it is to do that?  </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div><br></div><div><br></div><div>Yup, stupidly hard to do well and right.<span></span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is something for<br>
release 3.x, or maybe 4.x, when all of the other problems have been sorted<br>
out.<br>
<br>
>I have a feeling we are talking past each other soemwhere...<br>
<br>
Not really.  I'm trying to point out that while you can wish for anything you<br>
want in an HSM (for example I know some folks who'd pay very good money for a<br>
compact, radiation-hardened HSM that'll run off a 48V bus, but I'm not going<br>
to add that to the wishlist), you need to set some practical, achievable<br>
goals.</blockquote><div><br></div><div>I missed the partly rhetorical tone of your question and thought you really were asking what prevents an attacker with access to a full blown HSM from just reading out the keys... but I know that you already understand all this, which is why I was very confused.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If I was asked to budget for what's being wished for, and completely pulling<br>
this out of thin air since I haven't sat down to figure it out in detail, I'd<br>
ask for 3-4 hand-picked FTE's (i.e. I'd choose people I knew had lots of<br>
experience in doing this), a minimum of several years to produce something<br>
(there's a lot more R than D going to be involved in product R&D), and a<br>
budget in the 6-7 figure range.<br>
<br>
Implementing all of what's on the (apparent) wishlist is a really huge<br>
project.  What I'm trying to do is point out that we need to set priorities<br>
for some of the goals, this ==> is achievable within X months and Y cost so<br>
worth doing, this ==> will take X more months and Y cost and should be<br>
deferred until version 2, that sort of thing. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Peter.<br>
<br>
<br>
</blockquote><br><br>-- <br>I don't think the execution is relevant when it was obviously a bad idea in the first place.<br>This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.<br>   ---maf<br>