1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
---
title: "75 Million Lives, Two Keys"
date: 2025-01-05T23:42:00+01:00
draft: true
---
2025 has begun. In this new year, with its new national healthcare record system, the country of Germany will start one
of the largest rollouts of a cryptographic system in history. While the system has received scrutiny as well as
resulting harsh criticism from a number of parties ranging from NGOs to everyday civilians, the system has received
surprisingly little attention from the academic applied cryptography crowd. Additionally, previous criticism of
the system has largely revolved around organizational issues. While valid, we belive that some cryptographic issues at
the core of the system have escaped attention unitl now. In particular, at the core of the system is a key escrow system
that contains several questionable design choices and that in its overall design seems out of place in 2025.
The aim of the system is to serve as a shared storage for all healthcare records of a person. In the system, a person's
entire patient file with all documentation on the treatment process including test results, images and other raw data
will be stored in something vaguely resembling cloud storage such that all healthcare providers that the person visits
can access the entire file. This centralized, synchronized storage eliminates the need for transferring this data
between hospitals and doctors offices by fax, mail or physical media as it was common practice until now. After a
development and testing phase lasting approximately five years, the German government decided to roll out the system to
everybody insured under Germany's mandatory national health insurance scheme, totalling approximately 75 million people,
on January 15th 2025.
In this article, we will give an overview of the system's cryptographic design before highlighting a few odd
design choices that could amount to a viable attack vector to the powerful adversaies
## Context and involved parties
Germany has a national, mandatory health insurance system. The system is open to any permanent resident of the country
irrespective of citizenship. The system is mandatory in that while residents can choose between a number of both
publically owned as well as private healthcare providers, it is not possible to opt out of the system. The public health
insurance providers cover approximately 90% of German residents. These providers are organized in an umbrella
organization named "GKV Spitzenverband". The resposibility of this umbrella organization largely revolves around
negotiating prices with pharmaceutical companies and with healthcare providers as a publically sanctioned cartel, but
also includes the specification and operation of shared IT infrastructure for billing and data exchange between
healthcare providers.
While GKV Spitzenverband is the party that ultimately holds responsibility for the regulatory administration of national
healthcare IT infrastructure, it has delegated large parts of both the technical specification of this infrastructure as
well as its day-to-day operation to Gematik GmbH, a state-owned limited liability corporation created specifically for
the purpose of developing and implementing national healthcare IT standards. The electronic healthcare record system we
describe in this article was standardized and implemented by Gematik GmbH under the direction of GKV Spitzenverband.
Healthcare providers in Germany need to be registered with GKV Spitzenverband to serve members of public health
insurance providers. Since these public providers constitute approximately 90% market share, the vast majority of
healthcare providers are registered this way.
Before the new national health record system, a number of healthcare IT processes have already been standardized and
implemented by the parties above. In particular, every insured person already owns a cryptographic smartcard that acts
as their proof of identity when accessing healthcare services. On the other side of such transactions, healthcare
providers are likewise identified by cryptographic smartcards. Until now, these cards were used to facilitate billing of
services from healthcare providers to insurers and to transfer prescriptions from prescribing doctors to pharmacies.
A central role in this existing infrastructure is assumed by VPN gateways that link healthcare providers to
the centrally-run backend infrastructure. Gematik GmbH calls these devices "Konnektor". They are specially-built
hardware devices that contain multiple smart cards to authenticate the VPN connection towards the backend, and besides
acting as a standard VPN gateway for client applications in the healthcare provider's network to tunnnel their backend
requests through, the Konnektors also perform cryptographic operations in some of Gematik GmbH's protocols, such as
authenticating certain requests using signatures.
## Design principles
The new health record system was built on top of the existing infrastructure described above. In particular, access to
health records is managed through keys stored in the patient's and the healthcare provider's existing smartcards, and
all backend communication is tunneled through the existing VPN. Access to the files is mediated through the healthcare
provider's existing patient management software. While in early drafts of the system, access to healthcare records
through the patient's smartcard was gated behind a PIN, the impracticality of making the entire patient populace
remember PINs led the implementors to scrap this provision, meaning that the patient's smartcard is all a healthcare
provider needs to access the patient's record.
A critical cornerstone in the system's design is that the system's designers decided that a lost smartcard should not
lead to any data loss. As a consequence of this decision, while some of the record's access keys are kept on the
patient smartcard, in contravention to conventional smartcard designs the same keys are kept accessible in a centralized
key escrow system named "Schlüsselgenerierungsdienst" and abbreviated as SGD. Furthermore, these keys are not generated
on the smartcard either -- instead, the key escrow system generates these access keys, one copy of which is then
transmitted and stored inside the smartcard.
The system supports re-issuing a smartcard to gain access to a healthcare record. Since the record's privacy pivots on
this process, the system incorporates some organziational countermeasures that aim to make it hard to gain access to a
re-issued copy of a patient smartcard without the patient's help or otherwise multiple colluding parties.
## Cryptographic design
## The implied adversary model
While Gematik GmbH publishes detailed specifications of the systems they standardize, these specifications and some
associated implementation guidelines are about the extent of public information. Software implementations are being kept
secret, and while standardization results are available, a large fraction of design rationale is discussed behind closed
doors. From an academic perspective, the most glaring omission in Gematik GmbH's public documents is any definition of a
threat model or an adversary model. As a result of this, we will deduce an adversary model below by contextualizing the
published standards in the national healthcare setting. We will base our further analysis of the system on this
adversary model.
## Previous reviews and audits of the system
[0] https://www.destatis.de/DE/Themen/Arbeit/Arbeitsmarkt/Qualitaet-Arbeit/Dimension-2/krankenversicherungsschutz.html
|
