1. RUHR-UNIVERSITÄT
Bochum
Fakultät für Wirtschaftswissenschaft
Bachelorarbeit im Studiengang
Angewandte Informatik
zur Erlangung
des Bachelor-Grades
in
Angewandte Informatik
über das Thema
Processes of PKIs, within health Telematics’ infrastructure
Eingereicht bei
Herrn Prof. Dr. Roland Gabriel
Lehrstuhl für Wirtschaftsinformatik
von
Dipl.-Ing. Zdravko Danailov
Anschrift 44625,
Bochumerstr.108
Herne
Abgabetag 06.10.2009

2. I
Table of Contents
TABLE OF CONTENTS ...................................................................................... I
ABBREVIATIONS ............................................................................................. III
LIST OF FIGURES .............................................................................................. V
1 INTRODUCTION ......................................................................................... 1
1.1 MOTIVATION .................................................................................................... 1
1.2 STRUCTURE ...................................................................................................... 1
2 CERTIFICATES AND THE TELEMATICS INFRASTRUCTURE ...... 3
2.1 AUTHENTICATION ............................................................................................. 3
2.2 ELECTRONIC HEALTH CARD ............................................................................. 5
2.3 HEALTH PROFESSIONAL CARD AND SMART MODULE CARD ............................ 6
2.4 THE TELEMATICS INFRASTRUCTURE ................................................................. 8
2.4.1 Primary systems ....................................................................................... 9
2.4.2 Telematics infrastructure ....................................................................... 10
2.4.3 Techical services .................................................................................... 11
2.5 FOUNDATIONS OF CERTIFICATES AND PUBLIC KEY INFRASTRUCTURES ........... 12
2.5.1 Public key infrastructure (PKI) ............................................................. 12
2.5.2 Certification Authority (CA) .................................................................. 13
2.5.3 X.509 Certificate .................................................................................... 15
2.5.4 Card Verifiable Certificates (CV-Certificates)...................................... 18
2.6 PROCESS DESIGN ............................................................................................ 21
2.6.1 Functions and application of process design ........................................ 21
2.6.2 Aris ......................................................................................................... 22
3 TRUST MODEL .......................................................................................... 23
3.1 PKI TRUST MODEL WITHIN THE TELEMATICS INFRASTRUCTURE .................... 23
3.2 TRUST SERVICE STATUS LIST (TSL)............................................................... 23
3.3 BRIDGE-CA STRUCTURE ................................................................................. 24
3.4 REASONS FOR THE USAGE OF A BRIDGE-STRUCTURE WITHIN THE TELEMATICS
INFRASTRUCTURE ................................................................................................... 26
4 PROCESSES OF THE ROOT CA ............................................................ 28
4.1 PROCESS BY GENERATION OF NEW KEY PAIR FOR THE ROOT CA ..................... 28
4.1.1 Generation of the new key pair .............................................................. 30

3. II
4.1.2 Creation of a backup for the new key pair ............................................ 30
4.1.3 Release of the public key........................................................................ 30
4.1.4 Notification of the second-level-CAs ..................................................... 30
4.1.5 Issuing Cross CV-Certificates ............................................................... 30
4.1.6 Initialization of the CV-Certificate ........................................................ 31
4.1.7 Activation of new key pair ..................................................................... 32
4.2 REGISTRATION OF THE SECOND-LEVEL-CAS .................................................. 33
4.2.1 Request acception .................................................................................. 35
4.2.2 Request verification ............................................................................... 35
4.2.3 Notification (of the requesting CA) about the result ............................. 35
4.2.4 Storing the result in the internal CA database ...................................... 35
4.2.5 Storing the verification in the internal registration log......................... 35
4.3 ISSUING OF A NEW CV-CERTIFICATE FOR A SECOND-LEVEL-CA .................... 35
4.3.1 Accept the request .................................................................................. 37
4.3.2 Verification of the request and public key ............................................. 37
4.3.3 Issuing a CV-Certificate ........................................................................ 37
4.3.4 Sending/Forwarding the CV-Certificate to the CA ............................... 37
4.3.5 Storing the verification in the certificate protocol ................................ 37
4.4 SECURITY ....................................................................................................... 38
5 NORMATIVE PKI BASIC SERVICES.................................................... 40
5.1 STRUCTURE AND TYPES OF NORMATIVE PKI BASIC SERVICES ........................ 40
5.2 CERTIFICATE RETRIEVAL BASIC SERVICE ........................................................ 44
5.3 DIRECTORY PROXY BASIC SERVICE ................................................................. 44
5.4 DIRECTORY SERVICE ....................................................................................... 45
5.4.1 HPC and SMC-B certificates ................................................................. 45
5.4.2 eHC- certificates .................................................................................... 46
5.4.3 Service and infrastructure certificates................................................... 46
5.5 CERTIFICATE VALIDATION BASIC SERVICE ...................................................... 47
5.6 OCSP BASIC SERVICES ................................................................................... 48
5.6.1 OCSP-Client basic service .................................................................... 48
5.6.2 OCSP-Requester .................................................................................... 49
5.6.3 OCSP-Responder ................................................................................... 50
5.7 CRL BASIC SERVICES ..................................................................................... 50
5.8 TSL SERVICES ................................................................................................ 51
5.8.1 Retrieval................................................................................................. 51
5.8.2 TSL provider basic service .................................................................... 52
5.8.3 Creator................................................................................................... 52
6 SUMMARY AND CONCLUSION ............................................................ 53
BIBLIOGRAPHY................................................................................................VI

4. III
Abbreviations
AdV Anwendungen zur Wahrnehmung der
Versichertenrechte = services for perception of the
AMTS Arzneimitteltherapiesicherheitsprüfung =
pharmacotherapy safety test
AVS = PhAS Apothekenverwaltungssysteme = Pharmacy
Administration Systems
AUT Authentication
AUTN Authentication Certificate for
Information/Messages
C2C Card-to-Card
ca. circa
CA Certification Authority
cf. confer,compare
Connector The secure connection between the local area
network (LAN) and the remote Network of the
Telematics infrastructure.
Connector Identity Private Key and Certificate
CRL Certificate Revocation List
CVC Card-Verifiable-Certificates
e.g. for example
eHC eHealth Card
eHR electronic health records
ENC Encryption
ENCV Encryption Certificate for Prescriptions
EPC Event-driven process chain
ePrescription electronic Prescription
GMA(Bundesärztekammer) German Medical Association
HPC Health Professional Card

5. IV
HSM High Security Module
HTTP Hypertext Transfer Protocol
ibid. ibidem
ICC Integrated Circuit Card/Smartcard
ICCSN Integrated Circuit Card Serial Number
IPSec Internet Protocol Security
KIS = HIS Krankenhausinformationssysteme = Hospital
Information Systems
KBV National Association of Statutory Health Insurance
Physicians
NAP Network Access Point
OCSP Online Certificate Status Protocol
OSig Organizational Signature
QES Qualified Electronic Signature
RFC Request for Comments
SDS Service Directory Service
SigL Signatures Law
SMC Smart Module Card
SMC-B Smart Module Card Type B
SMC-A Smart Module Card Type A
SMC-K Smart Module Card Type K
SMC-RFID Smart Module Card Type RFID
TSL Trusted-service Status List
VPN Virtual Private Network
viz. videlicet

