IBM® NVMe FlashCore™ Module 3

Certificate

Approved Algorithms (18)

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

flowchart LR
  %% Deterministic review-risk graph for IBM® NVMe FlashCore™ Module 3
  %% 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>Load firmware<br/>firmware load</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Unauthenticated<br/>Self-Test<br/>Status Output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<br/>library named: nss</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>application</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 IBM® NVMe FlashCore™ Module 3
  %% 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>Load firmware<br/>firmware load</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Unauthenticated<br/>Self-Test<br/>Status Output</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>HTTPS<br/>library named: nss</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>application</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

IBM® NVMe FlashCore™ Module 3 Security Level 2 Rev. 3.9 – September 18, 2025 IBM ® Corporation

Table of Tables Table of Figures

This is the security policy associated with the IBM NVMe FlashCore Module 3, a NVMe-connected self-encrypting non-volatile storage hardware module, a Cryptographic Module which is being validated per FIPS 140-3. This document is designed to meet the FIPS 140-3 standard (see Section 1.3 References 1) and Implementation Guidance (see Section 1.3 References 3) requirements. It is not intended to provide the type of interface details required to develop a compliant application. This document is non-proprietary. This document may be reproduced in its original entirety.

1. FIPS PUB 140-3, issued Mar 22, 2019
2. FIPS 140-3 Derived Test Requirements, issued Mar, 2020
3. Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program, last updated May 4, 2021
4. TCG Storage Architecture Core Specification, Specification Version 2.01
5. TCG Storage Security Subsystem Class: Opal, Specification Version 2.01
6. TCG Storage Opal SSC Feature Set: PSID Version 1.00
7. TCG Storage Opal SSC Feature Set: Single User Mode, Specification Version 1.00
8. NVM Express Revision 1.2.1
9. NVM Express Revision 1.3
10. NVM Express Revision 1.4

AdminSP       Administrative security partition, a TCG term AES           Advanced Encryption Standard (FIPS 197) APT           Adaptive Proportion Test ARM           Advanced RISC Machine CAVP          Cryptographic Algorithm Validation Program CBC           Cipher Block Chaining, an encryption mode CKG           Cooperative Key Generation CLiC          CryptoLite in C CO            Crypto-Officer CPLD          Complex Programmable Logic Device CPU           Central Processing Unit CRNGT         Continuous Random Number Generator Test CSP           Critical Security Parameter DDR4          Double Data Rate 4 memory DRBG          Deterministic Random Bit Generator ECB           Electronic Codebook Mode ENT           Entropy FCM3          FlashCore Module 3 FIPS          Federal Information Processing Standard FKM           Flash Key Management FPGA          Field Programmable Gate Array HMAC          Hash-based Message Authentication Code IC            Integrated Circuit IG            Implementation Guide LBA           Logical Block Address KAT           Known Answer Test KDF           Key Derivation Function KEK           Key Encryption Key LockingSP     Locking Range security partition, a TCG term MEK           Media Encryption Key MSID          Manufactured SID, TCG term for a unique per FCM3 public value used as the default NAND          Not AND (a type of flash memory) NOR           A type of flash memory NSSR          NVMe SubSystem Reset NVMe          Nonvolatile memory express OFS           Original Factory State PIN           Personal Identification Number POST          Power on Self-Test PSID          Physical SID, TCG term for a unique per FM value public value RAM           Random Access Memory RCT           Repetition Count Test RSA           Rivest Shamir Adleman algorithm SHA           Secure Hash Algorithm SID           Security ID, TCG term for Drive Owner CO role’s PIN SLR           SUM Locking Range SP            Security Policy (per FIPS 140-3) SSC           Security Subsystem Class SSP           Sensitive Security Parameter SUM           Single User Mode SWG           Storage Work Group TCG           Trusted Computing Group

TEL Tamper Evident Label XTS XEX-based tweaked-codebook mode with ciphertext stealing, an encryption mode

