diff options
Diffstat (limited to 'paper')
| -rw-r--r-- | paper/Makefile | 14 | ||||
| -rw-r--r-- | paper/ihsm_paper.tex | 17 | ||||
| -rw-r--r-- | paper/tches-22-01-changes.tex | 3 |
3 files changed, 23 insertions, 11 deletions
diff --git a/paper/Makefile b/paper/Makefile index 285d184..051e628 100644 --- a/paper/Makefile +++ b/paper/Makefile @@ -12,13 +12,25 @@ DIFF_VERSION ?= v2.0 main_tex ?= ihsm_paper brief_tex ?= ihsm_tech_report +sub_stem ?= cant-touch-this-ihsm-paper VERSION_STRING := $(shell git describe --tags --long --dirty) all: ${main_tex}.pdf ${brief_tex}.pdf +.PHONY: submission-outputs +submission: diff cover-letter ${main_tex}.pdf + cp ${main_tex}.pdf ${sub_stem}-${VERSION_STRING}.pdf + cp ${main_tex}_diff.pdf ${sub_stem}-${VERSION_STRING}-diff.pdf + cp tches-22-01-changes.pdf ${sub_stem}-${VERSION_STRING}-cover-letter.pdf + rm -f ${sub_stem}-${VERSION_STRING}-supplementary.zip + zip -r ${sub_stem}-${VERSION_STRING}-supplementary.zip ${sub_stem}-${VERSION_STRING}-diff.pdf ${sub_stem}-${VERSION_STRING}-cover-letter.pdf + +.PHONY: cover-letter +cover-letter: tches-22-01-changes.pdf + .PHONY: diff -diff: ihsm_paper_diff.pdf +diff: ${main_tex}_diff.pdf ihsm_paper_diff.tex: ihsm_paper.tex ihsm.bib python3 diffinator.py $^ $(DIFF_VERSION) > $@ diff --git a/paper/ihsm_paper.tex b/paper/ihsm_paper.tex index 024ca1f..851da46 100644 --- a/paper/ihsm_paper.tex +++ b/paper/ihsm_paper.tex @@ -393,7 +393,7 @@ based on general-purpose computer hardware and allow for state-of-the-art databa without first porting them to an embedded operating system or foreign CPU architecture. A practical example of this approach is a 2019 technology demonstration~\cite{signal2019} created by the signal.org, the organization running the signal secure messenger app. In this demonstration, signal.org have implemented the Raft consensus -algorithm~\cite{ongaro2019} inside Intel SGX to replicate state between redundant instances. +algorithm~\cite{ongaro2019} inside Intel SGX to replicate state between geographically redundant enclaves. Excluding natural disasters there are three main categories of challenges to an IHSM's longevity: Failure of components of the IHSM due to age and wear, failure of the external power supply and spurious triggering of the intrusion alarm by @@ -772,7 +772,7 @@ $\SI{100}{\kilo\baud}$, a transmission of a one-byte message in standard UART fr $\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}$. 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 +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 @@ -787,15 +787,15 @@ 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 +amount of data that has to be processed in our application (hundreds of bytes per second), 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 -proof of concept prototype we decided against using a battery to reduce rotor mass and balancing issues. +This annual energy consumption is close to the capacity of a single CR123A lithium primary cell. By either using several +such cells or by optimizing power consumption, several years of battery life could easily be reached. In our proof of +concept prototype we decided against using a battery to reduce rotor mass and avoid balancing issues. We also decided against mechanically complex solutions such as slip rings or electronically complex ones such as inductive power transfer. Instead, we chose a simple setup consisting of a stationary lamp pointing at several solar @@ -976,10 +976,9 @@ monitor PCB as well as firmware and data analysis scripts for the experiments we digital artifacts as well as the sources to this paper are included in the git repository linked below. \center{ - \center{This is version \texttt{\input{version.tex}\unskip} of this paper, generated on \today. The git repository - can be found at:} - \center{\censorIfSubmission{\url{https://git.jaseg.de/rotohsm.git}}} + + \center{This is version \texttt{\input{version.tex}\unskip} of this paper, generated on \today.} } \end{document} diff --git a/paper/tches-22-01-changes.tex b/paper/tches-22-01-changes.tex index 4623678..f9fc758 100644 --- a/paper/tches-22-01-changes.tex +++ b/paper/tches-22-01-changes.tex @@ -52,7 +52,8 @@ As pointed out by Reviewer~B, our initial submission lacked a detailed discussio 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. +alarms triggered by external vibrations. Section~3.5 also addressses 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} |