Processes of PKIs, within health Telematics infrastructure
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Processes of PKIs, within health Telematics infrastructure

on

  • 652 views

 

Statistics

Views

Total Views
652
Views on SlideShare
652
Embed Views
0

Actions

Likes
0
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Processes of PKIs, within health Telematics infrastructure Document Transcript

  • 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 ThemaProcesses 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. ITable of ContentsTABLE OF CONTENTS ...................................................................................... IABBREVIATIONS ............................................................................................. IIILIST OF FIGURES .............................................................................................. V1 INTRODUCTION ......................................................................................... 11.1 MOTIVATION .................................................................................................... 11.2 STRUCTURE ...................................................................................................... 12 CERTIFICATES AND THE TELEMATICS INFRASTRUCTURE ...... 32.1 AUTHENTICATION ............................................................................................. 32.2 ELECTRONIC HEALTH CARD ............................................................................. 52.3 HEALTH PROFESSIONAL CARD AND SMART MODULE CARD ............................ 62.4 THE TELEMATICS INFRASTRUCTURE ................................................................. 8 2.4.1 Primary systems ....................................................................................... 9 2.4.2 Telematics infrastructure ....................................................................... 10 2.4.3 Techical services .................................................................................... 112.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)...................................... 182.6 PROCESS DESIGN ............................................................................................ 21 2.6.1 Functions and application of process design ........................................ 21 2.6.2 Aris ......................................................................................................... 223 TRUST MODEL .......................................................................................... 233.1 PKI TRUST MODEL WITHIN THE TELEMATICS INFRASTRUCTURE .................... 233.2 TRUST SERVICE STATUS LIST (TSL)............................................................... 233.3 BRIDGE-CA STRUCTURE ................................................................................. 243.4 REASONS FOR THE USAGE OF A BRIDGE-STRUCTURE WITHIN THE TELEMATICSINFRASTRUCTURE ................................................................................................... 264 PROCESSES OF THE ROOT CA ............................................................ 284.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 ..................................................................... 324.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......................... 354.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 ................................ 374.4 SECURITY ....................................................................................................... 385 NORMATIVE PKI BASIC SERVICES.................................................... 405.1 STRUCTURE AND TYPES OF NORMATIVE PKI BASIC SERVICES ........................ 405.2 CERTIFICATE RETRIEVAL BASIC SERVICE ........................................................ 445.3 DIRECTORY PROXY BASIC SERVICE ................................................................. 445.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................................................... 465.5 CERTIFICATE VALIDATION BASIC SERVICE ...................................................... 475.6 OCSP BASIC SERVICES ................................................................................... 48 5.6.1 OCSP-Client basic service .................................................................... 48 5.6.2 OCSP-Requester .................................................................................... 49 5.6.3 OCSP-Responder ................................................................................... 505.7 CRL BASIC SERVICES ..................................................................................... 505.8 TSL SERVICES ................................................................................................ 51 5.8.1 Retrieval................................................................................................. 51 5.8.2 TSL provider basic service .................................................................... 52 5.8.3 Creator................................................................................................... 526 SUMMARY AND CONCLUSION ............................................................ 53BIBLIOGRAPHY................................................................................................VI
  • 4. IIIAbbreviationsAdV Anwendungen zur Wahrnehmung der Versichertenrechte = services for perception of theAMTS Arzneimitteltherapiesicherheitsprüfung = pharmacotherapy safety testAVS = PhAS Apothekenverwaltungssysteme = Pharmacy Administration SystemsAUT AuthenticationAUTN Authentication Certificate for Information/MessagesC2C Card-to-Cardca. circaCA Certification Authoritycf. confer,compareConnector The secure connection between the local area network (LAN) and the remote Network of the Telematics infrastructure.Connector Identity Private Key and CertificateCRL Certificate Revocation ListCVC Card-Verifiable-Certificatese.g. for exampleeHC eHealth CardeHR electronic health recordsENC EncryptionENCV Encryption Certificate for PrescriptionsEPC Event-driven process chainePrescription electronic PrescriptionGMA(Bundesärztekammer) German Medical AssociationHPC Health Professional Card
  • 5. IVHSM High Security ModuleHTTP Hypertext Transfer Protocolibid. ibidemICC Integrated Circuit Card/SmartcardICCSN Integrated Circuit Card Serial NumberIPSec Internet Protocol SecurityKIS = HIS Krankenhausinformationssysteme = Hospital Information SystemsKBV National Association of Statutory Health Insurance PhysiciansNAP Network Access PointOCSP Online Certificate Status ProtocolOSig Organizational SignatureQES Qualified Electronic SignatureRFC Request for CommentsSDS Service Directory ServiceSigL Signatures LawSMC Smart Module CardSMC-B Smart Module Card Type BSMC-A Smart Module Card Type ASMC-K Smart Module Card Type KSMC-RFID Smart Module Card Type RFIDTSL Trusted-service Status ListVPN Virtual Private Networkviz. videlicet
  • 6. VList of FiguresFIGURE 1: SUCCESSFUL AUTHENTICATION IN CASE OF A SINGLE MESSAGE ................................................................................................ 3FIGURE 2: SUCCESSFUL AUTHENTICATION IN CASE OF AN ONGOING INTERACTION ................................................................... 4FIGURE 3: OVERVIEW OF THE ENTIRE ARCHITECTURE .................... 8FIGURE 4: PRIMARY SYSTEMS ARCHITECTURE .................................... 9FIGURE 5: TELEMATICS INFRASTRUCTURE ......................................... 10FIGURE 6: TECHNICAL SERVICES ARCHITECTURE ........................... 11FIGURE 7: SINGLE CA..................................................................................... 14FIGURE 8: HIERARCHICAL PKI .................................................................. 14FIGURE 9: X.509V3 STRUCTURE .................................................................. 16FIGURE 10: BRIDGE-CA WITHIN THE TELEMATICS INFRASTRUCTURE ............................................................................. 25FIGURE 11: STRUCTURE OF PKI WITH TSL AND INVOLVED PARTIES ................................................................................................. 26FIGURE 12: CREATION OF THE NEW KEY PAIR - PHASE 1 ................ 29FIGURE 13: CREATION OF THE NEW KEY PAIR - PHASE 2 ................ 32FIGURE 14: CREATION OF THE NEW KEY PAIR - PHASE 3 ................ 33FIGURE 15: REGISTRATION OF A SECOND-LEVEL-CA ....................... 34FIGURE 16: ISSUING OF NEW CV-CERTIFICATE FOR A SECOND- LEVEL-CA ............................................................................................. 36FIGURE 17: NORMATIVE PKI BASIC SERVICES ..................................... 42FIGURE 18: NORMATIVE PKI BASIC SERVICES GROUP ONE............ 43FIGURE 19: NORMATIVE PKI BASIC SERVICES GROUP TWO .......... 47FIGURE 20: NORMATIVE PKI BASIC SERVICES GROUP THREE ...... 51
  • 7. 11 Introduction1.1 MotivationDespite of its first designation (for example Global Positioning System(GPS)), theTelematics infrastructure has found application in many different spheres such ashealth 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 verycomplex 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 thequestion about the security.The goal of this thesis is to thresh out the processes by creation and handling ofdigital certificates within the range of the Health Telematics Infrastructure. Forthis purpose the existing logical architecture with its components will beexamined as well as the basic services and different groups of persons that areinvolved.1.2 StructureIn order to examine the structure and security of the certificates in the Telematicsinfrastructure, the structure of this bachelor thesis is build-up as it follows.Chapter 2 focuses on the theoretical fundamentals of the Health Telematicsinfrastructure, Public Key Infrastructure and the different types of certificates usedfor transferring and storing data. Also it will be paid attention to the necessarytypes of cards within the complex system. An analysis of the PKI Trust modelinside the Telematics infrastructure will be performed in chapter 3. Chapter 4 isabout the processes of the root CAs. It will pay attention to specific details as thegeneration of a new key pair for the root CA, registration of the second-level-CAsand issuing of a new CV-Certificate for the second-level-CA. In chapter 5 thenormative PKI basic services, as well as their functionality within the Telematics
  • 8. 2infrastructure will be discussed. Chapter 6 will conclude with a critical view onthe Telematics infrastructure and the processes, which have already beenexamined in detail in this bachelor thesis.
  • 9. 32 Certificates and the Telematics infrastructure2.1 AuthenticationThe authentication service is responsible for confirming the authenticity ofcommunication. There are two particular cases, which can occur (1) a singlemessage (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 message1 cf. Stallings (2006), p. 18.
  • 10. 4In case of a single message (Figure 1), the task of the authentication service is toguarantee in front of the recipient that the origin of the specific message isauthentic, viz. the source of the message and the source, it claims to be from, arethe same.2 Figure 2: successful authentication in case of an ongoing interaction2 cf. Stallings (2006), p. 18.
  • 11. 5By an ongoing interaction (Figure 2), during the initiation of connection theservice confirms the authenticity of the both entities, viz. whether the entities arethose they claim to be. Also the service grants that the connection is not interferedin any way, viz. a third party cannot dissemble as one of the two interactingentities in order to send/receive unauthorized data.3There 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 thetask ] to provide confidence that an entity is not attempting either a 5 Data origin authentication The Data origin authentication sustains applications (e.g. electronicmail) 6are present.2.2 Electronic Health CardIn order to improve the health insurance system the German government enacted alaw7, by which they started an enormous infrastructural Telematics project: theintroduction of a national electronic Health Card (eHealth Card). This3 cf. Stallings (2006), p. 18.4 Stallings (2006), p. 19.5 ibid., p. 18.6 ibid., p. 18.7 SGB V (2009), § 291.
  • 12. 6microprocessor chip card is an important element in the fast developingTelematics infrastructure. This card is simply the key to a health system data aswell as to applications for computing and processing such data. The main purposeby the initiation of this project is the enhancement of efficiency, quality andtransparency in medical care. The solution is a patient based sector-spanningnetwork with persistent information flow. 8 For this reason the top organizationsof the national German health system assumed the responsibility to create andintroduce the required infrastructure and therefore founded gematik Gesellschaftfür Telematikanwendungen der Gesundheitskarte mbH9 in 2005.10The electronic health card (eHC) is a working out of the Fraunhofer Institutesupported by the Federal Ministry of Health in Germany. The eHC is conceivedand developed as a service-oriented architecture (SOA) with some restrictions, the health card can only be accessed locally on the client side; orservices should use remote procedure calls for communication due to performanceand availability issues. 11 As a result, the system architecture is divided intoapplications such as emergency data, electronic prescription (ePrescription),electronic medical report or an e 122.3 Health Professional Card and Smart Module CardThe Health Professional Card (HPC), which nowadays is an immutable part of the concept, primarily was one independent construct. In 1996 the GermanMedical Association (GMA) together with the National Association of StatutoryHealth Insurance Physicians Elektronischer8 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. 7Arztausweis ated on this subject. Rapidly came clear that theintroduction of the HPC would not be possible without a reconcilement with theeHC.13 HPC can be defined as an individually programmed accessauthorization card held by the health professionals 14 (e.g. doctors andpharmacists).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 oftheir own. For example, a medical association can upload a database with specificmedical data online, where the HPC serves as an access key instead of passwordand 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. Thefirst two of them can be treated as constricted HPC. They give the possibility tomedical secretaries, nurses etc., to start different activities and so to disburden thedoctors and pharmacists. The goal of SMC-A is to execute the issuance of adigital 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. TheSMC-B is issued for an institution (e.g. hospital). Using the card this institutioncan authenticate itself over the Telematics infrastructure or eHC, and also issuedigital certificates. The third variant of SMCs the SMC-K is intended for usagein small or middle institutions. It is integrated in the connector (please see section2.4.2). SMC-K secures the communication of the connector with the broker, cardterminal and HPC.1513 cf. Schmeh (2009), p. 153.14 Istepanian/Pattichis (2006), p. 103.15 cf. Schmeh (2009), p. 153.
  • 14. 82.4 The Telematics infrastructureHealth Telematics designates the combination of telecommunication andinformatics in the healthcare sector. In some countries, Health Telematics - -seems to be currently establishing itself both in Germany and at an internationallevel.The entire architecture is shown in Figure 3. Figure 3: overview of the entire architecture1616 cf. gematik (2008e), p. 28.
  • 15. 92.4.1 Primary systems Figure 4: Primary systems architectureThe primary systems (Figure 4) provide application programs for the medical careproviders and insurants. The programs used by the medical care providers arePractice Administration Systems (PAS) for medical specialists and dentists,Hospital Information Systems (HIS) for hospital, rehabilitation centers etc. andPharmacy Administration Systems (PhAS) for pharmacies. The programs, whichare relevant for the insurants are eKiosk and Versicherten@Home. They providefunctions for the insurants to access their data, in order to Show specificdata as well as to administrate the rights or in some cases to delete data.1717 cf. gematik (2008e), p. 29.
  • 16. 102.4.2 Telematics infrastructure Figure 5: Telematics infrastructureThere 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 terminalsare managed via connectors. The connectors have gateways to the primarysystems and card terminals. Also, across them the connectors have access to thechip cards. Finally, the connectors access the Telematics network and applicationgateways (Broker services).18Telematics implements a very complex networked system, which is based on andsecured by central gateways. Over connectors more than 100000 medical anddental practices, 2000 hospitals as well as 21000 pharmacies are connected to theTelematics infrastructure. The access to the communication system is secured via18 cf. gematik (2008e), p. 29.
  • 17. 11network gateways (VPN-gateways). The VPN-gateways grant, that only theapproved connectors have access to the communication system.19Via application gateways the access to the sever-based application services ismanaged and secured by the so called Broker services. The Broker services allowthe central allocation of standard processing between connector and technicalservices.202.4.3 Techical services Figure 6: technical services architectureThere are two types of technical services (Figure 6) obligatory and optionalservices. The obligatory services of eHC are those that manage particularlyadministration data of insurants and also the transfer of medical prescriptions.21Obligatory services are insurants19 cf. gematik (2008e), p. 30.20 ibid., p. 31.21 SGB V (2009), §291a.
  • 18. 12management, services for perception of the insurants (AdV). Optionalservices are emergency data, pharmacotherapy safety tests (AMTS) and electronichealth records (eHR).222.5 Foundations of certificates and public key infrastructures2.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 goalby PKI is to brace a set of public and private keys with a person or device in orderto e.g. check, verify identity or for privacy purposes when exchanging data.23There are fundamental differences in usage and storing between thesemathematically related keys. The private key has to be kept under the control ofits owner. Just in the opposite the public key, can be distributed overpublicly available directories for use by any individual who wishes to participatewithin a security service with the person holding the private key related to thatpublic key. 24 This system has proved its high level of efficiency based on theboth keys (private key and public key), forming a mathematically related pair, soit is to obtain the private keyfrom knowledge of the public key and the algorithm, using them (public key andalgorithm). Another important security aspect is the distribution of the public keyswithin PKIs. It is attained via digital certificates based on X.509 standard.25Building 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. 13belong to the entity (individual or system) with whom they are communicating. 26Therefore, 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 symmetrickey cryptography, PKI offers very strong authentication system. 272.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 issuesdigital certificates exerting a digital signature algorithm, which brace the identityof a user or system to a public key. The keys issued by the CA are in the form ofcertificates (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 thepublic keys.In some cases organizations have the possibility to use their own CAs, but theyhave to build them and to provide the necessary support. Furthermore, in mostcases such organizations prefer to outsource their CAs to third-party vendors.Nevertheless, for the conventional and proper functioning of the PKIs, the CA hasto be safe and secured, also to possess the corresponding necessary support.28There are three types of CAs PKIs single CA PKI, hierarchical PKI and meshedPKI. Because of their usage and application, regarding the Telematicsinfrastructure 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 CA29Theoretically, by the single CA (Figure 7: single CA), in order to incorporate inthe PKI system, the user generates its own public/private key pair and sends arequest to the CA to certify the public key. The confirmation from the CA, that thepublic key really does belong to the person in question (the CA issues a digitalcertificate as a confirmation), is sent back to a recipient whenever the person isabout to communicate with some party with public key encryption or digitalsigning. 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 keyof the sender. Thethe CA, and an expiration date. 30But the single CA PKI is possible only theoretically. As a matter of fact the PKIsystem is designed as a multiple-levels-hierarchy, which manages certificategeneration and verification between CAs. (Figure 8: hierarchical PKI) Figure 8: hierarchical PKI3129 Joshi (2008), p. 222.30 ibid., p. 222f.31 ibid., p. 222.
  • 21. 15The 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 forall 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 bythe user, this CAs is always capable of finding a higher-level CA in the treestructure. 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 certificateof a user consists of two parts: (1) a message issued by a high-level CA to certifya low-level CA and (2) a message issued by the low-level CA who will eventuallycertify the public key of the user. 32 By this way is established a chain-of-trust oftwo CAs, so the path validation can be managed. As a result, every entity thatdesignates 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 estimatedtime for verifying a certificate increases every additional level in the hierarchy. 332.5.3 X.509 Certificate2.5.3.1 X.509 Certificate structureThe public-key certificate format, which is the most feasible within the Telematicsinfrastructure, is the X.509.34 One X.509 certificate possesses the followingobligatory structural elements (shown in Figure 9) and is signed with thecorresponding 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 structure35The applied certificate format is specified within the Version -element. Therecan be changes to the certificate version. For example the first version from 1988has the version number v1 and is identified with version value 0. In 1996 theversion v3 (X.509v3) was released, which contains extensions of the primarystructure. The specification of the issuer Issuer - element) or thename of the user Subject -element) allows multiple application ofthese names. extension -element can be specified a sequence of one ormore extensions, such as KeyUsage, PrivateKeyUsagePeriod or certificatepolicies.36 KeyUsage - extension specifies, for what purpose (encipherment,35 cf. . Eckert (2008), p. 380.36 ibid., p. 380.
  • 23. 17signature, certificate signing)37 the key contained in the certificate can be used.38 PrivateKeyUsagePeriod -extension allows the certificate issuer tospecify a different validity period for the private key than the certificate. 39 By the certificatePolicies -extension can be specified the terms under which thecertificate has been issued and the purposes for which the certificate may beused. 40It is responsibility of the certifying entity (CA) that two certificates cannot beissued with the same serial number. In order to verify a certificate the recipientneeds data for the hash and signing methods and for the public key of the signingentity as well. This data is contained in the certificate. The name of the certifyingentity identifies explicitly the service, which confirms the properness of thecertificate. The certificate issuer can specify the validity period, defined via thesub- notBefore notAfter -sub-element (w Subject -field) is defined theuser, for which the certificate is issued (for server, particularly for web-servers,server- - ] is usedto carry the public key and identity of the algorit 41They can differ from the algorithms, used by the certifying entity.2.5.3.2 Personal assigned X.509 CertificatesThe 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 certificatesthe 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. 18Furthermore, the data of the card owner can be encrypted. 42 In other words, thereare the actual personal assigned X.509 Certificates for authentication (AUT),encryption (ENC) and the Qualified Electronic Signature (QES), which isoptional. Besides these three types of certificates, by the eHC are used twoadditional ones ENCV and AUTN. They can be used for technical purposeswithout PIN verification.43For the HPC are defined four types of X.509 Certificates, whereas these forQualified Signatures are issued only by the accredited providers and can beaffiliated to the SigL Root of the Federal Network Agency. By the QualifiedSignatures, which are issued under the responsibility of the GMA, AttributeCertificates are provided, describing the professional rights of the doctors. By thecertificates of apothecaries and psychotherapists is abstained from the additionalAttribute Certificates.For the SMCs the X.509 Certificates as well as the CVC are defined with roleattributes. More specific is the situation by the SMC-B, where in addition to theEncryption and Authentication Certificates are used the OrganizationalCertificates (OSig).442.5.4 Card Verifiable Certificates (CV-Certificates)Card-verifiable certificate (CVC) is a digital certificate. In comparison with theX.509 certificates, which require more memory capacity, due to the flexibility andthe usage of complex algorithms, the CVCs are applicable for authentication andtherefore have simplified structure. More specific the CVC are used for directmutual authentication between chip cards (for example authentication betweeneHC and HPC) within the Telematics infrastructure.45 In addition, these cards42 cf. gematik (2008e), p. 134.43 cf. gematik (2008b), p. 14.44 ibid., p. 14.45 cf. gematik (2008c), p. 13.
  • 25. 19contain 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 AuthenticationBy the Card-to-Card Authentication, one particular card verifies its authenticity toanother one. Additionally, depending on the specific executed C2C Authenticationand 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.4746 cf. gematik (2008c), p. 13.47 ibid., p. 13.
  • 26. 202.5.4.2 Specificities by the CVCsThe CV-Certificates cannot be revoked as the X.509 certificates, because the chip authenticity (butnot the validity) of the certificates can be checked, if all CV-Certificates can betraced back to one explicit CVC-Root-CA, with well-known for each card,certificate. Nevertheless, the CV-Certificates can be verified and analyzed by thecards, which is not possible by the X.509 certificates.48In addition to the different technical parameters, the CVC contains IntegratedCircuit Card Serial Number (ICCSN) and Access Profile. By this Profile isdetermined, what is the access level to the data or the feasibility of other functionsin one card by the C2C-Authentication. Thus, there are two types of AccessProfiles: Access Profile for Role Authentication Access Profile for Function Entity Authentication of the cardAccording to the allocation of the different CV-Certificates on the card types thereare: 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.4948 cf. gematik (2008c), p. 13.49 ibid., p. 14.
  • 27. 212.5.4.2.1 Role AuthenticationFor a Role CV-Certificate, contained in eHC, HPC or one SMC-A/SMC-B, theAccess Profile specifies which Role has the card owner (person or organization).Via this Role within the CV-Certificate is specified what access rights over thedata saved on the other card becomes the card holder after a C2C authentication.502.5.4.2.2 Function Entity Authentication of the cardFor a CV-Certificate, contained within HPC, SMC-A, SMC-B, SMK-K or SMC-RFID, the Access Profile specify which Function Entity contains this particularcard.512.6 Process Design2.6.1 Functions and application of process designBefore dealing with business processes or workflow processes they have to bedesigned. The process model is carried out by one or more designers. They can beexternal consultant, system analyzer, end user or administrator, whereas acombination between them is also possible. The generated process model isfoundation for the work of the system developers and programmer by the modeltransformation into executable/ working system. Furthermore, the systemanalyzers use this model to improve or customize the process. The managementoperates with the model in order to make strategic improvements if possible. Forthe end user and administrator it serves as an instrument for documentation. The50 cf. gematik (2008c), p. 14.51 ibid., p. 14.
  • 28. 22design is always context-sensitive. It is important in which sphere the processmodel will be applied and what is the main goal of the process. Hence there arethree basic questions it 522.6.2 ArisFor the better representation and understanding of the processes within theTelematics infrastructure, in this bachelor paperwork will be used Aris. Arisstands for a group of systems, which essential characteristic consists in that, todesign, analyze and document business or workflow processes. In this case theterm workflow process covers not only the control flow, viz. the chronologicalsequence of the functional fulfillment, but also the directly connected dataspecifications, organization specifications and resources specifications.53 The typeof model, which fully covers the requirements by representing the processeswithin the Telematics infrastructure Business process -model type. Itdescribes the process as a sequence of events and activities (Event-driven processchain or EPC) and also gives the possibility to add more detailed information byusing organizational units, IT systems and data.52 cf. Richter-von Hagen/Stucky (2004), p. 61-62.53 cf. Scheer/ Jost (2002), p. 16.
  • 29. 233 Trust Model3.1 PKI Trust Model within the Telematics infrastructureWithin the Telematics infrastructure several different PKI trust models have beendeveloped and tested especially the hierarchical model based on a root CA and thecross-certification model.54clear that absolute hierarchical trust model cannot be used within the PKI, becausethe flexibility of the Telematics infrastructure will be limited.55 In view ofovercoming this problem, the Bridge-CA model has been developed. It is acombination of the root CA and cross-certification model. Before we discuss moredetailed the Bridge-CA we will scrutinize the main element, on which thisstructure/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 publicaccess and provides actual information about numerous aspects of the service in 56Within PKI there are two different TSLs: TCL (Trusted Component List) andpersonal TSL (Trust-service Status List). In the TCL all CAs are included, whichare authorized to issue a certificate whether for the IPSec-Access to theTelematics infrastructure or for an authentication between two services (Networkand Service Certificates). In the TSL all CAs are included, which are authorized to54 cf. Paulus et al. (2004), p. 44.55 cf. gematik (2008e), p. 135.56 Paulus et al. (2004), p. 44.
  • 30. 24issue a certificate for physical and juristic persons (Certificates for eHC, HPC andCV-Certificates).573.3 Bridge-CA structureThe Bridge-CA model within the Telematics infrastructure is shown in Figure 10.There are six different spheres in which the certificates can be divided eHCcertificates, CVC certificates, services certificates, HPC/SMC certificates,network certificates and devices certificates.Each certificate and therefore each public key within the PKI is signed throughone Certification Authority to confirm the authenticity. Additionally, the signingCA must be a trustful one. The trust in a CA can only exist, when all securityspecifications of the CA fulfill the requirement, that their abidance can beconfirmed by one independent entity. The public key distribution via a centralentity is considerably reduced for the system management, because the public keyof this entity has to be distributed to all Telematics systems integrity-secured. Allfurther public keys can be traced back to this central entity, thus the validity canbe verified. Validation of trust is not necessary, concerning public keys.58From the certificate type and certificate content is clear, for which sphere it wasgenerated. In each one of these spheres can exist more than one root-CA thatrespectively has Sub-CAs (TrustCenter for Qualified Signatures). There is anexception, 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/definiteroot CA.57 cf. gematik (2008e), p. 294.58 ibid., p. 135.
  • 31. 25 Figure 10: Bridge-CA within the Telematics infrastructure59Each of these Root-CAs, presented within this Trust Model, must be authorizedby a TrustCenter by being included in a Trusted-Service-Status-List (TSL). TheTSL contains the public keys of all trustworthy CAs, the data about the certificatetypes, accredited for these CAs, as well as the address of the certificate statusservices (OCSP-Responder and CRL Provider). The TSL is validated through thegematik TSP (Trust Service Provider).60 All authorized TSPs must be available inthe TSL (gematik Trusted-service Status List), but not before they have beenregistered by the gematik.6159 gematik (2008e), p. 135.60 cf. gematik (2008e), p. 135f.61 cf. gematik (2008a), p. 14.
  • 32. 263.4 Reasons for the usage of a Bridge-Structure within the Telematics infrastructureThe concept of two-level-hierarchy, which is specified by law for the QualifiedElectronic Signatures with provider accreditation, is not applicable for theEncryption (ENC), Authentication (AUT) and Organizational (OSig) Signatures,because of the expected multitude of certificate issuers and the integration of theexisting structures. The following figure shows the involved parties in the PKI, aswell as the complexity of the system.62 Figure 11: Structure of PKI with TSL and involved parties6362 cf. gematik (2008a), p. 12.63 gematik (2008a), p. 12.
  • 33. 27Regarding consumer protection, aspects of commitment, identification andregistration through the cost units, a specified method/mechanism for decryptionof data, if the ENC-key is lost, duration and costs of the introduction, there arefundamental differences of the regulation by the Qualified Certificates. Thereforeas a trust model is used a Bridge-Structure, by which the individual information ofevery single TSP is saved in one signed XML-file (TSL).64Another very important aspect for the security of the complete system is thesecurity of the PKI for CV-Certificates. This will be discussed in chapter 4 withits specific features.64 cf. gematik (2008a), p. 14.
  • 34. 284 Processes of the root CAIn the following chapter the processes, which are executed during the usage ofroot CAs, will be examined more detailed. First of all we will make clear what isroot CA in its essence. The highest level, or root, of the hierarchy of trust is theroot certificate authority. It is normally maintained offline and only accessedwhen needed for signing purposes. Root CA responsibilities also include thegeneration and distribution of the Certificate Revocation List (CRL) in cases ofany private key compromise in branches directly below the root. Root certificatesare self-signed65. 66The processes of the root CA can be divided into two groups main and subprocesses. There are three main processes process by generation of new key pairfor 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 CAThis 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 acertain point for the issuing of new CV-Certificates, also the associated public keymust be appropriately released.6765 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 1Figure 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. 304.1.1 Generation of the new key pairIt must be internally initiated in the HSM (please see Figure 12).68 HardwareSecurity Module (HSM, also "Crypto-Box") is a component, integrated in thehardware with corresponding qualified functionality, which secure the private keyof the broker-components and can execute cryptographic operations (e.g. signing).Because the private key is known only within the HSM, a successful intrusion intothe broker and/or security entity would not compromise the private key of thebroker.694.1.2 Creation of a backup for the new key pairIt is internally initiated in the HSM (please see Figure 12).4.1.3 Release of the public keyThe public key must be read-out by the HSM, and subsequently released inapplicable form. Particularly, all data-processors/card-producers must receive thiskey (please see Figure 12).4.1.4 Notification of the second-level-CAsThe second-level-CAs must be notified/ informed about this process (please seeFigure 13).4.1.5 Issuing Cross CV-CertificatesWith the current key pair must be issued a Cross CV-Certificate across/ throughthe public key of the new key pair and the opposite- with the new key pair must beissued a Cross CV-Certificate across/ through the public key of the current keypair.68 cf. gematik (2008c), p. 22.69 cf. gematik (2007), p. 35f.
  • 37. 31This 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 tobe activated (please see Figure 13).704.1.6 Initialization of the CV-CertificateThe connector must possess the corresponding Cross CV-Certificates of the rootCA, so the eHC, HPC and the SMC can execute a C2C-Authentication even thenwhen their current CV-Certificates are different Root-versions. Because of this theroot CA provides the issued Cross CV-Certificates on a server, from which allcomponents 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 tobe activated and Cross CV-Certificate has to be issued (please see Figure 14).7170 cf. gematik (2008c), p. 22.71 ibid., p. 22.
  • 38. 32 Figure 13: Creation of the new key pair - Phase 24.1.7 Activation of new key pairThe 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 apartchronologically, so the associated Cross CV-Certificates can be prepared on timefor download before the actual activation (please see Figure 13).7272 cf. gematik (2008c), p. 22.
  • 39. 33 Figure 14: Creation of the new key pair - Phase 34.2 Registration of the second-level-CAsThis 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 externalservice providers.
  • 40. 34One second-level-CA is registered by the root CA (Figure 15) before it canrequest a corresponding CV-Certificate across its public key.73 Figure 15: Registration of a second-level-CAFigure 15 includes the sub processes from section 4.2.1, 4.2.2, 4.2.3, 4.2.4 and4.2.5.73 cf. gematik (2008c), p. 23.
  • 41. 35Sub processes (from the side of the root CA):4.2.1 Request acception4.2.2 Request verification4.2.3 Notification (of the requesting CA) about the result4.2.4 Storing the result in the internal CA databaseIn 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 thefollowing 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-Certificate4.2.5 Storing the verification in the internal registration logThe 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 theroot CA.744.3 Issuing of a new CV-Certificate for a second-level-CAFor CA upon request is issued a new CV-Certificate for its private key with thecurrent key pair of the root CA. After that the new CV-Certificate is forwarded to74 cf. gematik (2008c), p. 23.
  • 42. 36the CA. Verification for this process is saved in the internal certificate protocol ofthe root CA. 75 Figure 16: Issuing of new CV-Certificate for a second-level-CAFigure 15 includes the sub processes from section 4.3.1, 4.3.2, 4.3.3, 4.3.4 and4.3.5.Sub processes (from the side of the root CA):75 cf. gematik (2008c), p. 23.
  • 43. 374.3.1 Accept the requestThe request for the issuing of a new CV-Certificate must be forwarded by the CAand respectively accepted by the root CA.764.3.2 Verification of the request and public keyThe 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 associatedexplanatory statement.4.3.3 Issuing a CV-CertificateWith the current key pair of the root CA is issued a CV-Certificate based on thepublic key within the request.4.3.4 Sending/Forwarding the CV-Certificate to the CAThe newly issued CV-Certificate must be sent/ forwarded to the requesting CA.4.3.5 Storing the verification in the certificate protocolThe request and newly issued CV-Certificate must be saved in the certificateprotocol.7776 cf. gematik (2008c), p. 23.77 ibid., p. 24.
  • 44. 384.4 SecurityAs already mentioned in chapter 3, the security of the PKI for CV-Certificates is avery important aspect for the security of the complete System. Issuing of CV-Certificates, the second-level-CA provides (in collaboration with cards producerand 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.). 78Once a CV-Certificate is issued, it has unlimited validity79. Therefore, it has to beavoided through the security policy of the PKI for CV-Certificates, anunauthorized issuing of CV-Certificates or issuing for unauthorized purposes.The following specifications must be reckoned as minimum standard. Because ofthe fundamental significance of the PKI for CV-Certificates for the Telematicsinfrastructure security, one general security level must be implemented by the rootCA as well as by the second-level-CAs.80For components and services of the Telematics infrastructure, based on theminimum standard of the security concept, specific security and protectionprofiles have to be provided. Tminimum standard and the efficiency of the specified concrete security measuresmust be verified during the evaluation as well as the admission of components orservices 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. 39only in the security boundaries of the Telematics infrastructure, hence the existingsystems of the suppliers and cost objects are not directly affected by the specifiedpolicies and minimum standard of the security concept. These IT-Systems operateunder the security measures and policies, integrated there. The specificapplicational and operational environment of the gateway-components must beadequately secured and the service provider must bear the responsibility for theadequate security.81The operator of the specific CAs can create and implement their own securityconcepts, according to requirements of the ordering party (for example cardsproducer) or their own if the following minimum requirements are performed.One second-level-CA Within the process ofregistration the adherence to the requirements must be substantiated throughsecurity report.8281 gematik (2008d), p. 22f.82 gematik (2008c), p. 25.
  • 46. 405 Normative PKI Basic Services5.1 Structure and types of normative PKI basic servicesWithin the Telematics infrastructure, different services with the samefunctionality have to exist to grant redundancy and backup. There are two basictypes of normative PKI basic services backend services and consumer services,which exchange data and interact with each other.83 Before we examine theservices in details, we will scrutinize the backend and consumer servicesseparately considering the way they process data, their tasks as well as the subtypes into which they can be divided.The backend services are data storage services that generally operate passively.84They grant data for other services and thus must either possess own data or haveaccess to other services within the PKI structure, which allows them to obtain thenecessary 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 irrelevantfor the consumer services. The consumer services are services that do not storeany 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 thecorresponding backend services (every single backend service possesses morethan one entity). The data intended for the consumer service, which is the targetentity, is supplied from (1) the certificate, to which the operation refers, or (2) thecertificate of the signing entity.86 Compared to the backend services, the consumerservices can be summarized into one of the above specified categories services,which have more than one entity, even though they all allocate to the samedatabase and therefore are exchangeable, granting redundancy (e.g. Certificateretrieval basic service, OCSP-Client basic service, CRL validation basic service,Certificate validation basic service and TSL retrieval basic service).87 Thecomplete hierarchy and the connections between the services are shown in Figure17.85 gematik (2008e), p. 295.86 ibid., p. 137.87 ibid., p. 137.
  • 48. 42 Figure 17: Normative PKI basic servicesAfter the introduction of the normative PKI basic services, we will examine theservices and connections between them more detailed. There are three groups ofservices into which we divide this hierarchical structure, consisting of backendand consumer services.The first group of services, shown in Figure 18, consists of the certificate retrievalbasic service (consumer service), the directory proxy and the directory basicservices (backend services). These services will be discussed separately insections 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, CRLvalidation basic service (consumer services), OCSP requestor basic service, OCSPresponder basic service, CRL provider proxy basic service (backend services) and
  • 49. 43CRL provider basic service (backend service), which is optional, as alreadymentioned above in this section. These services will be discussed separately insections 5.5, 5.6, 5.7.The third group of normative PKI basic services, shown in Figure 20, consists ofthe TSL retrieval basic service (consumer services), the TSL providerinfrastructure 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. 445.2 Certificate retrieval basic serviceThe certificate retrieval basic service is a consumer service. Its task is to providecertificates for consumer services, which belong to a specified identity. For thispurpose the necessary data for the explicit identification as well as the certificatetype are turned over to the certificate retrieval basic service. By the certificateretrieval only the necessary certificate is localized and loaded through thedirectory proxy service, as well as its validity is checked by the certificatevalidation service, before provided. It is very important to mention that certificateretrieval is possible only for certificates, which are assigned to appropriatedirectory service (all valid certificates, issued by the CA are available via thedirectory basic service (for more details, please see section 5.4))88.5.3 Directory proxy basic serviceThe directory proxy basic service is a backend service, which establishes theconnection between the certificate retrieval service and directory basic service.Within the PKIs of Telematics infrastructure exist more than one autonomous PKIentities. By this backend service, certificates from the same type are frequentlydistributed between more PKI entities (please see section 2.5.2), so they cannot beallocated without the acknowledgement of the storing PKI or all existing PKIswithin the Telematics infrastructure. The directory proxy basic serviceencapsulates this complexity for the certificate retrieval basic service and localizesthe certificate within several PKI entities completely on the basis of explicitcharacteristics.8988 cf. gematik (2008e), p. 137f.89 ibid., p. 138.
  • 51. 455.4 Directory serviceThe directory service is a backend service. Its task is to release certificates andcertificate data in form of OCSP responses or revocation lists (please see section5.6 and 5.7). In a directory service the public keys of all certified parties areprovided 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 thedirectory proxy basic service a directory service, through which all certificatescreated 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 requiredcertificates for the authentication are embedded for example in signatures.The following directory services are implemented:5.4.1 HPC and SMC-B certificatesFor signature verification and other purposes (consignment of encrypted messagesto the healthcare professional), the certificates of the healthcare professional haveto be allocated in the directory services. Also, these services provide applicablesearch-functions. In particular, the specifications to the directory servicesdetermine the issued sectors.9290 cf. gematik (2008f), p. 99.91 ibid., p. 99.92 cf. gematik (2008e), p. 138.
  • 52. 465.4.2 eHC- certificatesGenerally, the eHC- certificates cannot be accessed through the directory services,because the chip cards are not constantly connected to the system and theverification as well as update of the certificate is not mandatory. So thecertificates should be integrated in messages and electronic documents.935.4.3 Service and infrastructure certificatesDirectory services are provided for service and infrastructure certificates as well.These services conduce particularly to the signature verification or signatureencryption, when the certificate owner is not capable of providing such ones.Therefore, the directory services should permit only direct access of certificatesand no variable search.94 Certificates, which cannot be accessed directly, areusually 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 two5.5 Certificate validation basic serviceThe certificate validation basic service is a consumer service. Its task is to securethe validation of a certificate (e.g. for the certificate retrieval basic service asalready 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 servicesBefore we discuss the OCSP and CRL basic services in particular, we will explainthe goal for their creation and implementation. The existing CRL-based methodsare proposed to verify the availability of certificate, but they cannot provide thecurrent certificate status information. For this reason the OCSP has been proposedto overcome the problem.96enables applications to determine the (revocation) state of an identifiedcertificate. 97 It defines the format and the structure of a message between theserver and the client. Compared to the CRLs the OCSP provides more timelyrevocation information and is capable of obtaining additional status information.98 does not contain any concrete explanation about theoperation and mechanisms about checking certificate status validation. 995.6.1 OCSP-Client basic serviceThe OCSP-Client basic service is a consumer service. Via the OCSP-Client thevalidity of a certificate is verified online towards OCSP-Requester.100 In otherwords an OCSP Client issues a status request to an OCSP responder and95 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. 49suspends acceptance of the certificate in question until the responder provides aresponse. 101 The signed response is accepted as valid if the OCSP-Clientconfirms 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 1025.6.2 OCSP-RequesterThe OCSP-Requester service is a backend service. Its task is to forward therequests from the OCSP-Clients to the OCSP-Responder. It administrateany data, but serves only as connector for performance optimization and for101 Myers et al. (1999), p. 1.102 ibid., p. 5.
  • 56. 50expansion of availability. The OCSP request message contains version of theprotocol, service request, target certificate identification as well as optionalextensions.5.6.3 OCSP-ResponderThe OCSP-Responder service is a backend service. Its function is to deliver thecurrent certificate status value. There are three main states of certificate to bedistinguished good , and . In case of acertificate the OCSP-Responder has to return the revocationTime additionally tothe state. 1035.7 CRL Basic servicesThere are three CRL basic services: the CRL validation basic service (consumerservice), the CRL provider proxy and the CRL provider basic services (backendservice).The task of the CRL validation basic Service is to check the certificate status onhand of a CRL.104 The CRL is a list, including the certificate serial numbers of therevoked certificates and acts as a kind of blacklist105. The CRL stored by the CRLserver is digitally signed by the CA and is updated frequently. 106 The usage of theCRLs is possible for status validation in documented exception cases (such as forexample certificate validation of VPN-concentrator); generally the OCSP is usedin 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. 51The 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 three5.8 TSL Services5.8.1 RetrievalThe TSL retrieval basic service is a consumer service. Its task is to administrateand update the local version of TSL, as well as the TSL Provider Service loads thenew versions of TSL via the TSL retrieval basic service.107 cf. gematik (2008e), p. 140.
  • 58. 52It is very important to mention that the time frame of the next update isdetermined in TSL; it should be consistently distributed and occur at any timewithout the high-performance periods within the Telematics infrastructure.5.8.2 TSL provider basic serviceThe TSL provider basic service is a backend service. It is used as reference pointfor the infrastructure and person TSLs. The infrastructure TSL provider service isidentical with the person TSL provider service, however both are logicallyseparated services.108 The person TSLs contain all CAs, which have the rights toissue X.509 certificates for the eHC, HPC and SMC-B. The infrastructure TSLscontain all CAs, which have the rights to issue service and network certificates.109Actually, 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 issecured 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 CreatorThe TSL creator basic service is a backend service. Its task is to generate newversions of TSL, signed via the private key as well as using the public key and thecorresponding X.509 certificate110, towards to provide them to the TSL providerentities.108 cf. gematik (2008e), p. 140.109 ibid., p. 306.110 cf. gematik (2008d), p. 377.
  • 59. 536 Summary and conclusionThis bachelor thesis pays attention to the very complex infrastructure of theHealth Telematics. The theoretical fundamentals of the Health Telematicsinfrastructure, Public Key Infrastructure and the different types of certificates usedfor transferring and storing data are represented to give an overview on thecomplete system. Afterwards it offers an explanation of what model of trust isapplied and why this model eligible for this infrastructure is. The so-calledBridge-CA model as well as the TSP, TCL and TSL are the basic elements withthe help of which chain-of-trust is established within the structure. Flexibility ofthe system is reached by using the Bridge-CA model. All PKI types within theTelematics infrastructure, viz. PKI for eHC certificates, PKI for CVC certificates,PKI for services certificates, PKI for HPC/SMC certificates, PKI for networkcertificates 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) andsecond-level-CAs. The CAs have the task of issuing and managing the keyswithin the PKI as well as generating and distributing the CRL. Safety by theexecution of the processes between them is very important for the security of thewhole infrastructure. Therefore, the processes executed during the usage of theCAs are examined in detail. The end of this work focuses on the normative PKIbasic services to show their functionality and way of usage within the Telematicsinfrastructure.Relying on the close examinations, which have been made, the existingTelematics 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 securitylevel, caused by the lack of implementation of one unified security standard. Thedevelopment and implementation of such standard will provide long-termprotection, availability and confidentiality for the stored data. The security level ofthe and those of the Online Certificate Status Protocol,
  • 60. 54Complete Revocation List and Trusted-service Status List can be considered asgood. The information for their structure and the processes involved is welldocumented. On the other hand there are some obscurities, regarding the model oftrust, the normative PKI basic services and the processes by the root CAs. Themultitude of documents concerning them impedes the study thence the properunderstanding. In this sense, there could be made some improvements bydecreasing the number of documents.Despite the strengths or weaknesses, the existing Health Telematics infrastructureis a reliable, trustworthy system, which will play an enormous role for the furtherdevelopment of the health care sector.
  • 61. VIBibliographyAbraham, Ajith; Franke, Katrin; Köppen, Mario (2003): Intelligent SystemsDesign 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 BrokerServices, 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-ZertifikateGrobkonzept, 2008.gematik (2008d): Einführung der Gesundheitskarte ÜbergreifendesSicherheitskonzept 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 KeyInfrastructure Certificate and CRL Profile, http://www.ietf.org/rfc/rfc2459.txt,January 1999, abgerufen am 23.08.2009.
  • 62. VIIIstepanian, Robert; Pattichis, Constantinos (2006): M-health: emerging mobilehealth systems, New York 2006.Joshi, James (2008): Network Security: know it all, Burlington 2008.Khosrowpour, Mehdi (1999): Managing Information Technology Resources inOrganizations in the Next Millennium, Hersley/London 1999.Lee, Roger; Hu, Gongzu; Miao, Huaikou (2009): Computer and InformationScience, Berlin/Heidelberg 2009.Myers, M.; Ankney, R.; Malpani, A.; Galperin, S.; Adams C. (1999): X.509Internet 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-systemsand computer networks, Cambridge 2007.Paulus, Sacher; Pohlmann, Norbert; Reimer, Helmut (2004): ISSE 2004:Securing Electronic Business Processes: Highlights of the Information SecuritySolutions Europe 2004 Conference, Wiesbaden 2004.Pohlmann, Norbert; Reimer, Helmut; Schneider, Wolfgang (2007):ISSE/SECURE 2007: Securing Electronic Business Processes: Highlights of theInformation Security Solutions Europe / SECURE 2007 Conference, Wiesbaden2007.Ramachandran, Jay (2002): Designing Security Architecture Solutions, NewYork 2002.Richter-von Hagen, Cornelia; Stucky, Wolffried (2004): Business-Process- andWorkflow-Management: Verbesserung durch Process- Management, Wiesbaden2004.Scheer, August-Wilhelm; Jost, Wolfram (2002): Aris in der Praxis,Berlin/Heilderberg/New York 2002.
  • 63. VIIISchmeh, Klaus (2009): Elektronische Ausweisdokumente: Grundlagen undPraxisbeispiele, München 2009.SGB V (2009): Sozialgesetzbuch Fünftes Buch (V), 2009.Stallings, William (2006): Cryptography and network security: principles andpractice, Upper Saddle River 2006.Vacca, John (2004): Public Key Infrastructure: building trusted applications andWeb services, Boca Raton 2004.Willett, Keith (2008): Information Assurance Architecture, Boca Raton 2008.