Split paper/tech report

3 files changed, 615 insertions, 7 deletions

diff --git a/doc/quick-tech-report/Makefile b/doc/quick-tech-report/Makefile
index a2c5f12..8a4bc75 100644
--- a/doc/quick-tech-report/Makefile
+++ b/doc/quick-tech-report/Makefile
@@ -8,22 +8,19 @@ SHELL := bash
 MAKEFLAGS += --warn-undefined-variables
 MAKEFLAGS += --no-builtin-rules
 
-main_tex ?= rotohsm_tech_report
+main_tex ?= rotohsm_paper
+brief_tex ?= rotohsm_tech_report
 
 VERSION_STRING := $(shell git describe --tags --long --dirty)
 
-all: ${main_tex}.pdf
+all: ${main_tex}.pdf ${brief_tex}.pdf
 
 %.pdf: %.tex rotohsm.bib version.tex
 	pdflatex -shell-escape $<
 	biber $* 
 	pdflatex -shell-escape $<
 
-.PHONY: preview
-preview:
-	pdflatex -shell-escape ${main_tex}.tex
-
-version.tex: ${main_tex}.tex rotohsm.bib
+version.tex: ${main_tex}.tex ${brief_tex}.tex rotohsm.bib
 	echo "${VERSION_STRING}" > $@
 
 resources/%.pdf: $(LAB_PATH)/%.ipynb
@@ -33,4 +30,6 @@ resources/%.pdf: $(LAB_PATH)/%.ipynb
 clean:
 	rm -f ${main_tex}.aux ${main_tex}.bbl ${main_tex}.bcf ${main_tex}.log ${main_tex}.blg
 	rm -f ${main_tex}.out ${main_tex}.run.xml texput.log 
+	rm -f ${brief_tex}.aux ${brief_tex}.bbl ${brief_tex}.bcf ${brief_tex}.log ${brief_tex}.blg
+	rm -f ${brief_tex}.out ${brief_tex}.run.xml texput.log 
 
