KONA N41M0 FIPS 1402 Cryptographic Module NonProprietary Security Policy Document Version: 1.2 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 Table of Contents References ........................................................................................................................................... 4 Acronyms and Definitions .................................................................................................................... 5 1 Overview ....................................................................................................................................... 6 1.1 Versions, Configurations and Modes of Operation ..................................................................... 7 1.2 Hardware and Physical Cryptographic Boundary ........................................................................ 7 1.3 Firmware and Logical Cryptographic Boundary ........................................................................... 9 2 Cryptographic Functionality ......................................................................................................... 10 2.1 Critical Security Parameters ....................................................................................................... 12 2.2 Public Keys ................................................................................................................................. 12 2.3 Secure Channel Protocol Authentication Method ..................................................................... 14 2.4 Demonstration Applet Authentication Method ........................................................................ 15 2.5 Services ...................................................................................................................................... 15 3 Selftest ....................................................................................................................................... 19 3.1 PowerOn Selftests ................................................................................................................... 19 3.2 Conditional SelfTests ................................................................................................................ 20 4 Physical Security Policy ................................................................................................................ 21 5 Operational Environment ............................................................................................................ 21 6 Electromagnetic Interference and Compatibility (EMI/EMC) ........................................................ 21 7 Mitigation of Other Attacks Policy ............................................................................................... 21 8 Security Rules and Guidance ........................................................................................................ 21 9 Appendix ..................................................................................................................................... 22 List of Tables Table 1: References ....................................................................................................................................... 4 Table 2: Acronyms and Definitions ............................................................................................................... 5 Table 3: Security Level of Security Requirements ........................................................................................ 6 . Table 4: Ports and Interfaces ........................................................................................................................ 8 Table 5: Approved Cryptographic Functions............................................................................................... 10 Table 6: NonApproved but Allowed Cryptographic Functions .................................................................. 11 Table 7: Critical Security Parameters .......................................................................................................... 12 Table 8: Public KeyRoles, Authentication and Services .............................................................................. 13 Table 9: Roles Supported by the Module ................................................................................................... 14 Table 10: Unauthenticated Services ........................................................................................................... 15 Table 11: Authenticated Services ............................................................................................................... 16 Table 12: CSP and Public Key Access within Services ................................................................................. 18 Table 13: PowerOn SelfTest ..................................................................................................................... 20 Copyright KONA I Co., Ltd., 2015 Page 2 of 23 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 List of Figures Figure 1: KONA N41M0 chip (Front) ............................................................................................................. 7 Figure 2: KONA N41M0 chip (Back) .............................................................................................................. 8 Figure 3: Module Block Diagram ................................................................................................................... 9 Figure 4: KONA I KONA N41M0 ­ plastic body: Physical Form ................................................................... 22 Figure 5: KONA I KONA N41M0 ­ secure SD cards: Physical Form ............................................................. 22 Figure 6: KONA I KONA N41M0 ­ key FOBs: Physical Form ........................................................................ 23 Figure 7: KONA I KONA N41M0 ­ USB token: Physical Form ...................................................................... 23 Figure 8: KONA I KONA N41M0 ­ (U)SIM: Physical Form ........................................................................... 23 Copyright KONA I Co., Ltd., 2015 Page 3 of 23 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 [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 4 of 23 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] DPA Differential Power Analysis 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 5 of 23 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 singlechip module implementing the Global Platform operational environment, with Card Manager and a Demonstration Applet. The Demonstration Applet is available only to demonstrate the complete cryptographic capabilities of the Module for FIPS 1402 validation, and is not intended for general use. The term platform herein is used to describe the chip and operational environment, not inclusive of the Demonstration 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 implementation is compliant with: [ISO 7816] Parts 14 [ETSI TS 102 613] [ETSI TS 102 622] [JavaCard] [GlobalPlatform] Copyright KONA I Co., Ltd., 2015 Page 6 of 23 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 Demonstration Applet v1.2.4 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 7 of 23 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 Figures 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 Vpp ETSI 102 613: SWP Control in, Data in, Data out, Status out Table 4: Ports and Interfaces Copyright KONA I Co., Ltd., 2015 Page 8 of 23 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.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 The module inhibits all data output via the data output interface while the module is in error state and during selftests. 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 9 of 23 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 strengths 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] AES128/192/256 CMAC 3525 HMAC [FIPS 1981] The module supports generation and verification with SHA1, 2253 SHA256, SHA384, and SHA512; key lengths >= 112 bits. SHA1, SHA2 [FIPS 1802] Secure Hash Standard compliant oneway (hash) algorithms; 2907 SHA1, SHA224, 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] Elliptic Curve Digital Signature Algorithm. The module 718 supports the NIST defined P224, P256, P384, and P521 curves for key pair generation, signature generation, and signature verification. For legacy use, the module supports P192 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 10 of 23 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 AES (Cert. # 3525, key wrapping) Wrap NonSP 80056B [IG D.9] Compliant RSA RSA (key wrapping; key establishment methodology provides 112 bits of Key Transport encryption strength) (Encapsulation) 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 11 of 23 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. DEM prefix denotes a Demonstration Applet CSP. CSP Description/Usage OSRNGSEED 256, 320, 384 bits 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. DEMAUTH AES128 (SCP03) used by the Authenticate service. DEMKAPPRI P224, P256, P384, and P521 private key used to demonstrate the allowed EC DH by Key Agreement service. DEMMAC 2Key or 3Key TripleDES MAC or AES128/192/256 CMAC key or HMAC key used by the Message Authentication service. DEMSGVPRI 2048bit RSA/RSA CRT or EC P224, P256, P384, and P521 private keys used by the Key Pair Generation and Digital Signature (Signature generation only) services. DEMWRAP AES256 key used for wrap/unwrap other CSPs and Random Output by Update Demo SECRET Keys, Get Data and Random Number Generation services. DEMWRAPPRI 2048bit RSA/RSA CRT private keys used by the Key Pair Generation and Update Demo Keys services. DEMCON TripleDES (2/3Key), AES128, 192 and 256 keys are used by the Confidentiality SECRET service. DEMSHARED 20 bytes shared secret generated by ECDH Key Agreement Service. SECRET Table 7: Critical Security Parameters 2.2 Public Keys Key Description/Usage DAPPUB RSA 2048bit new firmware signature verification key. DEMKAPPUB Stores P224, P256, P384, and P521 public keys of temporarily generated EC keypair at ECDH Key Agreement Service. Copyright KONA I Co., Ltd., 2015 Page 12 of 23 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 Key Description/Usage DEMSGVPUB 2048bit RSA/RSA CRT or EC P224, P256, P384, and P521 public key used in the Key Pair Generation service to hold the generated public key. This public key is retrievable by Get Data service. DEMWRAPPUB 2048bit RSA/RSA CRT public key used in the Key Pair Generation service to hold the generated public key. This public key is retrievable by Get Data service. DEM3PPUB 3rd party RSA 1024/2048 bits public key used by Digital Signature Service (for signature verification) and 3rd party RSA2048 bits public key used for wrapping keys in Get Data service. 3rd party ECDSA public keys with EC P192, P224, P256, P384 and P521 used by Digital Signature Service (for signature verification). Table 8: Public Key Copyright KONA I Co., Ltd., 2015 Page 13 of 23 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. Table 9: Roles Supported by the Module lists 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 Demonstration Applet Identitybased Demonstration Applet services. 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). 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. Copyright KONA I Co., Ltd., 2015 Page 14 of 23 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.2 Demonstration Applet Authentication Method The Demonstration Applet uses a predetermined datum (DEMAUTH) 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 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 one minute period is 2^24. Therefore, the probability that a random attempt at authentication will succeed in a oneminute 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 Description CO User Secure Channel Establish and use a secure communications channel (INITIALIZE X UPDATE; EXTERNAL AUTHENTICATE). Context Select an applet or manage logical channels (APDU: SELECT, MANAGE X X 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 Applet operation state, version number and release date (APDU: X GET DATA). Authenticate Demonstration Applet authentication service (using SCP03). X Module Reset Power cycle or reset the Module. Includes PowerOn SelfTest. X Table 10: Unauthenticated Services Service Description CO User 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 Demonstration Applet and CSPs. Update Demo Keys Update DEMAUTH, DEMMAC, DEMKEYWRAP, DEMCONSECRET, X DEM3PPUB key Random Number Demonstrate DRBG/NDRBG and return a random number. X Generation Copyright KONA I Co., Ltd., 2015 Page 15 of 23 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 Description CO User Key Pair Generation Demonstrate 2048 RSA/RSA CRT keypair generation and EC (P224, X P256, P384, and P521) keypair generation. Get Data Demonstrate retrieving CSPs as wrapped form and Public keys as X plain form of the generated keypair by the module. Digital Signature Demonstrate RSA and ECDSA signature generation and signature X verification. Message Demonstrate TripleDES MAC, CMAC, and HMAC. X Authentication Message Digest Demonstrate SHA1 and SHA2. X Confidentiality Demonstrate AES128/192/256 key and 2key Triple DES or 3key X Triple DES encryption and decryption. Key Agreement Demonstrate allowed EC DH with P224, P256, P384 and P521 X curves. Destroy Demo Destroys (Zeroizes) all Demonstration Applet CSPs (APDU INS byte = X Applet CSPs 0xDA). Table 11: Authenticated Services CSPs and Public Keys DEMSHAREDSECRET DEMWRAPSECRET DEMCONSECRET DEMWRAPPUB DEMWRAPPRI OSRNGSTATE DEMSGVPUB DEMKAPPUB OSRNGSEED DEMSGVPRI DEMKAPPRI DEM3PPUB DEMAUTH DEMMAC SDKMAC OSMKEK SDSMAC DAPPUB 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 Applet Info Copyright KONA I Co., Ltd., 2015 Page 16 of 23 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 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 Z 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 E E E W W W W W Update Demo Keys I I I I I G G E E E E Random W W Number Generation I Z Z G G G G G G E E E W W W W W W Key Pair Generation Z Z E E Get Data O O O O O O O E E E E W Digital Signature Copyright KONA I Co., Ltd., 2015 Page 17 of 23 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 E E Message Authenticati on Message Digest E E Confidentiali ty G G G E E E W W W Key O Agreement Z Z E Destroy W W Demo Applet CSPs 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 18 of 23 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 Each time the module is powered up, it tests that the cryptographic algorithms still operate correctly and that sensitive data have not been damaged. Poweron self­tests are available on demand by power cycling the module. The module inhibits all data output via the data output interface while the module is in error state and during selftests. 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 a AES128 bit CTR_DRBG. TripleDES Performs encrypt and decrypt KATs using 3Key TripleDES in ECB mode. TripleDES MAC Performs TripleDES MAC generate and verify KATs using a 3key 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, and SHA384 is tested by the HMACSHA 384 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 Instead of separate Symmetric Key Wrap KATs, TripleDES KATs and AES KATs will take Wrap place. Asymmetric Key Performs RSA encrypt/decrypt KATs using an RSA 2048bit key with SHA256. Wrap NonSP 80056A Selftests as described in FIPS IG 9.9 using EC P224. Compliant ECDH Copyright KONA I Co., Ltd., 2015 Page 19 of 23 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 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 Pairwise Consistency Test performed on every ECDSA key pair generation. The test performs a calculation and a verification of a digital signature. RSA RSA Pairwise 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 Pairwise 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 DAPPUB. Table 14: Conditional SelfTest Copyright KONA I Co., Ltd., 2015 Page 20 of 23 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, 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: 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. Copyright KONA I Co., Ltd., 2015 Page 21 of 23 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 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, the secure channel should be initiated, and the cryptoofficer can initiate the secure channel by authentication. Identity based authentication is used by DemoApplet through GlobalPlatform v2.2 Secure Channel Protocol 3 (SCP03). Selecting and authenticating DemoApplet using an authentication key stored in DEMAUTH key container 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 DemoApplet service by userrole, authentication should be done with GP SCP03 specified in Global Platform Card Specification v2.2 ­ Amendment D. 10 Appendix Physical form factor Figures using KONA N41M0 module Figure 4: KONA I KONA N41M0 ­ plastic body: Physical Form Figure 5: KONA I KONA N41M0 ­ secure SD cards: Physical Form Copyright KONA I Co., Ltd., 2015 Page 22 of 23 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 6: KONA I KONA N41M0 ­ key FOBs: Physical Form Figure 7: KONA I KONA N41M0 ­ USB token: Physical Form Figure 8: KONA I KONA N41M0 ­ (U)SIM: Physical Form Copyright KONA I Co., Ltd., 2015 Page 23 of 23 KONA I Co., Ltd. Public Material ­ may be reproduced only in its original entirety (without revision)