The cryptographic module is the IBM NVMe FlashCore Module 3 (FCM3) in its entirety. The cryptographic module will be referred to as the FCM3 throughout this document. This FCM3 uses approved algorithms to provide a number of cryptographic services. Those services include encryption and decryption of user data in hardware, support for cryptographic erase, support for multiple user data Locking Ranges (each of which can be configured for independent access control and protection), and authentication checking of code downloads. The services are provided via FCM3 support of the TCG Opal SSC interface. The FCM3 is a multiple-chip embedded hardware cryptographic module embodiment. The module’s cryptographic boundary is comprised of all hardware and firmware components contained within the module’s physical enclosure. The host interface to the FCM3 is physically a PCIe connector, over which the industry-standard NVMe protocol (see Section 1.3 References 8) is supported. Through the NVMe logical interface the FCM3 supports the TCG SWG Core (see Section 1.3 References 4) and TCG Opal SSC (see Section 1.3 References 5) protocols. All control of the FCM3 via its interfaces is typically through an application on a host system. All human control of an FCM3 is assumed to be through such an application. The primary cryptographic service supported by the FCM3 is encryption of user data at rest: encrypting user data written to the FCM3 before the resultant ciphertext is written to the FCM3’s non-volatile solid-state memory. The FCM3 also supports the complementary decryption function, decrypting that ciphertext from solid-state memory when it is read back. Storing user data in encrypted form enables another cryptographic service the FCM3 supports: cryptographic erase, which nearly instantly renders all previously encrypted user data to be effectively destroyed. The FCM3 supports TCG Opal access controls, which restrict access to use of, and administration of, the encryption and cryptographic erase services.

The FCM3 will operate in a non-compliant state until the Secure Initialization steps detailed in Section 11.1 are performed. From this non-compliant state, the FCM3 may be securely initialized so that it operates in the Approved mode. After the FCM3 has been Securely Initialized and operated per the Security Rules detailed in Section 11.1, the FCM3 will remain in Approved mode of operation until either an important error or failure has been detected or a “Revert via OFS” service is performed. An operator controlling the FCM3 can use the “FIPSmode?” service, if it does not return the expected status (see Section 4.5), then the FCM3 is not operating in Approved mode. An operator can cause an FCM3 operating in Approved mode to quit Approved mode by use of the FCM3’s “Revert via OFS” service. This service will zeroize the FCM3’s keys and CSPs and transition it through its Original Factory State (OFS) to its non-compliant state. The operator can then cause that FCM3 to return to Approved mode by following the Secure Initialization procedure detailed in Section 11.1 again. To operate the FCM3 is in its Approved mode, it must be configured properly, and it must be operated in accordance with the associated policy restrictions (detailed in Section 11.2). Violating the ongoing policy restrictions would mean that the FCM3 is no longer being operated in its Approved mode of operation.

When operated in this mode the FCM3 provides cryptographic services via industry-standard NVMe commands, TCG Opal commands addressed to the TCG AdminSP, and TCG Opal commands addressed to the TCG LockingSP. To operate in Approved mode, the Drive Owner must invoke the Activate method on the LockingSP starting from an non-compliant state which itself must start afresh from an OFS state. Keys and CSPs established in Approved mode cannot be used in non-compliant state. This is accomplished by the key zeroization which performed as part of the “Revert via OFS” service. Similarly, Keys and CSPs established in non-compliant state cannot be used in Approved mode. If an FCM3 had been previously operated with a non-FIPS code load, a Locking Range may have been established, though that FCM3 would not have been in Approved mode

because of the non-FIPS code load. In this case some keys (e.g. the Locking Range’s MEK) would have been established with a non-FIPS code load and they cannot be used in Approved mode. If the code on that FCM3 is then updated to the FIPS code load, then the FCM3 must be put back into the OFS state by use of one of the Opal methods specified in the “Revert via OFS” service. This service will cause cryptographic erase of all data written to those Locking Ranges as the Locking Range’s MEKs are zeroized. Then the drives can be put back into Approved mode if all requirements are met. The FCM3 only supports Single User Mode (SUM), so only a single User has independent access control to read/write/erase a given Locking Range. By default, there is a single “Global Range” that encompasses the whole user data area. “Locking Ranges”, when established, are configured to be subsets of the LBA range initially established as a Global Range.

