diff options
author | jaseg <git@jaseg.de> | 2021-07-13 13:25:03 +0200 |
---|---|---|
committer | jaseg <git@jaseg.de> | 2021-07-13 13:25:03 +0200 |
commit | f14b83d06412aad735d985a6d7cd4595d20f83b8 (patch) | |
tree | fd7ed1ace79fae59b9de795f20eb6ab603821ffc | |
parent | 2bed326dca70f04fe4e852431aeda18c52d77e45 (diff) | |
download | ihsm-f14b83d06412aad735d985a6d7cd4595d20f83b8.tar.gz ihsm-f14b83d06412aad735d985a6d7cd4595d20f83b8.tar.bz2 ihsm-f14b83d06412aad735d985a6d7cd4595d20f83b8.zip |
Work on changes letter
-rw-r--r-- | paper/ihsm.bib | 18 | ||||
-rw-r--r-- | paper/ihsm_paper.tex | 23 | ||||
-rw-r--r-- | paper/tches-22-01-changes.tex | 106 |
3 files changed, 145 insertions, 2 deletions
diff --git a/paper/ihsm.bib b/paper/ihsm.bib index 9e69037..d19b432 100644 --- a/paper/ihsm.bib +++ b/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;} diff --git a/paper/ihsm_paper.tex b/paper/ihsm_paper.tex index de94ea2..024ca1f 100644 --- a/paper/ihsm_paper.tex +++ b/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 diff --git a/paper/tches-22-01-changes.tex b/paper/tches-22-01-changes.tex new file mode 100644 index 0000000..7857125 --- /dev/null +++ b/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} |