259 lines
17 KiB
TeX
259 lines
17 KiB
TeX
\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{Anonymous Author(s)}
|
|
\institute{}
|
|
%\author{Jan Sebastian Götte\inst{1}}
|
|
%\institute{Technical University of Darmstadt, Darmstadt, Germany, \email{research@jaseg.de}}
|
|
\title{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 insurance laws, the system's user base encompasses the majority of all German
|
|
residents. People who have replaced their public health insurance with private insurance as of now 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,
|
|
the government 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.
|
|
|
|
While there has been loud criticism of the system's security from civil society organizations such as digital rights
|
|
nonprofit organization Chaos Computer 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 the 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 this is unlikely to be the case. The reference implementation provided by the
|
|
specification authority \cite{GithubRepositoryERPFD} follows the specified 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 healthcare 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 terminated by a specialized VPN appliance named ``Konnektor'' that simultaneously hosts 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 under it is issued an 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 was 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 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 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 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}. 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 bits 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 cryptographic developments particularly 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}
|