Include Björn's remarks, spellcheck
This commit is contained in:
parent
21520789fc
commit
aa05b1dd6e
2 changed files with 57 additions and 51 deletions
|
|
@ -111,19 +111,19 @@ This paper contains the following contributions:
|
|||
\begin{figure}
|
||||
\center
|
||||
\includegraphics[width=12cm]{prototype_pic2.jpg}
|
||||
\caption{The protoype as we used it to test power transfer and bidirectional communication between stator and rotor.
|
||||
This picture shows the proof of concept prototype's configuration that we used for accelerometer characterization
|
||||
(Section~\ref{sec_accel_meas}) without the vertical security mesh struts that connect the circular top and bottom
|
||||
outer meshes.}
|
||||
\caption{The prototype as we used it to test power transfer and bidirectional communication between stator and
|
||||
rotor. This picture shows the proof of concept prototype's configuration that we used for accelerometer
|
||||
characterization (Section~\ref{sec_accel_meas}) without the vertical security mesh struts that connect the circular
|
||||
top and bottom outer meshes.}
|
||||
\label{prototype_picture}
|
||||
\end{figure}
|
||||
|
||||
In Section~\ref{sec_related_work}, we will give an overview of the state of the art in HSM physical security. On this
|
||||
basis, in Section~\ref{sec_ihsm_construction} we will elaborate the principles of our Inertial HSM approach. We will
|
||||
analyze its weaknesses in Section~\ref{sec_attacks}. Based on these results we have built a proof of concept hardware
|
||||
prototype, whose design we will elaborate in Section~\ref{sec_proto}. In Section~\ref{sec_accel_meas} we present our
|
||||
characterization of an automotive MEMS accelerometer IC as a rotation sensor in this proof of concept prototype. We
|
||||
conclude this paper with a general evaluation of our design in Section~\ref{sec_conclusion}.
|
||||
prototype.In Section~\ref{sec_proto} we will elaborate the design of this prototype. In Section~\ref{sec_accel_meas} we
|
||||
present our characterization of an automotive MEMS accelerometer IC as a rotation sensor in this proof of concept
|
||||
prototype. We conclude this paper with a general evaluation of our design in Section~\ref{sec_conclusion}.
|
||||
|
||||
\section{Related work}
|
||||
\label{sec_related_work}
|
||||
|
|
@ -148,8 +148,8 @@ An HSM in principle has to have this examination equipment built-in.
|
|||
Physical seals are used in a wide variety of applications, but the most interesting ones from a research point of view
|
||||
that are recorded in public literature are those used in monitoring of nuclear material under the International Atomic
|
||||
Energy Authority (IAEA). Most of these seals use the same approach that is used in Physically
|
||||
Uncloneable Functions (PUFs), though their development predates that of PUFs by several decades. The seal is created in
|
||||
a way that intentionally causes large, random device to device variations. These variations are precisely recorded at
|
||||
Unclonable Functions (PUFs), though their development predates that of PUFs by several decades. The seal is created in a
|
||||
way that intentionally causes large, random device to device variations. These variations are precisely recorded at
|
||||
deployment. At the end of the seal's lifetime, the seal is returned from the field to the lab and closely examined to
|
||||
check for any deviations from the seal's prior recorded state. The type of variation used in these seals includes random
|
||||
scratches in metal parts and random blobs of solder (IAEA metal cap seal), randomly cut optical fibers (COBRA seal), the
|
||||
|
|
@ -188,7 +188,7 @@ al.~\cite{tobisch2020}\ is that they use commodity WiFi hardware to reduce the c
|
|||
resulting system is likely both much cheaper and capable of protecting a much larger security envelope than designs
|
||||
using finely patterned foil security meshes such as~\cite{immler2019}, at the cost of worse and less predictable
|
||||
security guarantees. Where~\cite{tobisch2020} use electromagnetic radiation, Vrijaldenhoven
|
||||
in~\cite{vrijaldenhoven2004} uses ultrasound waves travelling on a surface acoustic wave (SAW) device to a similar end.
|
||||
in~\cite{vrijaldenhoven2004} uses ultrasound waves traveling on a surface acoustic wave (SAW) device to a similar end.
|
||||
|
||||
While Tobisch et al.~\cite{tobisch2020}\ approach the sensing frontend cost as their primary optimization target, the
|
||||
prior work of Kreft and Adi~\cite{kreft2012} considers sensing quality. Their target is an HSM that envelopes a volume
|
||||
|
|
@ -262,7 +262,7 @@ is the widespread industry use of delicate tamper sensing mesh membranes. The us
|
|||
deployed in the field for a variety of use cases from low security payment processing devices to high security
|
||||
certificate management at a minimum tells us that a properly implemented mesh \emph{can} provide a practical level of
|
||||
security. On the other hand, in contrast to this industry focus, academic research has largely focused on ways to
|
||||
fabricate enclosures that embed characteristics of a Physically Uncloneable Function. By using stochastic properties of
|
||||
fabricate enclosures that embed characteristics of a Physically Unclonable Function. By using stochastic properties of
|
||||
the enclosure material to form a PUF, such academic designs effectively leverage signal processing techniques to improve
|
||||
the system's security level by a significant margin.
|
||||
|
||||
|
|
@ -421,7 +421,7 @@ Uninterruptible Power Supply (UPS) can be used, but in practice a productized IH
|
|||
integrated into its case. Conservatively assuming an average operating power consumption of $\SI{10}{\watt}$ for an
|
||||
IHSM's motor, a single large laptop battery with a capacity of $\SI{100}{\watt\hour}$~\cite{faa2018} could already power
|
||||
an IHSM for 10 hours continuously. $\SI{10}{\watt}$ is a reasonable high estimate given that there are large industrial
|
||||
fans rated at lower wattages. For example, \texttt{CF2207LBL-000U-HB9}, a $\SI{250}{\milli\meter}$ diameter
|
||||
fans rated at lower wattages. For example, \partnum{CF2207LBL-000U-HB9}, a $\SI{250}{\milli\meter}$ diameter
|
||||
$\SI{7.8}{\meter^3\per\minute}$ industrial axial fan made by Sunon is rated at only
|
||||
$\SI{6.6}{\watt}$\footnote{\url{https://www.digikey.com/en/products/detail/sunon-fans/CF2207LBL-000U-HB9/9083282}}. If
|
||||
a built-in battery is undesirable, or if power outages of more than a few seconds at a time are unlikely (e.g.\ because
|
||||
|
|
@ -438,15 +438,15 @@ the IHSM. People working in the datacenter might bump the IHSM. Vibrations from
|
|||
couple through the ground into the datacenter and into the IHSM. Finally, earthquakes are a common occurrence in some
|
||||
regions of the world and will couple through any reasonable amount of vibration damping.
|
||||
|
||||
There are two key points to note on vibration damping. One, the instantaneous mechanical power of a vibrating motion
|
||||
There are two key points to note on vibration damping. First, the instantaneous mechanical power of a vibrating motion
|
||||
is proportional to the square of its amplitude when fixing frequency and the cube of its frequency when fixing
|
||||
amplitude. This means that to reach a certain instantaneous acceleration, much more power is needed in a high-frequency
|
||||
vibrating motion compared to lower frequencies. This observation interacts the second key point we want to note here:
|
||||
An ideal vibration damper works better with higher frequencies, and has a lower bound below which it does no longer
|
||||
damp vibration transmission~\cite{kelly1993,beards1996,dixon2007}. From these two observations it follows that if we
|
||||
wish to reduce the likelihood of false detections by our IHSM tamper alarm, we can achieve this goal efficiently by
|
||||
damping high-frequency shock and vibration, as low-frequency shock or vibration components will not reach accelerations
|
||||
large enough to cause a false alarm.
|
||||
vibrating motion compared to lower frequencies. This observation interacts with our other point that, second, an ideal
|
||||
vibration damper works better with higher frequencies, and has a lower bound below which it does no longer damp
|
||||
vibration transmission~\cite{kelly1993,beards1996,dixon2007}. From these two observations it follows that if we wish to
|
||||
reduce the likelihood of false detections by our IHSM tamper alarm, we can achieve this goal efficiently by damping
|
||||
high-frequency shock and vibration, as low-frequency shock or vibration components will not reach accelerations large
|
||||
enough to cause a false alarm.
|
||||
|
||||
To put this into perspective, consider an IHSM running at an angular frequency of $\SI{1000}{rpm}$. If the IHSM's tamper
|
||||
sensor is mounted at a radius of $\SI{100}{\milli\meter}$ from the axis of rotation, it will measure a constant
|
||||
|
|
@ -584,9 +584,9 @@ is hard. Let us assume a small IHSM mesh with radius $r=\SI{100}{\milli\meter}$.
|
|||
To keep a manipulator stationary within a $\SI{5}{\milli\meter}$ by $\SI{5}{\milli\meter}$ window over a period of
|
||||
$\SI{10}{\second}$ requires attack tool and IHSM speeds to be matched to an accuracy better than
|
||||
$\frac{\SI{5}{\milli\meter}}{\SI{10}{\second}} \cdot \frac{1}{2\pi r} = \SI{8.0}{\milli\hertz} = \SI{0.048}{rpm}$.
|
||||
Relative to a realsistic IHSM's speed of $\SI{1000}{rpm}$ this corresponds to approximately $\SI{50}{ppm}$.
|
||||
Achieving this accuracy would likely require active servo control of the attack tool's rotation that is locked by
|
||||
optically tracking of the IHSM's rotor.
|
||||
Relative to a realistic IHSM's speed of $\SI{1000}{rpm}$ this corresponds to approximately $\SI{50}{ppm}$. Achieving
|
||||
this accuracy would likely require active servo control of the attack tool's rotation that is locked by optically
|
||||
tracking of the IHSM's rotor.
|
||||
|
||||
If an attacker were to solve the tracking issue, the remaining issue is that they still need to construct a
|
||||
remote-controlled manipulator that can be mounted on the attack tool's rotating stage that is able to disable the IHSM's
|
||||
|
|
@ -778,16 +778,16 @@ requires $\SI{10}{\milli\ampere}$ of active current, this yields an average oper
|
|||
$\SI{100}{\micro\ampere}$. This value is comparable to a reasonable estimation of the current consumption of the
|
||||
monitoring circuit itself. In our prototype we used ST Microelectronics STM32 Series ARM Cortex-M microcontrollers. To
|
||||
get an estimate on the current consumption of an energy-optimized design we will refer to the datasheet of the
|
||||
\texttt{STM32L486JG}\footnote{\url{https://www.st.com/resource/en/datasheet/stm32l486jg.pdf}}, a representative member
|
||||
of ST's \texttt{STM32L4} low-power sub-family that provides hardware acceleration for AES256. A good target for an
|
||||
\partnum{STM32L486JG}\footnote{\url{https://www.st.com/resource/en/datasheet/stm32l486jg.pdf}}, a representative member
|
||||
of ST's \partnum{STM32L4} low-power sub-family that provides hardware acceleration for AES256. A good target for an
|
||||
implementation of a secure cryptographic channel on this device would be the noise protocol framework~\cite{perrin2018}.
|
||||
While the initial handshake for key establishment uses elliptic-curve cryptography and may take several hundred
|
||||
milliseconds~\cite{tschofenig2015}, the following payload data transfer messages require only symmetric cryptographic
|
||||
primitives. The \texttt{STM32L486JG} datasheet lists the microcontroller's typical operating current at around
|
||||
primitives. The \partnum{STM32L486JG} datasheet lists the microcontroller's typical operating current at around
|
||||
$\SI{8}{\milli\ampere}$ at $\SI{48}{\mega\hertz}$ clock speed, and lists a sleep current of less than
|
||||
$\SI{1}{\micro\ampere}$ in low-power standby mode with RTC enabled. The AES peripheral is listed with less than
|
||||
$\SI{2}{\micro\ampere\per\mega\hertz}$ typical current consumption. A typical high-$g$ accelerometer for an IHSM
|
||||
application would be ST Microelectronics' \texttt{H3LIS331DL}. Its
|
||||
application would be ST Microelectronics' \partnum{H3LIS331DL}. Its
|
||||
datasheet\footnote{\url{https://www.st.com/resource/en/datasheet/h3lis331dl.pdf}} lists a typical current consumption
|
||||
between $\SI{10}{\micro\ampere}$ in low-power mode with output sampling rate up to $\SI{10}{\hertz}$ and
|
||||
$\SI{300}{\micro\ampere}$ in normal operating mode with output sampling rate up to $\SI{1}{\kilo\hertz}$. Given the low
|
||||
|
|
@ -817,14 +817,14 @@ Besides power transfer from stator to rotor, we need a reliable, bidirectional d
|
|||
low-latency heartbeat signal. We chose to transport an $\SI{115}{\kilo\baud}$ UART signal through a simple IR link for a
|
||||
quick and robust solution. The link's transmitter directly drives a standard narrow viewing angle IR led through a
|
||||
transistor. The receiver has an IR PIN photodiode reverse-biased at $\frac{1}{2}V_\text{CC}$ feeding into an
|
||||
\texttt{MCP6494} general purpose opamp configured as an $\SI{100}{\kilo\ohm}$ transimpedance amplifier. As shown in
|
||||
\partnum{MCP6494} general purpose opamp configured as an $\SI{100}{\kilo\ohm}$ transimpedance amplifier. As shown in
|
||||
Figure \ref{photolink_schematic}, the output of this TIA is amplified one more time before being squared up by a
|
||||
comparator. Our design trades off stator-side power consumption for a reduction in rotor-side power consumption by
|
||||
using a narrow-angle IR led and photodiode on the rotor, and wide-angle components at a higher LED current on the
|
||||
stator. Figure~\ref{ir_tx_schema} shows the physical arrangement of both links. The links face opposite one another and
|
||||
are shielded from one another by the motor's body in the center of the PCB.
|
||||
|
||||
% We used an \texttt{MCP6494} quad CMOS op-amp. At a specified $\SI{2}{\milli\ampere}$ current
|
||||
% We used an \partnum{MCP6494} quad CMOS op-amp. At a specified $\SI{2}{\milli\ampere}$ current
|
||||
% consumption it is within our rotor's power budget, and its Gain Bandwidth Product of $\SI{7.5}{\mega\hertz}$ yields a
|
||||
% useful transimpedance in the photodiode-facing TIA stage.
|
||||
|
||||
|
|
@ -864,7 +864,7 @@ Our prototype IHSM uses a motor controller intended for use in RC quadcopters. I
|
|||
control this motor controller through an RC servo tester. In our experiments we externally measured the device's speed
|
||||
of rotation using a magnet fixed to the rotor and a reed switch held close. The reed switch output is digitized using an
|
||||
USB logic analyzer at a sample rate of $\SI{100}{\mega\hertz}$. We calculate rotation frequency as a
|
||||
$\SI{1}{\second}$ running average over debounced interval lengths of this captured signal\footnote{A regular frequency
|
||||
$\SI{1}{\second}$ running average over interval lengths of the debounced captured signal\footnote{A regular frequency
|
||||
counter or commercial tachometer would have been easier, but neither was available in our limited COVID-19 home office
|
||||
lab.}.
|
||||
|
||||
|
|
@ -962,7 +962,7 @@ allow the construction of devices secure against a wide range of practical attac
|
|||
specialized tools. The rotating mesh allows longitudinal gaps, which enables new applications that are impossible with
|
||||
traditional HSMs. Such gaps can be used to integrate a fan for air cooling into the HSM, allowing the use of powerful
|
||||
computing hardware inside the HSM. We hope that this simple construction will stimulate academic research into (more)
|
||||
secure hardware. We have published all design artifacts of our PoC online, please refer to Appendix~\ref{sec_repo} for
|
||||
secure hardware. We published all design artifacts of our PoC online, please refer to Appendix~\ref{sec_repo} for
|
||||
details. The next steps towards a practical application of our design will be to design a manufacturable stator/rotor
|
||||
interface with inductive power and data transfer integrated into the motor's magnetics and a custom motor driver tuned
|
||||
for the application that is able to precisely measure both angular velocity and winding current for an added degree of
|
||||
|
|
|
|||
|
|
@ -43,33 +43,37 @@
|
|||
\subtitle{Changes of Major Revision compared to version submitted to TCHES 21/4}
|
||||
\maketitle
|
||||
|
||||
This document lists the requested revisions we identified from the reviewers comments and explains how we adressed these
|
||||
requests.
|
||||
We again wish to express our deep gratitude for the reviewers' profound insights and valuable feedback in the TCHES 21/4
|
||||
review round. After the program committee's ``major revision'' decision we have reflected upon our submission with the
|
||||
new insights we have gained from the reviewers' comments. In the remainder of this document, we will list the requested
|
||||
changes that we have identified from the reviewers' helpful comments and explain how we adressed these requests in the
|
||||
enclosed major revision of our submission. We hope that by extensively reworking our initial submission we have improved
|
||||
it to the satisfaction of the reviewers and program committee.
|
||||
|
||||
\paragraph{Lack of discussion of operational constraints.}
|
||||
|
||||
As pointed out by Reviewer~B, our initial submission lacked a detailed discussion of the operational constraints of
|
||||
Inertial Hardware Security Modules. We have adressed this with more than two pages of new content on the operation of
|
||||
IHSMs in the new Sections~3.5 ``Long-Term Operation'' and~3.6 ``Transportation''. In these sections we address the
|
||||
reviewers' points on the continuous power supply requirement and go into detail on the likelihood of spurious tamper
|
||||
alarms triggered by external vibrations. Section~3.5 also addressses Reviewer~B's comments on failover, backup and
|
||||
replication of cryptographic secrets.
|
||||
As pointed out by Reviewers~A and~B, our initial submission lacked a detailed discussion of the operational constraints of
|
||||
Inertial Hardware Security Modules. We thank the reveiwer for this helpful observation. We have adressed this with more
|
||||
than two pages of new content on the operation of IHSMs in the new Sections~3.5 ``Long-Term Operation'' and~3.6
|
||||
``Transportation''. In these sections we address the reviewers' points on the continuous power supply requirement and go
|
||||
into detail on the likelihood of spurious tamper alarms triggered by external vibrations. Section~3.5 also addresses
|
||||
Reviewer~B's comments on failover, backup and replication of cryptographic secrets.
|
||||
|
||||
\paragraph{Lack of discussion of improved cooling capabilities of IHSMs compared to traditional HSMs.}
|
||||
|
||||
As Reviewer~D pointed out, our initial submission alluded to the possibility of facilitating cooling airflow through an
|
||||
IHSM's security mesh and noted that this would allow for greater processing capabilities, but did not go into detail on
|
||||
the extent of this effect. In our revised paper, we have extended Section~3.4 ``Mechanical Layout'' with an
|
||||
order-of-magnitude estimation of this effect based on real-world benchmarks and information available from vendors of
|
||||
traditional HSMs.
|
||||
the extent of this effect. To address this valid remark, in our revised paper, we have extended Section~3.4 ``Mechanical
|
||||
Layout'' with an order-of-magnitude estimation of this effect based on real-world benchmarks and information available
|
||||
from vendors of traditional HSMs.
|
||||
|
||||
\paragraph{Mechanical Rotating Stage Attacks.}
|
||||
|
||||
As pointed out by Reviewer~D, in our original submission our discussion of the Swivel Chair Attack discusses attacks by
|
||||
by a rotating human attacker in depth and mentions the possibility of a fully mechanized attack robot. However, our
|
||||
initial submission did not go into detail on the constraints of such a fully mechanized attack. In our revised paper we
|
||||
have completed our discussion in this section with one half page of new content and one new diagram discussing
|
||||
fully mechanized attack robots.
|
||||
initial submission did not go into detail on the constraints of such a fully mechanized attack. We are grateful to the
|
||||
reviewer for pointing out the lack of detail in this regard. In our revised paper we have completed our discussion in
|
||||
this section with one half page of new content and one new diagram discussing fully mechanized attack robots.
|
||||
|
||||
\paragraph{Comparison of IHSM attacks to those on traditional HSMs.}
|
||||
|
||||
|
|
@ -80,15 +84,17 @@ response, we have significantly extended Section~4 ``Attacks'' with one page of
|
|||
reader.
|
||||
|
||||
\paragraph{Notes on future work.}
|
||||
|
||||
Reviewer~D stated that they would find an outlook on the next design steps towards a practically usable design
|
||||
interesting. We have adressed this at the end of Section~7 ``Conclusion'' to the extent of our current plans.
|
||||
|
||||
\paragraph{Design Artifact Availability.}
|
||||
Reviewer~D state that acceess to design artifacts would be useful for readers of the paper. While we cannot make our
|
||||
|
||||
Reviewer~D stated that acceess to design artifacts would be useful for readers of the paper. While we cannot make our
|
||||
design artifacts available as part of the peer review process as they contain a multitude of references to the
|
||||
identities of the authors and their employer, we have added a brief appendix that in the publication version of our
|
||||
paper will contain a link to the open-source repository containing all hardware, software and paper sources relating to
|
||||
our research project.
|
||||
identities of the authors and their employer, we have added a brief appendix that the publication version of our
|
||||
paper will contain with a link to the open-source repository containing all hardware, software and paper sources
|
||||
relating to our research project.
|
||||
|
||||
\paragraph{Detailed discussion of contactless attacks.}
|
||||
|
||||
|
|
@ -101,8 +107,8 @@ it can provide to its payload.
|
|||
|
||||
\paragraph{Justification of mesh monitor power consumption estimates.}
|
||||
|
||||
A point noted by Reviewer~B is that in our initial submission we provided an estimate on the current consumption of an
|
||||
IHSM monitoring cirucit without providing a detailed justification of our estimate. In response, we have extended
|
||||
Section~5.3 ``Power transmission from Stator to rotor'' with a more detailed justification of this estimate.
|
||||
A point noted by Reviewers~A and~B is that in our initial submission we provided an estimate on the current consumption
|
||||
of an IHSM monitoring cirucit without providing a detailed justification of our estimate. In response, we have extended
|
||||
Section~5.3 ``Power transmission from stator to rotor'' with a more detailed justification of this estimate.
|
||||
|
||||
\end{document}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue