Work on changes letter

paper/ihsm.bib

@@ -423,4 +423,22 @@
     urldate = {2021-07-12},
 }
 
+@WWW{perrin2018,
+    title = {The Noise Protocol Framework},
+    author = {Trevor Perrin},
+    url = {http://noiseprotocol.org/noise.html},
+    version = {Revision 34},
+    urldate = {2021-07-13},
+    date = {2018-07-11},
+}
+
+@InProceedings{tschofenig2015,
+    booktitle = {NIST Lightweight Cryptography Workshop 2015},
+    author = {Hannes Tschofenig and Manuel Pegourie-Gonnard and Hugo Vincent},
+    url = {https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/presentations/session7-vincent.pdf},
+    urldate = {2021-07-13},
+    title = {Performance of State-of-the-Art Cryptography on ARM-based Microprocessors},
+    date = {2015-07-21},
+}
+
 @Comment{jabref-meta: databaseType:biblatex;}

paper/ihsm_paper.tex

@@ -771,8 +771,27 @@ tamper status to the static monitoring circuit at least once every $T_\text{tx}
 $\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.
+$\SI{100}{\micro\ampere}$.  This value is comparable to a reasonable estimation of the current consumption of the
+monitoring cirucit 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
+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
+$\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
+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
+amount of data (hundreds of bytes per second) that has to be processed in our application, if we assume a duty cycle of
+$\SI{1}{\percent}$ of active data processing vs.\ sleep mode at the given clock speed we arrive at a total estimated
+current consumption of our microcontroller of less than $\SI{100}{\micro\ampere}$.  Thus, reserving
+$\SI{100}{\micro\ampere}$ for the monitoring circuit on top of the $\SI{100}{\micro\ampere}$ for the transceiver circuit
+we arrive at an energy consumption of $\SI{1.7}{\ampere\hour}$ per year.
 
 This annual energy consumption is close to the capacity of a single CR123A lithium primary cell. Thus, by either using
 several such cells or by optimizing power consumption several years of battery life could easily be reached.  In our

paper/tches-22-01-changes.tex

@@ -0,0 +1,106 @@
+\documentclass[a4paper]{scrartcl}
+\usepackage[T1]{fontenc}
+\usepackage{amssymb,amsmath}
+\usepackage{eurosym}
+\usepackage{wasysym}
+\usepackage{amsthm}
+\usepackage{censor}
+\usepackage[
+    backend=biber,
+    style=numeric,
+    natbib=true,
+    url=false, 
+    doi=true,
+    eprint=false
+    ]{biblatex}
+\addbibresource{ihsm.bib}
+
+
+\makeatletter
+\@ifclasswith{iacrtrans}{submission}{
+    \newcommand{\censorIfSubmission}[1]{\censor{#1}{\scriptsize[Author information removed for double-blind peer review]}}
+}{
+    \newcommand{\censorIfSubmission}[1]{#1}
+}
+\makeatother
+
+\usepackage[binary-units]{siunitx}
+\DeclareSIUnit{\baud}{Bd}
+\DeclareSIUnit{\year}{a}
+\usepackage{commath}
+\usepackage{graphicx,color}
+\usepackage{subcaption}
+\usepackage{array}
+\usepackage{hyperref}
+
+\renewcommand{\floatpagefraction}{.8}
+\newcommand{\degree}{\ensuremath{^\circ}}
+\newcolumntype{P}[1]{>{\centering\arraybackslash}p{#1}}
+\newcommand{\partnum}[1]{\texttt{#1}}
+
+\begin{document}
+\title{Can't Touch This: Inertial HSMs Thwart Advanced Physical Attacks}
+\subtitle{Changes of Major Revision compared to version submitted to TCHES 20/4}
+\maketitle
+
+This document lists the requested revisions we identified from the reviewers comments and explains how we adressed these
+requests.
+
+\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''.
+% FIXME
+
+\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.
+
+\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.
+
+\paragraph{Comparison of IHSM attacks to those on traditional HSMs}
+
+In addition to the previous point, Reviewer~D pointed out that the discussion of attacks on IHSMs in our initial
+submission would have benefited from a more thorough contextualization of the attacks possible on traditional HSMs. In
+response, we have significantly extended Section~4 ``Attacks'' with one page of new content in two new Subsections~4.2
+``Attacks that don't work'' and~4.3 ``Attacks that work on any HSM'' that provide this missing context to guide the
+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
+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.
+
+\paragraph{Detailed discussion of contactless attacks}
+
+Reviewer~C noted that like a traditional HSM an IHSM cannot prevent contactless attacks such as electromagnetic
+sidechannel attacks or laser fault injection. While our initial submission acknowledged this property of our design, our
+original submission did not provide a detailed discussion of its extent. In our revised paper, we have added a new
+Section~4.2 ``Attacks that work on any HSM'' that provides more detail on contactless attacks. In this section we
+observe that the IHSM design allows for some mitigations against contactless attacks due to the physically larger space
+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.
+
+\end{document}