When invoking the Activate method to enter Approved mode, the Drive Owner creates a Locking Range (LR). All LRs created within the FCM3 must be of the Single User Mode (SUM) type. The FCM3 does not support creation of non-SUM LRs, or reclassification of SUM LRs into non-SUM LRs, and any TCG Opal methods attempting either of those will fail with the appropriate error code returned. So, all LRs created in an FCM3 will be, and will remain, “SUM Locking Ranges” (SLRs). SLRs conform to the SUM feature set (see Section 1.3 References 7). Each SLR is controlled and administered solely by the single User role it is associated with per Section 1.3 References 5 and see Section 1.3 References 7, e.g. SLR1 by User2. TCG Opal implements multiple Cryptographic Officer (CO) roles which operate cooperatively to establish, configure, and administer these SLRs. These roles include, at a minimum, the Drive Owner, the User(s), and the LockingSP Admin(s). While in Approved mode, this cooperative operation includes:

1. Creating one or more SLRs (by the Drive Owner) • the FCM3 supports a Global Range and the additional creation of up to 3 SLRs
2. Customize the User PIN and LBA range associated with each created SLR (by User(s) only)
3. Lock and Unlock SLRs (by User(s) only)
4. Crypto-Erase of SLRs (by User(s) or Locking SP Admin(s))
5. Crypto-Erase of Global Range (by Locking SP Admin(s))

The following FCM3 configurations have been validated: Table 2-1 Cryptographic Module Tested Configuration

