Add improvements from proofreading by Lisa and Benny

chapter-epa/chapter.tex

@@ -13,27 +13,34 @@
 2025.}
 Looking at the landscape of computer security solutions, we are presented with a wide variety of vendors and products
 that may give the impression that hardware security is a solved problem. Vendors sell various claims rangning from
-\emph{You don't need hardware security, just do it in the cloud!} to \emph{Buy our HSM and you will be secure!}. In
+\emph{You don't need hardware security, just do it in the cloud!}~\cite{
+    utimacoWhatCloudHSM2025,
+    microsoftOverviewAzureCloud,
+    ibmCloudHSM2016,
+    amazonAWSCloudHSM,
+    googleCloudHSMCloud2025,
+    WhatCloudHSM}
+to \emph{Buy our HSM and you will be secure!}~\cite{utimacoUseCases,thalesLunaNetworkHardware}. In
 practice, things are not as easy and even well-intentioned projects still often go awry on the hardware security
 dimension. To motivate our research into physical security in this thesis, in this chapter we will have a look at one
 such project that was done by capable people with the best intentions, yet it resulted in a hardware security design
 that is dangerously inadequate for the purpose.
 
 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.
+record system, named ePA (short for \emph{elektronische Patientenakte}, ``electronic patient record''). 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.
+issue. While it is possible to opt out from the use of the new digital record, 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
@@ -41,11 +48,11 @@ 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 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
-with only 256 bits of entropy\footnote{
+In this chapter, we aim to point out some unconventional 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,
@@ -63,7 +70,7 @@ We base our analysis of the ePA on the system's publicly available standards in
 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
+}. 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
@@ -71,48 +78,48 @@ security of the system.
 
 \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
-description would exceed the limits of this analysis. 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.
+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 analysis. Briefly put, TI consists of a
+shared demilitarized zone (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
-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,
+card that contains a smart card with keys to authenticate towards the central infrastructure. The primary use of these
+smart cards up to now is that when an enrolled person 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 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.
+VPN, and by patients through proxy servers connected to 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.
 
 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.
+requiring consent or cooperation of the people whose records are being
+processed~\cite{gematikWhitepaperDatenschutzUnd2025}.
 
 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. 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
+duplicate user ID smartcard in case an enrolled 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 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.
 
-\section{Related Work}
+\subsection{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
@@ -197,18 +204,18 @@ 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}. 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 entropy lead
-to an unsatisfactory overall constellation.
+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 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~\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}