jaseg/ihsm
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Some more minor changes for submission

Browse source
This commit is contained in:
jaseg 2021-07-13 15:28:55 +02:00
parent 61f4b840bc
commit f08eea06ee
3 changed files with 23 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

14
paper/Makefile
View file

@ -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) > $@

17
paper/ihsm_paper.tex
View file

@ -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}

3
paper/tches-22-01-changes.tex
View file

@ -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}