6. V
List of Figures
FIGURE 1: SUCCESSFUL AUTHENTICATION IN CASE OF A SINGLE
MESSAGE ................................................................................................ 3
FIGURE 2: SUCCESSFUL AUTHENTICATION IN CASE OF AN
ONGOING INTERACTION ................................................................... 4
FIGURE 3: OVERVIEW OF THE ENTIRE ARCHITECTURE .................... 8
FIGURE 4: PRIMARY SYSTEMS ARCHITECTURE .................................... 9
FIGURE 5: TELEMATICS INFRASTRUCTURE ......................................... 10
FIGURE 6: TECHNICAL SERVICES ARCHITECTURE ........................... 11
FIGURE 7: SINGLE CA..................................................................................... 14
FIGURE 8: HIERARCHICAL PKI .................................................................. 14
FIGURE 9: X.509V3 STRUCTURE .................................................................. 16
FIGURE 10: BRIDGE-CA WITHIN THE TELEMATICS
INFRASTRUCTURE ............................................................................. 25
FIGURE 11: STRUCTURE OF PKI WITH TSL AND INVOLVED
PARTIES ................................................................................................. 26
FIGURE 12: CREATION OF THE NEW KEY PAIR - PHASE 1 ................ 29
FIGURE 13: CREATION OF THE NEW KEY PAIR - PHASE 2 ................ 32
FIGURE 14: CREATION OF THE NEW KEY PAIR - PHASE 3 ................ 33
FIGURE 15: REGISTRATION OF A SECOND-LEVEL-CA ....................... 34
FIGURE 16: ISSUING OF NEW CV-CERTIFICATE FOR A SECOND-
LEVEL-CA ............................................................................................. 36
FIGURE 17: NORMATIVE PKI BASIC SERVICES ..................................... 42
FIGURE 18: NORMATIVE PKI BASIC SERVICES GROUP ONE............ 43
FIGURE 19: NORMATIVE PKI BASIC SERVICES GROUP TWO .......... 47
FIGURE 20: NORMATIVE PKI BASIC SERVICES GROUP THREE ...... 51

7. 1
1 Introduction
1.1 Motivation
Despite of its first designation (for example Global Positioning System(GPS)), the
Telematics infrastructure has found application in many different spheres such as
health service system, vehicle tracking, fleet management, satellite navigation,
mobile data and television, auto insurance and e-Business.
In this bachelor thesis will be paid attention to the Health Telematics. Its very
complex structure, in which there are several different groups of involved persons,
as well as its usage for transfer and storage of significant data, certainly arise the
question about the security.
The goal of this thesis is to thresh out the processes by creation and handling of
digital certificates within the range of the Health Telematics Infrastructure. For
this purpose the existing logical architecture with its components will be
examined as well as the basic services and different groups of persons that are
involved.
1.2 Structure
In order to examine the structure and security of the certificates in the Telematics
infrastructure, the structure of this bachelor thesis is build-up as it follows.
Chapter 2 focuses on the theoretical fundamentals of the Health Telematics
infrastructure, Public Key Infrastructure and the different types of certificates used
for transferring and storing data. Also it will be paid attention to the necessary
types of cards within the complex system. An analysis of the PKI Trust model
inside the Telematics infrastructure will be performed in chapter 3. Chapter 4 is
about the processes of the root CAs. It will pay attention to specific details as the
generation of a new key pair for the root CA, registration of the second-level-CAs
and issuing of a new CV-Certificate for the second-level-CA. In chapter 5 the
normative PKI basic services, as well as their functionality within the Telematics

8. 2
infrastructure will be discussed. Chapter 6 will conclude with a critical view on
the Telematics infrastructure and the processes, which have already been
examined in detail in this bachelor thesis.

9. 3
2 Certificates and the Telematics infrastructure
2.1 Authentication
The authentication service is responsible for confirming the authenticity of
communication. There are two particular cases, which can occur (1) a single
message (e.g. warning or alarm signal), or (2) an ongoing interaction (e.g.
connection of a terminal to a host).1
Figure 1: successful authentication in case of a single message
1 cf. Stallings (2006), p. 18.

10. 4
In case of a single message (Figure 1), the task of the authentication service is to
guarantee in front of the recipient that the origin of the specific message is
authentic, viz. the source of the message and the source, it claims to be from, are
the same.2
Figure 2: successful authentication in case of an ongoing interaction
2 cf. Stallings (2006), p. 18.

11. 5
By an ongoing interaction (Figure 2), during the initiation of connection the
service confirms the authenticity of the both entities, viz. whether the entities are
those they claim to be. Also the service grants that the connection is not interfered
in any way, viz. a third party cannot dissemble as one of the two interacting
entities in order to send/receive unauthorized data.3
There are two types of authentications specified in the standard:
Peer entity authentication
association with a logical connection to provide confidence in the
4 The peer entity authentication undertakes the
task ] to provide confidence that an entity is not attempting either a
5
Data origin authentication
The Data origin authentication sustains applications (e.g. electronic
mail) 6
are present.
2.2 Electronic Health Card
In order to improve the health insurance system the German government enacted a
law7, by which they started an enormous infrastructural Telematics project: the
introduction of a national electronic Health Card (eHealth Card). This
3 cf. Stallings (2006), p. 18.
4 Stallings (2006), p. 19.
5 ibid., p. 18.
6 ibid., p. 18.
7 SGB V (2009), § 291.

12. 6
microprocessor chip card is an important element in the fast developing
Telematics infrastructure. This card is simply the key to a health system data as
well as to applications for computing and processing such data. The main purpose
by the initiation of this project is the enhancement of efficiency, quality and
transparency in medical care. The solution is a patient based sector-spanning
network with persistent information flow. 8 For this reason the top organizations
of the national German health system assumed the responsibility to create and
introduce the required infrastructure and therefore founded gematik Gesellschaft
für Telematikanwendungen der Gesundheitskarte mbH9 in 2005.10
The electronic health card (eHC) is a working out of the Fraunhofer Institute
supported by the Federal Ministry of Health in Germany. The eHC is conceived
and developed as a service-oriented architecture (SOA) with some restrictions,
the health card can only be accessed locally on the client side; or
services should use remote procedure calls for communication due to performance
and availability issues. 11 As a result, the system architecture is divided into
applications such as emergency data, electronic prescription (ePrescription),
electronic medical report or an e 12
2.3 Health Professional Card and Smart Module Card
The Health Professional Card (HPC), which nowadays is an immutable part of the
concept, primarily was one independent construct. In 1996 the German
Medical Association (GMA) together with the National Association of Statutory
Health Insurance Physicians Elektronischer
8 Pohlmann et al. (2007), p. 396.
9 SGB V (2009), § 291 b.
10 cf. Pohlmann et al. (2007), p. 396.
11 Lee et al. (2009), p. 52.
12 ibid., p. 52.

13. 7
Arztausweis ated on this subject. Rapidly came clear that the
introduction of the HPC would not be possible without a reconcilement with the
eHC.13 HPC can be defined as an individually programmed access
authorization card held by the health professionals 14 (e.g. doctors and
pharmacists).
Despite of the integration with the eHC, the HPC has also its own significance.
associations,
which are responsible for the issuance of the cards, can provide applications of
their own. For example, a medical association can upload a database with specific
medical data online, where the HPC serves as an access key instead of password
and login id.
Alongside the eHC and HPC there is a third type of card - Smart Module Card
(SMC). Three variants of the SMC subsist SMC-A, SMC-B and SMC-K. The
first two of them can be treated as constricted HPC. They give the possibility to
medical secretaries, nurses etc., to start different activities and so to disburden the
doctors and pharmacists. The goal of SMC-A is to execute the issuance of a
digital signature by the HPC, if the doctor has already adjusted and permitted it.
This method can be used for example by nurses to sign an ePrescription. The
SMC-B is issued for an institution (e.g. hospital). Using the card this institution
can authenticate itself over the Telematics infrastructure or eHC, and also issue
digital certificates. The third variant of SMCs the SMC-K is intended for usage
in small or middle institutions. It is integrated in the connector (please see section
2.4.2). SMC-K secures the communication of the connector with the broker, card
terminal and HPC.15
13 cf. Schmeh (2009), p. 153.
14 Istepanian/Pattichis (2006), p. 103.
15 cf. Schmeh (2009), p. 153.

14. 8
2.4 The Telematics infrastructure
Health Telematics designates the combination of telecommunication and
informatics in the healthcare sector. In some countries, Health Telematics
- -
seems to be currently establishing itself both in Germany and at an international
level.
The entire architecture is shown in Figure 3.
Figure 3: overview of the entire architecture16
16 cf. gematik (2008e), p. 28.

15. 9
2.4.1 Primary systems
Figure 4: Primary systems architecture
The primary systems (Figure 4) provide application programs for the medical care
providers and insurants. The programs used by the medical care providers are
Practice Administration Systems (PAS) for medical specialists and dentists,
Hospital Information Systems (HIS) for hospital, rehabilitation centers etc. and
Pharmacy Administration Systems (PhAS) for pharmacies. The programs, which
are relevant for the insurants are eKiosk and Versicherten@Home. They provide
functions for the insurants to access their data, in order to Show specific
data as well as to administrate the rights or in some cases to delete data.17
17 cf. gematik (2008e), p. 29.

16. 10
2.4.2 Telematics infrastructure
Figure 5: Telematics infrastructure
There are three main structures within the Telematics infrastructure (Figure 5)
local components (connectors and card terminals), Telematics network gateways
(VPN-gateways) and Telematics application gateways (Broker services).
The access of the Telematics primary systems and the access to the card terminals
are managed via connectors. The connectors have gateways to the primary
systems and card terminals. Also, across them the connectors have access to the
chip cards. Finally, the connectors access the Telematics network and application
gateways (Broker services).18
Telematics implements a very complex networked system, which is based on and
secured by central gateways. Over connectors more than 100000 medical and
dental practices, 2000 hospitals as well as 21000 pharmacies are connected to the
Telematics infrastructure. The access to the communication system is secured via
18 cf. gematik (2008e), p. 29.

17. 11
network gateways (VPN-gateways). The VPN-gateways grant, that only the
approved connectors have access to the communication system.19
Via application gateways the access to the sever-based application services is
managed and secured by the so called Broker services. The Broker services allow
the central allocation of standard processing between connector and technical
services.20
2.4.3 Techical services
Figure 6: technical services architecture
There are two types of technical services (Figure 6) obligatory and optional
services. The obligatory services of eHC are those that manage particularly
administration data of insurants and also the transfer of medical prescriptions.21
Obligatory services are insurants
19 cf. gematik (2008e), p. 30.
20 ibid., p. 31.
21 SGB V (2009), §291a.

18. 12
management, services for perception of the insurants (AdV). Optional
services are emergency data, pharmacotherapy safety tests (AMTS) and electronic
health records (eHR).22
2.5 Foundations of certificates and public key infrastructures
2.5.1 Public key infrastructure (PKI)
The public key infrastructure (PKI) is a structure for creation, issuance,
revocation, and processing of public and private encryption keys. The main goal
by PKI is to brace a set of public and private keys with a person or device in order
to e.g. check, verify identity or for privacy purposes when exchanging data.23
There are fundamental differences in usage and storing between these
mathematically related keys. The private key has to be kept under the control of
its owner. Just in the opposite the public key, can be distributed over
publicly available directories for use by any individual who wishes to participate
within a security service with the person holding the private key related to that
public key. 24 This system has proved its high level of efficiency based on the
both keys (private key and public key), forming a mathematically related pair, so
it is to obtain the private key
from knowledge of the public key and the algorithm, using them (public key and
algorithm). Another important security aspect is the distribution of the public keys
within PKIs. It is attained via digital certificates based on X.509 standard.25
Building up a mutual thrust between sides (individuals or systems)
communicating with each other is way to protect and authenticate the transactions.
In other words the sides have to be confident that the [ ]
22 cf. gematik (2008e), p. 31-33.
23 cf. Willett (2008), p. 253.
24 Obaidat/Boudriga (2007), p. 76.
25 cf. Obaidat/Boudriga (2007), p. 76.

19. 13
belong to the entity (individual or system) with whom they are communicating. 26
Therefore, PKI can be introduced to resolve that problem.
Because of its ability to manage certificates (e.g. to issue or revoke a certificate),
to encrypt keys, to make secure logs and also to protect archives, using symmetric
key cryptography, PKI offers very strong authentication system. 27
2.5.2 Certification Authority (CA)
The difficult task of issuing and managing the keys (private and public keys)
within the PKI is assumed by the certification authorities (CA). The CA issues
digital certificates exerting a digital signature algorithm, which brace the identity
of a user or system to a public key. The keys issued by the CA are in the form of
certificates (e.g. X.509). The public keys of entities as well as other elements (e.g.
name of the certificate, certificate status, time of issuance of the certificate,
certificate version and so on) are contained in these certificates. The client and the
public keys.
In some cases organizations have the possibility to use their own CAs, but they
have to build them and to provide the necessary support. Furthermore, in most
cases such organizations prefer to outsource their CAs to third-party vendors.
Nevertheless, for the conventional and proper functioning of the PKIs, the CA has
to be safe and secured, also to possess the corresponding necessary support.28
There are three types of CAs PKIs single CA PKI, hierarchical PKI and meshed
PKI. Because of their usage and application, regarding the Telematics
infrastructure we will discuss only the single CA PKI and the hierarchical PKIs.
26 Obaidat/Boudriga (2007), p. 76.
27 cf. Obaidat/Boudriga (2007), p. 76.
28 cf. E Cole/ Krutz (2005), p. 540.

20. 14
Figure 7: single CA29
Theoretically, by the single CA (Figure 7: single CA), in order to incorporate in
the PKI system, the user generates its own public/private key pair and sends a
request to the CA to certify the public key. The confirmation from the CA, that the
public key really does belong to the person in question (the CA issues a digital
certificate as a confirmation), is sent back to a recipient whenever the person is
about to communicate with some party with public key encryption or digital
signing. Within the PKI the public key of the CA is available for all participants,
as they can check the authenticity of the certificate and by this way the public key
of the sender. The
the CA, and an expiration date. 30
But the single CA PKI is possible only theoretically. As a matter of fact the PKI
system is designed as a multiple-levels-hierarchy, which manages certificate
generation and verification between CAs. (Figure 8: hierarchical PKI)
Figure 8: hierarchical PKI31
29 Joshi (2008), p. 222.
30 ibid., p. 222f.
31 ibid., p. 222.

21. 15
The hierarchical PKI can be seen as a tree structure with the corresponding nodes.
The root node of the tree is represented by the root CA, which is trustworthy for
all participants in the structure (users or CAs). By this way is formed the chain-of-
trust relationship, because irrespective of that, which low-level CA is selected by
the user, this CAs is always capable of finding a higher-level CA in the tree
structure. The verification by the hierarchical PKI (e.g. in a two-level CA PKI)
proceeds as it follows. In the two-level CA system, the public key certificate
of a user consists of two parts: (1) a message issued by a high-level CA to certify
a low-level CA and (2) a message issued by the low-level CA who will eventually
certify the public key of the user. 32 By this way is established a chain-of-trust of
two CAs, so the path validation can be managed. As a result, every entity that
designates to receive a user certificate (as well as the certificate of the CA,
certifying the user certificate) has to obtain (1) the public key of the low-level CA,
serving that user and (2) after that the user certificate. Logically, the estimated
time for verifying a certificate increases every additional level in the hierarchy. 33
2.5.3 X.509 Certificate
2.5.3.1 X.509 Certificate structure
The public-key certificate format, which is the most feasible within the Telematics
infrastructure, is the X.509.34 One X.509 certificate possesses the following
obligatory structural elements (shown in Figure 9) and is signed with the
corresponding private key of the signing entity.
32 Joshi (2008), p. 223.
33 cf. Joshi (2008), p. 223.
34 cf. Khosrowpour (1999), p. 283.

22. 16
Figure 9: X.509v3 structure35
The applied certificate format is specified within the Version -element. There
can be changes to the certificate version. For example the first version from 1988
has the version number v1 and is identified with version value 0. In 1996 the
version v3 (X.509v3) was released, which contains extensions of the primary
structure. The specification of the issuer Issuer - element) or the
name of the user Subject -element) allows multiple application of
these names. extension -element can be specified a sequence of one or
more extensions, such as KeyUsage, PrivateKeyUsagePeriod or certificate
policies.36 KeyUsage - extension specifies, for what purpose (encipherment,
35 cf. . Eckert (2008), p. 380.
36 ibid., p. 380.

23. 17
signature, certificate signing)37 the key contained in the certificate can be used.38
PrivateKeyUsagePeriod -extension allows the certificate issuer to
specify a different validity period for the private key than the certificate. 39 By the
certificatePolicies -extension can be specified the terms under which the
certificate has been issued and the purposes for which the certificate may be
used. 40
It is responsibility of the certifying entity (CA) that two certificates cannot be
issued with the same serial number. In order to verify a certificate the recipient
needs data for the hash and signing methods and for the public key of the signing
entity as well. This data is contained in the certificate. The name of the certifying
entity identifies explicitly the service, which confirms the properness of the
certificate. The certificate issuer can specify the validity period, defined via the
sub- notBefore notAfter
-sub-element (w Subject -field) is defined the
user, for which the certificate is issued (for server, particularly for web-servers,
server- - ] is used
to carry the public key and identity of the algorit 41
They can differ from the algorithms, used by the certifying entity.
2.5.3.2 Personal assigned X.509 Certificates
The X.509 Certificates of HPC, eHC and SMC-B serve to authenticate physical
(HPC, eHC) and juristic persons (SMC-B). By this way, using public certificates
the digital signatures can be verified hence the identities authenticated.
37 cf. Housley et al. (1999), p. 26.
38 cf. Eckert (2008), p. 380.
39 cf. Housley et al. (1999), p. 28.
40 ibid., p. 28.
41 ibid., p. 22.

24. 18
Furthermore, the data of the card owner can be encrypted. 42 In other words, there
are the actual personal assigned X.509 Certificates for authentication (AUT),
encryption (ENC) and the Qualified Electronic Signature (QES), which is
optional. Besides these three types of certificates, by the eHC are used two
additional ones ENCV and AUTN. They can be used for technical purposes
without PIN verification.43
For the HPC are defined four types of X.509 Certificates, whereas these for
Qualified Signatures are issued only by the accredited providers and can be
affiliated to the SigL Root of the Federal Network Agency. By the Qualified
Signatures, which are issued under the responsibility of the GMA, Attribute
Certificates are provided, describing the professional rights of the doctors. By the
certificates of apothecaries and psychotherapists is abstained from the additional
Attribute Certificates.
For the SMCs the X.509 Certificates as well as the CVC are defined with role
attributes. More specific is the situation by the SMC-B, where in addition to the
Encryption and Authentication Certificates are used the Organizational
Certificates (OSig).44
2.5.4 Card Verifiable Certificates (CV-Certificates)
Card-verifiable certificate (CVC) is a digital certificate. In comparison with the
X.509 certificates, which require more memory capacity, due to the flexibility and
the usage of complex algorithms, the CVCs are applicable for authentication and
therefore have simplified structure. More specific the CVC are used for direct
mutual authentication between chip cards (for example authentication between
eHC and HPC) within the Telematics infrastructure.45 In addition, these cards
42 cf. gematik (2008e), p. 134.
43 cf. gematik (2008b), p. 14.
44 ibid., p. 14.
45 cf. gematik (2008c), p. 13.

25. 19
contain also the so-called key pairs, which are used along with the associated CV-
Certificates, for the authentication (Card-to-Card Authentication).
2.5.4.1 Card-to-Card Authentication
By the Card-to-Card Authentication, one particular card verifies its authenticity to
another one. Additionally, depending on the specific executed C2C Authentication
and the content of the used CV-Certificate, the following states can be obtained46:
Establishment of a Trusted Channel between both cards, so
cryptographically encrypted data can be exchanged.
For example: C2C Authentication between SMC and HPC within the
scope of Batch and Convenience Signatures.
In one of the cards, depending on the CV-Certificate of one of the other
cards, is given access to certain data.
For example: C2C Authentication between eHC and HPC, aiming
Read/Write an electronic Prescription (ePrescription).
In one of the cards, depending on the CV-Certificate of one of the other
cards, certain range of functions are enabled.
For example: C2C Authentication between HPC and SMC-A to enable the
SMC-A.47
46 cf. gematik (2008c), p. 13.
47 ibid., p. 13.

26. 20
2.5.4.2 Specificities by the CVCs
The CV-Certificates cannot be revoked as the X.509 certificates, because the chip
authenticity (but
not the validity) of the certificates can be checked, if all CV-Certificates can be
traced back to one explicit CVC-Root-CA, with well-known for each card,
certificate. Nevertheless, the CV-Certificates can be verified and analyzed by the
cards, which is not possible by the X.509 certificates.48
In addition to the different technical parameters, the CVC contains Integrated
Circuit Card Serial Number (ICCSN) and Access Profile. By this Profile is
determined, what is the access level to the data or the feasibility of other functions
in one card by the C2C-Authentication. Thus, there are two types of Access
Profiles:
Access Profile for Role Authentication
Access Profile for Function Entity Authentication of the card
According to the allocation of the different CV-Certificates on the card types there
are:
eHC contains only one Role CV-Certificate
SMC-Ks and SMC-RFIDs contain only Device CV-Certificates
HPCs, SMC-As and SMC-Bs contain one Role CV-Certificate as well as
(if necessary more than one) Device CV-Certificates.49
48 cf. gematik (2008c), p. 13.
49 ibid., p. 14.

27. 21
2.5.4.2.1 Role Authentication
For a Role CV-Certificate, contained in eHC, HPC or one SMC-A/SMC-B, the
Access Profile specifies which Role has the card owner (person or organization).
Via this Role within the CV-Certificate is specified what access rights over the
data saved on the other card becomes the card holder after a C2C authentication.50
2.5.4.2.2 Function Entity Authentication of the card
For a CV-Certificate, contained within HPC, SMC-A, SMC-B, SMK-K or SMC-
RFID, the Access Profile specify which Function Entity contains this particular
card.51
2.6 Process Design
2.6.1 Functions and application of process design
Before dealing with business processes or workflow processes they have to be
designed. The process model is carried out by one or more designers. They can be
external consultant, system analyzer, end user or administrator, whereas a
combination between them is also possible. The generated process model is
foundation for the work of the system developers and programmer by the model
transformation into executable/ working system. Furthermore, the system
analyzers use this model to improve or customize the process. The management
operates with the model in order to make strategic improvements if possible. For
the end user and administrator it serves as an instrument for documentation. The
50 cf. gematik (2008c), p. 14.
51 ibid., p. 14.

28. 22
design is always context-sensitive. It is important in which sphere the process
model will be applied and what is the main goal of the process. Hence there are
three basic questions it
52
2.6.2 Aris
For the better representation and understanding of the processes within the
Telematics infrastructure, in this bachelor paperwork will be used Aris. Aris
stands for a group of systems, which essential characteristic consists in that, to
design, analyze and document business or workflow processes. In this case the
term workflow process covers not only the control flow, viz. the chronological
sequence of the functional fulfillment, but also the directly connected data
specifications, organization specifications and resources specifications.53 The type
of model, which fully covers the requirements by representing the processes
within the Telematics infrastructure Business process -model type. It
describes the process as a sequence of events and activities (Event-driven process
chain or EPC) and also gives the possibility to add more detailed information by
using organizational units, IT systems and data.
52 cf. Richter-von Hagen/Stucky (2004), p. 61-62.
53 cf. Scheer/ Jost (2002), p. 16.

29. 23
3 Trust Model
3.1 PKI Trust Model within the Telematics infrastructure
Within the Telematics infrastructure several different PKI trust models have been
developed and tested especially the hierarchical model based on a root CA and the
cross-certification model.54
clear that absolute hierarchical trust model cannot be used within the PKI, because
the flexibility of the Telematics infrastructure will be limited.55 In view of
overcoming this problem, the Bridge-CA model has been developed. It is a
combination of the root CA and cross-certification model. Before we discuss more
detailed the Bridge-CA we will scrutinize the main element, on which this
structure/model is based on the Trust Service Status List (TSL).
3.2 Trust Service Status List (TSL)
The standardized TSL and its publication have been proposed by the European
is available for public
access and provides actual information about numerous aspects of the service in
56
Within PKI there are two different TSLs: TCL (Trusted Component List) and
personal TSL (Trust-service Status List). In the TCL all CAs are included, which
are authorized to issue a certificate whether for the IPSec-Access to the
Telematics infrastructure or for an authentication between two services (Network
and Service Certificates). In the TSL all CAs are included, which are authorized to
54 cf. Paulus et al. (2004), p. 44.
55 cf. gematik (2008e), p. 135.
56 Paulus et al. (2004), p. 44.

30. 24
issue a certificate for physical and juristic persons (Certificates for eHC, HPC and
CV-Certificates).57
3.3 Bridge-CA structure
The Bridge-CA model within the Telematics infrastructure is shown in Figure 10.
There are six different spheres in which the certificates can be divided eHC
certificates, CVC certificates, services certificates, HPC/SMC certificates,
network certificates and devices certificates.
Each certificate and therefore each public key within the PKI is signed through
one Certification Authority to confirm the authenticity. Additionally, the signing
CA must be a trustful one. The trust in a CA can only exist, when all security
specifications of the CA fulfill the requirement, that their abidance can be
confirmed by one independent entity. The public key distribution via a central
entity is considerably reduced for the system management, because the public key
of this entity has to be distributed to all Telematics systems integrity-secured. All
further public keys can be traced back to this central entity, thus the validity can
be verified. Validation of trust is not necessary, concerning public keys.58
From the certificate type and certificate content is clear, for which sphere it was
generated. In each one of these spheres can exist more than one root-CA that
respectively has Sub-CAs (TrustCenter for Qualified Signatures). There is an
exception, more precisely the CVC PKI. The CVC PKI has only one root CA,
because all Card-Variable-Certificates have to trace back to one explicit/definite
root CA.
57 cf. gematik (2008e), p. 294.
58 ibid., p. 135.

31. 25
Figure 10: Bridge-CA within the Telematics infrastructure59
Each of these Root-CAs, presented within this Trust Model, must be authorized
by a TrustCenter by being included in a Trusted-Service-Status-List (TSL). The
TSL contains the public keys of all trustworthy CAs, the data about the certificate
types, accredited for these CAs, as well as the address of the certificate status
services (OCSP-Responder and CRL Provider). The TSL is validated through the
gematik TSP (Trust Service Provider).60 All authorized TSPs must be available in
the TSL (gematik Trusted-service Status List), but not before they have been
registered by the gematik.61
59 gematik (2008e), p. 135.
60 cf. gematik (2008e), p. 135f.
61 cf. gematik (2008a), p. 14.

32. 26
3.4 Reasons for the usage of a Bridge-Structure within the
Telematics infrastructure
The concept of two-level-hierarchy, which is specified by law for the Qualified
Electronic Signatures with provider accreditation, is not applicable for the
Encryption (ENC), Authentication (AUT) and Organizational (OSig) Signatures,
because of the expected multitude of certificate issuers and the integration of the
existing structures. The following figure shows the involved parties in the PKI, as
well as the complexity of the system.62
Figure 11: Structure of PKI with TSL and involved parties63
62 cf. gematik (2008a), p. 12.
63 gematik (2008a), p. 12.

33. 27
Regarding consumer protection, aspects of commitment, identification and
registration through the cost units, a specified method/mechanism for decryption
of data, if the ENC-key is lost, duration and costs of the introduction, there are
fundamental differences of the regulation by the Qualified Certificates. Therefore
as a trust model is used a Bridge-Structure, by which the individual information of
every single TSP is saved in one signed XML-file (TSL).64
Another very important aspect for the security of the complete system is the
security of the PKI for CV-Certificates. This will be discussed in chapter 4 with
its specific features.
64 cf. gematik (2008a), p. 14.

34. 28
4 Processes of the root CA
In the following chapter the processes, which are executed during the usage of
root CAs, will be examined more detailed. First of all we will make clear what is
root CA in its essence. The highest level, or root, of the hierarchy of trust is the
root certificate authority. It is normally maintained offline and only accessed
when needed for signing purposes. Root CA responsibilities also include the
generation and distribution of the Certificate Revocation List (CRL) in cases of
any private key compromise in branches directly below the root. Root certificates
are self-signed65. 66
The processes of the root CA can be divided into two groups main and sub
processes. There are three main processes process by generation of new key pair
for the root CA, registration of the second-level-CA and issuing of new CV-
Certificate for a second-level-CA. Each one of them will be discussed separately,
considering all sub processes as well.
4.1 Process by generation of new key pair for the root CA
This process covers also the generation of the first key pair (first generation)
within the initialization of the root CA.
For the work of the root CA is generated a new key pair, that is available from a
certain point for the issuing of new CV-Certificates, also the associated public key
must be appropriately released.67
65 The root certificate is self-signed, in other words the root CA has issued its own certificate (i.e.,
the subject and issuer are identical). The signature is generated by the certificate owner, using
the private key that corresponds to the public key associated with the certificate.
66 Vacca (2004), p. 35.
67 cf. gematik (2008c), p. 21.

35. 29
Figure 12: Creation of the new key pair - Phase 1
Figure 12 includes the sub processes from section 4.1.1, 4.1.2 and 4.1.3.
The sub processes by the regulation of the Backup are as it follows:

36. 30
4.1.1 Generation of the new key pair
It must be internally initiated in the HSM (please see Figure 12).68 Hardware
Security Module (HSM, also "Crypto-Box") is a component, integrated in the
hardware with corresponding qualified functionality, which secure the private key
of the broker-components and can execute cryptographic operations (e.g. signing).
Because the private key is known only within the HSM, a successful intrusion into
the broker and/or security entity would not compromise the private key of the
broker.69
4.1.2 Creation of a backup for the new key pair
It is internally initiated in the HSM (please see Figure 12).
4.1.3 Release of the public key
The public key must be read-out by the HSM, and subsequently released in
applicable form. Particularly, all data-processors/card-producers must receive this
key (please see Figure 12).
4.1.4 Notification of the second-level-CAs
The second-level-CAs must be notified/ informed about this process (please see
Figure 13).
4.1.5 Issuing Cross CV-Certificates
With the current key pair must be issued a Cross CV-Certificate across/ through
the public key of the new key pair and the opposite- with the new key pair must be
issued a Cross CV-Certificate across/ through the public key of the current key
pair.
68 cf. gematik (2008c), p. 22.
69 cf. gematik (2007), p. 35f.

37. 31
This sub-process is not necessary during the generation of the first key pair.
Before it is possible, that this sub process can be executed, the first key pair has to
be activated (please see Figure 13).70
4.1.6 Initialization of the CV-Certificate
The connector must possess the corresponding Cross CV-Certificates of the root
CA, so the eHC, HPC and the SMC can execute a C2C-Authentication even then
when their current CV-Certificates are different Root-versions. Because of this the
root CA provides the issued Cross CV-Certificates on a server, from which all
components involved can download them.
This sub-process is not necessary during the generation of the first key pair.
Before it is possible, that this sub process can be executed, the first key pair has to
be activated and Cross CV-Certificate has to be issued (please see Figure 14).71
70 cf. gematik (2008c), p. 22.
71 ibid., p. 22.

38. 32
Figure 13: Creation of the new key pair - Phase 2
4.1.7 Activation of new key pair
The new key pair must be activated in the HSM. From this moment all CV-
Certificates by the CA are issued with this new key pair.
Generally, generation and activation of the new key pair come apart
chronologically, so the associated Cross CV-Certificates can be prepared on time
for download before the actual activation (please see Figure 13).72
72 cf. gematik (2008c), p. 22.

39. 33
Figure 14: Creation of the new key pair - Phase 3
4.2 Registration of the second-level-CAs
This process is not executed by the technical operators of the root CA, but by
responsibility for the decision whether one CA can be registered
ubtasks of this process to external
service providers.

40. 34
One second-level-CA is registered by the root CA (Figure 15) before it can
request a corresponding CV-Certificate across its public key.73
Figure 15: Registration of a second-level-CA
Figure 15 includes the sub processes from section 4.2.1, 4.2.2, 4.2.3, 4.2.4 and
4.2.5.
73 cf. gematik (2008c), p. 23.

41. 35
Sub processes (from the side of the root CA):
4.2.1 Request acception
4.2.2 Request verification
4.2.3 Notification (of the requesting CA) about the result
4.2.4 Storing the result in the internal CA database
In the CA database is saved all relevant data of the successful registered second-
level-CAs. The data of this database is among other things needed by the
following processes:
Data of the second-level-CA about the generation of a new key pair for the
Root-CA
CA-request verification of the issuing of a new CV-Certificate
4.2.5 Storing the verification in the internal registration log
The request, result and motivation must be saved in the internal registration log,
as its contents must enable a revision-safe verification for the proper work of the
root CA.74
4.3 Issuing of a new CV-Certificate for a second-level-CA
For CA upon request is issued a new CV-Certificate for its private key with the
current key pair of the root CA. After that the new CV-Certificate is forwarded to
74 cf. gematik (2008c), p. 23.

42. 36
the CA. Verification for this process is saved in the internal certificate protocol of
the root CA. 75
Figure 16: Issuing of new CV-Certificate for a second-level-CA
Figure 15 includes the sub processes from section 4.3.1, 4.3.2, 4.3.3, 4.3.4 and
4.3.5.
Sub processes (from the side of the root CA):
75 cf. gematik (2008c), p. 23.

43. 37
4.3.1 Accept the request
The request for the issuing of a new CV-Certificate must be forwarded by the CA
and respectively accepted by the root CA.76
4.3.2 Verification of the request and public key
The request must be verified as it follows:
The request must be correct in view of setup/assembling
The request must derive from a CA, which has been already registered by
the root CA.
The Authenticity of the public key within the request, as well as the
evidence of possession (by the requesting party) of the associated private
key must be verified.
If necessary, the request is declined and returned to the sender with an associated
explanatory statement.
4.3.3 Issuing a CV-Certificate
With the current key pair of the root CA is issued a CV-Certificate based on the
public key within the request.
4.3.4 Sending/Forwarding the CV-Certificate to the CA
The newly issued CV-Certificate must be sent/ forwarded to the requesting CA.
4.3.5 Storing the verification in the certificate protocol
The request and newly issued CV-Certificate must be saved in the certificate
protocol.77
76 cf. gematik (2008c), p. 23.
77 ibid., p. 24.

44. 38
4.4 Security
As already mentioned in chapter 3, the security of the PKI for CV-Certificates is a
very important aspect for the security of the complete System. Issuing of CV-
Certificates, the second-level-CA provides (in collaboration with cards producer
and in the presence of data, required for the production) the creation of:
unique eHC for insured persons
unique HPCs/ SMCs with profiles for any Roles(doctor, apothecary, etc.)
unique SMCs with profiles for any devices(SMC-K, SMC-RFID, etc.). 78
Once a CV-Certificate is issued, it has unlimited validity79. Therefore, it has to be
avoided through the security policy of the PKI for CV-Certificates, an
unauthorized issuing of CV-Certificates or issuing for unauthorized purposes.
The following specifications must be reckoned as minimum standard. Because of
the fundamental significance of the PKI for CV-Certificates for the Telematics
infrastructure security, one general security level must be implemented by the root
CA as well as by the second-level-CAs.80
For components and services of the Telematics infrastructure, based on the
minimum standard of the security concept, specific security and protection
profiles have to be provided. T
minimum standard and the efficiency of the specified concrete security measures
must be verified during the evaluation as well as the admission of components or
services within the Telematics infrastructure.
78 cf. gematik (2008c), p. 23f.
79 The CV-Certificate validity of one eHC/ HPC/ SMC is limited through the endurance of the
associated private key and the usability of the chip card. The CV-Certificates lose their validity
(or they cannot be used successfully in C2C-Authentication), if the Cross CV-Certificate of the
root CA, associated to the root version is deleted from the connectors.
80 cf. gematik (2008c), p. 25.

45. 39
only in the security boundaries of the Telematics infrastructure, hence the existing
systems of the suppliers and cost objects are not directly affected by the specified
policies and minimum standard of the security concept. These IT-Systems operate
under the security measures and policies, integrated there. The specific
applicational and operational environment of the gateway-components must be
adequately secured and the service provider must bear the responsibility for the
adequate security.81
The operator of the specific CAs can create and implement their own security
concepts, according to requirements of the ordering party (for example cards
producer) or their own if the following minimum requirements are performed.
One second-level-CA Within the process of
registration the adherence to the requirements must be substantiated through
security report.82
81 gematik (2008d), p. 22f.
82 gematik (2008c), p. 25.

46. 40
5 Normative PKI Basic Services
5.1 Structure and types of normative PKI basic services
Within the Telematics infrastructure, different services with the same
functionality have to exist to grant redundancy and backup. There are two basic
types of normative PKI basic services backend services and consumer services,
which exchange data and interact with each other.83 Before we examine the
services in details, we will scrutinize the backend and consumer services
separately considering the way they process data, their tasks as well as the sub
types into which they can be divided.
The backend services are data storage services that generally operate passively.84
They grant data for other services and thus must either possess own data or have
access to other services within the PKI structure, which allows them to obtain the
necessary data. The backend services can be divided in four different categories:
services, which are optional (e.g. CRL provider basic service),
services, which exist only once within the Telematics infrastructure (e.g.
TSL creator basic service),
services, which have more than one entity, even though they all allocate to
the same database and therefore are exchangeable, granting redundancy
(e.g. Directory proxy basic service, OCSP requestor basic service, CRL
provider proxy basic service, TSL provider infrastructure/ person basic
service),
83 cf. gematik (2008e), p. 137.
84 ibid., p. 295.

47. 41
services, which appear more than once within the infrastructure and have
different databases (e.g. Directory basic service, OCSP responder basic
service).
In the opposite to backend services, how data is provided is completely irrelevant
for the consumer services. The consumer services are services that do not store
any data and they query the backend services. 85 Their task is (1) to run a function,
such as encapsulation of certificate check and (2) to interact with the
corresponding backend services (every single backend service possesses more
than one entity). The data intended for the consumer service, which is the target
entity, is supplied from (1) the certificate, to which the operation refers, or (2) the
certificate of the signing entity.86 Compared to the backend services, the consumer
services can be summarized into one of the above specified categories services,
which have more than one entity, even though they all allocate to the same
database and therefore are exchangeable, granting redundancy (e.g. Certificate
retrieval basic service, OCSP-Client basic service, CRL validation basic service,
Certificate validation basic service and TSL retrieval basic service).87 The
complete hierarchy and the connections between the services are shown in Figure
17.
85 gematik (2008e), p. 295.
86 ibid., p. 137.
87 ibid., p. 137.

