More notes from leo included
This commit is contained in:
parent
2584232b70
commit
75c0da19d8
2 changed files with 48 additions and 40 deletions
|
|
@ -10,38 +10,39 @@
|
|||
\label{chapter-epa}
|
||||
|
||||
\todo{FIXME: Proper citation here}
|
||||
\sourceattrib{This part is based on a short paper written by me and presented by me at the HS3 workshop at ESORICS
|
||||
2025.}
|
||||
\sourceattrib{This part is based on a short paper written by me and presented by Jan Sebastian Götte at the HS3 workshop
|
||||
at ESORICS 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!}~\cite{
|
||||
\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
|
||||
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, 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.
|
||||
record system, named ePA (short for \emph{elektronische Patientenakte}, ``electronic patient
|
||||
record'')~\cite{kochNochVieleUnklarheiten2025}. 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 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.
|
||||
residents, approximately 90\textpercent. 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 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
|
||||
|
|
@ -49,7 +50,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 chapter, we aim to point out some unconventional cryptographic engineering decisions in the system. In
|
||||
In this chapter, we aim to highlight 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
|
||||
|
|
@ -61,40 +62,35 @@ long-term secret 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. 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.
|
||||
highly sensitive secret is a ``hard, opaque potting material'', with no tamper detection and response required.
|
||||
|
||||
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
|
||||
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
|
||||
security of the system.
|
||||
}. We note that hypothetically, the implementation might deviate from these standards and be more secure. 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 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 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.
|
||||
ePA is embedded into Germany's national public healthcare backend system ``Telematikinfrastruktur'' (abbreviated TI;
|
||||
German for ``telematics infrastructure''). 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 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.
|
||||
smart cards previously was to automatically provide personal information such as name, birth date, address and insurance
|
||||
enrollment status when an enrolled person visits a healthcare provider.
|
||||
|
||||
ePA is implemented inside the TI system. Its centralized services are accessed by healthcare providers through the TI's
|
||||
VPN, and by patients through proxy servers connected to TI's VPN. Patient records are encrypted and decrypted inside
|
||||
|
|
@ -104,8 +100,8 @@ 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
|
||||
management delegated to a Hardware Security Module (HSM). 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~\cite{gematikWhitepaperDatenschutzUnd2025}.
|
||||
|
|
|
|||
12
main.bib
12
main.bib
|
|
@ -3776,6 +3776,18 @@
|
|||
organization = {heise online}
|
||||
}
|
||||
|
||||
@online{kochNochVieleUnklarheiten2025,
|
||||
title = {Noch viele Unklarheiten bei der elektronischen Patientenakte},
|
||||
author = {Koch, Marie-Claire},
|
||||
date = {2025-05-08},
|
||||
issn = {1037-7344},
|
||||
url = {https://www.heise.de/hintergrund/Elektronische-Patientenakte-Welche-Unklarheiten-es-noch-gibt-10377344.html},
|
||||
urldate = {2025-11-28},
|
||||
abstract = {Rund um die elektronische Patientenakte gibt es noch viele offene (Sicherheits-)Fragen. Dabei ist sie gerade erst bundesweit gestartet, zumindest theoretisch.},
|
||||
langid = {ngerman},
|
||||
organization = {heise online}
|
||||
}
|
||||
|
||||
@inproceedings{kodwaniSecurityKeyDerivation2021,
|
||||
title = {On {{Security}} of {{Key Derivation Functions}} in {{Password-based Cryptography}}},
|
||||
booktitle = {2021 {{IEEE International Conference}} on {{Cyber Security}} and {{Resilience}} ({{CSR}})},
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue