Rework for 3.0/VAU version w/o SGD
This commit is contained in:
jaseg
parent
6937131126
commit
46da9173c5
2 changed files with 153 additions and 71 deletions
98
paper.bib
98
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}},
|
||||
|
|
|
|||
126
paper.tex
126
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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue