642 lines
41 KiB
TeX
642 lines
41 KiB
TeX
\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 Foil Advanced Physical Attacks}
|
|
\author{Jan Götte}
|
|
\date{2020-09-15}
|
|
\maketitle
|
|
|
|
\section*{Abstract}
|
|
|
|
In this paper, we introduce a novel, highly effective 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 even the best commercial offerings. 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 equates 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 in form of smartcard-like 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 be reduced to that of its
|
|
physically secured TPM\cite{heise2020t2jailbreak,frazelle2019,johnson2018}. Being physcially small, physical security is
|
|
less of a challenge on the scale of a TPM.
|
|
|
|
\subsection{Technical approaches to physical security}
|
|
|
|
Shrinking things to the nanoscopic level to secure them against tampering is an engineering solution to problems that
|
|
cannot be solved (yet) with cryptographic security. The security of chips like smartcards and TPMs often rests on the
|
|
assumption that their fine structures are hard to reverse engineer and modify. As of now, this property holds and in the
|
|
authors' opinion it will likely be a reasonable assumption 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 these
|
|
chips\cite{albartus2020,anderson2020}.
|
|
|
|
\subsection{Hardware Security Modules}
|
|
|
|
Right now, Hardware security modules (HSMs) are the class of commercial devices offering the highest ``physical
|
|
security-to-volume-product''. Where smartcards physically secure a single chip, HSMs secure a small circuit board. In
|
|
contrast to a smartcard, in a tradeoff between security and convenience the HSM actively deletes its secrets when it
|
|
detects a manipulation. Commercial HSMs commonly employ what we call \emph{boundary monitoring}. They have a physical
|
|
security barrier that they continuously monitor for holes. Usually, this barrier is a thin foil that is patterned with
|
|
at least two meandering electrical traces that is folded in layers to cover the entire area of the foil. The HSM
|
|
monitors these traces for shorts or breaks. This simple construction transforms the security problem into a
|
|
manufacturing challenge\cite{isaacs2013,immler2019,anderson2020}.
|
|
|
|
In our classification the other type of HSMs are \emph{volumetric} HSMs. They monitor their entire internal volume for
|
|
changes using e.g.\ electromagnetic radiation\cite{tobisch2020,kreft2012} or ultrasound\cite{vrijaldenhoven2004}. Their
|
|
security is limited by the analog sensitivity of their transceivers. Their practicality is limited by their complex
|
|
transceiver and signal processing circuitry. They promise to secure larger volumes than boundary monitoring at higher
|
|
parts cost. A problem with volumetric designs is their security analysis, which is hard to do without significant
|
|
guesswork. In e.g.\ a device that use electromagnetic radiation to monitor its volume, one might have to numerically
|
|
solve the electromagnetic field equations inside the HSM to validate its impenetrability.
|
|
|
|
\subsection{Inertial HSMs: A new approach to physical security}
|
|
|
|
We are certain that there is still much work to be done and many insights to be gained in both HSM and in smartcard
|
|
technology\footnote{
|
|
As a baseline, consider a box with mirrored walls that contains a smaller box suspended on thin wires that has
|
|
cameras looking outward in all directions at the mirrored walls. Given that the defender can control lighting
|
|
conditions inside this kaleidoscopic box in this application modern cameras perform better than the human eye.
|
|
Thus, a successful physical attack on this system would likely an ``invisibility cloak''--and the system would
|
|
remain secure as long as no such thing exists. To be viable, an HSM technology must be either cheaper, smaller or
|
|
more sensitive than this strawman setup\cite{kim2018}.
|
|
}. % TODO perhaps misplaced citation and/or poor source?
|
|
Still, we wish to introduce a novel approach to sidestep the issues of conventional HSMs 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. As a trivial example, consider an HSM as it is used in
|
|
ecommerce applications for credit card payments. 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, triggering 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\footnote{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.
|
|
|
|
\subsection{Contributions}
|
|
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}
|
|
|
|
\section{Related work}
|
|
% summaries of research papers on HSMs. I have not found any actual prior art on anything involving mechanical motion
|
|
% beyond ultrasound.
|
|
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.
|
|
|
|
Our concept is novel in that mechanical motion has not been proposed before 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}
|
|
|
|
\subsection{Using motion for tamper detection}
|
|
|
|
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. Let us think about the constraints of our approach.
|
|
|
|
\begin{enumerate}
|
|
\item We need the tamper sensor's motion to be fairly fast. If any point of the sensor moves slow enough for a human
|
|
to follow, it becomes a weak spot.
|
|
\item We need to keep the entire apparatus compact.
|
|
\item We need the sensor's motion to be very predictable so that we can detect an attacker trying to stop it.
|
|
\end{enumerate}
|
|
|
|
From this, we can make a few observations.
|
|
|
|
\begin{enumerate}
|
|
\item Non-periodic linear motion (like a train on wheels) is likely to be a poor choice since it requires a large
|
|
amount of space, and it is comparatively easy to follow something moving linearly.
|
|
\item Oscillatory motion such as linear vibration or a pendulum motion might be a good candidate would there not be
|
|
the moment at its apex when the vibration reverses direction the object is stationary. This is a weak spot.
|
|
\item Rotation is a very good choice. It does not require much space to execute. Additionally, 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. Since their tangential linear velocity would rise linearly with the radius from the axis of rotation, an
|
|
assumption on tolerable centrifugal force allows one to limit the approximate maximum size and mass of an
|
|
attacker (see Appendix \ref{sec_minimum_angular_velocity}). The axis of rotation is a weak spot, but we can
|
|
simply nest multiple layers of protection at an angle to each other.
|
|
\item We do not have 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.
|
|
\end{enumerate}
|
|
|
|
\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. At high speeds, this acceleration may become very large. This poses the engineering challenge of preventing
|
|
the whole thing from flying apart, but also creates an obstacle to any attacker trying to manipulate the sensor.
|
|
|
|
In Appendix \ref{sec_minimum_angular_velocity} we present some back-of-the-envelope calculations on 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. Other configurations such as one
|
|
using two two-axis accelerometers in the rotor are also possible. 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{Payload mounting mechanisms}
|
|
|
|
The simplest way to mount a stationary payload in a spinning security mesh is to drive the rotor using a hollow shaft.
|
|
This allows the payload to be mounted on a fixed rod threaded through this hollow shaft along with wires for power and
|
|
data. The stationary rod and cables on the axis of rotation inside the hollow shaft are 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.
|
|
|
|
\subsection{Spinning mesh power supply}
|
|
|
|
There are several options to transfer power to the rotor from its stationary frame.
|
|
|
|
\begin{enumerate}
|
|
\item Slip ring contacts are a poor candidate as they are limited in their maximum speed and lifetime, and as
|
|
precision mechanical components are expensive.
|
|
\item Inductive power transfer as used in inductive charging systems can be used without modification if both coils
|
|
are mounted axially.
|
|
\item A second brushless motor on the axis of rotation can be used as a generator, with its axis connected to the
|
|
fixed frame and its stator mounted and connected to the rotor. Likewise, a custom-made drive motor that includes
|
|
some auxiliary rotor windings for power transfer in addition to the rotor's magnets would be possible.
|
|
\item A bright lamp along with some small solar cells may be a practical approach for small amounts of
|
|
energy\footnote{See Appendix \ref{sec_energy_calculations} for a back-of-the-envelope calculation}.
|
|
\item For a very low-power security mesh, a battery specified to last for the lifetime of the device may be
|
|
practical\footnote{See Appendix \ref{sec_energy_calculations}}.
|
|
\end{enumerate}
|
|
|
|
In our prototype, we settled on a solar cell-based solution for its simplicity.
|
|
|
|
\subsection{Payload cooling}
|
|
|
|
In boundary-sensing HSMs, cooling of the processor inside is a serious issue since any air duct or heat pipe would have
|
|
to penetrate the HSM's security boundary. This problem can be solved with complex and costly siphon-style constructions,
|
|
but in commercial systems heat conduction is used exclusively\cite{isaacs2013}. This limits the maximum power
|
|
dissipation of the payload and thus its processing power. In our spinning HSM concept, the spinning mesh can have
|
|
longitudindal gaps in the mesh without impeding its function. This allows air to pass through the mesh during rotation,
|
|
and one could even integrate an actual fan into the rotor. This greatly increases the maximum possible power dissipation
|
|
of the payload and unlocks much more powerful processing capabilities.
|
|
|
|
\subsection{Spinning mesh data communication}
|
|
|
|
As for power, slip rings are the obvious choice to couple data signals through the rotating joint. Like for power, ones
|
|
that match our reliability and speed constraints are expensive.
|
|
|
|
Our design has a stationary payload and only the security mesh and sensors are spinning. The rotor only needs to send
|
|
occassional status reports and a high-frequency alarm trigger heartbeat signal to the stator. For
|
|
this, a simple optocoupler close to the axis of rotation is a good solution that we implemented in our prototype.
|
|
|
|
\section{Attacks}
|
|
\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 alarm circuitry}
|
|
|
|
An electronic attack could also target the alarm circuitry inside the stationary payload, or the communication link
|
|
between rotor and payload. The link can easily be proofed by using a cryptographically secured protocol 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 and has to tolerate environmental attacks such as ones using temperature, ionizing radiation,
|
|
lasers, supply voltage variations, ultrasound or other vibration and gases or liquids. The easiest way to proof an alarm
|
|
system against these is to employ adequate filtering of the incoming power supply and use sensors for the others,
|
|
triggering an alarm in case extraordinary environmental variations are detected.
|
|
|
|
If the alarm link between rotor and stator uses a spoofable interface such as an optical link, this link must be
|
|
bidirectional to allow the alarm signal receiver to verify link latency. In a purely unidirectional spoofable link, an
|
|
attacker could record the authenticated "no alarm" signal from the transmitter while simultaneously replaying it just
|
|
slightly slower (say at $\SI{99}{\percent}$ speed) to the receiver. The receiver would not be able to distinguish
|
|
between this attack and ordinary deviations in the transmitter's local clock frequency. However, the attacker can at any
|
|
point simply stop the rotor and replay the leftover recorded "no alarm" signal. Given the frequency stability of
|
|
commercial crystals, this would allow for an attack duration of several seconds per hour of recording time.
|
|
|
|
\subsection{Fast and violent attacks}
|
|
|
|
A variation of the above attacks on the alarm circuitry would be an attack that
|
|
attempts to simply destroy this circuitry before the alarm can be acted upon using a tool like a large hammer or a gun.
|
|
Mitigations for this type of attack include potting the payload inside a mechanically robust enclosure. The alarm
|
|
signalling chain's integrity can be checked continuously using a cryptographic heartbeat protocol. A simple active-high
|
|
or active-low alarm signal cannot be considered fail-safe in this scenario.
|
|
|
|
\subsection{Attacks on the rotation sensor}
|
|
|
|
An attacker may try to stop the rotor before tampering with the mesh. 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. Physical attacks on the accelerometer are possible\cite{trippel2017}, but in the
|
|
authors' estimate are too hard to control to be practically useful.
|
|
|
|
A last type of attack might be to try to physically tamper with the accelerometer's sensing mechanism. MEMS
|
|
accelerometers usually use a cantilever design, where a proof mass moves a cantilever whose precise position can be
|
|
measured electronically. A possible way to attack such a device might 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. This attack would require direct access to the accelerometer from the outside
|
|
and can be prevented by mounting the accelerometer in a shielded place inside the security envelope. This attack can
|
|
only work if the rate of rotation and thus the accelerometer's readings are constant. If the rate of rotation is set to
|
|
change on a schedule, it is trivially detectable.
|
|
|
|
In Appendix \ref{sec_degrees_of_freedom} we outline the constraints on sensor placement.
|
|
|
|
\section{Prototype implementation}
|
|
|
|
To validate our theoretical design, we have implemented 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 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 one or 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}
|
|
|
|
To allow a quick iteration of our design while producing results with a realistic level of security, 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/}}.
|
|
|
|
Our mesh generation plugin overlays a grid on the target area and 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}
|
|
|
|
As a baseline solution for data transmission, 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 \textsf{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}
|
|
|
|
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 made up from 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}
|
|
|
|
During experiments, our prototype performed as intended. After some experimentation, we got both power and data
|
|
transmission through the rotating joint 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
|
|
each receiver's 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{Future Work}
|
|
|
|
\subsection{Design space exploration}
|
|
|
|
There are several aspects of intertial HSM design that we wish to explore in future work.
|
|
|
|
\paragraph{Other modes of movement} An oscillating iHSM might enable power and data transfer to the moving part using
|
|
cables.
|
|
|
|
\paragraph{Multiple axes of rotation} The weak spot of our prototype design at the stationary shaft can be alleviated
|
|
using gyroscope mechanics.
|
|
|
|
\paragraph{Other sensing modes} By printing the inside of the rotor with a pattern that is observed by a linear CCD a
|
|
completely passive rotor may be possible.
|
|
|
|
\paragraph{Bearing longevity}
|
|
|
|
\paragraph{Handling of gyroscopic precession forces during shipping}
|
|
|
|
\subsection{Penetration testing}
|
|
We intend to refine our prototype design to production quality. As part of this, we wish to try out a range of attacks
|
|
on our prototype.
|
|
|
|
\section{Conclusion}
|
|
In this paper, we have presented inertial hardware security modules (iHSMs), a novel concept for the construction of
|
|
highly secure hardware security modules from inexpensive, commonly available parts. We have elaborated the engineering
|
|
considerations underlying a practical implementation of this concept. We have implemented a prototype demonstrating
|
|
practical solutions to the significant engineering challenges of this concept. We have analyzed the concept for its
|
|
security properties and highlighted its ability to significantly strengthen otherwise weak tamper detection barriers. We
|
|
have laid out some ideas for future research on the concept.
|
|
|
|
\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}
|