diff options
author | jaseg <git@jaseg.de> | 2021-10-07 19:34:36 +0200 |
---|---|---|
committer | jaseg <git@jaseg.de> | 2021-10-07 20:31:44 +0200 |
commit | 844fc1b96c9937da374dabc76d4b974672cf9c56 (patch) | |
tree | d7570814809fd02860887bebaf139ce3af01f37d /paper | |
parent | 9c10f393bc3d33179e070950ac00ec231f8a6847 (diff) | |
download | ihsm-844fc1b96c9937da374dabc76d4b974672cf9c56.tar.gz ihsm-844fc1b96c9937da374dabc76d4b974672cf9c56.tar.bz2 ihsm-844fc1b96c9937da374dabc76d4b974672cf9c56.zip |
Changes re: shepherding 21-10-01
* Extend use cases
* Add maintenance/repair section
Diffstat (limited to 'paper')
-rw-r--r-- | paper/Makefile | 2 | ||||
-rw-r--r-- | paper/ihsm.bib | 9 | ||||
-rw-r--r-- | paper/ihsm_paper.tex | 90 |
3 files changed, 73 insertions, 28 deletions
diff --git a/paper/Makefile b/paper/Makefile index 271964f..98f907e 100644 --- a/paper/Makefile +++ b/paper/Makefile @@ -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 diff --git a/paper/ihsm.bib b/paper/ihsm.bib index 5dabfb8..2b2b277 100644 --- a/paper/ihsm.bib +++ b/paper/ihsm.bib @@ -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}, diff --git a/paper/ihsm_paper.tex b/paper/ihsm_paper.tex index cb70164..5e1a797 100644 --- a/paper/ihsm_paper.tex +++ b/paper/ihsm_paper.tex @@ -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. - -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. +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. + +% 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 |