Some more minor changes for submission

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}