deploy.py auto-committmp

author: jaseg <git@jaseg.de> 2021-08-16 13:28:57 +0200
committer: jaseg <git@jaseg.de> 2021-08-16 13:28:57 +0200
commit: 63ef9727eb44275eb3ae70f24e584a37a58d415a (patch)
tree: 22efc0f0bfc5a20f4832c69e240223e0338da8f8 /posts/kicad-mesh-plugin/index.html
parent: 403b121807ad1d238806e1c1212a6dedcadb761a (diff)
parent: 6c1bf0bbf6189c6927514f58271dd63831909640 (diff)
download: blog-tmp.tar.gz
blog-tmp.tar.bz2
blog-tmp.zip
1 files changed, 255 insertions, 0 deletions
diff --git a/posts/kicad-mesh-plugin/index.html b/posts/kicad-mesh-plugin/index.html
new file mode 100644
index 0000000..7ed444f
--- /dev/null
+++ b/posts/kicad-mesh-plugin/index.html
@@ -0,0 +1,255 @@
+<!DOCTYPE html>
+<html lang="en-us">
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>Kicad Mesh Plugin | 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">Kicad Mesh Plugin</span></h1>
+
+<h2 class="date">2020/08/18</h2>
+<p class="terms">
+  
+  
+  
+  
+  
+</p>
+</div>
+
+
+
+<main>
+<div class="document">
+
+
+<figure>
+<img src="images/anim.webp" style="max-width: 20em">
+</figure><div class="section" id="tamper-detection-meshes">
+<h2>Tamper Detection Meshes</h2>
+<p>Cryptography is at the foundation of our modern, networked world. From email to card payment infrastructure in brick and
+mortar stores, cryptographic keys secure almost every part of our digital lives againts cybercriminals or curious
+surveillance capitalists. Without cryptography, many of the things we routinely do in our lives such as paying for
+groceries with a credit card, messaging a friend on <a class="reference external" href="https://signal.org">Signal</a> or unlocking a car with its keyfob
+would not be possible. The security of all of these systems in its core lies on the secrecy of cryptographic keys.
+Systems differ in what kind of keys they use, how often these keys are replaced and the intricacies of the cryptographic
+operations these keys fit into but all have in common that their security relies on keeping the keys secret.</p>
+<p>In practice, this secrecy has been implemented in many different ways. Mass-market software such as browsers or
+messenger apps usually relies on some operating system facility to tell the computer &quot;<em>please keep this piece of memory
+away from all other applications</em>&quot;. While on desktop operating systems usually this does not provide much of a barrier
+to other programs on the same computer, on modern mobile operating systems this approach is actually quite secure.
+However, given sufficient resources no security is perfect. All of these systems can be compromised if the host
+operating system is compromised sufficiently, and for organizations with considerable resources a market has sprung up
+that offers turn-key solutions for all wiretapping needs.</p>
+<p>In some applications, this level of security has not been considered sufficient. Particularly financial infrastructure
+is such a high-profile target that a lot of effort has been put into the security of cryptographic implementations. The
+best cryptographic algorithm is useless if it is run on a compromised system (from that system's point of view anyway).
+One of the core cryptographic components in financial applications are smartcards like they are used as payment cards in
+most countries nowadays. These smartcards contain a small, specialized cryptographic microcontroller that is designed to
+be hard to tamper with. Though one of the design goals of the system is to reduce the amount of sensitive information
+stored on the card, things such as copying of a card can only be hindered by making the chip hard to read out.</p>
+<figure>
+    <img src="images/modern_art.svg" style="max-width: 20em">
+</figure><p>With smartcards being the means of choice on one side of the counter in electronic payments, on the other side of the
+counter a different technology prevails. Attacks on payment terminals are bound to have much more dire consequences than
+attacks on individual cards since one terminal might see hundreds of cards being read every day. For this reason, the
+level of attack countermeasures employed in these terminals is a considerable step up from bare smartcards. While a
+smartcard is made physically hard to tamper, it does not have a battery and it can only detect tampering once it is
+powered by a reader. This allows for well-equipped attackers to use tools such as Focused Ion Beam (FIB) workstations to
+circumvent the smartcard's defences while it is powered down, and then power up the card to carry out the actual attack.</p>
+<p>The answer to this problem in electronic payment infrastructure is called <em>Hardware Security Module</em>, or HSM. An HSM is
+similar to a smartcard in its function (cryptographic processing using keys that are meant to never leave the protection
+of the HSM). The one major between the two is that an HSM has its own battery and is continuously powered from its
+manufacture to the day it is scrapped. If the HSM looses power at any point in time, it uses a small amount of energy
+stored internally to securely wipe all cryptographic secrets from its memory within a few milliseconds.</p>
+<p>Being powered at all times allows the HSM to actively detect and respond to attacks. The most common way this is done is
+by wrapping the juicy secret parts in a foil or a printed circuit board that is patterned with a long and convoluted
+maze of wires, called a <em>mesh</em>. The HSM is continuously monitoring these wires for changes (such as shorts, breaks or
+changes in resistance) and will sound the alarm when any are detected. Practically, this presents a considerable hurdle
+to any attacker: They have to find a way to disable or circumvent the mesh while it is being monitored by the HSM.  In
+practice, often this is no insurmountable challenge but it again increases attack costs.</p>
+</div>
+<div class="section" id="diy-meshes">
+<h2>DIY Meshes</h2>
+<p>Throughout my studies in security research I have always had an interest in HSMs. I have taken apart my fair share of
+HSMs and at this point, to understand the technology more, I want to experiment with building my own HSM. In last year's
+<a class="reference external" href="https://blog.jaseg.de/posts/hsm-basics/">HSM basics</a> post I have lined out some ideas for a next generation design that
+deviates from the bread-and-butter apporoach of using a mesh as the primary security feature. Before embarking on
+practical experiments with these ideas, I want to first take a stab at replicating the current state of the art as best
+I can. State of the art meshes often use exotic substrates such as 3D plastic parts with traces chemically deposited on
+their surface or special flexible substrates with conductive ink traces. These technologies will likely be too
+cumbersome for me to implement myself only for a few prototypes, and industrial manufacturers will most likely be too
+expensive. Thus, I will concentrate on regular PCB technology for now.</p>
+<p>The idea of a mesh on a PCB is pretty simple: You have one or several traces that you try to cover every corner of the
+mesh PCB's area with. To be most effective, the traces should be as thin and as close together as possible. To increase
+the chances of a manipulation being detected, multiple traces can also be used that can then be monitored for shorts
+between them.</p>
+<p>While one can feasibly lay out these traces by hand, this really is an ideal application of a simple auto-router. While
+general PCB autorouting is <em>hard</em>, auto-routing just a few traces to approximate a space-filling curve is not. Since I
+am just starting out, I went with the simplest algorithmic solution I could think of. I first approximate the area
+designated to the mesh with a square grid whose cells are a multiple of my trace/space size. The mesh will only be drawn
+into grid cells that are fully inside the set boundaries. All cells outside or going across the border are discarded in
+this step.</p>
+<p>I decided to implement this auto-router in a KiCAD plugin. Though KiCADs plugin API is not the best, it was just about
+usable for this task.</p>
+<figure>
+    <img src="images/kicad-mesh-outline.png" alt="KiCAD showing an irregular board shape with rounded corners and
+    indents. In the middle of the board there is a footprint for a 4-pin surface-mount pin header.">
+    <figcaption>The process starts out with the mesh shape being defined inside KiCAD. The mesh's outline is drawn
+    onto one of the graphical "Eco" layers. A footprint is placed to serve as a placeholder for the mesh's
+    connections to the outside world. This footprint is later used as the starting point for the mesh generation
+    algorithm.</figcaption>
+</figure><figure>
+    <img src="images/grid-vis-plain.svg" alt="A vizualization of the grid fitting process. Over the mesh's irregular
+    outline a grid is drawn. In this picture, all grid cells that are fully inside the grid are shown. Grid cells
+    that overlap the mesh border are highlighted. Grid cells outside of the mesh border are not drawn.">
+    <figcaption>A visualization of the grid fitting process. First, a grid large enough to contain the mesh border
+    is generated. Then, every cell is checked for overlap with the mesh border area. If the cell is fully inside, it
+    (yellow), it is considered in the mesh generation later. Cells outside (gray) or on the border (red) are
+    discarded.</figcaption>
+</figure><p>After generating the grid, starting from the place I want to connect to the mesh, I walk the grid's cells one by one to
+generate a tree that covers the entire grid's area. To set the mesh's starting place I place a footprint on the board
+(dark gray in the picture above) whose designator I then tell my script. The tree generation algorithm looks like a
+depth-first search, except all checks are random. Depending on the level of randomness used at each step of the
+algorithm it yields more or less organized-looking results. Below are five example runs of the algorithm at differing
+levels of randomness with the cells colored according to their distance from the tree root. 0% randomness means that the
+algorithm is going to try cells in forward direction first on every step, and only then try out left and right. 100%
+means that on every step, the algorithm is choosing a new direction at random.</p>
+<figure>
+<figure class="side-by-side">
+    <img src="images/cells-0.svg" alt="a completely organized looking grid with spiral patterns all over.">
+    <figcaption>0%</figcaption>
+</figure><figure class="side-by-side">
+    <img src="images/cells-25.svg">
+    <figcaption>25%</figcaption>
+</figure><figure class="side-by-side">
+    <img src="images/cells-50.svg">
+    <figcaption>50%</figcaption>
+</figure><figure class="side-by-side">
+    <img src="images/cells-75.svg">
+    <figcaption>75%</figcaption>
+</figure><figure class="side-by-side">
+    <img src="images/cells-100.svg" alt="a completely random looking grid with cells aggregating into ireggular
+    areas that look like paint splotches.">
+    <figcaption>100%</figcaption>
+</figure>
+</figure><p>After I have built this tree like you would do in a depth-first search, I draw my one or several mesh mesh traces into
+it. The core observation here is that there is only 16 possible ways a cell can be connected: It has four neighbors,
+each of which it can either be connected to or not, which results in 2^4 options. If you consider rotations and
+mirroring, this works out to rotations or mirrored versions of only six base tiles: The empty tile, a tile with all four
+sides connected, a straight through, a 90 degree bend, and a &quot;T&quot;-junction—see the illustration below.</p>
+<figure>
+    <img src="images/maze_tiles_plain.svg" style="max-width: 20em">
+    <figcaption>
+    There are six possible tile types in our connectivity graph inside its square tiling. This graphic illustrates
+    all sixteen rotations of these with how they would look in a two-conductor mesh.
+    </figcaption>
+</figure><p>After tiling the grid according to the key above, we get the result below.</p>
+<figure>
+    <img src="images/tiles-25-small.svg">
+    <figcaption>
+    An auto-routed mesh with traces colored according to tile types.
+    </figcaption>
+</figure><figure>
+    <img src="images/traces-25-small.svg">
+    <figcaption>
+    The same mesh, but with traces all black.
+    </figcaption>
+</figure><p>Putting it all together got me the KiCAD plugin you can see in the screenshot below.</p>
+<figure>
+    <img src="images/kicad-mesh-settings2.png">
+    <figcaption>
+    The plugin settings window open.
+    </figcaption>
+</figure><figure>
+<img src="images/kicad-mesh-result-large.png">
+<figcaption>
+    After runing the plugin, the generated mesh looks like this in pcbnew.
+</figcaption>
+</figure><p>I am fairly happy with the result, but getting there was a medium pain. Especially KiCAD's plugin API is still very
+unfinieshed. It is hard to use, most parts are completely undocumented and if you use anything but its most basic parts
+things tend to break. One particular pain point for me was that after generating the mesh, the traces have been added to
+the board, but are still invisible for some reason. You have to save the board first, then re-load the file for them to
+become visible. Also KiCAD crashes whenever the plugin tries to remove a trace, so currently my workflow involves always
+making a copy of the board file first and treating mesh generation as a non-reversible finishing step.</p>
+<p><a class="reference external" href="https://git.jaseg.de/kimesh.git/tree/plugin/mesh_dialog.py">Check out the code on my cgit</a>.</p>
+<!-- ::
+
+.. raw:: html
+
+    <figure>
+        <img src="images/grid-vis-plain.svg" alt="">
+        <figcaption></figcaption>
+    </figure> -->
+</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">
+           &#169;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>
+
author	jaseg <git@jaseg.de>	2021-08-16 13:28:57 +0200
committer	jaseg <git@jaseg.de>	2021-08-16 13:28:57 +0200
commit	63ef9727eb44275eb3ae70f24e584a37a58d415a (patch)
tree	22efc0f0bfc5a20f4832c69e240223e0338da8f8 /posts/kicad-mesh-plugin/index.html
parent	403b121807ad1d238806e1c1212a6dedcadb761a (diff)
parent	6c1bf0bbf6189c6927514f58271dd63831909640 (diff)
download	blog-tmp.tar.gz blog-tmp.tar.bz2 blog-tmp.zip