Common Criteria Protection Profile Security Module Card Type B (PP-SMC-B) BSI-CC-PP-0053-V2 Approved by the Federal Ministry of Health th Version 1.2, 17 November 2009 Common Criteria Protection Profile Security Module Card Type B —— this page was intentionally left blank —— 2 of 92 Bundesamt für Sicherheit in der Informationstechnik th Common Criteria Protection Profile Version 1.2, 17 November 2009 Security Module Card Type B Foreword This ‘Protection Profile — Security Module Card Type B (PP-SMC Type B)’ 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 3.1, Revision 3 [1], [2], [3] with final interpretations of the CCIMB. Correspondence and comments to this Protection Profile — Security Module Card Type B (PP-SMC- B) 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 th Version 1.2, 17 November 2009 Common Criteria Protection Profile Security Module Card Type B NUR FÜR DIE ERARBEITUNGPHASE GÜLTIG Change history Version Date Reason Remarks th 1.97 15 January 2009 first issue nd 0.98 2 April 2009 nd 0.99 2 September 2009 according the CC3.1 revision 3 th 1.0 4 September 2009 after the remarks of the evaluator th 1.2 17 November 2009 changes according the remarks of the BSI th Last Version: 1.2 (17 November 2009) Variables Name Value Display File name and sizes Set automatically PP3.1_SMC-B_v1.1.doc Last Version 1.2 1.2 th th Date 17 November 2009 17 November 2009 Classification unclassified unclassified Authors Wolfgang Killmann, Dr. Alla Wolfgang Killmann, Dr. Alla Gnedina Gnedina 4 of 92 Bundesamt für Sicherheit in der Informationstechnik th Common Criteria Protection Profile Version 1.2, 17 November 2009 Security Module Card Type B Table of Content 1 PP Introduction......................................................................................................................... 7 1.1 PP reference ................................................................................................................................ 7 1.2 TOE Overview............................................................................................................................ 7 1.2.1 TOE usage and security features for operational use .............................................. 9 1.2.2 TOE type ............................................................................................................... 13 1.2.3 TOE life cycle ....................................................................................................... 13 1.2.4 Avaiable non-TOE hardware/software/firmware.................................................. 17 2 Conformance Claim................................................................................................................ 17 3 Security Problem Definition .................................................................................................. 17 3.1 Introduction............................................................................................................................... 18 3.2 Organisational Security Policies............................................................................................... 24 3.3 Threats ...................................................................................................................................... 25 3.3.1 Threats mainly addressing TOE_ES and TOE_APP ............................................ 25 3.3.2 Threats mainly addressing TOE_IC and TOE_ES................................................ 26 3.4 Assumptions ............................................................................................................................. 27 4 Security Objectives ................................................................................................................. 28 4.1.1 Security Objectives for the TOE ........................................................................... 28 4.1.2 Security Objectives for the Operational Environment .......................................... 31 4.2 Security Objectives Rationale................................................................................................... 32 5 Extended Components Definition.......................................................................................... 34 5.1 Definition of the Family FCS_RNG......................................................................................... 34 5.2 Definition of the Family FIA_API............................................................................................ 35 5.3 Definition of the Family FMT_LIM......................................................................................... 36 5.4 Definition of the Family FPT_EMSEC .................................................................................... 37 6 Security Requirements ........................................................................................................... 38 6.1 Security Functional Requirements for the TOE........................................................................ 39 6.1.1 Cryptographic support (FCS) ................................................................................ 40 6.1.2 Identification and Authentication.......................................................................... 49 6.1.3 Access Control ...................................................................................................... 56 Bundesamt für Sicherheit in der Informationstechnik 5 of 92 th Version 1.2, 17 November 2009 Common Criteria Protection Profile Security Module Card Type B 6.1.4 Security Management............................................................................................ 64 6.1.5 SFR for TSF Protection......................................................................................... 70 6.2 Security Assurance Requirements for the TOE ........................................................................ 73 6.3 Security Requirements Rationale.............................................................................................. 74 6.3.1 Security Functional Requirements Coverage ........................................................ 74 6.3.2 Security Requirements Sufficiency ....................................................................... 76 6.3.3 Dependency Rationale........................................................................................... 81 6.3.4 Rationale for the Assurance Requirements ........................................................... 85 6.3.5 Security Requirements – Mutual Support and Internal Consistency..................... 85 7 PP Application Notes .............................................................................................................. 86 7.1 Glossary and Acronyms............................................................................................................ 86 7.2 Literature................................................................................................................................... 89 6 of 92 Bundesamt für Sicherheit in der Informationstechnik th Common Criteria Protection Profile Version 1.2, 17 November 2009 Security Module Card Type B 1 PP Introduction There exists the following Protection Profile for the Security Module Card Type B: • "Common Criteria Protection Profile Security Module Card Type B (PP-SMC-B)", BSI-CC- PP-0053, version 2.5 from 21.April 2009. This Protection Profile has been prepared according the "Specification German Health Professional Card and Security Module Card"(version 2.3.0 from 04.07.2008) following the rules and formats of Common Criteria Version 2.3. The "Common Criteria Protection Profile Security Module Card Type B (PP-SMC-B)", BSI-CC-PP- 0053-V2, version 1.2 from 17.November 2009, is prepared following the rules and formats of Common Criteria Version 3.1, Revision 3. 1.1 PP reference 1 Title: Protection Profile — Security Module Card Type B (PP-SMC-B)) Sponsor: Bundesamt für Sicherheit in der Informationstechnik Editors: Wolfgang Killmann, Dr. Alla Gnedina, Jens Kroder, T-Systems GEI GmbH CC Version: 3.1 Assurance Level: The minimum assurance level for this PP is EAL4 augmented. General Status: final version Version Number: 1.2 Registration: BSI-CC-P-053-V2 Keywords: electronic health card, security module card 1.2 TOE Overview 2 The protection profile defines the security objectives and requirements for the electronic Security Module Card Type B (SMC-B, German: “Sicherheitsmodul-Karte Typ B”) based on the regulations for the German health care system. It address the security services provided by this card, mainly: - Authentication of the cardholder by use of a PIN, - Card-to-Card Authentication between the Security Module Card Type B (SMC-B) and a Health Professional Card (HPC) or an electronic Health Card (eHC) or another Security Module Cards with and without establishment of a trusted channel, - Document key decipherment for an external application, Bundesamt für Sicherheit in der Informationstechnik 7 of 92 th Version 1.2, 17 November 2009 Common Criteria Protection Profile Security Module Card Type B - Client-server authentication for a client, - Creation of electronic signature for the cardholder. 3 The Target of Evaluation (TOE) is the Security Module Card Type B. The SMC-B is a contact based smart card, which is conformant to the specification documents [20], [22]. The physical characteristics shall comply with ISO/IEC 7816-1 and related standards. 4 The TOE comprises of TOE_IC, consisting of: - the circuitry of the SMC’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 SMC Type B applications (data structures and their content) and TOE_GD - the guidance documentation delivered together with the TOE. 5 The TOE provides the following main security services: (1) Authentication of the cardholder by use of a PIN, (2) Access control for the functions (3) to (9) listed below, (3) Asymmetric card-to-card authentication between the SMC Type B and an eHC, a HPC or an SMC without establishment of a trusted channel, (4) Asymmetric card-to-card authentication between the SMC Type B and a HPC or an SMC with establishment of a trusted channel, possibly with storage of introduction keys, (5) Support of secure messaging by means encryption of data, decryption of data, generation of MAC and verification of MAC, (6) Creation of digital signatures, (7) Document key decipherment and transcipherment, (8) Client-server authentication, (9) Terminal Support Service including random number generation, storage of and cryptographic operation with a private key for TLS protocol ad storage of configuration data and network data. 8 of 92 Bundesamt für Sicherheit in der Informationstechnik th Common Criteria Protection Profile Version 1.2, 17 November 2009 Security Module Card Type B 1.2.1 TOE usage and security features for operational use 6 The TOE is used by an institution which is under control of an individual acting as accredited health profession in a health care environment (1) to support medical assistants, pharmaceutical staff and other persons under control of a health professional using HPC to get access to data eHC, (2) to support trusted channel in interaction with other smart cards, (3) to provide services as creation of digital signatures for documents and for TLS protocol, decryption and client-server authentication for the health institution. 7 The following list provides an overview of the security services provided by the SMC-B during the usage phase. These security services together with the functions for the initialization and the personalization build the TSF scope of control. In order to refer to these services later on, short identifiers are defined: 8 Service_User_Auth_PIN: The human user authenticates himself with his PIN. This service is meant for authentication of the human user to authorize access to services Service_Elec_Signature, Service_Client_Server_Auth and Service_Key_Decryption. In addition it provides privacy protection because certain data in the card (or secured by the card) can only be accessed after user authentication ([20], Chapter 7). Functions to change the PIN or to unblock the PIN (reset the retry counter), when it was blocked (because of successive false PIN entries), are supporting this service. For the latter the PIN unblocking code (PUK) is used, this authentication will be called Service_User_Auth_PUK. 1 9 Service_Asym_Mut_Auth_w/o_SK : Authentication of technical user using asymmetric techniques between the SMC, eHC or HPC without agreement of a symmetric key (cf. [20], chapter 15). This service of the SMC-B includes two independent parts (a) the verification of an authentication attempt of an external entity by means of the commands GET CHALLENGE and EXTERNAL AUTHENTICATE and (b) the command INTERNAL AUTHENTICATE to authenticate themselves to an external entity (cf. to [20], 15.1.2, 15.2 for details). The algorithmic identifier ‘rsaRoleCheck’ is used for the command EXTERNAL AUTHENTICATE and ‘rsaRoleAuthentication’ is used for the command INTERNAL AUTHENTICATE (cf. for details to [20], section 15). 10 Service_Asym_Mut_Auth_with_SM: Mutual Authentication using asymmetric techniques between the SMC-B and a HPC with agreement of symmetric secure messaging keys and establishment of a secure messaging channel after successful authentication as receiver of secured 1 The Abbreviation SK here stands for symmetric key used for establishing Secure Messaging, which is the card security protocol realising a trusted channel. Bundesamt für Sicherheit in der Informationstechnik 9 of 92 th Version 1.2, 17 November 2009 Common Criteria Protection Profile Security Module Card Type B commands and sending of secured responses. The keys of a secure messaging channel are stored temporarily. This service runs a protocol in two linked together parts (a) the command INTERNAL AUTHENTICATE to authenticate themselves to an external entity and (b) the verification of an authentication attempt of an external entity by means of the commands GET CHALLENGE and EXTERNAL AUTHENTICATE (cf. for details to [20], 15.4.4). This service uses the commands INTERNAL AUTHENTICATE and EXTERNAL AUTHENTICATE with algorithmic identifier ‘rsaSessionkey4SM’. 11 Service_Asym_Mut_Auth_with_TC: Mutual Authentication using asymmetric techniques 2 between the SMC-B and a HPC, SMC or eHC , with establishment of a trusted channel keys after successful authentication. The TOE supports secure messaging by means encryption of data, decryption of data, generation of MAC and verification of MAC. This service of the SMC-B runs a protocol in two linked together parts (a) the command INTERNAL AUTHENTICATE to authenticate themselves to an external entity and (b) the verification of an authentication attempt of an external entity by means of the commands GET CHALLENGE and EXTERNAL AUTHENTICATE (cf. for details to [20], 15.4.4). This service uses the commands INTERNAL AUTHENTICATE and EXTERNAL AUTHENTICATE with algorithmic identifier ‘rsaSessionkey4TC’ (cf. for details to [20], section 15) to establish symmetric keys of type desSessionkey4TC for PSO: ENCIPHER, PSO: DECIPHER PSO: COMPUTE CRYPTOGRAPHIC CHECKSUM and PSO: VERIFY CRYPTOGRAPHIC CHECKSUM. 12 Service_Asym_Mut_Auth_with_Intro: Mutual Authentication using asymmetric techniques between the HPC and a SMC-B with storage of introduction keys after successful authentication (cf. for details to [21], sec 6.1.4). This service is meant for situations, where the SMC-B frequently interacts with a manageable number of HPCs, SMC-Bs and SMC-Ks. In the context of the so called “Round of introduction” a mutual authentication with negotiation of session keys is executed; these sessions keys will be stored in a persistent way as „Introduction Keys“ after successful authentication. The agreed introduction keys belong individually to the corresponding authentication keys. The CHR of the involved certificate is stored as key reference after adjusting the index (first byte of CHR) to the computed key material. This service runs a protocol similar to the Service_Asym_Mut_Auth_with_SM, but the algorithmic identifier is ‘rsaSessionkey4Intro’ for both authentication commands (cf. for details to [21], section 7.1.3) in order to request storage of the resulting keys. The authentication related data contain data elements for key computation. The symmetric introduction keys, which are stored this way, will be used as the asymmetric keys for agreement of symmetric trusted channel keys that were involved in the authentication procedure. Thus, an introduction object inherits certain information of the public key certificate as well as security-related properties of the private key. 2 Note the agreement of introduction keys is intended for smart cards often working together as SMC-B and HBA but not eHC. Nevertheless this combination is possible. The SMC specification [22], sec. 6.3.11, states “PrK.SMC.AUTR_CVC is the global private key for C2C-authentication between SMC/eGK” and in table 78 the algid “rsaRoleAuthentication, rsaSessionkey4SM” are defined. Typically only rsaRoleAuthentication will be used. “rsaSessionkey4SM” makes no sense because the eHC cannot send secure messaging commands. It should be “rsaSessionkey4TC” in order to generate secured command for the eHC as reciever. 10 of 92 Bundesamt für Sicherheit in der Informationstechnik