Security Policy for TECSEC ARMORED CARD – CONTACTLESS CRYPTOGRAPHIC MODULE July 30, 2013 See Section 1.4 Software Release: 2 Document Version: C Document Revision: DEV_32_089_ Document Number: © TecSec, Incorporated 2012. This document may be reproduced only in its original entirety [without revision]. TecSec, Constructive Key Management, CKM, CKM Enabled, the CKM Lock & Card Logo, and Secrypt are registered trademarks of TecSec, Incorporated. The TecSec logo and the CKM logo are trademarks of TecSec Incorporated. All other names are trademarks of their respective owners. This product is protected by one or more of the following U.S. patents, as well as pending U.S. patent applications and foreign patents: 5,369,702. 5,369,707. 5,375,169. 5,410,599. 5,432,851. 5,680,452. 5,717,755. 5,787,173. 5,898,781. 6,075,865. 6,266,417. 6,490,680. 6,542,608. 6,549,623. 6,606,386. 6,608,901. 6,684,330. 6,694,433. 6,754,820. 6,845,453. 7,016,495. 7,079,653. 7,089,417. 7,095,852. 7,111,173. 7,131,009. 7,178,030. 7,212,632. 7,490,240. 7,539,855. 7,738,660 7,817,800. 7,974,410. 8,077,870. DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 Approval Sheet Document Title: Security Policy for TecSec Armored Card - Original Date: March 11, 2009 Contactless Document Number: DEV_32_089 Revision Date: July 18, 2013 Author: Roger D. Butler Jr. Revision: 2.0B Approval Authority: Configuration Control Board Approval: Revision History VERSION AREA(S) DATE REVISION REVISION/CHANGE DESCRIPTION AFFECTED NO. Original Issue – Title: TecSec PIV Eagle Card – Contact [FIPS 140] Cryptographic Module Security Policy; $ > Documentation > Certifications > March 11, 2009 1.0 All EagleCard_Certification > OriginalPIVCard > TecSec PIV [FIPS 140] Documentation Set > Security Policy > Contact Version 2F of the Contact SP was modified to create November 29, 2012 2.0 All this SP for Contactless. Updated due to SP800-133 completion status December 14, 2012 A 3.9.4 affecting section references July 18, 2013 B Updated due to comments from CMVP All July 30, 2013 C Section 8 – remove extraneous verbiage 8 TecSec Incorporated Page ii Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 Table of Contents SECTION PAGE 1  Introduction .........................................................................................................................1  1.1  Scope .................................................................................................................................1  1.2  Hardware ..........................................................................................................................1  1.3  Firmware ...........................................................................................................................3  1.4  Versions and Mode of Operation .....................................................................................5  2  Ports and Interfaces .............................................................................................................5  3  Cryptographic Functionality.................................................................................................6  3.1  Critical Security Parameters..............................................................................................7  3.1.1  Operating System and Security Domain CSPs ..............................................................8  3.2  BOCC Applet CSPs .............................................................................................................8  3.3  PIV Applet CSPs .................................................................................................................9  3.4  CKM Attribute Container CSPs ..........................................................................................9  3.5  Platform Public Keys .......................................................................................................10  3.6  PIV Applet Public Keys ....................................................................................................10  3.7  BOCC Public Keys ............................................................................................................10  3.8  CKM Attribute Container Public Keys .............................................................................10  3.9  Key Generation and Key Establishment ..........................................................................11  3.9.1  Random Bit Generation ..............................................................................................11  3.9.2  Key Generation ...........................................................................................................11  3.9.3  ECC Key Agreement Primitives ...................................................................................11  3.9.4  CKM Key Construction ................................................................................................11  4  Roles, Authentication and Services ...................................................................................12  4.1  SCP03 Authentication .....................................................................................................12  4.2  Biometric On Card Comparison ......................................................................................13  4.3  CKM Authentication ........................................................................................................14  4.4  Services ...........................................................................................................................15  4.4.1  General Purpose and Unauthenticated Services .......................................................15  4.4.2  Security Domain Administrative Services ..................................................................16  4.4.3  PIV Applet Card Command Services ...........................................................................17  4.4.4  CKM Attribute Container Applet Services ..................................................................18  4.4.5  CKM Info Applet .........................................................................................................18  5  Self Test ..............................................................................................................................20  6  Operational Environment ..................................................................................................21  7  Electromagnetic Interference and Compatibility (EMI/EMC)............................................21  8  Physical Security and Mitigation of Other Attacks ............................................................21  9  Security Rules and Guidance..............................................................................................22  10  References .........................................................................................................................24  TecSec Incorporated Page iii Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 List of Figures FIGURE PAGE Figure 1.2‐1 TecSec Armored Card – Logical Block Diagram .....................................................2  Figure 1.3‐1 Crypto Module Block Diagram ...............................................................................4  List of Tables TABLE PAGE Table 1.0‐1 Security Level of Security Requirements ................................................................1  Table 2.0‐1 Ports and Interfaces ................................................................................................5  Table 3.0‐1 FIPS Approved Cryptographic Functions ................................................................6  Table 3.0‐2 Non‐FIPS Approved But Allowed Cryptographic Functions ....................................7  Table 3.1.1‐1 CM Operating System and Security Domain CSPs ...............................................8  Table 3.2‐1 BOCC Applet CSPs ...................................................................................................8  Table 3.3‐1 PIV Applet CSPs .......................................................................................................9  Table 3.4‐1 Critical Security Parameters....................................................................................9  Table 3.5‐1 Platform Public Keys .............................................................................................10  Table 3.6‐1 PIV Public Keys ......................................................................................................10  Table 3.7‐1 BOCC Public Keys ..................................................................................................10  Table 3.8‐1 CKM Public Keys ....................................................................................................10  Table 4.0‐1 Roles Description ..................................................................................................12  Table 4.3‐1 Supported Authentication Key File Types.............................................................15  Table 4.5.1‐1 General Purpose and Unauthenticated Services and CSPs ...............................15  Table 4.5.2‐1 Domain Administrative Services ........................................................................16  Table 4.5.3‐1 Services, Roles, and Associated CSP Usage .......................................................17  Table 4.5.4‐1 CKM Attribute Container Applet Services .........................................................18  Table 4.6‐1 CKM Info Applet Services ......................................................................................19  Table 5.0‐1 Power‐On Self‐Tests..............................................................................................20  Table 5.0‐2 Conditional Self‐Tests ...........................................................................................20  Table 10.0‐1 References ..........................................................................................................24  Table 10.0‐2 Abbreviations and Acronyms ..............................................................................25  TecSec Incorporated Page iv Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 1 Introduction The purpose of this document is to define the Security Policy for the TecSec Armored Card – Contactless Cryptographic Module (CM) as part of the [FIPS 140] certification process. The CM, validated to [FIPS 140] overall Level 2, is a single-chip embodiment with the GlobalPlatform Java Card operating system, the contactless interface subset of a dual-chip PIV [FIPS 201] solution, Biometric On Card Comparison (BOCC) and CKM® Data Attribute Container functionality. The [FIPS 140] security levels for the CM are as follows: Table 1.0-1 Security Level of Security Requirements SECURITY REQUIREMENT SECURITY LEVEL Cryptographic Module Specification 2 Cryptographic Module Ports and Interfaces 2 Roles, Services, and Authentication 3 Finite State Model 2 Physical Security 3 Operational Environment NA Cryptographic Key Management 2 EMI/EMC 3 Self-Tests 2 Design Assurance 3 Mitigation of Other Attacks 2 1.1 Scope The TecSec Armored Card – Contactless Cryptographic Module is the product defined. This document is part of a set of documents documenting the cryptographic module embedded in the card. There is also a set of documents for the Contact chip. 1.2 Hardware The CM is specifically designed for smart cards and targets ID applications. The physical form of the CM is depicted in figure 1.2-1 below. A block diagram of the CM is depicted in Figure 1.2-2 below. TecSec Incorporated Page 1 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 Figure 1.2-1 - CM Physical Image Figure 1.2-1 TecSec Armored Card – Logical Block Diagram TecSec Incorporated Page 2 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 The CM Processor is a low-power, high-performance, 8/16-bit microcontroller with ROM program memory, EEPROM memory, based on the RISC architecture. The CM Processor features the Ad-X cryptographic accelerator for fast computation and low-power operation, based on a 32-bit multiplier-accumulator architecture designed to accelerate encryption and authentication functions. Additional security features include power and frequency protection logic, logical scrambling on program data and addresses, and Power Analysis countermeasures and memory accesses controlled by a supervisor mode. The CM will typically be embedded into a plastic smart card body and connected to an ISO 14443 compliant antenna assembly. The CM boundary separates the chip from the card and antenna assembly. The cryptographic boundary is the surface of the chip and associated bond pads, and not the entire smart card. The contact interfaces of the module are not intended to be used in the final product and will not be connected in the smartcard form factor; however, these interfaces are not disabled and are available at the cryptographic boundary. Although only the contactless interfaces will be used in the end product, the contact interfaces are included in this Security Policy for completeness and accuracy. 1.3 Firmware CM firmware comprises five Java Card applets implementing PIV contactless features, the Biometric On Card Comparison (BOCC) applet and the CKM Attribute Container applet (one applet, potentially with multiple instances) and the CKM Info applet (for reporting on free resources) running on a GlobalPlatform Java Card operating system. Assembled onto a smart card with a companion module for Contact functionality, the CM has been validated for conformance to [SP 800-73] – see NPIVP PIV Card Application Cert. #35. TecSec Incorporated Page 3 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 ID SSD BOCC Java Java Card CKM Info Card applet applet ISD CKM Data CKM Data PIV AC Java AC Java Java Card ... Card applet Card applet applet instance instance Athena IDProtect GlobalPlatform Java Card operating system HARDWARE Inside Secure AT90SC28880RCFV Figure 1.3-1 Crypto Module Block Diagram The ISD applet is also known as the Global Platform Card Manager. ISD and SSD applets have identical functionality but distinct roles, differentiated by Security Domain keyset. The embedded operational environment implementation is compliant with: GlobalPlatform, Card Specification, Version 2.1.1, March 2003 • GlobalPlatform, Card Specification 2.1.1, Amendment A, March 2004 • GlobalPlatform, Card Specification 2.2, Amendment D Secure Channel Protocol 03, • Version 1.1, September 2009 Runtime Environment Specification, Java Card Platform, Version 2.2.2, March 2006 • Application Programming Interface, Java Card Platform, Version 2.2.2, March 2006 • Virtual Machine Specification, Java Card Platform, Version 2.2.2, March 2006 • The GlobalPlatform external interface and internal API allows for application load and deletion and for secure communication between applications. In particular, it allows for the loading of a special application called a Supplementary Security Domain (SDD) that allows an Application Provider to separate their key space from the Card Issuer. The Java Card API provides a large set of cryptographic services. Some of these services rely on hardware. All applets are written in Java (as limited by the Java Card standards). TecSec Incorporated Page 4 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 1.4 Versions and Mode of Operation Hardware: P/N Inside Secure AT90SC28880RCFV Revision G Firmware P/N Athena IDProtect Duo Version 010E.0264.0001 • P/N TecSec SSD Applet Version 1.001 • P/N TecSec PIV Applet Version 1.007 • P/N TecSec BOCC Applet Version 1.001 • P/N TecSec CKM Attribute Container Applet Version 1.002 • P/N TecSec CKM Info Applet Version 1.000 • The module is always in the Approved mode of operation. To verify that a module is in the Approved mode of operation, the Card Issuer must: 1. Send GET DATA to the ISD applet with the CPLC Data tag and verify that the OS version matches 010E.0264.0001. 2. Validate that the SSD and PIV applets are in the FIPS mode as per [PIVAPP]. The SSD shall be version 1.001 and the PIV shall be 1.007. 3. Select the BOCC applet and verify that the File Control Information (FCI) returned from the BOCC applet indicates version 1.001. (See [BOCCAPP] for more details.) 4. Use the Configuration service (Get TecSec Information command) on the CKM Attribute Container applet. The version shall be 1.002. See [CKMAPP] for details. 2 Ports and Interfaces The CM functions as a slave processor, accessed via a smart card reader over ISO/IEC 7816 and 14443 compliant interfaces. The CM supports the T=0, T=1 and T=CL transmission protocols. Table 2.0-1 Ports and Interfaces PIN DESCRIPTION LOGICAL INTERFACE TYPE CLK External Clock signal 1 – 10.1MHz Control in GND Ground Power VCC Supply Voltage Power 1.62 – 5V Power Data in, data out, control in, In/Out 0 Input/Output status out RST External Reset signal Control in Power, Data in, data out, RF1, RF2 RF Antenna connections control in, status out TecSec Incorporated Page 5 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 3 Cryptographic Functionality The CM operating system implements the FIPS Approved and Non-FIPS Approved cryptographic function listed in Table 3 and Table 3 below. Table 3.0-1 FIPS Approved Cryptographic Functions FUNCTION ALGORITHM DESCRIPTION CERT # Random Number [SP 800-90] [SP800-90] DRBG. The Module supports a SHA-256 98 Generation Hash_DRBG based Hash_DRBG. Message Digests SHA-11 [FIPS 180-2] Secure Hash Standard compliant hashing 1465 algorithms SHA-256 SHA-512 Message HMAC-SHA-512 [FIPS 198] Keyed Hash Message Authentication Code. 1354 Authentication Uses the Cert. #1465 SHA-512 primitive. (HMAC) Codes [SP 800-38B] AES CMAC. Uses the Cert. #1655 AES-256 2226 AES CMAC primitive. (AES) [FIPS186-2] RSA signature generation and verification. Digital Signature RSA PKCS#1.5 824 The Module supports [PKCS#1] RSASSA-PSS and RSASSA-PKCS1-v1_5 with 1024- and 2048-bit RSA keys. [FIPS186-3] Elliptic Curve Digital Signature Algorithm. The 214 ECDSA Module supports the NIST defined P-256, P-384 and P- 521 curves for signature generation and verification, and key pair generation. Encryption and [SP800-67] Triple Data Encryption Standard algorithm. Triple-DES 1088 The Module supports the 2-Key2 and 3-Key options; in decryption ECB and CBC modes. [FIPS197] Advanced Encryption Standard algorithm. The AES 1655 Module supports AES-128, AES-192 and AES-256; in ECB and CBC modes. [FIPS186-3] Elliptic Curve Digital Signature Algorithm. The 214 Key Generation ECDSA Module supports the NIST defined P-256, P-384 and P- 521 curves for key pair generation. [SP800-56A] The Section 5.7.1.2 ECC CDH Primitive 2 Key Agreement ECC CDH only. The module supports the NIST defined P-256, P-384 (CVL) and P-521 curves. [SP 800-108] KDF in Counter Mode, using the Cert. # 4 Key Derivation KDF CTR 1354 HMAC-SHA-512 and Cert. #2226 AES-CMAC (KDF) primitives and the Cert.#98 DRBG. 1 Per NIST SP 800-131A: Through December 31, 2013, the use of SHA-1 is deprecated for digital signature generation. SHA-1 shall not be used for digital signature generation after December 31, 2013. 2 Per NIST SP 800-131A: Through December 31, 2015, the use of 2-key Triple DES for encryption is restricted: the total number of blocks of data encrypted with the same cryptographic key shall not be greater than 220. After December 31, 2015, 2-key Triple DES shall not be used for encryption. Decryption using 2-key Triple DES is allowed for legacy-use. TecSec Incorporated Page 6 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 Table 3.0-2 Non-FIPS Approved But Allowed Cryptographic Functions CATEGORY ALGORITHM DESCRIPTION Random Number Hardware RNG; minimum of 64 bits per access. The HW RNG output is NDRNG Generation used to seed the FIPS approved DRBG. The module implements a non-SP 800-56B-compliant Key Transport Key Decapsulation RSA primitive (RSA key decapsulation). This operation follows the PIV specification [SP 800-73] mechanism and does not establish a key or CSP into the module. RSA Key ANSI X9.31 RSA key pair generation (untested, non-compliant). The RSA Generation Module supports 1024- and 2048-bit RSA key generation. Per IG 7.12, the non-Approved RSA key generation method is allowed for use in the Approved mode until the transition end date of 12/31/2013. [AESKeyWrap] AES Key Wrap. The Module supports AES key wrapping AES Key Wrap AES with AES-256. (Used for key output, not key establishment.) AES CMAC (untested, non-compliant). The Module supports AES MAC AES CMAC CMAC with AES-128, AES-192 and AES-256 for GlobalPlatform SCP03. The AES CMAC implementation is embedded within the SCP functionality and was not CAVP validated, but is not required for secure operation of the module or to meet FIPS requirements. ECC Key EC Diffie- Non-SP 800-56A compliant EC Diffie-Hellman. Uses the CAVP tested Agreement Hellman ECC CDH primitive.(Key establishment methodology provides between 128 and 256 bits of encryption strength.) The CM implements GlobalPlatform Secure Channel Protocol 03 (SCP03) for authentication and the establishment of session keys for use in secure channel data encryption and data integrity functions for the CI and IDI roles. The CM implements a Supplemental Security Domain to administer the PIV and BOCC applets, associated with the IDI role. The PIV applet provides the cryptographic end-point services specified in [SP 800-73] for the contactless interface. The CKM Attribute Container applet provides CKM® Combiner / Recombiner and CKM Data Attribute Container functionality, described further below. The BOCC applet provides cryptographic services to securely transport authentication data. 3.1 Critical Security Parameters All CSPs used by the CM are described in this section. All usage of these CSPs by the CM, including all CSP lifecycle states, is described in Section 0, cross referenced to roles and services. TecSec Incorporated Page 7 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 3.1.1 Operating System and Security Domain CSPs CSPs used by the CM’s operating system are prefixed with OS. Table 3.1.1-1 CM Operating System and Security Domain CSPs KEY DESCRIPTION / USAGE Operating System CSPs OS-DRBG- 384 bit random value from HW RNG used to seed the DRBG (entropy input) SEED OS-DRBG- 880 bit value of current DRBG state, inclusive of V and C STATE OS-MKEK AES-256 key used to encrypt all secret and private keys stored in the EEPROM Global Platform SCP03 – Security Domain Keyset SD-KENC AES-256 key used by the CI and IDI roles to establish SD-SENC. SD-KMAC AES-256 key used by the CI and IDI roles to establish SD-SMAC and SD-SRMAC. SD-KDEK AES-256 data decryption key used by the CI and IDI roles to decrypt CSPs AES-256 session encryption key used by the CI and IDI roles to encrypt/decrypt SD-SENC Secure Channel Session data AES-256 session MAC key used by the CI role to verify inbound Secure Channel SD-SMAC Session data integrity MAC AES-256 session MAC key used by the CI role to generate outbound Secure SD-SRMAC Channel Session data integrity MAC The CM supports two sets of security domain keys, ISD and SSD. 3.2 BOCC Applet CSPs BOCC applet CSP names are prefixed with “BOCC“. Some key identifiers permit different algorithms for a given key identifier; correspondingly, in the table below, BOCC-KEAK is shown with multiple key types. Table 3.2-1 BOCC Applet CSPs KEY DESCRIPTION / USAGE BOCC-BIO Private portion of biometric authentication data, 1-n instances RSA 1024, 2048 RSA key transport private key; an optional* key used to decapsulate BOCC- BOCC-SENC. This key may be used by the Sign Certificate Request until a valid KDK certificate is loaded into the module. ECDH P-256, P-384 key agreement key; an optional* ECC private key used for ECDH BOCC- establishment of BOCC-SENC. This key may be used by the Sign Certificate Request KAK until a valid certificate is loaded into the module. BOCC- AES-128/192/256 session data decryption key; established using ECDH or using RSA SENC key transport. TecSec Incorporated Page 8 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 3.3 PIV Applet CSPs PIV applet CSP names are prefixed with “PIV“. [SP 800-73] defines the operations performed by the PIV applet and [SP 800-78] defines the cryptographic requirements for the PIV applet. Some key identifiers described in these specifications permit different algorithms for a given key identifier; correspondingly, in the table below, PIV-CAK is shown with multiple key types. Table 3.3-1 PIV Applet CSPs KEY DESCRIPTION / USAGE [SP 800-78] 9E (FIPS 201-1 Card Authentication Key). The PIV specifications permit both symmetric and asymmetric algorithms to be used for card authentication. This PIV-CAK module supports all defined options: 3-key Triple-DES; AES-128, AES-192, AES-256; RSA 1024, RSA 2048; ECDSA P-256 and P-384 curves. 3.4 CKM Attribute Container CSPs Table 3.4-1 Critical Security Parameters KEY DESCRIPTION / USAGE CKM Credential Master Key n: 128 byte secret key material (0 to 10 instances). A CKM-CRD-MKn constituent of CKM Symmetric and Asymmetric Credentials. CKM Credential Private Authorization Key n: Private component of an ECC P-521 CKM-CRD-PAKn key pair (0 to 10 instances). A constituent of a CKM7 Asymmetric Credential. CKM Credential Private Signature Key n: Private component of an ECC P-521 key CKM-CRD-PSKn pair (0 to 10 instances). A constituent of a CKM7 Asymmetric Credential. CKM Ephemeral-Header-Signature Private Signature Key: Private component of an CKM-EHS-PSK ECC P-521 key pair. Optional key used to sign the CKM header. CKM symmetric authentication key: optional AES-128, AES-192 or AES-256 key CKM-AUTH-SYM used for authentication, 0-24 instances. CKM user signing key: optional RSA 2048, ECDSA P-256, P-384 or P-521 key CKM-USER-PSK used for digital signature, 0-n instances CKM user symmetric key: optional AES-128, AES-192 or AES-256 key used for key CKM-USER-SYM wrap, encryption and decryption, 0-n instances. CKM user Key Agreement key: optional EC-CDH P-256, EC-CDH P-384 or EC- CKM-USER-KAK CDH P-521 key used for Key Agreement, 0-n instances CKM-WK-DEK CKM Working Key: AES-256 data encryption key used to protect CKM data. CKM Working-Key Key Wrapping Key: AES-256 key used to wrap CKM-WK-DEK CKM-WK-KWK for protected storage in the CKM header. CKM Working-Key Static Master Key: 128 byte secret key material, used as input to CKM-WK-SMK SP 800-108 KDF for derivation of the working key. CKM Working-Key Ephemeral Key Generating Key: AES-256 key used as the key CKM-WK-EKGK to the SP 800-108 PRF function for derivation of the working key. TecSec Incorporated Page 9 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 3.5 Platform Public Keys Table 3.5-1 Platform Public Keys KEY DESCRIPTION / USAGE SD-DAP RSA 1024 new firmware signature verification key. 3.6 PIV Applet Public Keys The PIV Applet public keys are generated using the PIV Applet GENERATE ASYMMETRIC KEYPAIR service. An entity external to the CM packages these public keys in a certificate and is expected to store them back onto a card container using the PIV applet PUT DATA operation. The CM supports the PIV Applet GET DATA command to retrieve these certificates. Only the ID Issuer role can generate these keys. These public keys are: Returned by the card when the matching RSA Private Key is generated. • Not used for any other purpose or service on the CM • Table 3.6-1 PIV Public Keys KEY DESCRIPTION / USAGE PIV-CA- [SP 800-78] Card authentication key (9E), RSA or ECDSA variant. RSA 1024 and 2048, PUB ECDSA P-256, P-384. 3.7 BOCC Public Keys Table 3.7-1 BOCC Public Keys KEY DESCRIPTION / USAGE BOCC-KDK- RSA 1024, 2048 RSA key transport public key; an optional key provided to the PUB external host for it to use to encapsulate BOCC-SENC. BOCC-KAK- ECDH P-256, P-384 key agreement key; an optional ECC public key used for ECDH PUB establishment of BOCC-SENC. 3.8 CKM Attribute Container Public Keys Table 3.8-1 CKM Public Keys KEY DESCRIPTION / USAGE CKM CReDential PuBlic Authorization Key n: 0 to 10 instances of the public CKM_CRD_PBAKn component of an ECC P-521 key pair. A constituent of a CKM7 Asymmetric Credential. CKM CReDential public Signature Verification Key n: 0 to 10 instances of the CKM_CRD_SVKn public component of an ECC P-521 key pair. A constituent of a CKM7 Asymmetric Credential. CKM Ephemeral-Header-Signature Signature Verification Key: an optional ECC CKM-EHS-SVK P-521 key pair, used to generate or verify a signature header. TecSec Incorporated Page 10 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 KEY DESCRIPTION / USAGE User defined public signature verification keys for data attribute containers: RSA 1024, RSA 2048, ECDSA P-256, ECDSA-P-384, ECDSA P-521. The CM CKM-USER-SVK supports as many instances as will fit in the attribute container. User defined public key agreement keys for data attribute containers: EC-CDH CKM-USER-KAK- P-256, EC-CDH-P-384, EC-CDH P-521. The CM supports as many instances as PUB will fit in the attribute container. 3.9 Key Generation and Key Establishment 3.9.1 Random Bit Generation The DRBG is implemented in accordance with the Hash_DRBG method described in [SP 800- 90] Section 10.1. 1. All DRBG parameters are in accordance with Table 2 of [SP 800-90]. 3.9.2 Key Generation The CM uses the [SP 800-90] DRBG to generate keys in accordance with applicable standards. 3.9.3 ECC Key Agreement Primitives The CM implements a non-SP 800-56A compliant (untested) ECC Key Agreement scheme C (1,1, ECC-CDH). The ECC-CDH primitive is implemented in accordance with [SP 800-56A] Section 5.7.1.2 (ECC-CDH primitive – CAVP tested, CVL Cert. #2) and the Section 5.8.1 concatenated Key Derivative Function (KDF). 3.9.4 CKM Key Construction The CM implements CKM Key Construction in accordance with [ANSI X9.73] Annex D and [ANSI X9.69]. CKM is a method of key establishment using the methods described in [SP 800- 133] Section 7.4 and Section 7.6, with the exception that in CKM the key agreement primitives are used to protect data at rest rather than data in motion. That is, the primitives are used to derive a key value at different times: when the key is needed for storage and when the key is needed for retrieval. A given data protection scenario uses a configurable set of pre-shared keys, comprised of symmetric, asymmetric and shared secret (ECC CDH) key constituents. These keys are concatenated and digested by a SHA-512 in a configurable sequence to form a CKM Working-Key Key Wrapping Key (CKM-WK-KWK). The CKM Working Key (CKM-WK-DEK) is derived from the CKM Working-Key Static Master Key (CKM-WK-SMK) and the CKM Working-Key Ephemeral Key Generating Key (CKM-WK-EKGK) using [SP 800-108]. The [SP 800-90] DRBG is used to derive or generate any key or random value required for this process. All primitives used in this process are Approved and CAVP validated, with the requisite self-tests. All elements of the process employ TecSec Incorporated Page 11 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 256-bit security strength functions and key lengths: AES-256 symmetric keys, p521 ECC CDH and SHA-512. 4 Roles, Authentication and Services Table 4.0-1 lists all operator roles supported by the module. This CM does not support a maintenance role. The CM does not support concurrent operators and clears previous authentications on power cycle. Table 4.0-1 Roles Description ROLE DESCRIPTION ID Card Issuer (the Cryptographic Officer role for [FIPS 140] purposes). This role is responsible for CI managing the security configuration of the module. The Card Issuer authenticates to the module through the GlobalPlatform (GP) mutual authentication protocol. This protocol is based on the sharing of an AES key set between the Card Issuer operator and the CM ISD. Once authenticated, the Card Issuer is able to execute the services provided by the ISD in a Secure Channel Session (see [GP] for more details). ID Issuer. This role is responsible for managing the security configuration of a loaded IDI application. The ID Issuer authenticates to the module through the GlobalPlatform mutual authentication protocol. This protocol is based on the sharing of AES key sets between the ID Issuer operator and the CM embedded SSD. Once authenticated, the ID Issuer is able to execute the services provided by the application over an SCP03 secure channel session. This includes putting PIV objects into the PIV applet, putting PIV RSA and EC Private keys into the PIV applet, putting BOCC data into the BOCC applet and managing putting BOCC RSA and EC Private keys into the BOCC applet via the CS SSD. CKM User (the User role for [FIPS 140] purposes): CKM Attribute Container role used to grant CU or deny access to objects or CSPs. This role can be authenticated with multiple combinations of authentication data in accordance with the CKM access control scheme. CKM Attribute Container Owner: CKM Attribute Container role used to grant or deny access to ACO objects or CSP’s. This role can be authenticated with multiple combinations of authentication data in accordance with the CKM access control scheme. This role is used to maintain the CSPs (loading/generating, …) and to create/destroy data objects in the attribute container. Public Operator. A non-authenticated operator can only access non-security relevant services PO provided by the ISD that do not require any prior authentication. In addition the Public Operator can use the PIV Card Authentication service, which in accordance [SP 800-73] does not require authentication. The Public Operator does not have the ability to create, modify, substitute, or disclose any CSP. 4.1 SCP03 Authentication The CM supports the [SCP03] mutual authentication handshake, providing identity based authentication of the Card Issuer (CI) and ID Issuer (IDI) roles. Authentication is associated to a security domain, which is in turn implicitly associated with a role as described above: the CM TecSec Incorporated Page 12 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 ISD Key Set corresponds to the CI role; the PIV SSD, BOCC SSD and CKM SSD key sets correspond to the ID Issuer role. The [SCP03] mutual authentication verifies possession of a secret shared between the CM and the external operator. Access control restrictions are listed by service in the tables in Section 4.5. Each service available to the CI or IDI roles requires successful [SCP03] mutual authentication as described in this section. This authentication mechanism includes a counter of failed authentication and a blocking mechanism. The counter is decremented prior to any attempt to authenticate and is only reset to its threshold (maximum value) upon successful authentication. The authentication mechanism is blocked when the associated counter reaches zero. The counter threshold is in the range one to 255 with default value 80. This mechanism is called velocity checking (see [GP]). If the authentication mechanism of the ISD is blocked the CM is irreversibly terminated (the OS- MKEK and OS-MPEK are zeroized and the CM enters the GlobalPlatform TERMINATED state in which only the ISD may be selected with the SELECT APDU command and only the GET DATA (ISD) APDU command is available). The [SCP03] interaction utilizes the 256 AES session key associated with the domain to authenticate to the associated role. The authentication strength for this method is as follows: The probability that a random attempt at authentication will succeed is 1/2^128 (2.94E- • 39). 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^128 (7.49E-37). The ISD and SSD cryptographic keys are associated with their respective identity by a unique two-byte value, Key Version Number (KVN) and Key ID (KID), as defined in the GlobalPlatform standard (see [GP]). 4.2 Biometric On Card Comparison Biometric authentication strength is set by a biometric threshold parameter when the fingerprint is enrolled. The biometric algorithm provider has provided a Receiver Operating Curve (ROC) characteristic curve, achieved through a large statistical sampling process, to be used by the algorithm within the CM and by the corresponding enrollment software. To comply with [FIPS 140] authentication strength, the operator must select the 1/1,000,000 FAR setting when validating fingerprint minutiae. TecSec Incorporated Page 13 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 4.3 CKM Authentication The CKM Authentication can be configured to use basic authentication mechanisms in an And/Or combination. For instance one CU role can be configured to be “(Pin and Bio) or SecureChannel.” The valid authentication mechanisms are: Secure Channel • External Authentication (Challenge Response) • Biometric Match using the BOCC applet • NOTE: If the BOCC mechanism is used alone then it must be configured for the 1:1,000,000 FAR by the Identity Issuer (IDI role). Both the Secure Channel and External Authentication use keys stored in the CM for the validation. The CKM Attribute Container applet uses the proprietary file system described in detail in [CKMAPP] to securely store key information. The applet file system enhances the Global Platform file system. Every file (MF, DF, EF, Object) has 5 security indicators that describe who can perform 5 types of actions on the files. The actions are Read, Write, Delete, Crypto, and Life Cycle State Identifier (LCSI). Read controls the reading of non-internal file types. Internal file types cannot be returned to the card edge. Write controls the writing/updating/PutKey/GenerateKey operations. Delete specifies who can delete the file. Crypto specifies that the card may perform cryptographic operations with this file assuming that the command and file type match. The LCSI security setting controls who can perform the ActivateEF, DeactivateEF and TerminateEF commands on that file. It is also used in some special cases like the resetRetryCounter to specify which authentications are required in order to perform that command. Each security setting indicates which of the 6 CU roles, the Attribute Container Owner (ACO) role or Public role that are needed to perform the specified services. If the CKM Attribute Container Applet is configured to support the PKCS #11 standard then 2 of the CU roles are predefined for the PKCS #11 User and PKCS #11 Security Officer (SO). For the Secure Channel and External Authentication mechanisms the associated key files should be created as internal keys which prevent all access to the keys by the card edge (the keys cannot be read). The type of the key file determines the type of authentication mechanism that is to be used and how many support files will also be needed. Here is a table of the supported authentication key file types and the mechanism used to authenticate the file. TecSec Incorporated Page 14 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 Table 4.3-1 Supported Authentication Key File Types FILE TYPE AUTHENTICATION MECHANISM DESCRIPTION AES Keyset Secure Channel type 03 or Verify command using the first key CKM Credential Secure Channel type F2 AES key Verify command (performs External Authentication mechanism) Biometric Template Global Biometric applet is authenticated Note: The file types in the above table also include the internal file types. Therefore AES Keyset also matches Internal AES Keyset. 4.4 Services All services implemented by the CM are listed in the tables below. Each service description also describes all usage of CSPs by the service. The following security rules also apply to the CM: No additional interface or service is implemented by the CM 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 SET STATUS • (TERMINATED) zeroization service in the CI role. 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. 4.4.1 General Purpose and Unauthenticated Services The services listed next do not require authentication, and may be performed by any role, including the unauthenticated PO role. Table 4.5.1-1 General Purpose and Unauthenticated Services and CSPs SERVICE DESCRIPTION Card reset Power cycle the CM by removing and reinserting it into the RF field.. On the first instance of card reset, the CM generates OS-MKEK (global component) and OS- MPEK. On any card reset, the CM overwrites OS-DRBG-STATE On any card reset, the card zeroizes SD-S-ENC, SD-S-MAC, SD-S-RMAC. Operator can select an Application to which subsequent commands are routed. The SELECT response contains various data depending on the application that is selected. When used by unauthenticated PO or by the authenticated PA or PC, to retrieve public data. GET DATA No CSPs are accessed this service in this context. GET Retrieves additional bytes buffered by the CM from the previous command. RESPONSE As a low level transport protocol, does not access any CSPs. TecSec Incorporated Page 15 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 SERVICE DESCRIPTION Initiate a GlobalPlatform Secure Channel Session, setting key set version and index. When used in the ISD, executes using OS-MKEK, ISD-KENC, ISD-KMAC and generates INITIALIZE ISD-SENC; ISD-SMAC. UPDATE When used in the SSD, executes using SSD-KENC, SSD-KMAC and generates SSD-SENC and SSD-SMAC. 4.4.2 Security Domain Administrative Services The CI and IDI roles are active only when the applicable domain is currently selected following successful authentication. The ISD, ID SSD and BOCC SSD key sets and the PIV-CAK key are loaded within a GlobalPlatform Secure Channel Session to ensure confidentiality (256-bit AES encryption) and integrity (AES CMAC). Application loading (utilizing several of the above services) is an operating system function available before and after card issuance, but restricted to the Card Issuer or ID Issuer: an SCP03 Secure Channel Session must be open between the external operator (more precisely the middleware the CI or IDI is using to manage card content) and the ISD. Application loading is protected by an AES CMAC on every block of data. The IDI is responsible for application personalization and lifecycle management in accordance with [GP]. Table 4.5.2-1 Domain Administrative Services SERVICE DESCRIPTION CI IDI Delete a uniquely identifiable object such as an Executable Load File DELETE X X (package), an Application (applet) or an Executable Load File and its related (card content or Applications. key) The DELETE (key) service deletes a key uniquely identified by the KID and KVN within the applicable domain: SD-Key-ENC, SD-Key-MAC, SD-Key- DEK. The IDI role is permitted to execute the DELETE service only if the APDU commands are previously signed by the Card Issuer (GlobalPlatform Delegated Management). When invoked within an [SCP03] secure channel session executes using SD-S-MAC, SD-S-ENC SD-S-RMAC, determined by security level. EXTERNAL Open a GlobalPlatform Secure Channel Session with the ISD to X X AUTHENTICATE communicate with confidentiality and integrity, inclusive of operator authentication. Executes using OS-MKEK. When invoked within an [SCP03] secure channel session executes using SD-S-MAC, SD-S-ENC, SD-S-RMAC, SD-Key-ENC, SD-Key-MAC, SD-Key- DEK. Personalize the PIV applet or BOCC applet. X Personalize TecSec Incorporated Page 16 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 SERVICE DESCRIPTION CI IDI Applet Executes using OS-DRBG-STATE. Writes BOCC-KEAK. BOCC-BIO Generates BOCC-KEAK. PIV-CAK Outputs public key for BOCC-KEAK, PIV-CAK Retrieve Life Cycle status information of the ID SSD, and Executable Load X X File, Executable Module, Application or associated Security Domain. GET STATUS When invoked within an [SCP03] secure channel session executes using SD-S-MAC, SD-S-ENC SD-S-RMAC, determined by security level. Initiate or perform the various steps required for CM applet management. X X The IDI role is permitted to execute this service only if the APDU commands Install and Load are previously signed by the Card Issuer (GlobalPlatform Delegated Applet Management). Executes using OS-DRBG-STATE, SD-S-MAC, SD-S-ENC, SD-S-RMAC, SD-Key-ENC, SD-Key-MAC, SD-Key-DEK. PUT KEY The service can: X X Replace an existing key with a new key Replace multiple existing keys with new keys Add a single new key Add multiple new keys Writes SD-Key-ENC, SD-Key-MAC, SD-Key-DEK. Executes using OS-DRBG-STATE, OS-KSSK, SD-S-MAC, SD-S-ENC, SD- S-RMAC, SD-Key-ENC, SD-Key-MAC, SD-Key-DEK. Modify the Card Life Cycle State or an associated Application Life Cycle SET STATUS X X State. The IDI role can modify the ID SSD Life Cycle State or an associated Application Life Cycle State. When invoked with the TERMINATED status in the CI role, zeroizes OS- KSSK and OS-PSSK, effectively destroying all other CSPs. Executes using SD-S-MAC, SD-S-ENC, SD-S-RMAC, SD-Key-ENC, SD- Key-MAC, SD-Key-DEK. STORE DATA Transfer data to the SD. X X Executes using SD-S-MAC, SD-S-ENC, SD-S-RMAC, SD-Key-ENC, SD- Key-MAC, SD-Key-DEK. 4.4.3 PIV Applet Card Command Services Table 4.5.3-1 Services, Roles, and Associated CSP Usage SERVICE DESCRIPTION PUBLIC GENERAL As defined in [SP 800-73] for the Contactless function, GENERAL X AUTHENTICATE AUTHENTICATE is permitted only for use with the PIV Card Authentication Key (PIV-CAK). When invoked with a challenge or witness tag by a public operator, executes the specified algorithm using PIV-CAK. The GET DATA card command retrieves the data content of the single data GET DATA X object whose tag is given in the data field. TecSec Incorporated Page 17 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 4.4.4 CKM Attribute Container Applet Services CKM Attribute Containers are a 7816 File/Data Object system with PKCS 11 extensions. Each Attribute Container has an MF with at least some EFs; and may have a credential set. Commands are permitted to an authorized operator; command access control is based on both file/data object type and file / data object permissions. CKM Attribute Containers offer Cryptographic Services and Authentication Services as shown in the tables in this section. Authentication for file / data object is any and/or combination of External / Mutual authentication • SCP03 • Biometric • 5 8-bit words per file/object: Read Write Delete Crypto LCSI 8 bits represent public + 6 general operator roles (CU) and the ACO role One specialized operator type is Attribute Container owner. Attribute Container Owner has additional capability on some commands: e.g. retrieve a file map for all files, delete any file. Table 4.5.4-1 CKM Attribute Container Applet Services SERVICE DESCRIPTION CU ACO This service is the general purpose file and object read/write File / data object X X functionality that is derived from ISO/IEC 7816-4 and ISO/IEC 7816-9 This service contains commands that are used to authenticate a role or Authentication X X validate that a role is authenticated These commands are used to encrypt or decrypt user provided data Encrypt / decrypt X X using an on-card CSP These commands are used to wrap or unwrap caller specified data RSA Wrap/Unwrap X X using on card RSA CSPs These commands are used to create or validate a signature using a user Sign / verify X X provided hash value and an on-card CSP Key management These commands are used to establish keys (CSPs) on card X X These commands are used to configure the attribute container or to Configuration X retrieve configuration information about the attribute container 4.4.5 CKM Info Applet The CKM Info applet has no CSPs and no defined roles. All services are available to the unauthenticated role. TecSec Incorporated Page 18 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 Table 4.6-1 CKM Info Applet Services SERVICE DESCRIPTION PUBLIC Returns the free card resources, specifically available EEPROM, Query X and RAM in bytes. TecSec Incorporated Page 19 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 5 Self Test Table 5.0-1 Power-On Self-Tests TEST TARGET DESCRIPTION A CRC 16 EDC is used to test firmware integrity. Firmware integrity SHS Performs separate SHA-1, SHA-256 and SHA-512 KATs. Triple-DES Performs separate encrypt and decrypt KATs using 3-Key Triple-DES in CBC mode. AES Performs separate encrypt and decrypt KATs using an AES-128 in CBC mode. RSA Performs a KAT (RSA PKCS#1 sign and verify) using an RSA 2048 bit key pair. ECDSA Performs a KAT (ECDSA sign and verify) using an ECC P-256 key pair. ECC-CDH Performs an ECC-CDH KAT using an ECC P-256 key pair. Performs HMAC SP 800-108 KDF in Counter mode; incorporates self-test of the Ctr KDF HMAC embedded HMAC-SHA-512 algorithm. Ctr KDF AES- Performs AES-CMAC SP 800-108 KDF in Counter mode; incorporates self-test of the CMAC embedded AES-CMAC algorithm. DRBG Performs a KAT of the DRBG functions. Table 5.0-2 Conditional Self-Tests TEST TARGET DESCRIPTION On every generation of 64 bits of random data by the HW RNG the Module performs HW RNG a stuck fault test to assure that the output is different from the previous value. In case of failure the Module enters the “CM is mute” error state. Each time the Module is powered on it performs the DRBG health test monitoring DRBG functions. On every generation of 256 bits of random data by the DRBG, the Module performs a stuck fault test to assure that the output is different from the previous value. In case of failure the Module enters the “CM is mute” error state. When an asymmetric key pair is generated (for RSA or ECC) the Module performs a Key Gen PCT Pairwise Consistency Test (PCT). In case of failure the invalid key pair is zeroized and the Module enters the “CM is mute” error state. When a signature is generated (for RSA or ECDSA) the Module performs a PCT Key pair integrity using the associated public key. This PCT is also performed during the RSA and ECDSA KAT. When new firmware is loaded into the Module using the LOAD command, the Module Firmware Load verifies the integrity of the new firmware by verifying a signature of the new firmware using the ISD-DAP public key; the new firmware in this scenario is signed by an external entity using the private key corresponding to ISD-DAP. If the signature verification fails the Module returns an error and does not load the firmware. Every CSP is protected with a 16 bit CRC. The integrity is checked when a CSP is CSP Usage used. In case of failure the Module enters the “ISD is terminated” error state. TecSec Incorporated Page 20 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 6 Operational Environment 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. 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. 7 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. 8 Physical Security and Mitigation of Other Attacks The CM is a single-chip implementation that meets commercial-grade specifications for power, temperature, reliability, and shock/vibrations. The CM uses standard passivation techniques and is protected by a hard opaque tamper-evident metal active shield. The CM hardware is designed to meet Common Criteria EAL5+. The CM employs physical security mechanisms in order to restrict unauthorized physical access to the contents of the module and to deter unauthorized use or modification of the module (including substitution of the entire module) when installed. All hardware and firmware within the cryptographic boundary are protected. The CM chip is coated with opaque, hard tamper-evident materials to deter direct observation within the visible spectrum and to provide evidence of tampering (visible signs on the metal layer), with high probability of causing serious damage to the chip while attempting to probe it or remove it from the module. The CM has passed Level 3 physical security testing for hardness, opacity and tamper evidence. Typical smart card attacks are Simple Power Analysis, Differential Power Analysis, Timing Analysis and Fault Induction that may lead to revealing sensitive information such as Keys by monitoring the module power consumption and timing of operations or bypass sensitive operations. This Cryptographic Module is protected against SPA, DPA, Timing Analysis and Fault Induction by combining State of the Art firmware and hardware counter-measures. The Cryptographic Module is protected from attacks on the operation of the IC hardware. The protection features include detection of out-of-range supply voltages, frequencies or temperatures, detection of illegal address or instruction, and physical security. This chip is TecSec Incorporated Page 21 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 Common Criteria certified; more information is available here http://www.commoncriteriaportal.org/products/. All cryptographic computations and sensitive operations provided by the Cryptographic Module are designed to be resistant to timing and power analysis. Sensitive operations are performed in constant time, regardless of the execution context (parameters, keys, etc.), owing to a combination of hardware and firmware features. 9 Security Rules and Guidance The Module implementation enforces the following security rules: The Module does not output plaintext CSPs. The Module does not support manual key • entry. The Module does not output intermediate key values. • 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 CSPs are zeroized by the zeroization service. • Status information does not contain CSPs or sensitive data that if misused could lead to a • compromise of the Module. Additional applications can be loaded in the Module after issuance as specified in GlobalPlatform. However, any other firmware loaded into this Module is out of the scope of this validation and requires a separate FIPS 140-2 validation. Application loading is one of the services provided by the operating system that is restricted to the Card Manager: a Secure Channel Session must be open between the external operator (more precisely the middleware the CM is using to manage content) and the ISD. Application loading is protected by ISD-DAP. The application loading service is available before and after Module issuance. The CM is responsible for application personalization and lifecycle management following GlobalPlatform. The application loading service uses RSA 1024 for Data Authentication Pattern (DAP) operations. DAP is used for firmware load integrity and is deprecated per SP800-131A but may be used through 12/31/2013 for digital signature verification. All other uses of RSA 1024 are there for legacy operations and should not be used for new signatures. The user of the CM shall not use RSA 1024 for any other purpose as all other uses are disallowed per SP800- 131A. Since the BOCC can be used as a form of authentication in the CKM Attribute Container applet, it shall be configured by the Identity Issuer (IDI Role) for 1:1,000,000 FAR when the TecSec Incorporated Page 22 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 fingerprints are enrolled. If a lesser FAR is used the BOCC either cannot be used or must be used in an AND condition with either the external authentication (Verify command) or a secure channel. The process to set the FAR is described in [PIVAPP]. TecSec Incorporated Page 23 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 10 References The documents listed in this section form a part of this document to the extent specified herein. In the event of conflict between the documents referenced herein and the contents of this document, the contents of this document, upon final approval, are considered the superseding authority. The latest versions of these documents are assumed to be applicable unless otherwise specified by including the specific version. Refer to the master list of documents, or equivalent, for the latest revision and date. The following standards are referred to in this Security Policy. Table 10.0-1 References ACRONYM FULL SPECIFICATION NAME [FIPS140-2] Security Requirements for Cryptographic modules, May 25, 2001 [FIPS 180-2] SECURE HASH STANDARD [FIPS 198] The Keyed-Hash Message Authentication Code (HMAC), March 6, 2002 Personal Identity Verification (PIV) of Federal Employees and Contractors, [FIPS201] March 2006 (Change Notice 1, June 23, 2006) Java CardTM 2.2.1 Runtime Environment Revision 1.0, 18 May 2000 [JCRE] Java CardTM 2.2.1 Application Programming Interface Revision 1.0, 18 May [JCAPI] 2000 Java CardTM 2.2.1 Virtual Machine Revision 1.0, 18 May 2000 [JCVM] [GP] GlobalPlatform Card Specification, Version 2.1.1, March 2003 [ANSI X9.69] ANSI X9.69-2006 Framework for Key Management Extensions. [ANSI X9.73] ANSI X9.73-2010 Cryptographic Message Syntax ASN.1 and XML [ANSI X9.96] ANSI X9.64-2004 XML Cryptographic Message Syntax (XCMS) GlobalPlatform Card Technology Secure Channel Protocol 03 Card [SCP03] Specification v 2.2 – Amendment D Version 1.1 September, 2009 ISO/IEC 14443-1, First edition 2000-04-15, Identification cards — Contactless [14443-1] integrated circuit(s) cards — Proximity cards — Part 1: Physical characteristics ISO/IEC 14443-2, First edition 2001-07-01, Identification cards — Contactless [14443-2] integrated circuit(s) cards — Proximity cards — Part 2: Radio frequency power and signal interface ISO/IEC 14443-3, First edition 2001-02-01, Identification cards — Contactless [14443-3] integrated circuit(s) cards — Proximity cards — Part 3: Initialization and anticollision ISO/IEC 14443-4, First edition 2001-02-01, Identification cards — Contactless [14443-4] integrated circuit(s) cards — Proximity cards — Part 4: Transmission protocol [GP] GlobalPlatform Card Specification v2.1.1 Recommendation for Block Cipher Modes of Operation: The CMAC Mode for [SP 800-38B] Authentication Recommendation for Pair-Wise Key Establishment Schemes Using Discrete [SP 800-56A] Logarithm Cryptography TecSec Incorporated Page 24 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 ACRONYM FULL SPECIFICATION NAME Interfaces for Personal Identity Verification –Part 1: End-Point PIV Card [SP 800-73] Application, Namespace, Data Model and Representation, September 2008 Interfaces for Personal Identity Verification –Part 2: End-Point PIV Card Application Card Command Interface, September 2008 [SP 800-78] 9A (FIPS 201-1 PIV Authentication Key) Private signature key [SP 800-78] 9B (FIPS 201-1 Card Management Key) Secret key [SP 800-78] 9C (FIPS 201-1 Digital Signature Key) Private signature key (FIPS 201-1 Key Management Key) Private key when used for RSA key [SP 800-78] 9D decryption (FIPS 201-1 Key Management Key) Private key when used for the EC DH [SP 800-78] 9D shared secret (Z value) generation function (Card Authentication) key. The PIV specifications permit both symmetric and [SP 800-78] 9E asymmetric algorithms to be used for this purpose Recommendation for Random Number Generation Using Deterministic Random [SP 800-90] Bit Generators [SP 800-108 Recommendation for Key Derivation Using Pseudorandom Functions Transitions: Recommendation for Transitioning the Use of Cryptographic [SP 800-131A] Algorithms and Key Lengths [PIVAPP] TecSec PIV Application Provider Manual [BOCCAPP] Bio Cardholder Verification Module (CVM) APDU List [CKMAPP] CKM® Attribute Container Applet Manual Table 10.0-2 Abbreviations and Acronyms ACRONYM DEFINITION AC Attribute Container AdvX Advance Crypto AES Advanced Encryption Standard AID Application Identifier AP ID Issuer APDU Application Protocol Data Unit (IS0 7816/14443 data packet) API Application Programming Interface AVR Automatic Voltage Regulation BOCC Biometric On Card Comparison CA Certificate Authority CI Card Issuer CM Cryptographic Module CSP Critical Security Parameter DAP Data Authentication Pattern DES Data Encryption Standard TecSec Incorporated Page 25 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_089_Security Policy for TecSec Armored Card - Contactless Cryptographic Module July 30, 2013 ACRONYM DEFINITION DF Directory File (per 7816-4) DRBG Deterministic Random Bit Generator ECC Elliptic Curve Cryptography ECC-CDH Elliptic Curve Cryptography - Cofactor Diffie-Hellman ECDSA Elliptic Curve Digital Signing Algorithm EEPROM Electronically Erasable Programmable Read Only Memory EF Element File (per 7816 -4) EMI/EMC ElectroMagnetic Interference, ElectroMagnetic Compatibility GP GlobalPlatform HRNG Hardware Random Number Generator ID Identity IDI Identity Issuer ISD Issuer Security Domain KSSK Key Secure Storage Key KID Key Identifier, see [GP] KVN Key Version Number, see [GP] LCSI Life Cycle State Identifier MF Master File (per 7816-4) PIV Personal Identity Verification PKCS Public Key Cryptography Standard RNG Random Number Generator ROM Read Only Memory RSA Rivest, Shamir, Adleman SO Security Officer SSD Supplementary Security Domain TecSec Incorporated Page 26 Copyright 2012-2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision]