Thales Luna K7 Cryptographic Module

Certificate

Approved Algorithms (95)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for Thales Luna K7 Cryptographic Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Update<br/>Firmware Load<br/>recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>kernel<br/>bootloader</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Thales Luna K7 Cryptographic Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Update<br/>Firmware Load<br/>recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>kernel<br/>bootloader</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

Thales Luna K7 Cryptographic Module 002-010935-003 Rev. U January 31, 2025

Document Information Document Part Number 002-010935-003 Initial Release Date February 23, 2024 Update Release Date January 31, 2025 Thales and/or its subsidiaries and are registered in certain countries. All other trademarks and service marks, whether registered or not in specific countries, are the property of their respective owners. Disclaimer All information herein is either public information or is the property of and owned solely by Thales and/or its subsidiaries who shall have and keep the sole right to file patent applications or any other kind of intellectual property protection in connection with such information. Nothing herein shall be construed as implying or granting to you any rights, by license, grant or otherwise, under any intellectual and/or industrial property rights of or concerning any of Thales’s information. This document can be copied or distributed for informational, non-commercial, internal and personal use only provided that: appear in all copies. > This document shall not be posted on any network computer or broadcast in any media other than on the NIST CMVP validation list and no modification of any part of this document shall be made. Use for any other purpose is expressly prohibited and may result in severe civil and criminal liabilities. The information contained in this document is provided “AS IS” without any warranty of any kind. Unless otherwise expressly agreed in writing, Thales makes no warranty as to the value or accuracy of information contained herein. Thales hereby disclaims all warranties and conditions with regard to the information contained herein, including all implied warranties of merchantability, fitness for a particular purpose, title and noninfringement. In no event shall Thales be liable, whether in contract, tort or otherwise, for any indirect, special or consequential damages or any damages whatsoever including but not limited to damages resulting from loss of use, data, profits, revenues, or customers, arising out of or in connection with the use or performance of information contained in this document. Thales does not and shall not warrant that this product will be resistant to all possible attacks and shall not incur, and disclaims, any liability in this respect. Even if each product is compliant with current security standards in force on the date of their design, security mechanisms' resistance necessarily evolves according to the state of the art in security and notably under the emergence of new attacks. Under no circumstances, shall Thales be held liable for any third party actions and in particular in case of any successful attack against systems or equipment incorporating Thales products. Thales disclaims any liability with respect to security for direct, indirect, incidental or consequential damages that result from any use of its products. It is further stressed that independent testing and verification by the person using the product is particularly encouraged, especially in any application in which defective,

incorrect or insecure functioning could result in damage to persons or property, denial of service or loss of privacy.

Term

Definition

Acronyms and Abbreviations ACRONYMS AND ABBREVIATIONS AES                        Advanced Encryption Standard ANSI                       American National Standards Institute AU                         Audit User API                        Application Programming Interface CBC                        Cipher Block Chaining CDH                        Cofactor Diffie-Hellman CID                        Client IDentity CITS                       Chrysalis ITS CKG                        Cryptographic Key Generation CFB                        Cipher FeedBack CMAC                       Cipher Block Chaining Message Authenticate Code CMVP                       Cryptographic Module Validation Program CO                         Crypto Officer CPV1                       Cloning Protocol Version 1 CPV3                       Cloning Protocol Version 3 CPV4                       Cloning Protocol Version 4 CSP                        Critical Security Parameter CTR                        CounTeR CU                         Crypto User CVL                        Component Validation List DAK                        Device Authentication Key DAC                        Device Authentication Certificate DEK                        Data Encryption Key

Term

Definition

Acronyms and Abbreviations DH                         Diffie-Hellman DMK                        Data MAC Key DPK                        Data Protection Key DSA                        Digital Signature Algorithm DRBG                       Deterministic Random Bit Generator ECB                        Electronic Code Book ECC                        Elliptic Curve Cryptography ECDH                       Elliptic Curve Diffie-Hellman ECDSA                      Elliptic Curve Digital Signature Algorithm EFP                        Environmental Failure Protection EFT                        Environmental Failure Testing EKA                        Ephemeral Key Agreement ELF                        Executable and Linkable Format EMC                        ElectroMagnetic Compatibility EMI                        ElectroMagnetic Interference ESV                        Entropy Source Validation FFC                        Finite Field Cryptography FIPS                       Federal Information Processing Standard FM                         Functionality Module GCM                        Galois Counter Mode GMAC                       Galois Message Authentication Code GSK                        Global Storage Key HMAC                       Keyed-Hash Message Authentication Code HA                         High Availability HOC                        Hardware Origin Certificate HOK                        Hardware Origin Key

Term

Definition

Acronyms and Abbreviations HSE-BBRAM                  High-speed erase battery backed RAM HSM                        Hardware Security Module / Host Security Module ICD                        Interface Control Design/Document IG                         Implementation Guidance ISO/IEC                    International Organization for Standardization / International Electrotechnical Commission I/O                        Input/Output IV                         Initialization Vector KAS                        Key Agreement Scheme KAT                        Known Answer Test KBKDF                      Key-Based Key Derivation Function KCV                        Key Cloning Vector KDF                        Key Derivation Function KDM                        Key Destruction Method KEK                        Key Encryption Key KEV                        Key Encryption Vector KTS                        Key Transport Scheme KW                         Key Wrap KWP                        Key Wrap with Padding LCO                        Limited Crypto Officer LED                        Light Emitting Diode LSB                        Least Significant Bit MAC                        Message Authentication Code Masking                    A Thales term to describe the encryption of a key for use only within a Thales cryptographic module Mbps                       Megabits per second MGF                        Mask Generation Function

Term

Definition

Acronyms and Abbreviations MIC                        Manufacturer’s Integrity Certificate MIK                        Manufacturer’s Integrity Key MK                         Master Key NIST                       National Institute of Science and Technology N/A                        Not Applicable OFB                        Output FeedBack PAC                        PED Authentication Certificate PAK                        PED Authentication Key PBKDF                      Password Based Key Derivation Function PCIe                       Peripheral Component Interconnect Express PCT                        Pair-wise Consistency Test PEC                        Password Encryption Certificate PED                        PIN Entry Device PEK                        Password Encryption Key PKCS                       Public-Key Cryptography Standards POST                       Power-on Self-Test PSK                        Partition Storage Key PSS                        Probabilistic Signature Scheme PST                        Periodic Self-Test RDK                        Role Domain Key RNG                        Random Number Generator RPV                        Remote PED Vector RSA                        Rivest Shamir Adleman RSADP                      RSA Decryption Primitive RSASVE                     RSA Secret-Value Encapsulation RTC                        Real Time Clock

Term

Definition

Acronyms and Abbreviations SALK                       Secure Audit Logging Key SHA                        Secure Hash Algorithm SKA                        Static Key Agreement SMFS                       Secure Memory File System SMK                        SKS Master Key SKS                        Scalable Key Storage SO                         Security Officer SSC                        Shared Secret Computation SSP                        Sensitive Security Parameter STC                        Secure Trusted Channel STM                        Secure Transport Mode Triple-DES                 Triple Data Encryption Standard TUK                        Token or Module Unwrapping Key TVK                        Token or Module Variable Key TWC                        Token or Module Wrapping Certificate USB                        Universal Serial Bus USK                        User’s Storage Key VPD                        Vital Product Data XEX                        XOR-encrypt-XOR XOR                        eXclusive OR XTS                        XEX Tweakable block cipher ciphertext Stealing

[PKCS #1] PKCS #1: RSA Cryptographic Standard, RSA Laboratories, v2.1.

[ISO/IEC 14888-3:2018] ISO/IEC 14888-3:2018, ‘IT Security techniques

• Digital Signatures with appendix
• Part 3: Discrete logarithm based mechanisms’, 2018-11.

References [ISO/IEC 19790:2012] ISO/IEC 19790:2012 (Corrected 2015-12-15, IDT) Information technology

• Security techniques
• Security requirements for cryptographic modules, 2015-12-15. [ISO/IEC 24759:2017] ISO/IEC 24759:2017 (Corrected 2017-03, IDT) Information technology
• Security techniques
• Test requirements for cryptographic modules, 2017-03.

NOTE: You require an account to access the Customer Support Portal. To create a new

account, go to the portal and click on the REGISTER link.

Preface PREFACE This document deals only with operations and capabilities of the Thales Luna K7 Cryptographic Module in the technical terms of [FIPS 140-3]. General information on Thales HSM alongside other Thales products is available from the following sources:

[ISO/IEC 24759:2017] Section 6 [Number Below]

FIPS 140-3 Section Title General Cryptographic Module Specification Cryptographic Module Interfaces Roles, Services, and Authentication Software/Firmware Security Operational Environment Physical Security Non-Invasive Security Sensitive Security Parameter Management Self-Tests Life-Cycle Assurance Mitigation of Other Attacks

Security Level

The Thales Luna K7 Cryptographic Module meets all level 3 security requirements for [FIPS 140-3] as summarized in the table below: Table 1-1: Security Levels

NOTE Thales Luna K7 Cryptographic Module does not support degraded operation as defined in [ISO/IEC 19790:2012].

NOTE The Thales Luna K7 Cryptographic Module can be used as follows:

> as a standalone device called the Thales Luna PCIe HSM; or

> as an embedded device in the Thales Luna Network HSM.

The Thales Luna K7 Cryptographic Module is a multi-chip embedded hardware security module in the form of a PCIe card, which typically resides within a custom computing or security appliance. The cryptographic module is contained in its own secure enclosure, which provides physical resistance to tampering. The cryptographic boundary of the module is defined to encompass all components inside the secure enclosure on the PCIe card. The module must be explicitly configured to operate in an [FIPS 140-3] approved mode of operation using steps outlined in section 13.2 and where these are performed during the secure initialization of the module. The module only supports a single approved mode of operation and any configuration changes to settings defining that mode will trigger a zeroization of all partition Sensitive Security Parameter (SSP) and require the full reset and re-initialization of the module. The module provides secure key generation and storage for symmetric keys and asymmetric key pairs along with support for a broad range of cryptographic services. Access to key material and cryptographic services for users and user application software is provided through the PKCS #11 programming API, which is implemented over the module’s proprietary command interface. The module may host multiple ‘user partitions’ which are cryptographically separated and are presented as ‘virtual tokens’ to user applications. A single ‘admin partition’ exists, which is dedicated to the HSM Security Officer (HSM SO) and Administrator roles. Each partition must be separately authenticated in order to make it available for use.

chip embedded. The cryptographic boundary of the module is shown in Figure 2-1 and Figure 2-2 below with the module the metal enclosure on the top and bottom sides of the PCIe card as outlined. The fans and heatsinks depicted alongside the removable backup battery are inside the cryptographic boundary (i.e. included in the module versioning on the certificate), but excluded from the testing requirements of FIPS 140-3.

Cryptographic Module Specification Cryptographic Boundary Figure 2-1: Thales Luna K7 Cryptographic Module cryptographic boundary with fans Cryptographic Boundary Figure 2-2: Thales Luna K7 Cryptographic Module cryptographic boundary with heatsinks

NOTE As covered above, ‘firmware’ for the module includes the bootloader, main

firmware, and may also contain optional FM’s if loaded. To use the module in an approved

mode of operation, all firmware, including the bootloader, main firmware and any FM’s

Cryptographic Module Specification Figure 2-3: Thales Luna Network HSM The following figure highlights the logical boundary of the module covered by this certification: Figure 2-4 – Thales Luna K7 Cryptographic Module, cryptographic boundary. may be loaded by the HSM SO 1 onto the PCIe card to interface to the main firmware. The bootloader, main firmware and FM are considered ‘firmware’ within the scope of definitions in [ISO/IEC 19790:2012]. The HSM Security Of f icer is responsible f or managing the HSM. As such, the HSM SO is authorized to install and conf igure the HSM, set and maintain global HSM security policies and load FMs. For more inf ormation on the HSM SO, and all other roles, ref er to section 4.1.

loaded onto the module must be validated to [FIPS 140-3] to run on Thales Luna K7

Cryptographic Module.

The scope of this certificate exclusively covers the bootloader and main firmware as

approved for use by the module.

Any FM approved to run on the module will have its own FIPS 140-3 certificate to run on

top of the module and where it will most likely be of embodiment, firmware module if

maintaining a FIPS 140-3, Level 3 approval overall.

Model

Hardware [Part Number and Version] 808-000048-002 or 808-000048-003 808-000066-001 808-000073-001 or 808-000073-002

Firmware Version Main firmware: 7.8.4 or 7.8.5; with Bootloader: 1.1.1, 1.1.2, 1.1.4, or 1.1.5 Main firmware: 7.8.4 or 7.8.5; with Bootloader: 1.1.1, 1.1.2, 1.1.4, or 1.1.5 Main firmware: 7.8.4 or 7.8.5; with Bootloader: 1.1.1, 1.1.2, 1.1.4, or 1.1.5

Distinguishing Features

NOTE The security features described in this document apply to the Thales Luna K7

Cryptographic Module only and do not include any feature that may be enforced by the

host appliance, client or Thales Luna PED.

NOTE As the module is a hardware module of embodiment multi-chip embedded – this security policy is not required to list an operating system.

The following tested configuration are covered in this security policy: Table 2-1: Cryptographic module tested configuration. Thales Luna PCIe HSM 808-000048-002 Main firmware: 7.8.4 or Half-height PCIe card with factory installed fans. or 7.8.5; with Listed hardware parts are functionally identical 1.1.2, 1.1.4, or 1.1.5 for one of the internal components. Network HSM 1.1.2, 1.1.4, or 1.1.5 Listed hardware parts are functionally identical with the difference being a change of supplier for one of the internal components.

NOTE The following certificates referenced above contain redundant listings not used by the

cryptographic module:

> Cert #C1701 includes a listing for FIPS 186-2, RSA, SigVer. This is redundant listing and where

the same implementation has been retested to [FIPS 186-4], RSA, SigVer covered under Cert

#A3164.

> Cert #C1707 includes listing for KAS-ECC, KAS-FFC, CVL (RSADP), GMAC and TDES-CMAC as a

redundant MAC option for KDF [SP800-108r1];

> Cert #C1717 includes a listing for KAS-ECC and CVL (RSADP);

> Cert #C1718 includes KAS-ECC, KAS-FFC, GMAC, CVL (RSADP) and AES in GCM mode with

external IV; and

> Cert #C1719 includes CVL (RSADP).

Implementations for these algorithms are present in the software libraries or hardware integrated

circuits used by the module and have completed CAVP testing but where this code is not

executable for the certified configuration of the module.

The approved algorithms implemented by the module alongside their mapping to the certificates above alongside algorithms use by service are listed in the Table 2-2 below. Listings in the ‘Use / Function’ column map to services listed in Table 4-2 and Table 4-4:

Cryptographic Module Specification Table 2-2: Approved Algorithms GCM 2, KW, KWP 3, OFB, XTS 4. audit log secret key, Request partition STC identity, Initiate STC tunnel, Send commands to partition with STC tunnel initiated, Clone SMK between partitions, Clone partition objects between partitions, Rollover SMK for a given partition, Request HSM self-test, Initialize role, Configure partition for high-available recovery / login, Login as role, Initialize Remote PED Vector (RPV), Send or receive data over PED tunnel (local PED), Send or receive data over PED tunnel (remote PED), Generate local symmetric or asymmetric key-pair, Generate domain parameters, Derive key from existing partition secret or private key object, Import secret or private key using key wrapping, Export secret or private key using key wrapping, Insert key from external storage using SKS, Extract key to external storage using SKS, Perform encrypt operation on user supplied data object, Perform decrypt operation on user supplied data object, Generate signature or MAC over user supplied data, Activate SMFS, Store/retrieve data from SMFS. used when data being encrypted or decrypted is greater than 2KB in size.> #C1707 Algorithm: Triple-DES. Mode: CBC, CFB64, CFB8, CTR, ECB, OFB Key size: 168-bits (3-key). Request HSM self-test, Import secret or private key using (decrypt only). key wrapping, Perform decrypt operation on user supplied data object, Validate signature or MAC over user supplied data. The module generates IVs internally using the approved DRBG where all IV used are 128-bits in length per [SP800-38D]. KW and KWP use this implementation conf iguration when objects are less than 2KB in size. Otherwise, the #C1718 implementation is used. XTS-AES is only supported f or consumption by users with the ‘Perf orm encrypt operation on user supplied data object’ service. When used, output f rom this service should be used exclusively f or data storage. Keys generated using PBKDF are exclusively used f or f unctions internal to the module and where these are used f or storage applications.

Message Authentication Code

Cryptographic Module Specification #C1707 Algorithm: SHA. Methods: SHA-1, SHA2-224, SHA2-256, N/A. Update firmware, Protect object integrity, Load SHA2-384, SHA2-512, SHA3-224, SHA3- configuration update file, Request partition STC identity, 256, SHA3-384, SHA3-512, SHAKE-128, Initiate STC tunnel, Clone SMK between partitions, Clone SHAKE-256 (Byte Only). partition objects between partitions, Enable/disable STM, Request HSM self-test, Initialize role, Change authentication data, Configure partition for high-available recovery / login, Login as role, Initialize Remote PED Vector (RPV), Generate local symmetric or asymmetric key-pair, Generate domain parameters, Derive key from existing partition secret or private key object, Import secret or private key using key wrapping, Export secret or private key using key wrapping, Insert key from external storage using SKS, Re-seed partition DRBG, Extract entropy from partition DRBG, Perform digest operation on user supplied data, Perform encrypt operation on user supplied data object, Generate signature or MAC over user supplied data, Download FM, Activate SMFS, Store/retrieve data from SMFS, Setup Local PED Session, Setup Remote PED Session, Send or receive data over PED tunnel (remote PED). #C1718 Algorithm: SHA. Methods: SHA2-256, SHA2-512 (Byte N/A. Generate secure log record, Submit external messages for Only). entry into secure audit log, Validate the audit log, Request HSM self-test. 4]. 4]. #C1707 Algorithm: HMAC. Methods: HMAC-SHA-1, HMAC-SHA2-224, Mac size: 10-to-64 bytes (dependent Request HSM self-test, Send or receive data over PED tunnel HMAC-SHA2-256, HMAC-SHA2-384, on hash). (remote PED), Generate signature or MAC over user supplied HMAC-SHA2-512, HMAC-SHA3-224, Key size: key size < block size, key size data, Validate signature or MAC over user supplied data, 1]. HMAC-SHA3-256, HMAC-SHA3-384, = block size, key size > block size. Store/retrieve data from SMFS, Initialize the HSM, Initialize HMAC-SHA3-512. role, Change authentication data, Login as role Key size: key size < block size, key size certificate covers the standalone algorithm implementation = block size, key size > block size. exclusively used to support secure logging.> 1].

Asymmetric

Algorithm: RSA. Standard: [FIPS 186- 4].

Method: Key Generation, Signature Generation, Signature Verification. Signature Type: ANSI X9.31, PKCS #1-v1.5 1.5, PKCS-PSS. Hash options: Signature Generation (PKCS #1-v1.5 and PKCS-PSS): SHA2-224, SHA2-256, SHA2-384, SHA2-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512. Signature Generation (ANSI X9.31): SHA2-224, SHA2-256, SHA2-384, SHA2-512. Signature Verification (PKCS #1-v1.5 and PKCS-PSS): SHA-1, SHA2-224, SHA2-256, SHA2-384, SHA2-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512. Signature Verification (ANSI X9.31): SHA-1, SHA2-224, SHA2-256, SHA2- 384, SHA2-512. Vendor affirmed using [FIPS 140-3 IG], C.C, The Use and the Testing Requirements for the Family of Functions defined in FIPS 202, when using SHA-3.

Modulus length: 2048, 3072

• Key Generation, Signature Generation and Signature Verification. 1024
• Signature Verification only.

Cryptographic Module Specification HSM self-test. signature or MAC over user supplied data, Request HSM selftest. #C1707, Algorithm: RSA. Method: Key Generation, Signature Modulus length: 2048, 3072 – Key Clone SMK between partitions, Clone partition objects #C1717. Generation, Signature Verification. Generation, Signature Generation and between partitions, Generate local symmetric or asymmetric Signature Verification. key-pair, Request HSM self-test, Generate signature or MAC over user supplied data, Validate signature or MAC over user supplied data, Download FM. Signature Generation (PKCS #1-v1.5 Both algorithm implementations used when HSM Policy (43) and PKCS-PSS): SHA2-224, SHA2-256, Enable low-level math acceleration is enabled. covered by #C1707 used when Partition Policy (16) Operate Without RSA blinding is enabled and #C1717 used when Partition Policy (16) Operate Without RSA blinding is disabled.

Cryptographic Module Specification #C1719 as already mapped from the RSA listing above but where this implementation is used when HSM Policy (43) Enable low level math acceleration is disabled. Of the two implementations, Algorithm implementation covered by Cert #C1718 used when Partition Policy (16) Operate Without RSA blinding is enabled and Cert #C1719 used when Partition Policy (16) Operate Without RSA blinding is disabled. #A480, Algorithm: RSA. Methods: Signature Generation, Modulus length: 4096-bit. Load configuration update file, Clone SMK between #A481. Signature Verification. partitions, Clone partition objects between partitions, , Configure partition for high-available recovery / login, Generate local symmetric or asymmetric key-pair, Request HSM self-test, Generate signature or MAC over user supplied data, Validate signature or MAC over user supplied data, Download FM. Both algorithm implementations used when HSM Policy (43) Signature Generation (ANSI X9.31): Enable low-level math acceleration is enabled. Signature Verification (PKCS #1-v1.5 Operate Without RSA blinding is enabled and Cert #A481 blinding is disabled.

Cryptographic Module Specification #A478, Algorithm: RSA. Method: Key Generation. Modulus length: 4096-bit. Generate local symmetric or asymmetric key-pair. #A480, Implementation covered by Cert #A480 used when HSM #A481. Policy (43) Enable low-level math acceleration is enabled and Partition Policy (16) Operate Without RSA blinding is enabled. Implementation covered by Cert #A481 used when HSM Policy (43) Enable low-level math acceleration is enabled and Partition Policy (16) Operate Without RSA blinding is independent CAVP assurance activities Policy (43) Enable low-level math acceleration is performed. disabled and Partition Policy (16) Operate Without RSA blinding is enabled. Implementation covered by Cert #A479 used when HSM Policy (43) Enable low-level math acceleration is disabled and Partition Policy (16) Operate Without RSA blinding is disabled. 4].

Cryptographic Module Specification Generation, Signature Generation,          Parameter Generation, Key                domain parameters, Generate signature or MAC over user Signature Verification.                    Generation, Signature Generation.        supplied data, Validate signature or MAC over user supplied 4]. Generation.                                Parameter Generation, Key                domain parameters when HSM Policy (43) Enable low-level Generation.                              math acceleration is disabled. #C1707         Algorithm: ECDSA.           Methods: Key Generation, Signature         Curves: B-233, B-283,                    Request partition STC identity, Initiate STC tunnel, Generate Generation, Signature Verification.        B-409, B-571, K-233,                     local symmetric or asymmetric key-pair, Generate signature K-283, K-409, K-571,                     or MAC over user supplied data, Validate signature or MAC P-224, P-256, P-384,                     over user supplied data, Initialize Remote PED Vector (RPV). SHA2-256, SHA2-384, SHA2-512,                                                   Note: Initiate STC tunnel , Request partition STC identity and Signature Verification: SHA-1, SHA2-                                            Algorithm implementation used when HSM Policy (43)

Key Agreement Scheme

