WIP
This commit is contained in:
jaseg
parent
35f9c1cff7
commit
bc7a3e3d34
3 changed files with 25 additions and 19 deletions
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
\chapterquote{attributed to Grace Hopper\cite{
|
||||
WikiQuoteGraceHopper,
|
||||
QuoteOriginMost2014
|
||||
QuoteOriginMost2014,
|
||||
}}{
|
||||
The most dangerous phrase in the language is ``We've always done it this way!''.
|
||||
}
|
||||
|
|
@ -39,7 +39,7 @@ been demonstrated practically, this criticism has largely been ignored by the po
|
|||
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 section, we aim to point out some perplexing cryptographic engineering decisions in the system. In particular,
|
||||
In this chapter, 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
|
||||
|
|
@ -51,10 +51,14 @@ with only 256 bits of entropy\footnote{
|
|||
The current standard only requires one escrow service, and drops the entropy requirement of the root keys from 512
|
||||
bits to 256 bits. The apparent reason for the long-term nature of these keys is that they are updated manually.
|
||||
}. 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.
|
||||
highly sensitive secret is a ``hard, opaque potting material'', with no tamper detection and response required. We
|
||||
belive that Inertial HSMs provide a path forward for systems like this, enabling physical security in applications that
|
||||
currently rely on insecure, legacy systems. Even if for regulatory reasons a poorly secured conventional HSM without
|
||||
active tamper sensing is chosen, it would be conceivable to construct an IHSM enclosure \emph{around} this conventional
|
||||
HSM, in effect retrofitting the missing active tamper-sensing envelope.
|
||||
|
||||
We base our analysis on the system's publicly available standards in their latest version as of the writing of the paper
|
||||
underlying this section in April 2025, describing version 3.0 of the healthcare record system \cite{
|
||||
We base our analysis of the ePA on the system's publicly available standards in their latest version as of the writing
|
||||
of the paper underlying this chapter 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
|
||||
|
|
@ -63,7 +67,7 @@ specification authority \cite{GithubRepositoryERPFD} follows the specified minim
|
|||
there is no meaningful way for either the public or for researchers such as us to ascertain the concrete implementation
|
||||
security of the system.
|
||||
|
||||
\subsection{The Design of ePA}
|
||||
\section{The Design of ePA}
|
||||
|
||||
ePA (short for \emph{elektronische Patientenakte}, ``electronic patient record''), is embedded into Germany's national
|
||||
public healthcare backend system ``Telematikinfrastruktur'' (TI). TI is a highly complex system, and a detailed
|
||||
|
|
@ -106,7 +110,7 @@ that a new root key is generated once a year, but as far as we can tell, record
|
|||
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.
|
||||
|
||||
\subsection{Related Work}
|
||||
\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
|
||||
|
|
@ -123,12 +127,12 @@ could trivially acquire each of the smartcards as well as the Konnektor necessar
|
|||
\textcite{tschirsichKonnteBisherNoch0100} summarize the history of attacks demonstrated on the system and show multiple
|
||||
practical attacks on various parts of the system's implementation.
|
||||
|
||||
\subsection{Concerning Cryptographic Engineering Choices}
|
||||
\section{Concerning Cryptographic Engineering Choices}
|
||||
|
||||
We wish 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.
|
||||
|
||||
\subsubsection{Use of Key Escrow}
|
||||
\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
|
||||
|
|
@ -144,7 +148,7 @@ surface \cite{
|
|||
andersonSecurityEngineeringGuide2020,
|
||||
}.
|
||||
|
||||
\subsubsection{Cryptographic Design}
|
||||
\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
|
||||
|
|
@ -163,7 +167,7 @@ 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.
|
||||
|
||||
\subsubsection{A Realistic Attacker Model}
|
||||
\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
|
||||
|
|
@ -185,7 +189,7 @@ an advanced physical attack, then being able to decrypt captured encrypted healt
|
|||
nation-state adversary might have access to an exploit allowing the compromise of the system's TEEs, which would enable
|
||||
the extraction of any patient records being processed in plaintext inside these TEEs.
|
||||
|
||||
\subsubsection{Physical Security}
|
||||
\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
|
||||
|
|
@ -203,7 +207,7 @@ to side-channel attacks. The lack of tamper response, unspecified resistance to
|
|||
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.
|
||||
|
||||
\subsection{Conclusion}
|
||||
\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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue