From 5af08604d7a54441ad757f4ab9f550c54deb6ce9 Mon Sep 17 00:00:00 2001 From: jaseg Date: Wed, 16 Sep 2020 13:08:38 +0200 Subject: Initial commit --- quick-tech-report/.gitignore | 10 ++ quick-tech-report/Makefile | 36 +++++ quick-tech-report/rotohsm_tech_report.bib | 0 quick-tech-report/rotohsm_tech_report.tex | 222 ++++++++++++++++++++++++++++++ 4 files changed, 268 insertions(+) create mode 100644 quick-tech-report/.gitignore create mode 100644 quick-tech-report/Makefile create mode 100644 quick-tech-report/rotohsm_tech_report.bib create mode 100644 quick-tech-report/rotohsm_tech_report.tex diff --git a/quick-tech-report/.gitignore b/quick-tech-report/.gitignore new file mode 100644 index 0000000..c49262e --- /dev/null +++ b/quick-tech-report/.gitignore @@ -0,0 +1,10 @@ +*.out +*.bbl +*.aux +*.toc +*.blg +*.bcf +*.log +*.run.xml + +version.tex diff --git a/quick-tech-report/Makefile b/quick-tech-report/Makefile new file mode 100644 index 0000000..259f303 --- /dev/null +++ b/quick-tech-report/Makefile @@ -0,0 +1,36 @@ + +LAB_PATH ?= ../lab-windows + +SHELL := bash +.ONESHELL: +.SHELLFLAGS := -eu -o pipefail -c +.DELETE_ON_ERROR: +MAKEFLAGS += --warn-undefined-variables +MAKEFLAGS += --no-builtin-rules + +main_tex ?= rotohsm_tech_report + +VERSION_STRING := $(shell git describe --tags --long --dirty) + +all: ${main_tex}.pdf + +%.pdf: %.tex %.bib version.tex + pdflatex -shell-escape $< + biber $* + pdflatex -shell-escape $< + +.PHONY: preview +preview: + pdflatex -shell-escape ${main_tex}.tex + +version.tex: ${main_tex}.tex ${main_tex}.bib + echo "${VERSION_STRING}" > $@ + +resources/%.pdf: $(LAB_PATH)/%.ipynb + jupyter-nbconvert --to=pdf --output-dir=resources --output=$* --LatexExporter.template_file=resources/nbexport.tplx $^ + +.PHONY: clean +clean: + rm -f ${main_tex}.aux ${main_tex}.bbl ${main_tex}.bcf ${main_tex}.log ${main_tex}.blg + rm -f ${main_tex}.out ${main_tex}.run.xml texput.log + diff --git a/quick-tech-report/rotohsm_tech_report.bib b/quick-tech-report/rotohsm_tech_report.bib new file mode 100644 index 0000000..e69de29 diff --git a/quick-tech-report/rotohsm_tech_report.tex b/quick-tech-report/rotohsm_tech_report.tex new file mode 100644 index 0000000..f37b572 --- /dev/null +++ b/quick-tech-report/rotohsm_tech_report.tex @@ -0,0 +1,222 @@ +\documentclass[12pt,a4paper]{article} +\usepackage[english]{babel} +\usepackage[utf8]{inputenc} +\usepackage[T1]{fontenc} +\usepackage[ + backend=biber, + style=numeric, + natbib=true, + url=false, + doi=true, + eprint=false + ]{biblatex} +\addbibresource{rotohsm.bib} +\usepackage{amssymb,amsmath} +\usepackage{listings} +\usepackage{eurosym} +\usepackage{wasysym} +\usepackage{amsthm} +\usepackage{tabularx} +\usepackage{multirow} +\usepackage{multicol} +\usepackage{tikz} +\usepackage{mathtools} +\DeclarePairedDelimiter{\ceil}{\lceil}{\rceil} +\DeclarePairedDelimiter{\paren}{(}{)} + +\usetikzlibrary{arrows} +\usetikzlibrary{chains} +\usetikzlibrary{backgrounds} +\usetikzlibrary{calc} +\usetikzlibrary{decorations.markings} +\usetikzlibrary{decorations.pathreplacing} +\usetikzlibrary{fit} +\usetikzlibrary{patterns} +\usetikzlibrary{positioning} +\usetikzlibrary{shapes} + +\usepackage[binary-units]{siunitx} +\DeclareSIUnit{\baud}{Bd} +\usepackage{hyperref} +\usepackage{tabularx} +\usepackage{commath} +\usepackage{graphicx,color} +\usepackage{ccicons} +\usepackage{subcaption} +\usepackage{float} +\usepackage{footmisc} +\usepackage{array} +\usepackage[underline=false]{pgf-umlsd} +\usetikzlibrary{calc} +%\usepackage[pdftex]{graphicx,color} +\usepackage{epstopdf} +\usepackage{pdfpages} +\usepackage{minted} % pygmentized source code + +\renewcommand{\floatpagefraction}{.8} +\newcommand{\degree}{\ensuremath{^\circ}} +\newcolumntype{P}[1]{>{\centering\arraybackslash}p{#1}} + +\usepackage{fancyhdr} +\fancyhf{} +\fancyfoot[C]{\thepage} +\newcommand{\includenotebook}[2]{ + \fancyhead[C]{Included Jupyter notebook: #1} + \includepdf[pages=1, + pagecommand={\thispagestyle{fancy}\section{#1}\label{#2_notebook}} + ]{resources/#2.pdf} + \includepdf[pages=2-, + pagecommand={\thispagestyle{fancy}} + ]{resources/#2.pdf} +} + +\begin{document} + +\title{A High-Security Physical Security Primitive Based On Mechanical Movement} +\author{Jan Götte} +\date{2020-09-15} +\maketitle + +\section{Abstract} +In this paper, we introduce a novel, highly effective countermeasure against physical attacks: Inertial hardware +security modules. Whereas conventional technology can be categorized into systems monitoring a thin boundary (such as +security meshes) and systems monitoring the interior volume (such as the "enclosure PUF" of Tobisch et al.). What all of +these systems have in common is that they try to detect attacks by crafting sensors responding to increasingly minute +manipulations of the monitored medium. Our approach is novel in that we alleviate the sensitivity requirement of a +security mesh by increasing the complexity of any manipulation at all by orders of magnitude by fastly rotating the +security mesh--presenting a moving target to an attacker. Attempts to modify the rotation itself are easily monitored +with commercial MEMS accelerometers and gyroscopes. + +Our approach leads to a HSM that can easily be built from off-the-shelf parts by any university electronics lab, yet is +as secure or more secure than even the best commercial offerings. + +\section{Introduction} +Since the early days of computers, physical security has often been a core component of any computer system's security +architecture. Physical security in fact predates our modern concept of computer security by decades. Long before +passwords, access control lists, role-based authentication and other modern concepts of information security were +developed, information was secured by physically locking away the computers that held it. + +Nowadays, concerns of physical security are mostly limited to certain applications. Credit card processing and medical +data processing are two instances where a combination of smartcards and hardware security modules is used to provide a +higher level of security than what ordinary computers can provide. Meanwhile, in most commercial data processing +applications, the physical security provided by an average datacenter is considered to be appropriate. + +In modern systems, phyiscal security always is tightly interwoven with the system's overall security architecture. +Beyond the level provided by locks and guards, it is generally considered infeasible to physically secure all parts of a +computer. High-level physical security is usually limited to either a single chip or part of a chip such as a secure +element, enclave or smartcards--or it is limited to a small module acting within a very limited scope, as is the case in +commercial HSMs that largely act as cryptographic co-processors with built-in key management functions. + +\subsection{Technical approaches to physical security} +The use of chips as secure elements has recently become popular beyond the smartcards of yesteryear. Apple has carried +over a secure enclave IC from their line of phones into their line of laptops in 2016. Likewise, Google has developed +its own security IC for use in phones and laptops. An issue to consider with all such IC-based security solutions is +that they do not provide any cryptographic security. The real-world security of these solutions solely rests on the +assumption that due to their fine structure, ICs are hard to reverse engineer and manipulate. As of now, this property +holds and in the authors' opinion it will likely be a reasonable assumptions for some years to come. However, in its +essence this is a type of security by obscurity: Obscurity here mostly applying to the rarity of tools that are +necessary for practical attacks such as focused ion beam workstations and accompanying sample preparation equipment. An +important observation in this regard is that already, several people are slowly chipping away at this obscurity: A group +at Ruhr University Bochum is working on advanced tooling for netlist reverse engineering, and there are several +companies offering commercial IC reverse engineering services. + +\subsection{Hardware Security Modules} +At larger physical dimensions, hardware security modules (HSMs) provide an effective solution to the problem: In +conformity with Kerckhoff's principle, their creators do not try to hide the structure of the system within. Instead, +the HSM monitors it for any manipulation and wipes all key material when one is detected. The most common commercial +realization of this is what we call a "boundary-monitoring" HSM. This is a device uses a microcontroller monitoring the +conductivity of usually two electrical traces that are folded many times to cover the entire area of a plastic enclosure +part or a plastic foil wrapped around the module. The security problem thus gets transformed into a manufacturing +challenge: How fine can these traces be made--so they are disturbed by even the tiniest of holes for say, a fine needle; +and how sensitive can they be made to perturbations--so they break from even gentle attempts at mechanical, chemical or +other physical manipulation. + +The other type of HSM that so far has garnered mostly academic interest are what we call "volumetric" HSMs. Where a +boundary-monitoring HSM senses disturbations to a thin boundary between its inside and the outside world, a volumetric +HSM monitors its entire interior volume. Approaches that have been proposed so far include monitoring using +electromagnetic radiation % FIXME: citation (paper1 (this chip thing w/ distributed PAs/LNAs), paper2 (RUB) +and ultrasonic sensing. % FIXME: citation +Common to both approaches is that for technical reasons the wavelength of the employed radiation is in the range of +millimeters or larger. This implies that practical attacks acting on a smaller scale of physical size require sensitive +monitoring circuity to be reliably caught. % FIXME maybe talk to a physicist here. +Since they require advanced transceivers and signal processing, these HSMs incur a high implementation cost compared to +one based on a traditional security mesh, while they in turn promise to be easier and less expensive to scale in +physical size. A severe problem with any previous volumetric designs is that their security analysis is very hard. While +multiple designs have been proposed academically, none of these proposals include an analysis of their physical security +properties that goes beyond guesswork. %FIXME verify this. +The obvious reason for this is that to evaluate the volume inside the HSM that is covered by a given transceiver +combination and a given test signal pattern necessarily requires numerically solving the volumetric electromagnetic +field equations inside the HSM, applying a model of transmitter and receiver to the results that takes into account +receiver sensitivity and ADC resolution, transmitter power and receiver saturation effects and then validating that +every point in space (or at least inside a boundary region) is covered. While the guess that attacks are impractical +might still be true this would be based on the fact that the same problem presents itself to an attacker trying to +circumvent these measures--degrading their security to simple obscurity again. + +\subsection{A new approach to physical security} +We are certain that there is still much work to be done and many insights to be gained from further explorations +of the two concepts described above. Trivially, consider a box with mirrored walls that, suspended on thin wires, +contains a smaller box that has cameras looking outward in all directions at the mirrored walls. Given that the defender +can control lighting conditions inside this kaleidoscopic box in this application modern cameras can be considered +equivalent to or better than the human eye. Thus, a successful physical attack on this system would likely an +"invisibility cloaks"--and the system would remain secure as long as no such thing exists. This example is a useful +point of reference. To be viable, a HSM technology must be either smaller or more sensitive than such a setup. + +The candidate we wish to introduce in this paper uses a novel approach to side-step the issues of both the concepts +introduced in the previous section and provides radically better security against physical attacks--both in theory and +in practice. + +Our core observation is that given any less expensive but more coarse HSM technology, we can make it radically more +difficult to attack by introducing fast mechanical motion. As a trivial example, consider a HSM as it is used in +ecommerce applications for credit card payments. Focusing on its main defense for simplicity, its physical security is +limited by the structure size of the mesh that is likely used in its shell. If an attacker can tap the mesh's electrical +traces and bridge across the mesh in a way the HSM cannot detect (e.g. by making sure the bridge has the same electrical +impedance as the mesh traces have e.g. by comparing against another device of the same type), they have circumvented the +device's protections. Any such attack would likely involve some fine drill bits, needles, wires, glue, perhaps solder or +even lasers. + +Now consider the same HSM, but this time mounted on a large flywheel. In this scenario the HSM uses the same +protections as before, but is now additionally equipped with an accelerometer that it uses to verify that it is in fact +rotating at a very high speed. How would an attacker approach this HSM? They would have to either slow down the rotation +(which would quickly be sensed by the accelerometer) or they would have to attack the moving HSM--the HSM literally +becomes a moving target. While rotating the entire attack workbench might be possible for slow speeds, rotating frames +of reference quickly become inhospitable to human life and at some point the technical means to rotate a CNC attack +robot probably weighing several kilograms become inconvenient as well. Contact-less EM or optical attacks are more +limited in the first place, and can effectively be shielded. + +\section{Related work} +% summaries of research papers on HSMs. +% I have not found any actual prior art on anything involving mechanical motion beyond ultrasound. + +\section{The physics of hardware security} +% approaching the issue from measurable quantities +\section{Intertial HSMs} +\section{Hardware prototype} +\section{Future work} +\subsection{Other modes of movement} +\subsection{Multiple axes of rotation} +\subsection{Means of power transmission} +\subsection{Other sensing modes} +\subsection{Longeivity} +\section{Conclusion} + +\printbibliography[heading=bibintoc] +\appendix +\section{License} +{\center{ +\begin{minipage}[t][10cm][b]{\textwidth} + \center{\ccbysa} + + \center{This work is licensed under a Creative-Commons ``Attribution-ShareAlike 4.0 International'' license. The + full text of the license can be found at:} + + \center{\url{https://creativecommons.org/licenses/by-sa/4.0/}} + + \center{For alternative licensing options, source files, questions or comments please contact the authors.} + + \center{This is version \texttt{\input{version.tex}\unskip} generated on \today. The git repository can be found at:} + + \center{\url{https://git.jaseg.de/rotohsm.git}} +\end{minipage} +}} + +\end{document} -- cgit From 704bdcfe3bba7475f49bb99c0a885976640bf218 Mon Sep 17 00:00:00 2001 From: jaseg Date: Thu, 17 Sep 2020 13:08:19 +0200 Subject: Add contributions section --- quick-tech-report/rotohsm_tech_report.tex | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/quick-tech-report/rotohsm_tech_report.tex b/quick-tech-report/rotohsm_tech_report.tex index f37b572..2de3c29 100644 --- a/quick-tech-report/rotohsm_tech_report.tex +++ b/quick-tech-report/rotohsm_tech_report.tex @@ -183,6 +183,17 @@ of reference quickly become inhospitable to human life and at some point the tec robot probably weighing several kilograms become inconvenient as well. Contact-less EM or optical attacks are more limited in the first place, and can effectively be shielded. +\subsection{Contributions} +This work contains the following contributions: +\begin{enumerate} + \item Presentation of the \emph{Inertial HSM} concept, allowing cost-effective prototype and small-scale production + of highly secure HSMs. + \item Discussion of possible boundary sensing modes in the intertial HSM model. + \item Exploration of the design space of inertial HSMs. + % FIXME \item Presentation of a prototype inertial HSM. + % FIXME \item Measurement of the prototype HSM's susceptibility to various types of attack. +\end{enumerate} + \section{Related work} % summaries of research papers on HSMs. % I have not found any actual prior art on anything involving mechanical motion beyond ultrasound. @@ -190,13 +201,16 @@ limited in the first place, and can effectively be shielded. \section{The physics of hardware security} % approaching the issue from measurable quantities \section{Intertial HSMs} -\section{Hardware prototype} \section{Future work} \subsection{Other modes of movement} \subsection{Multiple axes of rotation} \subsection{Means of power transmission} \subsection{Other sensing modes} \subsection{Longeivity} + +\section{Hardware prototype} +% FIXME + \section{Conclusion} \printbibliography[heading=bibintoc] -- cgit From b3a6b004be88ede776d2fb66e3dfc83cff171d95 Mon Sep 17 00:00:00 2001 From: jaseg Date: Fri, 18 Sep 2020 11:14:26 +0200 Subject: Add prior art and engineering constraints --- quick-tech-report/rotohsm_tech_report.tex | 128 ++++++++++++++++++++++++++++-- 1 file changed, 121 insertions(+), 7 deletions(-) diff --git a/quick-tech-report/rotohsm_tech_report.tex b/quick-tech-report/rotohsm_tech_report.tex index 2de3c29..d2b50ad 100644 --- a/quick-tech-report/rotohsm_tech_report.tex +++ b/quick-tech-report/rotohsm_tech_report.tex @@ -152,7 +152,7 @@ every point in space (or at least inside a boundary region) is covered. While th might still be true this would be based on the fact that the same problem presents itself to an attacker trying to circumvent these measures--degrading their security to simple obscurity again. -\subsection{A new approach to physical security} +\subsection{Inertial HSMs: A new approach to physical security} We are certain that there is still much work to be done and many insights to be gained from further explorations of the two concepts described above. Trivially, consider a box with mirrored walls that, suspended on thin wires, contains a smaller box that has cameras looking outward in all directions at the mirrored walls. Given that the defender @@ -197,10 +197,119 @@ This work contains the following contributions: \section{Related work} % summaries of research papers on HSMs. % I have not found any actual prior art on anything involving mechanical motion beyond ultrasound. +In chapter 18 of the forthcoming 3rd edition of his seminal book on "Security Engineering"\cite{anderson2020}, Ross +Anderson gives a background on physical security in general and on HSMs in particular. As an example he cites the IBM +4758 HSM whose details are laid out in depth in \cite{smith1998}. This HSM is an example of an industry-standard +construction. Though it is now a bit dated, the construction techniques of the physical security mechanisms have not +changed much in the last two decades. Apart from some auxiliary temperature and radiation sensors to guard against +attacks on the built-in SRAM memory the module's main security barrier uses the traditional construction of a flexible +mesh wrapped around the module's core. In \cite{smith1998}, the authors claim the module monitors this mesh for +short circuits, open circuits and conductivity. The fundamental approach to tamper detection and construction is similar +to other commercial offerings\cite{obermaier2018}. + +In \cite{immler2019}, Immler et al. describe a HSM based on precise capacitance measurements of a mesh. In contrast to +traditional meshes, the mesh they use consists of a large number of individual traces (more than 32 in their example). +Their concept promises a very high degree of protection. The main disadvantages of their concept are a limitation in +both covered area and component height, as well as the high cost of the advanced analog circuitry required for +monitoring. A core component of their design is that they propose its use as a PUF to allow for protection even when +powered off, similar to a smart card--but the design is not limited to this use. + +In \cite{tobisch2020}, Tobisch et al.\ describe a construction technique for a hardware security module that is based +around commodity Wifi hardware inside a conductive enclosure. In their design, an RF transmitter transmits a reference +signal into the RF cavity formed by the conductive enclosure. One or more receivers listen for the signal's reflections +and use them to characterize the RF cavity w.r.t.\ phase and frequency response. Their fundamental assumption is that +the RF behavior of the cavity is inscrutable from the outside, and that even a small disturbance anywhere within the +volume of the cavity will cause a significant change in its RF response. The core idea in \cite{tobisch2020} is to use +commodity Wifi hardware to reduce the cost of the HSM's sensing circuitry. The resulting system is likely both much +cheaper and capable of protecting a much larger security envelope than e.g. the design from \cite{immler2019}, at the +cost of worse and less predictable security guarantees. + +While \cite{tobisch2020} approach the sensing frontend cost as their only optimization target, the prior work of Kreft +and Adi\cite{kreft2012} considers sensing quality. Their target is an HSM that envelopes a volume barely larger than a +single chip. They theorize how an array of distributed RF transceivers can measure the physical properties of a potting +compound that has been loaded with RF-reflective grains. In their concept, the RF response characterized by these +transceivers is shaped by the precise three-dimensional distribution of RF-reflective grains within the potting +compound. + +\subsection{Comparison to prior research} + +Our concept is truly novel in that neither academic literature, nor patent databases contain any mention of mechanical +motion being used as part of a hardware security module. Most academic research concentrates on the issue of creating +new, more sensitive security barriers for HSMs while commercial vendors concentrate on means to cheaply manufacture +these security barriers. Our concept instead focuses on the issue of taking any existing, cheap low-performance security +barrier and transforming it into a marginally more expensive but very high-performance one. The closes to a mechanical +HSM that we were able to find during our research is an 1988 patent\cite{rahman1988} that describes an mechanism to +detect tampering along a communication cable by enclosing the cable inside a conduit filled with pressurized gas. + +\section{Intertial HSM construction and operation} +\subsection{Using motion for tamper detection} +Mechanical motion has been proposed as a means of making things harder to see with the human eye\cite{haines2006} but we +seem to be the first to use it in tamper detection. Let us think about how one would go about increasing the security of +a primitive tamper detection sensor. + +\begin{enumerate} + \item We need the sensor's motion to be fairly fast. If any point of the sensor moves slow enough for a human to + follow, it becomes a weak spot. + \item We need the sensor's motion to be periodic to keep it within a reasonable space. Otherwise we could just load + our HSM on an airplane and assume that airplanes are hard to stop non-destructively mid-flight. + \item We need the sensor's motion to be very predictable so that we can detect an attacker trying to stop it. +\end{enumerate} + +From this, we can make a few observations. + +\begin{enumerate} + \item Linear motion is likely to be a poor choice since it requires a large amount of space, and it is comparatively + easy to follow something moving linearly. + \item Oscillatory motion such as linear vibration or a pendulum motion might be a good candidate, but for the + instant at its apex when the vibration reverses direction the object is stationary, which is a weak spot. + \item Rotation is a very good choice. Not only does it not require much space to execute, but also if the axis of + rotation is within the HSM itself, an attacker trying to follow the motion would have to rotate around the same + axis. Since their tangential linear velocity would rise linearly with the radius from the axis of rotation, an + assumption on tolerable centrifugal force allows one to limit the approximate maximum size and mass of an + attacker. For an HSM measuring at most a few tens of centimeters across, it is easy to build something that + rotates too fast for a human to be able to follow it. The axis of rotation is a weak spot, but this can be + alleviated by placing additional internal sensors around it and locating all sensitive parts of the sensing + circuit radially away from it. +\end{enumerate} + +Another important observation is that we do not have to move the entire contents of the HSM. It suffices if we can +somehow move the tamper detection barrier around these contents while keeping the contents stationary. This reduces the +inertial mass of the moving part and eases data communication and power supply of the payload. + +In a rotating reference frame, at any point the centrifugal force is proportional to the square of the angular frequency +and linearly proportional to the distance from the axis of rotation. We can exploit this fact to create a sensor that +detects any disturbance of the rotation by simply placing a linear accelerometer at some distance to the axis of +rotation. During constant rotation, the linear acceleration tangential to the rotation will be zero. The centrifugal +force is orthogonal to this, and will be constant as long as the angular velocity remains constant (assuming a fixed +axis of rotation). At high angular velocities, considerable forces can be created this way. This poses the engineering +challenge of preventing the whole thing from flying apart, but also creates an obstacle to any attacker trying to +manipulate the sensor. + +\subsection{Payload mounting mechanisms} +The simplest way to mount a stationary payload in a rotating security mesh is to drive the rotor through a +hollow axis. This allows the payload to be mounted on a fixed rod threaded through the hollow axis, along with wires for +power and data. + +\subsection{Rotating mesh power supply} +There are several options to transfer power to the rotor from its stationary frame. + +\begin{enumerate} + \item Slip ring contacts are a poor candidate as they are limited in their maximum speed and lifetime, and as + precision mechanical components are expensive. + \item Inductive power transfer as used in inductive charging systems can be used without modification. + \item A second brushless motor on the axis of rotation can be used as a generator, with its axis connected to the + fixed frame and its stator mounted and connected to the rotor. + \item A bright LED along with some small solar cells may be a practical approach for small amounts of energy. + \item For a very low-power security mesh, a battery specified to last for the lifetime of the device may be + practical. +\end{enumerate} + +\subsection{Rotating mesh data communication} +As we discussed above, while slip rings are the obvious choice to couple electrical signals through a rotating joint, +they are likely to be too expensive and have too short a life span for our application. Since the only information that +needs to pass between payload and rotor are the occassional status report and a high-frequency heartbeat signal that +acts as the alarm trigger, a simple optocoupler close to the axis of rotation is a good solution. -\section{The physics of hardware security} -% approaching the issue from measurable quantities -\section{Intertial HSMs} \section{Future work} \subsection{Other modes of movement} \subsection{Multiple axes of rotation} @@ -208,6 +317,12 @@ This work contains the following contributions: \subsection{Other sensing modes} \subsection{Longeivity} +\section{Attacks} +\subsection{Attacks on the rotation sensor} +\subsection{Attacks on the mesh} +\subsection{Attacks on the alarm circuitry} +\subsection{Fast and violent attacks} + \section{Hardware prototype} % FIXME @@ -216,7 +331,7 @@ This work contains the following contributions: \printbibliography[heading=bibintoc] \appendix \section{License} -{\center{ +\center{ \begin{minipage}[t][10cm][b]{\textwidth} \center{\ccbysa} @@ -231,6 +346,5 @@ This work contains the following contributions: \center{\url{https://git.jaseg.de/rotohsm.git}} \end{minipage} -}} - +} \end{document} -- cgit From 869a304aad504f54c64a8c52acd7e095deea0dfa Mon Sep 17 00:00:00 2001 From: jaseg Date: Fri, 18 Sep 2020 12:59:08 +0200 Subject: Finish first rough draft --- quick-tech-report/rotohsm.bib | 75 ++++++++++++++++++ quick-tech-report/rotohsm_tech_report.tex | 123 ++++++++++++++++++++++++++++-- 2 files changed, 191 insertions(+), 7 deletions(-) create mode 100644 quick-tech-report/rotohsm.bib diff --git a/quick-tech-report/rotohsm.bib b/quick-tech-report/rotohsm.bib new file mode 100644 index 0000000..3270c13 --- /dev/null +++ b/quick-tech-report/rotohsm.bib @@ -0,0 +1,75 @@ +% Encoding: UTF-8 + +@Book{anderson2020, + author = {Ross Anderson}, + date = {2020-09-16}, + title = {Security Engineering}, +} + +@TechReport{smith1998, + author = {Sean Smith and Steve Weingart}, + date = {1998-02-19}, + institution = {IBM T.J. Watson Research Center}, + title = {Building a High-Performance, ProgrammableSecure Coprocessor}, + url = {ftp://www6.software.ibm.com/software/cryptocards/rc21102.pdf}, + urldate = {2020-09-16}, +} + +@Article{immler2019, + author = {Vincent Immler and Johannes Obermaier and Kuan Kuan Ng and Fei Xiang Ke and Jin Yu Lee and Yak Peng Lim and Wei Koon Oh and Keng Hoong Wee and Georg Sigl}, + date = {2019}, + journaltitle = {IACR Transactions on Cryptographic Hardware and Embedded Systems}, + title = {Secure Physical Enclosures from Coverswith Tamper-Resistance}, + doi = {https://doi.org/10.13154/tches.v2019.i1.51-96}, + issn = {2569-2925}, + url = {https://tches.iacr.org/index.php/TCHES/article/view/7334/6506}, + urldate = {2020-09-16}, +} + +@Article{obermaier2018, + author = {Johannes Obermaier and Vincent Immler}, + date = {2018}, + journaltitle = {Journal of Hardware and Systems Security}, + title = {The Past, Present, and Future of Physical Security Enclosures: From Battery-Backed Monitoring to PUF-Based Inherent Security and Beyond}, + doi = {10.1007/s41635-018-0045-2}, + issn = {2509-3428}, + pages = {289-296}, + volume = {2}, + year = {2018}, +} + +@Article{tobisch2020, + author = {Johannes Tobisch and Christian Zenger and Christof Paar}, + date = {2020-03-13}, + journaltitle = {TRUDEVICE 2020: 9th Workshop on Trustworthy Manufacturing and Utilization of Secure Devices}, + title = {Electromagnetic Enclosure PUF for TamperProofing Commodity Hardware and otherApplications}, + url = {https://www.emsec.ruhr-uni-bochum.de/media/crypto/veroeffentlichungen/2020/05/13/trudevice_submission_enclosure_puf.pdf}, + urldate = {2020-09-17}, +} + +@Article{kreft2012, + author = {Heinz Kreft and Wael Adi}, + date = {2012}, + journaltitle = {2012 NASA/ESA Conference on Adaptive Hardware and Systems (AHS)}, + title = {Cocoon-PUF, a novel mechatronic secure element technology}, + doi = {10.1109/ahs.2012.6268655}, + year = {2012}, +} + +@Patent{rahman1988, + author = {Mujib Rahman}, + date = {1988-03-10}, + number = {US4859024A}, + title = {Optical fiber cable with tampering detecting means}, +} + +@WWW{haines2006, + author = {Lester Haines}, + editor = {The Register}, + date = {2006-09-25}, + title = {US outfit patents 'invisible' UAV: Stealth through persistence of vision}, + url = {https://www.theregister.com/2006/09/25/phantom_sentinel/}, + urldate = {2020-09-17}, +} + +@Comment{jabref-meta: databaseType:biblatex;} diff --git a/quick-tech-report/rotohsm_tech_report.tex b/quick-tech-report/rotohsm_tech_report.tex index d2b50ad..41938f7 100644 --- a/quick-tech-report/rotohsm_tech_report.tex +++ b/quick-tech-report/rotohsm_tech_report.tex @@ -311,28 +311,138 @@ needs to pass between payload and rotor are the occassional status report and a acts as the alarm trigger, a simple optocoupler close to the axis of rotation is a good solution. \section{Future work} +With this paper, we intend to spread the word on our idea. Thus, below we include a selection of the open questions we +are currently working on. If you wish to tackle some of these, please feel free to contact the authors. + \subsection{Other modes of movement} +Though we decided to use rotation as an easy-to-implement yet secure option, other modes of movement bear promise as +well. Particularly for less high-security applications without strict space constraints, a variant based on a pendulum +motion may be worth investigating as it would simplify the mechanical construction. Power and data transfer to the +moving part could simply be done with very flexible cables. + \subsection{Multiple axes of rotation} +One option to alleviate the weak spot a rotating mesh has at its axis of rotation, a system with two or more axes of +rotation could be used. A single mesh would still suffice in this case, but when evaluating accelerometer readings, the +braking detection algorithm would have to superimpose both. + \subsection{Means of power transmission} +Power transmission from payload to rotor is another point worth investigating. It may be possible to use some statically +mounted permanent magnets with a coil integrated into the rotor's PCB as a low-power generator. While likely +inefficient, this setup would be low-cost and would still suffice for the meager power requirements of the rotor's +monitoring circuitry. + +\subsection{Payload cooling} +An issue with existing HSM concepts is that the mesh has to fully envelope the payload, and thus traditional air cooling +or heat pipes cannot be used. Existing systems rely on heat conduction through the mesh alone for cooling, severly +limiting the maximum power dissipation of the payload. In our rotating HSM concept, the rotating mesh can have radial +gaps in the mesh without impeding its function. This allows air to pass through the mesh during rotation, and a future +evolution of the concept could even integrate a fan into the rotating component. This greatly increases the maximum +possible power dissipation of the payload, allowing for much more powerful processing. + \subsection{Other sensing modes} -\subsection{Longeivity} +Since the security requirement the primary tamper-detection barrier needs to measure up to are much more lenient in the +rotating HSM concept than in traditional HSMs, other coarse sensing modes besides low-tech meshes may be attractive. One +possibility that would also eliminate the need of any active circuitry on the rotor would be to print the inside of the +rotor with a pattern, then have a linear array of reflective optical sensors located close to the rotor along a +longitudinal line. These sensors would observe the printed pattern passing by at high speed, and could compare their +measurements against a model of the rotor. Tampering by drilling holes or slots would show up as adding an offset to +part or all of the pattern. Likewise, the speed of rotation can be deducted directly from a sequence of measurements. + +\subsection{Longevity} +A core issue with a mechanical HSM is component longevity. Save for dust and debris clogging up the system's mechanics +the primary failure point are the bearings. A good partner for further development or even commercialization might be a +manufacturer of industrial ducted fans as they are used e.g.\ in servers for cooling. Small industrial fans usually use +BLDC motors and bearings specially optimized for longevity. + +\subsection{Transportation of an active device} +A rotating mass responds to torque not co-linear with its axis of rotation with a gyroscopic precession force. In +practice, this means that moving a device containing a spun-up rotating HSM on its inside might induce significant +forces on both the HSM (posing the danger of false alarms) and on the carrier of the device (potentially making handling +challenging). This effect would have to be taken into account in a real-world deployment, especially if the finished +device is to be shipped by post or courier services after spin-up. + +\subsection{Hardware prototype} +We are currently working on a hardware prototype that demonstrates the fundamental components of our concept. The +prototype will be based on a security mesh made with a commercial printed circuit board manufacturing process. In our +prototype we intend to use two commercially available hollow-shaft brushless DC (BLDC) motors originally intended for +quadcopter-mounted camera gimbals, one for driving and one for power transfer. The prototype will have a usable internal +volume sufficient to house a small form factor PC ($\approx\SI{2}{\liter}$). \section{Attacks} -\subsection{Attacks on the rotation sensor} \subsection{Attacks on the mesh} +There are two locations where one can attack a tamper-detection mesh. Either, the mesh itself can be tampered with. This +includes bridging its traces to allow for a hole to be cut. The other option is to tamper with the monitoring circuit +itself, to prevent a damaged mesh from triggering an alarm and causing the HSM to erase its contents. Attacks in both +locations are electronic attacks, i.e. they require electrical contact to parts of the circuit. Traditionally, this +contact is made by soldering, or by placing a probe such as a thin needle. Any kind of electrical contact that does not +involve an electron or ion beam or a liquid requires mechanical contact. We consider none of these forms feasible to be +performed on an object rotating at high speed without a complex setup that rotates along with the object. Thus, we +consider them to be practically infeasible outside of a well-funded, special-purpose laboratory. + \subsection{Attacks on the alarm circuitry} +An electronic attack could also target the alarm circuitry inside the stationary payload, or the communication link +between rotor and payload. The link can easily be proofed by using a cryptographically secured protocol along with a +high-frequency heartbeat message. The alarm circuitry has to be designed such that it is entirely contained within the +HSM's security envelope and has to tolerate environmental attacks such as through temperature, ionizing radiation, +lasers, supply voltage variations, ultrasound or other vibration and gases or liquids. The easiest way to proof an alarm +system against these is to employ adequate filtering of the incoming power supply and use sensors for the others, +triggering an alarm in case extraordinary environmental variations are detected. + \subsection{Fast and violent attacks} +A variation of the above attacks on the alarm circuitry would be an attack that attempts to simply destroy this +circuitry before the alarm can be acted upon. This type of attack might involve things such as a large hammer, or a gun. +Mitigations for this type of attack include putting the entire payload and monitoring circuit in a mechanically robust +enclosure and potting them, and linking all components of the alarm chain in such a way cryptographically and on a +protocol level that the destruction of any of its parts leads to the secrets being destroyed before an attack would be +able to probe them. An implication of this is that the electrical realization of the alarm signal up to its eventual +destination cannot be a simple active-high or active-low line, since neither can be considered fail-safe in this +scenario. -\section{Hardware prototype} -% FIXME +\subsection{Attacks on the rotation sensor} +An attacker trying to stop the rotor to tamper with the mesh may first try to deceive the rotation monitoring circuit +such that it misses the rotor being stopped. In a realization based on a commercial MEMS accelerometer, this attack +could take two forms: An electronic attack on the MEMS sensor, the monitoring microcontroller or the link in between, +and a physical attack on the MEMS sensor itself. The former would be no easier than an electronic attack that attempts +to bridge the mesh traces at the monitoring microcontroller. Thus, we consider it not to be practically feasible outside +of a laboratory built especially for this purpose. + +There are several options for the latter attack. A recent paper %FIXME +has shown that accelerometers respond to certain ultrasonic stimuli with bogus measurements. Since this primitive does +not, however, yield accurate control over these bogus measurements, we deem it to be impractical for our scenario. +Another possible attack scenario would be to somehow stop the rotating motion while subjecting the HSM to an external +linear motion. Given the low error margins in the measurements of commercial accelerometers we consider this attack +infeasible. A last type of attack might be to try to physically tamper with the accelerometer's sensing mechanism. MEMS +accelerometers usually use a simple cantilever design, where a proof mass moves a cantilever whose precise position can +be measured electronically. A possible way to attack such a device might be to first decapsulate it using laser ablation +synchronized with the device's rotation. Then, a fast-setting glue such as a cyanoacrylate could be deposited on the +moving MEMS parts in either liquid or gaseous form, locking them in place after hardening. This attack would require +direct access to the accelerometer from the outside and can be prevented by mounting the accelerometer inside the +security envelope. This attack only works if the rate of rotation is constant and is trivially detectable if the rate of +rotation is set to change on a schedule. \section{Conclusion} +In this paper, we have presented inertial hardware security modules, a novel concept for the construction of highly +secure hardware security modules from inexpensive, commonly available parts. We have elaborated the engineering +considerations underlying a practical implementation of this concept. We have analyzed the concept for its security +properties and highlighted its ability to significantly strengthen otherwise weak tamper detection barriers. We have +laid out some ideas for future research on the concept, and we will continue our own research on the topic. \printbibliography[heading=bibintoc] \appendix -\section{License} +\section{Patents and licensing} +During devlopment, we performed several hours of research on prior art for the inertial HSM concept. Yet, we could not +find any mentions of similar concepts either in academic literature or in patents. Thus, we deem ourselves to be the +inventors of this idea and we are fairly sure it is not covered by any patents or other restrictions at this point in +time. + +Since the concept is primarily attractive for small-scale production and since cheaper mass-production alternatives are +already commercially available, we have decided against applying for a patent and we wish to make it available to the +general public without any restrictions on its use. This paper itself is licensed CC-BY-SA (see below). As for the +inertial HSM concept, we invite you to use it as you wish and to base your own work on our publications without any fees +or commercial restrictions. Where possible, we ask you to cite this paper and attribute the inertial HSM concept to its +authors. + \center{ -\begin{minipage}[t][10cm][b]{\textwidth} \center{\ccbysa} \center{This work is licensed under a Creative-Commons ``Attribution-ShareAlike 4.0 International'' license. The @@ -345,6 +455,5 @@ acts as the alarm trigger, a simple optocoupler close to the axis of rotation is \center{This is version \texttt{\input{version.tex}\unskip} generated on \today. The git repository can be found at:} \center{\url{https://git.jaseg.de/rotohsm.git}} -\end{minipage} } \end{document} -- cgit From 65400d123e593f2ed77f23d1b901cdf613fc15c1 Mon Sep 17 00:00:00 2001 From: jaseg Date: Wed, 7 Oct 2020 10:02:14 +0200 Subject: Add missing docs --- doc/TCC scenario algorithmic complexity.odt | Bin 0 -> 20034 bytes doc/diagram tcc export conventional.png | Bin 0 -> 166248 bytes doc/diagram tcc export conventional.svg | 773 ++++++++++++++ doc/diagram tcc export revolutionary.png | Bin 0 -> 230120 bytes doc/diagram tcc export revolutionary.svg | 864 ++++++++++++++++ doc/diagram tcc.svg | 1281 ++++++++++++++++++++++++ doc/trusted computing cluster overview v01.odt | Bin 0 -> 432990 bytes 7 files changed, 2918 insertions(+) create mode 100755 doc/TCC scenario algorithmic complexity.odt create mode 100755 doc/diagram tcc export conventional.png create mode 100755 doc/diagram tcc export conventional.svg create mode 100755 doc/diagram tcc export revolutionary.png create mode 100755 doc/diagram tcc export revolutionary.svg create mode 100755 doc/diagram tcc.svg create mode 100755 doc/trusted computing cluster overview v01.odt diff --git a/doc/TCC scenario algorithmic complexity.odt b/doc/TCC scenario algorithmic complexity.odt new file mode 100755 index 0000000..babafdd Binary files /dev/null and b/doc/TCC scenario algorithmic complexity.odt differ diff --git a/doc/diagram tcc export conventional.png b/doc/diagram tcc export conventional.png new file mode 100755 index 0000000..291889e Binary files /dev/null and b/doc/diagram tcc export conventional.png differ diff --git a/doc/diagram tcc export conventional.svg b/doc/diagram tcc export conventional.svg new file mode 100755 index 0000000..ce362d2 --- /dev/null +++ b/doc/diagram tcc export conventional.svg @@ -0,0 +1,773 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + End-user devices + Servers + + + Cloud Service Providers + + Hardware Security Modules + + + + + + + + + + + Personal Information + + + + Credit Card Information + + + + + + + + diff --git a/doc/diagram tcc export revolutionary.png b/doc/diagram tcc export revolutionary.png new file mode 100755 index 0000000..ce4815b Binary files /dev/null and b/doc/diagram tcc export revolutionary.png differ diff --git a/doc/diagram tcc export revolutionary.svg b/doc/diagram tcc export revolutionary.svg new file mode 100755 index 0000000..d694d60 --- /dev/null +++ b/doc/diagram tcc export revolutionary.svg @@ -0,0 +1,864 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + End-user devices + Cloud Service Providers + Servers + Trusted Computing Modules + Trusted Computing Cluster + + + + + + + + + + + + + + Personal Information + + + + Credit Card Information + + + + + + + + + diff --git a/doc/diagram tcc.svg b/doc/diagram tcc.svg new file mode 100755 index 0000000..0626589 --- /dev/null +++ b/doc/diagram tcc.svg @@ -0,0 +1,1281 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + End-user devices + Cloud Service Providers + Servers + Trusted Computing Modules + Trusted Computing Cluster + + + + + + + + + + + + + + Personal Information + + + + Credit Card Information + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + End-user devices + Servers + + + Cloud Service Providers + + Hardware Security Modules + + + + + + + + + + + Personal Information + + + + Credit Card Information + + + + + + + + diff --git a/doc/trusted computing cluster overview v01.odt b/doc/trusted computing cluster overview v01.odt new file mode 100755 index 0000000..9b60453 Binary files /dev/null and b/doc/trusted computing cluster overview v01.odt differ -- cgit