Cryptographic Module Specification Generation, Signature Verification. B-409, B-571, K-233, where this implementation is only exercised for the listed K-283, K-409, K-571. curves and when HSM Policy (43) Enable low-level math acceleration is disabled. Request HSM self-test, Derive key from existing partition secret or private key object. Algorithm implementation used when HSM Policy (43) Caveat: key establishment Enable low-level math acceleration is enabled. Request HSM self-test, Derive key from existing partition secret or private key object. Algorithm implementation used when HSM Policy (43) Standard: [SP800- Caveat: key establishment Enable low-level math acceleration is enabled. above but where this implementation is only exercised for the listed curves and when HSM Policy (43) Enable low-level Caveat: key establishment math acceleration is disabled.

Cryptographic Module Specification As per services mapped to KAS-ECC-SSC for Cert #A480 above but where this implementation is only exercised for the listed curves and when HSM Policy (43) Enable low-level Caveat: key establishment math acceleration is disabled. Request HSM self-test, Derive key from existing partition secret or private key object. methodology provides between 112 used when HSM Policy (43) Enable low-level math Request HSM self-test, Derive key from existing partition secret or private key object. Standard: [SP800- methodology provides between 112 used when HSM Policy (43) Enable low-level math Request HSM self-test, Derive key from existing partition secret or private key object. methodology provides between 112 used when HSM Policy (43) Enable low-level math Request HSM self-test, Derive key from existing partition secret or private key object. Standard: [SP800- methodology provides between 112 used when HSM Policy (43) Enable low-level math

Cryptographic Module Specification #A478, Algorithm: KAS-RSA. Method: KAS1-basic. Modulus length: 4096-bit. Clone SMK between partitions, Configure partition for high#A479, available recovery / login. #A481 rsakpg2-crt Implementation covered by Cert #A480 used when HSM Policy (43) Enable low-level math acceleration is enabled and Partition Policy (16) Operate Without RSA blinding is enabled. Implementation covered by Cert #A481 used when HSM Policy (43) Enable low-level math acceleration is enabled and Partition Policy (16) Operate Without RSA blinding is disabled. Implementation covered by Cert #A478 used when HSM Policy (43) Enable low-level math acceleration is disabled and Partition Policy (16) Operate Without RSA blinding is enabled. Implementation covered by Cert #A479 used when HSM Policy (43) Enable low-level math acceleration is disabled and Partition Policy (16) Operate Without RSA blinding is disabled. Algorithm implementation used when HSM Policy (43) Enable low-level math acceleration is enabled. #A478 Algorithm: KAS-ECC- Methods: ephemeralUnified, onePassDH. Curves: B-233, B-283, As per services mapped to KAS-ECC-SSC for Cert #A480 SSC. B-409, B-571, K-233, above but where this implementation is only exercised for Standards: [SP800- K-283, K-409, K-571. the listed curves and when HSM Policy (43) Enable low-level 56Ar3]. math acceleration is disabled. #A478, Algorithm: KAS-FFC- Methods: dhHybrid1, dhEphem, Request HSM self-test, Derive key from existing partition #A480 SSC. dhHybridOneFlow, dhOneFlow. secret or private key object. Implementation covered by Cert #A480 is used when HSM Policy (43) Enable low-level math acceleration is enabled. Implementation covered by Cert #A478 is used when HSM Policy (43) Enable low-level math acceleration is disabled.

Cryptographic Module Specification Cert #C1707). high-available recovery / login, Export secret or private key Caveat: key establishment using key wrapping, Clone SMK between partitions, Clone methodology provides between 128 partition objects between partitions. AES KW and AES KWP implementation covered by this KTS is used when data sizes being encrypted or decrypted are less than 2KB in size. When cloning objects using CPV3, KWP is used. When cloning objects with CPV4, GCM is one of two is the other, as covered below). Cert #C1718). high-available recovery / login, Export secret or private key Standards: [FIPS 197] Caveat: key establishment using key wrapping, Clone SMK between partitions, Clone AES KW and AES KWP implementation covered by this KTS are exclusively used when data sizes being encrypted or decrypted are 2KB or greater in size. When cloning objects using CPV3, KWP is used. available with CPV4 with the other option being GCM covered above.

Key Derivation Function,

Cryptographic Module Specification #A478, Algorithm: KTS-RSA. Method: KTS-OAEP-basic. Modulus length: 2048, 3072, 4096, Request HSM self-test, Import secret or private key using #A481 Implementation covered by Cert #A480 used when HSM Hash: SHA2-224, SHA2-256, SHA2-384, Policy (43) Enable low-level math acceleration is enabled and Partition Policy (16) Operate Without RSA blinding is SHA2-256, SHA2-384, SHA2-512, SHA3- Implementation covered by Cert #A481 used when HSM 224, SHA3-256, SHA3-384, SHA3-512 Policy (43) Enable low-level math acceleration is enabled and Partition Policy (16) Operate Without RSA blinding is disabled. Implementation covered by Cert #A478 used when HSM Policy (43) Enable low-level math acceleration is disabled and Partition Policy (16) Operate Without RSA blinding is enabled. Implementation covered by Cert #A479 used when HSM Policy (43) Enable low-level math acceleration is disabled and Partition Policy (16) Operate Without RSA blinding is disabled. #C1707 Algorithm: Key-Based Mode: Counter. Supported Lengths: 1024, 1032, Initialize the HSM, Initialize role, Derive key from existing Key Derivation 2048, and 2056. partition secret or private key object, Change authentication Function (KBKDF). data, Login as role, Request HSM self-test. #A480 Algorithm: KDA 7. Method: One-Step Key Derivation. Shared secret length: 224-8192, Request HSM self-test, Derive key from existing partition increment 1 byte. secret or private key object, Clone SMK between partitions,

Cryptographic Module Specification #A480 Algorithm: X9.42 Key Methods: SHA-1, SHA2-224, SHA2-256, Shared secret length: Request HSM self-test, Derive key from existing partition #A480 Algorithm: X9.63 Key Methods: SHA2-224, SHA2-256, SHA2- Field Size: 224, 256, 384, 521. Perform encrypt operation on user supplied data object #A480 Algorithm: PBKDF 8. Methods: HMAC-SHA2-512 (as covered Derived Key Length: Initialize the HSM, Initialize role, Change authentication under Cert #C1707). 256-bit. data, Login as role, Request HSM self-test. Random Number Generation ESV (Cert Algorithm: Physical. Methods: Live noise source with SHA2- Security Strength: Initialize the HSM, Create a user partition, Request partition #98) Standards: [SP800- 512 vetted conditioning function. Full Entropy. STC identity, Initiate STC tunnel, Clone SMK between 90B], [FIPS 180-4]. partitions, Clone partition objects between partitions, Rollover SMK for a given partition, Enable/disable STM, Request HSM self-test, Initialize role, Configure partition for high-available recovery / login, Initialize Remote PED Vector (RPV), Setup Local PED Session, Setup Remote PED Session, Generate local symmetric or asymmetric key-pair, Generate domain parameters, Derive key from existing partition secret or private key object, Export secret or private key using key wrapping, Re-seed partition DRBG, Extract entropy from partition DRBG, Perform encrypt operation on user supplied data object, Generate signature or MAC over user supplied data, Activate SMFS Used internal to the cryptographic module to derive the storage encryption key used to encrypt the checkword used during password based authentication. The derived key is separately used to encrypt f or storage the USK which is independently also encrypted under the module generated KEK. The module uses method 1a f rom [SP800-132] where the derived Master Key (MK) is used directly as the Data Protection Key (DPK).

Algorithm: CKG. Standard: [SP800- 133].

Method: symmetric keys and seed for asymmetric key generation are created based on the direct output of the module DRBG (Cert #C1707).

Security strength: 256-bit.

Cryptographic Module Specification Affirmed asymmetric key generation are created 256-bit. STC identity, Initiate STC tunnel, Clone SMK between based on the direct output of the module partitions, Clone partition objects between partitions, DRBG (Cert #C1707). Rollover SMK for a given partition, Initialize role, Change authentication data, Initialize Remote PED Vector (RPV), Setup Remote PED Session, Generate local symmetric or asymmetric key-pair, Generate domain parameters, Activate SMFS.

Cryptographic Module Specification Table 2-3: Supported non-NIST elliptic curve as per [FIPS 140-3] IG C.A

Algorithm Key Transport

Caveat

Use / Function

Algorithm

Caveat N/A

Use / Function

Cryptographic Module Specification Table 2-4 Non-approved algorithms allowed in the approved mode of operation KTS (AES Cert Key unwrapping; key establishment methodology provides Clone partition objects between partitions, Clone #C1707) between 128 and 256 bits of encryption strength. SMK between partitions, Import secret or private Uses allowances in [FIPS 140-3 IG] D.G, Key transport key using key wrapping. methods, for key unwrapping using un-authenticated modes of encryption listed on Cert #C1707 without use of an additional approved hash function. KTS (Triple- Key unwrapping; key establishment methodology provides Import secret or private key using key wrapping. DES Cert 112 bits of encryption strength. #C1707) Uses allowances in [FIPS 140-3 IG] D.G, Key transport methods, for key unwrapping using un-authenticated modes of encryption listed on Cert #C1707 without use of an additional approved hash function. KAS-ECC-SSC Key establishment methodology provides between 112 and Derive key from existing partition secret or private (Cert #A480) 256-bits of encryption strength. key object. Curves Non-NIST (as per [FIPS 140-3 IG] C.A): see Table 2-3 Algorithm implementation used when HSM Policy above. (43) Enable low-level math acceleration is enabled. KAS-ECC-SSC Key establishment methodology provides between 112 and Derive key from existing partition secret or private (Cert #A478) 256-bits of encryption strength. key object. Curves Non-NIST (as per [FIPS 140-3 IG] C.A): see Table 2-3 As per services mapped to KAS-ECC-SSC for Cert above for curves over a binary field – GF(2m) exclusively. #A480 above but where this implementation is only exercised for the listed curves and when HSM Policy (43) Enable low-level math acceleration is disabled. Table 2-5: Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed N/A N/A N/A

NOTE The module is capable of supporting a single mode of operation. Transition from an

approved to non-approved mode of operation automatically triggers HSM zeroize or

decommission module service.

Algorithm / Function Symmetric Encryption / Decryption

Use / Function

Cryptographic Module Specification Non-Approved security functions are not available for use when the module has been configured to operate in the approved mode (see section 13.2). The following table lists non-approved algorithms supported for use with certain user consumable services when the module is configured in the non-Approved mode of operation during secure initialization. Table 2-6: Non-approved algorithms not allowed in the approved mode of operation. ARIA Perform decrypt operation on user supplied data object, Perform encrypt operation on CAST3 user supplied data object, Derive key from CAST5 existing partition secret or private key object, Import secret or private key using key DES wrapping RC2 RC4 RC5 RSA (non-compliant with less than 112 bits of encryption strength) RSA X.5099 SEED SM4 Triple-DES (non-compliant for encrypt operations) XOR 10 Hashing HAS-160 Derive key from existing partition secret or private key object, Validate signature or MAC KECCAK over user supplied data, Perform digest MD2 operation on user supplied data MD5 RIPEMD-160 SM3 Message Authentication Code ARIA-CMAC SEED-CMAC this algorithm allows RSA encryption of a supplied data object without the use of padding. Any required padding is added by the operator ahead of supplying the data to this variant of the RSA encrypt/decrypt f unction. this algorithm allows the operator to XOR supplied data with either a supplied base key or key derived f rom a base key. This f unction is deprecated f or use in any situation where security of the data or key is required.

Algorithm / Function

Use / Function

Cryptographic Module Specification Triple-DES-CMAC (non-compliant for MAC generation) Generate signature or MAC over user supplied data, Validate signature or MAC HMAC (non-compliant with less than 112 bits of encryption strength) over user supplied data HAS160-HMAC MD5-HMAC SM3-HMAC RIPEMD160-HMAC AES-MAC ARIA-MAC CAST3-MAC CAST5-MAC DES-MAC RC2-MAC RC5-MAC SEED-MAC SSL3-MD5-MAC SSL3-SHA1-MAC Triple-DES-MAC Triple-DES-x9.19-MAC TUAK MILENAGE COMP128 Asymmetric DSA (non-compliant with less than 112 bits of encryption strength) Generate signature or MAC over user supplied data, Validate signature or MAC ECDSA (non-compliant with less than 112 bits of encryption strength) over user supplied data EdDSA EdDSA PH KCDSA RSA (non-compliant with less than 112 bits of encryption strength) SM2 SM3 Key Derivation AES 11 Derive key from existing partition secret or private key object ARIA BIP32 DES

11 AES is non-approved for key derivation when used to derive keys using methods other than as permitted by NIST standard such

as [SP800-56Cr2] and [SP800-108r1] in particular, use of AES in ECB or CBC mode directly to derive keys.

Algorithm / Function

Use / Function

Cryptographic Module Specification MD5 SHA 12 SSL PRE-MASTER SSL3-MASTER SM3 Triple-DES XOR 13 Key Agreement ECC (non-compliant with less than 112 bits of encryption strength) Derive key from existing partition secret or private key object Diffie-Hellman (key agreement; key establishment methodology; non-compliant with less than 112 bits of encryption strength) Key Transport AES 14 Import secret or private key using key wrapping, Export secret or private key using ARIA key wrapping, Clone partition objects CAST3 between partitions 15 CAST5 DES RC2 RSA (key wrapping; key establishment methodology; non-compliant with less than

RSA 16 SEED SM4 TDES Asymmetric Key Generation Diffie-Hellman (non-compliant with less than 112 bits of encryption strength) Generate local symmetric or asymmetric keypair, Generate domain parameters . ECC (non-compliant with less than 112 bits of encryption strength) KCDSA RSA (non-compliant with less than 112 bits of encryption strength) SM2 X9.42 Domain Parameter Generation SHA1, SHA2 and SHA3 are non-approved f or key derivation when they are used to derive keys in a way that is non-compliant with NIST standards such as [SP800-56Cr2], [SP800-108r1], [SP800-132] and [SP800-135r1]. XOR is non-approved f or key derivation when selected as a mechanism to combine supplied user data with an existing module stored key. AES is non-approved f or key transport when used to encrypt keys using methods other than as permitted by NIST standards such as [SP80038F]. In particular, use of un-authenticated modes of AES f or encryption without a separate authentication tag (e.g. signature or MAC) is nonapproved. this service uses both [SP800-56Br2] non-compliant RSA encryption f or encryption of a nonce f ollowed by AES encryption of key objects in a [SP800-38F] non-compliant manner when Cloning Protocol Version 1 is used f or key export. Later versions of this protocol as separately mapped to this service use approved cryptography. non-compliant when used f or key transport using RSA variants that are [SP800-56Br2] non-compliant.

The following two figures identify the physical interfaces to the cryptographic module: USB 2.0 Decommission interf ace External tamper interf ace Backup supply PCIe Bus Connector Serial port RS232 Fan 1, 12V Fan 2, 12V Figure 3-1: Thales Luna K7 Cryptographic Module physical interfaces (non-LED).

Cryptographic Module Interfaces Tamper LED (Red) General status LED (Green) General status LED (Blue) Battery LED (Green) Figure 3-2: Thales Luna K7 Cryptographic Module status LED interfaces. Where physical interfaces identified in Figure 3-1 and Figure 3-2 are outside the defined cryptographic boundary shown in Figure 2-1 and Figure 2-2, the physical port as listed in the following table corresponds to the internal tracking on the PCB from the physical interface to the module at the point it crossed the cryptographic module boundary. The following table maps the physical interface to logical interfaces and supported data: Table 3-1: Ports and interfaces. Signals crossing the module boundary are the raw USB 2.0 data packets prior to the addition of physical layer signalling (PHY) and voltage level shif ting.

NOTE Interactive mode is a state for the module bootloader where rather than

following through a sequence of steps that lead directly to execution of the main

firmware without operator intervention, the bootloader can be halted during boot and

enters into a state where for a limited period of time, it will offer a number of services

in response to commands it receives on the modules serial port.

Services supported are as covered under the ‘bootloader services’ section of Table 4-2.

Roles

Principal Duties

Roles, Services, and Authentication

The Thales Luna K7 Cryptographic Module supports the following roles: Table 4-1: Thales Luna K7 Cryptographic Module Roles HSM Security Officer (HSM SO) The HSM SO is responsible for managing the HSM. As such, the HSM SO is authorized to install and configure the HSM, set and maintain global HSM security policies and [Admin Partition Role] install FMs. He/she is also able to request the load of new HSM firmware update files (FUF) and new Configuration Update Files (CUF). The HSM SO is able to create and delete partitions, but is not authorized to generate, load or use keys stored on the user partitions that have been created. The HSM SO is able to create, manage and use keys created in the Admin Partition alongside is responsible for initializing the ‘Administrator role’. The HSM SO can reset the Administrator password (configuration dependent). The HSM can have only one HSM SO. Administrator The Administrator is authorized to create, use, transfer and destroy key objects contained in the Admin partition. This role has privileges that are a subset of the HSM [Admin Partition Role] SO role. Partition Security Officer The Partition SO creates the partition level Partition CO role, sets and changes (Partition SO) partition-level policies. This role also has an option to reset the Partition CO password (configuration dependent) following lockout. [User Partition Role] Partition Crypto Officer The Partition CO role is authorized to create, use, destroy and transfer key objects for (Partition CO) a given partition. The Partition CO can optionally create the Partition LCO and Partition CU, and perform initial assignment of key authorization data. [User Partition Role] Partition Limited Crypto Officer The Partition LCO is an optional partition role authorized to create and use key objects, (Partition LCO) and perform initial assignment of key authorization data. The role is only permitted to delete key objects where per-key authorization is used and the correct authorization [User Partition Role] data for a given key object can be presented to the cryptographic module. Partition Crypto User (Partition The Partition CU is the partition role authorized to use the key objects within the CU) partition (e.g. sign, encrypt/decrypt). [User Partition Role] Audit User (AU) The AU initializes the secret key used to generate Message Authentication Code (MAC) for secure audit messages alongside configuring logging levels for the HSM. [Admin Partition Role]

Roles

Principal Duties

NOTE All methods of authentication supported by the module (memorized secret or multi-

factor crypto device + memorized secret, incorporate the use of an ID alongside the

presentation of the authentication data and are identity based.

Role HSM Management

Service

Input

Output

Public User Unauthenticated user with limited access to perform signature verification with public keys where CKA_PRIVATE = false, initialization of the module and roles and to read Guidance on assuming a given role is covered in section 13.5, ‘Assuming Roles’. The mapping of the cryptographic module’s roles services can be found in the table below. In this table, ‘Any role’ in the ‘role’ column signifies that any role identified in Table 4-1: Thales Luna K7 Cryptographic Module Roles can access the corresponding service. This includes the ‘public user’ that is an implicit role and HSM SO (admin partition). Set partition policy partition policy number, return code.

Role Management

Query role status.

session, role.

Roles, Services, and Authentication certificate, return code. HSM SO (admin or                  Manage STC client                 session, client identity        return code. un-initialized user partition).                                     certificate. Partition SO (user partition). HSM SO (admin or                  Query STC status                  session, client identity.       client status, return code. un-initialized user partition). Partition SO (user partition). Any role.                         Initiate STC tunnel.              -                               return code. Partition CO, Partition LCO,      partitions. Partition CU calculated fingerprint (disabled), return code. Any role.                         Query role status.                session, role.                  role status, return code.

Luna PED Configuration

Roles, Services, and Authentication HSM SO, Administrator, AU,                                         password authentication). Partition SO, Partition CO, Partition LCO, Partition CU, Public User (required to initialize HSM SO, AU or Partition SO). Partition SO (required to Partition CU). HSM SO).                                                           authentication data.            configuration), return code. AU (required to change AU). HSM SO or Administrator Administrator). Partition SO (required to change Partition SO and Partition CO) Partition CO or Partition LCO Partition LCO). Note: Roles are not changed, only the role authentication HSM SO, Administrator, AU,       Configure partition for high-     session, HA Login key           return code. Partition LCO, Partition CU. HSM SO, Administrator, AU,       Login as role.                    session, role ID,               return code. Partition LCO, Partition CU. Any role.                        Close authenticated sessions.     -                               return code. HSM SO.                          Initialize Remote PED Vector      -                               return code.

Key Management Activities

Cryptographic Services

Re-seed partition DRBG.

session, seed.

Roles, Services, and Authentication algorithm, algorithm            return code. Partition CO, Partition LCO.     using key wrapping.                algorithm, algorithm            return code. Partition CO, Partition LCO,     using SKS.                                                         return code. Partition CU. Partition CU. HSM SO, Administrator,           Re-seed partition DRBG.            session, seed.                  return code. Partition SO, Partition CO, Partition LCO, Partition CU.

Bootloader Services

Functionality Module Management

Partition CO, Partition LCO, Partition CU. Partition CO, Partition LCO, Partition CU. Partition CU. HSM SO, Administrator.          Activate SMFS.                      -                               return code. Any role.                       Delete FM.                          FM ID                           return code. Any role.                       Delete SMFS.                        -                               return code. Partition SO is able to validate signatures using public keys where CKA_PRIVATE is set to 0.

Roles, Services, and Authentication

All roles, except for the Public User, must authenticate to the module by providing their authentication data. If configured with PED, all roles must authenticate using an iKey. When a role is initialized, a module generates the authentication data as a 48-byte random value and writes it to a iKey. Optionally, the Crypto-Officer, Limited Crypto Officer and Crypto-User roles can be configured to use two-factor authentication by also assigning a password to the role. If configured with Password, all roles must authenticate using a minimum of an 8-character password. When a role is initialized under this configuration, the operator enters the initial password for the role. Regardless of configuration (PED or Password), the password is delivered to the module encrypted with the public key from the Password Encryption Certificate (PEC) using KTS-OAEP-basic from [SP800-56Br2]. Table 4-3: Roles and Authentication HSM SO Memorized Multi-Factor Crypto Device. iKey: 48-byte random authentication data generated when a Secret. role is initialized and stored on iKey. The probability of guessing the authentication data in a single attempt is 1 in 2384. With a Auditor Memorized Multi-Factor Crypto Device. maximum of 6000 failed login attempts per minute. User provided byte array (minimum 8 bytes): Memorized secret Partition SO Memorized Multi-Factor Crypto Device. when set using tools supplied with the module are limited to a Secret. character set of 86 characters 19 presented to the module as their ASCII byte representation. The strength of an 8 character Secret. + optional Memorized password with character set size of 86 is log2(868). This makes the probability of guessing the memorized secret in a single attempt 1 in 251 The module supports a maximum of 6000 failed Partition LCO Memorized Multi-Factor Crypto Device login attempts per minute when the failed login count for a Secret. + optional Memorized given role is disabled. Secret. Automatic lock-out: This feature, which is enabled by default, Partition CU Memorized Multi-Factor Crypto Device can be used to limit the impact of brute force attacks on login Secret. + optional Memorized and is covered in more detail in section 4.2.3. Public User Not Required. N/A. N/A. When using the password authentication mechanism, the module encrypts a known check-word under a key derived using PBKDF from [SP800-132] and option 1a from section 5.4, ‘Using the Derived Master Key to Protect Data’. During a login attempt, the module generates a key from the supplied password, and attempts to decrypt a known checkword. Successful login is achieved if the decrypted checkword matches the expected value. If successful, the PBKDF derived key is used to remove a layer of encryption from the module stored User Storage Key (USK) 20. Supported characters by tools used with the module to conf igure memorized secret are limited to: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 !@#$%^*()-_=+[]{}/:',.~ When ‘decommission’ is enabled as a module capability, the USK is independently encrypted in storage under a 256-bit module generated AES key.

Roles, Services, and Authentication The length of the password used as input to the PBKDF function is consistent with the password length selected by the authenticating user, which is required to be between 7 and 255 characters long. Where passwords are randomly generated, the probability of successfully guessing the password and deriving the storage key for a minimum password length of 7 characters is 1 in 256. This probability is significantly reduced if random passwords are not used. Guidance in Appendix A, ‘Security Considerations’ of [SP800-132] should be consulted when picking an appropriate password length in situations where encryption layers derived from the user password are required to protect the confidentiality of module protected user keys. The module uses an iteration count of 1000 when generating the key used to decrypt the checkword. This limit has been set to account for the fact that objects encrypted under the [SP800-132] derived key are never exported from the module and are exclusively stored inside its cryptographic boundary where they are physically protected. In addition, the module supports lock-out of all identities following a configurable number of failed login attempts where this is the primary mechanism offered by the module to protect against bruteforcing of memorized secret.

If PED authentication is configured, the Crypto-Officer, Limited Crypto Officer and Crypto-User roles can be configured to use a two-step authentication process. The first stage is termed “Activation” and is performed using a PED key. Once activated, access to key material and cryptographic services is not allowed until the second stage of authentication, ‘User Login’, has been performed using the role’s password. Once activated, a role stays activated until the role is explicitly deactivated, deleted or the module is reset 21.

In addition to the cryptographic strength of the authentication mechanisms, all authenticating roles have the ability to maintain a failed authentication count that can be configured to stop attempts to brute force authentication data. The maximum supported failed authentication attempts can be set to between 3 and 10 for each role with the following lockout behaviors observed:

All services listed in the table below can be accessed in approved mode and when in this mode exclusively use the security functions listed in Table 2-2 and When the module is operating in this mode, security functions in section 2.5 are disabled and blocked from being used. As notes on the content of Table 4-4: A module is reset in response to a trigger signal being received on the External Event input, Decommission signal and EFP violations, loss of power or a request f rom a host application.

NOTE While default setting for HSM Policy (52), Restrict FM Privilege is this setting is only false,

relevant to a FIPS approved configuration following load of the ‘Enable Functionality Module CUF’.

This unlocks the ability to enable the related ‘HSM Policy (50) Allow Functionality Modules’. Prior

to HSM Policy (50) being set to , the setting of HSM Policy (52) Restrict FM Privilege is true

redundant to the modules operation as functionality modules can’t be loaded and the policy only

relates to commands received by the module from within code executing within a sandboxed

functionality module.

Roles, Services, and Authentication

Factory reset deletes all roles (including HSM SO), all users and objects and sets all HSM settings and policy to values defined in pre-loaded configuration update files.

Algorithms: N/A. Key management technique: N/A. Authentication technique: N/A.

PSK, USK, DRBG Key, DRBG Seed, DRBG V, KCV, SMK, STC-PIDPUB, STC-PIDPRIV, STC- CIDPUB, STC-PIDPUB, STC-PKAPUB, STC-PKAPRIV, STC-CKAPUB, STC- PEN, STC-PMA, STC-PIV, STC- CEN, STC-CMA, STC-CIV, HAPUB, HAPK, RND, Asymmetric Key Pairs (general partition or session keys), Symmetric Keys (general partition or session keys), DRBG Key, SALK, CWKHSM, CWKPED, DEKHSM, DMKHSM, DEKPED, DMKPED, AEK, AEK-EK, AccessID.

Any role.

Z: (for ALL partition) PSK, USK, DRBG Key, DRBG Seed, DRBG V, KCV, SMK, STC-PIDPUB, STC-PIDPRIV, STC- CIDPUB, STC-PIDPUB, STC- PKAPUB, STC-PKAPRIV, STC- CKAPUB, STC-PEN, STC-PMA, STC-PIV, STC-CEN, STC- CMA, STC-CIV. HAPUB, HAPK, RND, Asymmetric Key Pairs (general partition or session keys), Symmetric Keys (general partition or session keys). In addition, the following HSM level keys are erased: DRBG Key, SALK, CWKHSM, CWKPED, DEKHSM, DMKHSM, DEKPED, DMKPED. E: AEK, AEK-EK, AccessID.

To initiate and use STC the HSM SO must have done the initial conf iguration prior to running the command.

This service uses the cloning protocol to establish a shared key between source and destination partitions and then to transfer a selected SMK encrypted under this shared key between partitions. Either CPV3 or CPV4 is supported for both import and export of SMK.

Algorithms: CPV4: CTR_DRBG (Cert #C1707), AES (Cert #C1707)

• AES- 256 in GCM mode or CTR and either HMAC-SHA2-512 or HMAC-SHA3-512 (Cert #C1707). CPV3: CTR_DRBG (Cert #C1707), AES (Cert #C1707)
• AES- 256 in KWP. Key management technique: ESV (Cert #98), CKG, SHA (Cert #C1707)
• SHA2-512, CTR_DRBG (Cert #C1707), SHA (Cert #C1707)
• SHA2-512. CPV4 - KAS (Cert #A480)
• Ephemeral Unified and OneStep KDF (with pre-shared 256-bit key as additional input) with either-SHA2-512 or SHA3-512 as the PRF. CPV3 - KAS (Cert #A480)
• KAS1-basic using 4096-bit modulus and OneStep KDF (with pre-shared 256-bit key as additional input) with SHA2-512. Authentication technique: Single- Factor Crypto Software.

DRBG Key, DRBG Seed, DRBG V, Root Certificate, MIC, HOC (or FM equivalent), KCV and Cloning Transfer Key, SMK, AEK, AEK-EK, AccessID and; CPV3 KEVt, TUK4, TWK4. CPV4 CPV4 Key Agreement Private Key, CPV4 Key Agreement Source Public Key, CPV4 Key Agreement Source Destination Public Key, CPV4 Key Agreement Shared Secret, CPV4 Key Transport Key, CPV4 Session Key, CPV4 Session Salt, CPV4 Per-Blob Salt, CPV4 Per-Blob Encryption Key, CPV4 Per- Blob MAC Key, CPV4 Messaging Private Key, CPV4 Messaging Public Key.

HSM SO is able to clone (or receive) the SMK from/to the Admin Partition. Partition CO is able to clone (or receive) the SMK from/to the user partition.

G/E: KEVs, KEVt, CPV4 Key Agreement Private Key, Key Agreement Source Public Key, CPV4 Key Agreement Shared Secret, CPV4 Key Transport Key, CPV4 Session Key, CPV4 Session Salt, CPV4 Per-Blob Salt, CPV4 Per-Blob Encryption Key, CPV4 Per-Blob MAC Key, Cloning Transfer Key. E: DRBG Key, DRBG Seed, DRBG V, Root Certificate, MIC, HOC (or FM equivalent), TWC3, TWK3 TUK4, TWK4, CPV4 Messaging Private Key, CPV4 Messaging Public Key, KCV, Key Agreement Destination Public Key, AEK, AEK-EK, AccessID. R/W: SMK. W: DRBG Key, DRBG Seed, DRBG V.

Roles, Services, and Authentication

Role Management

This service returns status in relation to a target role (e.g. whether the role is initialized or not).

Algorithms: N/A. Key management technique: N/A. Authentication technique: N/A.

AEK, AEK-EK, AccessID.

Any role.

E: AEK, AEK-EK, AccessID.

This service triggers creation of the module Remote PED Vector. As part of this service, keys used by the PED for remote PED setup are written to an orange PED key connected to Thales Luna PED during initiation of the service.

Algorithms: AES (Cert #C1707)

• KWP mode with 256-bit key. Key management technique: ESV (Cert #98), CKG, SHA (Cert #C1707)
• SHA2-512, CTR_DRBG (Cert #C1707), ECDSA (Cert #C1707)
• Key Generation and Signature Generation over curve P521. Authentication technique: Single- Factor Crypto Software, Multi- Factor Crypto Device.

GSK, RPV, RPV-C, RPV-K, PED- SKA-C and PED-SKA-K, AEK, AEK-EK, AccessID.

HSM SO.

E: GSK, AEK, AEK-EK, AccessID. G: PED-SKA-C and PED-SKA- K. W: RPV, RPV-C, RPV-K.

Key Management Activities

This service is used to generate symmetric keys or asymmetric key pairs requested by the end- user and stored in the cryptographic module for use with other user consumable cryptographic services or to export to other cryptographic modules or systems.

Algorithms: AES (Cert #C1707)

• KWP mode with 256-bit key. Key management technique: ESV (Cert #98), CKG, SHA #C1707)
• SHA2-512, CTR_DRBG (Cert #C1707), RSA (Cert #C1707)
• Key Generation (all supported methods and curves), ECDSA (Cert #C1707 - Key Generation (all supported methods and curves). Authentication technique: N/A.

USK, DRBG Key, DRBG Seed, DRBG V, Asymmetric Key Pairs (general partition or session keys), Symmetric Keys (general partition or session keys), DRBG Key, DRBG Seed, DRBG V, AEK, AEK-EK, AccessID.

HSM SO, Administrator (for admin partition keys). Partition CO, Partition LCO (for user partition).

E: USK, DRBG Key, DRBG Seed, DRBG V, AEK, AEK-EK, AccessID. W: Asymmetric Key Pairs (general partition or session keys), Symmetric Keys (general partition or session keys), DRBG Key, DRBG Seed, DRBG V.

Public users cannot generate any objects where either CKA_SENSITIVE or CKA_PRIVATE attributes are true. As such, the service would not af f ect the security of the module or the security of the inf ormation being protected, as sought by 4.1.A.

Public users cannot generate/import any objects where either CKA_SENSITIVE or CKA_PRIVATE attributes are true. As such, the service would not af f ect the security of the module or the security of the inf ormation being protected, as sought by 4.1.A.

Partition SO is able to validate signatures using public keys where CKA_PRIVATE is set to 0.

Functionality Module Management

The FM must f irst be activated by the HSM SO in order to store/retrieve data f rom SMFS.

NOTE While default setting for HSM Policy (52), Restrict FM Privilege is this setting is only false,

relevant to a FIPS approved configuration following load of the ‘Enable Functionality Module CUF’.

This unlocks the ability to enable the related ‘HSM Policy (50) Allow Functionality Modules’. Prior

to HSM Policy (50) being set to , the setting of HSM Policy (52) Restrict FM Privilege is true

redundant to the modules operation as FM can’t be loaded and the policy only relates to

commands received by the module from within code executing within a sandboxed functionality

module.

Roles, Services, and Authentication

Non-approved services listed in the table below are not available when the module has been configured to operate in the approved mode (see section 13.2). As notes on the content of Table 2-6: > In the ‘Indicator Column’:

• IND_1
• Partition Policy (42) Enable CPv1 is set to false, Partition Policy (43) Enable nonPolicy (56), Allow User Defined ECC Curves is set to false, AND return code is CKR_OK;

27 RSA is non-compliant when using PKCS#1, v1.5 padding for encryption or decryption.

28 RSA is non-compliant with less than 112 bits of encryption strength.

29 Triple-DES is non-compliant with less than 112 bits of encryption strength.

30 HMAC is non-compliant with less than 112-bits of encryption strength.

Service

Description This service is not possible for the Backup configuration. This service is used by a user to request validation of a signature or MAC over a block of user-supplied data using a module stored cryptographic key. The service returns whether the validation was successful. This service is not possible for the Backup configuration.

Non-Approved Algorithms Accessed Asymmetric Algorithms: DSA31, ECDSA32, EdDSA, EdDSA PH, KCDSA, RSA33, SM2, SM3. Symmetric Algorithms: ARIA-CMAC, SEED-CMAC, Triple-DES- CMAC34, HMAC35, HAS160-MAC, MD5-HMAC, SM3-HMAC, RIPEMD160-HMAC, AES-MAC, ARIA-MAC, CAST3-MAC, CAST5- MAC, DES-MAC, RC2-MAC, RC5-MAC, SEED-MAC, SSL3-MD5- MAC, SSL3-SHA1-MAC, Triple-DES-MAC, Triple-DES-x9.19-MAC, TUAK, MILENAGE, COMP128. Asymmetric Algorithms: DSA36, ECDSA37, EdDSA, EdDSA PH, KCDSA, RSA38, SM2, SM3.

Roles HSM SO, Administrator, Partition CO, Partition LCO, Partition CU

Indicator

HSM Management

This service supports use of CPV1 for key object import and export exclusively.

AES, RSA.

HSM SO, Administrator, Partition CO, Partition LCO, Partition CU

Key Management Activities

This service is used to derive keys based on other key material stored in the module or supplied to it on request of the end-user. Derived keys are stored in the cryptographic module for use with other user consumable cryptographic services or to export

AES40, ARIA, BIP32, DES, MD5, SHA, SSL PRE-MASTER, SSL3- MASTER, SM3, Triple-DES, XOR.

HSM SO, Administrator, Partition CO, Partition LCO

Asymmetric Algorithms: DSA 31, ECDSA 32, EdDSA, EdDSA PH, Asymmetric Algorithms: DSA 36, ECDSA 37, EdDSA, EdDSA PH, DSA is non-compliant with less than 112 bits of encryption strength. ECDSA is non-compliant with less than 112 bits of encryption strength. RSA is non-compliant with less than 112 bits of encryption strength. Triple-DES-CMAC is non-compliant with less than 112-bits of encryption strength. HMAC is non-compliant with less than 112-bits of encryption strength. DSA is non-compliant with less than 112 bits of encryption strength. ECDSA is non-compliant with less than 112 bits of encryption strength. RSA is non-compliant with less than 112 bits of encryption strength. this service uses both [SP800-56Br2] non-compliant RSA encryption f or encryption of a nonce f ollowed by AES encryption of key objects in a [SP800-38F] non-compliant manner when Cloning Protocol Version AES is non-approved f or key derivation when use to derive keys using methods other than as permitted by NIST standard such as [SP800-56Cr2] and [SP800-108r1] in particular, use of AES in ECB or CBC

Service

Description to other cryptographic modules or systems. This service is not possible for the Backup configuration. This service is used to generate symmetric keys or asymmetric key pairs requested by the end-user and stored in the cryptographic module for use with other user consumable cryptographic services or to export to other cryptographic modules or systems. This service is not possible for the Backup configuration This service is used to import secret or private key from the admin or user partitions using key wrapping Unauthenticated symmetric encryption is permitted for key unwrapping under Uses allowances in [FIPS 140-3 IG] D.G, Key transport methods. This service is not possible for the Backup configuration. This service is used to export secret or private key from the admin or user partitions using key wrapping. This service is not possible for the Backup configuration.

Non-Approved Algorithms Accessed Diffie-Hellman41, ECC42, KCDSA, RSA43, SM2. ARIA, CAST3, CAST5, DES, RC2, RSA44, SEED, SM4. AES45, ARIA, CAST3, CAST5, DES, RC2, RSA, SEED, SM4, TDES.

Roles HSM SO, Administrator, Partition CO, Partition LCO HSM SO, Administrator, Partition CO, Partition LCO HSM SO, Administrator, Partition CO, Partition LCO

Indicator

Dif f ie-Hellman key generation mechanisms are non-compliant with less than 112-bits of encryption strength. ECC key generation mechanisms are non-compliant with less than 112-bits of encryption strength. RSA key generation mechanisms are non-compliant with less than 112-bits of encryption strength. RSA is non-approved f or key transport when used with an encryption strength of 112-bits or when using PKCS #1, v1.5 padding f or encryption. AES is non-approved f or key transport when used to encrypt keys using methods other than as permitted by NIST standards such as [SP800-38F]. In particular, use of un-authenticated modes of AES f or encryption without a separate authentication tag (e.g. signature or MAC) is non-approved.

Service

Description This service is used to generate domain parameters requested by the end-user and stored in the cryptographic module for use with other user consumable cryptographic services or to export to other cryptographic modules or systems.

Non-Approved Algorithms Accessed X9.42 Domain Parameter Generation

Roles Any role

Indicator

Public users cannot generate any objects where either CKA_SENSITIVE or CKA_PRIVATE attributes are true. As such, the service would not af f ect the security of the module or the security of the inf ormation being protected, as sought by 4.1.A.

The Thales Luna K7 Cryptographic Module’s firmware integrity is checked on startup as described in section 10.1. The bootloader runs the self-test functions to check the firmware integrity as well as the cryptographic algorithms used to check the bootloader and main firmware image authenticity. Any failures during these tests will result in a module halt in which an error message is output, the module halts all functions and data output is inhibited. The main firmware image is used to check the integrity of any loaded FM. The bootloader and firmware are stored as signed binaries using RSA PKCS #1-v1.5 with a 4096-bit module and SHA2-384. The operator can trigger an on-demand check of the module firmware using the CA_SelfTest Cryptoki API command. An example of the CA_SelfTest Cryptoki API command in use can be found in section 13.3. Periodic Self-Tests (PST) are performed every 24 hours and run the firmware integrity tests and a subset of the KAT tests. Failure of either of these self-tests during PST will trigger a module halt. Recovery from this state will require the module to be restarted and for the detected fault to have cleared otherwise the module will re-halt during POST following restart. See Section 10 for additional information about the PST.

All FM images downloaded into the module must have an assigned signature from the FM developer. FMs are only executed inside the HSM after this signature has been validated. The FM code authenticity and integrity is protected using RSA #1 v1.5 signature with SHA2-512 digest and a minimum of 2048-bit modulus.

When new main firmware is to be loaded using the hsm updatefw LunaCM command, a separate mechanism is used to authenticate the firmware than the pre-operational firmware self-test. An example of the hsm updatefw LunaCM command can be found in section 11.11. Once initiated the firmware load sequence uses a set series of ICD commands and all others are prohibited until the firmware update is completed. Updating the main firmware is a two stage process. The first stage is to download the main firmware to the module. The second stage involves subsequently re-authenticating and loading the main firmware following a module restart, this occurs based on the bootloader during power-on ahead of the communications module being started. The firmware load test can be found in Table 10-2.

The following are the firmware components included on the module: > hsm - this component is compiled as a 32bit LSB executable for PowerPC. This is identified throughout this document as the ‘main firmware’. > bootloader - the bootloader is an Executable and Linkable Format (ELF) executable. This is identified throughout this document as the ‘bootloader’.

Software/Firmware Security No source code, object code or just-in-time compiled code are included in the module. This scope of this certification does not currently include any certified FM where these are expected to have independent FIPS 140-3 certificates. As such, no components covering FM are listed in this section.

The module supports a limited operating environment as defined in [ISO/IEC 19790:2012]. The only changes to the environment permitted in the approved mode of operation is through the loading of FM where the loaded FM has been [FIPS 140-3] certified to run on Thales Luna K7 Cryptographic Module.

Physical Security Mechanism

Recommended Frequency of Inspection/Test On receipt of HSM following transport; At any point following any un-authorized access to the environment hosting the HSM; and Following any extended periods of unattended storage for the module.

Inspection/Test Guidance Details

The module is of physical embodiment multi-chip embedded and supports physical security level 3. The module is enclosed in a strong metal enclosure that provides tamper-evidence. Any tampering that might compromise a module’s security is detectable by visual inspection of the physical integrity of a module. The HSM SO should perform a visual inspection of the module at regular intervals. Within the metal enclosure, a hard opaque epoxy covers the circuitry of the cryptographic module. Attempts to remove this epoxy will cause sufficient damage to the cryptographic module so that it is rendered inoperable. The module’s enclosure is opaque to resist visual inspection of the device design, physical probing of the device and attempts to access sensitive data on individual components of the device.

The module supports a physical interface for the input of an external event signal. The external event signal jumper is monitored in both the powered-on state and the powered-off state. In the event of an external event signal, the module will erase the Token Module Variable Key, reset itself, clear all working memory and log the event. The module can be reset and placed back into operation when the external event signal is removed.

The module detects removal from the PCI-E slot in both the powered-on state and the powered-off state. If the card is removed from the PCI-E slot, the Token Module Variable Key (TVK) is erased and the event is logged.

The module supports an EFP mechanism that will trigger module shutdown if low or high temperature extremes and out-of-range voltage conditions are detected whilst the module is active. This is covered in more detail in section 7.3. The following routine inspections are recommended. surfaces for signs of tamper.

Physical Security Following manufacture, both the front and rear covers of the Thales Luna K7 Cryptographic Module are permanently adhered to the PCB assembly using epoxy resin and with the lid assemblies having feet set into the epoxy. Any attempts to remove the covers will result in significant physical damage to the card rendering it unusable. Example (but not exhaustive) pictures of potential attempts to tamper a card are shown in the figure below: Figure 7-1: Example indicators of a tamper event during shipping (prizing at module corners). In the event of any observed damage, photograph the card and contact Thales to confirm whether observed anomalies are to be expected or are confirmed signs of potential tampering.

The module’s hardware is designed to sense and respond to out-of-range temperature conditions as well as out-of-range voltage conditions. The temperature and voltage conditions are only monitored in the poweredon state. In the event that the module senses an out-of-range temperature or over voltage, the module will erase the TVK, reset itself, clear all working memory and log the event. The module can be reset and placed back into operation when in-bound operating conditions have been restored The module monitors three voltage rails: 5V, 3.3V and 1.8V each of which can independently trigger an EFP event. The following table covers the limits enforced by the module:

The module PCB is potted using an epoxy-based compound inside the area identified as cryptographic boundary in Figure 2-1 and Figure 2-2. The potting compound is applied directly to the PCB inside a fence. Heatsinks are anchored to the potted area during the curing process. The following table lists the temperature range tested during the assessment of the module.

NOTE Hardness temperature covered the temperature range permitted for storage of the

module. The modules operational temperature range sits within these values.

Further details on the operating ranges for the module for both input voltage and

temperature can be found in section 13.4.

N/A: [ISO/IEC 19790:2012] Section 6.8, Non-invasive security is non-applicable as there are currently no requirement in [SP800-140F].

NOTE A HSM wipe-out (KDM3) zeroizes all keys and CSPs on the module. This method

applies to every row in Table 9-1 and is explicitly called out in the table only if the SSP is not

covered by any other destruction method.

The following table lists Sensitive Security Parameters (SSP) used to perform approved security function The following notes should be observed when reading the table:

SSP Management Table 9-1: Summary of SSPs [SP800-90Ar1]                                                                                            KEK encrypts all sensitive values and is zeroized in This key is a CSP. manufacture as part                                                                the Root Key. It is self-signed with its private key Root Certificate                      RSA (#C1707,                               of the bootloader                                                                  controlled by Thales. Used in verifying Firmware Signing                                                                                                                                                    The X.509 public subordinate certificate signed by Certificate                        RSA (#C1707,                                                                                                                  “Root Private” signing key used to certify HSM This key is a PSP. Capability Signing                                                                                                                                                   The X.509 public subordinate certificate signed by Certificate                         RSA (#C1707,                                                                                                                  “Root Private” signing key used to certify HSM The X.509 public key certificate corresponding to Manufacturer’s                                                                                                                                                      the Manufacturing Integrity Key (MIK) controlled Integrity Certificate                   RSA (#C1707,                                                                                                                  by Thales. It is signed by the Root Key. Used in 150-bit.      #C1717, #C1718                                                         N/A.                                                   verifying all key material certified by Hardware 4096-bit public key                     and #C1719).                                                                                                                  Origin Certificates (HOCs). This key is a PSP. ECC Manufacturing Integrity Certificate                                                                                                                                                 The X.509 public key certificate corresponding to (ECC MIC)                          ECDSA (Cert                                                                                                                   the ECC Manufacturing Integrity Key (ECC MIK). It for public key on                                                                                                                                                   This key is a PSP. curve P-384. Full HSM Wipe -       A 4096-bit RSA private key used to sign certificates Hardware Origin Key                                                                                                                             KDM3                  for other device key pairs, such as the TWC4 used

SSP Management The X.509 public key certificate corresponding to Hardware Origin                                                                                                                                                 the HOK. It is signed by the Manufacturer’s Certificate (HOC)                     RSA (#C1707,                                                                                                              Integrity Key (MIK) at the time the device is 150-bit.      #C1717, #C1718                                                     N/A.                                                   manufactured. Used in verifying all key material and #C1719).                                                                                                              signed by the HOK. A 4096-bit RSA private key used to sign certificates FM Hardware Origin                      RSA (#C1707,                                                                                                              for other device key pairs, such as the TWC4. It is This key is a CSP. The X.509 public key certificate corresponding to FM Hardware Origin                                                                                                                                                the FM HOK. It is signed by the Manufacturer’s Certificate (FM HOC)                    RSA (#C1707,                                                                                                              Integrity Key (MIK) at the time the device is 150-bit.      #C1717, #C1718                                                     N/A.                                                   manufactured. Used in verifying all key material and #C1719).                                                                                                              signed by the FM HOK. This key is a PSP. ECC Hardware Origin                                                                                                                         Full HSM Wipe -       ECC P-384 private key used to sign other device Key                                                                                                                                  KDM3                  keys and used for a specific PKI implementation (ECC HOK)                                                [FIPS 186-4],                                             Flash memory                               requiring assurance that a key or a specific action Appendix B.4.1.                                           encrypted with GSK   Erased when FM        originated within the hardware crypto module. ECC private key on                     #C1718). curve P-384.                                                                                                                             KDM3                  This key is a CSP. The X.509 public key certificate corresponding to ECC Hardware Origin                                                                                                                         Full HSM Wipe -       the ECC HOK. It is signed by the ECC Certificate                                                                                                                            KDM3                  Manufacturing Integrity Key (ECC MIK). It is used (ECC HOC)                          ECDSA (Cert [FIPS 186-4],     Certificate Output in                   Flash memory                               for a specific PKI implementation requiring ECC public certificate                                       Appendix B.4.1.   Plaintext.                              plaintext            Erased when FM        assurance that a key or a specific action originated for public key on                                                                                                                         policy is enabled –   within the hardware crypto module. curve P-384.                                                                                                                            KDM3 This key is a PSP. FM ECC Hardware                                                                                                                                                  ECC P-384 private key used to sign other device Origin Key                                                                                                                                                    keys and used for a specific PKI implementation (FM ECC HOK)                                               [FIPS 186-4],                                             Flash memory         Full HSM Wipe -       requiring assurance that a key or a specific action Appendix B.4.1.                                           encrypted with GSK   KDM3                  originated within the hardware crypto module. ECC private key on                     #C1718). curve P-384.                                                                                                                                                   This key is a CSP.

SSP Management The X.509 public key certificate corresponding to FM ECC Hardware                                                                                                                                                       the FM ECC HOK. It is signed by the ECC Origin Certificate                                                                                                                                                    Manufacturing Integrity Key (ECC MIK). It is used (FM ECC HOC)                          ECDSA (Cert ECC public certificate                                       Appendix B.4.1.      Plaintext.                                   plaintext          KDM3                 assurance that a key or a specific action originated for public key on                                                                                                                                                    within the hardware crypto module. curve P-384. This key is a PSP. Token or Module                                                                                                                                                      A 2048-bit RSA private key used with the Cloning This key is a CSP. The X.509 public key certificate corresponding to the TUK4. It is signed by the HOK. Used in RSA (#C1707,                                                                                                                   exchange of nonce (KEVs and KEVt) as part of the This key is a PSP. Token or Module                                                                                                                                                      A 4096 bit RSA private key used in the key cloning Unwrapping Key                        RSA (#C1707,                                                                                                                   protocol. It is generated each time the module This key is a CSP. Token or Module                                                                                                                                  Power Cycle –        The X.509 public key certificate corresponding to Wrapping Certificate                                                                                                                              KDM1.                the TUK4. It is signed by the HOK. Used in certificate.                                                                                                                                  change.              This key is a PSP. Cloning Key                                                                   Exchanged during                                                                     384-bit nonce used with the cloning protocol and Encryption Vector –                                          [SP800-90Ar1]
384 bit nonce.                                                                 further details).                                                                    This key is a CSP.

protocol and used to transfer key objects between This key is a CSP.

SSP Management Source Private Key curve P-521 or                                                                  key.                                                                                  This key is a CSP. between HSMs. ECC public key on        256-bit                                                                                N/A.                                                    Signed by the CPV4 Messaging Private Key of the This key is a PSP. Destination Public                                                                                                                                                      between HSMs. destination HSM. This key is a PSP. negotiation. This key is a CSP. Agreement Shared                                                                                             This key is a CSP.

SSP Management [SP800-56Cr2] and                                                                                     This key is used to MAC the encrypted object Secret alongside the                                                                                  This key is a CSP. [SP800-56Cr2] and                                                                                     Blob Encryption Key and CPV4 Per-Blob MAC Key Secret alongside the                                                                                  This key is a CSP. the CPV4 protocol                                                              generate the CPV4 Per-Blob Encryption Key and Power Cycle –        Random 256-bit salt unique per object encryption 256.                   protocol.                                                                      CPV4 Per Blob MAC Key. change.              This key is a CSP.

SSP Management [SP800-56Cr2] and                                                                                     generate a MAC over individual encrypted keys in either SHA2-512 or                                                                                    transport when AES in CTR mode is selected as the include the CPV4                                                                                      This key is a CSP. destructive policy   This key is a CSP. BrainpoolP512r1.                                                                                                                            change. Public Certificate                                                                                                                                               Certificate included with signed messages and This key is a PSP. BrainpoolP512r1.                                                                                                                             change. Power Cycle –        4096-bit RSA private key used for a specific PKI Device                                                                                                                                 KDM1.                implementation requiring assurance that a key or a change.              This key is a CSP.

SSP Management The X.509 public key certificate corresponding to Device                                                                                                                                                        the CITS-DAK. Signed by the HOK. Used for a Authentication Key                      RSA (#C1707,                                                                                                                specific PKI implementation requiring assurance 150-bit.      #C1717, #C1718                                                         N/A.                                                 that a key or a specific action originated within the 4096-bit public key                     and #C1719).                                                                                                                hardware crypto module. This key is a PSP. ECC Device Authentication Key                      ECDSA (Cert                                                                                                                 ECC P-384 private key. ECC private key on                     #C1718).                                                                                                                    This key is a CSP. curve P-384. ECC Device Authentication Certificate                                                                                                                                                    The X.509 public key certificate corresponding to (ECC DAC)                                              N/A – generated       Certificate Output in                   Flash memory         Full HSM Wipe -     the ECC DAK. It is signed by the ECC HOK. ECC public certificate                  #C1718). This key is a PSP. for public key on curve P-384. Token or Module                                                                                                                                Zeroized in         It is used to encrypt authentication data stored for measures - KDM5     This key is a CSP. Random value used to create module fingerprint Secure Transport                                                                                                                               Zeroized in [SP800-90Ar1]                                                                                          that is used to verify the module’s integrity as part 992-bits.                                              256. This key is a PSP.

DRBG Key implementation of the NIST SP 800-90Ar1 CTR This key is a CSP. conditioned output Random seed data drawn from the Hardware RBG from ESV (Cert and used to seed an implementation of the NIST platform noise This key is a CSP.

SSP Management Part of the secret state of the approved DRBG. The value is generated using the methods This key is a CSP. 256-bit AES key that is the same for all users on a specific Luna cryptographic module. It is used to Global Storage Key [SP800-90Ar1] encrypt permanent parameters within the nonThis key is a CSP. For PED configurations, this is a 256-bit value, the first 32-bytes of which are used as an AES KW 256bit key that is used to wrap/unwrap the SALK when it is exported / imported from / to the module. [SP800-90Ar1] It is either generated by the module or imprinted 256-bit. CTR_DRBG with AES- onto the module at the time audit user role is Role Domain Key

256 for PED Input / Output via initialized. The 48-byte random value is output

PED. initializing the Auditor role on additional modules For password configurations, this value is an 8 -

during configuration of the secure audit capability. This key is a CSP. A 256-bit key used to verify data integrity and [SP800-90Ar1] authentication of the log messages. Saved in the This key is a CSP. AccessID to be used in the Secure Audit logs, to Secure Audit [SP800-90Ar1] prevent against the theft of the actual AccessID. A This key is a CSP.

SSP Management PED configuration                                                               using ICD A salted hash of the                        User provided password input by the operator as a
8 - 255 character                                                                                                       encrypted with PSK.                         This key is a CSP.

data string. [SP800-56Br2]. A 256-bit key generated by the Thales Luna client and submitted to the HSM for use to wrap the AccessID Encryption HSM generated AEK for export to the Thales Luna KTS-OAEP. A new key is generated for each AEK transfer This key is a CSP. AccessID. AccessID Encryption This key is a CSP. 128-bit secret value used as an authorization token This key is a CSP. Hashed user password with 256-bit random salt. Password Hash (PED supplied by the end-user as part of login when secret. This key is a CSP.

SSP Management A 256-bit random value that is generated by the [SP800-90Ar1] Working SDRAM in module when a role is created and is written out 48-byte random 256. generation). value. This key is a CSP. User provided password input by the operator as

8 - 255 character This key is a CSP.

This key is used to encrypt all sensitive attributes User Storage Key of all private objects owned by users of a partition This key is a CSP. [SP800-90Ar1] This key is unique per-partition and used to This key is a CSP. [SP800-90Ar1] A randomly generated 256-bit secret used as the SKS Master Key CTR_DRBG with AES- master key for deriving all SKS key blob encryption This key is a CSP. HA Login Public Key A 4096-bit RSA public key used for the HA Login This key is a PSP. HA Login Private Key A 4096-bit RSA private key used for the HA Login 4096-bit private key. B.3.6. This key is a CSP.

SSP Management Wrapping Key [SP800-90Ar1] command - KDM1 authentication data for re-import from the primary 256-bits AES key. KDM1 This key is a CSP. Value that controls a partition’s ability to participate in the cloning protocol. In the case of PED configurations, it is generated by the module or imprinted onto the module at partition initialization time. Input / Output via For password configurations, this 8 - 255 character For PED configurations, the 48-byte random value is output from the original partition in the domain to a PED key to enable initializing additional modules into the domain. This key is a CSP. A randomly generated 256-bit key, which must be shared between a remote PED and a cryptographic Flash memory module in order to establish a secure encrypted with GSK communication channel between them. This key is a CSP. PED Authentication An ECC public key certificate used to verify curve P-521. destructive policy This key is a PSP.

SSP Management PED Authentication                                                                                                                                           An ECC private key used to sign certificates used Key (PAK)                          ECDSA (Cert                                                                                                           for local or remote connection with the Thales curve P-521.                                                                                                                          destructive policy This key is a CSP. HSM Static Key-                                                                                                                                             Used by the Thales Luna PED to authenticate the local HSM to connect to and to extract the HSM’s Certificate for Local                                                                                                                   KDM1 Output via direct                                                              static ECC public key for C(1e,1s, ECC CDH) key256-bit.                                             connection to a Luna       N/A.                                                agreement for local connection with a Thales Luna curve P-521.                                                                                                                                              This key is a PSP. HSM Static KeyAgreement Private                                                                                                                       Power Cycle Used by the HSM as the static private key for Key for Local                                                                                                                         KDM1 C(1e,1s, ECC CDH) key-agreement agreement for ECC private key on                                                                                                                                           This key is a CSP. curve P-521. Used by the Thales Luna PED to authenticate the HSM Static Key-                                                                                                                       Power Cycle -        remote HSM to connect to and to extract the Agreement                                                                                                                           KDM1                 HSM’s static ECC public key for: destructive policy        •     C(1e,1s, ECC CDH) DLC Key Transport curve P-521. This key is a PSP. Used by the remote HSM as the static private key HSM Static Key-                                                                                                                                             for: Agreement Private                                                                                                                       KDM1                      •     C(2e,2s, ECC CDH) key-agreement Key for Remote SKA-KREMOTE) ECC private key on                                                                                                                                                •     C(1e,1s, ECC CDH) DLC Key Transport curve P-521.                                                                                                                                                          for SSP migration This key is a CSP.

SSP Management HSM Ephemeral Key-                                                                                                                                           Used by the Thales Luna PED to authenticate the Agreement                                                                                                                                                 remote HSM to connect to and to extract the Certificate (HSM-                                                            Output via direct                                                              HSM’s ephemeral public key for C(2e,2s, ECC CDH) PED.                                                                           with a Thales Luna PED. curve P-521.                                                                                                                                              This key is a PSP. Used by the Thales Luna PED to authenticate the HSM Ephemeral Key-                                                                                                                                           remote HSM and to extract the HSM’s ephemeral Agreement Private                                                                                                                                           public key for C(2e,2s, ECC CDH) key-agreement 256-bit.                                             Not Input or Output        N/A.                                                agreement for remote connection with a Thales curve P-521. This key is a CSP. Remote PED Vector                                                                                                                       request via ICD      An ECC public key certificate used by the HSM curve P-521.                                                                                                                         Erased on user       This key is a PSP. Remote PED Vector                                                                                                                       request via ICD      An ECC private key used by the HSM to sign PEDcurve P-521.                                                                                                                         Erased on user       This key is a CSP.

SSP Management Agreement                                                                                                                                                          Used by the HSM to authenticate and extract the Certificate for                                                                                                                                                      Luna PED’s ECC ephemeral public key for C(2e,2s, PED.                                                                                    Uniquely generated for each use. curve P-521.                                                                                                                                                         This key is a PSP. KDM2 or KDM1 in      Used by the Thales Luna PED for Remote PED Static Key-                                                                                                                                   response to erase    connections. Act as An ECC static private key for Agreement Private                                                                                                                                  request via ICD      C(2e,2s, ECC CDH) key-agreement. (PED-SKA-K)                        #A480).              Appendix B.4.1.                                                     plaintext                               Key is not used by the HSM as a SP but is Erased on user       generated by it for use by the Luna PED. curve P-521.                                                                                                                                     destructive policy   This key is a CSP. Intermediate key value used during setup of the PED Master Shared                                                                                                                                                       Key is the output of the ECDH function and used to This key is a CSP. HSM CSP Wrapping                                            OneStep KDF from                              [SP800-56Ar3]                            KDM1                 Derived during Local and Remote PED Channel for

SSP Management PED CSP Wrapping                                           OneStep KDF from                              [SP800-56Ar3]                            KDM1                 Derived during Local and Remote PED Channel for HSM Data Encryption                                         OneStep KDF from                              [SP800-56Ar3]                            KDM1                 Derived during Remote PED Channel for encrypting Derived during Remote PED Channel for message authentication of communication messages (from This key is a CSP. Derived during Remote PED Channel as the initialization vector for encrypting communication This key is a CSP. PED Data Encryption                                         using SHA2-512 as                             [SP800-56Ar3]                            KDM1                 Derived during Remote PED Channel for encrypting

SSP Management Derived during Remote PED Channel for message authentication of communication messages (from This key is a CSP. Derived during Remote PED Channel as the initialization vector for encrypting communication This key is a CSP. KDM1                 A 4096-bit RSA private key used to decrypt user Password Encryption                    RSA (#C1707,         [FIPS 186-4],                                                                                                   passwords that are provided to the module. It is destructive policy   This key is a CSP. Password Encryption                                                                                                                                                         The X.509 public key certificate corresponding to Certificate (PEC)                    RSA (#C1707,         [FIPS 186-4],                                                                                                   the PEK. It is created and signed by the HOK the 150-bit.      #C1717, #C1718       Appendix                                             N/A.                                                       first it is required. certificate                                                                                                                                        command -            This key is a PSP. FM SMFS Encryption                                                                                                                                                          This key is used to encrypt data submitted by an Key (SMFSKENC)                       AES (Cert                                                                                                                            FM to the SMFS for storage. command. -           This key is a CSP. FM SMFS MAC Key                                                                                                                                                             This key is used to generate MAC over data (SMFSKINT)                                                                                                                                                              submitted by an FM to the SMFS for storage. command. -           This key is a CSP.

SSP Management Partition STC Static Public ID Key                                                                                                                                                  A 521-bit ECC public key used as the partition’s ECC public key on                                                                                                                                                 This key is a PSP. curve P-521. Partition STC Static Private ID Key                                                                                                                                                  A 521-bit ECC private key used as the partition’s ECC private key on                                                                                                                                                This key is a CSP. curve P-521. Ephemeral Public Key                                                                                                                                               A 521-bit ECC public key used as the partition’s This key is a PSP. curve P-521.                                                                                                                                KDM1 Partition STC A 521-bit ECC private key used as the partition’s ECC private key on                                                                                                                                                This key is a CSP. curve P-521. Client STC Static Public ID Key                                                                                                                                                   A 521-bit ECC public key used as the client’s static ECC public key on                                                                                                                                                This key is a PSP. curve P-521. Client STC Ephemeral                                                                                                                           Zeroized via ICD Public Key                                                                                                                                                   A 521-bit ECC public key used as the client’s (STC-CKA PUB)                     KAS-ECC (Cert                                                                      Working RAM in                           ephemeral key in the STC protocol. This key is a PSP. curve P-521.                                                                                                                                KDM1 Intermediate key value during the STC key negotiation. STC Master Shared                     from [SP800-                                                                                                                Key is the output of the ECDH function and used to 256-bit      56Cr2] and using               N/A.                 N/A.                                                                    generate the Partition STC Session Encryption and This key is a CSP.

SSP Management Partition STC Session These keys are agreed upon with a client STC-PIV, STC-CEN, hash. key pair generation. STC-CMA, STC-CIV). This key is a CSP. [FIPS 186-4], pairs that can be

SSP Management KDA (#A480) This key is a CSP.

The module includes a non-deterministic Random Bit Generator (RBG) within the module boundary. The non-deterministic RBG is used exclusively to feed an approved conditioning function where in-turn the output of the conditioning function is used to seed the DRBG (Cert #C1707). The Non-Deterministic RBG complies with [SP800-90B] and has been validated using with guidance set out in [FIPS 140-3 IG] . Table 9-2: Non-Deterministic Random Number Generation Specification Non-deterministic jitter Full-entropy output [SP800-90B] compliant Non-Deterministic RBG using a hardware based noise in from FRO. internal to the module boundary. Digitized output from the noise source is fed through an approved conditioning function based on SHA2-512 (Cert #C1707). Raw noise is generated based on non-deterministic jitter built up in freerunning oscillators. The module achieves full entropy from the output of the conditioning function where every 384-bits used to seed the DRBG includes 384-bits of entropy. All outputs from the noise source are subjected to statistical testing ahead of being fed to the conditioning function. The output of the hardware noise source includes a total failure test to check for bit-patterns consistent with hardware failures.

Depending on the configuration of the module, the following methods of key import and export for ‘Asymmetric Key Pairs (general partition keys)’ and ‘Symmetric Keys (general partition keys)’ are available as a service: > Key Wrap / Unwrap using Cloning Protocol Version 4 (CPV4) CPV4 uses the following cryptography:

• ECDH OneStep Key Derivation (section 5.8.2.1 from [SP800-56Ar3]) with C(2e, 0s, ECC CDH) with either P-521 or BrainpoolP512r1 as a curve to derive the CPV4 Shared Secret;
• OneStep KDF with either SHA2-512 or SHA3-512 is used to derive all keys as part of the CPV4 protocol;
• ECDSA with either P-521 or BrainpoolP512r1 are used for signing the ephemeral CPV4 Source Public Key alongside exchanged messages;
• AES-256 in either GCM mode or in CTR mode are used to encrypt sensitive objects in transfer using the protocol. Where CTR mode is used, transferred objects independently also include either a HMAC-SHA2-512 or HMAC-SHA3-512 MAC. Exact cryptography used is selected based on a down-selected cipher suite during the initial CPV4 negotiation.

NOTE Where a key is generated by the module using a generation or derivation method in

a non-approved mode of operation and exported, this SSP shall not be re-imported to the

module and used when configured in its approved mode of operation.

SSP Management public/private key pair and where the resulting encrypt operation is not considered part of a key transport scheme as defined in [FIPS 140-3 IG], D.G.

• [SP800-38F] compliant KTS using one of the following options for both key unwrapping and wrapping: − AES (128, 192 or 256-bit) in KW, KWP.
• [FIPS 140-3 IG] D.G, Key transport methods, compliant KTS for unwrap of key objects using one of the following options: − AES (128, 192 or 256-bit) in CBC, CTR or ECB modes; or − Triple-DES (112 and 168-bit) in CBC, ECB and CTR. The unwrap operation takes as input an encrypted symmetric key or asymmetric private key and a handle to the key required to successfully unwrap the object. It decrypts the key and returns the handle > Key Unwrap using historic versions of SKS The module supports key import for keys previously exported from another certified Thales HSM using versions of SKS supported by legacy firmware versions, and where related certificates are now on NIST’s historical list. Import is supported for key migration only. Objects imported using this method are either:
• encrypted using AES with 256-bit key in GCM mode with SHA2-256 for integrity protection; or
• encrypted using AES with 256-bit key in OFB mode and with SHA1 for integrity protection.

Test

Operations Performed Digest. Sign and Verify. Verify and Digest. Verify and Digest.

Indicator

NOTE Signature verification pre-operational self-tests will always be preceded by the

Conditional KAT on the bootloader implementations of RSA supporting a single mode of

operation. Transition from an approved to non-approved mode of operation automatically

triggers the HSM zeroize or decommission module service.

NOTE When conditional tests are run as part of the pre-operational self-test, the HSM will

test all possible implementations of a given algorithm independent of the HSM level

configuration and settings.

During PST, the module will exclusively test the implementation of a given algorithm in use

for a given configuration and settings of the HSM at the time of a given conditional test

executing,

The module performs the pre-operational self-tests upon power-up to confirm the firmware integrity, and to check the continued correct operation of the random number generator and each of the implemented cryptographic algorithms used in support of the integrity checks. While the module is running these self-tests, all interfaces are disabled until the successful completion of the self-tests. If any test fails an error message is output alongside being recorded in the error log, the module halts, and data output is inhibited. SHA (SHA-1 and SHA2-384) KAT. Digest. Error output and module halt. RSA (4096-bit modulus) KAT. Sign and Verify. Error output and module halt. Boot loader performs an RSA PKCS #1-v1.5 signature with Verify and Digest. Error output and module halt. 4096-bit modulus and SHA2-384 signature verification of itself. Boot loader performs an RSA PKCS #1-v1.5 signature with Verify and Digest. Error output and module halt. 4096-bit modulus and SHA2-384 signature verification of the main firmware image. do not require operator input to initiate.

Self-Tests All KAT alongside statistical testing of the noise source is performed immediately following the preoperational self-test at module power-on.

Test

Cryptographic Mechanism Tested Pre-operational: SHA-1 and SHA2-384. PST: N/A. Pre-operational: RSA PKCS #1-v1.5, modulus 4096, SHA2-384. PST: N/A. Continuous Test: Total failure test on the output from the hardware noise source, Repetition Count Test and Adaptive Proportion Test statistical tests. Continuous Test: RSA PKCS #1-v1.5, modulus 4096 signature and SHA2-384. Performed for all RSA key generation mechanism. Performed for all DSA key generation mechanism. Performed for all ECC key generation mechanism. Pre-operational: Instantiate, Generate and Reseed KAT for CTR_DRBG with AES-256. PST: <as per pre-operational self-test.> Pre-operational: SHA1, SHA2-224, SHA2-256, SHA2-384, SHA2-512, SHA3-224, SHA3-256, SHA3- 384, SHA3-512, SHAKE-128, SHAKE-256. PST: hash are tested based on inclusion in the KAT for higher-order algorithms.

Location Bootloader. Bootloader. Firmware. Firmware Firmware. Firmware. Firmware. Firmware. Firmware.

When Performed Prior to first use. Prior to first use. Continuous. On firmware update request. On generation. On generation. On generation. Prior to first use, PST. Prior to first use, PST.

Operations Performed Digest. Sign and Verify. N/A. Verify. Encrypt, Decrypt, Sign and Verify. Sign and Verify. Sign, Verify and Derive. N/A. Digest.

Indicator

Table 10-2: Conditional self-tests (Firmware) for ECDSA and ECDH).

Test

Cryptographic Mechanism Tested Pre-operational: HMAC-SHA1, HMAC-SHA2-224, HMAC-SHA2-256, HMAC-SHA2-384, HMAC-SHA2- 512, HMAC-SHA3-224, HMAC-SHA3-256, HMAC- SHA3-384, HMAC-SHA3-512. PST: HMAC-SHA1, HMAC-SHA2-224, HMAC-SHA2- 384, SHA3-256. Pre-operational: HMAC-SHA2-256. PST: HMAC-SHA2-256. Pre-operational: Signature Generation, Sig Verification for RSA X9.31 with SHA2-256, RSA PKCS #1-v1.5 with SHA2-256, RSA PKCS #1-v1.5 (no hash), RSA PKCS #1-v1.5 PSS with SHA2-256 and SHA2-256 for MGF, [SP800-56Br2] RSA-OAEP- basic with 2048-bit modulus and SHA1, SHA2-256 and SHA2-384, SHA2-512 as MGF. PST: Signature Generation, Signature Verification for: PKCS-PSS with modulus of 8192-bits and SHA2-256, PKCS-PSS with modulus of 2048-bit and SHA2-256, RSA-OAEP-basic with 2048-bit modulus and SHA2-256 as MGF. Pre-operational: Signature Generation, Signature Verification for 2048-bit modulus with SHA2-224. Signature Verification with 1024-bit modulus and SHA-1. PST: Signature Generation, Signature Verification for 2048-bit modulus with SHA2-224. Pre-operational: X9.42 Diffie-Hellman [SP800- 56Ar3] key derive with 2048-bit modulus. PST: <as per pre-operational self-test.>

Location Firmware. Firmware Firmware. Firmware. Firmware.

When Performed Prior to first use, PST. Prior to first use, PST. Prior to first use, PST. Prior to first use, PST. Prior to first use, PST.

Operations Performed Digest. Digest. Sign, Verify, Encrypt and Decrypt. Sign and Verify. Derive.

Indicator

47 random values used during the KAT operation of the PKCS-PSS are fixed as per [FIPS 140-3 IG], 10.3.A with both signature generation and signature verification

48 random values used during the KAT operation are fixed as per [FIPS 140-3 IG], 10.3.A with both signature generation and signature verification operations tested

Test

Cryptographic Mechanism Tested Pre-operational: ECB, CBC, OFB, CFB128, CFB8, KW, KWP, GCM, XTS and CMAC covering 128- bit,192-bit and 256-bit keys as supported by the different modes. PST: CBC, GCM, KWP (data object <=2KB), KWP (data object >2KB) – 256-bit key. Pre-operational: ECB, CBC, OFB, CFB64, CTR, CMAC for 168-bit keys. PST: ECB with 168-bit key, CMAC with 168-bit key. Pre-operational: ECC CDH [SP800-56Ar3] shared secret calculation (only) using curves P224, P384, P521 and K233. PST: ECC CDH with P384, OneStep KDF using SHA2-256. Pre-operational: Signature Generation, Signature Verification with ECDSA using curves P256 and K233 (no hashing). PST: Signature Generation, Signature Verification using ECDSA using curves P256 and K233 (no hashing). Pre-operational: KBKDF [SP800-108r1] with AES- CMAC, HMAC-SHA2-224, HMAC-SHA2-256, HMAC-SHA2-384, HMAC-SHA2-512 as PRF options. PST: KBKDF [SP800-108r1] using AES-CMAC as the PRD with 128-bit key.

Location Firmware. Firmware. Firmware. Firmware. Firmware.

When Performed Prior to first use, PST. Prior to first use, PST. Prior to first use, PST. Prior to first use, PST. Prior to first use, PST.

Operations Performed Encrypt and Decrypt. Encrypt and Decrypt. Derive. Sign and Verify. Derive.

Indicator

49 random values used during the KAT operation are fixed as per [FIPS 140-3 IG], 10.3.A with both signature generation and signature verification operations tested

Test

Cryptographic Mechanism Tested Pre-operational: OneStep KDF [SP800-56Cr2] with SHA1, SHA2-224, SHA2-256, SHA2-384, SHA2-512, SHA3-224, SHA3-256, SHA3-384, SHA3- 512. X9.42/X9.63 KDF using SHA1. PST: OneStep KDF [SP800-56Cr2] with SHA2-512. X9.42/X9.63 KDF using SHA1. Pre-operational: KAS1-basic [SP800-56Br2] with 4096-bit modulus. PST: <as per pre-operational self-test.> Pre-Operational PBKDF [SP800-132] using HMAC- SHA1, HMAC-SHA2-224, HMAC-SHA2-256, HMAC- SHA2-384, HMAC-SHA2-512. PST: PBKDF [SP800-132] using HMAC-SHA2-512.

Location Firmware. Firmware. Firmware.

When Performed Prior to first use, PST. Prior to first use, PST. Prior to first use, PST.

Operations Performed Derive. Encrypt and Decrypt. Derive.

Indicator

The module will perform periodic self-tests (PST) at set intervals of time for the pre-operational tests and a subset of the KAT tests. These tests will be performed every 24 hours at which point the PSTs will be implemented as a single asynchronous command with multiple steps that make up all PSTs that must be executed. The command will be added to the HSM’s command scheduler run queue, alongside any other commands that have been sent to the HSM. Each time the PST command is given time to execute, it will perform a single step and then return priority to other commands in the queue. Each step will be consistent in size with other cryptographic commands so as not to impact overall performance of the HSM. Conditional tests performed periodically are identified in Table 10-2 above as tests with ‘PST’ in the ‘When Performed’ column.

NOTE The module shall be received in a zeroised state. To check the status of the module

use the LunaCM command as described in section 11.12, ‘Checking hsm showinfo

Module Status’.

The module is confirmed as being in the zeroised state is the for partition status

the administration slot reports . zeroized

Thales Luna K7 Cryptographic Module should be deployed in a secure environment that will protect the module from sophisticated attackers with direct access. This is standard practice for high-value assets such as HSMs and forms part of a defense-in-depth approach to security. Securing the environment of the HSM typically will include a combination of both: > securing its location using physical defenses; and > procedures for monitoring and managing authorized access to the HSM. The exact measures put in place will vary and should be commensurate with the potential consequences or costs associated with the complete compromise of the HSM and cryptographic keys (or data objects) it protects. Common components of a physical security solution often include:

Ahead of using the module it must be initialized, after which it should be immediately configured into its approved mode of operation. Prior to secure initialization of the module, access control relies on procedural controls only and where the module should be received in the zeroised state with no initialized roles. Initialized creates the HSM SO role, names the module and associates the admin partition with a key cloning domain. Initialization is performed using the hsm init command from LunaCM for Thales Luna PCIe HSM or LunaSH for Thales Luna Network HSM. It should be noted that the hsm init command should only be run when an individual has been assigned to the HSM SO role and usually is run either by them or with them present. Following initialization of the module, it should immediately be configured into its approved mode of operation ahead of initialization of any further roles or creation of any stored key objects. Guidance on configuring the approved mode of operation is provided in section 13.2.

NOTE As part of initialization when using PED based authentication, the end-user is asked if

they wish to duplicate your iKey. It is strongly recommended that you do this and for

duplicate keys to be retained in secure storage for backup purposes. It is not possible to

copy iKey at a later point.

Security of the overall system including the HSM is only as strong as its weakest component. As such – the environment needs to take responsibility for securing artefacts relating to the HSM when outside its control. In particular, the following explicit requirements shall be met:

In addition to the above, to minimize risks to data being transferred in plaintext through the local environment of the HSM:

Permitted devices at the time of writing this document include: Thales Luna PED and the USB-to-Serial dongle supplied for use with functionality modules.

The HSM maintains a host accessible log of events in PCIe accessible FRAM memory. This allows the log on the Thales Luna K7 Cryptographic Module to be read by the host driver even if the bootloader or firmware has failed during power-on leaving the card in an un-responsive state. > The FRAM log can viewed using the lunadiag tool installed with the Thales Luna client:

• to view the FRAM log select option 18 Read Diagnostic Log then one of: − option 3 Tamper
• will output event in the log dedicated to tamper with recorded events. − option 1 card history
• records reset events that can be correlated with either when a card has been turned on or a soft or hard reset has had to occur. The following figures show example output from the logs: Tamper Log Entry 0, 0x25 bytes read, timestamp = 7630, reset count = 1: New FRAM LOG created. Entry 1, 0xc9 bytes read, timestamp = 17167, reset count = 4: LOG(TAMPER): ds3644_initialize - Warning: 10 L3 tamper settings do not match default! Registers re-configured. Actual values: 0x8f 0xff 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x5c 0xd2 0x7e Entry 2, 0x31 bytes read, timestamp = 17167, reset count = 4: ALM2008: Internal data corruption Card History Log Entry 0, 0x20 bytes read, timestamp = 303, reset count = 1965: reset reason 0x9154008 Date: 2019-05-30 (Thursday) Time: 1:09:09 Entry 1, 0x20 bytes read, timestamp = 304, reset count = 1966: reset reason 0x9154008 Date: 2019-05-30 (Thursday) Time: 1:09:38 Entry 2, 0x20 bytes read, timestamp = 3097, reset count = 1967: reset reason 0x41154008 Date: 2019-05-30 (Thursday) Time: 22:06:07 When reading the FRAM log messages: > timestamp
• is the elapsed time in milliseconds since the last time the card was reset; and > reset count
• identifies the reset event the offset is relevant to. This can be used with the card history log to calculate the time an event occurred by taking the data and time listed against the reset event and then adding the offset from the timestamp. In the scenario of a power-on or on-demand self-test failing, even if the triggered event causes the module to enter the halted state, the details can be accessed through the FRAM log. If the FRAM logs cannot be read following halt, this likely indicates the power-on self-tests detected an error during startup of the bootloader. If the firmware experienced a halt during its power-on tests, then further error details will still be accessible through the FRAM logs. An example of the module failing the SHA224 self-test on startup is below: ---Entry 155, 0x40 bytes read, timestamp = 6495, reset count = 117: LOG(CRITICAL): SHA2_SelfTest failed, rc=0x30000a

In order to maintain the separation of user roles throughout the life of the HSM deployment and to avoid compromise of a role, end users MUST:

CAUTION! Should the end user fail to comply with these requirements this could lead to subsequent compromise or malicious misuse of the HSM and its cryptographic keys.

CAUTION! In order to securely use the Thales Luna PED in its remote configuration, it is

important to check and acknowledge the serial number of the target HSM during setup of

the Remote PED tunnel.

If the displayed serial number does not match the expected target HSM serial number the

user must reject the displayed serial number at the PED, which will halt channel setup.

Should an end user lose iKey or believe their iKey to have been compromised it is imperative for the security of the HSM deployment that immediate action is taken to: 1. minimize the chances of subsequent misuse of the lost or compromised iKey; and 2. check for evidence of misuse of the iKey to allow for wider compromise recovery actions to be considered. Following identification of a lost or compromised iKey, the following actions should be taken: > If a backup token was made and it includes a corresponding PIN, duplicate the iKey to allow re-issue (while retaining a backup) but ensure the PIN is changed on all residual copies of the duplicated iKey prior to re-deployment of the iKey. > If the iKey was originally issued with no PIN, the iKey should be considered compromised and will need to be recreated: • Recreating an iKey requires all objects stored in the impacted partition or HSM to be backed up to allow for recovery following recreation of a new token − Where supported, cloning and SKS should be used to back up the HSM contents to a secondary − If an HSM SO iKey has been lost, all partitions and objects on the HSM should be backed up if partitions are still available. − If a Partition CO, Partition LCO or Partition CU iKey is lost, the impacted partition should be backed up.

NOTE is a sister command to and when enabled role resetpw role changepw

as a capability can enable a Security Officer to reset a lost or forgotten password on

behalf of an end user.

Life-cycle Assurance − If the AU token is lost, a copy of the Audit Logging Secret should be made and transferred to an iKey. − For the loss of an HSM SO token, LunaSH or LunaCM commands hsm factoryReset followed by hsm init should be run to re-create the iKey. This will result in a loss of all unbacked up objects on the HSM.

• In the event of loss of a Partition CO, Partition LCO or Partition CU token, the HSM SO must use the partition delete command to remove a partition before subsequently creating a new partition using partition create.
• For AU, the audit partition must be re-initialised using the LunaSH command audit init . Run role init –name audit in LunaCM to recreate a new AU token. The Audit Logging Secret can then be imported using the audit secret import from LunaSH or audit import from LunaCM.

Should a role believe their PIN or password to have been compromised (where used) but access to the corresponding token or to the HSM was not possible, the following action should be taken: > the PIN or password should be changed using: • role changepw LunaCM command for a compromised password or iKey PIN to issue a new password and the option to create a new iKey PIN where appropriate. At this time it is not possible to reset a password or PIN associated with the HSM SO role and as such, the only route to change this PIN is to back up and then to reinitialize the HSM.

The KCV is used to register an HSM with a domain allowing it to transfer keys with other modules. Loss of a domain key should be considered a security event. Backups of the KCV or print-outs (optional) of the HSM-or-Partition domain secret should be retained. If this has not been performed, it is not possible to recreate or replace the domain secret. In order to recover from complete loss of a domain secret, the objects in the HSM (where configuration permits) need to be exported and re-imported into an HSM registered with a new domain.

When a Remote PED iKey is considered to be compromised, a new iKey should be generated and distributed to all remote PED on the Orange iKey. In order to create a new Remote PED iKey: > Thales Luna PCIe HSM: • run the ped vector init from LunaCM; > Thales Luna Network HSM:

NOTE Use of the and bootloader commands to perform a complete terase tplease

erase of all Flash based storage is not intended to be performed by customers and is

included here for completeness only.

The Flash contains keys created during manufacture that cannot be replaced without

repeating the full manufacturing process for the card.

Following erase of the flash, only signed firmware in a format not made publicly available

can be loaded onto the module.

Life-cycle Assurance • run the ped vector init from LunaCM or hsm ped vector init from LunaSH.

When an individual no longer has the requirement to hold the authorized role associated with the HSM, a hand-over of iKeys and corresponding PIN or password should be arranged. When a token has been lost for a role to be revoked, guidance on recovering from a lost end user authentication iKey in section 11.6 should be followed.

Keys can be deleted from a partition in one of a number of ways:

Decommissioning is the process of removing all sensitive information from the cryptographic module and/or the appliance hosting it. The following sections cover the steps required in order to decommission.

The Thales Luna PCIe HSM is equipped with a two-pin decommission input, as covered in section 3.1. Short-circuiting the decommission jumper header decommissions the HSM. You can use the blade of a screwdriver, or other electrical conducting tool to short-circuit the two pins of the decommission header, or you can connect a switch to the decommission header if desired. Power is not required to decommission the HSM. That is, you can decommission the HSM after removing it from the chassis.

Life-cycle Assurance When you decommission a Thales Luna PCIe HSM, the HSM is zeroised, all user accounts are deleted, and the HSM is returned to its factory state. Any firmware or partition upgrade licenses installed on the HSM are retained. Following decommission of the HSM using this method, confirm the operation was successful using the hsm showinfo LunaCM command on the next power-cycle. The below text response should be shown: Manually Zeroized: Yes This confirms the decommission process was executed successfully. Alternatively, run the LunaCM hsm factoryreset command to decommission the HSM to factory default settings. Care should be taken to observe that the command executes to a successful completion. An example output from a successful factory reset is shown below: lunacm:>hsm factoryreset You are about to factory reset the HSM. All contents of the HSM will be destroyed. HSM policies will be reset and the remote PED vector will be erased. Are you sure you wish to continue? Type 'proceed' to continue, or 'quit' to quit now ->proceed Command Result : No Error Figure 11-1: Example successful factory reset console output from LunaCM

For full decommission (removing the unit from service, clearing the HSM of all your material, clearing the appliance of all identifying information) of a functioning Thales Luna Network HSM, follow these steps in LunaSH, using the serial connection:

1. Rotate all logs: lunash:> syslog rotate
2. Delete all files in the SCP directory: lunash:> my file clear
3. Delete all logs: lunash:> syslog cleanup
4. Return the appliance to factory-default settings: lunash:> sysconf config factoryreset -service all
5. Delete any backups of settings: lunash:> sysconf config clear
6. Push the decommission button (small red button, inset in the Thales Luna Network HSM back panel). The switch is tactile and has a travel of 1.4mm. Figure 11-2: Thales Luna Network HSM decommission button location
7. Power down the appliance.

NOTE All updates of the firmware MUST be FIPS validated before they can be loaded for

the module to remain in an approved mode of operation.

Life-cycle Assurance 8. Power up the appliance. At this point, the HSM internally issues and executes its zeroise routine to erase all partitions and objects. This step takes about five minutes. The KEK is already gone at that point

• erased as soon as the button is pressed
• so the step of erasing partitions and objects is for customers subject to especially rigid decommission protocols.

Updating the module’s firmware requires the HSM SO and the firmware update file to complete. Run the LunaCM hsm updatefw command to update the current firmware to a new version. If any failures are detected during the update the command will fail and the module will continue running on the existing An example output from a successful firmware update is shown below: lunacm:>hsm updatefw -fuf fwupdateK7_testCert_7.0.1_RC327.fuf authcode fwupdateK7_testCert_7.0.1_RC327.fuf.txt You are about to update the firmware. The HSM will be reset. Are you sure you wish to continue? Type 'proceed' to continue, or 'quit' to quit now -> proceed Updating firmware. This may take several minutes. Firmware update passed. Resetting HSM Command Result : No Error Figure 11-3: Example successful FW update console output from LunaCM

The module status can be assessed by running either the hsm showinfo LunaCM for Thales Luna PCIe HSM or the hsm show LunaSH command for Thales Luna Network HSM. Where physical access to the module is possible – additional information on status can be found based on the four status LED on the PCIe card as covered in section 3.1, ‘Ports and Interface Overview’.

The module does not require any periodic maintenance outside the routine inspection of Tamper Evidence as documented in Section 7.2.

Mitigation of Other Attacks

No assured mitigations to ‘other attacks’ are covered in this security policy.

NOTE Any module returning hardware, main firmware and bootloader versions not listed in this security policy is out of the scope of this validation and requires a separate FIPS 140-3 certificate.

Ahead of putting the module into its approved mode of operation, it is important to identify the hardware, main firmware and bootloader versions of the target module and to check these correspond to one of the tested modules listed in section Table 2-1. The following sections provide guidance on checking each element. Two paths are supported to checking the hardware, bootloader and main firmware versions depending on whether the LunaCM or LunaSH management interfaces are being used 50: > hsm showinfo when using LunaCM; and > hsm show when using LunaSH. Both commands return status information on the target cryptographic module including the module name, version numbers for both bootloader and main firmware and separately the hardware identity. Example output for each command for a valid module is shown in the Figure 13-1 and Figure 13-2 below with relevant versions highlighted in red: lunacm:>hsm showinfo Partition Label -> myPCIeHSM Partition Manufacturer -> SafeNet Partition Model -> Luna K7 Partition Serial Number -> 67842 Partition Status -> L3 Device HSM Part Number -> 808-000048-002 Token Flags -> CKF_RNG CKF_RESTORE_KEY_NOT_NEEDED CKF_TOKEN_INITIALIZED RPV Initialized -> Not Supported Slot Id -> 4 Session State -> CKS_RW_PUBLIC_SESSION Role Status -> none logged in Token Flags -> TOKEN_KCV_CREATED Partition OUID: 000000000000000002090100 Partition Storage: Total Storage Space: 393216 Used Storage Space: 0 Free Storage Space: 393216 Object Count: 0 Overhead: 9848 FM HW Status -> FM Bootloader Version -> 1.1.5 Firmware Version -> 7.8.5 Rollback Firmware Version -> 7.0.3

50 Both LunaCM and LunaSH map to the Luna ICD logical interface at the cryptographic module boundary.

Guidance Environmental: Fan 1 Status                                                    : active Fan 2 Status                                                    : active Battery Voltage                                                 : 3.093 V Battery Warning Threshold Voltage                               : 2.750 V System Temp                                                     : 38 deg. C System Temperature Warning Threshold                            : 75 deg. C HSM Storage: Total Storage Space: 33554432 Used Storage Space:   33554432 Free Storage Space:   0 Allowed Partitions:   1 Number of Partitions: 1 License Count -> 8 1. 621000068-000 K7 Base Configuration 2. 621010185-003 Key backup via cloning protocol 3. 621000135-002 Enable allow decommissioning 4. 621000134-002 Enable 32 megabytes of object storage 5. 621000154-001 Enable decommission on tamper with policy off 6. 621000021-002 Maximum performance 7. 621000138-001 Controlled tamper recovery 8. 621000074-001 Enable Functionality Modules Command Result: No Error Figure 13-1: Example output of hsm showinfo command from LunaCM lunash:>hsm show Appliance Details: ================== Software Version:                                        7.8.0-1 HSM Details: ============ HSM Label:                                                      myLunaHSM Serial #:                                                       66331 Bootloader:                                                    1.1.5 Firmware:                                                      7.8.5 HSM Model:                                                      Luna K7 HSM Part Number:                                               808-000073-001 Authentication Method:                                          Password HSM Admin login status:                                         Not Logged In HSM Admin login attempts left:                                  3 before HSM zeroization! RPV Initialized:                                                No Audit Role Initialized:                                         No Remote Login Initialized:                                       No Manually Zeroized:                                              No Secure Transport Mode:                                          No HSM Tamper State:                                               No tamper(s) Partitions created on HSM: ============================== Partition:         154438865296, Name: mypar0 Number of partitions allowed:                                    100 Number of partitions created:                                    1 FIPS 140 Operation: ===================== The HSM is in FIPS 140 approved operation mode.

NOTE If the HSM SO or Partition SO attempt to enable or disable the above policies, a warning is

displayed and the HSM SO or Partition SO is prompted to confirm the selection. If this policy is left

set to , the module will be operating in the non-approved mode of operation. true

Guidance HSM Storage Information: ======================== Maximum HSM Storage Space (Bytes): 33554432 Space In Use (Bytes): 335544 Free Space Left (Bytes): 33218888 Environmental Information on HSM: ================================= Battery Voltage: 3.072 V Battery Warning Threshold Voltage: 2.750 V System Temp: 53 deg. C System Temp Warning Threshold: 75 deg. C Functionality Module HW: FM ======================= Command Result: 0 (Success) Figure 13-2: Example output of hsm show command from LunaSH Where Luna K7 is returned as the Partition Model in the output from LunaCM and HSM Model in the output from LunaSH, this can be mapped directly as an alias for ‘Thales Luna K7 Cryptographic Module’ as Partition) must check and, if necessary, set the following partition level policy: > Partition Policy (42) Enable CPv1– this is set to true by default when the HSM Policy (12), Allow Algorithms is set to false, the module will set this value to false (enforced by the module). This Ahead of configuring the individual partitions, the HSM SO must set the following HSM level policies: > HSM Policy (56), Allow User Defined ECC Curves – this policy is set to true by default and shall be > HSM Policy (52) Restrict FM Privilege - must be set to true following load of the ‘Enable Functionality Module CUF’ in order to ensure all FIPS 140-3 requirements are enforced at the boundary between the module firmware and any loaded functionality module.

NOTE While default setting is this setting is only relevant to a FIPS approved configuration false,

following load of the ‘Enable Functionality Module CUF’. This unlocks the ability to enable the

related ‘HSM Policy (50) Allow Functionality Modules’. Prior to HSM Policy (50) being set to , true

the setting of HSM Policy (52) Restrict FM Privilege is redundant to the modules operation as FM

can’t be loaded and the policy only relates to commands received by the module from within code

executing within a sandboxed functionality module.

Guidance Following entry into an approved mode of operation: > any changes to the HSM level policy will trigger an automatic zeroization of the HSM erasing all roles and partition stored key objects; and > any changes to the partition level policy will trigger an automatic zeroization of the partition erasing all partition stored key objects.

To make the module perform cryptographic self-tests ‘on demand’ this can be achieved using the following: > Self Test (Option #90) when using the ckdemo client tool. This will give you 3 options of self-tests to run on the module:

Enter your choice : 90 Slots available: slot#5 - Admin Token Slot slot#6 - User Token Slot slot#9 - Admin Token Slot Select a slot (last selected slot = 6): 6 Test to perform: [0] To cancel [1] H/W Test [2] Crypto Test [3] RNG Test [4] Perf mode on (us) [5] Perf mode on (ns) [6] Perf mode off [7] Cryptographic Algorithm Self Tests [8] Sentry off [9] Sentry on [10] Inject error: exit() [11] Inject error: raise() [12] Inject error: kernel oops

Guidance [13] Inject error: infinite loop [14] List all enabled Sentry PKA engines (0:5) [15] Disable a Sentry PKA engine (0:5) [16] Enable a Sentry PKA engine (0:5) > 2 Status: Doing great, no errors (CKR_OK) (TITLE) menu titles, (99 or FULL) Full Help, (NONE) No help, (0 or EXIT) Quit Status: Doing great, no errors (CKR_OK) 13-3: Example output of the Self Test command from CKDemo In addition to using CKDemo as a tool, on demand self-test can be requested using the CA_ PerformSelfTest command using the Cryptoki API.

The nominal temperature range for operation of the module is between 0 and 50°C. The nominal temperature range for storage and distribution of the module is between -20 and 80°C. The overall input operation voltage of the module as a PCI-E card is +12V ± 8% DC. This input is used to generate the voltages covered in section 7.3 and as are used internal to the module. The module’s tamper thresholds can be found in section 7.3.

To log into the module’s roles as described in section 4.1 you must first set the slot to the partition you wish to log into. To set the slot you must first use the slot list LunaCM command to view the available slots, once you have the chosen slot you wish to log into use the following: > set slot when using LunaCM. lunacm:> slot set -slot 4 Command Result : No Error 13-4: Example output of set slot command from LunaCM Once set you may now log into any of the available roles to the partition by using: > role login when using LunaCM. lunacm:> role list Roles (short) ============================ Partition SO po Crypto Officer co Limited Crypto Officer lco Crypto User cu Command Result : No Error

NOTE Some roles must first be initialized before they can be logged in. To do so you must use the command in LunaCM role init

NOTE When reviewing the manuals, you should refer to the latest version of each manual.

Should any conflict be identified between guidance in this security policy and statements in the

online product documentation, guidance in the security policy takes precedence.

lunacm:>role login -name po Please attend to the PED. Command Result : No Error 13-5: Example output of role list and role login commands from LunaCM

In addition to the direct guidance provided in this security policy both Thales Luna PCIe HSM and Thales Luna Network HSM include extensive user guidance in their online free to access manual. The full manuals for these products can be accessed at www.thalesdocs.com where the target products can be found under ‘Luna HSMs’ and where the ‘read docs’ link will take you to the front page where the document portal for either Thales Luna PCIe HSM and Thales Luna Network HSM can be found.