jaseg/phd-thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add itemized contributions list to intro

Browse source
This commit is contained in:
jaseg 2025-12-01 16:03:08 +01:00
parent d7b381307c
commit 229bb34b09
2 changed files with 64 additions and 37 deletions
Download patch file Download diff file Expand all files Collapse all files

57
chapter-epa/chapter.tex
View file

@ -114,9 +114,10 @@ unclear on the exact mechanism of key derivation, in previous versions of the st
random salt, and the healthcare ID number of the enrolled person was used in SHA256-HKDF. The specification requires
that a new root key is generated once a year, but as far as we can tell, record key rollover is not done automatically
but is only meant to be done when the \emph{user} requests it, and old root keys must be retained forever to ensure old
records can be accessed.
records can be accessed. Through this lack of automatic key rollover combined with the need to retain root keys
indefinitely, attack surface is maximized and incremental compromises of the system over long time spans become possible.
\subsection{Related Work}
\subsection{Previous Analyses}
\emph{gematik}, the state-owned company specifying the system, commissioned several security assessments of the system
relating to the key escrow service.
@ -158,12 +159,14 @@ surface \cite{
Our first concern is the system's general approach of using a key escrow service instead of securely storing the keys
inside the system's already existing smart card infrastructure. Like any other key escrow system, this key escrow
service poses a centralized security risk. The system's designers made this decision since it was deemed important that
access to an encrypted record can be restored quickly after an insurance ID card is lost, without requiring the
service poses a centralized security risk. The system's designers made this decision since it was considered important
that when an encrypted record must be restored after an insurance ID card is lost, it can be re-created without the
cooperation of the healthcare providers holding the primary copies of the person's medical records.
\subsection{Cryptographic Design}
\todo{Feedback from HS3 reviewer: I feel that this section is a mix-up of critique on the cryptographic design and the
approach to privacy protection and data minimisation. How are they linked? I'm missing some discussion here.}
The system's overall cryptographic design is intentionally kept simple. The standard explicitly mentions that symmetric
primitives have been preferred over asymmetric primitives in the core key escrow functions due to the risk of an attack
on asymmetric primitives in the long term. Notably, other advanced cryptographic techniques such as secret sharing
@ -178,19 +181,16 @@ For instance, the system leaks a person's insurance ID number to the key escrow
requested. Along with the timing and frequency of these requests, this leaks information on the person's condition to
the key escrow service in an identifiable way.
% TODO I feel that this section is a mix-up of critique on the cryptographic design and the approach to privacy
% protection and data minimisation. How are they linked? I'm missing some discussion here.
\subsection{A Realistic Attacker Model}
We observe that the system as a whole does not appear to be designed to defend against well-resourced adversaries. The
series of practical attacks that have been demonstrated on the system confirm this impression. In
\textcite{tschirsichKonnteBisherNoch2024} summarize a series of successful attacks. Attacks include social engineering
resulting in access to copies of smartcards enabling accessing patient records, using misconfigured Konnektor VPN
appliances with their LAN DMZ and authentication interface exposed on the public internet, circumventing video-based
authentication processes resulting in duplicate file keys being provided, classis SQL injection on a backend service
maintaining an authentication database, accessing all national patient records through brute-force enumeration of weak
identifiers, and several more.
We observe that the system as a whole does not appear to be designed to defend against well-resourced adversaries. A
series of demonstrated practical attacks on the system, none of which required advanced capabilities, confirm this
impression. In \textcite{tschirsichKonnteBisherNoch2024} summarize a series of successful attacks. Attacks include
social engineering resulting in access to copies of smartcards enabling accessing patient records, using misconfigured
Konnektor VPN appliances with their local network DMZ and authentication interface exposed on the public internet,
circumventing video-based authentication processes resulting in duplicate file keys being provided, classis SQL
injection on a backend service maintaining an authentication database, accessing all national patient records through
brute-force enumeration of weak identifiers, and several more.
We believe that a system like this must be designed to withstand well-resourced adversaries such as foreign secret
services, since the medical data stored in such as information on chronic illness, sexually transmittable disease or
@ -207,19 +207,20 @@ the extraction of any patient records being processed in plaintext inside these
Physical security has received some consideration in the system's specification. First, smart cards are used extensively
for authentication. Second, Hardware Security Modules are used in key locations of the system to process some
cryptographic secrets. The core of the system's key escrow service is implemented inside an HSM. However, it is notable
that the actual security level required for this HSM is only FIPS 140-2 level 3
\cite{usnationalinstituteofstandardsandtechnologySecurityRequirementsCryptographic2002}. FIPS 140-2 is a US government
standard that used to be popular for the specification of HSMs. However, not only has FIPS 140-2 been made obsolete by
FIPS 140-3 in 2019 \cite{usnationalinstituteofstandardsandtechnologySecurityRequirementsCryptographic2019}, its security
level 3 mostly provides logical separation of cryptographic functions from other logic and is not very meaningful in the
context of physical attacks. The only physical requirement of FIPS 140-2 level 3 is that the HSM has a hard, opaque
coating. This coating is specified to be tamper-evident, but notably no active tamper detection or response features are
required by this standard~\cite{andersonSecurityEngineeringGuide2020}. In contrast to the newer FIPS 140-3 standard and
the related ISO/IEC 19790 \cite{ISOIEC19790} as well as ISO/IEC 24759 \cite{ISOIEC24759} standards, FIPS 140-2 does not
make any particular requirements regarding resistance to side-channel attacks. The lack of tamper response, unspecified
resistance to side-channel attacks and the fact that the ePA specification only requires the long-lived key escrow root
key inside the HSM to have 256 bits of entropy lead to an unsatisfactory overall constellation.
cryptographic secrets. The core of the system's key escrow service is implemented inside an HSM that is part of a
redundant HSM cluster. However, it is notable that the actual security level required for this HSM is only FIPS 140-2
level 3 \cite{usnationalinstituteofstandardsandtechnologySecurityRequirementsCryptographic2002}. FIPS 140-2 is a US
government standard that used to be popular for the specification of HSMs. However, not only has FIPS 140-2 been made
obsolete by FIPS 140-3 in 2019 \cite{usnationalinstituteofstandardsandtechnologySecurityRequirementsCryptographic2019},
its security level 3 mostly provides logical separation of cryptographic functions from other logic and is not very
meaningful in the context of physical attacks. The only physical requirement of FIPS 140-2 level 3 is that the HSM has a
hard, opaque coating. This coating is specified to be tamper-evident, but notably no active tamper detection or response
features are required by this standard~\cite{andersonSecurityEngineeringGuide2020}. In contrast to the newer FIPS 140-3
standard and the related ISO/IEC 19790 \cite{ISOIEC19790} as well as ISO/IEC 24759 \cite{ISOIEC24759} standards, FIPS
140-2 does not make any particular requirements regarding resistance to side-channel attacks. The lack of tamper
response, unspecified resistance to side-channel attacks and the fact that the ePA specification only requires the
long-lived key escrow root key inside the HSM to have 256 bits of entropy lead to an unsatisfactory overall
constellation.
\section{Conclusion}

44
chapter-introduction/chapter.tex
View file

@ -262,13 +262,6 @@ dissipation by two orders of magnitude.
Based on the current state of the field of hardware security, we deduce three overarching research questions for this
thesis that progress from theory to practical deployment.
% Research questions:
% 1. can hsm w/o proprietary mesh?
% 2. how do meshes look like in practice?
% 3. can we improve monitoring?
% 4. can we solve power transfer issue
% 5. applications
%
\begin{enumerate}
\item What is the state of the art in commercial tamper sensing mesh implementations?
\item What are criteria and approaches for the design of secure tamper sensing meshes?
@ -314,13 +307,46 @@ Distribution (QKD) networks using trustable physically secured relay nodes and i
elaborate how datacenter-scale Secure Multiparty Computation (SMPC) clusters can be created using IHSM enclosures with
commercial server hardware.
\section{Contributions}
Through this thesis, we make contributions advancing the state of hardware securty across several related sub-fields.
Our contributions include:
\begin{enumerate}
\item We conduct the first large-scale survey of tamper sensing measures in the real world, analyzing approximately
30 devices.
\item From our real world observations, we systematize tamper sensing mesh construction techniques and we provide a
list of criteria improving mesh security.
\item We experimentally analyze the impact of Computed Tomography (CT) imaging on mesh security.
\item We propose the IHSM, a new concept for HSM design based on a rotating mesh that increases payload size and
power dissipation capacity while simultaneously allowing for simpler meshes constructed from standard
components.
\item We show experimental results on IHSM mesh performance obtained with a prototype IHSM.
\item We introduce an algorithm for the automatic layout of tamper-sensing meshes and its implementation on top of a
popular, open-source Electronic Design Automation (EDA) tool.
\item We introduce a high-fidelity mesh monitoring approach that uses Time-Domain Reflectometry (TDR).
\item We show a low-cost implementation of our TDR monitoring approach.
\item We evaluate the performance of our TDR monitoring implementation and demonstrate its response to a large
set of attacks. We show that it reliably distinguishes identical copies of the same mesh specimen, suggesting
PUF-like behavior.
\item We introduce a generalized design approach for low-loss planar inductors that out-peform prior approaches in
parasitic capacitance, self-resonant frequency and rotational symmetry.
\item We apply our design approach to the problem of Wireless Power Transfer to the rotating mesh of an IHSM.
\item We conduct an exhaustive experimental evaluation of the rotational symmetry of a large set of planar WPT
inductors created using our approach.
\item We analyze physically secure Quantum Key Distribution relays as an IHSM use case and develop a low-loss fiber
optic passthrough that supports an additional, secondary, independently rotating mesh shielding the shaft
passthrough of the IHSM's primary mesh.
\item We explore IHSMs for co-located high performance Multiparty Computation (MPC) setups. We demonstrate a
fan-driven IHSM mesh concept for high-availability scenarios that removes motors as a single point of failure
while providing sufficient airflow for cooling high-power server components.
\end{enumerate}
We chose to publish all of our research as open source and unencumbered by patents to enable widespread adoption. IHSMs
can be custom built with only basic manufacturing capabilities at small scale and enable the deployment of secure
computation in insecure places even to small organizations such as university research departments, NGOs and small
businesses.
\section{Conclusion}
Looking at the practice of applied hardware security, we observe that despite ample availability of commercial solutions
promising easy hardware security, clearly there is still a lack of solutions that provide the adaptability necessary for
some real use cases at low enough cost. By publishing the tamper-sensing technology we developed during the making of