A SHORT OVERVIEW OF THE SECURITY CONCEPT OF THE

GERMAN ELECTRONIC HEALTH INFORMATION

INFRASTRUCTURE

Stefan Knipl and Ali Sunyaev

Faculty of Management, Economics and Social Sciences, University of Cologne, Pohligstraße 1, 50969 Cologne, Germany

Keywords:

Security analysis, Healthcare telematics, Electronic health card, Information systems security, Healthcare IS

security.

Abstract:

Germany is about to introduce a nation-wide healthcare telematics system, intending to connect existing in-

formation systems of all stakeholders. This could result in new threats to highly sensitive medical data. In

this paper we shortly describe the security concept itself and point out a few possible problems at reaching the

goals of information security.

1 INTRODUCTION

Stakeholders of the German health care system are

not interconnected. Since the health insurance card

currently in use in Germany is not a smart card it is

therefore not able to provide secure transfer of med-

ical data, thus preventing nationwide data crosslink-

ing. This is about to change with the introduction of a

new electronic health card in Germany (Schweiger et

al., 2007).

The rollout of the electronic health card is on its way,

hopefully leading to reduced costs in the health sys-

tem, while boosting efﬁciency. Critics fear that one of

its biggest strengths - merging information and mak-

ing it available to care providers- may become a prob-

lem. This data is extremely sensitive and must not

get in the hands of unauthorized persons. This paper

analyzes to which extent this has been conceptually

prevented.

2 SECURITY CONCEPT

This chapter describes the essential layout of the se-

curity concept of the German HTI.

2.1 EHC, HPC and SMC-B

Electronic health card (EHC), health care profes-

sional card (HPC) and security module card of type

B (SMC-B) are the essential smart cards used in the

HTI. Their memory is split in two parts: one is pro-

tected, containing secret keys and valuable data, the

other one being not protected especially.

Accessing data in the protected area is possible by

using one of three personal identiﬁcation numbers

(PIN). The gematik prohibits unprotected transfer of

PINs, read-out of keys or being able to create a clone

of a card (gematik, 2008b, p.69). The secret keys can

be decrypted by entering the right PIN.

EHC PINs often will not be needed for a longer period

of time and thus could easily not remain memorized

or get mixed up. Patients could therefore use a se-

quence of numbers that is easy to remember (and thus

easy to guess) or just write down the PINs and put

them next to the EHC. Astolen card may then lead to

the loss of conﬁdentiality.

If a card has to be replaced, there has to be a possi-

bility to access the data stored in the HTI (gematik,

2009b, p.46). To enable data transcoding a secret

key is divided in parts and given to trustees (gematik,

2009b, p.60). However, this concept is not yet fully

deﬁned.

2.1.1 Pseudonymization and Anonymization

Data minimization, pseudonymization and

anonymization are the means of choice to save

as little personal data as necessary (gematik, 2009a,

p.16).

Pseudonymization is used for the EHC. There are

further pseudonymized certiﬁcates, not issued on the

plain name of an insured person. If, however, one has

555

Knipl S. and Sunyaev A..

A SHORT OVERVIEW OF THE SECURITY CONCEPT OF THE GERMAN ELECTRONIC HEALTH INFORMATION INFRASTRUCTURE.

DOI: 10.5220/0003155705550558

In Proceedings of the International Conference on Health Informatics (HEALTHINF-2011), pages 555-558

ISBN: 978-989-8425-34-8

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

larger amounts of data of one single pseudonym then

de-pseudonymization may be possible. Since insured

persons get a new pseudonym with every EHC (i.e.

at least every ﬁve years) in most cases this should

be no real danger. More signiﬁcantly, card issuers

could perform a de-pseudonymization. This can only

be done by a few selected people and only if the

data protection ofﬁcial of the card issuer is involved

(gematik, 2008a, p.170f).

If data is exchanged with a health insurance then care

providers always have to be anonymized (gematik,

2008b, p.31). In addition the institution of a care

