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}