The configurations vary with respect to the memory integrated circuits (ICs) used. The number of parts, part numbers, and storage capacity of those ICs varies between configurations, but these ICs have no cryptographic capability and do not alter the FIPS services provided. A complete list of FCM3’s components can be found in the master components list. The majority of the components are not described in any further detail here because they are not related to encryption. The FCM3 small/medium drive contains a Xilinx Zynq Ultrascale+ XCZU19EG FPGA (vendor part # = XCZU19EG-L2FFVB1517E4845). That FPGA contains two processor complexes:

• For applications: Quad-core ARM® Cortex™ A53 MPCore™(up to 1.5GHz)
• For real-time: Dual-core ARM Cortex-R5 MPCore™ (up to 600MHz) Two of the A53 cores, and both of the R5 cores, are powered off and never run. The FCM3 large/xlarge drive contains a Xilinx Versal ACAP FPGA (vendor part # = XCVM1802-2LLEVSVD1760). That FPGA contains two processor complexes:
• For applications: Dual-core ARM® Cortex™ A72 MPCore
• For real-time: Dual-core ARM Cortex-R5F MPCore Two of the R5F cores are powered off and never run. The first of the application cores runs a forever while loop and the second core runs a bare-metal applications running a modified version of uC/OS-II v.2.61". The first of the application cores runs the Flash card (back-end) tasks including the Flash Key Manager (FKM) task. The second of the application cores runs the host attach (front-end) NVMe task. The TCG Opal task runs underneath NVMe task. All cryptography is done by either the TCG Opal task or the FKM task, each runs a copy of the IBM Crypto-Lite in C (CLiC) v4.14.27.7548 (c4T3/FlashSysANSIC64) code. Two application cores have its own memory address space, CPU register files, etc. CSP/SSP is not shared on these two application cores, which means only one core has access/control over a certain CSP/SSP. See Section 11.1 on how to configure and setup Approved mode on FCM3.

Table 2-2 Approved Algorithms The modules does not support any of the following:

• Non-Approved Algorithms Allowed in the Approved Mode of Operation
• Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed
• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation Please note that only the algorithms, modes and options listed in the table above are implemented and used by the module, and that the referenced certificates may contain additional, unused algorithms. * XTS-AES-256 is only used by the FCM3 in the context of storage applications *2 Only 4-byte aligned inputs are supported, so only 4-byte aligned inputs were verified by CAVP *3 In accordance with FIPS 140-3 IG C.C, the cryptographic module performs digital signature checking using SHA3- 384 as specified in FIPS PUB 202 (Vendor Affirmed). Per IG C.F, the key sizes for this RSA SigVer implementation are untested.

*4 In accordance with FIPS 140-3 IG D.H, the cryptographic module performs cryptographic key generation for symmetric keys & seeds for asymmetric keys per SP 800-133r2 Sections 4, 5.2, 6.1 and 6.2 (Vendor Affirmed). *5 KTS-OAEP-basic is used with AES-KW per Section 9.3 of SP800-56Br2.

Figure 2-1 FCM3 Top View Figure 2-2 FCM3 Front View Figure 2-3 FCM3 Back View

Edge connector is PCIe physically, NVMe logically CPU Flash MiB RAM STT MRAM GiB DDR                     ST DDR SFF 3                                        ME Gateway x    ME to host                                       DDR3         Flash Edge                                    Flash Controller Devices Connector                                     (FPGA) SPI OSPI OR Flash Cryptographic Boundary Figure 2-4 FCM3 Block Diagram

Table 3-1 Ports and Interfaces Notes: * FCM3 has no control output interface.

Because all user data written to the FCM3 is encrypted when stored to its internal solid-state media, the data can be cryptographically erased (crypto-erased). The encrypted data, ciphertext, stored is effectively erased when the media encryption key (MEK) used to encrypt it is overwritten (with a fresh MEK) or erased (overwritten with a fixed value such as all zeroes). Because the FCM3 supports the ability to “zeroize” all keys and CSPs, per the FIPS -3 key management requirement, the FCM3 supports the capability to “zeroize” any and all MEKs, which in turn crypto-erases all the user data encrypted with those MEKs. The FCM3 supports the capability to zeroize any and all MEKs whether it is in Approved mode or not. It should be noted that user data stored to the FCM3 cannot be reliably destroyed by overwrite from the host because the actual storage space where a given LBA’s data is stored moves over time within the FCM3 for multiple reasons including support for wearleveling. But user data can be reliably destroyed by crypto-erase of the associated MEK. Alternately, all private keys and CSPs can be zeroized at once via Opal methods which cause Revert via OFS.

Whether in Approved mode or not, the TCG Revert and RevertSP methods may be invoked by an appropriately authenticated Role to put the FCM3 into an non-compliant state. This corresponds to the “Revert via OFS” service and is akin to a “restore to factory defaults” operation. This operation causes zeroization of all CSPs and private (or secret) cryptographic keys. Subsequently, the FCM3 has to be reinitialized before it can return to Approved mode of operation. These Revert and RevertSP methods may be invoked by the Drive Owner, by the AdminSP’s Admin, by the LockingSP’s Admins, or by an unauthenticated role using the public PSID value (see Section 1.3 References 6). The TCG Revert and RevertSP methods are also the appropriate method to perform the drive “end of life” procedures.

The following explains the Cryptographic Officer and User roles with a general description of the purpose and authority of each role. For further details of the services performed by each role while the FCM3 is in Approved mode, see Section 4.5.

This role corresponds to the SID (Secure ID) Authority on the AdminSP as defined in Opal SSC (see Section 1.3 References 5). This role is used to transition the FCM3 to Approved mode. It should be noted that to operate in Approved mode, a FIPS validated code version (i.e. FIPS code) must be loaded into the FCM3, and the FCM3 must have booted to that code level. If the FCM3 is not running FIPS code, it cannot be operating in Approved mode.

When in Approved mode, these roles’ Authority corresponds to the LockingSP’s Admin roles as defined in Opal SSC (see Section 1.3 References 5).

When in Approved mode, this role’s Authority corresponds to the AdminSP’s Admin role defined in Opal SSC (see Section 1.3 References 5). This role is enabled by default, but can be disabled by the Drive Owner, if desired. When enabled, an authenticated AdminSP Admin1 can invoke the “Revert via OFS” service.

When in Approved mode, this role’s Authority corresponds to the LockingSP’s User role as defined in Opal SSC (see Section 1.3 References 5). This role can unlock (and also lock) the corresponding SLR in the FCM3, so that an operator can read and write data to that SLR. This role can also invoke the Crypto-Erase service of the associated SLR.

The PINs have a fixed length of 256 bits. Per the policy security rules, the FCM3 only allows programming of PINs that are of length

256 bits (see Section 11.1’s Rule 7). This PIN length results in a probability of at most 1/2256 (i.e. less than 10-38) for the PIN to be

guessed in a single random attempt. Each authentication attempt requires 39ms on average for the FCM3 to complete. This means that at most (60*1000)/39 (= 1538) attempts can, on average, be made in one minute. So the probability of multiple random attempts succeeding in guessing a PIN in a one minute period is at most 1538/2256. For PIN-based authentications (e.g., TCG SID, TCG Admins 1- , etc.), they’re considered as ‘memorized secret’ authentication mechanism as per SP 800-63B.

The SID is initially set to the value of the manufactured value (MSID). This is a device-unique public value which is 256 bits long. The Security Rules (see Section 11) for the FCM3 requires that the PI values must be “personalized” to private values using the “Set PI ” service. The Drive Owner PIN can be set to a different value by use of the TCG Set Method.

The following tables details the FIPS 140-3 services the FCM3 provides when in Approved mode. It shows which services (Approved Security Functions) can be invoked or used by which authenticated operators (Access Control). In terms of the operator access control, note the following:

• Use of the services described below is compliant only when the FCM3 is in Approved mode.
• Not shown are the security functions which underline the higher-level algorithms shown below (e.g. DRBG-SHA-512 as part of ENT (P)).
• Operator authentication is not shown in this table, but an operator must have appropriately authenticated to the role shown in the Operator Access Control column to use/invoke the service shown in the Service Name column of the same row.
• Some security functions listed are used solely to protect / encrypt keys and CSPs.
• Input and output details of TCG Opal (or NVMe) methods used to invoke the services below are defined by the TCG Opal (or NVMe) standards.
• Unauthenticated services (e.g. FIPScode?) do not provide access to private keys or CSPs.
• Some services such as User data read / write have indirect access control provided through enable, disable, lock, and unlock services used by an authenticated operator.
• The User Data Read/Write service implements the lock-based authentication model.
• Power-cycling the module re-locks the previously unlocked service.
• The lock-based authentication model remains secure as the currently authenticated operator remains in physical control of the module interfaces until power off.

Table 4-1 Roles, Service Commands, Input and Output Notes: * the drive first needs to be unlocked by an authenticated role. ** service is optional and has no impact. Secure key passing is enabled by default and cannot be disabled due to programmatic checks

Table 4-3 Approved Services * This is unauthenticated as per clause (c) of IG 4.1.A. G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g. the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP.

The module's approved integrity technique is RSA SigVer FIPS 186-4 with 4096-bit modulus and SHA3-384 (vendor affirmed), conducted on the module’s executable code which is in the form of a pre-compiled firmware binary image. FCM3 firmware image has an RSA 4096 with SHA3-384 digital signature appended, it’s checked during firmware download and startup. If non-IBM image is downloaded, the firmware download procedure will return failure and reject it. The original image in OR flash won’t be updated at all. On every startup, a similar check occurs and puts the card in an error state when it fails. The firmware integrity test can be performed on-demand by the operator by power-cycling the module or by invoking the NSSR command via the ‘Reset Module’ service.

The FCM3 operates in a “limited operational environment”. Specifically, the operational environment cannot be modified while the FCM3 is in operation, and no code can be added or deleted. Firmware can be replaced or upgraded with a signed firmware download operation. If the code download’s digital signature checks as authentic, then the FCM3 will boot to it following the next cold boot and so will begin operating with the new firmware image. Per the FIPS 140-3 CMVP Management Manual section 'Partial validations and non-applicable areas', the following statement applies: "Section 6.6, Operational Environment may be designated as Not Applicable if the operational environment for the cryptographic module is a limited or non-modifiable operational environment and Section .7, Physical Security greater than Security Level .” The module has a limited operational environment and is being validated at physical security level 2. As such, this section of FIPS 140-3 requirements is not applicable.

The FCM3 has the following physical security: Built of production-grade components which have standard passivation. Two opaque tamper-evident labels (TELs) on the FCM2. There is one TEL on each end of the FCM2. See Figure 7-3 Tampered TEL1 for placement of TEL1 and Figure 7-4 Tampered TEL2 for placement of TEL2. The TELs are applied during IBM’s manufacturing process. They protect against physical access to the electronics by board removal and prevent electronic design visibility. Tamper-evident security labels applied by IBM manufacturing prevent FlashCore Module 3 Assembly cover removal for access to or visibility of the solid-state memory. Exterior of the FCM3 is opaque. The tamper-evident labels (TELs) cannot be penetrated, or removed and reapplied, without that tamper being readily evident. The TELs cannot be easily replicated with a low attack time. The operator is required to inspect the FCM3 periodically for any of the following types of tamper evidence:

• Flaking, folding, or ripping of TELs or metal case.
• Figure 7-3 Tampered TEL1 illustrates tamper evidence on TEL1.
• Figure 7-4 Tampered TEL2 illustrates tamper evidence on TEL2.
• Security label over screws is missing or penetrated.
• Text attributes (e.g. size, font, orientation, etc.) on security label does not match the original TEL.
• TEL label cutouts do not match original.
• FCM3 assembly lid does not sit evenly or looks deformed. If evidence of tampering is apparent, the operator must assume the FCM3 has been compromised and so should decommission that FCM3. At a minimum the operator must discontinue using that FCM3 in any way that relies on that FCM3’s cryptographic capabilities. Once tampering of a TEL has been detected, the FCM3 cannot thereafter ever be considered to be in Approved mode.

7.1.1 Figure 1 – TEL1 and TEL2

Figure shows TEL1 the BSMI label and TEL2 Warranty Label Figure 7-1 TEL1 BSMI Label

Figure 7-2 TEL2 BSMI Label

To provide tamper-evidence of FlashCore Module 3 Assembly cover removal:

7.2.1 Figure 2 – Tampered TEL1

Showing tamper-evidence on TEL1 Figure 7-3 Tampered TEL1 Where flaking and general distress are seen at each end of the label

7.2.2 Figure 3 – Tampered TEL2

Showing tamper evidence of TEL2 Figure 7-4 Tampered TEL2 Where flaking and general distress are seen at each end of the label

The FCM3 does not claim non-invasive security relevant to FIPS 140-3 validation.

The following table defines the keys / CSPs and the operators / services which use them. Note that:

• The use of PIN CSPs to authenticate is implied by the operator access control.
• All non-volatile storage of keys and CSPs is internal to the FCM3 and to which there is no logical or physical access from outside of the FCM3.
• The FCM3 uses a SP 800-90Ar1 DRBG and adopts the Hash_DRBG mechanism.
• Non-critical security parameters are not shown in this table.
• There is no audit feature supported which is security-relevant.
• The module implements a manual distribution using an electronic entry mechanism for SSP input and output per IG 9.5.A.

4) 4) Table 9-1 SSPs * per https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf; Table 2, seedlen ** Please note that the ‘FW erification Key’ is not considered an SSP per ISO IEC section 7. and is only included in the table for completeness.

