deploy.py auto-commit

author: jaseg <git@jaseg.de> 2023-12-27 13:42:28 +0100
committer: jaseg <git@jaseg.de> 2023-12-27 13:42:28 +0100
commit: 8a673ca3322350bd7e1580a90f89d0bd0c5fa3bf (patch)
tree: eeec5676c576c03a94b5bc74f929f2962d056ee9 /blog/hsm-basics
parent: 2bb3b936b405f4f089d77655aed62903b6ae0a7f (diff)
parent: ab0eb2b834856c19a195c98435c4525fba08376a (diff)
download: blog-8a673ca3322350bd7e1580a90f89d0bd0c5fa3bf.tar.gz
blog-8a673ca3322350bd7e1580a90f89d0bd0c5fa3bf.tar.bz2
blog-8a673ca3322350bd7e1580a90f89d0bd0c5fa3bf.zip
2 files changed, 240 insertions, 0 deletions
diff --git a/blog/hsm-basics/index.html b/blog/hsm-basics/index.html
new file mode 100644
index 0000000..0c9a062
--- /dev/null
+++ b/blog/hsm-basics/index.html
@@ -0,0 +1,240 @@
+<!DOCTYPE html>
+<html><head>
+    <meta charset="utf-8">
+    <title>Hardware Security Module Basics | Home</title>
+    <meta name="description" content="">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <meta name="mobile-web-app-capable" content="yes">
+    <meta name="color-scheme" content="dark light">
+    <link rel="stylesheet" href="/style.css">
+</head>
+<body><nav>
+    <div class="internal">
+        
+        <a href="/" title="Home">Home</a>
+        <a href="/blog/" title="Blog">Blog</a>
+        <a href="/projects/" title="Projects">Projects</a>
+        <a href="/about/" title="About">About</a>
+    </div>
+    <div class="external">
+        <a href="https://git.jaseg.de/" title="cgit">cgit</a>
+        <a href="https://github.com/jaseg" title="Github">Github</a>
+        <a href="https://gitlab.com/neinseg" title="Gitlab">Gitlab</a>
+        <a href="https://chaos.social/@jaseg" title="Mastodon">Mastodon</a>
+    </span>
+</nav>
+
+    <header>
+        <h1>Hardware Security Module Basics</h1>
+<ul class="breadcrumbs">
+    <li><a href="/">jaseg.de</a></li>
+    <li><a href="/blog/">Blog</a></li><li><a href="/blog/hsm-basics/">Hardware Security Module Basics</a></li>
+</ul>
+ <strong>2019-05-17</strong>
+    </header>
+    <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&amp;D as
+well as certification from the small volumes HSMs are sold in.</p>
+<p>Compared to system integration and certification the pure R&amp;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="diy-or-small-lab-mesh-production">
+<h3>DIY or small lab mesh production</h3>
+<p><strong>Analog sensing</strong> meshes are a proven technology where instead of just monitoring for continuity and shorts, analog
+parameters of the mesh traces such as inductance and mutual capacitance are monitored. In 2019, <a class="reference external" href="https://tches.iacr.org/index.php/TCHES/article/view/7334">Immler et al. published
+a paper</a> where took this principle and turned it all the
+way up. They directly derived a cryptographic secret from the analog properties of their HSM's security mesh in an
+attempt to built a <a class="reference external" href="https://en.wikipedia.org/wiki/Physical_unclonable_function">Physically Unclonable Function, or PUF</a>. The idea with PUFs is that they reproduce some entropy
+that comes from random tolerances of their production process. The same PUF will always yield (approximately) the same
+key, but since you cannot control these random production variations, in practice the resulting PUF cannot be cloned.
+Note however, that its secrets can of course be copied if you find a way to read them out.</p>
+<p>As Immler et al. demonstrated in their paper, you don't need any secret sauce to create an analog mesh sensing circuit.
+All you need are a bunch of (admittedly, expensive) off-the-shelf analog ICs. The interesting bit here is that by
+applying more advanced analog sensing, weaknesses of an otherwise coarse mesh desing could maybe be alleviated. That is,
+instead of monitoring a very fine mesh for continuity, you could instead closely monitor inductance and capacitance of a
+more coarse mesh. This trade-off between sensing circuit complexity (resp. cost) and mesh production capabilities may
+allow someone with a poorly equipped lab to still make a decent HSM. The question is, how do you produce a &quot;decent&quot; mesh
+given only basic tools? Here are some ideas.</p>
+<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>
+    Copyright © 2023 Jan Sebastian Götte
+    / <a href="/about/">About</a>
+    / <a href="/imprint/">Imprint</a>
+</footer>
+<script>
+            if(navigator.getEnvironmentIntegrity!==undefined)document.querySelector('body').innerHTML=`<h1>Your browser
+            contains Google DRM</h1>"Web Environment Integrity" is a Google euphemism for a DRM that is designed to
+            prevent ad-blocking, and which Google has forced into their browsers against widespread public opposition.
+                In support of an open web, this website does not function with this DRM. Please install a browser such
+            as <a href="https://www.mozilla.org/en-US/firefox/new/">Firefox</a> that respects your freedom and supports
+            ad blockers.`;
+        </script>
+    </body>
+</html>
diff --git a/blog/hsm-basics/mori_semi_hsm_talk_web.pdf b/blog/hsm-basics/mori_semi_hsm_talk_web.pdf
new file mode 100644
index 0000000..b8b7177
--- /dev/null
+++ b/blog/hsm-basics/mori_semi_hsm_talk_web.pdf
author	jaseg <git@jaseg.de>	2023-12-27 13:42:28 +0100
committer	jaseg <git@jaseg.de>	2023-12-27 13:42:28 +0100
commit	8a673ca3322350bd7e1580a90f89d0bd0c5fa3bf (patch)
tree	eeec5676c576c03a94b5bc74f929f2962d056ee9 /blog/hsm-basics
parent	2bb3b936b405f4f089d77655aed62903b6ae0a7f (diff)
parent	ab0eb2b834856c19a195c98435c4525fba08376a (diff)
download	blog-8a673ca3322350bd7e1580a90f89d0bd0c5fa3bf.tar.gz blog-8a673ca3322350bd7e1580a90f89d0bd0c5fa3bf.tar.bz2 blog-8a673ca3322350bd7e1580a90f89d0bd0c5fa3bf.zip