ihsm/paper/ihsm_paper.tex

\documentclass[nohyperref]{iacrtrans}
\usepackage[T1]{fontenc}
\usepackage[
    backend=biber,
    style=numeric,
    natbib=true,
    url=false, 
    doi=true,
    eprint=false
    ]{biblatex}
\addbibresource{ihsm.bib}
\usepackage{amssymb,amsmath}
\usepackage{eurosym}
\usepackage{wasysym}
\usepackage{amsthm}
\usepackage{censor}

\makeatletter
\@ifclasswith{iacrtrans}{submission}{
    \newcommand{\censorIfSubmission}[1]{\censor{#1}{\scriptsize[Author information removed for double-blind peer review]}}
}{
    \newcommand{\censorIfSubmission}[1]{#1}
}
\makeatother

\usepackage[binary-units]{siunitx}
\DeclareSIUnit{\baud}{Bd}
\DeclareSIUnit{\year}{a}
\usepackage{commath}
\usepackage{graphicx,color}
\usepackage{subcaption}
\usepackage{array}
\usepackage{hyperref}
\usepackage{xcolor}

\renewcommand{\floatpagefraction}{.8}
\newcommand{\degree}{\ensuremath{^\circ}}
\newcolumntype{P}[1]{>{\centering\arraybackslash}p{#1}}
\newcommand{\partnum}[1]{\texttt{#1}}

\begin{document}

\title[Can't Touch This: Inertial HSMs Thwart Advanced Physical Attacks]{Can't Touch This: Inertial HSMs Thwart Advanced Physical Attacks}
\author{Jan Sebastian Götte\and Björn Scheuermann}
\institute{HIIG\\ \email{ihsm@hiig.jaseg.de} \and HIIG\\ \email{bjoern.scheuermann@hiig.de}}
% FIXME keywords
\keywords{hardware security \and implementation \and smart cards \and electronic commerce}
\maketitle

\begin{abstract}
    In this paper, we introduce a novel countermeasure against physical attacks: Inertial Hardware Security Modules
    (IHSMs).  Conventional systems have in common that their security requires the crafting of fine sensor structures
    that respond to 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 an 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. We have built a proof-of-concept hardware
    prototype that demonstrates solutions to the concept's main engineering challenges. As part of this
    proof-of-concept, we have found that a system using a coarse security mesh made from commercial printed circuit
    boards and an automotive high-g-force accelerometer already provides a useful level of security.
\end{abstract}

\section{Introduction}

While information security technology has matured a great deal in the last half-century, physical security did not keep
up with the pace of the remainder of this industry. Given the right skills, physical access to a computer still often
allows 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}.

In contrast to TPMs and Smartcards, HSMs rely on an active security barrier usually consisting of a fragile foil with
conductive traces. These traces are much larger scale than a smart card IC's microscopic structures and instead are
designed to be very 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, this modified 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's monitoring circuit---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 Section~\ref{sec_swivel_chair_attack}). 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 paper 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 tamper sensors for inertial HSMs.
    \item We explore the design space of our inertial HSM concept.
    \item We present our work on a prototype inertial HSM (Figure~\ref{prototype_picture}).
    \item We present an analysis of the viability of using commodity MEMS accelerometers as braking sensors.
    % FIXME \item Measurement of the prototype HSM's susceptibility to various types of attack.
\end{enumerate}

\begin{figure}
    \center
    \includegraphics[width=12cm]{prototype_pic2.jpg}
    \caption{The prototype as we used it to test power transfer and bidirectional communication between stator and
    rotor.  This picture shows the proof-of-concept prototype's configuration that we used for accelerometer
    characterization (Section~\ref{sec_accel_meas}) without the vertical security mesh struts that connect the circular
    top and bottom outer meshes.}
    \label{prototype_picture}
\end{figure}

In Section~\ref{sec_related_work}, we will give an overview of the state of the art in HSM physical security. 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 proof-of-concept hardware
prototype.In Section~\ref{sec_proto} we will elaborate the design of this prototype. In Section~\ref{sec_accel_meas} we
present our characterization of an automotive MEMS accelerometer IC as a rotation sensor in this proof-of-concept
prototype. 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 that traces back decades in its electronic realization, initially being conceived by the US
NSA during the second world war~\cite{boak1973}. 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 interior using e.g.\ electromagnetic radiation~\cite{tobisch2020, kreft2012} or
ultrasound~\cite{vrijaldenhoven2004} but none of this research has found widespread adoption yet.

HSMs can be compared to physical seals~\cite{anderson2020}. Both are tamper-evident devices. The difference is that an
HSM continuously monitors itself whereas a physical seal only serves to record tampering and requires someone to examine
it. This examination can be done by eye in the field, but it can also be carried out in a laboratory using complex
equipment.  An HSM in principle has to have this examination equipment built-in.

Physical seals are used in a wide variety of applications. The most interesting ones from a research point of view that
are recorded in public literature are those used for monitoring of nuclear material under the International Atomic
Energy Authority (IAEA). Most of these seals use the same approach that is used in Physically Unclonable Functions
(PUFs), though their development predates that of PUFs by several decades.  The seal is created in a way that
intentionally causes large, random device-to-device variations. These variations are precisely recorded at deployment.
At the end of the seal's lifetime, the seal is returned to a lab and closely examined to check for any deviations from
the seal's prior recorded state. The type of variation used in these seals includes random scratches in metal parts and
random blobs of solder (IAEA metal cap seal), randomly cut optical fibers (COBRA seal), the uncontrollably random
distribution of glitter particles in a polymer matrix (COBRA seal prototypes) as well as the precise three-dimensional
surface structure of metal parts at microscopic scales (LMCV)~\cite{iaea2011}.

The IAEA's equipment portfolio does include electronic seals such as the EOSS. These devices are intended for remote
reading, similar to an HSM. They are constructed from two components: A cable that is surveilled for tampering, and a
monitoring device. The monitoring device itself is in effect an HSM and uses a security mesh foil like it is used in
commercial HSMs. 

The self-destruct built into an HSM serves as a strong tamper deterrent.  For illustration, compare an HSM to a computer
inside a locked safe when opposing a well-funded attacker with plenty of time.  In~\cite{boak1973}, Boak asserts that
absent an HSM's capability to self-destruct, the best safes can only withstand brute force attacks by an expert for
several minutes. While the state of electronics has advanced rapidly since Boak's 1973 lecture, the hardness of steel
has not increased correspondingly. Thus, we can conclude that even today, against a ``smart, well-equipped opponent with
plenty of time'' as noted by Boak, this self-destruction functionality is essential.

In~\cite{anderson2020}, Anderson gives a comprehensive overview of physical security. An example HSM that he cites is
the IBM 4758, the details of which are laid out in-depth in~\cite{smith1998}. This HSM is an example of an
industry-standard construction. Although 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. Besides some auxiliary temperature
and radiation sensors to guard against attacks on the built-in SRAM memory, the module's main security barrier uses the
common construction of a flexible mesh foil wrapped around the module's core. In~\cite{smith1998}, the authors state
that the module monitors this mesh for short circuits, open circuits, and conductivity. Other commercial offerings use
similar approaches to tamper detection~\cite{obermaier2018,drimer2008,anderson2020,isaacs2013}.

Shifting our focus from industry use to the academic state of the art, in~\cite{immler2019}, Immler et al. describe an
HSM based on precise capacitance measurements of a security mesh, creating a PUF from the mesh. In contrast to
traditional meshes, they use a large number of individual traces.  Their concept promises a very high degree of
protection, but is limited in area covered 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 on
a WiFi transceiver inside a conductive enclosure. In their design, a reference signal is sent 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
phase and frequency response of the RF cavity. The assumption underlying their system is that the RF behavior of the
cavity is inscrutable from the outside, and that any small disturbances within the volume of the cavity will cause a
significant change in its RF response. A core component of the work of Tobisch et al.~\cite{tobisch2020} is that they
use commodity WiFi hardware, so the resulting system is likely both much cheaper and capable of protecting a much larger
security envelope than designs using finely patterned foil security meshes such as~\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 traveling on a surface acoustic wave (SAW) device to a similar end.

While Tobisch et al.~\cite{tobisch2020}\ approach the sensing frontend cost as their primary 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.

To the best of our knowledge, we are the first to propose a mechanically moving 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 certify and cheaply manufacture 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 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 a
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}

Fast 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.

The core questions in the design of an inertial HSM are the following:

\begin{enumerate}
    \item What \textbf{type of motion} to use, such as rotation, pendulum motion, or linear motion.
    \item How to construct the \textbf{tamper detection sensor}.
    \item How to \textbf{detect braking} of the IHSM's movement.
    \item The \textbf{mechanical layout} of the system.
\end{enumerate}

We will approach these questions one by one in the following subsections and conclude this section with an exploration
of the practical implications that these aspects of IHSM construction have on IHSM operation, but first we will motivate
our concept with two use cases and outline our attacker model.

\subsection{Use Cases and Attacker Model}

The target application of an IHSM is high-risk data processing. This risk can be implied by either high-value data, or
by difficult physical security constraints.  Our goal with IHSMs is to eventually arrive at a system that, at low-cost,
can persist against a smart, well-funded adversary such as a secret service or organized cyber-crime.

Consider a group of healthcare providers intending to analyze a large database of patient health information.
Accumulating potentially millions of sensitive medical records on a single system for such processing poses an inherent
risk as this system becomes a valuable target for organized cyber-criminals looking for ransom.  IHSMs allow for a level
of physical security against e.g.\ a bribed insider that is as good as the level of network security afforded by modern
firewalls and cryptographic protocols.

On the other end of the spectrum, consider a real-time group video communication provider. Relaying and transcoding
video data between participants is hard to solve without trusting the server, but at the same time latency requires that
the server is physically located close to its users. Given the global history of privacy-invasive cyber-attacks by
secret services and other well-funded attackers, this may pose an issue. In this scenario, IHSMs allow for the secure
deployment of trusted server components closer to the user, or even at the network edge, where physical security is
challenging.

\subsection{Inertial HSM motion}
\label{sec_ihsm_motion}

First, there are several ways how we can approach motion. Periodic, aperiodic and continuous motion could serve the
purpose. There is also linear motion as well as rotation. We can also vary the degree of electronic control in this
motion. The main constraint on the HSM's motion pattern is that it needs to be (almost) continuous to not expose any
weak spots during instantaneous standstill of the HSM. Additionally, it has to stay within a confined space. For space
efficiency, linear motion would have to be periodic, like that of a pendulum. Such periodic linear motion will have to
quickly reverse direction at its apex so the device is not stationary long enough for this to become a weak spot.

In contrast to linear motion, rotation is space-efficient and can be continuous if the axis of rotation is inside the
device. When the axis is fixed, rotation will expose a weak spot close to the axis where tangential velocity is low.
Faster rotation can lessen the security impact of this fact at the expense of power consumption and mechanical stress,
but it can never elimitate it. More effective mitigations are additional tamper protection at the axis, and having the
HSM perform a compound rotation that has no fixed axis.

High speed gives rise to large centrifugal acceleration, which poses the engineering challenge of preventing rapid
unscheduled disassembly of the device, but it also creates an obstacle to any attacker trying to manipulate the device
in what we call a \emph{swivel chair attack} (see Section~\ref{sec_swivel_chair_attack}). An attacker trying to follow
the motion would have to rotate around the same axis. By choosing a suitable angular frequency we can prevent an
attacker from following the device's motion since doing so would subject them to impractically large centrifugal forces.
Essentially, this limits the approximate maximum size and mass of an attacker under an assumption on tolerable
centrifugal force.

In this paper, we focus on rotating IHSMs for simplicity of construction. For our initial research, we focus on systems
with a fixed axis of rotation due to their simple construction but we do wish to note the challenge of hardening the
shaft against tampering that any production device would have to tackle.

\subsection{Tamper detection mesh construction}

IHSMs do not eliminate the need for a security barrier. To prevent an attacker from physically destroying the moving
part, tamper detection such as a mesh is still necessary. In this subsection we will consider ways to realize this
security barrier.  In industry, mesh membranes are commonly used for tamper detection. Such membranes are deployed in
systems for a variety of use cases ranging from low-security payment processing to high-security certificate management.
From this we can conclude that a properly implemented mesh \emph{can} provide a practical level of security.  In
contrast to this industry focus, academic research has largely focused on ways to fabricate enclosures that embed
characteristics of a Physically Unclonable Function as a means of tamper detection~\cite{tobisch2020,immler2019}. By
using stochastic properties of the enclosure material to form a PUF, such academic designs leverage signal processing
techniques to improve the system's security level by a significant margin.

In our research, we focus on security meshes as our IHSM's tamper sensors.  The cost of advanced manufacturing
techniques and special materials used in fine commercial meshes poses an obstacle to small-scale manufacturing and
academic research.  The foundation of an IHSM security is that by moving the mesh, even a primitive, coarse mesh such as
one made from a low-cost PCB becomes very hard to attack in practice.  This allows us to use a simple construction made
up from low-cost components. Additionally, the use of a mesh allows us to only spin the mesh itself and its monitoring
circuit and keep the payload inside the mesh stationary for reduced design complexity.  Tamper sensing systems such as
RF fingerprinting that monitor the entire volume of the HSM instead of only a thin boundary layer would not allow for
this degree of freedom in an IHSM. They would instead require the entire IHSM to spin including its payload, which would
entail costly and complex systems for data and power transfer from the outside to the spinning payload.

\subsection{Braking detection}

The security mesh is a critical component in the IHSM's defense against physical attacks, but its monitoring is only one
half of this defense. The other half consists of a reliable and sensitive braking detection system. This system must be
able to quickly detect any slowdown of the IHSM's rotation. Ideally, a sufficiently sensitive sensor is able to measure
any external force applied to the IHSM's rotor and should already trigger a response at the first signs of a
manipulation attempt.

While the obvious choice to monitor rotation would be a magnetic or optical tachometer sensor attached to the IHSM's
shaft, this would be a poor choice for our purposes since optical and magnetic sensors are susceptible to contact-less
interference from outside. We could use feedback from the motor driver electronics to determine the speed. When using a
BLDC motor, the driver electronics precisely know the rotor's position at all times. However, this apporach might allow
for attacks at the mechanical interface between the mesh and the motor's shaft.  If an attacker can decouple the mesh
from the  motor e.g.\ by drilling, laser ablation or electrical discharge machining (EDM) on the motor's shaft, the
motor could keep spinning at its nominal frequency while the mesh is already standing still.

Instead of a stator-side sensor, a rotor-side inertial sensor such as an accelerometer or gyroscope placed inside the
spinning mesh monitoring circuit would be a good component to serve as an IHSM's tamper sensor. A gyroscope would need
to be placed close to the IHSM's shaft where centrifugal force is low, and would directly measure changes in angular
velocity. An accelerometer could be placed anywhere on the rotor and would measure centrifugal acceleration.

Modern, fully integrated MEMS accelerometers are very precise. By comparing acceleration measurements against a model of
the device's mechanical motion, deviations can quickly be detected. This limits an attacker's ability to tamper with the
device's motion. It may also allow remote monitoring of wear of the device's mechanical components such as bearings:
MEMS accelerometers are fast enough to capture vibrations, which can be used as an early warning sign of failing
mechanical components~\cite{kvk2019,sh2016,adc2019,e2013}.

In a spinning IHSM, an accelerometer mounted at a known radius with its axis pointing radially will measure centrifugal
acceleration. Centrifugal acceleration rises linearly with radius, and with the square of frequency: $a=\omega^2 r$. For
a given accelerometer and target speed of rotation, the accelerometer's location should be chosen to maximize dynamic
range. A key point here is that for speeds between $500$ and $\SI{1000}{rpm}$, centrifugal acceleration already becomes
very large at a radius of just a few $\si{\centi\meter}$. At $\SI{1000}{rpm}\approx\SI{17}{\hertz}$ and at a
$\SI{10}{\centi\meter}$ radius, centrifugal acceleration already is above $\SI{1000}{\meter\per\second}$ or $100\,g$.
Due to this large acceleration, off-axis performance of the accelerometer has to be considered. Suitable high-$g$
accelerometers for the large accelerations found on the circumference of an IHSM's rotor are mostly used in automotive
applications.

To evaluate the feasibility of accelerometers as tamper sensors we can use a simple benchmark. Let us assume an IHSM
spinning at $\SI{1000}{rpm}$. To detect any attempt to brake it below $\SI{500}{rpm}$, we have to detect a difference in
acceleration of a factor of $\frac{\omega_2^2}{\omega_1^2}=4$. Even without maximizing the accelerometer's dynamic range
through optimal placement, any commercial MEMS accelerometer will suffice. Only to detect slow deceleration, the
sensor's drift characteristics may have to be taken into account.

In Section~\ref{sec_accel_meas} below, we conduct an empirical evaluation of a commercial automotive high-$g$ MEMS
accelerometer for braking detection in our prototype IHSM.

\subsection{Mechanical layout}

With our IHSM's components taken care of, what remains to be decided is how to put together these individual components
into a complete device.  A basic spinning HSM might look as shown in Figure~\ref{fig_schema_one_axis}. Visible are the
axis of rotation, an accelerometer on the rotating part that is used to detect braking, the protected payload, and the
area covered by the rotating tamper detection mesh.  Note that we only have to move the tamper protection mesh, not the
entire contents of the HSM, keeping most of the HSM's mass stationary.  This reduces the moment of inertia of the
rotating part.  It also eliminates the need for rotating data and power connections to the payload, which can be
supplied through a hollow shaft instead. In our proof-of-concept prototype, we accept a weak spot at the point where the
shaft penetrates the mesh to simplify mechanical construction.

\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}

The spinning mesh must be designed to cover the entire surface of the payload, but 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.
Using longitudinal gaps in the mesh, our setup allows direct air cooling of regular heatsinks. This unlocks much more
powerful processing capabilities that greatly increase the maximum possible power dissipation of the payload.  In an
evolution of our design, the spinning mesh could even be designed to \emph{be} a cooling fan.

Conventional HSMs are limited by the construction of their security meshes which rely on plastics as their main
structural material. The security mesh has to fit the highest components inside the HSM. Since creating a security mesh
with a non-flat surface is difficult, this means there is an inevitable gap of a few millimeters between the surface of
the payload CPU and the interior surface of the mesh. This distance is added to several millimeters of epoxy resin that
the mesh must be embedded inside for it to be hard to remove intact. Overall, this leads to a structure approximately a
centimeter thick that includes several millimeters of epoxy resin with particularly poor thermal
conductivity~\cite{obermaier2019}.  Even if ``thermally conductive'' resins would be used, thermal conductivity is
limited to a fraction of what can be achieved with a heatsink directly attached to the CPU. A modern high-end CPU
heatsink with its fan running has a thermal resistance from CPU junction to air of around
$\SI{0.1}{\kelvin\per\watt}$~\cite{anandtech2015}.
If one were to make an HSM's security mesh out of an average thermally conductive epoxy with thermal conductivity
$k\approx\SI{1}{\watt\per\meter\kelvin}$~\cite{kordyban1998,shabany2009,mgchemicals2017}, the resulting thermal
resistance for a 5-by-5 centimeter, $\SI{5}{\milli\meter}$ thermal interface alone would be $\SI{2}{\kelvin\per\watt}$,
a more than 10-fold increase. For an acceptable temperature delta from junction to air of $\SI{60}{\kelvin}$ this yields
a maximum power dissipation of only $\SI{30}{\watt}$ compared to a theoretical $\SI{600}{\watt}$ for a conventional CPU
cooler.  Given that for modern high core-count CPUs both multithreaded performance and power dissipation are mostly
linear in core count, this severely limits the achievable performance.

This estimated performance discrepancy matches up with our observation. Thales, a manufacturer of conventional HSMs
reports $\SI{20}{\kilo Ops\per\second}$ ECC signature operations on NIST Curve P-256 on one of their top-of-range
``Luna HSM 790''~\cite{thales2021}, which compares to be slightly more than half of the $\SI{36}{\kilo Ops\per\second}$
signing operations that \texttt{openssl speed} in single-thread mode is able to do on an AMD Ryzen 7 PRO 4750U laptop
CPU using $\SI{2.0}{\watt}$ of power on the active core. Using today's technology, we expect a performance jump of one
to two orders of magnitude in computing power to be feasible in an IHSM compared to a conventional HSM.

\subsection{Long-term Operation}

Without settling on a particular design for an IHSM yet, from the previous sections we have already gained an
understanding of what an IHSM would look like in practice. In the following paragraphs, we will draw some conclusions on
how its design will affect the day-to-day operation of an IHSM.
Like other HSMs, in a practical application, an IHSM may have to run continuously for a decade or even longer. As with
any networked system, a setup including IHSMs must be designed in a way that prevents the failure of one or several
IHSMs on the network from compromising the whole system's security or reliability. Neither IHSMs nor traditional HSMs
can withstand fire or flooding, so while a breach of security can be ruled out, a catastrophic failure of the device and
erasure of data cannot~\cite{heise2021ovh}. Traditionally, this problem is solved by storing all secrets in multiple,
geographically redundant HSMs~\cite{thales2015hsmha}. On IHSMs this task is aided on the software layer since they are
based on general-purpose computer hardware and allow for state-of-the-art database replication techniques to be applied
without first porting them to an embedded operating system or foreign CPU architecture. A practical example of this
approach is a 2019 technology demonstration~\cite{signal2019} created by signal.org, the organization running the signal
secure messenger app. In this demonstration, signal.org have implemented the Raft consensus algorithm~\cite{ongaro2019}
inside Intel SGX to replicate state between geographically redundant enclaves.

Finely-grained monitoring of operational parameters may be capable of recognizing some types of failure such as backup
battery failure, mechanical wear or over/undertemperature conditions some time before alarm levels have been reached and
all secrets must be detstroyed. This type of early warning allows for the implementation of a graceful failover
mechanism. Similar to hot spares in hard disk arrays, a number of IHSMs might share a hot spare IHSM that is running,
but that does not yet contain any secrets. Once an IHSM detects early warning signs of an impending failure, it can then
transfer its secrets to the hot spare using replicatoin technologies as mentioned in the previous paragraph, then delete
its local copies.  This would allow for the graceful handling of device failures due to both age and disasters such as
fires.

Excluding natural disasters, there are three main categories of challenges to an IHSM's longevity: Failure of components
of the IHSM due to age and wear, failure of the external power supply, and spurious triggering of the intrusion alarm by
changes in the IHSM's environment. In the following paragraphs, we will evaluate each of these categories in its
practical impact.

\paragraph{Component failure.}
The failure mode of an IHSM's components is the same as in any other computer system and the same generic mitigation
techniques apply. The expected lifetime of electronic components can be increased by using higher-spec components and by
reducing thermal, mechanical, and electrical stress. To reduce vibration stress on both rotor and stator, the rotor must
be balanced. The main mechanical failure mode of an IHSM's is likely to be failure of the shaft bearings. By
incorporating knowledge from other rotating devices that have a long lifetime such as cooling fans, this failure mode
can be mitigated. Another noteworthy mechanical failure mode of an IHSM is dust buildup on the optical components of the
communication link. This failure mode can be mitigated by routing cooling airflow such that it does not go past the
communication link's optical components, as well as by filtering cooling air at the device's intakes.

\paragraph{Power failure.}
\label{sec-power-failure}
After engineering an IHSM's components to survive years of continuous operation, the next major failure mode to be
considered is power loss. Traditional HSMs solve the need for an always-on backup power supply by carrying large backup
batteries~\cite{obermaier2019}. The low static power consumption of a traditional HSM's simple tamper detection
circuitry allows for the use of non-replaceable backup batteries. An IHSM in contrast would likely require a
rechargeable backup battery since its motor requires more power than the mesh monitoring circuit of a traditional HSM.
In principle, a conventional Uninterruptible Power Supply (UPS) can be used, but in practice, a productized IHSM might
have a smaller battery integrated. Conservatively assuming an average operating power consumption of $\SI{10}{\watt}$
for an IHSM's motor, a single large laptop battery with a capacity of $\SI{100}{\watt\hour}$~\cite{faa2018} could
already power an IHSM for 10 hours continuously. $\SI{10}{\watt}$ is a reasonable high estimate given that there are
large industrial fans rated at lower wattages, e.g. Sunon \partnum{CF2207LBL-000U-HB9}, a $\SI{250}{\milli\meter}$
diameter $\SI{7.8}{\meter^3\per\minute}$ axial fan rated at $\SI{6.6}{\watt}$.  If a built-in battery is undesirable or
if power outages of more than a few seconds are unlikely (e.g.\ because of an external UPS), the IHSM's rotor itself can
be used as a flywheel for energy storage.

\paragraph{Spurious alarms due to vibration.}


Even with all components working to their specification, an IHSM could still catastrophically fail if for some reason
its alarm would be spuriously activated due to movement of the device.  The likelihood  of such an alarm failure must be
minimized, e.g.\ by employing vibration damping.  There are several possible causes why an IHSM might move during normal
operation. The IHSM may have to be relocated between datacenters, or a worker may bump the IHSM.  Additionally, the
effect of normal mechanical vibration on the IHSM's tamper sensors has to be considered. During normal operation,
vibration from outside sources such as backup generators and nearby traffic (e.g.  trains) may couple into the IHSM
through the building.  Since IHSMs are rotating machines they will themselves cause some amount of vibration and thus
vibration isolation is a reasonable design requirement.  Besides everyday sources of mechanical noise, (usually
harmless) earthquakes are a common occurrence in some regions of the world and will couple through any reasonable amount
of vibration damping.

None of these sources of mechanical noise are likely to cause a false alarm.  For reference, consider an IHSM running at
an angular velocity of $\SI{1000}{rpm}$. A tamper sensor mounted at a radius of $\SI{100}{\milli\meter}$ will measure a
constant centrifugal acceleration of approximately $100\,g$.  Literature on car crashes shows that accelerations above
$10\,g$ in the car's structural components correspond to a crash at $\SI{30}{\kilo\meter\per\hour}$ and
above~\cite{ika2002,german2007}.  Measurements of the Peak Ground Acceleration (PGA) of severe earthquakes show that
even the strongest earthquakes rarely reach a PGA of $\SI{0.1}{g}$~\cite{yoshimitsu1990} with the 2011 Tohoku earthquake
at approximately $\SI{0.3}{g}$.

Instantaneous acceleration increases linearly with frequency, but likewise simple vibration dampers work better with
higher frequencies~\cite{kelly1993,beards1996,dixon2007}, To reduce the likelihood of false detections, it is enough to
damp high-frequency shock and vibration, as low-frequency shock or vibration components will not reach accelerations
large enough to cause a false alarm. For instance, an earthquake's low-frequency vibrations dissipate a tremendous
amount of mechanical power across a large geographic area, but due to the their low absolute instantaneous acceleration,
we can ignore them for the purposes of our tamper detection system.  An IHSM's tamper detection subsystem will be able
to clearly distinguish attempts to stop the IHSM's rotation from normal environmental noise by their magnitude. Any
external acceleration that would come close in order of magnitude to the operating centrifugal acceleration at the
periphery of an IHSM's rotor would likely destroy the IHSM.

\subsection{Transportation}

While unintentional acceleration is unlikely to cause false alarms in an IHSM when simple vibration damping is employed,
there is an issue when intentionally moving an IHSM: The IHSM's rotor stores significant rotational energy and will
respond to tipping with a precession force. This could become an issue when a larger IHSM is transported between e.g.\
the manufacturer's premises and its destination data center.  The simple solution to this problem is to transport the
IHSM elastically mounted with its axis pointing upwards inside a shipping box that is weighted to resist precession
forces.

During shipping, the IHSM will require a continuous power supply. Following our conservative estimate in
Section~\ref{sec-power-failure}, 48-hour courier shipping could easily be bridged with the equivalent of 5-10 laptop
batteries. In applications that do not require a backup battery built-in to the IHSM (e.g. due to existing UPS backup),
the IHSM could be shipped connected to an external battery akin to a ``power bank'' that is sent back to the IHSM's
manufacturer after the IHSM has been installed. Long-distance shipping can be facilitated through compatibility with
standards used for powered refrigerated shipping containers.

\section{Attacks}
\label{sec_attacks}

After outlining the basic mechanical design of an inertial HSM as well as the fundamentals of its long-term operation
above, in this section, we will detail possible ways to attack it. At the core of an IHSM's defenses is the same
security mesh or other technology as it is used in traditional HSMs. This means that ultimately an attacker will have to
perform the same steps they would have to perform to attack a traditional HSM.  However, they will either need to
perform these attack steps with a tool such as a CNC actuator or a laser that follows the HSM's rotation at high speed,
or they will first need to defeat the braking sensor.

\subsection{Attacks that don't work}

In the sections below, we will go into detail on such attacks on IHSMs. To put these attack approaches into perspective,
we will start with a brief overview of attacks on conventional HSMs that the IHSM is defended against.

In principle, there are three ways to attack a conventional HSM. The hard way is to go through the security mesh without
triggering the alarm, e.g.\ with a probe that is finer than the mesh's spacing. For larger probes, an attacker can
laboriously uncover, then bridge the mesh traces to allow part of the mesh to be removed. Some HSMs attempt to detect
such attacks by measuring mesh resistance~\cite{obermaier2019}, but this is limited by available measurement precision.
If an attacker only wishes to disable a small section of the mesh to insert a handful of fine probes into the device,
this hardening approach becomes challenging. Consider a mesh that covers an area of $\SI{100}{\milli\meter}$ by
$\SI{100}{\milli\meter}$. An attacker who short-circuits a $\SI{5}{\milli\meter}$ by $\SI{5}{\milli\meter}$ section of
this mesh will change the mesh trace's resistance by approximately
$\frac{\SI{5}{\milli\meter}\cdot\SI{5}{\milli\meter}}{\SI{100}{\milli\meter}\cdot\SI{100}{\milli\meter}} = 0.25 \%$.
Detecting this change would require a resistance measurement of at least $\SI{9}{bit}$ of precision and corresponding
temperature stability of the mesh material.

The second way to attack an HSM is to go \emph{around} the mesh. Many commercial HSMs sandwich the payload PCB between
two halves of an enclosure~\cite{obermaier2019}. This design is vulnerable to attempts to stick a fine needle through
the interface between lid and PCB~\cite{dexter2015}. Conventional HSMs mitigate this weak spot by wrapping a patterned
conductive foil around the HSM that forms the security mesh, leaving only the corners and the payload's power and data
feed-through as potential weak spots.

The third and last way to attack a conventional HSM is to disable the mesh monitoring circuit~\cite{dexter2015}. An
attacker may need to insert several probes to wiretap the payload processor's secrets, but if poorly implemented, they
may be able to disable the mesh monitor with only one. This type of attack can be mitigated by careful electronic
design.

\subsection{Attacks that work on any HSM}

An IHSM provides an effective mitigation against direct attacks on the security mesh as described in the previous
paragraphs. However, there are certain generic attacks that work against any HSM technology, conventional or IHSM.
One type of such attacks are contactless attacks such as electromagnetic (EM) sidechannel attacks.
EM sidechannel attacks can be mitigated by shielding and by designing the IHSM's payload such that critical components
such as CPUs are physically distant to the security mesh, preventing EM probes from being brought close.
Conducted EMI sidechannels that could be used for power analysis can be mitigated by placing filters on the inside of
the security mesh at the point where the power and network connections penetrate the mesh~\cite{anderson2020}.
Finally, the API between the HSM's payload and the outside world provides attack surface.  Attacks through the network
interface must be prevented as in any other networked system by only exposing the minimum necessary amount of API
surface to the outside world, and by carefully vetting this remaining attack surface~\cite{anderson2020}.

IHSMs do not provide an inherent benefit against such contactless attacks. However, there are two mitigating factors in
play that still give IHSMs an advantage over conventional HSMs in this scenario. Because IHSM meshes can be made using
simpler technology than conventional HSM meshes at the same level of security, IHSMs can use larger meshes and are less
space-constrained. This larger volume allows for a greater physical distance between security-critical components and
places accessible to an attacker using an electromagnetic probe for EM sidechannel attacks.

Another attack that is possible against all types of HSMs are software attacks. Flaws in an HSM's software such as
memory safety errors in its external-facing APIs can lead to a full compromise of the HSM's secrets~\cite{ledger2019}.
Like a traditional HSM, an IHSM has to expose some API to the outside world to be useful. For both, the hardening
techniques are the same as in any other networked system and include the reduction of attack surface e.g. through
firewalling, fuzz testing and formal verification. In IHSMs these mitigations are easier to implement since they allow
the use of conventional server hardware and well-audited open source software, instead of hard-to-audit proprietary code
on an embedded platform.

\subsection{The Swivel Chair Attack}
\label{sec_swivel_chair_attack}

If we assume whoever integrates the payload into an IHSM has done adequate work and prevented all contactless attacks,
we are left with attacks that aim at mechanically bypassing the IHSM's security mesh. The first type of attack we will
consider is the most basic of all attacks: a human attacker holding a soldering iron trying to rotate herself along with
the mesh using a very fast swivel chair.  Let us pessimistically assume that this co-rotating attacker has their center
of mass on the axis of rotation. The attacker's body is likely on the order of $\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}$.
Wikipedia lists horizontal g forces in the order of $\SI{20}{g}$ as the upper end of the range tolerable by humans for a
duration of seconds or above. We thus set our target acceleration to
$\SI{100}{g}\;\approx\;\SI{1000}{\meter\per\second^2}$, a safety factor of $5$ past that range.  Centrifugal
acceleration is $a=\omega^2 r$. In our example, this results in a minimum angular velocity of $f_\text{min} =
\frac{1}{2\pi}\sqrt{\frac{a}{r}} = \frac{1}{2\pi}\sqrt{\frac{\SI{1000}{\meter\per\second^2}}{\SI{100}{\milli\meter}}}
\approx \SI{16}{\hertz} \approx \SI{1000}{rpm}$. From this, we can conclude that even at moderate speeds of
$\SI{1000}{rpm}$ and above, a manual attack is no longer possible and any attack would have to be carried out using some
kind of mechanical tool.

\begin{figure}
    \center
    \includegraphics[width=6cm]{attack-robot.pdf}
    \caption{Schematic overview of a robotic rotating-stage attack. An optical sensor (1) observes the IHSM's rotation
    and adjusts the setpoint of a servo motor (2) that rotates the attack stage (3). On the rotating attack stage, a
    remote-controlled manipulator (4) is mounted that deactivates the security mesh (7) and creates an opening (5).
    Through this opening, a human operator can then insert tools such as probes to read out sensitive information from
    the actual payload (6).}
    \label{fig_attack_robot}
\end{figure}

Figure~\ref{fig_attack_robot} shows a schematic overview of the structure of such a rotating attack tool.  The tool
itself has to rotate at the IHSM's speed because counter-rotating the IHSM instead, the accelerometer on the rotor would
measure lower centrifugal acceleration and detect the manipulation attempt.  Following the IHSM's rotation closely
enough to allow for remote-controlled manipulation of the IHSM is hard. Let us assume a small IHSM mesh with radius
$r=\SI{100}{\milli\meter}$.  To keep a manipulator stationary within a $\SI{5}{\milli\meter}$ by $\SI{5}{\milli\meter}$
window over a period of $\SI{10}{\second}$ requires attack tool and IHSM speeds to be matched to an accuracy better than
$\frac{\SI{5}{\milli\meter}}{\SI{10}{\second}} \cdot \frac{1}{2\pi r} = \SI{8.0}{\milli\hertz} = \SI{0.048}{rpm}$.
Relative to a realistic IHSM's speed of $\SI{1000}{rpm}$ this corresponds to approximately $\SI{50}{ppm}$.  Achieving
this accuracy would likely require active servo control of the attack tool's rotation that is locked, e.g.\ optically,
to the IHSM's rotor.

If an attacker were to solve the tracking issue, the remaining issue is that they still need to construct a
remote-controlled manipulator that is able to disable the IHSM's mesh. This manipulator would have to be tolerant to
high g forces so that it can be mounted on the attack tool's rotating stage.  Drilling only a small hole is not enough
in this case since, while the mesh is moving, the payload is stationary.  Instead, using the rotating manipulator, the
attacker has to create an opening in the mesh large enough to place a \emph{stationary} probe on the payload.  We
estimate that creating a rotating, remote-controllable manipulator that can be used to successfully attack a security
mesh is infeasible given the degree of manual skill necessary even for normal soldering work.

\subsection{Mechanical weak spots}

As we elaborated in the previous paragraphs, we consider a fast-moving mesh to offer a strong tamper detection
capability based on the assumption that the mesh is moving too fast to tamper. However, depending on the type of motion
used, the mesh's actual speed may vary by location and over time.  Our example configuration of a rotating mesh moves
continuously and does not have any time-dependent weak spots. It does, however, have a weak spot where the shaft
penetrates the mesh at the axis. The mesh's tangential velocity decreases close to the shaft, and the shaft itself may
allow an attacker to insert tools such as probes into the device through the opening it creates.  Conventional HSMs also
have to take precautions to protect their power and data connections. In conventional HSMs, power and data are routed
into the enclosure along a meandering path through the PCB or through flat flex cables sandwiched in between security
mesh foil layers~\cite{smith1998}.  As a result of these precautions, in conventional HSMs this interface rarely is a
mechanical weak spot. In inertial HSMs, careful engineering is necessary to achieve the same effect.
Figure~\ref{shaft_cm} shows variations of the shaft interface with increasing complexity.

\begin{figure}
    \begin{subfigure}[t]{0.3\textwidth}
        \center
        \includegraphics[width=4cm]{ihsm_shaft_countermeasures_a.pdf}
        \caption{Cross-sectional view of the basic configuration with no special protection of the shaft. Red: moving
        mesh -- Black: stationary part.}
        \label{shaft_cm_a}
    \end{subfigure}
    \hfill
    \begin{subfigure}[t]{0.3\textwidth}
        \center
        \includegraphics[width=4cm]{ihsm_shaft_countermeasures_b.pdf}
        \caption{An internal, independently rotating disc greatly decreases the space available to attackers at the
        expense of another moving part and a second moving monitoring circuit.}
        \label{shaft_cm_a}
    \end{subfigure}
    \hfill
    \begin{subfigure}[t]{0.3\textwidth}
        \center
        \includegraphics[width=4cm]{ihsm_shaft_countermeasures_c.pdf}
        \caption{A second moving tamper detection mesh also enables more complex topographies.}
        \label{shaft_cm_a}
    \end{subfigure}
    \caption{Mechanical countermeasures to attacks through or close to the shaft of a fixed-axis rotating IHSM.}
    \label{shaft_cm}
\end{figure}

\subsection{Attacking the mesh in motion}

To disable the mesh itself, an attacker can choose two paths. One is to attack the mesh itself, for example by bridging
its traces. The other option is to tamper with the monitoring circuit to prevent a damaged mesh from triggering an
alarm~\cite{dexter2015}.  Attacks in both locations require electrical contact to parts of the circuit. Traditionally,
this is done by soldering a wire or by placing a probe.  We consider this type of attack hard to perform on an object
spinning at high speed. Possible remaining attack avenues may be to rotate an attack tool in sync with the mesh or to
use a laser or ion beam fired at the mesh to cut traces or carbonize parts of the substrate to create electrical
connections. Encapsulating the mesh in a potting compound and shielding it with a metal enclosure as is common in
traditional HSMs will significantly increase the complexity of such attacks.

\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 falsify the rotor's MEMS accelerometer measurements. We can disregard electronic attacks on the sensor or the
monitoring microcontroller because they would be no easier than attacking the mesh traces. What remains would be
physical attacks of the accelerometer's sensing mechanism.  In a MEMS accelerometer, a proof mass moves a cantilever
whose precise position is measured electronically.  A topic of recent academic interest has been acoustic attacks
tampering with these mechanics~\cite{trippel2017}, but such attacks do not yield sufficient control to precisely falsify
sensor readings.  A possible more invasive attack may be to first decapsulate the sensor MEMS using laser ablation
synchronized with the device's rotation. Then, a fast-setting glue such as a cyanoacrylate could be deposited on the
MEMS, locking the mechanism in place. This type of attack can be mitigated by mounting the accelerometer in a shielded
location inside the security envelope and by varying the rate of rotation over time.

\subsection{Attacks on the alarm circuit}

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 using sensors for
temperature, ionizing radiation, laser radiation, supply voltage variations, ultrasound or other vibration, and gases or
liquids.  If a wireless link is used between the IHSM's rotor and stator, this link must be cryptographically secured.
To prevent replay attacks, link latency must continuously be measured, so this link must be bidirectional.
% 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 use a tool such as a large hammer or a gun to simply
destroy the part of the HSM that erases data in response to tampering before it can perform its job. To mitigate this
type of attack, the HSM must be engineered to be either tough or brittle: Tough enough that the tamper response
circuitry will reliably withstand any attack for long enough to carry out its function or brittle in a way that during
any attack, the payload is reliably destroyed before the tamper response circuitry.

\section{Proof-of-concept Prototype implementation}
\label{sec_proto}

As we elaborated above, the mechanical component of an IHSM significantly increases the complexity of any attack even
when implemented using only common, off-the-shelf parts. In view of this amplification of design security, we have
decided to validate our theoretical studies by implementing a proof-of-concept prototype IHSM
(Figure~\ref{prototype_picture}). The main engineering challenges we set out to solve in this proof-of-concept prototype
were:

\begin{enumerate}
    \item A mechanical design suitable for rapid prototyping that can withstand at least $\SI{500}{rpm}$.
    \item The 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}

We will outline our findings on these challenges one by one in the following paragraphs.

\subsection{Mechanical design}

We sized our proof-of-concept prototype to have sufficient payload space for a Raspberry Pi single-board computer to
approximate a traditional HSM's processing capabilities.  We use printed circuit boards as the main structural material
for the rotating part, and 2020 aluminium extrusion for its mounting frame. Figure~\ref{fig_proto_mesh} shows the
rotor's mechanical PCB designs.  The design uses a $\SI{6}{\milli\meter}$ brass tube as its shaft, which is sufficiently
narrow to pose a challenge to an attacker. The rotor is driven by a small hobby quadcopter motor.  Our prototype
incorporates a functional PCB security mesh. As we observed previously, this mesh only needs to cover every part of the
system once per revolution, so we designed the longitudinal PCBs as narrow strips to save weight.

\subsection{PCB security mesh generation}

Our proof-of-concept security mesh covers a total of five interlocking mesh PCBs (Figure~\ref{mesh_gen_sample}). A sixth
PCB contains the monitoring circuit and connects to these mesh PCBs.  To speed up design iterations, we automated the
generation of this security mesh through a plugin for the KiCAD EDA
suite\footnote{\censorIfSubmission{\url{https://blog.jaseg.de/posts/kicad-mesh-plugin/}}}.  Figure~\ref{mesh_gen_viz}
visualizes the mesh generation process. First, the target area is overlaid with a grid. Then, the algorithm  produces a
randomized tree covering the grid.  Finally, individual mesh traces are traced according to a depth-first search through
this tree.  We consider the quality of the plugin's output sufficient for practical applications.  Together with
FreeCAD's KiCAD StepUp plugin, this results in an efficient toolchain from mechanical CAD design to production-ready PCB
files.

\begin{figure}
    \begin{subfigure}{0.35\textwidth}
        \center
        \includegraphics[height=7cm]{proto_3d_design.jpg}
        \caption{The 3D CAD design of the proof-of-concept prototype.}
    \end{subfigure}
    \hfill
    \begin{subfigure}{0.6\textwidth}
        \includegraphics[width=8cm]{rotor_stator.jpg}
        \center 
        \caption{Assembled mechanical prototype rotor (left) and stator (right) PCB components.}
    \end{subfigure}
    \caption{Our proof-of-concept prototype IHSM's PCB security mesh design}
    \label{fig_proto_mesh}
\end{figure}

\begin{figure}
    \begin{subfigure}{\textwidth}
        \center
        \includegraphics[width=9cm]{mesh_gen_viz.pdf}
        \caption{Overview of the automatic security mesh generation process. 1 - Example target area. 2 - Grid overlay.
        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{subfigure}
    \begin{subfigure}{\textwidth}
        \center
        \includegraphics[width=6cm]{mesh_scan_crop.jpg}
        \caption{Detail of a PCB produced with a generated mesh.}
        \label{mesh_gen_sample}
    \end{subfigure}
    \caption{Our automatic security mesh generation process}
    \label{mesh_gen_fig}
\end{figure}

\subsection{Power transmission from stator to rotor}

The spinning mesh has its own autonomous monitoring circuit. This spinning monitoring circuit needs both power and data
connectivity to the stator.  To design the power link, we first need to estimate the monitoring circuit's power
consumption.  We base our calculation on the (conservative) assumption 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 a $\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}$.  This value is comparable to a reasonable estimation of the current consumption of the
monitoring circuit itself. In our prototype, we used ST Microelectronics STM32 Series ARM Cortex-M microcontrollers. To
get an estimate on the current consumption of an energy-optimized design we will refer to the datasheet of the
\partnum{STM32L486JG}\footnote{\url{https://www.st.com/resource/en/datasheet/stm32l486jg.pdf}}, a representative member
of ST's \partnum{STM32L4} low-power sub-family that provides hardware acceleration for AES256. A good target for an
implementation of a secure cryptographic channel on this device would be the noise protocol framework~\cite{perrin2018}.
While the initial handshake for key establishment uses elliptic-curve cryptography and may take several hundred
milliseconds~\cite{tschofenig2015}, the following payload data transfer messages require only symmetric cryptographic
primitives. The \partnum{STM32L486JG} datasheet lists the microcontroller's typical operating current at around
$\SI{8}{\milli\ampere}$ at $\SI{48}{\mega\hertz}$ clock speed and lists a sleep current of less than
$\SI{1}{\micro\ampere}$ in low-power standby mode with RTC enabled. The AES peripheral is listed with less than
$\SI{2}{\micro\ampere\per\mega\hertz}$ typical current consumption. A typical high-$g$ accelerometer for an IHSM
application would be ST Microelectronics' \partnum{H3LIS331DL}. Its
datasheet\footnote{\url{https://www.st.com/resource/en/datasheet/h3lis331dl.pdf}} lists a typical current consumption
between $\SI{10}{\micro\ampere}$ in low-power mode with output sampling rate up to $\SI{10}{\hertz}$ and
$\SI{300}{\micro\ampere}$ in normal operating mode with output sampling rate up to $\SI{1}{\kilo\hertz}$.  Given the low
amount of data that has to be processed in our application (hundreds of bytes per second), if we assume a duty cycle of
$\SI{1}{\percent}$ of active data processing vs.\ sleep mode at the given clock speed we arrive at a total estimated
current consumption of our microcontroller of less than $\SI{100}{\micro\ampere}$.  Thus, reserving
$\SI{100}{\micro\ampere}$ for the monitoring circuit on top of the $\SI{100}{\micro\ampere}$ for the transceiver circuit
we arrive at an energy consumption of $\SI{1.7}{\ampere\hour}$ per year.

This annual energy consumption is close to the capacity of a single CR123A lithium primary cell. By either using several
such cells or by optimizing power consumption, several years of battery life could easily be reached.  In our proof of
concept prototype, we decided against using a battery to reduce rotor mass and avoid balancing issues.

We also decided against mechanically complex solutions such as slip rings or electronically complex ones such as
inductive power transfer. Instead, we chose a simple setup consisting of a stationary lamp pointing at several solar
cells on the rotor.  At the monitoring circuit's low power consumption power transfer efficiency is irrelevant, so this
solution is practical.  Our system uses six series-connected solar cells mounted on the end of the cylindrical rotor
that are fed into a large $\SI{33}{\micro\farad}$ ceramic buffer capacitor through a Schottky diode. This solution
provides around $\SI{3.0}{\volt}$ at several tens of $\si{\milli\ampere}$ to the payload when illuminated using either
a $\SI{60}{\watt}$ incandescent light bulb or a flicker-free LED studio light of similar brightness\footnote{LED lights
intended for room lighting exhibit significant flicker that can cause the monitoring circuit to reset. Incandescent
lighting requires some care in shielding the data link from the light bulb's considerable infrared output.}.

\subsection{Data transmission between stator and rotor}

Besides power transfer from stator to rotor, we need a reliable, bidirectional data link to transmit mesh status and a
low-latency heartbeat signal. We chose to transport an $\SI{115}{\kilo\baud}$ UART signal through a simple IR link for a
quick and robust solution. The link's transmitter directly drives a standard narrow viewing angle IR led through a
transistor.  The receiver has an IR PIN photodiode reverse-biased at $\frac{1}{2}V_\text{CC}$ feeding into an
\partnum{MCP6494} general purpose opamp configured as a $\SI{100}{\kilo\ohm}$ transimpedance amplifier. As shown in
Figure \ref{photolink_schematic}, the output of this TIA is amplified one more time before being squared up by a
comparator.  Our design trades off stator-side power consumption for a reduction in rotor-side power consumption by
using a narrow-angle IR led and photodiode on the rotor, and wide-angle components at a higher LED current on the
stator. Figure~\ref{ir_tx_schema} shows the physical arrangement of both links. The links face opposite one another and
are shielded from one another by the motor's body in the center of the PCB.

% We used an \partnum{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.

\begin{figure}
    \begin{subfigure}{0.3\textwidth}
        \includegraphics[width=4.5cm]{ir_tx_schema.pdf}
        \caption{Basic layout, 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{subfigure}
    \hfill
    \begin{subfigure}{0.65\textwidth}
        \includegraphics[width=9cm]{photolink_schematic.pdf}
        \caption{Schematic with sample component values. C2 is highly dependent on the photodiode characteristics and
        stray capacitances.}
        \label{photolink_schematic}
    \end{subfigure}
    \caption{IR data link implementation}
\end{figure}

\subsection{Evaluation}

The proof-of-concept hardware worked as intended. Both rotating power and data links performed well. As we expected, the
mechanical design vibrated at higher speeds but despite these unintended vibrations, we were able to reach speeds in
excess of $\SI{1000}{rpm}$ by clamping the device to the workbench. Even at high speeds, both the power link and the
data links continued to function without issue.

By design, our prototype is not yet a production-ready solution. Its main limitation is the small payload volume that
can house one or two Raspberry Pi single-board computers, but does not allow for more powerful hardware such as a
contemporary server mainboard. Being constructed without access to a proper mechanical workshop, its imprecise
construction leads to vibration at high speeds. Its optical communication links in breadboard construction function and
need to be translated into manufacturable PCBs, and its security mesh has to be optimized for security. Finally, a motor
driver solution needs to be selected that allows for direct digital control of motor speed.  Overall, the prototype
soundly demonstrated the viability of the IHSM concept and we are confident that all of these limitations can be
conclusively solved in a new iteration that might be a ``beta'' version of a practical IHSM, built in a mechanical
workshop.

\section{Using MEMS accelerometers for braking detection}
\label{sec_accel_meas}

In our proof-of-concept prototype, for braking detection we chose an accelerometer placed on the circumference of our
prototype's rotor for two reasons: First, it avoids the likley issue of high centrifugal acceleration falsifying
gyroscope measurements.  Second, by orienting one axis of the accelerometer radially, we can avoid exceeding the
accelerometer's range even when rapidly accelerating or decelerating. Rapid angular acceleration or deceleration
produces high tangential linear acceleration or deceleration in our sensor, but the radially-oriented axis of the
accelerometer only experiences an amount of centrifugal acceleration that is bounded by the rotor's momentary angular
velocity and never exceeds the device's specified operating conditions.

Using our prototype, we performed an evaluation of an \partnum{AIS1120} commercial automotive MEMS accelerometer as a
braking sensor. The device is mounted inside our prototype at a radius of $\SI{55}{\milli\meter}$ from the axis of
rotation to the center of the device's package. The \partnum{AIS1120} provides a measurement range of $\pm 120\,g$. At
its 14-bit resolution, one LSB corresponds to $15\,\mathrm{m}g$.

Our prototype IHSM uses a motor controller intended for use in RC quadcopters. In our experimental setup, we manually
control this motor controller through an RC servo tester. In our experiments, we externally measured the device's speed
of rotation using a magnet fixed to the rotor and a reed switch. The reed switch output is digitized using a USB logic
analyzer at a sample rate of $\SI{100}{\mega\hertz}$. We calculate rotation frequency as a $\SI{1}{\second}$ running
average over interval lengths of the debounced captured signal\footnote{A regular frequency counter or commercial
tachometer would have been easier, but neither was available in our limited COVID-19 home office lab.}.

The accelerometer is controlled from the \partnum{STM32} microcontroller on the rotor of our IHSM prototype platform.
Timed by an external quartz, the microcontroller samples accelerometer readings at $\SI{10}{\hertz}$. Readings are
accumulated in a small memory buffer, which is continuously transmitted out through the prototype platform's infrared
link. Data is packetized with a sequence number indicating the buffer's position in the data stream and a CRC-32
checksum for error detection. On the host, a Python script stores all packets received with a valid checksum in an
SQLite database.

Data analysis is done separately from data capture. An analysis IPython notebook reads captured packets and reassembles
the continuous sample stream based on the packets' sequence numbers. The low $\SI{10}{\hertz}$ sample rate and high
$\SI{115}{\kilo Bd}$ transmission speed lead to a large degree of redundancy with gaps in the data stream being rare.
This allowed us to avoid writing retransmission logic or data interpolation.

Figure~\ref{fig-acc-steps} shows an entire run of the experiment. During this run, we started with the rotor at
standstill, then manually increased its speed of rotation in steps. Areas shaded gray are intervals where we manually
adjust the rotor's speed. The unshaded areas in between are intervals when the rotor speed is steady.
Figure~\ref{fig-acc-stacked} shows a magnified view of these periods of steady rotor speed. In both graphs, orange
lines indicate centrifugal acceleration as calculated from rotor speed measurements. Visually, we can see that
measurements and theory closely match. Our frequency measurements are accurate and the main source of error are the
accelerometer's intrinsic errors as well as error in its placement due to construction tolerances.

\begin{figure}
    \begin{subfigure}{0.5\textwidth}
        \center
        \includegraphics[width=1.1\textwidth]{../prototype/sensor-analysis/fig-acc-trace-steps-run50.pdf}
        \caption{Raw recording of accelerometer measurements during one experiment run. Shaded areas indicate time
        intervals when we manually adjusted speed.}
        \label{fig-acc-steps}
    \end{subfigure}
    \hfill
    \begin{subfigure}{0.45\textwidth}
        \center
        \includegraphics[width=1.1\textwidth]{../prototype/sensor-analysis/fig-acc-trace-stacked-run50.pdf}
        \caption{Valid measurements cropped out from \ref{fig-acc-steps} for various frequencies. Intermodulation
        artifacts from the accelerometer's $\SI{10}{\hertz}$ sampling frequency and the $\SI{3}{\hertz}$ to
        $\SI{18}{\hertz}$ rotation frequency due to gravity and device vibration are clearly visible.}
        \label{fig-acc-stacked}
    \end{subfigure}
    \label{fig-acc-traces}
    \caption{Traces of acceleration measurements during one experiment run.}
\end{figure}

The accelerometer has two main intrinsic errors. Offset error is a fixed additive offset to all measurements. Scale
error is an error proportional to a measurements value that results from a deviation between the device's specified and
actual sensitivity. We correct for both errors by first extracting all stable intervals from the time series, then
fitting a linear function to the measured data. Offset error is this linear function's intercept, and scale error is its
slope. We then apply this correction to all captured data before plotting and later analysis.  Despite its simplicity,
this approach already leads to a good match of measurements and theory modulo a small part of the device's offset
remaining. At high speeds of rotation, this remaining offset does not have an appreciable impact, but due to the
quadratic nature of centrifugal acceleration, at low speeds it causes a large relative error of up to
$\SI{8}{\percent}$ at $\SI{95}{rpm}$.

After offset and scale correction, we applied a low-pass filter to our data. The graphs show both raw and filtered data.
Raw data contains significant harmonic content. This content is due to vibrations in our prototype as well as gravity
since we tested our proof-of-concept prototype lying down, with its shaft pointing sideways.  FFT analysis shows that
this harmonic content is a clean intermodulation product of the accelerometer's sample rate and the speed of rotation
with no other visible artifacts.

Figure~\ref{fig-acc-theory} shows a plot of our measurement results against frequency. Data points are shown in dark
blue, and theoretical behavior is shown in orange. From our measurements, we can conclude that an accelerometer is a
good choice for an IHSM's braking sensor. A simple threshold set according to the sensor's calculated expected
centrifugal force should be sufficient to reliably detect manipulation attempts without resulting in false positives.
Periodic controlled changes in the IHSM's speed of rotation allow offset and scale calibration of the accelerometer on
the fly, without stopping the rotor.

\begin{figure}
    \center
    \includegraphics[width=0.7\textwidth]{../prototype/sensor-analysis/fig-acc-theory-meas-run50.pdf}
    \caption{Centrifugal acceleration versus angular frequency in theory and in our experiments. Experimental
    measurements are shown after correction for offset and scale error.  Above \SI{300}{rpm}, the relative error is
    below $\SI{0.5}{\percent}$. Below $\SI{300}{rpm}$, the residual offset error has a large impact ($0.05\,g$ absolute
    or $8\%$ relative at $\SI{95}{rpm}$.)}
    \label{fig-acc-theory}
\end{figure}

\section{Conclusion}
\label{sec_conclusion} 

In this paper, we introduced Inertial Hardware Security Modules (IHSMs), a novel concept for the construction of
advanced hardware security modules from simple components.  We analyzed the concept for its security properties and
highlighted its ability to significantly strengthen otherwise weak tamper detection barriers.  We validated our design
by creating a proof-of-concept hardware prototype. In this prototype, we have demonstrated practical solutions to the
major electronics design challenges: Data and power transfer through a rotating joint, and mechanized mesh generation.
We have used our prototype to perform several experiments to validate the rotary power and data links and the onboard
accelerometer.  Our measurements have shown that our proof-of-concept solar cell power link works well and that our
simple IR data link already is sufficiently reliable for telemetry. Our experiments with an \partnum{AIS1120} automotive
MEMS accelerometer showed that this part is well-suited for braking detection in the range of rotation speed relevant to
the IHSM scenario.

Overall, our findings validate the viability of IHSMs as an evolutionary step beyond traditional HSM technology.  IHSMs
offer a high level of security beyond what traditional techniques can offer even when built from simple components. They
allow the construction of devices secure against a wide range of practical attacks in small quantities and without
specialized tools.  The rotating mesh allows longitudinal gaps, which enables new applications that are impossible with
traditional HSMs.  Such gaps can be used to integrate a fan for air cooling into the HSM, allowing the use of powerful
computing hardware inside the HSM.  We hope that this simple construction will stimulate academic research into (more)
secure hardware. We published all design artifacts of our PoC online, please refer to Appendix~\ref{sec_repo} for
details. The next steps towards a practical application of our design will be to design a manufacturable stator/rotor
interface with inductive power and data transfer integrated into the motor's magnetics and a custom motor driver tuned
for the application that is able to precisely measure both angular velocity and winding current for an added degree of
tamper detection through the measurement of external forces acting on the rotor.

\printbibliography[heading=bibintoc]

\appendix
\section{Source code and design artifacts}
\label{sec_repo}

During our research on this paper, we have created a number of digital design artifacts including a 3D mechanical CAD
model of our prototype IHSM, schematics, and PCB layouts for all of its PCBs including the prototype security mesh
monitor PCB as well as firmware and data analysis scripts for the experiments we ran on the prototype IHSM. All of these
digital artifacts as well as the sources to this paper are included in the git repository linked below. 

\center{
    \center{\censorIfSubmission{\url{https://git.jaseg.de/rotohsm.git}}}

    \center{This is version \texttt{\input{version.tex}\unskip} of this paper, generated on \today.}
}

\end{document}