Camera-ready WIP

paper.tex

@@ -63,7 +63,7 @@
     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
+    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.
@@ -103,7 +103,7 @@ bits of entropy\footnote{
         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.
+    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.
 
@@ -119,12 +119,17 @@ 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.
+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
+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, usually an individual doctor's
+office or a hospital, this VPN connection is terminated by a specialized VPN appliance named ``Konnektor'' that
+simultaneously acts as a trusted component inside the client network hosting some software for purposes such as
+authentication. The Konnektor contains several smart cards that store keys used for authentication. Konnektor devices
+are offered by several vendors and healthcare providers like doctor's offices are indivudally responsible for purchasing
+and maintaining a Konnektor.
+
+% FIXME: Is there a threat/trust model of the system that you could summarise in a few sentences?
 
 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
@@ -132,23 +137,28 @@ use of these smart cards up to now is that when someone visits a healthcare prov
 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.
+ePA is implemented inside the TI system. Its centralized services are accessed by healthcare providers through the TI's
+VPN. Patient records are encrypted and decrypted inside TI's backend systems. Smart cards authenticate parties and
+hardware devices 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.
+With the current version of the specificatoin, the overall architecture of ePA heavily relies on Trusted Execution
+Environments (TEEs). Data processing on the server side is done in plaintext inside 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
+motivation for plaintext processing seems to be to enable large-scale data analysis for research purposes without
+requiring consent or cooperation of the people whose records are being processed.
 
 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.
+inside an HSM. The primary motivation behind the use of a key escrow service seems to be to enable the creation of a
+duplicate patient ID smartcard in case a person looses theirs. 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, 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.
 
 \section{Related Work}
 
@@ -195,23 +205,40 @@ The system's overall cryptographic design is intentionally kept simple. The stan
 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 key escrow service by reducing trust placed in any single component of the service are also absent while the system
+relies extensively on the engineering-based security guarantees of TEEs and HSMs. Given that the ePA system trusts its
+HSMs as unconditionally secure, it is unclear what purpose the manual yearly root key renewal serves, especially absent
+an automatic way to roll over the wrapped record keys.
 
-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.
+A consequence of the systems' simple cryptographic design is that 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.
+
+% 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 \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
+series of practical attacks that have been demonstrated on the system confirm this impression. In
+\textcite{tschirsichKonnteBisherNoch0100} 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 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.
+attacks on national digital infrastructure are a realistic concern. A possible scenario in the ePA system would be an
+enemy secret service gaining access to one of the HSMs storing the systems' root secrets, extracting the root secret by
+an advanced physical attack, then being able to decrypt captured encrypted health records at will. Similarly, a
+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.
 
 \subsection{Physical Security}
 
@@ -221,15 +248,15 @@ cryptographic secrets. The core of the system's key escrow service is implemente
 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.
+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}