summaryrefslogtreecommitdiff
path: root/doc/quick-tech-report/rotohsm_tech_report.tex
blob: f69301af93e9deab7b67f14b7ebf2b46b4964b80 (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
640
641
642
\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}