48. 42
Figure 17: Normative PKI basic services
After the introduction of the normative PKI basic services, we will examine the
services and connections between them more detailed. There are three groups of
services into which we divide this hierarchical structure, consisting of backend
and consumer services.
The first group of services, shown in Figure 18, consists of the certificate retrieval
basic service (consumer service), the directory proxy and the directory basic
services (backend services). These services will be discussed separately in
sections 5.2, 5.3, 5.4.
The second group of normative PKI basic services, shown in the Figure 19,
consists of certificate validation basic service, OCSP-Client basic service, CRL
validation basic service (consumer services), OCSP requestor basic service, OCSP
responder basic service, CRL provider proxy basic service (backend services) and

49. 43
CRL provider basic service (backend service), which is optional, as already
mentioned above in this section. These services will be discussed separately in
sections 5.5, 5.6, 5.7.
The third group of normative PKI basic services, shown in Figure 20, consists of
the TSL retrieval basic service (consumer services), the TSL provider
infrastructure and person basic services and the TSL creator basic service
(backend services). These services will be discussed separately in sections 5.8.1,
5.8.2, and 5.8.3.
Figure 18: Normative PKI basic services group one

50. 44
5.2 Certificate retrieval basic service
The certificate retrieval basic service is a consumer service. Its task is to provide
certificates for consumer services, which belong to a specified identity. For this
purpose the necessary data for the explicit identification as well as the certificate
type are turned over to the certificate retrieval basic service. By the certificate
retrieval only the necessary certificate is localized and loaded through the
directory proxy service, as well as its validity is checked by the certificate
validation service, before provided. It is very important to mention that certificate
retrieval is possible only for certificates, which are assigned to appropriate
directory service (all valid certificates, issued by the CA are available via the
directory basic service (for more details, please see section 5.4))88.
5.3 Directory proxy basic service
The directory proxy basic service is a backend service, which establishes the
connection between the certificate retrieval service and directory basic service.
Within the PKIs of Telematics infrastructure exist more than one autonomous PKI
entities. By this backend service, certificates from the same type are frequently
distributed between more PKI entities (please see section 2.5.2), so they cannot be
allocated without the acknowledgement of the storing PKI or all existing PKIs
within the Telematics infrastructure. The directory proxy basic service
encapsulates this complexity for the certificate retrieval basic service and localizes
the certificate within several PKI entities completely on the basis of explicit
characteristics.89
88 cf. gematik (2008e), p. 137f.
89 ibid., p. 138.

51. 45
5.4 Directory service
The directory service is a backend service. Its task is to release certificates and
certificate data in form of OCSP responses or revocation lists (please see section
5.6 and 5.7). In a directory service the public keys of all certified parties are
provided online in order to secure the authenticity of sender of a message.90 Thus,
the specific groups and types of certificates issued by the CA grant to the
directory proxy basic service a directory service, through which all certificates
created by the CA are available.
The implementation of the directory service is limited only to several certificate
oncept91, more specific - what persons are assignable.
If the certificates cannot be accessed via the directory service, the required
certificates for the authentication are embedded for example in signatures.
The following directory services are implemented:
5.4.1 HPC and SMC-B certificates
For signature verification and other purposes (consignment of encrypted messages
to the healthcare professional), the certificates of the healthcare professional have
to be allocated in the directory services. Also, these services provide applicable
search-functions. In particular, the specifications to the directory services
determine the issued sectors.92
90 cf. gematik (2008f), p. 99.
91 ibid., p. 99.
92 cf. gematik (2008e), p. 138.

52. 46
5.4.2 eHC- certificates
Generally, the eHC- certificates cannot be accessed through the directory services,
because the chip cards are not constantly connected to the system and the
verification as well as update of the certificate is not mandatory. So the
certificates should be integrated in messages and electronic documents.93
5.4.3 Service and infrastructure certificates
Directory services are provided for service and infrastructure certificates as well.
These services conduce particularly to the signature verification or signature
encryption, when the certificate owner is not capable of providing such ones.
Therefore, the directory services should permit only direct access of certificates
and no variable search.94 Certificates, which cannot be accessed directly, are
usually searched within the structure, but not variable.
93 cf. gematik (2008e), p. 138.
94 ibid., p. 138.

53. 47
Figure 19: Normative PKI basic services group two
5.5 Certificate validation basic service
The certificate validation basic service is a consumer service. Its task is to secure
the validation of a certificate (e.g. for the certificate retrieval basic service as
already mentioned in section 5.2). The validation requires two phases,
implemented by the certificate validation basic service:
Validation of certificate status through OCSP via OCSP-Client (please see
section 5.6.1). In some specific cases the certificate status can be validated
via CRL validation basic service (please see section 5.7).

54. 48
Validation of certificate authenticity via a CA and returning it to a trust
anchor95. Each certificate leads back to a bridge CA, which is possible
using the TSLs, initialized by the TSL retrieval basic service (please see
section 3.2).
5.6 OCSP basic services
Before we discuss the OCSP and CRL basic services in particular, we will explain
the goal for their creation and implementation. The existing CRL-based methods
are proposed to verify the availability of certificate, but they cannot provide the
current certificate status information. For this reason the OCSP has been proposed
to overcome the problem.96
enables applications to determine the (revocation) state of an identified
certificate. 97 It defines the format and the structure of a message between the
server and the client. Compared to the CRLs the OCSP provides more timely
revocation information and is capable of obtaining additional status information.98
does not contain any concrete explanation about the
operation and mechanisms about checking certificate status validation. 99
5.6.1 OCSP-Client basic service
The OCSP-Client basic service is a consumer service. Via the OCSP-Client the
validity of a certificate is verified online towards OCSP-Requester.100 In other
words an OCSP Client issues a status request to an OCSP responder and
95 Trust anchor-a CA that the PKI user explicitly trusts under all circumstances.
96 Abraham et al. (2003), p. 208.
97 Myers et al. (1999), p. 1.
98 cf. Myers et al. (1999), p. 1.
99 Abraham et al. (2003), p. 208.
100 cf. gematik (2008e), p. 139.

55. 49
suspends acceptance of the certificate in question until the responder provides a
response. 101 The signed response is accepted as valid if the OCSP-Client
confirms the following:
1. The certificate identified in the response corresponds to the certificate
identified in the corresponding request;
2. The signature on the response is valid;
3. The identity of the signer coincides with the recipient of the request.
4.
5. The time at which the status being indicated is known to be correct is
sufficiently recent.
6. When available, the time at or before which newer information will be
available about the status of the certificate is greater than the current
102
5.6.2 OCSP-Requester
The OCSP-Requester service is a backend service. Its task is to forward the
requests from the OCSP-Clients to the OCSP-Responder. It administrate
any data, but serves only as connector for performance optimization and for
101 Myers et al. (1999), p. 1.
102 ibid., p. 5.

56. 50
expansion of availability. The OCSP request message contains version of the
protocol, service request, target certificate identification as well as optional
extensions.
5.6.3 OCSP-Responder
The OCSP-Responder service is a backend service. Its function is to deliver the
current certificate status value. There are three main states of certificate to be
distinguished good , and . In case of a
certificate the OCSP-Responder has to return the revocationTime additionally to
the state. 103
5.7 CRL Basic services
There are three CRL basic services: the CRL validation basic service (consumer
service), the CRL provider proxy and the CRL provider basic services (backend
service).
The task of the CRL validation basic Service is to check the certificate status on
hand of a CRL.104 The CRL is a list, including the certificate serial numbers of the
revoked certificates and acts as a kind of blacklist105. The CRL stored by the CRL
server is digitally signed by the CA and is updated frequently. 106 The usage of the
CRLs is possible for status validation in documented exception cases (such as for
example certificate validation of VPN-concentrator); generally the OCSP is used
in cases of exception.
103 cf. Drake (2003), p. 84.
104 cf. gematik (2008e), p. 139f.
105 cf. Drake (2003), p. 84.
106 cf. Ramachandran (2002), p. 87.