provider has to be anonymized when querying

insured person’s master data (gematik, 2009b, p.38).

This way one seeks to prevent the possibility of

creating proﬁles of insured persons.

2.1.2 Data Access, Preservation and

Transferability

Access on EHC, HPC or SMC-B is only allowed us-

ing the connector. However, the connector will not be

available from start, so it may be set aside (gematik,

2009b, p.39), meaning that card readers can be di-

rectly connected to the clients of care providers. Once

connectors are available the protected parts of insured

persons’ master data can then be saved to the pro-

tected area of the EHC. Until then they may temporar-

ily be saved to the freely readable part of the EHC (for

a time period not yet deﬁned) (gematik, 2009a, p.15),

as is the current state of health insurance cards (HIC).

Insured persons have the possibility to access their

own data with write access to emergency records and

read access to the rest. Since prescriptions are rela-

tively often ﬁlled by proxy persons the delegation of

these rights to other insured persons will be possible

(gematik, 2009b, p.92).

Every access to an EHC or into the HTI will be au-

dited. Access will not be granted if auditing fails.

Replacing an EHC does not mean loss of data, since

existing data stored in the HTI can be transcoded.

2.2 Public Key Infrastructures

A public key infrastructure (PKI) is a trustworthy unit

helping to check certiﬁcate validity and issuing new

certiﬁcates. That way requests can only be conducted

by registered components and can be veriﬁed, pre-

venting man in the middle attacks and replay attacks.

Mutual checks happen on all levels in the HTI. The

smart cards that are used can perform such a check

with a few restrictions even without availability of the

HTI by using Card Veriﬁable Certiﬁcates (CVCs).

Certiﬁcates that are necessary for authentication must

contain the role of certiﬁcate owners (gematik, 2009b,

p.309). Otherwise a role assignment register would be

needed. The PKIs in the HTI provide the possibility to

verify X.509 certiﬁcates and CVCs (gematik, 2009b,

p.49). The PKI in the HTI is divided in two parts: one

for infrastructure, and one for persons and institutions

(gematik, 2009b, p.141). It will not be possible to use

services in the HTI by fraud with a fake certiﬁcate.

Additionally a security alarm would be executed by a

failed authentication (gematik, 2008b, p.127), allow-

ing counter measures.

Requesting certiﬁcate state is done by using the On-

line Certiﬁcate Status Protocol (OCSP).In exceptional

cases certiﬁcate revocation lists (CRLs) are allowed

(gematik, 2009b, p.142). OCSP does not use black-

listing. It returns the state in the CA data base, making

a revocation immediately active. OCSP answers may

be cached, but there is no severe threat that a revoked

certiﬁcate will be seen as valid by mistake, since they

are rarely used in such short intervals (the cache nor-

mally lasts 12 to 24 hours) (gematik, 2009b, p.303f).

It has to be considered as critical that non-availability

of a revocation list of integrity must not lead to the

result of all objects being considered as revoked as a

precaution (gematik, 2008b, p.78). If the PKI is avail-

able, but no data of revoked objects can be accessed

then all certiﬁcates had to be accepted if there were

no contradictory data cached. Availability would oth-

erwise not be given, but at least a security alert should

be executed.

CVCs allow smart cards to independently verify cer-

tiﬁcates. They are used for mutual authentication

of EHCs, HPCs and SMC-As/-Bs (gematik, 2008b,

p.68). Since the public certiﬁcate of the issuing CA is

known (gematik, 2008b, p.82), validity veriﬁcation is

directly possible. However it is not possible to verify

if a CVC has been revoked. Corresponding X.509 cer-

tiﬁcates are veriﬁed when using services in the HTI.

A revoked card may therefore not be misused if at-

tackers can not also disrupt the availability of the HTI

at the same time.

2.3 Data Transfer and Data Storage

Connection between card reader and connector is

encrypted and mutual authentication is required

(gematik, 2008b, p.51). Since part of the connec-

tion to professional services lie in the internet it is

open for attacks. Therefore connectors have to be

approved (gematik, 2008a, p.238) and they possess

an integrated VPN client, allowing a connection us-

ing IPSec and mutual authentication (gematik, 2008b,

p.121). At the other end of the connection a ﬁrewall

should be passed before reaching a VPN concentra-

tor, which may also include a packet ﬁlter (gematik,

HEALTHINF 2011 - International Conference on Health Informatics

556

2008b, p.120). Furthermore a VPN concentrator may

not contain any backdoors in its software (gematik,

2008b, p.121).

Components in the care provider region should ver-

ify integrity and authenticity of the services they con-

tacted (gematik, 2008a, p.155). Regarding security

this should be obligatory.

It is not assumed that the inner regions of the HTI

can not be reached by external attackers or are free of

internal attackers, so transfer of unencrypted personal

data has been prohibited (gematik, 2008a, p.153). Ad-

ditionally plain text protocols, such as FTP, are not

allowed to use (gematik, 2008b, p.98), as well as

is the case for operating WLANs (gematik, 2008e,

p.20). Between regions demilitarized zones (DMZ)

should be established (gematik, 2008b, p.98). Fur-

thermore intrusion prevention systems (IPS) may be

used (gematik, 2008b, p.98). Employed ﬁrewalls

may only open necessary ports and only allow con-

nections as far as they are needed for providing ser-

vices (gematik, 2008a, p.124). Additionally measures

have to be taken to prevent spooﬁng (gematik, 2008b,

p.97f). Unique message identities have to be assured

to prevent replay attacks (gematik, 2009b, p.193).

XML signature and encryption are used (gematik,

2009b, p.108) to provide consistent end-to-end au-

thentication and encryption on application layer.

Storage of data in the HTI is achieved in form of

data objects encrypted with a symmetric encryption

method. It is necessary to access an “object ticket”

containing the symmetric key to the data objects. Ob-

ject tickets contain a list of entitled persons, who may

access this symmetric key. Insured people themselves

are always entitled and able to entitle others.

It is important to prevent accesses without insured

person’s approval (gematik, 2009b, p.43), since this

would mean compromising conﬁdentiality.

2.4 NTP Service

It is necessary that all service in HTI got nearly the

same system time to prevent replay attacks and CVCs

with expired validity date to be seen as valid. The

NTP service is periodically called by all systems in

all regions answering with the current time. In total

there have to be at least four servers to recognize a

server returning a different wrong time to each client,

respectively three servers to detect a server respond-

ing with a time shifted by a constant factor (”false

ticker”). There must be at least four servers in the

HTI and each data center must include at least three

servers to still be able to detect false tickers if other

data centers should not be available (gematik, 2008a,

p.139f). Additionally all components accept no time

changes of more than 1000 seconds. Since time may

not be changed by entire hours or days, such an attack

may fairly easily be noticed and will not be useful for

exploitation.

2.5 Broker

A connector must contact a broker before it is granted

access to professional services. The broker contains

of the auditing service, the trusted service and the ser-

vice directory service.

The auditing service is logging all attempts of ac-

cesses to realize legal certainty. The broker does

not forward requests as long as auditing has not suc-

cessfully been completed (gematik, 2008b, p.115f).

Directly contradicting is the speciﬁcation that “non-

accessibility respectively non-availability of the au-

diting service MUST NOT lead to a complete stag-

nancy of the telematics infrastructure” (gematik,

2008b, p.114), especially since the auditing service

has to be established in a redundant way (gematik,

2008b, p.114).

The Service Directory service (SDS) lists all ser-

vices available in the HTI and their URLs. Items are

added after compatibility testing and approval by the

gematik (gematik, 2009b, p.196f). If attackers would

be able to add an entry this would have no effect, if

they could not also add an entry in the DNS service.

However there would be consequences if attackers

could change the URL of an existing entry. Without

being able to change DNS entries requests could not

be redirected to a fake server, though it could affect

availability of a service. Changes in the SDS are able

after successful authentication (gematik, 2007, p.32f).

If it can be assured that employees handle their X.509

certiﬁcates carefully damage potential in this area is

low. It should be considered if the four-eyes principle

could be applied here since otherwise availability of

essential parts of the HTI may be lowered.

2.6 DNS Service

The DNS service answers requests with the IP address

corresponding to a given mnemonic address. DNS

service is built in a redundant way, arranged in multi-

ple levels. Precautions should be taken so that a syn-

chronisation between different levels may not be able

for unauthorized persons (gematik, 2008b, p.92f). It

is therefore an attempt to achieve security by obscu-

rity. Security of a system may not rely on this lack of

knowledge.

To prevent attackers from redirecting requests away

from valid services, DNSSEC will be used (gematik,

2008f, p.45), guaranteeing authenticity and integrity

A SHORT OVERVIEW OF THE SECURITY CONCEPT OF THE GERMAN ELECTRONIC HEALTH INFORMATION

INFRASTRUCTURE

557

of DNS transactions, although facilitating denial of

service attacks because of its high calculation effort.

Thus the number of DNS requests is permanently

monitored. If a threshold is exceeded a security alert

is executed (gematik, 2008b, p.87).

2.7 Connector and Extended Trusted

Viewer

Connectors have a device speciﬁc identity in form of

a X.509 certiﬁcate. Only VPN concentrators will be

accepted as remote points, forwarding a connection

to the broker. It has to be assured that the key of

a connector’s SMC-B may not be read out (gematik,

2008b, p.54) to assure connector integrity. A connec-

tor must be able to reliably detect spooﬁng of wrong

system times. Besides, keys that are not trustworthy

may not be adopted and data that needs to be pro-

tected may not be transferred unencrypted (gematik,

2008b, p.54f). Lastly, it also may not be possible to

sign data, that a signer did not want to sign (gematik,

2008b, p.55f). This will be done by an Extended

Trusted Viewer (xTV). The necessary X.509 identity

of an xTV can also be deposited in the connector. If a

signature should be performed it shows the certiﬁcate

of the signer and the document to be signed, else the

result of certiﬁcate validation (gematik, 2009c, p.38).

An xTV can be realized by a software solution as well

as by suitable hardware.

2.8 Cryptographic Speciﬁcations

Generally medical data may exclusively be stored and

transferred in encrypted state (gematik, 2008a, p.95).

Cryptographically the principle of forward secrecy is

continuously implemented. If a key of lower level

of hierarchy is broken this initially has no effect for

keys on a higher level (gematik, 2008d, p.65). All

keys that are not part of the lowest level of hierarchy

and that are valid for at least a year have to be gen-

erated by truly random processes (gematik, 2008d,

p.67), since even a complex generation of random

numbers may hold the danger of attackers being able

to reconstruct the process. Once key validity expires

it has to be deleted including all its copies (gematik,

2008d, p.76), since otherwise old keys’ protection re-

quirements would be lowered, but it would still pose

a threat to the goal of conﬁdentiality.

3 CONCLUDING REMARKS

In this work we conducted a literature based analy-

sis of the security concepts of the German electronic

health card project. However, security always is a pro-

cess and never a state. Thus a reliable and mathemat-

ically veriﬁable total fulﬁllment of all security goals

can not be guaranteed (Wright et al., 2008). The HTI

and its components are therefore designed for con-

stant adjustment and enhancement. Ultimately the se-

curity concept of the gematik seems to be well elabo-

rated in most parts. However this is not yet a conclu-

sion for implementations in use, since these have not

been tested in the frame of this paper.

REFERENCES

gematik (2007): Speziﬁkation Infrastrukturkomponenten:

Registrierungsdienst (SDS) - Lokalisierungsdienst

Stufe 2. Version 1.1.0, 2007.

gematik (2008a):