\documentclass{llncs}

\usepackage[T1]{fontenc}
\usepackage[
    backend=biber,
    style=lncs,
    natbib=true,
    url=false, 
    doi=true,
    eprint=false
    ]{biblatex}
\addbibresource{paper.bib}
\usepackage{amssymb,amsmath}
\usepackage{eurosym}
\usepackage{wasysym}
\usepackage[binary-units]{siunitx}
\usepackage{commath}
\usepackage{graphicx,color}
\usepackage{colortbl}
\usepackage{subcaption}
\usepackage{placeins}
\usepackage{array}
\usepackage{censor}
\usepackage{hyperref}
\usepackage{makecell}

\DeclareSourcemap{
  \maps[datatype=bibtex, overwrite=true]{
    \map{
      \step[fieldsource=url, final]
      \step[fieldsource=institution, fieldtarget=organization]
      \step[typesource=report, typetarget=online]
    }
  }
}

\DeclareSIUnit{\baud}{Bd}
\DeclareSIUnit{\year}{a}
\DeclareSIUnit{\rpm}{rpm}
\renewcommand{\floatpagefraction}{.8}
\newcommand{\degree}{\ensuremath{^\circ}}
\newcolumntype{P}[1]{>{\centering\arraybackslash}p{#1}}
\newcommand{\partno}[1]{\textsf{\small#1}}
\newcommand{\price}[2]{#1 #2}
\newcommand{\todo}[1]{\textbf{TODO}\footnote{#1}}

\begin{document}

\author{Jan Sebastian Götte\inst{1}}
\institute{Technical University of Darmstadt, Darmstadt, Germany, \email{research@jaseg.de}}
\title{Perspective Paper: Germany Is Rolling Out Nation-Scale Key Escrow And Nobody Is Talking About It}
\maketitle
\keywords{Physical Security\and Tamper Resistance\and Hardware Security Module
            (HSM)\and Cryptography\and Governance\and Healthcare}

\begin{abstract}
    Germany is currently rolling out an opt-out, nation-scale database of the medical records of the majority of its
    population, with low-income people being disproportionally represented among its users. While there has been
    considerable criticism of the system coming from civil society, independent academic analysis of the system by the
    cryptography and information security community has been largely absent. In this paper, we aim to raise awareness of
    the system's existence and, based on the system's public specifications, highlight several concerning cryptographic
    engineering decisions. Our core observations is that the system's most sensitive long-term user keys are derived by
    a rudimentary, home-grown centralized key escrow mechanism. This mechanism relies on a per-use salt and only 256 bit
    of entropy, shared globally across millions of users. Furthermore, the system's specification mandates only Level 3
    compliance with the obsolete FIPS 140-2 security standard, which requires ``hard, opaque potting'', but lacks active
    tamper sensing. As a result, the system remains vulnerable to attacks by nation states and other well-funded
    adversaries.
\end{abstract}

\section{Introduction}

Beginning May 2025, after several delays, Germany has started the nation-scale rollout of its new electronic medical
record system. The system aims to create a national database accessible to all healthcare providers that holds the
complete electronic medical records of all publically insured people living in Germany. The system aims to replace
paper-based workflows that are error-prone and lead to healthcare providers often only having access to a subset of
patient's medical records. Data in scope for the system includes medical letters, laboratory results, and medical
imaging files.

Due to Germany's mandatory health insurace laws, the system's user base encompasses the majority of all German
residents. People who have replaced their public health insurance with private insurance currently are not subject to
the system. In Germany, by law private health insurance is only available to people from the top 10th percentile of
household income. This means that the system disproportionally affects people who have low income, creating an equity
issue. While it is possible to opt out from the use of the system, the process of opting out is difficult. Additionally,
both the government through advertising campaigns and health insurance providers have publically depicted the system in
a one-sidedly positive way, meaning that it is unlikely the majority of people subject to the system have a
comprehensive understanding of the system's benefits and risks that would be necessary for an informed decision on
opting out.

While there has been loud criticism of the system's security from civil society organizations such as digital rights
nonprofit organization Chaos Commputer Club (CCC) \cite{kochMoreMoreExperts2025} and several severe security flaws have
been demonstrated practically, this criticism has largely been ignored by the political structures in charge. We observe
that despite this civil society outrage and the system's large scale, it has received little attention from the academic
cryptography and information security community.

In this paper, we aim to point out some perplexing cryptographic engineering decisions in the system. In particular, we
point out that the system's core per-user secrets are kept in a rudimentary key escrow system whose security is based on
engineering assumptions, not on cryptographic principles. Furthermore, we observe that by specification, the individual
user keys of the system are derived from a per-user cleartext salt based on a system-wide long-term secret with only 256
bits of entropy\footnote{
    In previous versions of the standard \cite{
        gematikSpezifikationSchluesselgenerierungsdienstEPA2023,
        gematikUebergreifendeSpezifikationVerwendung2025,
    }, there were two escrow services, with both keys used in layers to reduce the risk of a compromise of either one.
    The current standard only requires one escrow service, and drops the entropy requirement of the root keys from 512
    bit to 256 bit.
}. Finally, we note that according to specification, the only physical security requirement for the protection of this
highly sensitive secret is a ``hard, opaque potting material'', with no tamper detection and response required.

We base our analysis on the system's publicly available standards in their latest version as of writing of this paper in
April 2025, describing version 3.0 of the healthcare record system \cite{
    gematikSpezifikationAktensystemEPA2025,
    gematikUbergreifendeSpezifikationVerwendung2024,
}. We note that the implementation might well deviate from these standards and be more secure - however, with the
system's history of flaws, we believe that is unlikely to be the case and the reference implementation provided by the
specification authority \cite{GithubRepositoryERPFD} follows the standards' minimum requirements closely. As of now,
there is no meaningful way for either the public or for researchers such as us to ascertain the concrete implementation
security of the system.

\section{The Design of ePA}

ePA is embedded into Germany's national public healtcare backend system ``Telematikinfrastruktur'' (TI). TI is a highly
complex system, and a detailed description would exceed the limits of this paper. Briefly put, TI consists of a shared
DMZ that parties like insurance providers and healthcare providers connect to through a VPN. At the client location,
this VPN connection is created from a specialized VPN appliance named ``Konnektor'' that simultaneously hosts as a
trusted environment executing some software for purposes such as authentication. The Konnektor hosts several smart cards
that store keys used for authentication.

Every person enrolled in the system as well as every healthcare professional providing services in it is issued a ID
card that contains a smart card that contains keys used to authenticate towards the central infrastructure. The primary
use of these smart cards up to now is that when someone visits a healthcare provider, they will insert their ID card
into a terminal so the healthcare provider can automatically fetch their personal information such as name, birth date,
address and enrollment status from their insurance provider.

ePA is implemented inside the TI system. Its centralized services are available through the TI's VPN, and encryption and
decryption of files stored in ePA are done on the Konnektor. The various smart cards are used to authenticate parties to
each other. Each insurance provider picks one of several implementations of ePA's server-side infrastructure to run for
its clients. Currently, there are two approved implementations of this server-side infrastructure.

The overall architecture of ePA heavily relies on Trusted Execution Environments (TEEs). Data processing on the server
side is done in TEEs, with some cryptographic key management delegated to a Hardware Security Module. While attacks on
the TEEs are considered in the system, the HSMs are assumed to be perfectly secure, and the system does not include
mitigations for a compromised HSM.

The primary services offered by the server side are authentication services, key escrow, and a database storing the
encrypted records themselves. Records are symmetrically encrypted with keys that are derived from system-wide secrets
inside an HSM. While the current version of the standard is unclear on the exact mechanism of key derivation, in
previous versions of the standard, the escrow service's root key, a random salt, and the healthcare ID number of the
person owning the record 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, 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.

\section{Related Work}

The state-owned company specifying the system commissioned several security assessments of the system relating to the
key escrow service. \textcite{fischlinKryptographischeAnalyseSpezifikation2021} focuses on the cryptographic
dimension of the key escrow service used in an older version of the standard, and is now obsolete.
\textcite{slanySicherheitsanalyseZurSicherheit2020} approaches the system at a higher level, and focuses on the
cryptography of the inner protocol layers spoken between the system's components. Industry research organization
Fraunhofer SIT were comissioned for a structured, theoretical assessment of attack paths to the
system \cite{fraunhofersitAbschlussberichtSicherheitsanalyseGesamtsystems2024}. We are not currently aware of
independent academic security research on the system. 

The design and operation of the system have been independently described in detail by civil society activists, who have
demonstrated several successful attacks on the system. \textcite{tschirsichHackerHinOder0100} demonstrated how they
could trivially acquire each of the smartcards as well as the Konnektor necessary for accessing the system.
\textcite{tschirsichKonnteBisherNoch0100} summarize the history of attacks demonstrated on the system and show multiple
practical attacks on various parts of the system's implementation.

\section{Concerning Cryptographic Engineering Choices}

In this paper, we aim to highlight some of the design choices in the system that we believe stray from current best
practice. This is by no means an exhaustive list, and is only meant to underscore why we believe the system deserves
more scrutiny.

\subsection{Use of Key Escrow}

First, 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 is concerning, given that this key escrow service poses as 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 cooperation of the
healthcare providers holding the primary copies of the person's medical records.

While key escrow services have been a topic of political debate in decades past, in the cryptographic community,
consensus generally is that they are a bad idea since they pose a centralized target for attack, and increase attack
surface \cite{
    abelsonRisksKeyRecovery1997,
    abelsonKeysDoormats2015,
    andersonSecurityEngineeringGuide2020,
}.

\subsection{Cryptographic Design}

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
schemes, oblivious pseudo-random functions or multiparty computation that could help with the security and privacy of
the key escrow service are also absent while the system relies extensively on the engineering-based security guarantees
of TEEs and HSMs.

The system trusts its components to a large degree. For instance, the system leaks a person's insurance ID number to the
key escrow HSM every time record keys are 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.

\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 \cite{tschirsichKonnteBisherNoch0100} confirm this
impression. We believe that a system like this must be designed to withstand well-resourced adversaries such as enemy
secret services, since the medical data stored in such as information on chronic illness, sexually transmittable disease
or severe food allergies has intelligence value. Repeated breaches of national digital infrastructure such as the 2015
breach of the US Office of Personnel Management \cite{barrettUSSuspectsHackers2015} or the 2024 compromise of US
telecommunications wiretapping systems \cite{mennChineseGovernmentHackers2024} demonstrate that such state-sponsored
attacks on national digital infrastructure are a realistic concern.

\subsection{Physical Security}

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 sevice is implemented inside an HSM. However, it is notable
that the actual security level required of this HSM is only FIPS 140-2 level
3 \cite{usnationalinstituteofstandardsandtechnologySecurityRequirementsCryptographic2002}. Not only has FIPS 140-2
been superseded by FIPS 140-3 since
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. 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 bit of security lead to an
unsatisfactory overall constellation.

\section{Conclusion}

In conclusion, we observe that in Germany's ePA national medical record database, despite the decade-long
standardization and implementation process, several cryptographic compromises ended up in the system's final deployment.
Even assuming that nation-scale key escrow is a good idea, the implementation of this key escrow system seems to stray
from current best practice. The system uses a secret key with only 256 bits of entropy to derive highly sensitive secret
keys for potentially tens of millions of people sharing an insurance provider. The cryptographic design of this escrow
system is unsophisticated, ignoring the past three decades in crytographic developments in particular in multiparty
computation (MPC) and other secret sharing techniques in favor of an engineering approach. In the engineering dimension,
the system's physical security is only held to the basic level 3 of the obsolete FIPS 140-2 standard, which is
considerably less secure than an average credit card payment terminal. The system's root keys are only protected by a
``hard, opaque potting material'' and no tamper detection and response is required. We estimate that the system poses an
attractive and soft target to nation-state adversaries. The system's shortcomings are made more severe by the fact that
the system disproportionally affects the lives of people with low income.

%\begin{credits}
%This is version \texttt{\input{version.tex}\unskip} of this paper, generated on \today. The git repository with the
%\LaTeX source for this paper, all hardware design files, and firmware and analysis source code can be found at:

%\center{Note: URL elided for peer review}
% \center{\url{https://git.jaseg.de/ihsm-sampling-mesh-monitor-hw.git}}
%\end{credits}

\printbibliography[heading=bibintoc]

\end{document}