Changes re: shepherding 21-10-01
* Extend use cases * Add maintenance/repair section
This commit is contained in:
parent
9c10f393bc
commit
844fc1b96c
3 changed files with 72 additions and 27 deletions
|
|
@ -8,7 +8,7 @@ SHELL := bash
|
|||
MAKEFLAGS += --warn-undefined-variables
|
||||
MAKEFLAGS += --no-builtin-rules
|
||||
|
||||
DIFF_VERSION ?= v3.0
|
||||
DIFF_VERSION ?= v3.1
|
||||
|
||||
main_tex ?= ihsm_paper
|
||||
brief_tex ?= ihsm_tech_report
|
||||
|
|
|
|||
|
|
@ -442,6 +442,15 @@
|
|||
date = {2018-07-11},
|
||||
}
|
||||
|
||||
@WWW{iana21,
|
||||
title = {Root Zone KSK Operator Key Management Procedure},
|
||||
author = {{Root Zone KSK Operator Policy Management Authority}},
|
||||
date = {2021-09-22},
|
||||
version = {Version 3.4},
|
||||
url = {https://www.iana.org/dnssec/procedures/ksk-operator/KSK_Key_Management_Procedure_v3.4.pdf},
|
||||
urldate = {2021-10-07},
|
||||
}
|
||||
|
||||
@InProceedings{ledger2019,
|
||||
title = {Everybody be cool, this is a robbery!},
|
||||
author = {Jean-Baptiste Bédrune and Gabriel Campana},
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@
|
|||
|
||||
\title[Can't Touch This: Inertial HSMs Thwart Advanced Physical Attacks]{Can't Touch This: Inertial HSMs Thwart Advanced Physical Attacks}
|
||||
\author{Jan Sebastian Götte\and Björn Scheuermann}
|
||||
\institute{HIIG\\ \email{ihsm@hiig.jaseg.de} \and HIIG\\ \email{bjoern.scheuermann@hiig.de}}
|
||||
\institute{HIIG, Berlin, Germany\\ \email{ihsm@hiig.jaseg.de} \and HIIG, Berlin, Germany\\ \email{bjoern.scheuermann@hiig.de}}
|
||||
% FIXME keywords
|
||||
\keywords{hardware security \and implementation \and smart cards \and electronic commerce}
|
||||
\maketitle
|
||||
|
|
@ -236,29 +236,44 @@ our concept with two use cases and outline our attacker model.
|
|||
\subsection{Use Cases and Attacker Model}
|
||||
|
||||
The target application of an IHSM is high-risk data processing. This risk can be implied by either high-value data, or
|
||||
by difficult physical security constraints. Our goal with IHSMs is to eventually arrive at a system that, at low-cost,
|
||||
can persist against a smart, well-funded adversary such as a secret service or organized cyber-crime.
|
||||
by difficult physical security constraints. Our goal with IHSMs is to eventually arrive at a system that, at low cost,
|
||||
can persist against a smart, well-funded adversary such as a secret service or organized cyber-crime. We apply
|
||||
Kerckhoff's principle and consider the attacker to have white-box access to the IHSM's hard-, firm- and software. We
|
||||
consider the attacker to have persistent access to the device and that they may be willing to spend weeks or months
|
||||
performing a single attack.
|
||||
|
||||
Consider a group of healthcare providers intending to analyze a large database of patient health information.
|
||||
Accumulating potentially millions of sensitive medical records on a single system for such processing poses an inherent
|
||||
risk as this system becomes a valuable target for organized cyber-criminals looking for ransom. IHSMs allow for a level
|
||||
of physical security against e.g.\ a bribed insider that is as good as the level of network security afforded by modern
|
||||
firewalls and cryptographic protocols.
|
||||
% In case a randomized security mesh is used (cf.\ Section\ \ref{mesh-gen}) and the mesh is shielded from observation
|
||||
% (e.g.\ optical or x-ray), we consider the concrete randomized routing of the mesh traces secret.
|
||||
|
||||
By targeting this pessimistic attacker model, we increase the real-world utility of IHSMs. Consider a group of
|
||||
healthcare providers intending to analyze a large database of patient health information. Accumulating potentially
|
||||
millions of sensitive medical records on a single system for such processing poses an inherent risk as this system
|
||||
becomes a valuable target for organized cyber-criminals looking for ransom. IHSMs permit a level of physical security
|
||||
against e.g.\ a bribed insider that is as good as the level of network security afforded by modern firewalls and
|
||||
cryptographic protocols.
|
||||
|
||||
On the other end of the spectrum, consider a real-time group video communication provider. Relaying and transcoding
|
||||
video data between participants is hard to solve without trusting the server, but at the same time latency requires that
|
||||
the server is physically located close to its users. Given the global history of privacy-invasive cyber-attacks by
|
||||
secret services and other well-funded attackers, this may pose an issue. In this scenario, IHSMs allow for the secure
|
||||
secret services and other well-funded attackers, this may pose an issue. In this scenario, IHSMs enable the secure
|
||||
deployment of trusted server components closer to the user, or even at the network edge, where physical security is
|
||||
challenging.
|
||||
|
||||
An application with a similar scenario is manipulation-proof audit logging. Since IHSMs are connected to backup power,
|
||||
they can continue to record log messages from other nearby devices even during catastrophic disruption such as
|
||||
large-scale power outages. In this use case, the IHSM assumes two functions: That of a trusted, highly available data
|
||||
storage and that of a trusted timestamping service.
|
||||
|
||||
\subsection{Inertial HSM motion}
|
||||
\label{sec_ihsm_motion}
|
||||
|
||||
First, there are several ways how we can approach motion. Periodic, aperiodic and continuous motion could serve the
|
||||
purpose. There is also linear motion as well as rotation. We can also vary the degree of electronic control in this
|
||||
motion. The main constraint on the HSM's motion pattern is that it needs to be (almost) continuous to not expose any
|
||||
weak spots during instantaneous standstill of the HSM. Additionally, it has to stay within a confined space. For space
|
||||
Against the background of these use cases, we will now elaborate on the four questions we formulated in the introduction
|
||||
to this section, starting with that on \emph{type of motion}. There are several ways how we can approach motion.
|
||||
Periodic, aperiodic and continuous motion could serve the purpose. There is also linear motion as well as rotation. We
|
||||
can also vary the degree of electronic control in this motion.
|
||||
|
||||
The primary constraint on an IHSM's motion pattern is that it needs to be (almost) continuous to not expose any weak
|
||||
spots during instantaneous standstill of the HSM. Additionally, it has to stay within a confined space. For space
|
||||
efficiency, linear motion would have to be periodic, like that of a pendulum. Such periodic linear motion will have to
|
||||
quickly reverse direction at its apex so the device is not stationary long enough for this to become a weak spot.
|
||||
|
||||
|
|
@ -296,7 +311,7 @@ In our research, we focus on security meshes as our IHSM's tamper sensors. The
|
|||
techniques and special materials used in fine commercial meshes poses an obstacle to small-scale manufacturing and
|
||||
academic research. The foundation of an IHSM security is that by moving the mesh, even a primitive, coarse mesh such as
|
||||
one made from a low-cost PCB becomes very hard to attack in practice. This allows us to use a simple construction made
|
||||
up from low-cost components. Additionally, the use of a mesh allows us to only spin the mesh itself and its monitoring
|
||||
up from low-cost components. Additionally, the use of a mesh enables us to only spin the mesh itself and its monitoring
|
||||
circuit and keep the payload inside the mesh stationary for reduced design complexity. Tamper sensing systems such as
|
||||
RF fingerprinting that monitor the entire volume of the HSM instead of only a thin boundary layer would not allow for
|
||||
this degree of freedom in an IHSM. They would instead require the entire IHSM to spin including its payload, which would
|
||||
|
|
@ -313,7 +328,7 @@ manipulation attempt.
|
|||
While the obvious choice to monitor rotation would be a magnetic or optical tachometer sensor attached to the IHSM's
|
||||
shaft, this would be a poor choice for our purposes since optical and magnetic sensors are susceptible to contact-less
|
||||
interference from outside. We could use feedback from the motor driver electronics to determine the speed. When using a
|
||||
BLDC motor, the driver electronics precisely know the rotor's position at all times. However, this apporach might allow
|
||||
BLDC motor, the driver electronics precisely know the rotor's position at all times. However, this approach might allow
|
||||
for attacks at the mechanical interface between the mesh and the motor's shaft. If an attacker can decouple the mesh
|
||||
from the motor e.g.\ by drilling, laser ablation or electrical discharge machining (EDM) on the motor's shaft, the
|
||||
motor could keep spinning at its nominal frequency while the mesh is already standing still.
|
||||
|
|
@ -419,15 +434,6 @@ approach is a 2019 technology demonstration~\cite{signal2019} created by signal.
|
|||
secure messenger app. In this demonstration, signal.org have implemented the Raft consensus algorithm~\cite{ongaro2019}
|
||||
inside Intel SGX to replicate state between geographically redundant enclaves.
|
||||
|
||||
Finely-grained monitoring of operational parameters may be capable of recognizing some types of failure such as backup
|
||||
battery failure, mechanical wear or over/undertemperature conditions some time before alarm levels have been reached and
|
||||
all secrets must be detstroyed. This type of early warning allows for the implementation of a graceful failover
|
||||
mechanism. Similar to hot spares in hard disk arrays, a number of IHSMs might share a hot spare IHSM that is running,
|
||||
but that does not yet contain any secrets. Once an IHSM detects early warning signs of an impending failure, it can then
|
||||
transfer its secrets to the hot spare using replicatoin technologies as mentioned in the previous paragraph, then delete
|
||||
its local copies. This would allow for the graceful handling of device failures due to both age and disasters such as
|
||||
fires.
|
||||
|
||||
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
|
||||
changes in the IHSM's environment. In the following paragraphs, we will evaluate each of these categories in its
|
||||
|
|
@ -460,8 +466,6 @@ if power outages of more than a few seconds are unlikely (e.g.\ because of an ex
|
|||
be used as a flywheel for energy storage.
|
||||
|
||||
\paragraph{Spurious alarms due to vibration.}
|
||||
|
||||
|
||||
Even with all components working to their specification, an IHSM could still catastrophically fail if for some reason
|
||||
its alarm would be spuriously activated due to movement of the device. The likelihood of such an alarm failure must be
|
||||
minimized, e.g.\ by employing vibration damping. There are several possible causes why an IHSM might move during normal
|
||||
|
|
@ -507,6 +511,37 @@ the IHSM could be shipped connected to an external battery akin to a ``power ban
|
|||
manufacturer after the IHSM has been installed. Long-distance shipping can be facilitated through compatibility with
|
||||
standards used for powered refrigerated shipping containers.
|
||||
|
||||
\subsection{Graceful Failover and Maintenance}
|
||||
|
||||
As described above, failure can never be fully prevented. However, finely-grained monitoring of operational parameters
|
||||
may be capable of recognizing some types of failure such as backup battery failure, mechanical wear or
|
||||
over/undertemperature conditions some time before alarm levels have been reached and all secrets must be destroyed.
|
||||
This type of early warning allows for the implementation of a graceful failover mechanism. Similar to hot spares in hard
|
||||
disk arrays, a number of IHSMs might share a hot spare IHSM that is running, but that does not yet contain any secrets.
|
||||
Once an IHSM detects early warning signs of an impending failure, it can then transfer its secrets to the hot spare
|
||||
using replicatoin technologies as mentioned in the previous paragraph, then delete its local copies. This would allow
|
||||
for the graceful handling of device failures due to both age and disasters such as fires.
|
||||
|
||||
When such failovers happen, IHSMs provide a key benefit compared to traditional HSMs. Since an IHSM is not permanently
|
||||
potted and its security mesh is mechanically robust, it can be stopped and disassembled to repair a faulty component
|
||||
such as a worn-out bearing or a defective payload component such as a RAM module or an SSD. A faulty IHSM can be
|
||||
refurbished like a normal server. Its disassembly does not require any special equipment.
|
||||
|
||||
The primary challenge in repairing IHSMs is purely operational. It has to be ensured that an attacker lying in wait
|
||||
cannot seize the opportunity of the IHSM's defenses shutting down to implant a hardware trojan. A possible approach
|
||||
would be to have the IHSM contain a cryptographic identity that it uses to authenticate its status to its operator, and
|
||||
that is destroyed along with the payload's secrets when the IHSM is tampered with. The IHSM's operator could then
|
||||
provide a cryptographically authenticated maintenance token to a trusted technician that allows the technician to power
|
||||
down this particular IHSM during a set time window. The technician can then physically repair the IHSM and return it
|
||||
into service, after which the operator can use the IHSM's identity to verify that the repair was conducted as intended.
|
||||
Using a physical token instead of powering off the IHSM remotely prevents the accidental unsupervised stopping of an
|
||||
IHSM due to operator error.
|
||||
|
||||
To decrease the risk posed by a rogue technician, similar to the DNSSEC root key signing ceremonies~\cite{iana21}
|
||||
arbitrarily complex procedures can be implemented that could, for example, require each maintenance procedure to be
|
||||
accompanied by several independent witnesses.
|
||||
|
||||
|
||||
\section{Attacks}
|
||||
\label{sec_attacks}
|
||||
|
||||
|
|
@ -739,6 +774,7 @@ incorporates a functional PCB security mesh. As we observed previously, this mes
|
|||
system once per revolution, so we designed the longitudinal PCBs as narrow strips to save weight.
|
||||
|
||||
\subsection{PCB security mesh generation}
|
||||
\label{mesh-gen}
|
||||
|
||||
Our proof-of-concept security mesh covers a total of five interlocking mesh PCBs (Figure~\ref{mesh_gen_sample}). A sixth
|
||||
PCB contains the monitoring circuit and connects to these mesh PCBs. To speed up design iterations, we automated the
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue