diff --git a/paper.bib b/paper.bib index ef0ef14..ebc80fa 100644 --- a/paper.bib +++ b/paper.bib @@ -1630,6 +1630,15 @@ keywords = {twisted-inductor} } +@online{fraunhofersitAbschlussberichtSicherheitsanalyseGesamtsystems2024, + title = {Abschlussbericht {{Sicherheitsanalyse}} Des {{Gesamtsystems ePA}} Für Alle}, + author = {{Fraunhofer SIT}}, + date = {2024-08-09}, + url = {https://www.sit.fraunhofer.de/fileadmin/dokumente/studien_und_technical_reports/Abschlussbericht_Sicherheitsanalyse_ePA_fuer_alle_Fraunhofer_SIT.pdf}, + urldate = {2025-05-16}, + file = {/home/jaseg/Zotero/storage/AD5MS92X/Abschlussbericht_Sicherheitsanalyse_ePA_fuer_alle_Fraunhofer_SIT.pdf} +} + @online{fs1M12FSC, title = {1M 12F SC/APC Singlemode Farbcodiertes LWL-Pigtail - FS.com Deutschland}, author = {FS}, @@ -1808,6 +1817,13 @@ file = {/home/jaseg/Zotero/storage/IUACRFKT/Girault et al. - 1988 - A Generalized Birthday Attack.pdf} } +@online{GithubRepositoryERPFD, + title = {Github Repository: {{eRP-FD}}/Vau-Hsm}, + url = {https://github.com/eRP-FD/vau-hsm/tree/master}, + urldate = {2025-05-16}, + file = {/home/jaseg/Zotero/storage/33V8YQTK/master.html} +} + @inproceedings{goldbergPlanarFabricationMesoscale2014, title = {Planar Fabrication of a Mesoscale Voice Coil Actuator}, booktitle = {2014 {{IEEE International Conference}} on {{Robotics}} and {{Automation}} ({{ICRA}})}, @@ -1933,6 +1949,14 @@ file = {/home/jaseg/Zotero/storage/PSGQDYRQ/Grisafi et al. - PISTIS Trusted Computing Architecture for Low-end.pdf} } +@standard{GrobkonzeptEPAFuer2023, + title = {Grobkonzept ePA für alle}, + date = {2023-12-13}, + langid = {ngerman}, + version = {1.0.0}, + file = {/home/jaseg/Zotero/storage/XRXV6BY6/Grobkonzept ePA für alle.pdf} +} + @article{grunenfelderFastSinglephotonDetectors2023, title = {Fast Single-Photon Detectors and Real-Time Key Distillation Enable High Secret-Key-Rate Quantum Key Distribution Systems}, author = {Grünenfelder, Fadri and Boaron, Alberto and Resta, Giovanni V. and Perrenoud, Matthieu and Rusca, Davide and Barreiro, Claudio and Houlmann, Raphaël and Sax, Rebecka and Stasi, Lorenzo and El-Khoury, Sylvain and Hänggi, Esther and Bosshard, Nico and Bussières, Félix and Zbinden, Hugo}, @@ -3498,17 +3522,15 @@ file = {/home/jaseg/Zotero/storage/TMI3LX3I/Melara et al. - CONIKS Bringing Key Transparency to End Users.pdf} } -@article{mennChineseGovernmentHackers2024, - entrysubtype = {newspaper}, +@online{mennChineseGovernmentHackers2024, title = {Chinese Government Hackers Penetrate {{U}}.{{S}}. Internet Providers to Spy}, author = {Menn, Joseph}, date = {2024-08-27}, - journaltitle = {The Washington Post}, - issn = {0190-8286}, url = {https://www.washingtonpost.com/technology/2024/08/27/chinese-government-hackers-penetrate-us-internet-providers-spy/}, urldate = {2025-05-15}, abstract = {Beijing’s hacking effort has “dramatically stepped up from where it used to be,” says former top U.S cybersecurity official.}, langid = {american}, + organization = {The Washington Post}, file = {/home/jaseg/Zotero/storage/4FLHNCC6/chinese-government-hackers-penetrate-us-internet-providers-spy.html} } @@ -4492,6 +4514,16 @@ file = {/home/jaseg/Sync/Research/Zotero/2020_Razaghi_Hill_Tamper detection system.pdf} } +@online{RefusingTechFascism, + title = {Refusing {{Tech Fascism}} — {{Error}} 406 {{Tech Fascism Not Acceptable}}}, + url = {https://error417.expectation.fail/406/tech-fascism-not-acceptable/essay-refusing-tech-fascism-by-tante}, + urldate = {2025-05-16}, + abstract = {An essay on Refusing Tech Fascism by Jürgen Geuter aka @tante}, + langid = {english}, + organization = {Error 417 Expectation Failed}, + file = {/home/jaseg/Zotero/storage/I6AG4WCP/essay-refusing-tech-fascism-by-tante.html} +} + @misc{renesaselectronicscorporationApplicationNoteAN2242019, title = {Application {{Note AN-224}}: {{ALVC}}/{{LVC Logic Characteristics}} and {{Applications}}}, author = {{Renesas Electronics Corporation}}, @@ -4989,11 +5021,10 @@ file = {/home/jaseg/Sync/Research/Zotero/2018_Skorobogatov_Hardware Security Implications of Reliability, Remanence, and Recovery in.pdf} } -@report{slanySicherheitsanalyseZurSicherheit2020, +@online{slanySicherheitsanalyseZurSicherheit2020, title = {Sicherheitsanalyse zur Sicherheit der kritischen Komponenten der elektronischen Patientenakte nach §291a SGB V}, author = {Slany, Wolfgang}, date = {2020-03}, - institution = {Technische Universität Graz}, url = {https://www.gematik.de/media/gematik/Medien/Newsroom/Presse/Dokumente/Sicherheitsanalyse_TU_Graz_zur_ePA_mit_Vorwort_der_gematik.pdf}, urldate = {2025-05-15}, langid = {german}, @@ -5106,6 +5137,32 @@ Archive 2: https://web.archive.org/web/20250510104017/https://de.linkedin.com/pu file = {/home/jaseg/Sync/Research/Zotero/2021_Sozio et al_Patchable Hardware Security Module (PHaSM) for Extending FPGA Root-of-Trust.pdf;/home/jaseg/Zotero/storage/D5BLNRV7/9707698.html} } +@standard{SpezifikationAktensystemEPA, + title = {Spezifikation Aktensystem ePA für alle}, + url = {https://gemspec.gematik.de/docs/gemSpec/gemSpec_Aktensystem_ePAfueralle/latest/}, + urldate = {2025-05-16}, + langid = {ngerman}, + pubstate = {2025-05-09}, + version = {1.4.1`}, + file = {/home/jaseg/Zotero/storage/7UYIC2N4/latest.html} +} + +@standard{SpezifikationFachmodulEPA2023, + title = {Spezifikation Fachmodul ePA}, + date = {2023-04-03}, + langid = {ngerman}, + version = {1.53.0}, + file = {/home/jaseg/Zotero/storage/J79W78KS/Spezifikation Fachmodul ePA.pdf} +} + +@standard{SpezifikationSchluesselgenerierungsdienstEPA2023, + title = {Spezifikation Schlüsselgenerierungsdienst ePA}, + date = {2023-03-31}, + langid = {ngerman}, + version = {1.6.0}, + file = {/home/jaseg/Zotero/storage/79DUVAQG/Spezifikation Schlüsselgenerierungsdienst ePA.pdf} +} + @article{sproHighVoltageInsulationDesign2021, title = {High-{{Voltage Insulation Design}} of {{Coreless}}, {{Planar PCB Transformers}} for {{Multi-MHz Power Supplies}}}, author = {Spro, Ole Christian and Mauseth, Frank and Peftitsis, Dimosthenis}, @@ -5369,12 +5426,10 @@ Archive 2: https://web.archive.org/web/20250510104017/https://de.linkedin.com/pu file = {/home/jaseg/Zotero/storage/ZCJLJ7JB/6484979.html} } -@video{tschirsichHackerHinOder0100, - entrysubtype = {video}, +@online{tschirsichHackerHinOder0100, title = {"{{Hacker}} Hin Oder Her": {{Die}} Elektronische {{Patientenakte}} Kommt!}, shorttitle = {"{{Hacker}} Hin Oder Her"}, - editor = {Tschirsich, Martin and Brodowski, cbro-Dr med Christian and Zilch, Dr André}, - editortype = {director}, + author = {Tschirsich, Martin and Brodowski, cbro-Dr med Christian and Zilch, Dr André}, year = {01:00:00 +0100}, url = {https://media.ccc.de/v/36c3-10595-hacker_hin_oder_her_die_elektronische_patientenakte_kommt}, urldate = {2025-05-15}, @@ -5383,12 +5438,10 @@ Archive 2: https://web.archive.org/web/20250510104017/https://de.linkedin.com/pu file = {/home/jaseg/Zotero/storage/XVJB3U43/36c3-10595-hacker_hin_oder_her_die_elektronische_patientenakte_kommt.html} } -@video{tschirsichKonnteBisherNoch0100, - entrysubtype = {video}, +@online{tschirsichKonnteBisherNoch0100, title = {„{{Konnte}} Bisher Noch Nie Gehackt Werden“: {{Die}} Elektronische {{Patientenakte}} Kommt - Jetzt Für Alle!}, shorttitle = {„{{Konnte}} Bisher Noch Nie Gehackt Werden“}, - editor = {Tschirsich, Martin and Kastl, Bianca}, - editortype = {director}, + author = {Tschirsich, Martin and Kastl, Bianca}, year = {00:00:00 +0100}, url = {https://media.ccc.de/v/38c3-konnte-bisher-noch-nie-gehackt-werden-die-elektronische-patientenakte-kommt-jetzt-fr-alle}, urldate = {2025-05-15}, @@ -5405,6 +5458,23 @@ Archive 2: https://web.archive.org/web/20250510104017/https://de.linkedin.com/pu file = {/home/jaseg/Sync/Research/Zotero/Tyagi et al_Orca.pdf} } +@standard{UbergreifendeSpezifikationVerwendung2024, + title = {Übergreifende {{Spezifikation Verwendung}} Kryptographischer {{Algorithmen}} in Der {{Telematikinfrastruktur}}}, + date = {2024-02-23}, + url = {https://gemspec.gematik.de/downloads/gemSpec/gemSpec_Krypt/gemSpec_Krypt_V2.28.1.html}, + urldate = {2025-05-16}, + version = {2.28.1}, + file = {/home/jaseg/Zotero/storage/4G4DKG53/gemSpec_Krypt_V2.28.1.html} +} + +@standard{UebergreifendeSpezifikationVerwendung, + title = {Übergreifende Spezifikation Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur}, + langid = {ngerman}, + pubstate = {2025-03-28}, + version = {2.40.0}, + file = {/home/jaseg/Zotero/storage/PTWL3X45/Übergreifende Spezifikation Verwendung kryptograph.pdf} +} + @report{usnationalinstituteofstandardsandtechnologySecurityRequirementsCryptographic2002, title = {Security {{Requirements}} for {{Cryptographic Modules}}}, author = {{(US) National Institute of Standards and Technology}}, diff --git a/paper.tex b/paper.tex index 2bc3aee..0872d54 100644 --- a/paper.tex +++ b/paper.tex @@ -50,10 +50,10 @@ cryptography and information security community has been largely non-existent. In this paper, we want to raise awareness of the system's existance, and based on the system's public specifications, we want to highlight some moderately spicy cryptographic engineering decisions. In particular, most sensitive, long-term user keys in the - system are derived by a simple, home-grown centralized key escrow system comprising of two HSMs from a per-use salt - and only 1024 bit of entropy shared globally across millions of users. Physically, only the insecure level 3 of the - obsolete FIPS 140-2 security standard (requiring ``hard, opaque potting'' but no active tamper sensing) is required - in the system's standardization, leaving it open to attacks by nation-state and other well-funded adversaries. + system are derived by an unsophisticated, home-grown centralized key escrow system from a per-use salt and only 256 + bit of entropy shared globally across millions of users. Physically, only the insecure level 3 of the obsolete FIPS + 140-2 security standard (requiring ``hard, opaque potting'' but no active tamper sensing) is required in the + system's standardization, leaving it open to attacks by nation-state and other well-funded adversaries. \end{abstract} \section{Introduction} @@ -76,27 +76,39 @@ comprehensive understanding of the system's benefits and risks that would be nec opting out. While there has been loud criticism of the system's security from civil society organizations such as digital rights -nonprofit Chaos Commputer Club (CCC) 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, the system has received very little attention from the academic cryptography and information security -community. +nonprofit organization Chaos Commputer Club (CCC) 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 wish to point out some spicy cryptographic engineering decisions in the system. In particular, we point out that the system's core per-user secrets are kept in an unsophisticateed 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 pair of system-wide long-term -secrets with a combined entropy of only 1 kbit. Finally, we note that according to specification, the only physical -security requirement for the protection of these highly sensitive secrets is a ``hard, opaque potting material'', with -no tamper detection and response required. +individual user keys of the system are derived from a per-user cleartext salt based a system-wide long-term +secret with only 256 bits of entropy\footnote{ + % FIXME reference + In previous versions of the standard\cite{ + SpezifikationSchluesselgenerierungsdienstEPA2023, + UbergreifendeSpezifikationVerwendung2024 + }, 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. 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. 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. +April 2025, describing version 3.0 of the healthcare record system\cite{ + UebergreifendeSpezifikationVerwendung, + SpezifikationAktensystemEPA +}. 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 +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 @@ -109,35 +121,34 @@ 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 reached through the TI's VPN, and encryption and +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 primary services offered by the server side are authentication services, one of two instances of the key escrow -service (``Schlüsselgenerierungsdienst'' or SGD), a database storing wrapped record keys, and a database storing the -encrypted records themselves. Records are symmetrically encrypted twice. One encryption layer is done at the client -side, inside the Konnektor, and the other encryption layer is processed inside a trusted execution environment (TEE, -tranlated to ``VAU'' in the German specifications) at the server side. The keys for both encryption layers are wrapped -and unwrapped in the Konnektor, and the wrapped keys are stored in the key database on the server side. For wrapping, -two layers of encryption are used with a second set of two keys. This second set of keys is generated by the key escrow -service every time the record is accessed. To generate these keys, the Konnektor separately requests them from each of -two instances of the escrow service. One of these instances is run as part of the insurance provider's server -infrastructure. The other instance is a single instance for the whole system shared across all insurance providers. This -instance is run by a state-owned company. When a new record is created, each of these escrow services generates a salt -that is stored along with the wrapped keys. The keys are deterministically generated from the escrow service's master -key, this salt, and the healthcare ID number of the person owning the record. According to the standards, this key -derivation step must be done inside of a Hardware Security Module (HSM). The specification requires new master keys to -be generated every six months, but does not include provisions for a true key rollover. Instead, old master keys have to -be kept around indefinitely such that the records encrypted under them remain accessible. +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 two academic security assessments of the system relating to -the key escrow service: \textcite{fischlinKryptographischeAnalyseSpezifikation2021} focuses on the cryptographic -dimension of the key escrow service. \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. We -are not currently aware of independent academic security research on the system. +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 @@ -148,7 +159,8 @@ practical attacks on various parts of the system's implementation. \section{Interesting Cryptographic Engineering Choices} In this paper, we wish to highlight some of the design choices in the system that we believe stray from current best -practice. +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} @@ -167,12 +179,12 @@ 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. +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 each of the two key escrow services every time record keys are requested. Along with the timing and frequency of -these requests, this leaks information on the person's condition to both instances of the key escrow service in an -identifiable way. +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} @@ -189,8 +201,8 @@ attacks on national digital infrastructure are a realistic concern. 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. In particular, 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 these HSMs is only FIPS 140-2 level +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 @@ -198,9 +210,9 @@ provides logical separation of cryptographic functions from other logic and is n 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, it does not make any particular requirements regarding resistance to +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 key escrow master key inside the HSM to have 512 bit of security combined lead to an +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} @@ -208,15 +220,15 @@ unsatisfactory overall constellation. 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 secret keys with only 1 kbit of entropy to derive highly sensitive secret -keys for several tens of millions of people. The cryptographic design of this escrow system is primitive, ignoring the -past three decades in crytographic developments in particular in multiparty computation (MPC) and other secret sharing -techniques in favor of an unsophisticated 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 low-entropy secret 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. +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