VERSION 2.50 Common Criteria Protection Profile electronic Health Card (eHC) – elektronische Gesundheitskarte (eGK) BSI-PP-0020-V2-2007-MA01 Approved by the Federal Ministry of Health Version 2.50, 2nd January 2008 Version 2.50, 2nd January 2008 Common Criteria Protection Profile electronic Health Card —— this page was intentionaly left blank —— page 2 of 82 Bundesamt für Sicherheit in der Informationstechnik Common Criteria Protection Profile Version 2.50, 2nd January 2008 electronic Health Card Foreword This ‘Protection Profile — electronic Health Card (eHC) – elektronische Gesundheitskarte (eGK)’ is issued by Bundesamt für Sicherheit in der Informationstechnik, Germany. The document has been prepared as a Protection Profile (PP) following the rules and formats of Common Criteria version 2.3 [1], [2], [3]. Correspondence and comments to this PP should be referred to: CONTACT ADDRESS Bundesamt für Sicherheit in der Informationstechnik Godesberger Allee 185-189 D-53175 Bonn, Germany Tel +49 1888 9582-0 Fax +49 1888 9582-400 Email Version 2.50, 2nd January 2008 Common Criteria Protection Profile electronic Health Card Contents 1 PP Introduction 7 1.1 PP reference 7 1.2 PP Overview 7 1.3 Conformance Claim 8 2 TOE Description 8 2.1 TOE definition 8 2.2 TOE usage and security features for operational use 9 2.3 TOE life cycle 12 3 Security Problem Definition 15 3.1 Introduction 16 3.1.1 Assets 16 3.1.2 Subjects 18 3.2 Organizational Security Policies 19 3.3 Threats 21 3.3.1 Threats mainly addressing TOE_ES and TOE_APP 22 3.3.2 Threats mainly addressing TOE_ES and TOE_IC 23 3.4 Assumptions 24 4 Security Objectives 25 4.1 Security Objectives for the TOE 25 4.1.1 Security objectives, which are mainly TOE_App oriented 25 4.1.2 Security Objectives, which are mainly TOE_ES oriented 28 4.1.3 Security Objectives, which are mainly TOE_IC oriented 30 4.2 Security Objectives for the Development and Manufacturing Environment 31 4.3 Security Objectives for the Operational Environmen t 32 4.4 Security Objectives Rationale 34 page 4 of 82 Bundesamt für Sicherheit in der Informationstechnik Common Criteria Protection Profile Version 2.50, 2nd January 2008 electronic Health Card 5 Security Requirements 37 5.1 Security Functional Requirements for the TOE 37 5.1.1 Cryptographic support (FCS) 38 5.1.2 Identification and Authentication 43 5.1.3 Access Contro l 47 5.1.4 Inter-TSF-Transfer 50 5.1.5 Security Managemen t 52 5.1.6 General Security Functions 57 5.2 Security Assurance Requirements for the TOE 60 5.3 Security Requirements for the environmen t 61 5.4 Security Requirements Rationale 61 5.4.1 Security Functional Requirements Coverage 61 5.4.2 Functional Requirements Sufficiency 62 5.4.3 Dependency Rationale 65 5.4.4 Rationale for the Assurance Requirements 69 5.4.5 Security Requirements – Mutual Support and Internal Consistency 70 6 Extended Components Definition 71 6.1 Definition of the Family FCS_RND 71 6.2 Definition of the Family FMT_LIM 72 6.3 Definition of the Family FPT_EMSEC 74 7 Annexes 75 7.1 Annex: Guidance on integration of this PP with other PPs in a Security Target 75 7.1.1 PP conformance 75 7.1.2 Security Objectives 76 7.1.3 Security Functional Requirements 76 7.1.4 Security Assurance Requirements 78 7.2 Glossary and Acronyms 78 7.3 Literature 80 Bundesamt für Sicherheit in der Informationstechnik page 5 of 82 Version 2.50, 2nd January 2008 Common Criteria Protection Profile electronic Health Card Tables Table 1: Smart Card Life Cycle Overview13 Table 2: Assets to be protected by the TOE and its environment 17 Table 3: Subjects 19 Table 4: Access Control Policy for Usage Phase 28 Table 5: Mapping of objectives to OSPs, threats, assumptions 34 Table 6: Coverage of Security Objectives for the TOE by SFRs 62 Table 7: Dependency rationale overview 68 page 6 of 82 Bundesamt für Sicherheit in der Informationstechnik Common Criteria Protection Profile Version , electronic Health Card 1 PP Introduction 1.1 PP reference Title: Protection Profile — electronic Health Card (eHC) – elektronische Gesundheitskarte (eGK) Sponsor: Bundesamt für Sicherheit in der Informationstechnik Editors: Bertolt Krüger SRC Security Research & Consulting GmbH CC Version: 2.3 Assurance Level: The minimum assurance level for this PP is EAL4 augmented. General Status: Final version Version Number: 2.50 Registration: BSI-PP-0020-V2-2007-MA01 Keywords: electronic Health Card (eHC), elektronische Gesundheitskarte (eGK) 1.2 PP Overview 1 The protection profile defines the security objectives and requirements for the electronic Health Card (German: “elektronische Gesundheitskarte”) based on the regulations for the German health care system. It addresses the security services provided by this card, mainly: • Mutual Authentication between the eHC and a Health Professional Card (HPC) or a Security Module Card (SMC), • Mutual Authentication between the eHC and a security device (e. g. for online update of contract data in the card), • Authentication of the cardholder by use of one of two PINs, called PIN.CH and PIN.home (which of these PINs is relevant depends on the service the cardholder wants to use), Note: Both of these PINs are used for general functions of the eHC. The electronic signature application (see below) requires a separate third PIN for its exclusive purposes. • Secure storage of contractual and medical data, with respect to confidentiality, integrity and authenticity of these data, • Authentication of the card using a private key and a X.509 certificate and • Document content key decipherment using a private key. Note: The eHC may contain an electronic signature application for the cardholder. This application is subject to the requirements for electronic signatures as defined in national and European law. Separate Protection Profiles exist defining such requirements, for example the SSCD-PPs [1]. Therefore the security requirements for this security feature are not contained in this eHC-PP. Annex 7.1 gives Bundesamt für Sicherheit in der Informationstechnik page 7 of 82 Version , Common Criteria Protection Profile electronic Health Card guidance, how this eHC-PP and for example the SSCD-PP can be integrated in a Security Target. 1.3 Conformance Claim 2 This protection profile claims conformance to - Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, August 2005, version 2.3, CCIMB-2005-08-001 - Common Criteria for Information Technology Security Evaluation, Part 2: Introduction and general model, August 2005, version 2.3, CCIMB-2005-08-002 - Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Requirements, August 2005, version 2.3, CCIMB-2005-08-003 as follows - Part 2 extended, - Part 3 conformant, - Package conformant to EAL4 augmented with ADV_IMP.2, AVA_MSU.3, and AVA_VLA. 4. 2 TOE Description 2.1 TOE definition 3 The Target of Evaluation (TOE) is a smart card, the electronic Health Card (eHC), which is 1 conformant to the specification documents [2] and [3] . The size of the card is type ID-1 according to ISO 7810 (the usual credit-card-size). 4 The card is a card with contacts according to ISO 7816-1 to –3. If it has an additional contact less interface, none of the eHC functions shall be accessible via this interface. 5 The overall system including the TOE and its environment are intended to comply to the relevant German legal regulations, in particular the “Gesetz zur Modernisierung der Gesetzlichen Krankenversicherung” (GKV-Modernisierungsgesetz – GMG), the “Sozialgesetzbuch” (SGB) and the privacy legislation (“Datenschutzgesetze des Bundes und der Länder”). 6 The TOE comprises the following parts TOE_IC, consisting of: 1 In future these specifications may be replaced by further versions. This PP allows the evaluation of cards, which are implemented according to such newer versions, as long as the security properties defined in this PP remain valid for those newer versions of these specifications. page 8 of 82 Bundesamt für Sicherheit in der Informationstechnik Common Criteria Protection Profile Version , electronic Health Card - the circuitry of the eHC’s chip (the integrated circuit, IC) and - the IC Dedicated Software with the parts IC Dedicated Test Software and IC Dedicated Support Software TOE_ES, - the IC Embedded Software (operating system) TOE_APP, - the eHC applications (data structures and their content) and guidance documentation delivered together with the TOE. 7 Note: The short terms TOE_IC, TOE_ES and TOE_APP will be used were appropriate in the rest of this document in order to refer to these parts of the TOE. 2.2 TOE usage and security features for operational use 8 German health insurance companies issue electronic Health Cards to patients insured by them. The card is used by the cardholders, when they use health care services, which are covered by the insurance. A picture of the patient is printed on the card in order to support identification. The eHC contains data for • cardholder identification, • contractual and financial information to be exchanged between cardholder and health care provider and/or the health insurance company and • medical data, including electronic prescriptions. (For a more detailed definition of the assets see section 3.1.) 2 9 In detail the functionality of the card is defined in the specifications : [4] Die Spezifikation der elektronischen Gesundheitskarte, Teil 1: Spezifikation der elektrischen Schnittstelle, Version 2.0.0, 13.12.2007, gematik [5] Die Spezifikation der elektronischen Gesundheitskarte, Teil 2: Grundlegende Applikationen, Version 2.0.0, 13.12.2007, gematik 2 In future these specifications may be replaced by further versions. This PP allows the evaluation of cards, which are implemented according to such newer versions, as long as the security properties defined in this PP remain valid for those newer versions of these specifications. Bundesamt für Sicherheit in der Informationstechnik page 9 of 82 Version , Common Criteria Protection Profile electronic Health Card 10 The following list gives an overview of the main security services provided by the electronic Health Card during the usage phase. In order to refer to these services later on, short identifiers are defined. 3 Service_Asym_Mut_Auth_w/o_SM : Mutual Authentication using asymmetric techniques between the eHC and a Health Professional Card (HPC) or a Security Module Card (SMC) without establishment of a Secure Channel. This service is meant for situations, where the eHC requires authentication by a HPC or SMC, but where the following data exchange is done without help of a security module. Service_Asym_Mut_Auth_with_SM: Mutual Authentication using asymmetric techniques between the eHC and a Security Module Card (SMC) or another security module with establishment of a Secure Channel. This service is meant for situations, where the eHC requires authentication by a SMC or another security module, which provides similar functionality, and where the following data exchange is done with the help of this security module and can therefore be encrypted and/or secured by a MAC. Service_Sym_Mut_Auth_with_SM: Mutual Authentication using symmetric techniques between the eHC and a security module with establishment of a Secure Channel. This service is meant for situations, where the eHC communicates with a central security module, which shares symmetric keys with the card. This may be a security module of the health insurance organisation, when managing the patient contractual data, or a module of the Download Service Provider, which may add new applications to the eHC (or manage the existing ones). Service_User_Auth_PIN: The cardholder authenticates himself with one of his PINs, either PIN.CH or PIN.home. This service is meant as a support service for some of the other services, which may require user authentication. In addition it provides privacy protection because certain data in the card (or secured by the card) can only be accessed after user authentication. In particular this applies to sensitive medical data. Functions to change the PIN or to unblock the PIN, when it was blocked (because of successive false PIN entries) are supporting this service. For the letter the PIN unblocking code (PUC) is used, this authentication will be called Service_User_Auth_PUC. Service_Privacy: The cardholder may deactivate sensitive medical data in the eHC. In order to use this service he authenticates himself with his PIN.home. This service allows the cardholder to prevent health care providers from accessing data, which the cardholder doesn’t want them to know. Note, that that the name 3 The Abbreviation SM here stands for Secure Messaging, which is the card security protocol realising a secure channel. page 10 of 82 Bundesamt für Sicherheit in der Informationstechnik