jaseg/ihsm
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Split paper/tech report

Browse source
This commit is contained in:
jaseg 2021-01-05 17:30:41 +01:00
parent 92f646fbf3
commit a46d649a5b
3 changed files with 615 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

13
doc/quick-tech-report/Makefile
View file

@ -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

BIN
doc/quick-tech-report/rotohsm_paper.pdf Normal file
View file

Binary file not shown.

609
doc/quick-tech-report/rotohsm_paper.tex Normal file
View file

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