summaryrefslogtreecommitdiff
path: root/doc/quick-tech-report/rotohsm_tech_report.tex
blob: bf51a87d8efe99dc229c0160957586929340b004 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
\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--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.

\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 smartcards or hardware security modules (HSMs). Smartcards and HSMs protect a physically small
volume of a single chip or circuit board, respectively. In lower-security applications\cite{heise2020t2jailbreak},
smartcard-like trusted platform modules (TPMs) and other types of security platform controllers allow an administrator
to tie a whole computer's security to that of the small security chip inside\cite{frazelle2019,johnson2018}.

\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 these chips 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 commercial devices offering the highest ``physical
security-to-volume-product''. Where smartcards secure a single chip, HSMs secure a small circuit board. In contrast to a
smartcard, 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 electrical traces that are folded many times 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. 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 has 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
\label{sec_minimum_angular_velocity}}. Non-contact electromagnetic or optical attacks that do not require mechanical
contact are more limited in the first place and can be shielded, so we have effectively forced the attacker to make 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 our inertial HSM concept.
    \item We present a prototype of an 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 it 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 claim 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 32 in their example).
Their concept promises a very high degree of protection. The main disadvantages of their concept are a limitation in
both 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.

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 closes 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
disturbances if we over-determine the system of equation determining 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 more
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.
    \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.
    \item A bright LED 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}

% FIXME not prototype implementation here

\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 solve by 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, for
data, too they are too expensive for our application.

In our design with a stationary payload where only the security mesh and sensors are spinning, only occassional status
reports and a high-frequency alarm trigger heartbeat signal have to pass from rotor to stator. For this, a simple
optocoupler close to the axis of rotation is a good solution.

\section{Attacks}
\subsection{Attacks on the mesh}

There are two locations where one can attack a tamper-detection mesh. Either, 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. 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. Any kind of electrical contact that does not
involve an electron or ion beam or a liquid requires mechanical contact. We consider none of these forms feasible to be
performed on an object spinning at high speed without a complex setup that rotates along with the object. 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 through 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.

\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 and would not make sense.  Physical attacks on the accelerometer are
possible\cite{trippel2017}, but in the authors' estimate are too hard to control to be practically useful.

A possible attack scenario would be to instantly stop the spinning motion and accelerate the HSM linearly such that the
linear acceleration as measured equals the previous centrifugal acceleration. Since commercial accelerometers are very
precise we do not consider this type of attack feasible.

A last type of attack might be to try to physically tamper with the accelerometer's sensing mechanism. MEMS
accelerometers usually use a simple 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 in either liquid or gaseous form, locking them in place after hardening. This attack would require
direct access to the accelerometer from the outside and can be prevented by mounting the accelerometer inside the
security envelope.  This attack only works 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.

% FIXME Appendix \ref{sec_degrees_of_freedom}

\section{Prototype implementation}

%FIXME
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 mechanical CAD 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 made for photography applications that provdided us with mostly flicker-free
light, 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}

\paragraph{Other modes of movement}
We decided to build a spinning HSM because it is the easiest option. Still, other modes of movement are also promising.
Particularly an oscillating HSM may be easier to construct at the expense of security. In it, power and data transfer to
the moving part could simply be done with cables.

\paragraph{Multiple axes of rotation}
The baseline single-axis spining HSM we propose has a weak spot at its shaft. This weak spot can be alleviated using a
gyroscoping mount, allowing the HSM to continuously change its axis of rotation.

\paragraph{Other sensing modes}
Beyond traditional security meshes, other sensing modes might be interesting in our unique setting.  One possible option
without any moving electronics would be to print the inside of the rotor with a pattern, then have a linear CCD look at
the rotor.  The CCD would see the printed pattern passing by at high speed, and one could compare its measurement
against a model of the rotor to check both speed of rotation and rotor integrity at once.

\paragraph{Longevity}
A core issue with a mechanical HSM is component longevity. Save for dust and debris clogging up the HSM's mechanics,
the primary failure point are the bearings. Industrial ducted fans such as servers fans may be a good source for
inspiration.

\paragraph{Transportation of an active device}
A rotating mass responds to torque that is not co-linear with its axis of rotation with a gyroscopic precession force.
In practice, this means that moving a device containing a spun-up rotating HSM on its inside might induce significant
forces on both the HSM (and cause false alarms) and on the carrier of the device (making handling challenging). A
real-world deployment would have to take this into account, especially if the finished device is to be shipped by post
or courier services after spin-up.

\section{Conclusion}
In this paper, we have presented inertial hardware security modules, 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 single byte 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 back-to-chest 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
16\frac{\pi}{\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 deem ourselves to be 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}