<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 2017-02-17, at 08:51 , Mike Hamburg <<a href="mailto:mike@shiftleft.org" class="">mike@shiftleft.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">"While devices from Thales have been proven in a range of settings including some of the world’s most stringent environments, you do not need to take our word for the fact that they are more secure. Thales products have been independently certified to meet FIPS 140-2 and Common Criteria standards.”</div></div></div></blockquote><div class="">Yeah, FIPS 140-2 means little, and CC depends on what level.</div></div></div></div></blockquote>CC also depends on the claims (SFRs in CC language) and the expected environment (Objectives for the Environment).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">What is the actual state of real-world security from respectable HSMs? How hard is it to extract secrets from a "level 4" tamper-resistant HSM that attempts to erase secrets when a potential attack is detecte?</div></div></div></blockquote><div class="">I’m not sure. It’s supposed to be hard, but I’ve never looked closely at the evaluation of such HSMs. There certainly are shoddy HSMs on the market, which leak their secrets (presumably accidentally) through radio emissions. I’d look carefully at what the certifications claim.</div></div></div></div></blockquote><div>Yes, I would advise that too. It is quite likely that the HSM is evaluated under the assumption that the environment provides significant protection against leakage already. In that case, the threat model possibly does <u class="">not</u> include leakage.</div><div>A recently formalised Protection Profile (<a href="https://www.commoncriteriaportal.org/files/ppfiles/ANSSI-CC-PP-2016_05%20PP.pdf" class="">https://www.commoncriteriaportal.org/files/ppfiles/ANSSI-CC-PP-2016_05%20PP.pdf</a>), i.e. a definition of the minimum security requirements to be tested against, states that the environment should:</div><div><blockquote type="cite" class="">
<div class="page" title="Page 27">
<div class="layoutArea">
<div class="column"><p class=""><span style="font-size: 10pt; font-weight: 700;" class="">OE.Env Protected operating environment
</span></p><p class=""><span style="font-size: 10pt;" class="">The TOE shall operate in a protected environment that limits physical access to the TOE to authorised
Administrators. The TOE software and hardware environment (including client applications) shall be
installed and maintained by Administrators in a secure state that mitigates against the specific risks
applicable to the deployment environment, including (where applicable):
</span></p>
<ul class="">
<li style="font-size: 10.000000pt; font-family: 'Symbol'" class=""><p class=""><span style="font-size: 10.000000pt; font-family: 'Helvetica'" class="">Protection against loss or theft of the TOE or any of its externally stored assets
</span></p>
</li>
<li style="font-size: 10.000000pt; font-family: 'Symbol'" class=""><p class=""><span style="font-size: 10.000000pt; font-family: 'Helvetica'" class="">Inspections to deter and detect tampering (including attempts to access side-channels, or to
access connections between physically separate parts of the TOE, or parts of the hardware </span><span style="font-family: Helvetica; font-size: 10pt;" class="">appliance)</span></p>
</li>
<li style="font-size: 10.000000pt; font-family: 'Symbol'" class=""><p class=""><span style="font-size: 10.000000pt; font-family: 'Helvetica'" class="">Protection against the possibility of attacks based on emanations from the TOE (e.g. </span><span style="font-family: Helvetica; font-size: 10pt;" class="">electromagnetic emanations) according to risks assessed for the operating environment</span></p>
</li>
<li style="font-size: 10.000000pt; font-family: 'Symbol'" class=""><p class=""><span style="font-size: 10.000000pt; font-family: 'Helvetica'" class="">Protection against unauthorised software and configuration changes on the TOE and the </span><span style="font-family: Helvetica; font-size: 10pt;" class="">hardware appliance</span></p>
</li>
<li style="font-size: 10.000000pt; font-family: 'Symbol'" class=""><p class=""><span style="font-size: 10.000000pt; font-family: 'Helvetica'" class="">Protection to an equivalent level of all instances of the TOE holding the same assets (e.g. </span><span style="font-family: Helvetica; font-size: 10pt;" class="">where a key is present as a backup in more than one instance of the TOE). </span></p>
</li>
</ul>
</div>
</div>
</div></blockquote></div><div>Rough translation: the evaluation is under the assumption that the HSM is in a trusted environment. Stealing the HSM, more intense physical and side channel analysis (such as common in the smartcard domain), messing with the settings by a malicious/incompetent system administrator, these are all <u class="">not considered</u> in the evaluation under the quoted PP.</div><div>That thee environment objectives are assumed to be followed in the CC is a fundamental choice of blinders to make an evaluation actually end (not a lot of products are secure if the administrator can’t be trusted, etc etc).</div><div><br class=""></div><div>Other HSMs do not have such assumptions that the environment counters these attacks, and should be tested against side channel attacks etc. Just how strong the attacker considered was, is defined by the number at the end of “AVA_VAN.”.</div><div>This number goes from 1-5, with the rough meaning of:</div><div>AVA_VAN.1: The attack isn’t yet on the internet as a tool or easy technique at the time of evaluation.</div><div>AVA_VAN.2: No easy modification of such tools is possible, or a few days of prodding the product didn’t work.</div><div>AVA_VAN.3: The evaluators determined that it won’t be easy to break the product. They’ll have spent a few weeks to determine this.</div><div>AVA_VAN.4: The evaluators got serious to determine this. Attacks should be months to do, or require very special equipment/knowledge/… Posting a successful attack will get you some respectful nods.</div><div>AVA_VAN.5: The evaluators went pretty much all out within a budget of ±100-300K€. Posting a successful attack will get you some serious respect (and probably job offers from the labs and the other developers).</div><div><br class=""></div><div>Considering the advances in this field, the formal validity of the certificate is 2 years. Certificates older than 5 years don’t have a lot of value anymore, the attack technology has improved too much.</div><div><br class=""></div><div>With kind regards,</div><div>Wouter (who works in the CC domain, mostly smartcards but also HSMs and such)</div></div><br class=""></div></body></html>