Copyright 2015 KONA I Co., Ltd. †may be reproduced only in its original entirety (without revision) KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Document Version: 1.1.6 Date: 10/13/2015 KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 2 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) CHANGE RECORD Revision Date Author Description of Change 1.1.0 1.1.1 Jan 6, 2015 KONA I Reordering of table 10, table 11, and table 12 Removing useless CSPs(SDâ€SDEK, and DAPâ€SYM) 1.1.2 Feb 11, 2015 KONA I Removing triple DES keys in operation system CSPs. 1.1.3 Feb 23, 2015 KONA I Updates during final review. 1.1.4 April 29, 2015 KONA I Update misprint in Figure 3 and PKI Applet version number. 1.1.5 Sep 23, 2015 KONA I Update regarding DRBG HEALTH CHECK functionality 1.1.6 Oct 13, 2015 KONA I Update regarding description of AES in Table 6 KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 3 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) Table of Contents References........................................................................................................................................... 5 Acronyms and Definitions.................................................................................................................... 6 1 Overview....................................................................................................................................... 7 1.1 Versions, Configurations and Modes of Operation ..................................................................... 9 1.2 Hardware and Physical Cryptographic Boundary ........................................................................ 9 1.3 Firmware and Logical Cryptographic Boundary......................................................................... 11 2 Cryptographic Functionality......................................................................................................... 12 2.1 Critical Security Parameters....................................................................................................... 14 2.2 Public Keys ................................................................................................................................. 15 3 Roles, Authentication and Services .............................................................................................. 16 3.1 Secure Channel Protocol Authentication Method..................................................................... 16 3.2 PKI Applet Authentication Method............................................................................................ 17 3.3 Services ...................................................................................................................................... 17 4 Selfâ€test....................................................................................................................................... 23 4.1 Powerâ€On Selfâ€tests ................................................................................................................... 23 4.2 Conditional Selfâ€Tests ................................................................................................................ 24 5 Physical Security Policy................................................................................................................ 25 6 Operational Environment ............................................................................................................ 25 7 Electromagnetic Interference and Compatibility (EMI/EMC) ........................................................ 25 8 Mitigation of Other Attacks Policy ............................................................................................... 25 9 Security Rules and Guidance........................................................................................................ 25 10 Appendix ..................................................................................................................................... 26 List of Tables Table 1: References.......................................................................................................................................5 Table 2: Acronyms and Definitions ............................................................................................................... 6 Table 3: Security Level of Security Requirements......................................................................................... 7 Table 4: Ports and Interfaces ...................................................................................................................... 11 Table 5: Approved Cryptographic Functions............................................................................................... 12 Table 6: Nonâ€Approved but Allowed Cryptographic Functions..................................................................13 Table 7: Critical Security Parameters.......................................................................................................... 14 Table 8: Public Keys.....................................................................................................................................15 Table 9: Roles Supported by the Module ................................................................................................... 16 Table 10: Unauthenticated Services ........................................................................................................... 17 Table 11: Authenticated Services ............................................................................................................... 19 Table 12: CSP and Public Key Access within Services .................................................................................22 KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 4 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) Table 13: Powerâ€On Selfâ€Test ..................................................................................................................... 23 List of Figures Figure 1: KONA N41M0 Chip (Front)............................................................................................................. 9 Figure 2: KONA N41M0 Chip (Back)............................................................................................................ 10 Figure 3: Module Block Diagram................................................................................................................. 11 Figure 4: KONA I KONA N41M0 – Plastic Body: Physical Form...................................................................26 Figure 5: KONA I KONA N41M0 – Secure SD Cards: Physical Form ............................................................27 Figure 6: KONA I KONA N41M0 – Key FOBs : Physical Form.......................................................................27 Figure 7: KONA I KONA N41M0 – USB Token: Physical Form.....................................................................27 Figure 8: KONA I KONA N41M0 – (U)SIM : Physical Form ..........................................................................28 KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 5 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) References Acronym Full Specification Name [FIPS140â€2] NIST, Security Requirements for Cryptographic Modules, May 25, 2001 [GlobalPlatform] GlobalPlatform Consortium: GlobalPlatform Card Specification 2.2.1,Jan 2011, http://www.globalplatform.org GlobalPlatform Consortium: GlobalPlatform Card Specification 2.2AmendmentD, Sept 2009 [ISO 7816] ISO/IEC 7816â€1: 1998 Identification cards â€â€ Integrated circuit(s) cards with contacts â€â€ Part 1: Physical characteristics ISO/IEC 7816â€2:2007 Identification cards â€â€ Integrated circuit cards â€â€ Part 2: Cards with contacts â€â€ Dimensions and location of the contacts ISO/IEC 7816â€3:2006 Identification cards â€â€ Integrated circuit cards â€â€ Part 3: Cards with contacts â€â€ Electrical interface and transmission protocols ISO/IEC 7816â€4:2005 Identification cards â€â€ Integrated circuit cards â€â€ Part 4: Organization, security and commands for interchange [JavaCard] Java Card 3.0.4 Runtime Environment (JCRE) Specification Java Card 3.0.4Virtual Machine (JCVM) Specification Java Card 3.0.4Application Programming Interface Published by Sun Microsystems, March 2006 [SP800â€131A] Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, January 2011 [SP 800â€67] NIST Special Publication 800â€67, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, version 1.2, July 2011 [FIPS113] NIST, Computer Data Authentication, FIPS Publication 113, 30 May 1985 [FIPS197] NIST, Advanced Encryption Standard (AES), FIPS Publication 197, November 26, 2001 [PKCS#1] PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories, June 14, 2002 [FIPS 186â€4] NIST, Digital Signature Standard (DSS), FIPS Publication 186â€4, July 2013 [FIPS 180â€4] NIST, Secure Hash Standard, FIPS Publication 180â€4, March 2012 [SP 800â€90A] NIST Special Publication 800â€90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, January 2012 [IG] NIST, Implementation Guidance for FIPS PUB 140â€2 and the Cryptographic Module Validation Program, last updated 25July 2013 [ETSI TS 102 613] Smart Cards; UICC †Contactless Frontâ€end (CLF) Interface; Part 1: Physical and data link layer characteristics [ETSI TS 102 622] Smart Cards; UICC †Contactless Frontâ€end (CLF) Interface; Host Controller Interface (HCI) [ETSI TS 102 705] Smart Cards; UICC Application Programming Interface for Java Cardâ„¢ for Contactless Applications Table 1: References KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 6 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) Acronyms and Definitions Acronym Definition APDU Application Protocol Data Unit, see [ISO 7816] API Application Programming Interface CM Card Manager, see [GlobalPlatform] CSP Critical Security Parameter, see [FIPS 140â€2] DAP Data Authentication Pattern, see [GlobalPlatform] DF Dedicated File DPA Differential Power Analysis EF Elementary File GP GlobalPlatform IC Integrated Circuit ISD Issuer Security Domain, see [GlobalPlatform] KAT Known Answer Test NFC Near Field Communication NVM Nonâ€Volatile Memory (e.g., EEPROM, Flash) OP Open Platform (predecessor to GlobalPlatform) PCT Pairâ€wise Consistency Test PKI Public Key Infrastructure SCP Secure Channel Protocol, see [GlobalPlatform] SPA Simple Power Analysis SWP Single Wire Protocol TPDU Transaction Protocol Data Unit, see [ISO 7816] Table 2: Acronyms and Definitions KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 7 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) 1 Overview This document defines the Security Policy for the KONA I Co., Ltd. KONA N41M0 cryptographic module, hereafter denoted the Module. The Module, validated to FIPS 140â€2 overall Level 3, is a single chip module implementing the Global Platform operational environment, with Card Manager and a PKI Applet. The PKI Applet is available for any Cryptographic solution the card may give. The term platform herein is used to describe the chip and operational environment, not inclusive of the PKI Applet. The Module is a limited operational environment under the FIPS 140â€2 definitions. The Module includes a firmware load function to support necessary updates. New firmware versions within the scope of this validation must be validated through the CMVP. Any other firmware loaded into this module is out of the scope of this validation and requires a separate FIPS 140â€2 validation. The FIPS 140â€2 security levels for the Module are as follows: Security Requirement Level Cryptographic Module Specification 3 Cryptographic Module Ports and Interfaces 3 Roles, Services, and Authentication 3 Finite State Model 3 Physical Security 3 Operational Environment N/A Cryptographic Key Management 3 EMI/EMC 3 Selfâ€Tests 3 Design Assurance 3 Mitigation of Other Attacks 3 Table 3: Security Level of Security Requirements The Module and the PKI Applet implementation are compliant with: ・ [ISO 7816] Parts 1â€4 (the Module) ・ [ISO 7816] Parts 4, 8 and 9 (PKI Applet) ・ [ETSI TS 102 613] KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 8 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) ・ [ETSI TS 102 622] ・ [JavaCard] ・ [GlobalPlatform] KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 9 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) 1.1 Versions, Configurations and Modes of Operation Hardware: Infineon SLE97CNFX1M00PEA22 (supports Contact ISO 7816 and ETSI TS 102 613) Firmware: KONA N41M0 v2.01 and PKI Applet v1.3.3 The module is always in an Approved mode of operation. The module does not support a nonâ€Approved mode of operation. To determine if this is a FIPS certified module operating in the Approved mode of operation, call the Module Info and Applet Info services and compare the Hardware/Firmware versions to the versions on the FIPS certificate. 1.2 Hardware and Physical Cryptographic Boundary Figure 1: KONA N41M0 Chip (Front) KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 10 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) Figure 2: KONA N41M0 Chip (Back) The Module is designed to be embedded into six (6) form factors: plastic card bodies, USB tokens, key FOBs, secure SD cards, embedded secure elements, and (U) SIMs. The physical form of the Module is depicted in Figure 1 and 2; this shows the physical cryptographic boundary, representing the surface of the chip and the bond pads. In production use, the Module is delivered to either vendors or end user customers in the following various forms: ï‚· As bare die in wafer form for direct chip assembly by wire bonding or flip chip assembly ï‚· Wire bonded and encapsulated by epoxy with additional packaging (e.g., Dual Interface Modules; Contact only Modules; Contactless Modules; SMD packages) ï‚· For plastic card bodies and secure SD cards form factor, the Module relies on [ISO7816] card readers as input/output devices. ï‚· For key FOBs form factor, the Module relies on [ETSI 102 613] card readers as input/output devices. ï‚· For USB token, embedded secure elements and (U) SIM form factors, the Module relies on [ISO7816] and [ETSI 102 613] card readers as input/output devices. Port Description Logical Interface Type VCC, GND ISO 7816: Supply voltage Power RST ISO 7816: Reset Control in CLK ISO 7816: Clock Control in I/O ISO 7816: Input/output Control in, Data in, Data out, Status out KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 11 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) Port Description Logical Interface Type Vpp ETSI 102 613: SWP Control in, Data in, Data out, Status out Table 4: Ports and Interfaces 1.3 Firmware and Logical Cryptographic Boundary Figure 3 depicts the Module operational environment. Figure 3: Module Block Diagram ï‚· The ISO 7816 UART supports the T=0 and T=1 communications protocol variants The entire logical interfaces (data I/O, control, status) path through the ISO 7816 port ï‚· The ETSI 102 613 SWP supports Single Wire communication protocol variants ï‚· 1016 KB FLASH; 32 KB RAM Section 3 describes applet functionality in greater detail. The JavaCard and Global Platform APIs are internal interfaces available to applets. Only applet services are available at the card edge (the interfaces that cross the cryptographic boundary). KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 12 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) 2 Cryptographic Functionality The Module implements the Approved and nonâ€Approved but allowed cryptographic functions listed below in Table 5: Approved Cryptographic Functions and Table 6: Nonâ€Approved but Allowed Cryptographic Functions Table. Algorithm Description Cert. # DRBG [SP 800â€90A] CTR_DRBG with security strength 128,192 and 256. 884 Tripleâ€DES [SP 800â€67] Triple Data Encryption Standard (TDES) algorithm. The module supports the 2â€Key1 and 3â€Key options; CBC and ECB modes. 1979 Tripleâ€DES MAC [FIPS113] Tripleâ€DES MAC (Tripleâ€DES Cert. #1979) Vendor Affirmed AES [FIPS 197] Advanced Encryption Standard algorithm. The module supports 128, 192, and 256â€bit key lengths and ECB and CBC modes. 3525 AES CMAC [SP800â€38B] AESâ€256 CMAC 3525 HMAC [FIPS 198â€1] The module supports generation and verification with SHAâ€1, SHAâ€256, and SHAâ€512; key lengths >= 112 bits. 2253 SHAâ€1, SHAâ€2 [FIPS 180â€2] Secure Hash Standard compliant oneâ€way (hash) algorithms; SHAâ€1, SHAâ€256, SHAâ€384, and SHAâ€512. 2907 RSA [FIPS 186â€4] RSA key generation, signature generation, and signature verification. The module supports 2048â€bit RSA keys with SHAâ€2 for key generation, signature generation, and signature verification. For legacy use, the module supports 1024â€bit RSA keys and SHAâ€1 for signature verification. 1811 RSA CRT [PKCS#1] RSA key generation, signature generation, and signature verification. The module supports 2048â€bit RSA keys with SHAâ€2 for key generation, signature generation, and signature verification. For legacy use, the module supports 1024â€bit RSA keys and SHAâ€1 for signature verification. 1812 ECDSA [FIPS 186â€4] EllipticCurve Digital Signature Algorithmes. The module supports the NIST defined Pâ€256, Pâ€384, and Pâ€521 curves for key pair generation, signature generation, and signature verification. For legacy use, the module supports Pâ€192 and Pâ€224 curves and SHAâ€1 for signature verification. 718 Table 5: Approved Cryptographic Functions 1 2â€Key TDES Encryption is Restricted per SP 800â€131A to limit the total number of blocks of data encrypted with the same cryptographic key to be no greater than 2^20. This restriction is implemented in the module’s firmware. KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 13 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) Algorithm Description NDRNG Hardware RNG. The HW RNG output used to seed the FIPS approved DRBG with entropy depending on DRBG’s instantiated security strength. Note: The NDRNG only produces about 98% minâ€entropy. This will still initialize the Approved DRBG with the required >=112 bits of security. More specifically, it lowers the DRBG’s security strength to 125 bits of security for AESâ€128 CTR_DRBG, 188 bits of security for AESâ€192 CTR_DRBG, and 250 bits of security for AESâ€256 CTR_DRBG. Symmetric Key Wrap AES (Cert. #3525, key wrapping) Nonâ€SP 800â€56A Compliant ECDH [IG D.8] EC Diffieâ€Hellman (key agreement; key establishment methodology provides between 112 and 256 bits of encryption strength) Table 6: Nonâ€Approved but Allowed Cryptographic Functions KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 14 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) 2.1 Critical Security Parameters All CSPs used by the Module are described in this section. All usage of these CSPs is described in the services detailed in Section 4. In the tables below, the following prefixes are used: ï‚· OS prefix denotes operating system. ï‚· SD prefix denotes the GlobalPlatform Security Domain. ï‚· DAP prefix denotes the GlobalPlatform Data Authentication Protocol. ï‚· PKI prefix denotes a PKI Applet CSP. CSP Description/Usage OSâ€RNGâ€SEED 256, 320, 384bits seed (entropy input) to AESâ€128/192/256 based CTR_DRBG. OSâ€RNGâ€STATE The current DRBG state. CSPs as described in FIPS IG 14.5. OSâ€MKEK 3â€Key Tripleâ€DES master key used to encrypt all keys stored in NVM. SDâ€KENC AESâ€128 master key used to generate SDâ€SENC. SDâ€KMAC AESâ€128 master key used to generate SDâ€SMAC. SDâ€KDEK AESâ€128 sensitive data decryption key used to decrypt CSPs. SDâ€SENC AESâ€128 session encryption key used to encrypt/decrypt secure channel data. SDâ€SMAC AESâ€128 session CMAC key used to verify inbound secure channel data integrity. PKIâ€AUTH Only one (1) AESâ€128 (SCP03) Key used by the Authenticate service. PKIâ€KAPâ€PRI Only one (1) EC Pâ€256/384/521 private key of temporarily generated EC keyâ€pair used by the EC DH Key Agreement. PKIâ€MAC 0 to 15 Tripleâ€DES (2/3â€Key)/AESâ€256 CMAC or HMAC (16â€32 bytes) keys are used by the Message Authentication service. PKIâ€SGVâ€PRI 0 to 20 (10 for RSA and 10 for EC) RSA/RSAâ€CRT 2048â€bit or EC Pâ€256/384/521 private keys are used by the Key Pair Generation and Digital Signature services. PKIâ€CSPâ€WRAP Only one (1) AESâ€256 key used for wrap/unwrap other CSPs and Random Output by Update CSPs, Get Data, PIN Verify, Reset Retry Counter and Random Number Generation services. At the Very beginning this container initialized with AESâ€256 key by ECDH Key Agreement Service. PKIâ€CONâ€SECRET 0 to 20 Tripleâ€DES (2/3â€Key) or AESâ€128/192/256 keys are used by the Confidentiality service. PKIâ€SOâ€PIN 4 to 8â€byte hexâ€string for unblocking USERâ€PIN. The PKI Applet has only one (1) instance for storing the Security Officer (SO) PIN. PKIâ€USERâ€PIN 4 to 8â€byte hexâ€string for user authentication to access files that require PIN Authentication. The PKI Applet has only one (1) instance for storing the User PIN. Table 7: Critical Security Parameters KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 15 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) 2.2 Public Keys Key Description/Usage DAPâ€PUB RSA 2048â€bit new firmware signature verification key. PKIâ€KAPâ€PUB Only one (1) container to store Pâ€256, Pâ€384, and Pâ€521 public keys of temporarily generated EC keyâ€pair at ECDH Key Agreement Service. PKIâ€SGVâ€PUB 0 to 20 (10 for RSA and 10 for EC) RSA/RSAâ€CRT 2048â€bit or EC Pâ€256/384/521 public keys are used by the Key Pair Generation, Get Data and Digital Signature services. PKIâ€3Pâ€PUB 0 to 15 3rd party public key containers is available in PKIâ€Applet. RSAâ€1024/2048 bits public key, EC Pâ€192, Pâ€224, Pâ€256, Pâ€384 and Pâ€521 public keys are used for Digital Signature Verification. PKIâ€3Pâ€PUB container can also be used in Get Data service. Table 8: Public Keys KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 16 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) 3 Roles, Authentication and Services The Module: ï‚· Does not support a maintenance role. ï‚· Clears previous authentications on power cycle. ï‚· Supports Global Platform SCP logical channels, allowing concurrent operators in a limited fashion. Authentication of each operator and their access to roles and services is as described below, independent of logical channel usage. ï‚· Only one operator at a time is permitted on a channel. ï‚· Applet deâ€selection (including Card Manager), card reset or power down terminates the current authentication. Reâ€authentication is required after any of these events for access to authenticated services. ï‚· Authentication data is encrypted during entry (by SDâ€KDEK), is stored in plaintext and is only accessible by authenticated services. ï‚· Context service (SELECT) enables operator role change. Because SELECT procedure contains applet deâ€selection in it, reâ€authentication is required. Lists of all operator roles supported by the Module. Role ID Role Description Authentication Type Authentication Method CO Cryptographic Officer – manages Module content and configuration, including issuance and management of Module data via the ISD. Identityâ€based Secure Channel Protocol Authentication User User – can run PKI Applet services. Identityâ€based PKI Applet Authentication Table 9: Roles Supported by the Module 3.1 Secure Channel Protocol Authentication Method The Secure Channel Protocol authentication method is provided by the Secure Channel service. The SD†KENC and SDâ€KMAC keys are used to derive the SDâ€SENC and SDâ€SMAC keys, respectively. The SDâ€SENC key is used to create a cryptogram; the external entity participating in the mutual authentication also creates this cryptogram. Each participant compares the received cryptogram to the calculated cryptogram and if this succeeds, the two participants are mutually authenticated (the external entity is authenticated to the Module in the CO role). KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 17 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) The probability that a random attempt will succeed is 1/2^128 = 2.9Eâ€39 (assuming a 128â€bit block). The maximum number of consecutive authentication attempts before a card error occurs is 300. So the corresponding conservative upper bound for the number of authentication attempts in a oneâ€minute period is 300. Therefore, the probability that a random attempt at authentication will succeed in a one†minute period is 300/2^128 = 8.8Eâ€37. 3.2 PKI Applet Authentication Method The PKI Applet uses a predetermined datum (PKIâ€AUTH) and AESâ€128 (SCP03) to authenticate the User operator. The probability that a random attempt at authentication will succeed is determined by the message size (128 bits for SCP03), chosen to correspond to the algorithm block size. The probability that a random attempt at authentication will succeed is 1/2^128=2.9Eâ€39. The maximum number of consecutive authentication attempts before a card error occurs is 2^24. So the corresponding conservative upper bound for the number of authentication attempts in a oneâ€minute period is 2^24. Therefore, the probability that a random attempt at authentication will succeed in a one†minute period is (2^24)/(2^128) = 4.9Eâ€32. 3.3 Services All services implemented by the Module are listed in the tables below. Each service description also describes all usage of CSPs by the service. All services which allow user access to the secret keys, private keys, and CSPs are authenticated service, so unauthorized user can’t read or edit the secret keys, private keys, and CSPs. Service Description CO User Secure Channel Establish and use a secure communications channel (INITIALIZE UPDATE; EXTERNAL AUTHENTICATE). X Context Select an Applet or manage logical channels (APDU: SELECT, MANAGE CHANNEL). X Module Info (Unauthenticated) Read unprivileged data objects or module information, e.g. Module configuration or status information (APDU: GET DATA, GET STATUS). X Applet Info (Unauthenticated) Read Applets Information (APDU: GET DATA) of PKIâ€Applet by User Role. X Authenticate PKI Applet authentication service (SCPâ€03). X Module Reset Power cycle or reset the Module. Includes Powerâ€On Selfâ€Test. X Table 10: Unauthenticated Services KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 18 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) Service Description CO User Lifecycle Modify the card or applet life cycle status (SET STATUS). By calling SET STATUS (TERMINATE) APDU, the status of applet become TERMINATE, and applet CSPs zeroization is performed. X Manage Content Load and install application packages and associated keys and data (APDU: DELETE; LOAD; INSTALL; PUT KEY; STORE DATA). Zeroize can be performed by calling DELETE APDU, used to delete the PKI Applet and CSPs. X Activation Activates PKIâ€Applet, DF/EFs. And also Deactivate EFs (APDU: ACTIVATE APPLET, ACTIVATE FILE and DEACTIVATE FILE). X File Management Service Creates and Selects EF’s and DF’s (APDU: CREATE FILE, SELECT FILE). X Data File Operation Updates, reads or erase binary into Transparent EFs (APDU: UPDATE BINARY, READ BINARY and ERASE BINARY). X Update CSPs Update Secret keys, Public Keys and initialized PIN reference data. X Reset Retry Counter Resets the reference data (PIN) retry counter to its initial value, or changes/updates reference data on completion of the reference data retry counter to its initial value for both SO_PIN and USER_PIN. X PIN Verify Authenticate the user by comparing the verification data (PIN) with the reference data stored in the applet internally. X Random Number Generation Generates Random Number by NDRBG/DRBG and return a random number. X Key Pair Generation Generates RSA and ECDSA keyâ€pair. X Get Data Retrieves Public keys in plain form and secret keys in encrypted form. X Manage Security Environment Manage the security environment for performing security operations with key and algorithm. X Digital Signature Signature generation and signature verification with RSA and ECDSA. X Message Authentication Generates and verifies MAC by Tripleâ€DES MAC, AES CMAC, and HMAC. X Message Digest Generates Digest using SHAâ€1 and SHAâ€2. X Confidentiality Encrypt/Decrypt plain text with AESâ€128/192/256 Keys or TDESâ€2/3 keys. X Key Agreement Creates shared secret by allowed EC DH. X Destroy PKI Applet CSPs Destroys (Zeroizes) all PKI Applet CSPs and delete Profile. X KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 19 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) Table 11: Authenticated Services Service CSPs and Public Keys OSâ€RNGâ€SEED OSâ€RNGâ€STATE OSâ€MKEK SDâ€KENC SDâ€KMAC SDâ€KDEK SDâ€SENC SDâ€SMAC PKIâ€AUTH PKIâ€KAPâ€PRI PKIâ€MAC PKIâ€SGVâ€PRI PKIâ€CSPâ€WRAP PKIâ€CONâ€SECRET PKIâ€SOâ€PIN PKIâ€USERâ€PIN DAPâ€PUB PKIâ€KAPâ€PUB PKIâ€SGVâ€PUB PKIâ€3Pâ€PUB Secure Channel â€â€ E W E E E E G E W G E W â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ Context â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ Z Z â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ Module Info (Unauth) â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ E E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ Applet Info (UnAuth) â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ Authenticate â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ Module Reset G E W Z G E W Z W I â€â€ â€â€ â€â€ Z Z â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ Lifecycle Z Z Z Z Z Z E E Z Z Z Z Z â€â€ Z Z â€â€ â€â€ â€â€ â€â€ KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 20 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) Service CSPs and Public Keys OSâ€RNGâ€SEED OSâ€RNGâ€STATE OSâ€MKEK SDâ€KENC SDâ€KMAC SDâ€KDEK SDâ€SENC SDâ€SMAC PKIâ€AUTH PKIâ€KAPâ€PRI PKIâ€MAC PKIâ€SGVâ€PRI PKIâ€CSPâ€WRAP PKIâ€CONâ€SECRET PKIâ€SOâ€PIN PKIâ€USERâ€PIN DAPâ€PUB PKIâ€KAPâ€PUB PKIâ€SGVâ€PUB PKIâ€3Pâ€PUB Manage Content â€â€ â€â€ E W I Z W I Z W I Z E Z E Z W Z Z Z Z Z Z Z Z E W I â€â€ â€â€ â€â€ Activation â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ File Management Service â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ Data File Operation â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ Update CSPs â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ W I â€â€ W I â€â€ E W I W I W I W I â€â€ â€â€ â€â€ W I Reset Retry Counter â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ E â€â€ E W I E W I â€â€ â€â€ â€â€ â€â€ PIN Verify â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ E â€â€ E E â€â€ â€â€ â€â€ â€â€ Random Number Generation G E W I Z G E W Z E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 21 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) Service CSPs and Public Keys OSâ€RNGâ€SEED OSâ€RNGâ€STATE OSâ€MKEK SDâ€KENC SDâ€KMAC SDâ€KDEK SDâ€SENC SDâ€SMAC PKIâ€AUTH PKIâ€KAPâ€PRI PKIâ€MAC PKIâ€SGVâ€PRI PKIâ€CSPâ€WRAP PKIâ€CONâ€SECRET PKIâ€SOâ€PIN PKIâ€USERâ€PIN DAPâ€PUB PKIâ€KAPâ€PUB PKIâ€SGVâ€PUB PKIâ€3Pâ€PUB Key Pair Generation G E W Z G E W Z E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ G W â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ G W â€â€ Get Data â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ O â€â€ E O â€â€ â€â€ â€â€ â€â€ O O Manage Security Environment â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ Digital Signature â€â€ E W E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ E E Message Authentication â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ Message Digest â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ Confidentiality â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ Key Agreement â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ â€â€ G E W Z â€â€ â€â€ G W â€â€ â€â€ â€â€ â€â€ G E W O Z â€â€ â€â€ KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 22 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) Service CSPs and Public Keys OSâ€RNGâ€SEED OSâ€RNGâ€STATE OSâ€MKEK SDâ€KENC SDâ€KMAC SDâ€KDEK SDâ€SENC SDâ€SMAC PKIâ€AUTH PKIâ€KAPâ€PRI PKIâ€MAC PKIâ€SGVâ€PRI PKIâ€CSPâ€WRAP PKIâ€CONâ€SECRET PKIâ€SOâ€PIN PKIâ€USERâ€PIN DAPâ€PUB PKIâ€KAPâ€PUB PKIâ€SGVâ€PUB PKIâ€3Pâ€PUB Destroy PKI Applet CSPs â€â€ â€â€ E â€â€ â€â€ â€â€ â€â€ â€â€ W †Z Z Z Z Z Z â€â€ â€â€ â€â€ â€â€ Table 12: CSP and Public Key Access within Services ï‚· G = Generate: The Module generates the CSP. ï‚· E = Execute: The Module executes using the CSP. ï‚· W = Write: The Module writes the CSP. ï‚· O = Output: The Module outputs the CSP. ï‚· I = Input: The Module receives the CSP. (i.e., it enters the module). ï‚· Z = Zeroize: The module zeroizes the CSP. For the Context service, SD session keys are destroyed on applet deselect (channel closure). ï‚· â€â€ = Not accessed by the service. KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 23 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) 4 Selfâ€test 4.1 Powerâ€On Selfâ€tests On powerâ€on or reset, the Module performs selfâ€tests as described in Table 13: Powerâ€On Selfâ€Test below. All KATs must be completed successfully prior to any other use of cryptography by the Module. If one of the KATs fails, the system is halted and will start again after a reset. Test Target Description Firmware Integrity 32â€bit XOR checksum performed over all code located in NVM. This integrity test is not required or performed for code stored in masked ROM code memory. The module calculates a 32â€bit XOR checksum over the whole program memory area. The OS and the loaded applet are also covered by the 32â€bit XOR checksum. DRBG Performs a fixed input KAT on AESâ€128 bits CTR DRBG. Tripleâ€DES Performs encrypt and decrypt KATs using 3â€Key Tripleâ€DES in ECB mode. Tripleâ€DES MAC Performs Tripleâ€DES MAC generate and verify KATs using a3â€key Tripleâ€DES key. AES Performs AESâ€128 key in ECB mode for decrypt KAT. Encrypt KAT is tested by AES CMAC. AES CMAC Performs AES CMAC generate and verify KATs using an AESâ€128 key. HMAC Performs HMAC generate and verify KATs using only SHAâ€384 (okay per IG 9.4). SHAâ€1, SHAâ€2 Performs SHAâ€1 and SHAâ€512 KATs. SHAâ€256 is tested by the RSA sign/verify KAT, SHA†224 is tested by the ECDSA sign/verify KAT (even though it is not used by the module), and SHAâ€384 is tested by the HMACâ€SHAâ€384 KAT. RSA Performs separate RSA signature generation and verification KATs using an RSA 2048†bit key with SHAâ€256. RSA CRT Performs separate RSA CRT signature generation and verification KATs using an RSA 2048â€bit key with SHAâ€2. ECDSA Performs separate ECDSA signature generation and verification KAT using the Pâ€224 curve with SHAâ€224. Symmetric Key Wrap Performs separate key wrap and unwrap KATs using an AESâ€128 key and 2â€key Triple†DES key. Nonâ€SP 800â€56A Compliant ECDH Selfâ€tests as described in FIPS IG 9.9 using EC Pâ€224. Table 13: Powerâ€On Selfâ€Test KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 24 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) 4.2 Conditional Selfâ€Tests Test Target Description NDRNG NDRNG Continuous Test performed when a random value is requested from the NDRNG. DRBG DRBG Continuous Test performed when a random value is requested from the DRBG. DRBG SP 800â€90A Section 11.3 DRBG Health Checks ECDSA ECDSA Pair wise Consistency Test performed on every ECDSA key pair generation. The test performs a calculation and a verification of a digital signature. RSA RSA Pair wise Consistency Test performed on every RSA key pair generation. The encrypt/decrypt function is always used for the pairwise consistency check because it is unknown what the key pair will be used for at the time of generation. RSA CRT RSA CRT Pair wise Consistency Test performed on every RSA key pair generation. The encrypt/decrypt function is always used for the pairwise consistency check because it is unknown what the key pair will be used for at the time of generation. Firmware Load RSA 2048 with SHAâ€256 signature verification performed when firmware is loaded. When new firmware is loaded into the Module using the Manage Content service, the Module verifies the integrity of the new firmware (applet) using MAC verification with the SDâ€SMAC key. Optionally, the Module may also verify a signature of the new firmware (applet) using the DAPâ€PUB public key; the signature block in this scenario is generated by an external entity using the private key corresponding to DAP†PUB. Table 14: Conditional Selfâ€Test KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 25 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) 5 Physical Security Policy The Module is a singleâ€chip implementation that meets commercialâ€grade specifications for power, temperature, reliability, and shock/vibrations. The Module uses standard passivation techniques and is protected by passive shielding (metal layer coverings opaque to the circuitry below) and active shielding (a grid of top metal layer wires with tamper response). A tamper event detected by the active shield places the Module permanently into the SYSTEM HALTED error state(POWER OFF state in [FSM], but never transits to POWER ON INITIALIZATION state). The Module is intended to be mounted in additional packaging; physical inspection of the die is typically not practical after packaging. Physical inspection of modules for tamper evidence is performed using a lot sampling technique during the card assembly process. 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 require 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, and Class B. 8 Mitigation of Other Attacks Policy The Module implements defenses against: ï‚· Light attacks ï‚· Invasive fault attacks ï‚· Sideâ€channel attacks (SPA/DPA) ï‚· Timing analysis ï‚· Differential fault analysis (DFA) 9 Security Rules and Guidance The Module implementation also enforces the following security rules: KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 26 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) ï‚· No additional interface or service is implemented by the Module which would provide access to CSPs. ï‚· Data output is inhibited during key generation, selfâ€tests, zeroization, and error states. ï‚· There are no restrictions on which keys or CSPs are zeroized by the zeroization service. ï‚· The module does not support manual key entry. ï‚· The module does not output plaintext CSPs or intermediate key values. ï‚· Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module. ï‚· Security Domains support security services such as key handling, encryption, decryption, digital signature generation and verification for their providers' (Card Issuer, Application Provider or Controlling Authority) applications. For the security services, secure channel should be initiated, and the cryptoâ€officer can initiate the secure channel by authentication. ï‚· Identity based authentication is used by PKIâ€Applet through Secure Channel Protocol 3 (SCPâ€03). Selecting and authenticating PKIâ€Applet using an authentication key (internally stored) will implicitly select an operator in “user†role. The role performs general security services, including cryptographic operations and other approved security functions. Prior to invoke any PKIâ€Applet service by userâ€role, authentication should be done with GP SCP03 specified in Global Platform Card Specification v2.2Amendment D and also by PIN verification if the resource required. ï‚· 10 Appendix Physical form factor Figures using KONA N41M0 module Figure 4: KONA I KONA N41M0 – Plastic Body: Physical Form KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 27 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) Figure 5: KONA I KONA N41M0 – Secure SD Cards: Physical Form Figure 6: KONA I KONA N41M0 – Key FOBs : Physical Form Figure 7: KONA I KONA N41M0 – USB Token: Physical Form KONA N41M0 FIPS 140â€2 Cryptographic Module Nonâ€Proprietary Security Policy Copyright KONA I Co., Ltd., 2015 Page 28 of 28 KONA I Co., Ltd. Public Material – may be reproduced only in its original entirety (without revision) Figure 8: KONA I KONA N41M0 – (U)SIM : Physical Form