Security Policy for TECSEC ARMORED CARD – CONTACT CRYPTOGRAPHIC MODULE August 7, 2013 See Section 1.4 Software Release: 2 Document Version: H Document Revision: DEV_32_082_ 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_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 Approval Sheet Document Title: Security Policy for TecSec Armored Card - Original Date: August 7, 2013 Contact Document Number: DEV_32_082 Revision Date: August 7, 2013 Author: Roger D. Butler Jr. Revision: 2H 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 Title: TecSec PIV Eagle Card – Contact [FIPS 140] Cryptographic Module Security Policy; $ > February 16, 2010 1.1 Documentation > EagleCard > FIPS > Eagle card 2 Title: TecSec PIV Eagle Card – Contact [FIPS 140] Cryptographic Module Security Policy; Based December 3, 2010 1.2 All version of document rolled into new template. Document reformatted in preparation for the February 2, 2011 A All developer updating the information Headers and Footers put into place, format checked. None of the comments or track changes that are related to content were addressed. May 12, 2011 B All Electronic title updated after putting back onto Visual Studios to correspond to the new document title. TecSec Incorporated Page ii Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 Research and added version history of document Revision October 31, 2011 only. History Only August 6, 2012 2 InfoGard team update in preparation for certification All SILO changed to Attribute Container; Figure 1.2-.1 Updated with text box for No Connect items; Figure 1.3-1 Updated changing Silo to All August 7, 2012 A Attribute Container and BMOC to BOCC; Formatting of key numbers; searched for all document references and added them to the Reference Table 11.1-1 Brought into this document the specific segments of Specific noted an Athena SP (provided by Infogard) where our August 7, 2012 B areas documents could benefit from their language. This version was written onto the primary document in TFS as a new version. Rogers’s latest changes August 21, 2012 B are included in this version. No changes made to the document, only this note added for clarity. By direction of Dean B I have accepted the track changes only. All comments have been left active, no wording changes or content changes made. Issues with document number resolved, this is August 21, 2012 C All Dev_32_082. Cryptographic Module words were taken out of the title as instructed by Roger B. The format was checked for consistency only. Validated that the CKM Attribute Container Applet August 22, 2012 C Version was 1.2 Patent list updated. Changes to the document August 28, 2012 D All made by Wai have been incorporated Updated PIV Applet version number to match the August 30,2012 D Page 4 PIV Applet Man Compared the most recent version of SP with the changes received from Steve Weymann and updated our most recent version to reflect those changes. Where his changes did not comply with September 9, 2012 E All our document template and CM policy (first use acronym and labeling tables) the changes were not implemented. October 2, 2012 F Updated with missing information All Updated due to SP800-133 completion status affecting section references. Also updated the CSP December 14, 2012 G 3.4, 3.8, 3.9.4 list due to missing items found in the contactless review August 7, 2013 H Updated with comments from CMVP All TecSec Incorporated Page iii Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 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 .....................................................................................4 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 ........................................................................................10 3.5 Platform Public Keys .......................................................................................................10 3.6 PIV Applet Public Keys ....................................................................................................10 3.7 BOCC Public Keys ............................................................................................................11 3.8 CKM Attribute Container Public Keys .............................................................................11 3.9 Key Generation and Key Establishment ..........................................................................12 3.9.1 Random Bit Generation ..............................................................................................12 3.9.2 Key Generation ...........................................................................................................12 3.9.3 ECC Key Agreement Primitives ...................................................................................12 3.9.4 CKM Key Construction ................................................................................................12 4 Roles, Authentication and Services ...................................................................................13 4.1 SCP03 Authentication .....................................................................................................14 4.2 PIV Authentication Methods ..........................................................................................15 4.3 Biometric On Card Comparison ......................................................................................16 4.4 CKM Authentication ........................................................................................................16 4.5 Services ...........................................................................................................................17 4.5.1 General Purpose and Unauthenticated Services .......................................................17 4.5.2 Security Domain Administrative Services ..................................................................18 4.5.3 PIV Applet Card Command Services ...........................................................................20 4.5.4 CKM Attribute Container Applet Services ..................................................................20 4.5.5 CKM Info Applet .........................................................................................................21 5 Self Test ..............................................................................................................................22 6 Operational Environment ..................................................................................................23 7 Electromagnetic Interference and Compatibility (EMI/EMC)............................................23 8 Physical Security and Mitigation of Other Attacks ............................................................23 9 Security Rules and Guidance..............................................................................................24 TecSec Incorporated Page iv Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 10 References .........................................................................................................................26 List of Figures FIGURE PAGE Figure 1.2‐1 ‐ CM Physical Image ...............................................................................................2 Figure 1.2‐2 TecSec Armored Card – Logical Block Diagram .....................................................2 Figure 1.3‐1 Crypto Module Block Diagram ...............................................................................3 Table 3.0‐2 Non‐FIPS Approved But Allowed Cryptographic Functions ....................................7 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.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..................................................................................10 Table 3.5‐1 Platform Public Keys .............................................................................................10 Table 3.6‐1 PIV Public Keys ......................................................................................................11 Table 3.7‐1 BOCC Public Keys ..................................................................................................11 Table 3.8‐1 CKM Public Keys ....................................................................................................11 Table 4.0‐1 Roles Description ..................................................................................................13 Table 4.4‐1 Supported Authentication Key File Types.............................................................17 Table 4.5.1‐1 General Purpose and Unauthenticated Services and CSPs ...............................18 Table 4.5.2‐1 Domain Administrative Services ........................................................................18 Table 4.5.3‐1 Services, Roles, and Associated CSP Usage .......................................................20 Table 4.5.4‐1 CKM Attribute Container Applet Services .........................................................21 Table 4.6‐1 CKM Info Applet Services ......................................................................................21 Table 5.0‐1 Power‐On Self‐Tests..............................................................................................22 Table 5.0‐2 Conditional Self‐Tests ...........................................................................................22 Table 10.0‐1 References ..........................................................................................................26 Table 10.0‐2 Abbreviations and Acronyms ..............................................................................27 TecSec Incorporated Page v Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 1 Introduction The purpose of this document is to define the Security Policy for the TecSec Armored Card – Contact 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 contact 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 4 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 – Contact 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 Contactless 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 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 Figure 1.2-1 - CM Physical Image NC NC Figure 1.2-2 TecSec Armored Card – Logical Block Diagram 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. TecSec Incorporated Page 2 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 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 7816 compliant contact plate. The CM boundary separates the chip from the card and contact plate. The cryptographic boundary is the surface of the chip and associated bond pads, and not the entire smart card. 1.3 Firmware CM firmware comprises five Java Card applets implementing PIV contact 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 Contactless functionality, the CM has been validated for conformance to [SP 800-73] – see NPIVP PIV Card Application Cert. #35. 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. TecSec Incorporated Page 3 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 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). 1.4 Versions and Mode of Operation Hardware: P/N Inside Secure AT90SC320288RCT Revision E Firmware P/N Athena IDProtect Version 0108.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 0108.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. TecSec Incorporated Page 4 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 2 Ports and Interfaces The CM functions as a slave processor, accessed via a smart card reader over an ISO/IEC 7816 compliant interface. The CM supports both the T=0 and T=1 half-duplex 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 NC Unused No Connect RST External Reset signal Control in TecSec Incorporated Page 5 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 3 Cryptographic Functionality The CM operating system implements the FIPS Approved and Non-FIPS Approved cryptographic function listed in Table 3.0-1 and Table 3.0-2 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. #1654 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 1087 The Module supports the 2-Key2 and 3-Key options; in decryption ECB and CBC modes. [FIPS197] Advanced Encryption Standard algorithm. The AES 1654 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 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 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 contact 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 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 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 OS-PKEK AES-256 key used to encrypt all PINs 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 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 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-APSK, PIV-CMENC, PIV-DSPSK and PIV-CAPS are shown with multiple key types. The [SP 800-73] draft specification defines a different usage for the [SP 800-78] 9D key when used with RSA or EC DH algorithms, hence the separation of PIV-KMKDK and PIV-KMKGK below. Table 3.3-1 PIV Applet CSPs KEY DESCRIPTION / USAGE PIV Local PIN, per [SP 800-73]. 6-8 char plaintext string. The module enforces use of PIV-LPIN numeric (‘0’ – ‘9’) values only. Global PIN 6-8 char plaintext string. The module enforces use of numeric (‘0’ – ‘9’) PIV-GPIN values only. Local PIN unblocking key, per [SP 800-73]. 8 byte plaintext string. 0xFF reserved for PIV-LPUK padding. [SP 800-78] 9A (FIPS 201-1 PIV Authentication Key) private signature key. RSA 1024, PIV-A-PSK RSA 2048; ECDSA P-256. PIV-CM- [SP 800-78] 9B (FIPS 201-1 Card Management Key) secret key. 3-Key Triple-DES; AES- ENC 128, AES-192, AES-256. PIV-DS- [SP 800-78] 9C (FIPS 201-1 Digital Signature Key) private signature key. RSA 2048; PSK ECDSA P-256, P-384. PIV-KM- [SP 800-78] 9D (FIPS 201-1 Key Management Key) private key when used for RSA key KDK decryption. RSA 2048. PIV-KM- [SP 800-78] 9D (FIPS 201-1 Key Management Key) private key when used for the ECC KGK CDH shared secret (Z value) generation function. ECDH P-256 and P-384 curves. [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. TecSec Incorporated Page 9 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 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. 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. TecSec Incorporated Page 10 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 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 [SP 800-78] 9A (FIPS 201-1 PIV Authentication Key) public signature verification key. PIV-A-SVK RSA 1024, RSA 2048; ECDSA P-256. [SP 800-78] Digital Signature Key (9C). RSA 2048; ECDSA P-256, P-384. PIV-DS-SVK PIV-KM- [SP 800-78] Key Management Key (9D). RSA 2048. KWK PIV-KM- [SP 800-78] Key Management Key (9D), ECC CDH variant. ECDH P-256, P-384. KZG 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. User defined public signature verification keys for data attribute containers. The CKM-USER-SVK CM 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. TecSec Incorporated Page 11 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 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 256-bit security strength functions and key lengths: AES-256 symmetric keys, p521 ECC CDH and SHA-512. TecSec Incorporated Page 12 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 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. PIV Application Administrator. This role is responsible for managing PIV applet container PA content using the PIV applet PUT DATA command and invoking asymmetric key pair generation using the PIV applet GENERATE ASYMMETRIC KEY PAIR command. Authenticates to the module using the external authentication sequence of the GENERAL AUTHENTICATE command with the PIV-CM-ENC (9B) key. PIV Cardholder (the User role for [FIPS 140] purposes). This role is responsible for interaction PC with the cardholder PIV applet card command functions. The operator in this role has knowledge of the PIV User local PIN (PIV-LPIN) and/or global PIN (PIV-GPIN) and can perform cryptographic operations using the keys stored in the PIV applet as well as retrieve applet containers restricted to the cardholder. The PIV User authenticates to the module through the PIV applet by presenting the PIV User local or global PIN. PIV PIN Administrator. This role is responsible for interaction with the PIN administrator PIV PP applet card command functions. The operator in this role has knowledge of the PIV PIN Unblocking Key (PIV-LPUK) and can unblock the PIV User PIN and establish a new PIV User PIN. The PIV PIN Administrator authenticates to the module through the PIV applet by presenting the LPUK in the CHANGE REFERENCE DATA or RESET RETRY COUNTER APDU commands. CKM User: CKM Attribute Container role used to grant or deny access to objects or CSPs. This CU 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 TecSec Incorporated Page 13 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 ROLE DESCRIPTION ID 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 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). TecSec Incorporated Page 14 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 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 PIV Authentication Methods The CM implements cardholder verification as defined by [SP 800-73]. Briefly, the PIV cardholder or PIV PIN Administrator provides a shared secret string value in plaintext to the module via commands sent by an external application through a card reader. The CM compares the provided value to the corresponding stored authentication data, PIV-LPIN, PIV-GPIN, or PIV-LPUK, as identified by a parameter in the command. Each of these methods has an associated retry count. The retry counts are definable as card personalization parameters, with a maximum retry of 10. [SP 800-73] defines the PIN and PUK parameters in the commands as described above. The CM PIV applet enforces a six numeric character minimum length. The authentication strength for this method is as follows: The probability that a random attempt at authentication will succeed is 1/10^6 (1.0E-6). • This calculation is based on the PIV-LPIN and PIV-GPIN variants of this mechanism; the PIV-LPUK permits a larger character set (all values except 0xFF). 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 10/10^6 (1.0E-5). The CM also implements the GENERAL AUTHENTICATE service in the PIV Applet for internal, external or mutual authentication as defined by the protocols described in [SP 800-73]. Only the internal authenticate and the internal portion of mutual authenticate are relevant to [FIPS 140] authentication requirements. Briefly, a random challenge of at least eight bytes is sent to the CM; the CM responds with the value of the challenge encrypted with the PIV-CMENC key (the [SP 800-78] ‘9B’ key, described in [FIPS 201] as the Card Management Key). The minimum equivalent strength of the possible PIV-CMENC key types is 112 bits. The CM enforces a maximum retry of 255 attempts. The authentication strength for this method is as follows: The probability that a random attempt at authentication will succeed is 1/2^64 (5.4E-20) • at minimum, when the 3-Key Triple-DES variant of 9B is used. The CM implements all [SP 800-73] algorithm and strength options for this key; the AES variants are stronger (a lower probability of false authentication). 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 (1.38E-17) TecSec Incorporated Page 15 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 All PIV PIN, PUK and cryptographic keys are identified by a one-byte value as defined in [SP800-78]. 4.3 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. Biometric On Card Comparison may also be used as a second factor to the PIN (the Fingerprint and PIN option). In this configuration, authentication strength is met by the PIN, and the FAR may be set to a lower level (See 4.4 CKM Authentication). 4.4 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 TecSec Incorporated Page 16 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 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. Table 4.4-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.5 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.5.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. TecSec Incorporated Page 17 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 Table 4.5.1-1 General Purpose and Unauthenticated Services and CSPs SERVICE DESCRIPTION Power cycle the CM by removing and reinserting it into the contact reader slot, or by reader Card reset assertion of the RST signal. 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. 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.5.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-CA 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- TecSec Incorporated Page 18 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 SERVICE DESCRIPTION CI IDI 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 Executes using OS-DRBG-STATE. Writes BOCC-KEAK. PIV-LPIN, PIV-GPIN, PIV-LPUK, BOCC-BIO, PIV- Personalize KMKDK, PIV-KMKGK Applet Generates BOCC-KEAK. PIV-APSK, PIV-CMENC, PIV-DSPSK, PIV- KMKDK, PIV-KMKGK , PIV-CAK Outputs public key for BOCC-KEAK, PIV-APSK, PIV-DSPSK, PIV-KMKDK, PIV-KMKGK, 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 TecSec Incorporated Page 19 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 SERVICE DESCRIPTION CI IDI Executes using SD-S-MAC, SD-S-ENC, SD-S-RMAC, SD-Key-ENC, SD- Key-MAC, SD-Key-DEK. 4.5.3 PIV Applet Card Command Services Table 4.5.3-1 Services, Roles, and Associated CSP Usage SERVICE DESCRIPTION PA PC PP CHANGE Change the PIV-LPIN or PIV-GPIN. Requires the correct current X REFERENCE value DATA GENERAL As defined in [SP 800-73] for the Contact function, has several X X AUTHENTICATE different usages depending on the operator and on command tags. When invoked with a challenge or witness tag by the PC operator, executes the specified algorithm using PIV-APSK, PIV-DSPSK, PIV- KMKDK, or PIV-KMKGK as specified in the command. When invoked with a challenge or witness tag by the PC or PO operator, executes the specified algorithm using PIV-CAPS. When invoked with a challenge or witness tag by the PA operator, executes the specified algorithm using PIV-CMENC. When invoked for nonce generation in a challenge executes using OS-DRBG-STATE GENERATE The PIV Application Administrator can cause any of the PIV RSA key X ASYMMETRIC pairs (9A, 9C, 9D, 9E) to be created and stored in the PIV applet. KEY PAIR The GET DATA card command retrieves the data content of the GET DATA X single data object whose tag is given in the data field. The PIV Application Administrator can replace the contents of PIV PUT DATA X Data objects using this APDU command. RESET RETRY Resets the retry counter of the PIN to its initial value and changes X COUNTER the PIN’s reference data VERIFY Authenticate the PIV cardholder using PIV-LPIN or PIV-GPIN. X 4.5.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. TecSec Incorporated Page 20 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 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 functionality File / data object X X that is derived from ISO/IEC 7816-4 and ISO/IEC 7816-9 This service contains commands that are used to authenticate a Authentication X X role or 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 Sign / verify X X user 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.5.5 CKM Info Applet The CKM Info applet has no CSPs and no defined roles. All services are available to the unauthenticated role. 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 21 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 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 22 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 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 cover), 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 4 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 PIN and 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 23 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 2013 Common Criteria certified; more information is available her http://www.commoncriteriaportal.org/products/. All cryptographic computations and sensitive operations such as PIN comparison 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 24 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 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 25 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 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 26 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 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 27 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision] DEV_32_082_Security Policy for TecSec Armored Card - Contact Cryptographic Module August 7, 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 PIV-LPIN PIV User local PIN PIV-GPIN PIV Global PIN PKCS Public Key Cryptography Standard PUK PIV User PIN Unblock PIN RNG Random Number Generator ROM Read Only Memory RSA Rivest, Shamir, Adleman SO Security Officer SSD Supplementary Security Domain TecSec Incorporated Page 28 Copyright 2013 www.tecsec.com Unclassified May be reproduced only in its original entirety [without revision]