Table 9-2 Non-Deterministic Random Number Generation Specification

No matter the FCM3 is in Approved mode or non-Approved mode, all the temporary keys and CSPs are zeroized when they are no longer needed.

A firmware integrity check (Pre-operational firmware integrity test) is performed as part of the power on process using the same SHA3384/RSA-4096 digital signature. The CPU cores are not allowed to run until and unless the firmware integrity check is run successfully. All the self-tests mentioned in this section can be performed on-demand by the operator by power-cycling the module or by invoking the SSR command via the ‘Reset Module’ service. The NVMe identify controller command indicates failure of self-tests Instead of reporting “ oErrors” as required by the approved mode, the identify controller command will show “FailAAAA” where AAAA are ASCII characters providing additional detail on the type of self-test failure. Self-tests may be invoked on-demand via power-cycle. All errors result in the module entering a "fenced" error state. The two fenced error states are referred to as "Self-Test Failed" and "Operational Test Failed". These error states cannot be normally recovered from without returning the module to the manufacturer for servicing, although IBM also suggests attempting an NVMe "NVM Subsystem Reset" (NSSR) first to attempt to have the module re-run the self-tests.

Table 10-1 Self-tests * This check is made each time a Root Key is expanded, by two key derivations, into XTS’s Key and Key . The Entropy source is continuously tested by a Repetition Count Test (RCT) and Adaptive Proportion Test (APT). SP 800-90Ar1 DRBG Instantiate and Generate Health Tests are addressed by destructing the existing instance and instantiating a new one each time a random number is to be generated. A KAT test is run against the new SP 800-90Ar1 instantiation to assure it is sound before it is used. The DRBG is then used to generate a random number by processing ENT (P) samples. A Continuous Random Number Generator Test (CRNGT) is performed on the output of the DRBG. The first random number generated after power up is not used, and SHA2-256 hash of each subsequently generated new random number is compared to the SHA2-256 of the immediately previous generated random number. The continuous test fails if the two numbers match indicating the output of the DRBG has not changed (i.e. is stuck). A firmware download test which checks the authenticity of the firmware download, is performed on any attempted firmware update to the FCM3. If the SHA3-384/RSA-4096 digital signature of the firmware update does not check, the firmware download is aborted.

The FCM3 does not typically change mode across power cycles and resets. However, certain operations can result in the FCM3 exiting Approved mode. In some of these situations (e.g. failure of the Power On Self Test), the FCM3 cannot be restored to Approved mode and in that case could not provide any further FIPS service. The administrator guidance and product documentation may be acquired by contacting the following email addresses: gkimbue@us.ibm.com nehal@us.ibm.com The following are the security rules for establishment and operation of the FCM3 in a FIPS 140-3 Approved manner. Further detail is available in the appropriate sections of this document.

1. Cryptographic Officers: At receipt of the product examine the shipping packaging and the product packaging to ensure it has not been accessed during shipping by the trusted courier.
2. Cryptographic Officers and Users: At installation, and periodically thereafter, examine the Tamper Evident Labels (TELs) installed at time of manufacture for tamper evidence.
3. Cryptographic Officers and Users: At installation, and periodically thereafter, query the FCM3’s firmware’s code level to be sure it matches the FIPS validated firmware level (see section 2.3). Additionally, use the “FIPScode?” service to assure the firmware identifies itself as “FIPScode” (i.e. that the proper compile time options were used when it was built).
4. Cryptographic Officers: Up to two key encryption keys (KEK(s)) need to be established for any future TCG authentication. First the FCM public key needs to be queried, generate a 256bits KEK, encrypt it by the RSA public key and pass it down to FCM.
5. Cryptographic Officers: At installation, determine if the FCM3 has been used previously (e.g. has a SLR already been established?). If so, then invoke the “Revert via OFS” service to zeroize all previously established secret keys and CSPs and remove any SLRs.
6. Cryptographic Officers: Transition the FCM3 to Approved mode by invoking the Activate method for each SLR to be created
7. Cryptographic Officers and Users: At installation, set all operator PINs applicable for the Approved mode to private values of 256 bits length by use of Approved mode: Drive Owner, Admins, and Users. The default authentication data is forcefully replaced upon firsttime authentication, otherwise it won’t be in Approved mode of operation.
8. Cryptographic Officers (specifically LockingSP Admins) to operate in Approved mode: Set ReadLockEnabled and WriteLockEnabled to “True” on each activated SLR. Periodically thereafter these settings should be checked to be sure they have not been modified.
9. Cryptographic Officers: Use the “FIPSmode?” service to assure the firmware sees itself as being in Approved mode.
10. Cryptographic Officers: At installation, disable the “Makers” authority by use of the TCG Set method.
11. After secure initialization is complete, do a power-on reset to clear authentications established during initialization.
12. Users: Do a GenKey of each SLR’s Media Encryption Key (MEK)
13. Cryptographic Officers: erify that the FCM3 indicates it is running “FIPSmode oErrors”. If all of these steps are followed correctly, the FCM3 will be in Approved mode of operation. It should be noted that all of the conditions detailed above must continue to be met to remain in Approved mode. Failure to follow these instructions would result in the module operating in a non-compliant state.

Each time a new CO role is to be assumed, the current Session must be closed, and a new Session started (or do a power-on reset), so that the previous authentication to the previous CO authority is cleared.

The FCM3 does not claim to mitigate against any other attacks relevant to FIPS 140-3 validation. - End --