<div dir="auto"><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote">Den 27 jan. 2017 06:09 skrev "Peter Gutmann" <<a href="mailto:pgut001@cs.auckland.ac.nz">pgut001@cs.auckland.ac.nz</a>>:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Henry Baker <<a href="mailto:hbaker1@pipeline.com">hbaker1@pipeline.com</a>> writes:<br>
<br>
This seems a lot like security by press release, if you look at the changes:<br>
<div class="quoted-text"><br>
>The guidelines include several new features that will help businesses defend<br>
>their IT systems and information stores from cyber-attacks, including:<br>
><br>
>* Stronger protection for private keys: The best practice will be to use a<br>
</div>>***FIPS 140-2 Level 2 HSM*** or equivalent.  [...] Therefore, companies must<br>
<div class="quoted-text">>either ***store keys in hardware*** they keep on premise hardware, or in a<br>
>new secure cloud-based code signing cloud-based service.<br>
<br>
</div>Since level 2 HSMs are expensive, not so easy to find, and a pain to use,<br>
companies are probably going to take the other option of moving their keys<br>
into the cloud.  So instead of having the key on an, at least on theory,<br>
isolated machine on a private LAN it's now in the cloud.  Wonderful.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">While unlikely to be implemented that way, it *could* be secure. Strong emphasis on *could*. </div><div dir="auto"><br></div><div dir="auto">Program the HSM to only accept customer requests that are signed by their trusted keys, or sent over a trusted channel directly to the HSM. Any overrides by the cloud company MUST be logged and audited by an independent entity (such as if the customer reports they lost the authentication key).  </div><div dir="auto"><br></div><div dir="auto">No web interface. Too hard to protect (XSS and all that). Only a simple secure interface with authentication protocols like U2F (phishing and replay protected), from a secure machine. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">
>* Certificate revocation: Most likely, a revocation will be requested by a<br>
>malware researcher or an application software supplier like Microsoft, if<br>
>they discover users of their software may be installing suspect code or<br>
>malware. After a CA receives request, it must either revoke the certificate<br>
>within two days, or alert the requestor that it has launched an investigation.<br>
<br>
</div>So the problem here was that if a malware researcher requested a revocation,<br>
the CA typically did nothing.  Now they're still free to do nothing, as long<br>
as they claim they're investigating.<br>
<br>
The first of those two arguably makes things worse rather than better, and the<br>
second is just business as usual.  The final one, use of TSAs, is necessitated<br>
by the way certs work and mostly a no-op.  "Realizing the importance of the<br>
case, my men are rounding up twice the usual number of suspects".<br>
<font color="#888888"><br>
Peter.<br>
</font><div class="elided-text">______________________________<wbr>_________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" rel="noreferrer" target="_blank">http://www.metzdowd.com/<wbr>mailman/listinfo/cryptography</a></div></blockquote></div><br></div></div>