diff --git a/doc/quick-tech-report/rotohsm_paper.pdf b/doc/quick-tech-report/rotohsm_paper.pdf
new file mode 100644
index 0000000..b988dd4
--- /dev/null
+++ b/doc/quick-tech-report/rotohsm_paper.pdf
diff --git a/doc/quick-tech-report/rotohsm_paper.tex b/doc/quick-tech-report/rotohsm_paper.tex
new file mode 100644
index 0000000..6b9d287
--- /dev/null
+++ b/doc/quick-tech-report/rotohsm_paper.tex
@@ -0,0 +1,609 @@
+\documentclass[10pt,journal,a4paper]{IEEEtran}
+\usepackage[english]{babel}
+\usepackage[utf8]{inputenc}
+\usepackage[T1]{fontenc}
+\usepackage[
+    backend=biber,
+    style=numeric,
+    natbib=true,
+    url=false, 
+    doi=true,
+    eprint=false
+    ]{biblatex}
+\addbibresource{rotohsm.bib}
+\usepackage{amssymb,amsmath}
+\usepackage{listings}
+\usepackage{eurosym}
+\usepackage{wasysym}
+\usepackage{amsthm}
+\usepackage{tabularx}
+\usepackage{multirow}
+\usepackage{multicol}
+\usepackage{tikz}
+\usepackage{mathtools}
+\DeclarePairedDelimiter{\ceil}{\lceil}{\rceil}
+\DeclarePairedDelimiter{\paren}{(}{)}
+
+\usetikzlibrary{arrows}
+\usetikzlibrary{chains}
+\usetikzlibrary{backgrounds}
+\usetikzlibrary{calc}
+\usetikzlibrary{decorations.markings}
+\usetikzlibrary{decorations.pathreplacing}
+\usetikzlibrary{fit}
+\usetikzlibrary{patterns}  
+\usetikzlibrary{positioning}
+\usetikzlibrary{shapes}
+
+\usepackage[binary-units]{siunitx}
+\DeclareSIUnit{\baud}{Bd}
+\DeclareSIUnit{\year}{a}
+\usepackage{hyperref}
+\usepackage{tabularx}
+\usepackage{commath}
+\usepackage{graphicx,color}
+\usepackage{ccicons}
+\usepackage{subcaption}
+\usepackage{float}
+\usepackage{footmisc}
+\usepackage{array}
+\usepackage[underline=false]{pgf-umlsd}
+\usetikzlibrary{calc}
+%\usepackage[pdftex]{graphicx,color}
+\usepackage{epstopdf}
+\usepackage{pdfpages}
+\usepackage{minted} % pygmentized source code
+
+\renewcommand{\floatpagefraction}{.8}
+\newcommand{\degree}{\ensuremath{^\circ}}
+\newcolumntype{P}[1]{>{\centering\arraybackslash}p{#1}}
+
+\usepackage{fancyhdr}
+\fancyhf{}
+\fancyfoot[C]{\thepage}
+\newcommand{\includenotebook}[2]{
+    \fancyhead[C]{Included Jupyter notebook: #1}
+    \includepdf[pages=1,
+        pagecommand={\thispagestyle{fancy}\section{#1}\label{#2_notebook}}
+        ]{resources/#2.pdf}
+    \includepdf[pages=2-,
+        pagecommand={\thispagestyle{fancy}}
+        ]{resources/#2.pdf}
+}
+
+\begin{document}
+
+\title{Can't Touch This: Inerial HSMs Thwart Advanced Physical Attacks}
+\author{Jan Götte}
+\date{2020-12-20}
+\maketitle
+
+\section*{Abstract}
+
+In this paper, we introduce a novel countermeasure against physical attacks: Inertial hardware security modules.
+Conventional systems have in common that they try to detect attacks by crafting sensors responding to increasingly
+minute manipulations of the monitored security boundary or volume. Our approach is novel in that we reduce the
+sensitivity requirement of security meshes and other sensors and increase the complexity of any manipulations by
+rotating the security mesh or sensor at high speed---thereby presenting a moving target to an attacker. Attempts to stop
+the rotation are easily monitored with commercial MEMS accelerometers and gyroscopes.  Our approach leads to a HSM that
+can easily be built from off-the-shelf parts by any university electronics lab, yet offers a level of security that is
+comparable to commercial HSMs. By building prototype hardware we have demonstrated solutions to the concept's
+engineering challenges.
+
+\section{Introduction}
+
+While information security technology has matured a great deal in the last half century, physical security has barely
+changed. Given the right skills, physical access to a computer still often means full compromise. The physical
+security of modern server hardware hinges on what lock you put on the room it is in.
+
+Currently, servers and other computers are rarely physically secured as a whole. Servers sometimes have a simple lid
+switch and are put in locked ``cages'' inside guarded facilities. This usually provides a good compromise between
+physical security and ease of maintenance. To handle highly sensitive data in applications such as banking or public key
+infrastructure, general-purpose and low-security servers are augmented with dedicated, physically secure cryptographic
+co-processors such as trusted platform modules (TPMs) or hardware security modules (HSMs). Using a limited amount of
+trust in components such as the CPU, the larger system's security can then be reduced to that of its physically secured
+TPM~\cite{newman2020,frazelle2019,johnson2018}.
+
+Like smartcards, TPMs rely on a modern IC being hard to tamper with.  Shrinking things to the nanoscopic level to secure
+them against tampering is a good engineering solution for some years to come.  However, in essence this is a type of
+security by obscurity: Obscurity here referring to the rarity of the equipment necessary to attack modern
+ICs~\cite{albartus2020,anderson2020}.
+
+HSMs rely on a fragile foil with much larger-scale conductive traces being hard to remove intact.  While we are certain
+that there still are many insights to be gained in both technologies, we wish to introduce a novel approach to sidestep
+the manufacturing issues of both and provide radically better security against physical attacks.  Our core observation
+is that any cheap but coarse HSM technology can be made much more difficult to attack by moving it very quickly.
+
+For example, consider an HSM as it is used in online credit card payment processing. Its physical security level is set
+by the structure size of its security mesh. An attack on its mesh might involve fine drill bits, needles, wires, glue,
+solder and lasers~\cite{drimer2008}.  Now consider the same HSM mounted on a large flywheel. In addition to its usual
+defenses the HSM is now equipped with an accelerometer that it uses to verify that it is spinning at high speed. How
+would an attacker approach this HSM? They would have to either slow down the rotation---which triggers the
+accelerometer---or they would have to attack the HSM in motion. The HSM literally becomes a moving target. At slow
+speeds, rotating the entire attack workbench might be possible but rotating frames of reference quickly become
+inhospitable to human life (see Appendix~\ref{sec_minimum_angular_velocity}). Since non-contact electromagnetic or
+optical attacks are more limited in the first place and can be shielded, we have effectively forced the attacker to use
+an attack robot.
+
+This work contains the following contributions:
+\begin{enumerate}
+    \item We present the \emph{Inertial HSM} concept. Inertial HSMs enable cost-effective small-scale production of
+        highly secure HSMs.
+    \item We discuss possible boundary sensing modes for inertial HSMs.
+    \item We explore the design space of our inertial HSM concept.
+    \item We present our work on a prototype inertial HSM.
+    % FIXME \item Measurement of the prototype HSM's susceptibility to various types of attack.
+\end{enumerate}
+
+In Section~\ref{sec_related_work}, we will give an overview of the state of the art in the physical security of HSMs. On
+this basis, in Section~\ref{sec_ihsm_construction} we will elaborate the principles of our inertial HSM approach. We
+will analyze its weaknesses in Section~\ref{sec_attacks}. Based on these results we have built a prototype system that
+we will illustrate in Section~\ref{sec_proto}. We conclude this paper with a general evaluation of our design in
+Section~\ref{sec_conclusion}.
+
+\section{Related work} 
+\label{sec_related_work}
+% summaries of research papers on HSMs.  I have not found any actual prior art on anything involving mechanical motion
+% beyond ultrasound.
+
+In this section, we will briefly explore the history of HSMs and the state of academic research on active tamper
+detection.
+
+HSMs are an old technology tracing back decades in their electronic realization. Today's common approach of monitoring
+meandering electrical traces on a fragile foil that is wrapped around the HSM essentially transforms the security
+problem into the challenge to manufacture very fine electrical traces on a flexible foil~\cite{isaacs2013, immler2019,
+anderson2020}.  There has been some research on monitoring the HSM's inside using e.g.\ electromagnetic
+radiation~\cite{tobisch2020, kreft2012} or ultrasound~\cite{vrijaldenhoven2004} but none of this research
+has found widespread adoption.
+
+In~\cite{anderson2020}, Anderson gives a comprehensive overview on physical security. An example they cite is the IBM
+4758 HSM whose details are laid out in depth in~\cite{smith1998}. This HSM is an example of an industry-standard
+construction. Though its turn of the century design is now a bit dated, the construction techniques of the physical
+security mechanisms have not evolved much in the last two decades. Apart from some auxiliary temperature and radiation
+sensors to guard against attacks on the built-in SRAM memory, the module's main security barrier uses the traditional
+construction of a flexible mesh wrapped around the module's core. In~\cite{smith1998}, the authors state the module
+monitors this mesh for short circuits, open circuits and conductivity. The fundamental approach to tamper detection and
+construction is similar to other commercial offerings~\cite{obermaier2018,drimer2008,anderson2020,isaacs2013}.
+
+In~\cite{immler2019}, Immler et al. describe a HSM based on precise capacitance measurements of a mesh. In contrast to
+traditional meshes, the mesh they use consists of a large number of individual traces (more than 30 in their example).
+Their concept promises a very high degree of protection. The main disadvantages of their concept are a limitation in
+covered area and component height, as well as the high cost of the advanced analog circuitry required for monitoring. A
+core component of their design is that they propose its use as a PUF to allow for protection even when powered off,
+similar to a smart card---but the design is not limited to this use.
+
+In~\cite{tobisch2020}, Tobisch et al.\ describe a construction technique for a hardware security module that is based
+around commodity Wifi hardware inside a conductive enclosure. In their design, an RF transmitter transmits a reference
+signal into the RF cavity formed by the conductive enclosure. One or more receivers listen for the signal's reflections
+and use them to characterize the RF cavity w.r.t.\ phase and frequency response. Their fundamental assumption is that
+the RF behavior of the cavity is inscrutable from the outside, and that even a small disturbance anywhere within the
+volume of the cavity will cause a significant change in its RF response. The core idea in~\cite{tobisch2020} is to use
+commodity Wifi hardware to reduce the cost of the HSM's sensing circuitry. The resulting system is likely both much
+cheaper and capable of protecting a much larger security envelope than e.g. the design from~\cite{immler2019}, at the
+cost of worse and less predictable security guarantees.  Where~\cite{tobisch2020} use electromagnetic radiation,
+Vrijaldenhoven in~\cite{vrijaldenhoven2004} uses ultrasound waves travelling on a surface acoustic wave (SAW) device to
+a similar end.
+
+While~\cite{tobisch2020} approach the sensing frontend cost as their only optimization target, the prior work of Kreft
+and Adi~\cite{kreft2012} considers sensing quality. Their target is an HSM that envelopes a volume barely larger than a
+single chip. They theorize how an array of distributed RF transceivers can measure the physical properties of a potting
+compound that has been loaded with RF-reflective grains. In their concept, the RF response characterized by these
+transceivers is shaped by the precise three-dimensional distribution of RF-reflective grains within the potting
+compound.
+
+We are the the first to propose a mechanically moving HSM security barrier as part of a hardware security module. Most
+academic research concentrates on the issue of creating new, more sensitive security barriers for HSMs~\cite{immler2019}
+while commercial vendors concentrate on means to cheaply manufacture and certify these security
+barriers~\cite{drimer2008}. Our concept instead focuses on the issue of taking any existing, cheap low-performance
+security barrier and transforming it into a marginally more expensive but very high-performance one. The closest to a
+mechanical HSM that we were able to find during our research is an 1988 patent~\cite{rahman1988} that describes an
+mechanism to detect tampering along a communication cable by enclosing the cable inside a conduit filled with
+pressurized gas.
+
+\section{Inertial HSM construction and operation}
+\label{sec_ihsm_construction}
+
+Mechanical motion has been proposed as a means of making things harder to see with the human eye~\cite{haines2006} and is
+routinely used in military applications to make things harder to hit~\cite{terdiman2013} but we seem to be the first to
+use it in tamper detection. If we consider different ways of moving an HSM to make it harder to tamper with, we find
+that making it spin has several advantages.
+
+First, the HSM has to move fairly fast. If any point of the HSM's tamper sensing mehs moves slow enough for a human to
+follow, it becomes a weak spot. E.g.\ in a linear pendulum motion, the pendulum becomes stationary at its apex.  Second,
+a spinning HSM is compact compared to alternatives like an HSM on wheels.  Finally, rotation leads to predictable
+accelerometer measurements.  A beneficial side-effect of spinning the HSM is that if the axis of rotation is within the
+HSM itself, an attacker trying to follow the motion would have to rotate around the same axis. Their tangential linear
+velocity would rise linearly with the radius from the axis of rotation, which allows us to limit the approximate maximum
+size and mass of an attacker using an assumption on tolerable centrifugal force (see Appendix
+\ref{sec_minimum_angular_velocity}).  In this consideration the axis of rotation is a weak spot, but that can be
+mitigated using multiple nested layers of protection.
+
+\begin{figure}
+    \center
+    \includegraphics{concept_vis_one_axis.pdf}
+    \caption{Concept of a simple spinning inertial HSM. 1 - Shaft. 2 - Security mesh. 3 - Payload. 4 -
+    Accelerometer. 5 - Shaft penetrating security mesh.}
+    \label{fig_schema_one_axis}
+\end{figure}
+
+In a rotating reference frame, centrifugal force is proportional to the square of angular velocity and proportional to
+distance from the axis of rotation. We can exploit this fact to create a sensor that detects any disturbance of the
+rotation by placing a linear accelerometer at some distance from the axis of rotation. During constant rotation, both
+acceleration tangential to the rotation and along the axis of rotation will be zero. Centrifugal acceleration will be
+constant.
+
+Large centrifugal acceleration at high speeds poses the engineering challenge of preventing the whole thing from flying
+apart, but it also creates an obstacle to any attacker trying to manipulate the sensor.  We do not need to move the
+entire contents of the HSM. It suffices if we move the tamper detection barrier around a stationary payload. This
+reduces the moment of inertia of the moving part and it means we can use cables for payload power and data.
+
+From our back-of-the-envelope calculation in Appendix \ref{sec_minimum_angular_velocity} we conclude that even at
+moderate speeds above $\SI{500}{rpm}$, an attack would have to be carried out using a robot.
+
+In Appendix \ref{sec_degrees_of_freedom} we consider sensor configurations and we conclude that one three-axis
+accelerometer each in the rotor and in the stator are a good baseline configuration. In general, the system will be more
+sensitive to attacks if we over-determine the system of equations describing its motion by using more sensors than
+necessary.
+
+\subsection{Mechanical layout}
+
+Thinking about the concrete construction of our mechanical HSM, the first challenge is mounting both mesh and payload on
+a single shaft.  The simplest way we found to mount a stationary payload inside of a spinning security mesh is a hollow
+shaft.  The payload can be mounted on a fixed rod threaded through this hollow shaft along with wires for power and
+data. The shaft is a weak spot of the system, but this weak spot can be alleviated through either careful construction
+or a second layer of rotating meshes with a different axis of rotation.  Configurations that do not use a hollow-shaft
+motor are possible, but may require additional bearings to keep the stator from vibrating.
+
+The next design choice we have to make is the physical structure of the security mesh.  The spinning mesh must be
+designed to cover the entire surface of the payload, but compared to a traditional HSM it suffices if it sweeps over
+every part of the payload once per rotation. This means we can design longitudinal gaps into the mesh that allow outside
+air to flow through to the payload.  In traditional boundary-sensing HSMs, cooling of the payload processor is a serious
+issue since any air duct or heat pipe would have to penetrate the HSM's security boundary. This problem can only be
+solved with complex and costly siphon-style constructions, so in commercial systems heat conduction is used
+exclusively~\cite{isaacs2013}. This limits the maximum power dissipation of the payload and thus its processing power.
+Our setup allows direct air cooling of regular heatsinks. This greatly increases the maximum possible power dissipation
+of the payload and unlocks much more powerful processing capabilities.  In an evolution of our design, the spinning mesh
+could even be designed to *be* a cooling fan.
+
+\subsection{Spinning mesh power and data transmission}
+
+On the electrical side, the idea of a security mesh spinning at more than $\SI{500}{rpm}$ leaves us with a few
+implementation challenges. Since the spinning mesh must be monitored for breaks or short circuits continuously, we need
+both a power supply for the spinning monitoring circuit and a data link to the stator.
+
+We found that a bright lamp shining at a rotating solar panel is a good starting point.  In contrast to e.g.\ slip
+rings, this setup is mechanically durable at high speeds and it also provides reasonable output power (see Appendix
+\ref{sec_energy_calculations} for some calculations on power consumption). A battery may not provide a useful lifetime
+without power-optimization. Likewise, an energy harvesting setup may not provide enough current to supply peak demand.
+
+Since the monitoring circuit uses little current, power transfer efficiency is not important. On the other hand, cost
+may be a concern in a production device. Here it may prove worthwhile to replace the solar cell setup with an extra
+winding on the rotor of the BLDC motor driving the spinning mesh. This rotor is likely to be a custom part, so adding
+an extra winding is unlikely to increase cost significantly. More traditional inductive power transfer may also be an
+option if it can be integrated into the mechanical design.
+
+Besides power, the data link between spinning mesh and payload is critical to the HSM's design.  This link is used to
+transmit the occassional status report along with a low-latency alarm trigger (``heartbeat'') signal from mesh to payload.
+As we will elaborate in Section~\ref{sec_proto} a simple infrared optical link turned out to be a good solution for this
+purpose.
+
+\section{Attacks}
+\label{sec_attacks}
+
+After outlining the basic mechanical design of an inertial HSM above, in this section we will detail possible ways to
+attack it. Fundamentally, attacks on an inertial HSM are the same as those on a traditional HSM since the tamper
+detection mesh is the same. Only, in the inertial HSM any attack on the mesh has to be carried out while the mesh is
+rotating, which for most types of attack will require some kind of CNC attack robot moving in sync with it.
+
+\subsection{Attacks on the mesh}
+
+There are two locations where one can attack a tamper-detection mesh. On one hand, the mesh itself can be tampered with.
+This includes bridging its traces to allow for a hole to be cut. The other option is to tamper with the monitoring
+circuit itself to prevent a damaged mesh from triggering an alarm and causing the HSM to erase its
+contents~\cite{dexter2015}. Attacks in both locations are electronic attacks, i.e. they require electrical contact to
+parts of the circuit. Traditionally, this contact is made by soldering or by placing a probe such as a thin needle.  We
+consider this contact infeasible to be performed on an object spinning at high speed without a complex setup that
+rotates along with the object or that involves ion beams, electron beams or liquids. Thus, we consider them to be
+practically infeasible outside of a well-funded, special-purpose laboratory.
+
+\subsection{Attacks on the rotation sensor}
+
+Instead of attacking the mesh in motion, an attacker may also try to first stop the rotor. To succeed, they would need
+to fool the rotor's MEMS accelerometer. An electronic attack on the sensor or the monitoring microcontroller would be no
+easier than directly bridging the mesh traces. 
+
+MEMS accelerometers usually use a cantilever design, where a proof mass moves a cantilever whose precise position can be
+measured electronically.  A topic of recent academic interest have been acoustic attacks tampering with these
+mechanics~\cite{trippel2017}.  In the authors' estimate these attacks are too hard to control to be practically useful
+against an inertial HSM.
+
+A possible way to attack the accelerometer inside an inertial HSM may be to first decapsulate it using laser ablation
+synchronized with the device's rotation. Then, a fast-setting glue such as a cyanoacrylate could be deposited on the
+moving MEMS parts, locking them in place. To mitigate this type of attack the accelerometer should be mounted in a
+shielded place inside the security envelope.  Further, this attack can only work if the rate of rotation and thus the
+expected accelerometer readings are constant.  If the rate of rotation is set to vary over time this type of attack is
+quickly detected.  In Appendix \ref{sec_degrees_of_freedom} we outline the constraints on sensor placement.
+
+\subsection{Attacks on the alarm circuitry}
+
+Besides trying to deactivate the tamper detection mesh, an electronic attack could also target the alarm circuitry
+inside the stationary payload, or the communication link between rotor and payload. The link can be secured using a
+cryptographically secured protocol like one would use for wireless radio links along with a high-frequency heartbeat
+message. The alarm circuitry has to be designed such that it is entirely contained within the HSM's security envelope.
+Like in conventional HSMs it has to be built to either tolerate or detect environmental attacks such as ones using
+temperature, ionizing radiation, lasers, supply voltage variations, ultrasound or other vibration and gases or liquids.
+Conventionally, incoming power rails are filtered thoroughly to prevent electrical attacks and other types of attacks
+are prevented by sensors that thrigger an alarm.
+
+In an inertial HSM, the mesh monitoring circuit's tamper alarm is transmitted from rotor to stator through a wireless
+link. Since an attacker may wirelessly spoof this link, it must be cryptographically secured. It also must be
+bidirectional to allow the alarm signal receiver to verify link latency: If it were unidirectional, an attacker could
+act as a Man-in-the-Middle and replay the mesh's authenticated ``no alarm'' signal at slightly below real-time speed
+(say at $\SI{99}{\percent}$ speed).  The receiver would not be able to distinguish between this attack and ordinary
+deviations in the transmitter's local clock frequency. Thus, after some time the attacker can simply stop the rotor and
+break the mesh while replaying the leftover recorded ``no alarm'' signal. Given the frequency stability of commercial
+crystals, this would yield the attacker several seconds of undisturbed attack time per hour of recording time.
+
+\subsection{Fast and violent attacks}
+
+A variation of the above attacks on the alarm circuitry is to simply destroy the part of the HSM that erases data in
+response to tampering before it can finish its job. This attack could use a tool such as a large hammer or a gun.
+Mitigations for this type of attack include potting the payload inside a mechanically robust enclosure. Additionally,
+the integrity of the entire alarm signalling chain can be checked continuously using a cryptographic heartbeat protocol.
+A simple active-high or active-low alarm signal as it is used in traditional HSMs cannot be considered fail-safe in this
+scenario as such an attack may well short-circuit or break PCB traces.
+
+\section{Prototype implementation}
+\label{sec_proto}
+
+After elaborating the design principles of inertial HSMs and researching potential attack vectors we have validated
+these theoretical studies by implementing a prototype rotary HSM. The main engineering challenges we solved in our
+prototype are:
+
+\begin{enumerate}
+    \item Fundamental mechanical design suitable for rapid prototyping that can withstand a rotation of $\SI{500}{rpm}$.
+    \item Automatic generation of security mesh PCB layouts for quick adaption to new form factors.
+    \item Non-contact power transmission from stator to rotor.
+    \item Non-contact bidirectional data communication between stator and rotor.
+\end{enumerate}
+
+\subsection{Mechanical design}
+
+We sized our prototype to have space for up to two full-size Raspberry Pi boards. Each one of these boards is already
+more powerful than an ordinary HSM, but they are small enough to simplify our prototype's design.  For low-cost
+prototyping we designed our prototype to use printed circuit boards as its main structural material. The interlocking
+parts were designed in FreeCAD as shown in Figure \ref{proto_3d_design}. The mechanical designs were exported to KiCAD
+for electrical design before being sent to a commercial PCB manufacturer. Rotor and stator are built from interlocking,
+soldered PCBs. The components are mounted to a $\SI{6}{\milli\meter}$ brass tube using FDM 3D printed flanges. The rotor
+is driven by a small hobby quadcopter motor.
+
+Security is provided by a PCB security mesh enveloping the entire system and extending to within a few millimeters of
+the shaft. For security it is not necessary to cover the entire circumference of the module with mesh, so we opted to
+use only three narrow longitudinal struts to save weight.
+
+To mount the entire HSM, we chose to use ``2020'' modular aluminium profile.
+
+\begin{figure}
+    \center
+    \includegraphics[height=7cm]{proto_3d_design.jpg}
+    \caption{The 3D CAD design of the prototype.}
+    \label{proto_3d_design}
+\end{figure}
+
+\subsection{PCB security mesh generation}
+
+The security mesh covers a total of five interlocking PCBs. A sixth PCB contains the monitoring circuit and connects to
+these mesh PCBs.  To allow us to quickly iterate our design without manually re-routing several large security meshes
+for every mechanical chage we wrote a plugin for the KiCAD EDA suite that automatically generates parametrized security
+meshes. When KiCAD is used in conjunction with FreeCAD through FreeCAD's KiCAD StepUp plugin, this ends up in an
+efficient toolchain from mechanical CAD design to security mesh PCB gerber files. The mesh generation plugin can be
+found at its website\footnote{\url{https://blog.jaseg.de/posts/kicad-mesh-plugin/}}. The meshes it produces have a
+practical level of security in our application. 
+
+The mesh generation process starts by overlaying a grid on the target area. It then produces a randomized tree covering
+this grid.  The individual mesh traces are then traced along a depth-first search through this tree. A visualization of
+the steps is shown in Figure \ref{mesh_gen_viz}. A sample of the production results from our prototype is shown in
+Figure \ref{mesh_gen_sample}.
+
+\begin{figure}
+    \center
+    \includegraphics[width=9cm]{mesh_gen_viz.pdf}
+    \caption{Overview of the automatic security mesh generation process. 1 - the blob is the example target area. 2 - A
+    grid is overlayed. 3 - Grid cells outside of the target area are removed. 4 - A random tree covering the remaining
+    cells is generated. 5 - The mesh traces are traced along a depth-first walk of the tree. 6 - Result.}
+    \label{mesh_gen_viz}
+\end{figure}
+
+\begin{figure}
+    \center
+    \includegraphics[width=6cm]{mesh_scan_crop.jpg}
+    \caption{A section of the security mesh PCB we produced with our toolchain for the prototype HSM.}
+    \label{mesh_gen_sample}
+\end{figure}
+
+\subsection{Data transmission through rotating joint}
+
+With the mesh done, the next engineering challenge was the mesh monitoring data link between rotor and stator.  As a
+baseline solution, we settled on a $\SI{115}{\kilo\baud}$ UART signal sent through a simple bidirectional infrared link.
+In the transmitter, the UART TX line on-off modulates a $\SI{920}{\nano\meter}$ IR LED through a common-emitter driver
+transistor. In the receiver, an IR PIN photodiode reverse-biased to $\frac{1}{2}V_\text{CC}$ is connected to a
+reasonably wideband transimpedance amplifier (TIA) with a $\SI{100}{\kilo\ohm}$ transimpedance. As shown in Figure
+\ref{photolink_schematic}, the output of this TIA is fed through another $G=100$ amplifier whose output is then squared
+up by a comparator.  We used an \texttt{MCP6494} quad CMOS op-amp. At a specified $\SI{2}{\milli\ampere}$ current
+consumption it is within our rotor's power budget, and its Gain Bandwidth Product of $\SI{7.5}{\mega\hertz}$ yields a
+useful transimpedance in the photodiode-facing TIA stage.
+
+To reduce the requirements on power transmission to the rotor, we have tried to reduce power consumption of the
+rotor-side receiver/transmitter pair trading off stator-side power consumption. One part of this is that we use
+a wide-angle photodiode and IR LED on the stator, but use narrow-angle components on the rotor. The two rx/tx pairs are
+arranged next to the motor on opposite sides. By placing the narrow-angle rotor rx/tx components on the outside as
+shown in Figure \ref{ir_tx_schema}, the motor shields both IR links from crosstalk. The rotor transmitter LED is
+driven at $\SI{1}{\milli\ampere}$ while the stator transmitter LED is driven at $\SI{20}{\milli\ampere}$.
+
+\begin{figure}
+    \center
+    \includegraphics{ir_tx_schema.pdf}
+    \caption{Schema of our bidirectional IR communication link between rotor and stator, view along axis of rotation. 1
+    - Rotor base PCB. 2 - Stator IR link PCB. 3 - Motor. 4 - receiver PIN photodiode. 5 - transmitter IR LED.}
+    \label{ir_tx_schema}
+\end{figure}
+
+\begin{figure}
+    \center
+    \includegraphics[width=9cm]{photolink_schematic.pdf}
+    \caption{Schematic of the IR communication link. Component values are only examples. In particular C2 depends highly
+    on the photodiode used and stray capacitances due to the component layout.}
+    \label{photolink_schematic}
+\end{figure}
+
+\subsection{Power transmission through rotating joint}
+Besides the data link, the other electrical interface we need between rotor and stator is for power transmission. We
+power Since this prototype serves only demonstration purposes, we chose to use the simplest possible method of power
+transmission: solar cells. We mounted six series-connected solar cells in three commercially available modules on the
+circular PCB at the end of our cylindrical rotor. The solar cells direclty feed the rotor's logic supply with buffering
+by a large $\SI{33}{\micro\farad}$ ceramic capacitor. With six cells in series, they provide around $\SI{3.0}{\volt}$ at
+several tens of $\si{\milli\ampere}$ given sufficient illumination.
+
+For simplicity and weight reduction, at this point we chose to forego large buffer capacitors on the rotor. This means
+variations in solar cell illumination directly couple into the microcontroller's supply rail. Initially, we experimented
+with regular residential LED light bulbs, but those turned out to have too much flicker and lead to our microcontroller
+frequently rebooting. Trials using an incandecent light produced a stable supply, but the large amount of infrared light
+emitted by the incandecent light bulb severely disturbed our near-infrared communication link.  As a consequence of
+this, we settled on a small LED light intended for use as a studio light that provdided us with almost flicker-free
+light at lower frequencies, leading to a sufficiently stable microcontroller VCC rail without any disturbance to the IR
+link.
+
+\subsection{Evaluation}
+
+After building our prototype inertial HSM according to the design decisions we outlined above, we performed a series of
+experiments to validate the critical components of the design.
+
+During these experiments, our prototype performed as intended. Both power and data transmission through the rotating
+joint were working reliably. Figure \ref{prototype_early_comms} shows our prototype performing reliably at maximum speed
+for the first time. Our improvised IR link is open in both directions for about $\SI{60}{\degree}$ of the rotation,
+which allows us to reliably transfer several tens of bytes in each direction during the receivers' fly-by even at high
+speed of rotation. As a result of our prototype experiments, we consider a larger-scale implementation of the inertial
+HSM concept practical.
+
+\begin{figure}
+    \center
+    \includegraphics[width=8cm]{prototype_early_comms_small.jpg}
+    \caption{The protoype when we first achieved reliable power transfer and bidirectional communication between stator
+    and rotor. In the picture, the prototype was communicating reliably up to the maximum $\approx\SI{1500}{rpm}$ that
+    we could get out of its hobby quadcopter parts.}
+    \label{prototype_early_comms}
+\end{figure}
+
+\section{Conclusion}
+
+\label{sec_conclusion} To conclude, in this paper we introduced inertial hardware security modules (iHSMs), a
+novel concept for the construction of highly secure hardware security modules from inexpensive, commonly available
+parts. We elaborated the engineering considerations underlying a practical implementation of this concept. We
+implemented a prototype demonstrating practical solutions to the significant engineering challenges of this concept. We
+analyzed the concept for its security properties and highlighted its ability to significantly strengthen otherwise weak
+tamper detection barriers.
+
+Inertial HSMs offer a high level of security beyond what traditional techniques can offer. They allow the construction
+of devices secure against a wide range of practical attacks at prototype quantities and without specialized tools. We
+hope that this simple construction will stimulate academic research into secure hardware.
+
+\printbibliography[heading=bibintoc]
+\appendix
+\subsection{Spinning mesh energy calculations}
+\label{sec_energy_calculations}
+Assume that the spinning mesh sensor should send its tamper status to the static monitoring circuit at least once every
+$T_\text{tx} = \SI{10}{\milli\second}$. At $\SI{100}{\kilo\baud}$ a transmission of a one-byte message in standard UART
+framing would take $\SI{100}{\micro\second}$ and yield an $\SI{1}{\percent}$ duty cycle. If we assume an optical or RF
+transmitter that requires $\SI{10}{\milli\ampere}$ of active current, this yields an average operating current of
+$\SI{100}{\micro\ampere}$. Reserving another $\SI{100}{\micro\ampere}$ for the monitoring circuit itself we arrive at an
+energy consumption of $\SI{1.7}{\ampere\hour\per\year}$.
+
+\subsubsection{Battery power}
+\label{sec_energy_calculations_battery}
+The annual energy consumption we calculated above is about equivalent to the capacity of a single CR123A
+lithium primary cell. Using several such cells or optimizing power consumption would thus easily yield several years of
+battery life.
+
+\subsubsection{LED and solar cell}
+\label{sec_energy_calculations_led}
+Let us assume an LED with a light output of $\SI{1}{W}$ illuminating a small solar cell. Let us pessimistically assume a
+$\SI{5}{\percent}$ conversion efficiency in the solar cell. Let us assume that when the rotor is at its optimal
+rotational angle, $\SI{20}{\percent}$ of the LED's light output couple into the solar cell. Let us assume that we loose
+another $\SI{90}{\percent}$ of light output on average during one rotation when the rotor is in motion. This results in
+an energy output from the solar cell of $\SI{1}{\milli\watt}$. Assuming a $\SI{3.3}{\volt}$ supply this yields
+$\SI{300}{\micro\ampere}$ for our monitoring circuit. This is enough even with some conversion losses in the step-up
+converter boosing the solar cell's $\SI{0.6}{\volt}$ working voltage to the monitoring circuit's supply voltage.
+
+\subsection{Minimum angular velocity: Rotating human attacker}
+\label{sec_minimum_angular_velocity}
+
+An attacker might try to rotate along with the HSM to attack the security mesh without triggering the accelerometer. Let
+us pessimistically assume that the attacker has the axis of rotation running through their center of mass. The
+attacker's body is probably at least $\SI{200}{\milli\meter}$ wide along its shortest axis, resulting in a minimum
+radius from axis of rotation to surface of about $\SI{100}{\milli\meter}$. We choose $\SI{250}{\meter\per\second^2}$ as
+an arbitrary acceleration well past the range tolerable by humans according to Wikipedia. Centrifugal acceleration is
+$a=\omega^2 r$. In our example this results in a minimum angular velocity of $\omega_\text{min} = \sqrt{\frac{a}{r}} =
+\sqrt{\frac{\SI{250}{\meter\per\second^2}}{\SI{100}{\milli\meter}}} \approx 8\cdot 2\pi\frac{1}{\si{\second}} \approx 500
+\text{rpm}$.
+
+\subsection{Fooling the accelerometer}
+\label{sec_degrees_of_freedom}
+
+Let us consider a general inertial HSM with one or more sensors that is attacked by an attacker. In this scenario, it is
+reasonable to assume that the rotating parts of the HSM are rigidly coupled to one another and will stay that way: For
+the attacker to decouple parts of the HSM (e.g. to remove one of its accelerometers from the PCB), the attacker would
+already have to circumvent the rotor's security mesh.
+
+Assuming the HSM is stationary, a sensor on the rotating part will experience two significant accelerations:
+\begin{enumerate}
+    \item Gravity $g = 9.8\frac{m}{s^2}$
+    \item Centrifugal force $a_C=\omega^2 r$, in the order of $\SI{1000}{\meter\per\second^2}$ or $100 g$ at
+        $r=\SI{100}{\milli\meter}$ and $\SI{1000}{rpm}$
+\end{enumerate}
+
+Due to the vast differences in both radius and angular velocity, we can neglegt any influence of the earth's rotation on
+our system.
+
+In normal operation, the HSM is stationary ($\mathbf v=0$) and the HSM's motor is tuned to exactly counter-balance
+friction so the rotor's angular velocity remains constant.  As a rigid body, the rotor's motion is fully defined by its
+rotation and translation. In total, this makes for six degrees of freedom. The three degrees of freedom of linear
+translation we can measure directly with an accelerometer in the stationary part on the inside of the HSM. This
+accelerometer could detect any rapid acceleration of the HSM's rotor. To measure rotation, we could mount a
+gyroscope on the rotor to detect deceleration. The issue with this is that like other MEMS acceleration sensors,
+commercial MEMS gyroscopes are vulnerable to drift and an attacker could slowly decelerate the rotor without being
+detected.
+
+A linear accelerometer mounted on the rotor however is able to catch even this attack. Subtracting gravity, it could
+determine both magnitude and direction of the centrifugal force, which is proportional to the square of angular velocity
+and not its derivative.
+
+In summary, a single three-axis accelerometer on the rotor combined with a three-axis accelerometer in the stator would
+be a good baseline configuration.
+
+\subsection{Patents and licensing}
+During development, we performed several hours of research on prior art for the inertial HSM concept. Yet, we could not
+find any mentions of similar concepts either in academic literature or in patents. Thus, we are likely the inventors of
+this idea and we are fairly sure it is not covered by any patents or other restrictions at this point in time.
+
+Since the concept is primarily attractive for small-scale production and since cheaper mass-production alternatives are
+already commercially available, we have decided against applying for a patent and we wish to make it available to the
+general public without any restrictions on its use. This paper itself is licensed CC-BY-SA (see below). As for the
+inertial HSM concept, we invite you to use it as you wish and to base your own work on our publications without any fees
+or commercial restrictions. Where possible, we ask you to cite this paper and attribute the inertial HSM concept to its
+authors.
+
+\center{
+    \center{\ccbysa}
+
+    \center{This work is licensed under a Creative-Commons ``Attribution-ShareAlike 4.0 International'' license. The
+    full text of the license can be found at:}
+
+    \center{\url{https://creativecommons.org/licenses/by-sa/4.0/}}
+
+    \center{For alternative licensing options, source files, questions or comments please contact the authors.}
+
+    \center{This is version \texttt{\input{version.tex}\unskip} generated on \today. The git repository can be found at:}
+
+    \center{\url{https://git.jaseg.de/rotohsm.git}}
+}
+\end{document}