MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy Table of Contents References .................................................................................................................................................4  Acronyms and definitions .........................................................................................................................5  Introduction  ...................................................................................................................................6  . 1  Firmware and Logical Cryptographic Boundary .......................................................... 8  1.2  Versions and mode of operation ........................................................................... 9  1.3  2  Cryptographic functionality ...................................................................................................... 13  Platform Critical Security Parameters .................................................................... 14  2.1  Platform Public key .......................................................................................... 14  2.2  Demonstration Applet Critical Security Parameters .................................................... 15  2.3  Demonstration Applet Public Keys ........................................................................ 15  2.4  Roles, authentication and services ......................................................................................... 16  3  Secure Channel Protocol (SCP) Authentication ........................................................ 17  3.1  3.2  USR role authentication .................................................................................... 17  3.3  Services ....................................................................................................... 18  Self-test ....................................................................................................................................... 21  4  Power-on self-test ........................................................................................... 21  4.1  Conditional self-tests ........................................................................................ 21  4.2  5  Physical security policy ............................................................................................................ 22  6  Electromagnetic interference and compatibility (EMI/EMC) ............................................... 22  Mitigation of other attacks policy ............................................................................................. 22  7  Security Rules and Guidance .................................................................................................. 22  8  Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 2/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy Table of Tables Table 1 – References ................................................................................................... 4  Table 2 – Acronyms and Definitions .................................................................................. 5  Table 3 – Security Level of Security Requirements ................................................................ 6  Table 4 – Ports and Interfaces ........................................................................................ 7  Table 5 –Versions and Mode of Operations Indicators ........................................................... 12  Table 6 – FIPS Approved Cryptographic Functions ............................................................... 13  Table 7 – Non-FIPS Approved But Allowed Cryptographic Functions .......................................... 13  Table 8 - Platform Critical Security Parameters.................................................................... 14  Table 9 – Platform Public Keys ...................................................................................... 14  Table 10 – Demonstration Applet Critical Security Parameters ................................................. 15  Table 11 – Demonstration Applet Public Keys ..................................................................... 15  Table 12 - Roles description .......................................................................................... 16  Table 13 - Unauthenticated Services and CSP Usage ........................................................... 18  Table 14 – Authenticated Card Manager Services and CSP Usage ............................................ 19  Table 15 – Demonstration Applet Services and CSP Usage .................................................... 20  Table 16 – Power-On Self-Test ...................................................................................... 21  Table of Figures Figure 1 –Physical Form and Cryptographic Boundary (P5CC081 left; P5CC145 right) ..................... 7  Figure 2 - Module Block Diagram ..................................................................................... 8  Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 3/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy References The following standards are referred to in this Security Policy. Acronym Full Specification Name [FIPS140-2] NIST, Security Requirements for Cryptographic Modules, May 25, 2001 GlobalPlatform Consortium: GlobalPlatform Card Specification 2.1.1, March 2003, http://www.globalplatform.org [GlobalPlatform] GlobalPlatform Consortium: GlobalPlatform Card Specification 2.1.1 Amendment A, March 2004 ISO/IEC 7816-1: 1998 Identification cards -- Integrated circuit(s) cards with contacts -- Part 1: Physical characteristics ISO/IEC 7816-2:2007 Identification cards -- Integrated circuit cards -- Part 2: Cards with contacts -- Dimensions and location of the contacts [ISO 7816] ISO/IEC 7816-3:2006 Identification cards -- Integrated circuit cards -- Part 3: Cards with contacts -- Electrical interface and transmission protocols ISO/IEC 7816-4:2005 Identification cards -- Integrated circuit cards -- Part 4: Organization, security and commands for interchange Java Card 2.2.2 Runtime Environment (JCRE) Specification Java Card 2.2.2 Virtual Machine (JCVM) Specification [JavaCard] Java Card 2.2.2 Application Programming Interface Published by Sun Microsystems, March 2006 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key [SP800-131A] Lengths, January 2011 American Bankers Association, Digital Signatures Using Reversible Public Key Cryptography for [ANS X9.31] the Financial Services Industry (rDSA), ANSI X9.31-1998 - Appendix A.2.4. NIST Special Publication 800-67, Recommendation for the Triple Data Encryption Algorithm [SP 800-67] (TDEA) Block Cipher, version 1.2, July 2011 [FIPS113] NIST, Computer Data Authentication, FIPS Publication 113, 30 May 1985. [FIPS 197] NIST, Advanced Encryption Standard (AES), FIPS Publication 197, November 26, 2001. [PKCS#1] PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories, June 14, 2002 NIST, Digital Signature Standard (DSS), FIPS Publication 186-2, January, 2000 with Change [FIPS 186-2] Notice 1. (DSA, RSA and ECDSA) NIST Special Publication 800-56A, Recommendation for Pair-Wise Key Establishment Schemes [SP 800-56A] Using Discrete Logarithm Cryptography, March 2007 [FIPS 180-3] NIST, Secure Hash Standard, FIPS Publication 180-3, October 2008 NIST, AES Key Wrap Specification, 16 November 2001. This document defines symmetric key [AESKeyWrap] wrapping, Use of 2-Key TDEA in lieue of AES is described in [IG] D.2. NIST, Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation [IG] Program, last updated 15 July 2011. Table 1 – References Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 4/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy Acronyms and definitions Acronym Definition GP Global Platform MMU Memory Management Unit OP Open Platform RMI Remote Method Invocation Table 2 – Acronyms and Definitions Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 5/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy 1 Introduction This document defines the Security Policy for the Gemalto MultiApp ID V2.1 cryptographic module, hereafter denoted the Module. The Module, validated to FIPS 140-2 overall Level 3, is a “contact-only” secure controller implementing the Global Platform operational environment, with Card Manager and a Demonstration Applet. The Demonstration Applet is available only to demonstrate the complete cryptographic capabilities of the Module for FIPS 140-2 validation, and is not intended for general use. The Module is designated as a limited operational environment under the FIPS 140-2 definitions. The Module includes a firmware load service to support necessary updates. The loading of non-validated firmware within the validated cryptographic module invalidates the module’s validation; new firmware versions within the scope of this validation must be validated through the FIPS 140-2 CMVP. Any other firmware loaded into this module is out of the scope of this validation and requires a separate FIPS 140-2 validation. The FIPS 140-2 security levels for the Module are as follows: Security Requirement Security Level Cryptographic Module Specification 3 Cryptographic Module Ports and Interfaces 3 Roles, Services, and Authentication 3 Finite State Model 3 Physical Security 4 Operational Environment N/A Cryptographic Key Management 3 EMI/EMC 3 Self-Tests 3 Design Assurance 3 Mitigation of Other Attacks 3 Table 3 – Security Level of Security Requirements The Module implementation is compliant with:  [ISO 7816] Parts 1-4  [JavaCard]  [GlobalPlatform] Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 6/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy 1.1 Hardware and Physical Cryptographic Boundary The Module is designed to be embedded into plastic card bodies, with a contact plate connection. The physical form of the Module is depicted in Figure 1 (to scale); the red outline depicts the physical cryptographic boundary, representing the surface of the chip and the bond pads. The cross-hatching indicates the presence of the hard, opaque outer layer shielding. In production use, the Module is wire- bonded to a frame connected to a contact plate, enclosed in epoxy and mounted in a card body. The Module relies on [ISO7816] card readers as input/output devices. Figure 1 –Physical Form and Cryptographic Boundary (P5CC081 left; P5CC145 right) Pad Description Logical interface type VCC, GND ISO 7816: Power and ground Power CLK ISO 7816: Clock Control in RST ISO 7816: Reset Control in I/O ISO 7816: Serial interface Data in, data out, control in, status out NC No connect Not used Table 4 – Ports and Interfaces Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 7/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy 1.2 Firmware and Logical Cryptographic Boundary Figure 2 depicts the Module operational environment and applets. Figure 2 - Module Block Diagram The Module supports [ISO7816] T=0 and T=1 communications protocol variations and two memory configurations:  M1 (utilizing the NXP P5CC081): 80 Kbyte EEPROM, 264 Kbyte ROM  M2 (utilizing the NXP P5CC145): 144 Kbyte EEPROM, 264 Kbyte ROM The JavaCard API is an internal interface, available to applets. Only applet services are available at the card edge (the interfaces that cross the cryptographic boundary). The Javacard Runtime Environment implements the dispatcher, registry, loader, logical channel and RMI functionalities. The Virtual Machine implements the bytecode interpreter, firewall, exception management and bytecode optimizer functionalities. The Card Manager is the card administration entity – allowing authorized users to manage the card content, keys, and life cycle states. Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 8/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy The Memory Manager implements services such as memory access, allocation, deletion, garbage collector. The Communication handler deals with the implementation of ATR, PSS, T=0 and T=1 protocols. The Cryptography Libraries implement the algorithms listed in section 2. 1.3 Versions and mode of operation Hardware: P5CC081, P5CC145 Firmware: MultiApp ID V2.1, patch V2.2 (for P5CC081 implementation) and V2.4 (for P5CC145 implementation), Demonstration Applet version V1.1 The Module is always in the approved mode of operation. To verify that a module is in the approved mode of operation, select the Card Manager and send the GET DATA commands shown below: Le P1-P2 Field CLA INS Purpose (Expected (Tag) response length) 9F-7F 2A Get CPLC data Value 00 CA 01-03 1D Identification information (proprietary tag) The Module responds with the following information: MPH117 Mask - CPLC data (tag 9F7F) Byte Description Value Value meaning 1-2 IC fabricator 4790h NXP 5081h 3-4 IC type P5CC081 1291h 5-6 Operating system identifier Gemalto Operating system release date 1102h April 12th 2011 7-8 (YDDD) – Y=Year, DDD=Day in the year 0201h 9-10 Operating system release level V2.1 xxxxh 11-12 IC fabrication date Filled in during IC manufacturing xxxxxxxxh 13-16 IC serial number Filled in during IC manufacturing Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 9/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy xxxxh 17-18 IC batch identifier Filled in during IC manufacturing xxxxh 19-20 IC module fabricator Filled in during module manufacturing xxxxh 21-22 IC module packaging date Filled in during module manufacturing xxxxh 23-24 ICC manufacturer Filled in during module embedding xxxxh 25-26 IC embedding date Filled in during module embedding xxxxh 27-28 IC pre-personalizer Filled in during smartcard preperso xxxxh 29-30 IC pre-personalization date Filled in during smartcard preperso IC pre-personalization equipment xxxxxxxxh 31-34 Filled in during smartcard preperso identifier xxxxh 35-36 IC personalizer Filled in during smartcard personalization xxxxh 37-38 IC personalization date Filled in during smartcard personalization xxxxxxxxh 39-42 IC personalization equipment identifier Filled in during smartcard personalization MPH119 Mask - CPLC data (tag 9F7F) Byte Description Value Value meaning 0-1 IC fabricator 4790h NXP 5145h 2-3 IC type P5CC145 1291h 4-5 Operating system identifier Gemalto Operating system release date 1157h June 6th 2011 6-7 (YDDD) – Y=Year, DDD=Day in the year 0201h 8-9 Operating system release level V2.1 xxxxh 10-11 IC fabrication date Filled in during IC manufacturing xxxxxxxxh 12-15 IC serial number Filled in during IC manufacturing xxxxh 16-17 IC batch identifier Filled in during IC manufacturing xxxxh 18-19 IC module fabricator Filled in during module manufacturing xxxxh 20-21 IC module packaging date Filled in during module manufacturing xxxxh 22-23 ICC manufacturer Filled in during module embedding xxxxh 24-25 IC embedding date Filled in during module embedding Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 10/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy xxxxh 26-27 IC pre-personalizer Filled in during smartcard preperso xxxxh 28-29 IC pre-personalization date Filled in during smartcard preperso IC pre-personalization equipment xxxxxxxxh 30-33 Filled in during smartcard preperso identifier xxxxh 34-35 IC personalizer Filled in during smartcard personalization xxxxh 36-37 IC personalization date Filled in during smartcard personalization xxxxxxxxh 38-41 IC personalization equipment identifier Filled in during smartcard personalization MPH117 Mask - Identification data (tag 0103) Byte Description Value Value meaning 0 Gemalto Family Name B0h Javacard 85h 1 Gemalto OS Name MultiApp ID 36h 2 Gemalto Mask Number MPH117 38h 3 Gemalto Product Name Generic MPH117 product Major nibble: flow version = 0h  Minor nibble: conformity to the security certificates  (1b in case of conformity claim, otherwise 0b) 08h 4 Gemalto Flow Version b3 (leftmost bit): conformity to FIPS certificate = 1b b2: conformity to PPSUN certificate = 0b b1: conformity to IAS Classic V3 PPSSCD certificate = 0b b0: conformity to IAS XL PPSSCD certificate = 0b Major nibble: filter family = 2h  22h 5 Gemalto Filter Set Lower nibble: version of the filter = 2h  4790h 6-7 Chip Manufacturer NXP 5081h 8-9 Chip Version P5CC081 0000h 10-11 RFU - xx..xxh 12-17 RFU - xx..xxh 18-28 RFU - Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 11/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy MPH119 Mask - Identification data (tag 0103) Byte Description Value Value meaning 0 B0h Javacard Gemalto Family Name 85h 1 MultiApp ID Gemalto OS Name 37h 2 MPH119 Gemalto Mask Number 39h 3 Generic MPH119 product Gemalto Product Name Major nibble: flow version = 0h  Minor nibble: conformity to the security certificates  (1b in case of conformity claim, otherwise 0b) 08h 4 Gemalto Flow Version b3 (leftmost bit): conformity to FIPS certificate = 1b b2: conformity to PPSUN certificate = 0b b1: conformity to IAS Classic V3 PPSSCD certificate = 0b b0: conformity to IAS XL PPSSCD certificate = 0b Major nibble: filter family = 2h  24h 5 Gemalto Filter Set Lower nibble: version of the filter = 4h  4790h 6-7 NXP Chip Manufacturer 5145h 8-9 P5CC145 Chip Version 0000h 10-11 - RFU xx..xxh 12-17 - RFU xx..xxh 18-28 - RFU Table 5 –Versions and Mode of Operations Indicators The Demonstration Applet AID (application identifier) value is 464950535F546573744170706C657401. It can be retrieved using the GET STATUS command - available after a successful Card Manager authentication – which provides the AIDs of all the packages loaded in the card. P1-P2 Field CLA INS Lc-Le Purpose (Tag) Value 80 F2 20-00 02-00 Get AID list – first command Get AID list, continued (to get the end of the list, Value 80 F2 20-01 02-00 if previous command returned ‘6310 SW) Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 12/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy 2 Cryptographic functionality The Module operating system implements the FIPS Approved and Non-FIPS Approved but Allowed cryptographic function listed in Tables 6 and 7 below. Algorithm Description Cert # RNG [ANS X9.31] Random number generator 1023 [SP 800-67] Triple Data Encryption Algorithm. The Module supports the 2- 1264 Key and 3-Key options; CBC and ECB modes. Note that the Module does Triple-DES not support a mechanism that would allow collection of plaintext / ciphertext pairs aside from authentication, limited in use by a counter. [FIPS113] TDEA Message Authentication Code. Vendor affirmed, based on 1264 Triple-DES MAC validated TDEA. [FIPS 197] Advanced Encryption Standard algorithm. The Module supports 1943 AES 128-, 192- and 256-bit key lengths with ECB and CBC modes. [PKCS#1] RSA signature generation, verification, and key pair generation. 1006 RSA The Module follows PKCS#1 and supports 1024 to 2048-bit RSA keys (by step of 32 bits). [PKCS#1] RSA signature generation, verification, CRT key pair generation. 1010 RSA CRT The Module follows PKCS#1 and supports 1024 to 2048-bit RSA keys (by step of 32 bits). [FIPS 186-2] Elliptic Curve Digital Signature Algorithm. The Module supports 280 ECDSA the NIST defined P-192, P-224, P-256, P-384 and P-521 curves. [SP 800-56A] The Section 5.7.1.2 ECC CDH Primitive. The Module supports 17 ECC CDH the NIST defined P-192, P-224, P-256, P-384 and P-521 curves. SHA-1, SHA-224, SHA- 1706 [FIPS 180-3] Secure Hash Standard compliant one-way (hash) algorithms. 256 SHA-384, SHA-512 [FIPS 180-3] Secure Hash Standard compliant one-way (hash) algorithms. 1707 Table 6 – FIPS Approved Cryptographic Functions Algorithm Description [AESKeyWrap] The Module supports symmetric key unwrapping using 2-Key TDEA. This Symmetric Key Wrap key establishment methodology provides 112 bits of encryption strength. Non-SP 800-56A EC DH. The Module supports the NIST defined P-192, P-224, P-256, EC DH P-384 and P-521 curves. Table 7 – Non-FIPS Approved But Allowed Cryptographic Functions Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 13/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy 2.1 Platform Critical Security Parameters All CSPs used by the Module are described in this section. All usage of these CSPs by the Module, including all CSP lifecycle states, are described in the services detailed in Section 4. Key Description / Usage 2-Key TDEA random loaded into the card during pre-personalization of the card OS-SEED-KEY used as a seed key for the [ANS X9.31] 64 bit random value and 64 bit counter value used in the [ANS X9.31] RNG OS-RNG-STATE implementation. Proprietary information describes seeding and persistence of the RNG state. OS-GLOBALPIN Global PIN value managed by the ISD. OS-MKDK 2-Key TDEA key used to encrypt OS-GLOBALPIN value ISD-KENC 2-Key TDEA Master key used by the CO role to generate ISD-SENC ISD-KMAC 2-Key TDEA Master key used by the CO role to generate ISD-SMAC 2-Key TDEA Sensitive data decryption key used by the CO role to decrypt CSPs for ISD-KDEK SCP01, and used to generate ISD-SDEK in case of SCP02. 2-Key TDEA Session encryption key used by the CO role to encrypt / decrypt ISD-SENC secure channel data. 2-Key TDEA Session MAC key used by the CO role to verify inbound secure ISD-SMAC channel data integrity and authenticity. ISD-SDEK 2-Key TDEA Session DEK key used by the CO role to decrypt CSPs for SCP02. An optional 2-Key Triple-DES key used to verify integrity and authenticity of DAP-DES packages loaded into the module. Table 8 - Platform Critical Security Parameters 2.2 Platform Public key Key Description / Usage RSA 1024 Global Platform Data Authentication Public Key. Optionally used to verify the DAP-SVK signature of packages loaded into the Module. Table 9 – Platform Public Keys Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 14/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy 2.3 Demonstration Applet Critical Security Parameters Key Description / Usage DSC-AES AES 128/192/256 key used by Demonstrate Symmetric Cipher DSC-TDEA 3-Key TDEA key used by Demonstrate Symmetric Cipher DSS-TDEA 3-Key TDEA key used by Demonstrate Symmetric Signature (MAC generation and verify) 1024-, 1536-, 2048- RSA private key used by Demonstrate Asymmetric Signature (signature DAS-RSA generation and verify) P-192, P-224, P-256, P-384, P-521 ECDSA private key used by Demonstrate Asymmetric Signature DAS-ECDSA (signature generation and verify) P-192, P-224, P-256, P-384, P-521 ECDSA private key used by Demonstrate ECC CDH (shared ECDH-ECC secret primitive) DKG-RSA 1024-, 1536-, 2048- RSA private key generated by Demonstrate Asymmetric Key Generation P-192, P-224, P-256, P-384, P-521 ECDSA private key generated by Demonstrate Asymmetric Key DKG-ECDSA Generation Demonstration master key, 3-Key TDEA key used to encrypt or decrypt keys exported out of or DMK imported into the module for use by the demonstration applet. Table 10 – Demonstration Applet Critical Security Parameters 2.4 Demonstration Applet Public Keys Key Description / Usage 1024-, 1536-, 2048- RSA public key used by Demonstrate Asymmetric Signature (signature DAS-RSA-SVK generation and verify) P-192, P-224, P-256, P-384, P-521 ECDSA public key used by Demonstrate Asymmetric DAS-ECDSA-SVK Signature (signature generation and verify) DKG-RSA-PUB 1024-, 1536-, 2048- RSA public key generated by Demonstrate Asymmetric Key Generation P-192, P-224, P-256, P-384, P-521 ECDSA public key generated by Demonstrate Asymmetric DKG-ECDSA-PUB Key Generation Table 11 – Demonstration Applet Public Keys Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 15/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy 3 Roles, authentication and services Table 12 lists all operator roles supported by the Module. This Module does not support a maintenance role. The Module clears previous authentications on power cycle. The Module supports GP logical channels, allowing multiple concurrent operators. Authentication of each operator and their access to roles and services is as described in this section, independent of logical channel usage. Only one operator at a time is permitted on a channel. Applet deselection (including Card Manager), card reset or power down terminates the current authentication; re-authentication is required after any of these events for access to authenticated services. Authentication data is encrypted during entry (by ISD-SDEK), is stored encrypted (by OS-MKDK) and is only accessible by authenticated services. Role ID Role Description CO (Cryptographic Officer) This role is responsible for card issuance and management of card data via the Card Manager applet. Authenticated using the SCP authentication method with ISD-SENC. USR (User) This role has the privilege to use the cryptographic services provided by the demonstration applet. Authenticated using the GLOBAL PIN verification. Table 12 - Roles description Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 16/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy 3.1 Secure Channel Protocol (SCP) Authentication The Open Platform Secure Channel Protocol authentication method is performed when the EXTERNAL AUTHENTICATE service is invoked after successful execution of the INITIALIZE UPDATE command. These two commands operate as described next. The ISD-KENC and ISD-KMAC keys are used along with other information to derive the ISD-SENC and ISD-SMAC keys, respectively. The ISD-SENC key is used to create a cryptogram; the external entity participating in the mutual authentication also creates this cryptogram. Each participant compares the received cryptogram to the calculated cryptogram and if this succeeds, the two participants are mutually authenticated (the external entity is authenticated to the Module in the CM role). [SP 800-131A] Section A.1 provides the NIST rationale for 2-Key TDEA security strength. 2-Key TDEA is used for Global Platform secure channel operations, in which the Module derives session keys from the master keys and a handshake process, performs mutual authentication, and decrypts data for internal use only. The Module encrypts a total of one block (the mutual authentication cryptogram) over the life of the session encryption key; no decrypted data is output by the Module. The Module claims 112-bit security strength for its 2-Key TDEA operations, as the meet-in-the-middle attack rationale described in [SP 800-131A] does not apply unless the attacker has access to encrypt/decrypt pairs. 2-Key TDEA key establishment provides 112 bits of security strength. The Module uses the ISD-KDEK key to decrypt critical security parameters, and does not perform encryption with this key or output data decrypted with this key.  The probability that a random attempt at authentication will succeed is 1/2^64 (the block size), meeting the FIPS 140-2 one in 1,000,000 requirement.  Based on the maximum count value of the failed authentication blocking mechanism, the probability that a random attempt will succeed over a one minute period is 255/2^112, meeting the FIPS 140-2 one in 100,000 requirement. 3.2 USR role authentication This authentication method compares a PIN value sent to the Module to the stored OS-GLOBALPIN values if the two values are equal, the operator is authenticated. This method is used in the Demonstration Applet services to authenticate to the USR role. The Module enforces a minimum character length of 6 characters, allowing all characters, so the strength of this authentication method is as follows: • The probability that a random attempt at authentication will succeed is 1/256^6, meeting the FIPS 140-2 one in 1,000,000 requirement. • Based on a maximum count of 15 for failed service authentication attempts, the probability that a random attempt will succeed over a one minute period is 15/256^6, meeting the FIPS 140-2 one in 100,000 requirement. Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 17/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy 3.3 Services All services implemented by the Module are listed in the tables below. Each service description also describes all usage of CSPs by the service. The ISD-SENC and ISD-SMAC keys are used by every Card Manager service when a secure channel has been established, for decryption and MAC verification (packet integrity and authenticity), respectively. This is noted below as “Optionally uses ISD-SENC, ISD-SMAC (SCP)”. Unauthenticated commands listed below function whether or not a secure channel has been established. Service Description Power cycle the Module by removing and reinserting it into the contact reader slot, or by reader assertion of the RST signal. The Card Reset service will invoke the power on self-tests described in Section 4. Card Reset Moreover, on any card reset, the Module overwrites with zeros the RAM copy of, (Self-test) OS-RNG-STATE, ISD-SENC, ISD-SMAC and ISD-SDEK. The Module can also write the values of all CSPs stored in EEPROM as a consequence of restoring values in the event of card tearing or a similar event. Authenticates the operator and establishes a secure channel. Must be preceded by EXTERNAL a successful INITIALIZE UPDATE. Uses ISD-SENC and ISD-SMAC. AUTHENTICATE Initializes the Secure Channel; to be followed by EXTERNAL AUTHENTICATE. INITIALIZE UPDATE Uses the ISD-KENC, ISD-KMAC and ISD-KDEK master keys to generate the ISD- SENC, ISD-SMAC and ISD-SDEK session keys, respectively. GET DATA Retrieve a single data object. Optionally uses ISD-SENC, ISD-SMAC (SCP). Open and close supplementary logical channels. Optionally uses ISD-SENC, ISD- MANAGE CHANNEL SMAC (SCP). SELECT Select an applet. Optionally uses ISD-SENC, ISD-SMAC (SCP). Table 13 - Unauthenticated Services and CSP Usage Receipt of the first command generates the RAM copy of OS-RNG-STATE and updates the EEPROM copy of OS-RNG-STATE. Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 18/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy Service CO Description Delete an applet from EEPROM. Uses ISD-SENC, ISD-SMAC (SCP). X DELETE This service is provided for use when an applet is loaded on the card, and does not impact platform CSPs Retrieve information about the card. Optionally uses ISD-SENC, ISD- X GET STATUS SMAC (SCP). Perform Card Content management. Optionally uses ISD-SENC, ISD- INSTALL SMAC (SCP). Optionally, the Module uses the DAP key (either DAP-DES X or DAP-SVK) to verify the package signature. Load a load file (e.g. an applet). Optionally uses ISD-SENC, ISD-SMAC X LOAD (SCP). Transfer data to an application during command processing. Optionally X PUT DATA uses ISD-SENC, ISD-SMAC (SCP). Load Card Manager keys X PUT KEY The Module uses the ISD-SDEK session key to decrypt the keys to be loaded. Optionally uses ISD-SENC, ISD-SMAC (SCP). Modify the card or applet life cycle status. Optionally uses ISD-SENC, ISD- X SET STATUS SMAC (SCP). Transfer data to an application or the security domain (card manager) X processing the command. STORE DATA Optionally, updates OS-GLOBALPIN. Optionally uses ISD-SENC, ISD-SMAC (SCP). Monitor the memory space available on the card. Optionally uses ISD- X GET MEMORY SPACE SENC, ISD-SMAC (SCP). X SET ATR Change the card ATR. Optionally uses ISD-SENC, ISD-SMAC (SCP). Table 14 – Authenticated Card Manager Services and CSP Usage The card life cycle state determines which modes are available for the secure channel. In the SECURED card life cycle state, all command data must be secured by at least a MAC. As specified in the GP specification, there exist earlier states (before card issuance) in which a MAC might not be necessary to send Issuer Security Domain commands. Note that the LOAD service enforces MAC usage. Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 19/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy Service USR Description X Demonstrate RNG Generates a random value. Does not use CSPs. Hashes a provided value using SHA-1, SHA-224, SHA- X Demonstrate Hash 256, SHA-384, SHA-512. Does not use CSPs. Encrypts or decrypts a provided value using DSC-AES or X Demonstrate Symmetric Cipher DSC-TDEA provided in encrypted form with the service. Generates or verifies a TDEA MAC using DSS-TDEA Demonstrate Symmetric Signature X provided in encrypted form during service invocation. Generates or verifies a signature using DAS-RSA or DAS- Demonstrate Asymmetric Signature ECDSA provided to the module in encrypted form during X service invocation. Generates a shared secret value in accordance with SP Demonstrate EC DH 800-56A Section 5.7.1.2, and as well with non-SP 800-56A X EC DH, using ECDH-ECC. Demonstrates RSA, RSA CRT and ECC key generation, Demonstrate Asymmetric Key Generation X generating DKG-RSA and DKG-ECDSA. Table 15 – Demonstration Applet Services and CSP Usage Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 20/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy 4 Self-test 4.1 Power-on self-test Each time the Module is powered up it tests that the cryptographic algorithms still operate correctly and that sensitive data have not been damaged. Power-on self–tests are available on demand by power cycling the Module. On power on or reset, the Module performs the self-tests described in Table 14 below. All KATs must be completed successfully prior to any other use of cryptography by the Module. If one of the KATs fails, the Module enters the Card Is Mute error state. Test Target Description Firmware 16 bit CRC performed over all code located in EEPROM. This integrity test is not required or Integrity performed for code stored in masked ROM code memory. RNG Performs ANSI X9.31 KAT with fixed inputs TDEA Performs separate encrypt and decrypt KATs using 2-Key TDEA in ECB mode. AES Performs separate encrypt and decrypt KATs using an AES 128 key in ECB mode. RSA Performs separate RSA PKCS#1 signature and verification KATs using an RSA 1024 bit key. ECDSA Performs a pairwise consistency test using an ECC P-192 key pair. ECC CDH Performs an ECC CDH KAT using an ECC P-192 key pair. SHA-1 Performs a SHA-1 KAT. SHA-224 Performs a SHA-224 KAT. SHA-256 Performs a SHA-256 KAT. SHA-384 Performs a SHA-384 KAT. SHA-512 Performs a SHA-512 KAT. Table 16 – Power-On Self-Test 4.2 Conditional self-tests On every call to the [ANS X9.31] RNG, the Module performs the FIPS 140-2 Continuous RNG test as described in AS09.42 to assure that the output is different than the previous value. When any asymmetric key pair is generated (for RSA or ECC keys) the Module performs a pairwise consistency test. When new firmware is loaded into the Module using the LOAD command, the Module verifies the integrity and authenticity of the new firmware using a TDEA MAC process and the ISD-SMAC key. Optionally, the Module may also verify a signature of the new firmware using the DAP-SVK public key or the DAP-DES key; the signature block in this scenario is signed by an external entity using the private key corresponding to DAP-SVK or the symmetric DAP-DES key. Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 21/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision]. MultiApp ID V2.1 Platform FIPS 140-2 Cryptographic Module Security Policy 5 Physical security policy The Module is a single-chip implementation that meets commercial-grade specifications for power, temperature, reliability, and shock/vibrations. The Module uses standard passivation techniques and is protected by passive shielding (metal layer coverings opaque to the circuitry below) and active shielding (a grid of top metal layer wires with tamper response). A tamper event detected by the active shield places the Module permanently into the Card Is Killed error state. The Module is intended to be mounted in a plastic smartcard; physical inspection of the card boundaries is not practical after mounting. Physical inspection of modules for tamper evidence is performed using a lot sampling technique during the card assembly process. The Module also provides a key to protect the Module from tamper during transport and the additional physical protections listed in Section 7 below. 6 Electromagnetic interference and compatibility (EMI/EMC) The Module conforms to the EMI/EMC requirements specified by part 47 Code of Federal Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class B. 7 Mitigation of other attacks policy The Module implements defenses against:  Light attacks  Invasive fault attacks  Side-channel attacks (SPA/DPA/EMA) 8 Security Rules and Guidance The Module implementation also enforces the following security rules:  No additional interface or service is implemented by the Module which would provide access to CSPs.  Data output is inhibited during key generation, self-tests, zeroization, and error states.  There are no restrictions on which keys or CSPs are zeroized by the zeroization service.  The Module does not support manual key entry, output plaintext CSPs or output intermediate key values.  Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the Module. END OF DOCUMENT Ref: R0A21037_013_FIPS_SP Rev: 1.5 18/01/2013 Page 22/22 © Copyright Gemalto 2012. May be reproduced only in its entirety [without revision].