57. 51
The CRL Proxy is a backend service. It can be used for performance optimization,
although is admissible only for service and network certificates.107
Figure 20: Normative PKI basic services group three
5.8 TSL Services
5.8.1 Retrieval
The TSL retrieval basic service is a consumer service. Its task is to administrate
and update the local version of TSL, as well as the TSL Provider Service loads the
new versions of TSL via the TSL retrieval basic service.
107 cf. gematik (2008e), p. 140.

58. 52
It is very important to mention that the time frame of the next update is
determined in TSL; it should be consistently distributed and occur at any time
without the high-performance periods within the Telematics infrastructure.
5.8.2 TSL provider basic service
The TSL provider basic service is a backend service. It is used as reference point
for the infrastructure and person TSLs. The infrastructure TSL provider service is
identical with the person TSL provider service, however both are logically
separated services.108 The person TSLs contain all CAs, which have the rights to
issue X.509 certificates for the eHC, HPC and SMC-B. The infrastructure TSLs
contain all CAs, which have the rights to issue service and network certificates.109
Actually, a Web Server provides over HTTP the TSL for download. At this point,
there is no need of any integrity or trust security, because the TSL integrity is
secured through a certificate of the Bridge CA and the TSL data are not trustful.
Nevertheless, the connection can be encrypted and authenticated over SSL.
5.8.3 Creator
The TSL creator basic service is a backend service. Its task is to generate new
versions of TSL, signed via the private key as well as using the public key and the
corresponding X.509 certificate110, towards to provide them to the TSL provider
entities.
108 cf. gematik (2008e), p. 140.
109 ibid., p. 306.
110 cf. gematik (2008d), p. 377.

59. 53
6 Summary and conclusion
This bachelor thesis pays attention to the very complex infrastructure of the
Health Telematics. The theoretical fundamentals of the Health Telematics
infrastructure, Public Key Infrastructure and the different types of certificates used
for transferring and storing data are represented to give an overview on the
complete system. Afterwards it offers an explanation of what model of trust is
applied and why this model eligible for this infrastructure is. The so-called
Bridge-CA model as well as the TSP, TCL and TSL are the basic elements with
the help of which chain-of-trust is established within the structure. Flexibility of
the system is reached by using the Bridge-CA model. All PKI types within the
Telematics infrastructure, viz. PKI for eHC certificates, PKI for CVC certificates,
PKI for services certificates, PKI for HPC/SMC certificates, PKI for network
certificates and PKI for devices certificates are connected via the Bridge-CA
(containing the TSL and TCL). Each one of these PKIs is based on two-level-
hierarchy, consisting of root CAs (or a single root CA in case of CVC PKI) and
second-level-CAs. The CAs have the task of issuing and managing the keys
within the PKI as well as generating and distributing the CRL. Safety by the
execution of the processes between them is very important for the security of the
whole infrastructure. Therefore, the processes executed during the usage of the
CAs are examined in detail. The end of this work focuses on the normative PKI
basic services to show their functionality and way of usage within the Telematics
infrastructure.
Relying on the close examinations, which have been made, the existing
Telematics infrastructure possesses positive as well as negative sides. As a whole,
the Health Telematics infrastructure is specified by good level of security.
Nevertheless there are some problems by the local networking, viz. low security
level, caused by the lack of implementation of one unified security standard. The
development and implementation of such standard will provide long-term
protection, availability and confidentiality for the stored data. The security level of
the and those of the Online Certificate Status Protocol,

60. 54
Complete Revocation List and Trusted-service Status List can be considered as
good. The information for their structure and the processes involved is well
documented. On the other hand there are some obscurities, regarding the model of
trust, the normative PKI basic services and the processes by the root CAs. The
multitude of documents concerning them impedes the study thence the proper
understanding. In this sense, there could be made some improvements by
decreasing the number of documents.
Despite the strengths or weaknesses, the existing Health Telematics infrastructure
is a reliable, trustworthy system, which will play an enormous role for the further
development of the health care sector.

61. VI
Bibliography
Abraham, Ajith; Franke, Katrin; Köppen, Mario (2003): Intelligent Systems
Design and Applications, Berlin/Heidelberg/New York 2003.
Cole, Eric; Krutz, Ronald (2005): Network Security Bible, New York 2005.
Drake, Miriam (2003): Encyclopedia of library and information science, 2.
Aufl., New York/Basel 2003.
Eckert, Claudia (2008): IT-sicherheit: Konzepte-Verfahren-Protokolle, 5. Aufl.,
München 2008.
gematik (2007): Einführung der Gesundheitskarte - Spezifikation der Broker
Services, 2007.
gematik (2008a): Einführung der Gesundheitskarte - PKI für X.509-Zertifikate,
Registrierung eines Trust Service Provider (TSP), 2008.
gematik (2008b): Einführung der Gesundheitskarte - PKI für die X.509-
Zertifikate, Grobkonzept, 2008.
gematik (2008c): Einführung der Gesundheitskarte - PKI für CV-Zertifikate
Grobkonzept, 2008.
gematik (2008d): Einführung der Gesundheitskarte Übergreifendes
Sicherheitskonzept der Telematikinfrastruktur, 2008.
gematik (2008e): Einführung der Gesundheitskarte Gesamtarchitektur, 2008.
gematik (2008f): Einführung der Gesundheitskarte Glossar, 2008.
Housley, R.; Ford, W.; Polk, W.; Solo, D. (1999): Internet X.509 Public Key
Infrastructure Certificate and CRL Profile, http://www.ietf.org/rfc/rfc2459.txt,
January 1999, abgerufen am 23.08.2009.

62. VII
Istepanian, Robert; Pattichis, Constantinos (2006): M-health: emerging mobile
health systems, New York 2006.
Joshi, James (2008): Network Security: know it all, Burlington 2008.
Khosrowpour, Mehdi (1999): Managing Information Technology Resources in
Organizations in the Next Millennium, Hersley/London 1999.
Lee, Roger; Hu, Gongzu; Miao, Huaikou (2009): Computer and Information
Science, Berlin/Heidelberg 2009.
Myers, M.; Ankney, R.; Malpani, A.; Galperin, S.; Adams C. (1999): X.509
Internet Public Key Infrastructure Online Certificate Status Protocol OCSP,
http://www.ietf.org/rfc/rfc2560.txt, June 1999, abgerufen am 29.08.2009.
Obaidat, Mohammad; Boudriga, Noureddine (2007): Security of e-systems
and computer networks, Cambridge 2007.
Paulus, Sacher; Pohlmann, Norbert; Reimer, Helmut (2004): ISSE 2004:
Securing Electronic Business Processes: Highlights of the Information Security
Solutions Europe 2004 Conference, Wiesbaden 2004.
Pohlmann, Norbert; Reimer, Helmut; Schneider, Wolfgang (2007):
ISSE/SECURE 2007: Securing Electronic Business Processes: Highlights of the
Information Security Solutions Europe / SECURE 2007 Conference, Wiesbaden
2007.
Ramachandran, Jay (2002): Designing Security Architecture Solutions, New
York 2002.
Richter-von Hagen, Cornelia; Stucky, Wolffried (2004): Business-Process- and
Workflow-Management: Verbesserung durch Process- Management, Wiesbaden
2004.
Scheer, August-Wilhelm; Jost, Wolfram (2002): Aris in der Praxis,
Berlin/Heilderberg/New York 2002.

63. VIII
Schmeh, Klaus (2009): Elektronische Ausweisdokumente: Grundlagen und
Praxisbeispiele, München 2009.
SGB V (2009): Sozialgesetzbuch Fünftes Buch (V), 2009.
Stallings, William (2006): Cryptography and network security: principles and
practice, Upper Saddle River 2006.
Vacca, John (2004): Public Key Infrastructure: building trusted applications and
Web services, Boca Raton 2004.
Willett, Keith (2008): Information Assurance Architecture, Boca Raton 2008.