diff options
| author | jaseg <git@jaseg.de> | 2023-10-14 14:54:16 +0200 |
|---|---|---|
| committer | jaseg <git@jaseg.de> | 2023-10-14 14:54:16 +0200 |
| commit | d0299874339b48e9f08b063d5864914c07700156 (patch) | |
| tree | e1173ffb785930b6967f50e0bc75b72fdc2c4556 /blog/kicad-mesh-plugin/index.html | |
| parent | f87afaaf44ad9a04dc1434b88db1158b0afc7008 (diff) | |
| parent | d3129f384f2a7313d7d2259b09c4d46661597ed7 (diff) | |
| download | blog-d0299874339b48e9f08b063d5864914c07700156.tar.gz blog-d0299874339b48e9f08b063d5864914c07700156.tar.bz2 blog-d0299874339b48e9f08b063d5864914c07700156.zip | |
deploy.py auto-commit
Diffstat (limited to 'blog/kicad-mesh-plugin/index.html')
| -rw-r--r-- | blog/kicad-mesh-plugin/index.html | 217 |
1 files changed, 217 insertions, 0 deletions
diff --git a/blog/kicad-mesh-plugin/index.html b/blog/kicad-mesh-plugin/index.html new file mode 100644 index 0000000..33ddc30 --- /dev/null +++ b/blog/kicad-mesh-plugin/index.html @@ -0,0 +1,217 @@ +<!DOCTYPE html> +<html><head> + <meta charset="utf-8"> + <title>Kicad Mesh Plugin | 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>Kicad Mesh Plugin</h1> +<ul class="breadcrumbs"> + <li><a href="/">jaseg.de</a></li> + <li><a href="/blog/">Blog</a></li><li><a href="/blog/kicad-mesh-plugin/">Kicad Mesh Plugin</a></li> +</ul> + <strong>2020-08-18</strong> + </header> + <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 "<em>please keep this piece of memory +away from all other applications</em>". 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="http://jaseg.de/blog/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> +<div class="subfigure"> + <figure> + <img src="images/cells-0.svg" alt="a completely organized looking grid with spiral patterns all over."> + <figcaption>0%</figcaption> + </figure> + <figure> + <img src="images/cells-25.svg"> + <figcaption>25%</figcaption> + </figure> + <figure> + <img src="images/cells-50.svg"> + <figcaption>50%</figcaption> + </figure> + <figure> + <img src="images/cells-75.svg"> + <figcaption>75%</figcaption> + </figure> + <figure> + <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> +</div><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 "T"-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> + 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> |