diff options
Diffstat (limited to 'posts/hsm-basics')
| -rw-r--r-- | posts/hsm-basics/index.html | 279 | ||||
| -rw-r--r-- | posts/hsm-basics/mori_semi_hsm_talk_web.pdf | bin | 0 -> 1075912 bytes |
2 files changed, 279 insertions, 0 deletions
diff --git a/posts/hsm-basics/index.html b/posts/hsm-basics/index.html new file mode 100644 index 0000000..dcbc430 --- /dev/null +++ b/posts/hsm-basics/index.html @@ -0,0 +1,279 @@ +<!DOCTYPE html> +<html lang="en-us"> + <head> + <meta charset="utf-8"> + <meta name="viewport" content="width=device-width, initial-scale=1"> + <title>Hardware Security Module Basics | jaseg.de</title> + <link rel="stylesheet" href="/css/style.css" /> + <link rel="stylesheet" href="/css/fonts.css" /> + + <header> + + + <link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/atom-one-light.min.css"> + <script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js"></script> + <script>hljs.initHighlightingOnLoad();</script> + <nav> + <ul> + + + <li class="pull-left "> + <a href="https://blog.jaseg.de/">/home/jaseg.de</a> + </li> + + + + + </ul> + </nav> +</header> + + </head> + + <body> + <br/> + +<div class="article-meta"> +<h1><span class="title">Hardware Security Module Basics</span></h1> + +<h2 class="date">2019/05/17</h2> +<p class="terms"> + + + + + +</p> +</div> + + + +<main> +<div class="document"> + + +<div class="section" id="hardware-security-modules-and-security-research-and-cryptography"> +<h2>Hardware Security Modules and Security Research and Cryptography</h2> +<p>On May 17 2019 I gave a short presentation on the fundamentals of hardware security modules at the weekly seminar of +Prof. Mori's security research working group at Waseda University. The motivation for this was that outside of low-level +hardware security people and people working in the financial industry HSMs are not thought about that often. In +particular most network or systems security people would not consider them an option. Also it could turn out to be +really interesting to think about what could be done with an HSM in conjunction with modern cryptography (instead of +just plain old RSA-OAEP and AES-CBC).</p> +<p><a class="reference external" href="mori_semi_hsm_talk_web.pdf">Click here to download a PDF with the slides for this talk.</a></p> +</div> +<div class="section" id="ideas-for-research-in-hsms"> +<h2>Ideas for research in HSMs</h2> +<p>Preparing for this talk brought me back to some research ideas I've been working on for a while now. Since I'm not sure +I'll find the time to properly research this topic, I thought it would be great to write down some rought outlines first +for future reference.</p> +<div class="section" id="the-problem-with-current-hsm-tech"> +<h3>The Problem with current HSM tech</h3> +<p>Currently, HSMs are only used in certain specific niche applications such as certificate authority key management and +financial transaction data handling. One key reason for this is that HSMs currently don't provide the affordances that +would be needed for them to be adopted more widely by the cryptographic and security engineering community. As far as I +can tell, the two core missing affordances are:</p> +<ol class="arabic simple"> +<li>To be more widely adopted, HSMs must become less expensive. Currently, they go for several tens of thousands of Euro, +which puts them outside most budgets.</li> +<li>To be more widely adopted, HSMs must provide the standardized programming interfaces familiar to cryptographic +developers. Currently, every HSM vendor has their own custom cryptographic API and a developer will have to train on +one specific vendor's tooling. Furthermore, any documentation of these internals is kept secret behind NDAs. This +constitutes a high barrier to entry, decreasing adoption in particular with young developers accustomed to +open-source ecosystems.</li> +</ol> +</div> +<div class="section" id="attacking-cost-of-implementation"> +<h3>Attacking cost of implementation</h3> +<p>The first issue can be addressed by simply creating a viable low-cost alternative. There is no fundamental technical +reason for the high cost of HSMs. This cost is instead due to manufacturers trying to recoup their expenses for R&D as +well as certification from the small volumes HSMs are sold in.</p> +<p>Compared to system integration and certification the pure R&D cost of HSM defense mechanisms themselves is not too high +in an academic context it should be feasible to develop a sort of HSM blueprint that can then be cheaply produced by +anyone in need. Since the application areas outlined here are far from the core business areas of the clients of +established HSM vendors this would most likely not be a realistic threat to any established vendor's business and a +co-existence of both should not pose any problems in the short term.</p> +</div> +<div class="section" id="benefits-of-an-academic-hsm-standard"> +<h3>Benefits of an academic HSM standard</h3> +<p>Tackling the high cost of current HSM hardware with an open-source HSM blueprint would yield +several academic advantages beyond cost reduction.</p> +<ol class="arabic simple"> +<li>An open-source blueprint could serve as an academic reference design to evaluate and compare other HSM designs +against. For instance this would not only allow quantifying the effectiveness of academic security measures but also +allow an evaluation of commercial HSMs.</li> +<li>An open-source blueprint could stimulate academic research in this academically very quiet albeit commercially +important area. This research would ultimately benefit everyone employing HSMs by raising security standards in the +field. Since HSMs are never solely relied upon for overal system security both defensive and offensive security +research would yield these benefits.</li> +<li>An open-source blueprint would encourage new people to get into the field and both apply HSMs to practical problems +as well as improve HSMs themselves. Currently, this is highly discouraged due to the strictly proprietary nature of +all available systems.</li> +<li>Finally, developing an open-source HSM blueprint might yield new findings in adjacent academic areas due to the +hightly multi-disciplinary nature of security research in general and HSM design in particular.</li> +</ol> +</div> +<div class="section" id="scope-of-an-academic-hsm-standard"> +<h3>Scope of an academic HSM standard</h3> +<p>An academic HSM blueprint would need to be flexible so that researchers can adapt it to their particular problem. A +modular architecture would lend itself to this flexibility. Fundamentally, there would be three components to this +architecture. First, a <strong>base</strong> containing infrastructure such as the surveillance microcontroller, power supplies, +power supply filtering and hardware DPA countermeasures, and possibly a standardized mechanical and electrical +interface.</p> +<p>Next to the base, a system integrator would put their <em>payload</em>. The nature of this payload is intentionally kept +unspecified, and it might be anything from a cryptographic microcontroller to a small embedded system such as a +raspberry pi single board computer. Keeping the <em>payload</em> open like this achieves two benefits: It gives the HSM +blueprint's user <em>their</em> familiar tooling and the hardware <em>they</em> need, allowing fast adoption. Someone well-versed in +e.g. Javascript could literally implement their cryptography in Javascript, run it on an off-the-shelf raspberry pi and +just apply the HSM blueprint around it. In addition, keeping the <em>payload</em> open reduces the scope of what needs to be +implemented. Building a general SDK on top of something like a bare ARM SoC such as a TI OMAP or a Freescale/NXP IMX +would be a considerable additional burden, on top of the actual HSM design. Keeping the <em>payload</em> open allows research +to concentrate on the actual point, the HSM design.</p> +<p>The final and most important component would be a set of <em>security measures</em> that can be combined with the base to +form the final HSM. Each of these <em>security measures</em> would entail a detailed specification of its design, manufacture +and security properties. These <em>security measures</em> could be simple things like tamper switches or potting, but could +also be complex things like security meshes.</p> +<p>Given these three components -- <em>base</em>, <em>payload</em> and <em>security measures</em> as detailed specifications any engineer should +be able to design and manufacture a HSM customized to their needs. Unifying these three components within the HSM +blueprint would be a set of reference designs. Each reference design would implement a particular parametrization of the +three architectural components with a physical hole cut out where the payload would go.. These reference designs would +for one serve to guide any implementer on the customization and integration of their own derivation from the blueprint. +In addition it would serve as an extremely simple, low-cost point of entry into the ecosystem. A curious researcher +could simply replicate the reference design and put their existing payload inside. Practically this might mean e.g. a +researcher having PCBs produced according to the design files for a reference design for a mesh-based HSM, producing +their own mesh, physically glueing a raspberry pi SBC into the middle of it, and potting the resulting system. Given the +ease of prototype PCB fabrication today this would realistically allow evaluation of HSM technologies on a budget that +is orders of magnitude less than the cost of current HSMs.</p> +</div> +</div> +<div class="section" id="research-ideas-for-tamper-detection-mechanisms"> +<h2>Research ideas for tamper detection mechanisms</h2> +<p>The core component of an HSM blueprint would be a suite of tamper detection mechanisms. Following are a few ideas on how +to improve on the current state of the art of membrane tamper switches plus temperature sensors plus PCB and printed +security meshes plus potting.</p> +<div class="section" id="improvements-on-existing-techniques"> +<h3>Improvements on existing techniques</h3> +<div class="section" id="light-sensors"> +<h4>Light sensors</h4> +<p><strong>Advanced analog sensing</strong> +<strong>Self-test functionality</strong></p> +</div> +<div class="section" id="security-meshes"> +<h4>Security meshes</h4> +<p><strong>Analog sensing</strong></p> +</div> +</div> +<div class="section" id="diy-or-small-lab-mesh-production"> +<h3>DIY or small lab mesh production</h3> +<p><strong>3D metal patterning techniques</strong> refers to any technique for producing thin, patterned metal structures on a +three-dimensional plastic substrate. The basic process would consist of 3D-printing the polymer substrate, depositing a +thin metal layer on top and then patterning this metal layer. A good starting point here would be the recent work of +<a class="reference external" href="https://www.youtube.com/watch?v=Z228xymQYho">Ben Kraznow</a> on this exact thing.</p> +<p><strong>Copper filament methods</strong> would be any method embedding copper wire from a spool in some resin or other matrix. This +could mean either of a systematic approach of carefully winding or folding the copper wire into patterns or a +non-systematic approach of simply stuffing a large tangle of copper wire into a small space. The main challenge with the +former would be to find a non-tedious way of production. The main challenge with the latter would be to find process +parameters that guarantee complete coverage of the HSM without holes or other areas of lower sensitivity to intrusions. +Both approaches would require careful consideration of the overall design including the polymer resin supporting +structure to ensure sensitivity against attacks since copper wire is mechanically much stronger than the micrometre-thin +metal coatings used in patterning techniques.</p> +</div> +<div class="section" id="envelope-measurement"> +<h3>Envelope measurement</h3> +<p>Finally, I think there is another set of currently under-utilized tamper-detection methods that would be very +interesting to explore. I am not aware of an academic term for these, so I am just going to dub them <em>envelope +measurement</em> here.</p> +<p>The fundamental apporach of a mesh is to build a physical security envelope (the mesh) that physically detects when it +is disturbed (open or short circuits). This approach works well but has the disadvantage that these meshes are rather +complex to manufacture since effectively every part of them is acting as a sensing element. A conceptually more complex +but in practice potentially simpler approach might be to split the functions of security envelope and sensing element. +This would mean that in place of the mesh, some form of passive element such as metal foil forms the security envelope +which is then checked for tampering using a very sensitive sensor inside. This remote-sensing approach might simplify +the manufacture of the envelope itself and thus yield a design that is more easily customized. Following are a few ideas +on how to approach this envelope measurement problem.</p> +<p><strong>Ultrasonic</strong> If the HSM is potted, a few ultrasonic transducers could be added inside the potting. With several +transducers, any one could be used to transmit ultrasound while the others measure complex phase and energy of the +signal they receive. The circuitry for this could be made fairly simple if using a static transmit frequency or a low +chirp rate by using a homodyne receiver built around a comparator fed into some timers. This approach would likely +detect any mechanical attack and would also rule out chemical attacks involving liquids (though starting from which +amount of liquid depends on receiver sensitivity). The main disadvantages might be high power consumption and cost and +size of the ultrasonic transducers. Traditional cheap transducers made for air as a transmission medium are fairly large +and might not adequately couple into potting compound. If somehow one could convince a standard small piezo element to +do the same job that would be great as far as cost and size are concerned. A concern in some fringe use cases might be +suceptibility to ambient noise, though this could easily be reduced at the expense of space and heat dissipation +capacity by adding sound dampening on the outside. A likely attack vector against this approach might be using a laser +cutter to drill a hole through the potting compound, then inserting probes carefully chosen to not couple too much +to the potting compound ultrasonically.</p> +<p><strong>Light</strong> In either an unpotted HSM or one potted with a transparent (at some wavelengths) potting compound one could +embed LEDs and photodiodes in a similar setup to the ultrasonic setup described above. In contrast to the ultrasound, +the LEDs would literally have to light up the HSM's interior and shadows might be an issue since the HSM is likely some +flat rectangular shape. A possible solution to this would be to coat both the embedded payload and the lid with some +highly reflective paint such as some glossy silver paint or simple white paint. The basic approach might be as simple as +simply turning on several LEDs distributed throughout the HSM in turn and measuring amplitude at several photodetectors, +or as complex as doing a LIDAR-like phase measurement sweeping through a range of frequencies to determine not only +absorption but also phase/distance characteristics between emitter LED and detector photodiode. Using some high-gain TIA +along with a homodyne detector (lock-in amplifier) and changing emitter intensity, very precise measurements of both +absorption and phase might be possible, as might be measurements through almost opaque, diffuse potting compounds such +as a grey epoxide resin. The main disadvantages of this method would likely be the need to thoroughly light-proof the +entire HSM (likely by wrapping it in metal foil) and the potentially high cost of transmitter and receiver circuitry +(nice TIAs aren't cheap). To be effective against attacks using e.g. very fine drills and probes the system would likely +have to be very sensitive.</p> +<p><strong>Radar</strong> Finally, one could turn to standard radar techniques to fingerprint the inside of the HSM. The goal here would +be fingerprinting instead of mapping since only changes need to be detected. In this approach one could use homodyne +detection to improve sensitivity and reduce receiver complexity, and sweep frequencies similar to an FMCW radar (but +probably without exploiting the self-demodulation effect). Besides high cost, this approach has two disadvantages. +First, such a system would likely not go beyond 24GHz or maybe 40GHz due to component availability issues. Even at 40GHz +the wavelength in the potting compound would be in the order of magnitude of several millimeters. Fine intrusions using +some tool chosen to not interact too much with the EM field inside the HSM such as a heated ceramic needle or simply a +laser cutter might not be detectable using this approach. In any case, this system would certainly not be able to detect +small holes piercing the HSM enclosure. The HSM enclosure would have to be made into an RF shield, likely by using some +metal foil in it.</p> +<p>Overall in the author's opinion these three techniques are most promising in order <em>Light</em>, <em>Ultrasonic</em>, <em>Radar</em>. Light +would prbably provide the best sensitivity at expense of some cost. Ultrasonic might be used in conjunction with light +to cover some additional angles since it is potentially very low-cost. Radar seems hard to engineer into a solution that +works reliably and also would likely be at least an order of magnitude more expensive than the other two technologies +while not providing better sensitivity.</p> +</div> +</div> +</div> +</main> + + <footer> + +<script> +(function() { + function center_el(tagName) { + var tags = document.getElementsByTagName(tagName), i, tag; + for (i = 0; i < tags.length; i++) { + tag = tags[i]; + var parent = tag.parentElement; + + if (parent.childNodes.length === 1) { + + if (parent.nodeName === 'A') { + parent = parent.parentElement; + if (parent.childNodes.length != 1) continue; + } + if (parent.nodeName === 'P') parent.style.textAlign = 'center'; + } + } + } + var tagNames = ['img', 'embed', 'object']; + for (var i = 0; i < tagNames.length; i++) { + center_el(tagNames[i]); + } +})(); +</script> + + + <div id="license-info"> + ©2020 by Jan Götte. This work is licensed under + <a href="https://creativecommons.org/licenses/by-nc-sa/4.0/">CC-BY-NC-SA 4.0</a>. + </div> + <div id="imprint-info"> + <a href="/imprint">Impressum und Haftungsausschluss und Datenschutzerklärung</a>. + </div> + </footer> + </body> +</html> + diff --git a/posts/hsm-basics/mori_semi_hsm_talk_web.pdf b/posts/hsm-basics/mori_semi_hsm_talk_web.pdf Binary files differnew file mode 100644 index 0000000..b8b7177 --- /dev/null +++ b/posts/hsm-basics/mori_semi_hsm_talk_web.pdf |