KeyVault Hardware Security Module (kvHSM) Security Policy Document: KeyVault Hardware Security Module Security Policy Version: 2.0 Date: 2023/01/06 Phone: +886-2-29343166 WWW: www.wisecure-tech.com © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 2 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Table of Contents 1. Cryptographic Module Specification................................................................................................ 4 1.1. Module Overview................................................................................................................. 4 1.2. Cryptographic Module Description ...................................................................................... 6 1.3. Mode of Operation............................................................................................................... 7 1.4. Module Information ............................................................................................................. 8 2. Cryptographic Module Ports and Interfaces .................................................................................. 10 2.1. Physical Ports...................................................................................................................... 10 2.2. Logical Interfaces................................................................................................................ 11 3. Roles, Services and Authentication................................................................................................ 13 3.1. Roles ................................................................................................................................... 13 3.2. Concurrent Users................................................................................................................ 14 3.3. Services............................................................................................................................... 14 3.3.1. Services in FIPS Mode of Operation ....................................................................... 14 3.3.2. Services in Non-FIPS Mode of Operation............................................................... 19 3.4. Algorithms .......................................................................................................................... 20 3.4.1. Approved Algorithms.............................................................................................. 20 3.4.2. Non-Approved Algorithms...................................................................................... 22 3.5. Identification and Authentication ...................................................................................... 22 3.5.1. Token-Based Authentication .................................................................................. 23 3.5.2. ID/Password Authentication .................................................................................. 23 3.6. Authentication Strength..................................................................................................... 24 4. Physical Security............................................................................................................................. 26 4.1. Static Protection ................................................................................................................. 26 4.2. Dynamic Protection............................................................................................................ 26 5. Operational Environment............................................................................................................... 28 5.1. Applicability........................................................................................................................ 28 6. Cryptographic Key Management.................................................................................................... 29 6.1. Random Number Generation............................................................................................. 32 6.2. Key Generation................................................................................................................... 32 6.3. Key Agreement (Establishment)......................................................................................... 33 6.4. Key Transport (Establishment)............................................................................................ 33 6.5. Key Entry and Output ......................................................................................................... 33 6.6. Split Knowledge Procedure ................................................................................................ 34 6.7. Key / CSP Storage................................................................................................................ 34 6.8. Key / CSP Zeroization.......................................................................................................... 34 7. EMI/EMC......................................................................................................................................... 36 8. Self-Tests......................................................................................................................................... 37 8.1. Power-Up Self-Tests............................................................................................................ 37 8.1.1. Integrity Tests ......................................................................................................... 37 3 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 8.1.2. Cryptographic Algorithm Tests ............................................................................... 37 8.2. On-Demand Self-Tests ........................................................................................................ 38 8.3. Conditional Self-Tests ......................................................................................................... 38 9. Guidance......................................................................................................................................... 40 9.1. Initialization........................................................................................................................ 40 9.2. USB Tokens ......................................................................................................................... 41 10. Mitigation of Other Attacks.................................................................................................... 42 11. Security Rules ......................................................................................................................... 43 12. References.............................................................................................................................. 44 13. Definitions and Acronyms ...................................................................................................... 45 4 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 1. Cryptographic Module Specification This document is the non-proprietary FIPS 140-2 Security Policy for the cryptographic module “KeyVault Hardware Security Module (kvHSM)” (hereafter referred to as “kvHSM”). The module contains the security rules under which the module must be operated and describes how this module meets the requirements as specified in FIPS PUB 140-2 (Federal Information Processing Standards Publication 140-2) for a Security Level 3 module. The following sections describe the cryptographic module and how it conforms to the FIPS 140-2 specification in each of the required areas. 1.1. Module Overview The module is a hardware security module made by WiSECURE Technologies. The module is a PCIe card that stores and manages cryptographic keys as a vault. It manages the entire lifecycle of keys, including generation, distribution, storage, destruction and archiving, and provides data encryption, data decryption, signature generation, signature verification, message digest, message authentication code (MAC), random number generation and key management services. The module provides a robust environment for cryptographic operations. It is designed in reaction to compromising, physical intrusion, and tampering. The module is carefully designed to mitigate risks of key leakage and dismisses the threat posed by side channel attack (SCA). The host application connects to the module through PCIe interface. The host identifies and authenticates against the module. Once authentication succeeds, the host requests cryptographic services to the module, which processes the requests and sends back the result. In addition, administrators of the module can access the management functions after authenticated with admin USB tokens. The overall architecture is shown in Figure 1. 5 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Figure 1 – Overall architecture The module are defined as multi-chip embedded cryptographic modules as defined by FIPS 140-2. It meets overall FIPS 140-2 Level 3 requirement in FIPS mode and support major algorithms needed by the modern crypto-based applications. The physical dimensions of the module are 167 mm x 68.9 mm x 16.5 mm (width x height x depth), as shown in Figure 2. Figure 2 – Front view 6 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Figure 3 – Back view The module provides a hardened, tamper-resistant environment. The module is covered with an aluminum enclosure. It covers all the major components and tamper response circuits that can detect the open event of the enclosure. 1.2. Cryptographic Module Description For the purpose of the FIPS 140-2 validation, the module is a multi-chip embedded hardware cryptographic module validated at an overall Security Level 3. The table below shows the security level claimed for each of the eleven sections that comprise the FIPS 140-2 standard: FIPS 140-2 Section Security Level 1 Cryptographic Module Specification 3 2 Cryptographic Module Ports and Interfaces 3 3 Roles, Services and Authentication 3 4 Finite State Model 3 5 Physical Security 3 6 Operational Environment N/A 7 Cryptographic Key Management 3 8 EMI/EMC 3 9 Self-Tests 3 10 Design Assurance 3 11 Mitigation of Other Attacks 3 Overall Level 3 Table 1 – Security levels The module is covered by aluminum enclosure, and the bottom side covered by epoxy material as shown in Figure 3. The physical boundary of the module is defined as the whole PCIe card, and the security boundary is red marked as shown in Figure 4. 7 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Figure 4 – Security boundary The block diagram of the module is shown as Figure 5. It contains the FPGA, Controller, Secure Element, DDR3, SPI Flash, Battery-Backup SRAM, Photodiode, Detect Switch and Battery. The crypto engines are implemented in FPGA and in Secure Element. The Keys and CSP are stored in Secure Element and encrypted by the Local Master Key (LMK). The LMK is kept in the Battery-backup SRAM which will be zeroized by the enclosure open event. Figure 5 – Block diagram 1.3. Mode of Operation The module supports two modes of operation.  In "FIPS mode", (the Approved mode of operation) only approved or allowed security functions with enough security strength can be used. The FIPS mode of operation is implicitly assumed when a administrator initializes the module for the first time.  In "non-FIPS mode", (the non-Approved mode of operation) non-approved security functions can be used in addition to the security functions allowed in FIPS mode. Once the module is operational, Administrator can check the mode in kvConsole/Setup. The kvConsole is the external utility for operator to communicate and manage the module. It is out of module boundary and is not part of the validation. The kvConsole UI will display the mode of 8 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. operation of the module. Figure 6 – Check FIPS mode Administrator can change the mode by clicking the “Change the FIPS compliance” button and follow the steps. Figure 7 – Set FIPS mode When a new mode of operation is selected by the operator, the module zeroizes the LMK, erases other encrypted CSPs, and requires a new initialization. This mechanism ensures that CSPs used in FIPS mode of operation cannot be used in non-FIPS mode, and vice versa. When the module is running in FIPS mode of operation, the module enforces that only service requests for approved cryptographic services, algorithms and key sizes are allowed. 1.4. Module Information  Vendor: WiSECURE Technologies  Product Name: kvHSM 9 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice.  Module Name: KeyVault Hardware Security Module (kvHSM)  Hardware Version: KV-HSM_V02  Firmware Version: v1.00.0000 10 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 2. Cryptographic Module Ports and Interfaces 2.1. Physical Ports Figure 8 shows the physical ports of the module. The module provides PCIe Gen2x8 physical interface. It provides the power source for the module and communication channel with the PCIe host. The USB host can be used to access the LMK token for key backup and restore. An RGB Status LED light indicates activity and status information of the module. The Erase Button can trigger the module to zeroize or restore the factory default configuration. Figure 8 – Physical ports The table below summarizes the physical ports. Physical Ports Pins Used FIPS 140-2 Designation Name and Description USB Host Interface USB Interface USB0_DP, USB0_DM Data Output Data Input The USB can also be used to access the LMK token for key backup and restore. PCIe Gen2x8 Interface PCIe Interface Lane 0 Transmit Side B (14, 15) Receive Side A (16, 17) Lane 1 Transmit Side B (19, 20) Receive Side A (21, 22) Lane 2 Transmit Side B (23, 24) Receive Side A (25, 26) Lane 3 Transmit Side B (27, 28) Receive Side A (29, 30) Data Input Control Input Data Output Status Output Power The module provide PCIe Gen2x8 physical interface. This interface provides the power source for the module and communication with the host. 11 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Physical Ports Pins Used FIPS 140-2 Designation Name and Description Lane 4 Transmit Side B (33, 34) Receive Side A (35, 36) Lane 5 Transmit Side B (37, 38) Receive Side A (39, 40) Lane 6 Transmit Side B (41, 42) Receive Side A (43, 44) Lane 7 Transmit Side B (45, 46) Receive Side A (47, 48) Status LED RGB LED Interface Status Output The R-G-B status LED can indicate the status of the module, including Self- Testing (Green), Initialize (Green), Normal Status (Blue) and Error (Red). Erase Button Erase pin GPIO Control Input The Erase Button can trigger the board to zeroize the battery-backup SRAM credential and proceed the parameter erasing process when power is supplied. Long-press of the button will cause the module to restore the factory default configuration. Table 2 – Physical ports 2.2. Logical Interfaces The following table summarizes the four logical interfaces and the mapping to the physical ports. Logical Interfaces Physical Ports Description Data Input USB Host LMK restore with LMK token PCIe Plaintext data from the host PCIe Ciphertext or signed data from the host PCIe Imported keys from the host Data Output USB Host LMK backup with LMK token PCIe Ciphertext or digital signatures to the host PCIe Exported keys to the host PCIe Management data to the host 12 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Logical Interfaces Physical Ports Description PCIe Device or control information to the host Control Input Erase Button Trigger Zeroization PCIe Management and Zeroization command from the host Status Output Status LED Module status PCIe Status request from the host Power Input PCIe N/A Table 3 – Logical Interfaces and their mapping with physical ports Figure 9 indicates the logical interfaces mapping with physical ports. Figure 9 – Logical interfaces 13 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 3. Roles, Services and Authentication This section defines the roles, services and authentication mechanisms with respect to the applicable FIPS 140-2 requirements. The module implements identity-based authentication to authenticate the user and verify that the user is authorized to assume the assigned role. For those services that require identification and authentication, the module verifies that the user has the proper role to perform the service. 3.1. Roles The module supports 4 roles: Administrator, Operator, Auditor and Application. The first 3 roles are crypto-officer roles and can be assigned to users of the module (user) that perform management operations. The Application role is a user role assigned to external entities (application) that connect to the module through the middleware request cryptographic services. A user can be assigned to only one fixed role: Administrator, Operator or Auditor. After the user is identified and authenticated to the module, the associated role is automatically assigned to the user. When the module is initialized the first time, as there are no users provided by default, the Administrator is assigned to the user that accesses the module while the module is initialized. The Application role is adopted implicitly by the external entities (applications) after they are identified and authenticated by the module and before requesting cryptographic services. The following table describes the authorized roles and the services they can perform. Notice that there are some services that do not require an authorized role. Role Description FIPS Roles Administrator (ADM) This role is assigned when a user with this role is authenticated successfully by the module. The module supports three users with this role. The administrator role (ADM) can perform key management (delete asymmetric and symmetric keys) and user management (add and delete users). Also, the Administrator can perform management services authorized to the Operator role. Crypto Officer Operator (OP) This role is assigned when a user with this role is authenticated successfully by the module. The module supports only one user with this role. The operator role (OP) can perform system management and key management. Crypto Officer Auditor (AUD) This role is assigned when a user with this role is authenticated successfully by the module. The module supports only one user with this role. The auditor role (AUD) Crypto Officer 14 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Role Description FIPS Roles can perform only audit management services (view management logs). Application (APP) This role is assigned when an external entity (application) is authenticated successfully by the module via middleware. The Application role can request cryptographic services to the module. User Table 4 – Roles 3.2. Concurrent Users The module supports concurrent users (including administrators and applications). The user requests session from the module and login with the session. The module maintains the session during the operation and close the session when user logout or timeout. Each login session is bounded to the user and is limited to the functions and keys permit to the user. 3.3. Services The module provides two types of services: management services and cryptographic server services. Management services include all services that can be executed from the management program by users of the module with the Administrator, Operator and Auditor roles. These services are classified into the following groups:  Module Management  Authority Management  Key Management  Backup and Recovery  Application Management Cryptographic server services are provided to applications that authenticates to the module through middleware.  Authentication services  Symmetric key services  Asymmetric key services  Other services 3.3.1. Services in FIPS Mode of Operation Table 5 below shows the functions that can be requested in FIPS mode of operation, including the cryptographic algorithms involved, the authorized roles that can execute them, and the required 15 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. access to keys and CSPs. Services that do not require an authorized role are marked as “N/A” (not applicable). Service Description Roles Key/CSP Access N/A ADM OP AUD APP Card Management Get HSM SN Get HSM SN * * * * Get HSM Publickey Get HSM Publickey * * * * Get Default CO Publickey Get Default CO Publickey * * * * Get FIPS mode Get FIPS mode * * * * Set FIPS mode Set the FIPS mode or Non-FIPS mode * * All Keys/CSPs Delete Erase LMK Erase the LMK * * LMK Delete Self-Test Run self-test process * * * SetTime Set time * * Get HSM status Get HSM overall status * * * * LMK and PSD Management Generate LMK Generate the LMK * * LMK Write Recover LMK Restore the LMK * * LMK Write Add PSD Create the PSD of the module * * SDMK SDMACK Write Write Init PSD SP Init the security policy of the PSD * * Add PSD Admin Add the admin to the security domain by PSD admin * ADM’s Public Key Write Session and Login/Logout Open Session Open a login session * * * * * Close Session Close a login session * * * * Query Session Query Session status * * * * Get Challenge Get challenge to login * * * * CoToken Login Login by CO Token, signed the challenge by token private key * CO’s Public Key Read CoPw Login Login by CO password * * CO Password Read UserPw Login Login by Application password * Application Password Read 16 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Logout Logout current user * * * * Security Domain Management List SD Get the list of security domains * * * Query SD Info Query the SD Information * * * Init SD Security Policy Set the security policy of the security domain including minimum admin required to login and maximum pin trial before lock * Update SD Security Policy Update the security policy of the security domain. * Add SD Create a security domain by PSD admin * SDMK SDMACK Write Remove SD Remove a security domain by PSD admin * SDMK SDMACK Write Backup SD Backup a security domain by PSD admin * LMK Read Restore SD Restore a security domain by PSD admin * LMK Read Administrator Management Add Admin Add other admin(s) * New Admin’s Public Key Write Remove Admin Remove an admin * New Admin’s Public Key Write List Admin Get admin list * Query Admin Info Get admin info * Admin’s Public Key Read Add Operator (Token-Based) Add token-based operator * OP’s Public Key Write Add Operator (ID/Password) Add id-password based operator * OP’s Password Write 17 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Remove Operator Remove operator * OP’s Public Key and Password Write Set Operator Password Set operator’s password by admin * OP’s Password Write Change Operator Password Change operator’s password by operator * OP’s Password Write List Operator Get operator List * Query Operator Info Get operator Info * * Add Auditor (Token-Based) Add token-based auditor * AUD’s Public Key Write Add Auditor (ID/Password) Add id-password based auditor * AUD’s Password Write Remove Auditor Remove auditor * AUD’s Public Key and Password Write Set Auditor Password Set auditor’s password by admin * AUD’s Password Write Change Auditor Password Change auditor’s password by auditor * AUD’s Password Write List Auditor Get auditor List * Query Auditor Info Get auditor Info * * Application Management Add Application Add application * Application’s Password Write Remove Application Remove application * Application’s Password Write Set Application Password Set application password by admin * Application’s Password Write Change Application Password Change application password by application * Application’s Password Write List Application Get application List * Query Application Info Get application Info * * Key Management Gen Key Generate keys for user * * User Key Write Remove Key Remove a key * * User Key Write List Key Get key List * * User Key Read 18 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Query Key Info Get key Info * * * User Key Read Update Key Status Update the key status: active / inactive * * User Key Write Update Key User Update the user of the key * * User Key Write Import Key Import key from an encrypted keyblob * * User Key TK Write Read Export Key Export key as an encrypted keyblob * * User Key TK Read Read Backup Key Backup key as an encrypted keyblob * * User Key SDMK Read Restore Key Restore key from an encrypted keyblob * * User Key SDMK Write Read Output Key (Init/Update/Final) Split the key into shares and output * * User Key Read Entry Key (Init/Update/Final) Restore the key from shares * * User Key Write Log Management Query Log Info Query Log Info * * Table 5 – Management services in FIPS mode of operation Table below shows the cryptographic services that can be requested in FIPS mode of operation, the involved cryptographic algorithms and the access required to keys and CSPs. All services, except for “Application Authentication”, require the Application role in order to be executed. This role is obtained after the external entity authenticates successfully to the module (using the “Application Authentication” service). Service Algorithms Key/CSP Access Authentication Service Application Authentication DRBG, SHA2-256 Application Password Read Symmetric Key Services Key Generation AES AES Key Create Data Encryption AES in ECB, CBC, OFB, CFB 126, CTR, modes AES Key Read Data Decryption AES in ECB, CBC, OFB, CFB 126, CTR modes AES Key Read AES GCM Data Encryption AES in GCM mod AES Key Read AES GCM Data Decryption AES in GCM mod AES Key Read 19 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. AES XTS Data Encryption AES in XTS mod AES Key Read AES XTS Data Decryption AES in XTS mod AES Key Read HMAC Generation HMAC with SHA2-256, SHA2-384, SHA2-512, SHA3-256, SHA3-384, SHA3-512 HMAC Key Read Asymmetric Key Services ECDSA Key Pair Generation DRBG, ECDSA ECDSA Private Key Create ECDSA Public Key Export ECDSA None N/A ECDSA Digital Signature Generation ECDSA ECDSA Private Key Read ECDSA Digital Signature Verification ECDSA None N/A RSA Public Key Export RSA 2048, RSA 4096 None N/A RSA Digital Signature Generation RSA 2048, RSA 4096 RSA Private Key Read RSA Digital Signature Verification RSA 2048, RSA 4096 None N/A Other Services Derive Key EC Diffie-Hellman ECC Private Key Read Message Digest SHA2-256, SHA2-384, SHA2-512, SHA3-256, SHA3-384, SHA3-512 SHAKE128, SHAKE256 None N/A Random Number Generation Hash_DRBG with SHA-256 Entropy Input String, Internal State Read Update Get FIPS status None N/A Get HSM status None N/A Table 6 – Cryptographic services in FIPS mode of operation 3.3.2. Services in Non-FIPS Mode of Operation Table below shows the cryptographic services that can be requested in non-FIPS mode of operation, the involved cryptographic algorithms and the access required to keys. Each service indicates the service ID within parentheses. All services require the Application role in order to be executed. This role is obtained after the external entity is authenticated successfully by the module (using the “Application Authentication” service). Service Standard Key Len / Curves Usage ECDSA Secp256k1 [ECCSEC2] Secp256k1 Digital signature ECC brainpool [ECCBP] P-256 Digital signature Table 7 – Cryptographic services in Non-FIPS mode of operation 20 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 3.4. Algorithms The module implements cryptographic algorithms in two separated components:  WiSECURE Cryptographic Library (version 1.0), a firmware component that implements general purpose cryptographic algorithms used for cryptographic services and internal usage (AES for key protection and ECC Signature Verification for user authentication). CAVP: C1435 and A665.  WiSECURE Cryptographic Hardware-Accelerated Library (version 1.0), an FPGA component that implements algorithms for high-speed cryptographic services. CAVP: C1706 and A1169. 3.4.1. Approved Algorithms The algorithms implemented in the module that are approved to be used in FIPS mode of operation are tested and validated by the CAVP. The following tables show the cryptographic algorithms that are approved and allowed in FIPS mode of operation. CAVP Cert Algorithm Standard Mode/Method Key Len / Curves Usage C1435 AES [FIPS 197] [SP 800-38A] ECB, CBC, OFB, CFB 128, CTR 128, 192, 256 Data Encryption C1435 AES-GCM [SP 800-38D] GCM 256 Data Encryption C1435 AES-XTS [SP 800-38E] XTS 256 Data Encryption, Only used for storage C1435 DRBG [SP 800-90A] Hash DRBG (SHA- 256) 256 Random Number Generation N/A ENT (P) [SP 800-90B] Provide entropy input to the approved DRBG. C1435 ECDSA KeyGen [FIPS 186-4] P-256/P-384/P-521 Key Generation C1435 ECDSA KeyVer [FIPS 186-4] P-256/P-384/P-521 Key Verification C1435 ECDSA SigGen [FIPS 186-4] SHA2-256/384/512 P-256/P-384/P-521 Signature Generation C1435 ECDSA SigVer [FIPS 186-4] SHA2-256/384/512 P-256/P-384/P-521 Signature Verification C1435 HMAC [FIPS 198-1] SHA2-256/384/512 SHA3-256/384/512 Message Authentication C1435 SHS [FIPS 180-4] 256/384/512 Message Digest C1435 SHA-3 [FIPS 202] 224/256/384/512 Message Digest 21 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. SHAKE128/256 C1706 AES [FIPS 197] ECB, CTR 256 Data Encryption C1706 AES [SP 800-38E] XTS 256 Data Encryption, Only used for storage C1706 ECDSA KeyGen [FIPS 186-4] P-256 Key Generation C1706 ECDSA SigGen [FIPS 186-4] SHA2-256 P-256 Signature Generation C1706 ECDSA SigVer [FIPS 186-4] SHA2-256 P-256 Signature Verification C1706 RSA KeyGen [FIPS 186-4] 2048 Key Generation C1706 RSA SigGen [FIPS 186-4] X9.31/PKCS#1.5/PSS SHA2-256 2048 Signature Generation C1706 RSA SigVer [FIPS 186-2] X9.31/PKCS#1.5/PSS SHA2-256 4096 Signature Generation C1706 RSA SigVer [FIPS 186-4] X9.31/PKCS#1.5/PSS SHA2-256 2048 Signature Verification A665 AES-GCM [SP 800-38D] 128, 192, 256 Data Encryption A665 AES-XTS [SP 800-38E] 128, 256 Data Encryption. Only used for storage A665 KAS-ECC-SSC [SP 800-56A] (Cofactor) Ephemeral Unified Model, C(2e, 0s, ECC CDH) scheme P-256/P-384/P-521 Key Agreement A665 KDA [SP 800-56C] HKDF 256 Key Agreement N/A KAS KAS-ECC-SSC Cert. #A665 and KDA Cert. #A665 Key Agreement N/A KTS AES Cert. #C1435 and HMAC Cert. #C1435; key establishment methodology provides 256 bits of encryption strength. Key Transport A665 KBKDF [SP 800-108] Counter 256/384/512 Key Derivation Feedback 256/384/512 Key Derivation Double Pipeline Iteration 256/384/512 Key Derivation A1169 RSA KeyGen [FIPS 186-4] SHA2-256 4096 Key Generation A1169 RSA SigGen [FIPS 186-4] SHA2-256 4096 Signature Generation Vendor CKG [SP 800-133]  Key Pairs generation using unmodified DRBG output for Digital 22 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Affirmed Signature Schemes  Key Pairs generation using unmodified DRBG output for Key Establishment  The “Direct Generation” of Symmetric Keys generation using unmodified DRBG output  Symmetric Keys Generated Using Key-Agreement Schemes  Distributing Symmetric Keys using key wrapping Table 8 – Approved algorithms There are algorithms, modes, and keys that have been CAVP tested but not used by the module. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in this table are used by the module. Some algorithms (AES, RSA and ECDSA) has FPGA implementations that provide high-speed cryptographic services. Those services can be used with imported wrapped keys and session keys derived from key agreement service. For AES GCM encryption, the IV is generated internally by the module’s Approved DRBG. The DRBG seed is generated inside the module’s physical boundary. The IV is 96 bits in length per [SP 800-38D], Section 8.2.2 and FIPS 140-2 [IG] A.5 scenario 2. In case the module’s power is lost and then restored, the key used for AES GCM encryption or decryption shall be re-distributed. When a GCM IV is used for decryption, the responsibility for the IV generation lies with the party that performs the AES-GCM encryption therefore there is no restriction on the IV generation. 3.4.2. Non-Approved Algorithms The table below shows the algorithms that are not approved in FIPS mode of operation. Algorithm Standard Usage ECDSA [ECCSEC2]: Secp256k1 Digital signature ECDSA [ECCBP]: Brainpool 256 Digital signature Table 9 – Non-Approved algorithms 3.5. Identification and Authentication The module uses identity-based authentication to identify and authenticate users and applications in the module:  Token-based authentication: For Administrator, Operator or Auditor roles, it can apply the Token 23 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. -based authentication. It is performed using a challenge-response mechanism with the user’s credentials (a 256-bit ECC key pair) stored in the user’s USB token.  ID/Password authentication: For Operator, Auditor and Application roles, it can apply the ID/Password-based authentication. It verifies the user’s credential stored in the module. Roles FIPS Roles Type of Authentication Authentication Data Administrator Crypto Officer Token-Based Public and Private Key Operator with Token Crypto Officer Token-Based Public and Private Key Auditor with Token Crypto Officer Token-Based Public and Private Key Operator with ID/Password Crypto Officer ID/Password ID/Password Auditor with ID/Password Crypto Officer ID/Password ID/Password Application User ID/Password ID/Password Table 10 – Roles and authentication mechanisms 3.5.1. Token-Based Authentication When a new user of the module is added, the module then asks for the insertion of the new user’s USB token, imports and stores the user’s ECC public key together with the ID and the associated role of the user. The module identifies and authenticates users of the module through the following steps: 1. The user asked for token-based login through kvConsole 2. The module generates a challenge consisting of a 256-bit random number 3. The user inserts the Admin Token into the USB port, and enters the PIN through the kvConsole 4. The Admin Token authenticates with the PIN provided by the user. 5. The Admin Token generates a digital signature of the challenge as response. (using the user’s ECC private key stored in the Admin Token) 6. The kvConsole ask for further tokens to process step 3-5 according to the security policy. 7. The kvConsole sends the response(s) to the module for login 8. The module verifies the signature(s) with the users’ public key(s) (stored in the module) If authentication succeeds, the user adopts the role assigned during its creation. A user remains authenticated until the user logs out from the module or the module is powered off (no authentication data remains in the module). 3.5.2. ID/Password Authentication Administrator can set the Operator and Auditor Role with ID and password to the module. The module identifies and authenticates users of the module through the following steps: 24 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 1. User enters the ID and Password through the kvConsole. 2. The kvConsole gets a challenge from module 3. The kvConsole calculate the user ECC private key from password (SHA256(password)) 4. The kvConsole calculate the response as ECDSA of the SHA256(challenge) with user ECC private key 5. The kvConsole send the user ID and response to module to login 6. The module verifies the response by user’s public key, which is calculate from user’s password stored inside the module. If the signature verified success, then authentication succeeds, the user adopts the role assigned during its creation. A user remains authenticated until the user logs out from the module or the module is powered off (no authentication data remains in the module). 3.6. Authentication Strength There are 2 types of user authentication mechanism.  Token-based authentication: The Token-based authentication mechanism can be applied to administrator, operator and auditor. It uses a 256-bit ECC key pair. According to [SP 800-57A], such a key provides a security strength of 128 bits. Therefore, the probability of a successful authentication by guessing the private key, using a USB token with a non-registered user’s credential, is 2-128 ≈ 10-38, which is far less than the maximum probability of 10-6 required by the FIPS 140-2 standard. For the token-based authentication it requires user to plug in token manually. It assumes user can perform a maximum 100 attempts in one minute, the total probability of guessing the credentials is 2.93 x 10-39 x100 = 2.93*10-37. This number is still far less than one in 100,000.  ID/Password authentication: The ID/Password authentication mechanism can be applied to operator, auditor and user application. It requires the length of password to be 8 characters at least, and it limits the maximum trial time of authentication. The module will locked if the fail-trial exceed the maximum trials and it will require the administrator to unlock for further usage. Considering a minimum alphabet of 36 symbols (numbers and alphabetic characters), the password still yields 368 ≈ 1012 possible combinations. In this case, the probability of success of random attempts is close to 10-12. This number is less than the maximum probability of 10-6 required by the FIPS 140-2 standard. For the ID/Password authentication, the Module will be locked if password fail-trial exceed the maximum trial, say 255 times. In this case the successful random attempt during one minute is 25 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 3.54 x 10-13 x 255 = 9.03 x 10-11, which is less than one in 100,000. 26 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 4. Physical Security This section describes the physical security mechanisms that the module employs in order to restrict unauthorized physical access to the contents of the module and to deter unauthorized use or modification of the module. 4.1. Static Protection The module is covered with an aluminum cover. It covers all the major components and tamper response circuits that can detect the event of the disclosure of enclosure. On the bottom side of the PCB a metal frame is attached directly onto the printed circuit board, and the space inside the metal frame is filled by hard and opaque potting material which show evidence of tampering on the enclosure when a physical attack is attempted. One tamper-evident seal is pre-installed (at factory) as shown on the Figure 10 with red circle. The tamper-evident seal covers joint seam and a screw on the middle of back side. The aluminum cover cannot be removed or displaced without removing the screw covered by the tamper-evident seal. The tamper-evident seal cannot be penetrated or removed and reapplied without evidence of tampering. The tamper-evident seal shall be installed for the module to operate in the Approved mode of operation. Figure 10 – Tamper-evident seal 4.2. Dynamic Protection During the operation of the module, keys and CSPs are stored in plaintext into the volatile memory. In order to prevent the disclosure of such sensitive information, the module with tamper-evident 27 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. enclosure (the heat sink and the potting material) implements the following physical security mechanisms:  The module implements a tamper response and zeroization circuitry which will be activated while the cover is removed.  The cryptographic module’s hardware components are covered by hard, opaque potting material or the heat sink which show evidence of tampering on the enclosure when a physical attack is attempted.  The potting material is hard and opaque enough to prevent direct observation and easy penetration to the depth of the underlying hardware components. It is highly probable that anyone attempting to penetrate to the depth of the circuitry will break off large pieces of potting material and tear important hardware components off the module, causing serious damage to the module. Users should check the tamper-evident seal and status LED periodically to maintain the physical security. 28 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 5. Operational Environment 5.1. Applicability The module operates in a non-modifiable operational environment. Once the firmware of the module is loaded, it cannot be modified or erased. Therefore, FIPS 140-2 requirements for the operational environment are not applicable to the module. 29 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 6. Cryptographic Key Management The following table summarizes the keys and CSPs that are used by the cryptographic services implemented in the module: Name Key Size / Curve Purpose Generation Entry and Output Storage Zeroization LMK AES-256 Key 256 bits Protect each SD MK During initialization, [SP 800-133]. (unmodified output from the approved DRBG) Input from LMK Tokens (split knowledge) Output to LMK tokens (split knowledge) Battery- Backup SRAM When Erase Event Triggered SD MK AES-256 Key 256 bits Protect each Keys and CSPs stored in the SD During SD initialization, [SP 800-133]. (unmodified output from the approved DRBG) Input and output as service requests (key wrapping) SLE97 Flash Encrypted by LMK Protected by SD MAC key Erased when SD deleted SD MAC Key HMAC 256 bits Protect each Keys and CSPs integrity During SD initialization, KBKDF from SD MK N/A SLE97 Flash Encrypted by LMK Erased when SD deleted Administrator ECC Public Key P-256 Identity- based Authenticati on None (Generated by USB Token) ECC Public Key is input from the USB token SLE97 Flash In Plaintext Form Protected by SD MAC key Erased when user deleted or initialized Operator ECC Public Key P-256 Identity- based authenticatio n None (Generated by USB Token) ECC Public Key is input from the USB token SLE97 Flash In Plaintext Form Protected by SD MAC key Erased when user deleted or initialized Auditor ECC Public Key P-256 Identity- based authenticatio n None (Generated by USB Token) ECC Public Key is input from the USB token SLE97 Flash In Plaintext Form Protected Erased when user deleted or initialized 30 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Name Key Size / Curve Purpose Generation Entry and Output Storage Zeroization by SD MAC key Operator Password 8 bytes min. Identity- based authenticatio n N/A Input from kvConsole SLE97 Flash Encrypted by SD MK Protected by SD MAC key Erased when user delete or initialized Auditor Password Identity- based authenticatio n N/A Input from kvConsole SLE97 Flash Encrypted by SD MK Protected by SD MAC key Erased when user delete or initialized User AES Keys 256 bits Encrypt/Decr ypt data Generated using [SP 800- 133]. (unmodified output from the approved DRBG) Input and output as service requests (wrapped key) SLE97 Flash Encrypted by SD MK Protected by SD MAC key Management Services User KEK 256 bits Encrypt/Decr ypt user key Generated using [SP 800- 133]. (unmodified output from the approved DRBG) Input from TK Tokens (split knowledge) Output to TK tokens (split knowledge) SLE97 Flash Encrypted by SD MK Protected by SD MAC key Management Services User MAC Key 256 bits Protect Wrapped Key Integrity KBKDF from User KEK N/A N/A (in RAM only) Erased when no longer used. User ECDSA Public Keys P-256 P-384 P-521 Digital Signature Verification Generated from ECDSA private key Input and output as service requests SLE97 Flash Protect by SD MAC key Management Services User ECDSA Private Keys P-256 P-384 P-521 Digital Signature Generation Generated using [SP 800- 133]. (unmodified output from Input and output as service requests (wrapped key) SLE97 Flash Encrypted by SD MK Protected by SD MAC Management Services 31 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Name Key Size / Curve Purpose Generation Entry and Output Storage Zeroization the approved DRBG) key User EC Diffie- Hellman Public Keys P-256 P-384 P-521 Key Agreement Generated from EC Diffie- Hellman private key Input and output as service requests SLE97 Flash Protect by SD MAC key Management Services User EC Diffie- Hellman Private Keys P-256 P-384 P-521 Key Agreement Generated using [SP 800- 133]. (unmodified output from the approved DRBG) Input and output as service requests (wrapped key) SLE97 Flash Encrypted by SD MK Protected by SD MAC key Management Services EC Diffie- Hellman Share Secret 256 bits Derive Secure Channel Session Key Established during EC Diffie-Hellman Exchange N/A N/A (in RAM only) Erased when no longer used. Secure Channel Session Key 256 bits Protect Channel Payload KAS from EC Diffie-Hellman Share Secret N/A N/A (in RAM only) Erased when no longer used. User RSA Public Keys 2048 bits 4096 bits Digital Signature Verification N/A Input and output as service requests SLE97 Flash Protect by SD MAC key Management Services User RSA Private Keys 2048 bits 4096 bits Digital Signature Generation N/A Input and output as service requests (wrapped key) SLE97 Flash Encrypted by SD MK Protected by SD MAC key Management Services Application Password 8 bytes min Identity- based Authenticati on of Application N/A Input by user with Administrator from kvConsole. SLE97 Flash Encrypted by SD MK Protected by SD MAC key Erased when user delete or initialized Entropy Input Entropy for DRBG Obtained from ENT (P) None N/A (in RAM only) Erased when no longer used. DRBG DRBG During DRBG N/A N/A (in Erased when 32 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Name Key Size / Curve Purpose Generation Entry and Output Storage Zeroization Internal State (V&C) Internal State Initialization RAM only) DRBG is no longer used. Table 11 – Lifecycle of keys and CSPs 6.1. Random Number Generation The module employs a Deterministic Random Bit Generator (DRBG) compliant to [SP 800-90A] for the creation of symmetric and asymmetric keys, creation of random number challenges for the identity- based authentication mechanism, and processing of the Random Number Generation service request. The DRBG supports the Hash_DRBG mechanisms. The DRBG is initialized during module initialization; the module loads by default the DRBG using the Hash_DRBG mechanism with SHA-256. For seeding the DRBG, the module uses a non-deterministic Random Number Generator (NDRNG) which is a SP 800-90B compliant physical entropy source, i.e., ENT (P). The ENT (P) is provided by FPGA implementation within the boundary. The ENT (P) provides around 0.64 bits entropy per byte. During initialization (seed) and reseeding (reseed) process, we feed DRBG by 768 bits of ENT (P) as entropy input; more specifically, using the terminology from [SP 800-90A], the 768 bits of ENT (P) is divided into 512 bits of entropy input and 256 bits of nonce of Hash_DRBG, with personalization string being empty. Since the ENT (P) provides around 0.64 bits entropy per byte, the 768 bits entropy input contains larger entropy than 256 bits, that is, larger than the security strength of Hash_DRBG SHA-256 algorithm (0.64 x 512 > 256). 6.2. Key Generation The module performs symmetric and asymmetric key generation for cryptographic service requests, key management services, and for key and CSP protection. AES symmetric keys are obtained using unmodified output from the approved DRBG. Keys are generated using random data from the [SP 800-90A] DRBG following the [SP 800-133]. ECDSA key pairs are generated in compliance with [FIPS186-4] and using the [SP 800-90A] DRBG and follow the [SP 800-133]. The LMK is an AES symmetric key and the value is split into 3 key components (shares) according to Shamir's Secret Sharing with threshold 2. Each share is stored in LMK token and any 2 of the 3 shares can reconstruct the original LMK. 33 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. The [SP 800-108] KBKDF is used to generate SD MAC Key, User MAC key, Secure Channel Session Key, and for key derivation service. 6.3. Key Agreement (Establishment) The module provides the following key agreement scheme to establish a key between two parties. Each party contribute info to construct the key.  EC Diffie-Hellman (key agreement; key establishment methodology provides 128 / 192 / 256 bits of encryption strength). It utilizes ECC with Curve P-256 / P-384 / P-521 for the 128 / 192 / 256 bits AES key agreement respectively. EC Diffie-Hellman is applicable for which scenario X1 (2) of [IG] D.8 Key Agreement Methods. The session key is derived by HKDF key derivation function documented in Section 5.1 of [SP 800-56C]. The usage of the key agreement includes:  Generate secret session key of the trusted path between the API and the module.  Provide key agreement service. 6.4. Key Transport (Establishment) The module protects keys whenever they are input to or output from the module. The module implements the following key transport mechanisms:  Key wrapping is used for protecting keys that are part of cryptographic service request or response messages. The module uses AES in CBC mode and HMAC-SHA-256 algorithms. The certificate is KTS (AES Cert. #C1435 and HMAC Cert. #C1435; key establishment methodology provides 256 bits of encryption strength). According to “Table 2: Comparable strengths” in [SP 800-57], the key sizes of AES provide the following security strength:  AES HMAC-SHA-256 key wrapping provides 256 bits of encryption strength. 6.5. Key Entry and Output The module supports electronic distribution of keys in encrypted form. The module does not enter or output keys in plaintext format outside its physical boundary. Cryptographic services requested by external entities may involve input of keys in the request message (e.g. data encryption or decryption, signature generation, HMAC) or output of keys in the response message (e.g. key generation). The module uses key wrapping with AES and HMAC-SHA-256 34 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. as the key transport mechanism, using one of the keys stored in the module. LMK can be input from or output to external LMK tokens through the key management services. The keys are input or output in split key component form based on Shamir’s Secret Sharing algorithm. 6.6. Split Knowledge Procedure The module uses the split knowledge procedure for entry and output of the Local Master Key (LMK) and Transport Key (TK). This mechanism is based on Shamir’s Secret Sharing algorithm. The module splits a key into three components, which are stored separately in three different USB tokens. Any two of these three components can reconstruct the original key when they are entered the module. 6.7. Key / CSP Storage All keys and CSPs are stored in encrypted form into the non-volatile memory. The module protects keys and CSPs using the same mechanism used for key wrapping (AES in CBC mode and HMAC-SHA- 256) compliant with [SP 800-38F]. The calculated HMAC value is stored with the encrypted key and the integrity of keys and CSPs are verified during decryption. All keys and CSPs are encrypted using the Local Master Key (LMK), which is stored in the battery- backup SRAM. 6.8. Key / CSP Zeroization The zeroization process is triggered by the operator, tamper response and switch FIPS mode. When the operator sends a zeroization host command or press erase button, it will perform the following processes in order: 1. Zeroize LMK stored in battery-backup SRAM 2. Erase Encrypted Keys and CSPs stored in Flash It will zeroize the LMK by writing 0x00s to overwrite the key resident in battery-backup SRAM. And all the Encrypted Keys and CSPs stored in Flash will be erased. The erase command must be signed by an authorized administrator or operator, or it must press the erase button for 10 seconds. When the module detects a tamper event of opening the enclosure, the zeroization circuit will cut the internal battery power and cause the SRAM shutdown and lose the LMK. 35 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. The LMK resident in the SRAM can be erased within 2ms when the zeroization process is triggered. The time is not enough for the attacker to compromise the plaintext secret and private keys. 36 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 7. EMI/EMC The module conforms to the EMI/EMC requirements specified by 47 Code of Federal Regulations, FCC PART 15, Subpart B, Unintentional Radiators, Digital Devices, Class B. 37 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 8. Self-Tests The module performs the following self-tests: Integrity Test, Continuous Random Generator Test, self- tests for a set of critical functions. All critical functions are listed in Table 12 and Table 13. The functions in Table 12 are tested immediately after power-up, and functions in Table 13 are tested conditionally. 8.1. Power-Up Self-Tests Power-up self-tests include integrity tests on the firmware and cryptographic algorithm self-tests. The module implements a series of power-up self-tests to ensure that cryptographic algorithms work as expected and the module has not been corrupted. Power-up self-tests are executed automatically when the module powered on. While the module is executing self-tests, input and output are inhibited. Input and output are inhibited, services are not available until all self-tests complete successfully. When the module finishes the power-up self-tests, the status LED indicates the status. The blink blue light indicates the test succeed and the module is ready for service. If any of the power-up self-test fails, the module enters the error state and it will blink red light to indicate an error status. Input and output are inhibited and none of the management or cryptographic services is available. The operator can get the test log via management console. 8.1.1. Integrity Tests The integrity of the module is verified by comparing a SHA-256 value calculated at run time with the value stored in the module. The SHA-256 value in the module is the hash value of firmware code and is computed during the module production process. During the integrity test, the firmware code is used again to compute a SHA-256 value, which is used to compare with the stored value. If the two SHA-256 values do not match, the integrity test fails, and the module enters the error state. 8.1.2. Cryptographic Algorithm Tests The module performs self-tests on all FIPS-Approved cryptographic algorithms supported in the Approved mode of operation, using the Known Answer Tests (KAT) and Pair-wise Consistency Tests (PCT) shown in the following table. 38 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. Algorithm Test AES  AES (encrypt/decrypt) KATs, 256-bit key for modes ECB/CBC/CFB128/CTR/GCM/OFB/XTS (Cert. #C1435, #A665)  AES (encrypt/decrypt) KATs, 256-bit key for modes ECB/CTR/XTS (Cert. #C1706) SHS  SHA2 KATs, SHA2-256, 384, 512 (Cert. #C1435)  SHA3 KATs, SHA3-224, 256, 384, 512 (Cert. #C1435)  SHAKE KATs, SHAKE-128, 256 (Cert. #C1435) HMAC  HMAC KATs, HMAC-SHA2-256, 384, 512 (Cert #C1435)  HMAC KATs, HMAC-SHA3-256, 384, 512 (Cert. #C1435) ECDSA  ECDSA PCT with P-256, P-384 and P-521 (Cert. #C1435)  ECDSA PCT with P-256 (Cert. #C1706) EC Diffie-Hellman  KAS-SSC-ECC KATs, P-256 (Cert. #A665)  Primitive Z computation KAT (Cert. #A665) (per [SP 800-56A], Section 5.7.1.2).  KDF KAT (Cert. #A665) (per [SP 800-56A], Section 5.8.1). RSA  RSA 2048 and 4096 PCT (Cert. #C1706 and #A1169) KBKDF  KBKDF KATs, 256 (Cert. #A665) (per [SP 800-108]) DRBG  KAT Hash_DRBG using SHA-256 (Cert. #C1435) Table 12 – Power-Up self-tests For KATs, the module calculates the result and compare it with the known value. If the answer does not match the known answer, the KAT fails, and the module enters the error state. For PCTs, if the signature generation or verification fails, the module enters the Error state. 8.2. On-Demand Self-Tests The operator can issue the management command or restart the module to trigger the power-up self- tests. 8.3. Conditional Self-Tests The module performs conditional tests on the cryptographic algorithms as shown in the following table. Algorithm Test ECDSA Pair-wise Consistency Test RSA Pair-wise Consistency Test ENT (P) Continuous Random Number Generator Test (CRNGT) Health Test compliant with SP 800-90B: Repetition Count Test (RCT) and Adaptive Proportion Test (APT) 39 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. DRBG Continuous Random Number Generator Test (CRNGT) Health Test compliant with SP 800-90A including: KAT for the Instantiate, Generate and Reseed functions. Table 13 – Conditional self-tests If a conditional test fails, the module enters the error state. Input and output are inhibited and none of the management or cryptographic services is available. The Continuous Random Number Generator Test (CRNGT) is performed on the ENT (P) and DRBG supported by the module. An initial random number is generated and stored upon power up for both ENT (P) and DRBG. A successive call to ENT (P)/DRBG generates a new set of data, which is compared to the comparison data. If a match is detected, this test fails; otherwise the new data is stored as the comparison data and returned to the caller. The module enters the error state if this test fails 40 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 9. Guidance In Approved mode of operation, the module must be operated using the FIPS approved services, with their corresponding FIPS approved or FIPS allowed cryptographic algorithms provided in this Security Policy (see Session 3.3). In addition, cryptographic algorithms and their key sizes must also comply with [SP 800-131A]. In FIPS mode of operation, all rules above are enforced by the module. In case a service request does not meet any of the rules, the module rejects the request. 9.1. Initialization The module is shipped to the vendor without any initialization of keys or CSPs. By default, the module is configured to operate in FIPS mode. The first user of the module implicitly acquires the Super Administrator role and is allowed to perform the module initialization without any authentication. The Administrator must perform the initialization of the module following the instructions.  Verify that the external condition of the package to see if there are signs of damage, or if the package has been opened during transit.  Open the package and verify with the content list that the module and all accessories are included.  Verify the condition of the module and closure to see if there are signs of damage.  Connect the module to a server PCIe slot.  Power-up the server.  Install and Run the module initial program (kvConsole).  Verify that the product model and version provided in the “View Device Basic Information” menu option matches the following information:  Vendor: WiSECURE Technologies  Product Name: kvHSM  Module Name: KeyVault Hardware Security Module (kvHSM)  Hardware Versions: KV-HSM_V02  Firmware Versions: v1.00.0000  Generate Admin Tokens  Use kvConsole to Initialize Admin Tokens (x3)  Use the Installation Wizard to perform the following activities:  Initialize the device by Admin Tokens. (Set admin Public-keys into module)  Create the Local Master Key (LMK) and export the LMK key components to LMK Tokens.  Create the Operator and Auditor  Configure the Device security policies 41 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 9.2. USB Tokens To initialize the module, the following USB Tokens must be available:  3 Admin Tokens for the device and user management.  3 LMK Tokens for exporting the LMK key components. The USB tokens must be initialized with an ad-hoc utility. Access to the USB token is protected through an eight-digit PIN. Operator and Auditor can use the Token as the login credential or set a password. 42 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 10. Mitigation of Other Attacks The module has been designed to mitigate against power analysis attacks and physical probing, which are outside of the scope of FIPS 140-2. Other Attack Mitigation Mechanism Side-channel attacks (power analysis) The module hardware provides desynchronization and confusing mechanism to protect security calculation against SPA and DPA power analysis attacks. The module implements following mitigations against the power analysis attacks: Montgomery powering ladder, exponent blinding, scalar randomization, random projective coordinates, random register address, point validation, curve integrity check and Two-share masking. Table 14 – Mitigation of other attacks 43 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 11. Security Rules The module design corresponds to the module's security rules. This section documents the security rules enforced by the module to implement the Level 3 security requirements of FIPS 140-2. 1. The module supports two modes of operation, FIPS mode and non-FIPS mode. Power-cycling zeroizes all volatile plaintext critical security parameters. 2. The FIPS mode is implicitly assumed when an Administrator initializes the module for the first time. 3. No hardware, software, or firmware components of the cryptographic module are excluded from the security requirements of FIPS 140-2. 4. All data output via the data output interface are inhibited when an error state exists and during self-tests. 5. The output data paths are logically disconnected from the circuitry and processes that perform key generation, and key zeroization. 6. The module never outputs plaintext cryptographic keys or CSPs or sensitive data. 7. Status information never contains CSPs or sensitive data that if misused could lead to a compromise of the module. 8. The module supports maximum 16 concurrent operators. 9. The module does not support a maintenance role. 10. The module does not support a bypass capability. 11. Authentication data within the module is protected against unauthorized disclosure, modification, and substitution. 12. The module contains the authentication data required to authenticate the operator for the first time. 13. The module’s authentication mechanism does not supply any feedback information to the operator. 14. Recovery from “soft” error states is possible via power-cycling. Recovery from “hard” error states is not possible. 15. The operator should periodically inspect the module for evidence of tampering. 16. Secret keys, private keys, public keys, and CSPs within the module are protected from unauthorized disclosure, modification, and substitution. 17. Compromising the security of the key generation methods requires as least as many operations as determining the value of the generated keys. 18. Intermediate key generation values are not output from the module. 19. The module does not support manual key entry. 20. The module does not support a SW/FW Load service from the operator (host). 44 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 12. References [ECCBP] RFC 5639: Elliptic Curve Cryptography ECC Brainpool Standard – Curves and Curve Generation [FIPS 140-2] FIPS PUB 140-2 - Security Requirements for Cryptographic Modules [FIPS 180-4] Secure Hash Standard (SHS) [FIPS 186-2] Digital Signature Standard (DSS) [FIPS 186-4] Digital Signature Standard (DSS) [FIPS 197] Advanced Encryption Standard (AES) [FIPS 198-1] The Keyed Hash Message Authentication Code (HMAC) [FIPS 202] SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions [IG] Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program [ECCSEC2] SEC2: Recommended Elliptic Curve Domain Parameters [SP 800-38A] NIST Special Publication 800-38A - Recommendation for Block Cipher Modes of Operation: Methods and Techniques [SP 800-38D] NIST Special Publication 800-38D - Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC [SP 800-38E] NIST Special Publication 800-38E - Recommendation for Block Cipher Modes of Operation: The XTS AES Mode for Confidentiality on Storage Devices [SP 800-38F] NIST Special Publication 800-38F - Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping [SP 800-56A] NIST Special Publication 800-56A Revision 3 - Recommendation for Pair-Wise Key- Establishment Schemes Using Discrete Logarithm Cryptography [SP 800-56C] NIST Special Publication 800-56C Revision 2 - Recommendation for Key-Derivation Methods in Key-Establishment Schemes [SP 800-90A] NIST Special Publication 800-90A Revision 1 - Recommendation for Random Number Generation Using Deterministic Random Bit Generators [SP 800-108] NIST Special Publication 800-108 - Recommendation for Key Derivation Using Pseudorandom Functions [SP 800-131A] NIST Special Publication 800-131A Revision 2 - Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths [SP 800-133] NIST Special Publication 800-133 Revision 2 - Recommendation for Cryptographic Key Generation 45 © 2023 WiSECURE Technologies This document can be reproduced and distributed only whole and intact, including this copyright notice. 13. Definitions and Acronyms AES Advanced Encryption Standard AMK Application Master Key APP Application CC Common Criteria CRNGT Continuous Random Number Generator Test CSP Critical Security Parameter DES Data Encryption Standard DH Diffie-Hellman DPA Differential Power Analysis DRBG Deterministic Random Bit Generator DSA Digital Signature Algorithm EC Elliptic Curve ECC Elliptic Curve Cryptography ECDSA Elliptic Curve Digital Signature Algorithm HSM Hardware Security Module KAS Key Agreement Scheme KAT Known Answer Test KDF Key Derivation Function KBKDF Key-Based Key Derivation Function HKDF HMAC-based Extract-and-Expand Key Derivation Function HMAC Keyed Hash Message Authentication Code LMK Local Master Key MAC Message Authentication Code MBK Master Backup Key NDRNG Non-deterministic Random Number Generator PCT Pair-wise Consistency Test PSD Primary Security Domain RNG Random Number Generator SCA Side-channel Attack SD Security Domain SHA Secure Hash Algorithm SP Security Policy SPA Simple Power Analysis SSC Shared Secret Computation TK Transport Key