KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy Document Version: 1.1.6 Date: 10/13/2015 Copyright 2015 KONA I Co., Ltd. may be reproduced only in its original entirety (without revision) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy CHANGE RECORD Revision Date Author Description of Change 1.1.0 Reordering of table 10, table 11, and table 12 1.1.1 Jan 6, 2015 KONA I Removing useless CSPs(SDSDEK, and DAPSYM) 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. Update misprint in Figure 3 and PKI Applet version 1.1.4 April 29, 2015 KONA I 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 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 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 Selftest ....................................................................................................................................... 23 4.1 PowerOn Selftests ................................................................................................................... 23 4.2 Conditional SelfTests ................................................................................................................ 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: NonApproved 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 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy Table 13: PowerOn SelfTest ..................................................................................................................... 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 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy References Acronym Full Specification Name [FIPS1402] 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 78161: 1998 Identification cards Integrated circuit(s) cards with contacts Part 1: Physical characteristics ISO/IEC 78162:2007 Identification cards Integrated circuit cards Part 2: Cards with contacts Dimensions and location of the contacts ISO/IEC 78163:2006 Identification cards Integrated circuit cards Part 3: Cards with contacts Electrical interface and transmission protocols ISO/IEC 78164: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 [SP800131A] Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, January 2011 [SP 80067] NIST Special Publication 80067, 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 1864] NIST, Digital Signature Standard (DSS), FIPS Publication 1864, July 2013 [FIPS 1804] NIST, Secure Hash Standard, FIPS Publication 1804, March 2012 [SP 80090A] NIST Special Publication 80090A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, January 2012 [IG] NIST, Implementation Guidance for FIPS PUB 1402 and the Cryptographic Module Validation Program, last updated 25July 2013 [ETSI TS 102 613] Smart Cards; UICC Contactless Frontend (CLF) Interface; Part 1: Physical and data link layer characteristics [ETSI TS 102 622] Smart Cards; UICC Contactless Frontend (CLF) Interface; Host Controller Interface (HCI) [ETSI TS 102 705] Smart Cards; UICC Application Programming Interface for Java CardTM for Contactless Applications Table 1: References 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 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 1402] 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 NonVolatile Memory (e.g., EEPROM, Flash) OP Open Platform (predecessor to GlobalPlatform) PCT Pairwise 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 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 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 1402 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 1402 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 1402 validation. The FIPS 1402 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 SelfTests 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 14 (the Module) [ISO 7816] Parts 4, 8 and 9 (PKI Applet) [ETSI TS 102 613] 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy [ETSI TS 102 622] [JavaCard] [GlobalPlatform] 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 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 nonApproved 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) 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 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 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 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). 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 2 Cryptographic Functionality The Module implements the Approved and nonApproved but allowed cryptographic functions listed below in Table 5: Approved Cryptographic Functions and Table 6: NonApproved but Allowed Cryptographic Functions Table. Algorithm Description Cert. # DRBG [SP 80090A] CTR_DRBG with security strength 128,192 and 256. 884 TripleDES [SP 80067] Triple Data Encryption Standard (TDES) algorithm. The 1979 module supports the 2Key1 and 3Key options; CBC and ECB modes. TripleDES MAC [FIPS113] TripleDES MAC (TripleDES Cert. #1979) Vendor Affirmed AES [FIPS 197] Advanced Encryption Standard algorithm. The module 3525 supports 128, 192, and 256bit key lengths and ECB and CBC modes. AES CMAC [SP80038B] AES256 CMAC 3525 HMAC [FIPS 1981] The module supports generation and verification with SHA1, 2253 SHA256, and SHA512; key lengths >= 112 bits. SHA1, SHA2 [FIPS 1802] Secure Hash Standard compliant oneway (hash) algorithms; 2907 SHA1, SHA256, SHA384, and SHA512. RSA [FIPS 1864] RSA key generation, signature generation, and signature 1811 verification. The module supports 2048bit RSA keys with SHA2 for key generation, signature generation, and signature verification. For legacy use, the module supports 1024bit RSA keys and SHA1 for signature verification. RSA CRT [PKCS#1] RSA key generation, signature generation, and signature 1812 verification. The module supports 2048bit RSA keys with SHA2 for key generation, signature generation, and signature verification. For legacy use, the module supports 1024bit RSA keys and SHA1 for signature verification. ECDSA [FIPS 1864] EllipticCurve Digital Signature Algorithmes. The module 718 supports the NIST defined P256, P384, and P521 curves for key pair generation, signature generation, and signature verification. For legacy use, the module supports P192 and P224 curves and SHA1 for signature verification. Table 5: Approved Cryptographic Functions 1 2Key TDES Encryption is Restricted per SP 800131A 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. 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 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% minentropy. 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 AES128 CTR_DRBG, 188 bits of security for AES192 CTR_DRBG, and 250 bits of security for AES256 CTR_DRBG. Symmetric Key Wrap AES (Cert. #3525, key wrapping) NonSP 80056A [IG D.8] EC DiffieHellman (key agreement; key establishment methodology Compliant ECDH provides between 112 and 256 bits of encryption strength) Table 6: NonApproved but Allowed Cryptographic Functions 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 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 OSRNGSEED 256, 320, 384bits seed (entropy input) to AES128/192/256 based CTR_DRBG. OSRNGSTATE The current DRBG state. CSPs as described in FIPS IG 14.5. OSMKEK 3Key TripleDES master key used to encrypt all keys stored in NVM. SDKENC AES128 master key used to generate SDSENC. SDKMAC AES128 master key used to generate SDSMAC. SDKDEK AES128 sensitive data decryption key used to decrypt CSPs. SDSENC AES128 session encryption key used to encrypt/decrypt secure channel data. SDSMAC AES128 session CMAC key used to verify inbound secure channel data integrity. PKIAUTH Only one (1) AES128 (SCP03) Key used by the Authenticate service. PKIKAPPRI Only one (1) EC P256/384/521 private key of temporarily generated EC keypair used by the EC DH Key Agreement. PKIMAC 0 to 15 TripleDES (2/3Key)/AES256 CMAC or HMAC (1632 bytes) keys are used by the Message Authentication service. PKISGVPRI 0 to 20 (10 for RSA and 10 for EC) RSA/RSACRT 2048bit or EC P256/384/521 private keys are used by the Key Pair Generation and Digital Signature services. PKICSPWRAP Only one (1) AES256 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 AES256 key by ECDH Key Agreement Service. PKICONSECRET 0 to 20 TripleDES (2/3Key) or AES128/192/256 keys are used by the Confidentiality service. PKISOPIN 4 to 8byte hexstring for unblocking USERPIN. The PKI Applet has only one (1) instance for storing the Security Officer (SO) PIN. PKIUSERPIN 4 to 8byte hexstring 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 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 2.2 Public Keys Key Description/Usage DAPPUB RSA 2048bit new firmware signature verification key. PKIKAPPUB Only one (1) container to store P256, P384, and P521 public keys of temporarily generated EC keypair at ECDH Key Agreement Service. PKISGVPUB 0 to 20 (10 for RSA and 10 for EC) RSA/RSACRT 2048bit or EC P256/384/521 public keys are used by the Key Pair Generation, Get Data and Digital Signature services. PKI3PPUB 0 to 15 3rd party public key containers is available in PKIApplet. RSA1024/2048 bits public key, EC P192, P224, P256, P384 and P521 public keys are used for Digital Signature Verification. PKI3PPUB container can also be used in Get Data service. Table 8: Public Keys 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 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 deselection (including Card Manager), card reset or power down terminates the current authentication. Reauthentication is required after any of these events for access to authenticated services. Authentication data is encrypted during entry (by SDKDEK), is stored in plaintext and is only accessible by authenticated services. Context service (SELECT) enables operator role change. Because SELECT procedure contains applet deselection in it, reauthentication is required. Lists of all operator roles supported by the Module. Role ID Role Description Authentication Type Authentication Method CO Cryptographic Officer ­ manages Identitybased Secure Channel Protocol Module content and configuration, Authentication including issuance and management of Module data via the ISD. User User ­ can run PKI Applet services. Identitybased 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 SDKMAC keys are used to derive the SDSENC and SDSMAC keys, respectively. The SDSENC 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). 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy The probability that a random attempt will succeed is 1/2^128 = 2.9E39 (assuming a 128bit 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 oneminute period is 300. Therefore, the probability that a random attempt at authentication will succeed in a one minute period is 300/2^128 = 8.8E37. 3.2 PKI Applet Authentication Method The PKI Applet uses a predetermined datum (PKIAUTH) and AES128 (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.9E39. 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 oneminute 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.9E32. 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 CO User Description Secure Channel Establish and use a secure communications channel (INITIALIZE X UPDATE; EXTERNAL AUTHENTICATE). Context Select an Applet or manage logical channels (APDU: SELECT, X MANAGE CHANNEL). Module Info Read unprivileged data objects or module information, e.g. Module X (Unauthenticated) configuration or status information (APDU: GET DATA, GET STATUS). Applet Info Read Applets Information (APDU: GET DATA) of PKIApplet by User X (Unauthenticated) Role. Authenticate PKI Applet authentication service (SCP03). X Module Reset Power cycle or reset the Module. Includes PowerOn SelfTest. X Table 10: Unauthenticated Services 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy Service CO User Description Lifecycle Modify the card or applet life cycle status (SET STATUS). X By calling SET STATUS (TERMINATE) APDU, the status of applet become TERMINATE, and applet CSPs zeroization is performed. Manage Content Load and install application packages and associated keys and data X (APDU: DELETE; LOAD; INSTALL; PUT KEY; STORE DATA). Zeroize can be performed by calling DELETE APDU, used to delete the PKI Applet and CSPs. Activation Activates PKIApplet, DF/EFs. And also Deactivate EFs (APDU: X ACTIVATE APPLET, ACTIVATE FILE and DEACTIVATE FILE). File Management Creates and Selects EF's and DF's (APDU: CREATE FILE, SELECT X Service FILE). Data File Operation Updates, reads or erase binary into Transparent EFs (APDU: X UPDATE BINARY, READ BINARY and ERASE BINARY). 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 X reference data retry counter to its initial value for both SO_PIN and USER_PIN. PIN Verify Authenticate the user by comparing the verification data (PIN) X with the reference data stored in the applet internally. Random Number Generates Random Number by NDRBG/DRBG and return a random X Generation number. Key Pair Generation Generates RSA and ECDSA keypair. X Get Data Retrieves Public keys in plain form and secret keys in encrypted X form. Manage Security Manage the security environment for performing security X Environment operations with key and algorithm. Digital Signature Signature generation and signature verification with RSA and ECDSA. X Message Generates and verifies MAC by TripleDES MAC, AES CMAC, and X Authentication HMAC. Message Digest Generates Digest using SHA1 and SHA2. X Confidentiality Encrypt/Decrypt plain text with AES128/192/256 Keys or TDES2/3 X keys. Key Agreement Creates shared secret by allowed EC DH. X Destroy PKI Applet Destroys (Zeroizes) all PKI Applet CSPs and delete Profile. X CSPs 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy Table 11: Authenticated Services CSPs and Public Keys PKICONSECRET OSRNGSTATE PKICSPWRAP OSRNGSEED PKIUSERPIN PKISGVPUB PKIKAPPUB PKISGVPRI PKIKAPPRI PKI3PPUB PKISOPIN PKIAUTH SDKMAC OSMKEK SDSMAC DAPPUB PKIMAC SDKENC SDKDEK SDSENC Service G G E E E E E E E W W W Secure Channel Context Z Z E E Module Info (Unauth) Applet Info (UnAuth) E E Authenticate G G E E W W W Module Reset I Z Z Z Z E E Lifecycle Z Z Z Z Z Z Z Z Z Z Z Z Z 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy CSPs and Public Keys PKICONSECRET OSRNGSTATE PKICSPWRAP OSRNGSEED PKIUSERPIN PKISGVPUB PKIKAPPUB PKISGVPRI PKIKAPPRI PKI3PPUB PKISOPIN PKIAUTH SDKMAC OSMKEK SDSMAC DAPPUB PKIMAC SDKENC SDKDEK SDSENC Service E E E E W W W W W Manage Content I I I I Z Z Z Z Z Z Z Z Z Z Z Z Z Activation File Management E Service Data File E Operation E E W W W W W W W Update CSPs I I I I I I I E E E E W W Reset Retry Counter I I E E E E PIN Verify G G E E E Random W W Number E Generation I Z Z 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy CSPs and Public Keys PKICONSECRET OSRNGSTATE PKICSPWRAP OSRNGSEED PKIUSERPIN PKISGVPUB PKIKAPPUB PKISGVPRI PKIKAPPRI PKI3PPUB PKISOPIN PKIAUTH SDKMAC OSMKEK SDSMAC DAPPUB PKIMAC SDKENC SDKDEK SDSENC Service G G G G E E E W W W W Key Pair Generation Z Z E E Get Data O O O O Manage Security E Environment E E E E E W Digital Signature E E Message Authentication Message Digest E E Confidentiality G G G E E E W W W Key Agreement O Z Z 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy CSPs and Public Keys PKICONSECRET OSRNGSTATE PKICSPWRAP OSRNGSEED PKIUSERPIN PKISGVPUB PKIKAPPUB PKISGVPRI PKIKAPPRI PKI3PPUB PKISOPIN PKIAUTH SDKMAC OSMKEK SDSMAC DAPPUB PKIMAC SDKENC SDKDEK SDSENC Service E W Destroy PKI Applet CSPs 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. 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 4 Selftest 4.1 PowerOn Selftests On poweron or reset, the Module performs selftests as described in Table 13: PowerOn SelfTest 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 32bit 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 32bit XOR checksum over the whole program memory area. The OS and the loaded applet are also covered by the 32bit XOR checksum. DRBG Performs a fixed input KAT on AES128 bits CTR DRBG. TripleDES Performs encrypt and decrypt KATs using 3Key TripleDES in ECB mode. TripleDES MAC Performs TripleDES MAC generate and verify KATs using a3key TripleDES key. AES Performs AES128 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 AES128 key. HMAC Performs HMAC generate and verify KATs using only SHA384 (okay per IG 9.4). SHA1, SHA2 Performs SHA1 and SHA512 KATs. SHA256 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 SHA384 is tested by the HMACSHA384 KAT. RSA Performs separate RSA signature generation and verification KATs using an RSA 2048 bit key with SHA256. RSA CRT Performs separate RSA CRT signature generation and verification KATs using an RSA 2048bit key with SHA2. ECDSA Performs separate ECDSA signature generation and verification KAT using the P224 curve with SHA224. Symmetric Key Performs separate key wrap and unwrap KATs using an AES128 key and 2key Triple Wrap DES key. NonSP 80056A Selftests as described in FIPS IG 9.9 using EC P224. Compliant ECDH Table 13: PowerOn SelfTest 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 4.2 Conditional SelfTests 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 80090A 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 SHA256 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 SDSMAC key. Optionally, the Module may also verify a signature of the new firmware (applet) using the DAPPUB 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 SelfTest 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 5 Physical Security Policy The Module is a singlechip implementation that meets commercialgrade 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 1402 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 1402 CMVP. Any other firmware loaded into this module is out of the scope of this validation and require a separate FIPS 1402 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 Sidechannel attacks (SPA/DPA) Timing analysis Differential fault analysis (DFA) 9 Security Rules and Guidance The Module implementation also enforces the following security rules: 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy No additional interface or service is implemented by the Module which would provide access to CSPs. Data output is inhibited during key generation, selftests, 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 cryptoofficer can initiate the secure channel by authentication. Identity based authentication is used by PKIApplet through Secure Channel Protocol 3 (SCP03). Selecting and authenticating PKIApplet 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 PKIApplet service by userrole, 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 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy 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 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) KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy Figure 8: KONA I KONA N41M0 ­ (U)SIM : Physical Form 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)