IBM® NVMe FlashCore™ Module 2

Certificate

Approved Algorithms (15)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for IBM® NVMe FlashCore™ Module 2
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>2.2.0.99</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Firmwar e load</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>User Data Read *<br/>Power On</i>"]
    C4["[high] Physical/logical<br/>interfaces (some 'blocked<br/>in firmware')<br/><i>PCIe connector</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"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I4["Interface reachability may<br/>vary by boot stage and<br/>lifecycle state."]
    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"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    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?"]
    R4["Are interfaces blocked<br/>before the bootloader<br/>runs, or only after<br/>approved mode starts?"]
    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"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E4["lifecycle reachability<br/>matrix · boot-stage<br/>interface timing ·<br/>factory/recovery/error-state<br/>access controls"]
    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
  C1 --> I1 --> R1 --> E1
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C4 --> I4 --> R4 --> E4
  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 C1,C2,C3,C4,C5,C6 clue;
  class I1,I2,I3,I4,I5,I6 infer;
  class R1,R2,R3,R4,R5,R6 risk;
  class E1,E2,E3,E4,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for IBM® NVMe FlashCore™ Module 2
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>2.2.0.99</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Firmwar e load</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>User Data Read *<br/>Power On</i><br/>src: securityPolicy.services"]
    C4["[high] Physical/logical interfaces (some 'blocked in firmware')<br/><i>PCIe connector</i><br/>src: securityPolicy.portsAndInterfaces"]
    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 C1,C2,C3,C4 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

IBM® NVMe FlashCore™ Module 2 Security Level 2 Rev. 2.6

• July 24, 2024 ® Corporation IBM

Table of Tables Table of Figures

This is the security policy associated with the IBM NVMe FlashCore Module 2, 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.2 References 1) and Implementation Guidance (see Section 1.2 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. 2. 3. 4. 5. 6. 7. 8. FIPS PUB 140-3, issued Mar 22, 2019 FIPS 140-3 Derived Test Requirements, issued Mar, 2020 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program, last updated May 4, 2021 TCG Storage Architecture Core Specification, Specification Version 2.01 TCG Storage Security Subsystem Class: Opal, Specification Version 2.01 TCG Storage Opal SSC Feature Set: PSID Version 1.00 TCG Storage Opal SSC Feature Set: Single User Mode, Specification Version 1.00 NVM Express Revision 1.2.1

AdminSP AES APT ARM CAVP CBC CKG CLiC CO CPLD CPU CRNGT CSP DDR4 DRBG ECB ENT FCM2 FIPS FKM FPGA HMAC IC IG LBA KAT KDF KEK Administrative security partition, a TCG term Advanced Encryption Standard (FIPS 197) Adaptive Proportion Test Advanced RISC Machine Cryptographic Algorithm Validation Program Cipher Block Chaining, an encryption mode Cooperative Key Generation CryptoLite in C Crypto-Officer Complex Programmable Logic Device Central Processing Unit Continuous Random Number Generator Test Critical Security Parameter Double Data Rate 4 memory Deterministic Random Bit Generator Electronic Codebook Mode Entropy FlashCore Module 2 Federal Information Processing Standard Flash Key Management Field Programmable Gate Array Hash-based Message Authentication Code Integrated Circuit Implementation Guide Logical Block Address Known Answer Test Key Derivation Function Key Encryption Key

LockingSP MEK MSID NAND NOR NSSR NVMe OFS PIN POST PSID RAM RCT RSA SHA SID SLR SP SSC SSP SUM SWG TCG TEL XTS Locking Range security partition, a TCG term Media Encryption Key Manufactured SID, TCG term for a unique per FCM2 public value used as the default Not AND (a type of flash memory) A type of flash memory NVMe SubSystem Reset Nonvolatile memory express Original Factory State Personal Identification Number Power on Self-Test Physical SID, TCG term for a unique per FM value public value Random Access Memory Repetition Count Test Rivest Shamir Adleman algorithm Secure Hash Algorithm Security ID, TCG term for Drive Owner CO role’s PIN SUM Locking Range Security Subsystem Class Single User Mode Storage Work Group Trusted Computing Group Tamper Evident Label XEX-based tweaked-codebook mode with ciphertext stealing, an encryption mode

The cryptographic module is the IBM NVMe FlashCore Module 2 (FCM2) in its entirety. The cryptographic module will be referred to as the FCM2 throughout this document. This FCM2 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 FCM2 support of the TCG Opal SSC interface. The FCM2 is a multiple-chip embedded cryptographic module implementation. The outside surfaces of the FlashCore Module 2 Assembly are the physical cryptographic boundary. The module’s logical boundary is comprised of all hardware and firmware components contained within the module’s physical boundary. The host interface to the FCM2 is physically a PCIe connector, over which the industry-standard NVMe protocol (see Section 1.2 References 8) is supported. Through the NVMe logical interface the FCM2 supports the TCG SWG Core (see Section 1.2 References 4) and TCG Opal SSC (see Section 1.2 References 5) protocols. All control of the FCM2 via its interfaces is typically through an application on a host system. All human control of an FCM2 is assumed to be through such an application. The primary cryptographic service supported by the FCM2 is encryption of user data at rest: encrypting user data written to the FCM2 before the resultant ciphertext is written to the FCM2’s non-volatile solid-state memory. The FCM2 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 FCM2 supports: cryptographic erase, which nearly instantly renders all previously encrypted user data to be effectively destroyed. The FCM2 supports TCG Opal access controls, which restrict access to use of, and administration of, the encryption and cryptographic erase services.

The FCM2 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 FCM2 may be securely initialized so that it operates in FIPS 140-3 Mode of operation (hereafter “approved mode”). After the FCM2 has been Securely Initialized and operated per the Security Rules detailed in Section 11.1, the FCM2 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 FCM2 can use the “FIPSmode?” service, if it does not return the expected status (see Section 4.5), then the FCM2 is not operating in approved mode. An operator can cause an FCM2 operating in approved mode to quit approved mode by use of the FCM2’s “Revert via OFS” service. This service will zeroize the FCM2’s keys and CSPs and transition it through its Original Factory State (OFS) to its noncompliant state. The operator can then cause that FCM2 to return to approved mode by following the Secure Initialization procedure detailed in Section 11.1 again. To operate the FCM2 is in its, 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 FCM2 is no longer being operated in its approved mode of operation.

When operated in this mode the FCM2 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 a 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 FCM2 had been previously operated with a non-FIPS code load, a Locking Range may have been established, though that FCM2 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 FCM2 is then updated to the FIPS code load, then the FCM2 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 FCM2 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 FCM2 must be of the Single User Mode (SUM) type. The FCM2 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 FCM2 will be, and will remain, “SUM Locking Ranges” (SLRs). SLRs conform to the SUM feature set (see Section 1.2 References 7). Each SLR is controlled and administered solely by the single User role it is associated with per Section 1.2 References 5 and see Section 1.2 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. 2. 3. 4. 5. Creating one or more SLRs (by the Drive Owner)

• the FCM2 supports a Global Range and the additional creation of up to 3 SLRs Customize the User PIN and LBA range associated with each created SLR (by User(s) only) Lock and Unlock SLRs (by User(s) only) Crypto-Erase of SLRs (by User(s) or Locking SP Admin(s)) Crypto-Erase of Global Range (by Locking SP Admin(s))

The following FCM2 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 approved services provided. A complete list of FCM2’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 FCM2 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 first of other two A53 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 A53 cores runs the Flash card (back-end) tasks including the Flash Key Manager (FKM) task. The second of the A53 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.24.3852 (c4T3/FlashSysANSIC64) Two A53 cores have its own memory address space, CPU register files, etc. CSP/SSP is not shared on these two A53 cores, which means only one core has access/control over a certain CSP/SSP.

Table 2-2 Approved Algorithms Table 2-3 Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed The modules does not support any of the following:

• Non-Approved Algorithms Allowed in the Approved Mode of Operation
• 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 FCM2 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 FCM2 Top View The following figure shows placement of TEL1 in red and TEL2 in red.

Figure 2-2 FCM2 Front View Figure 2-3 FCM2 Back View

Edge connector is PCIe physically, NVMe logically Figure 2-4 FCM2 Block Diagram

N/A Table 3-1 Ports and Interfaces Notes: * FCM2 has no control output interface.

Because all user data written to the FCM2 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 FCM2 supports the ability to “zeroize” all keys and CSPs, per the FIPS 140-3 key management requirement, the FCM2 supports the capability to “zeroize” any and all MEKs, which in turn crypto-erases all the user data encrypted with those MEKs. The FCM2 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 FCM2 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 FCM2 for multiple reasons including support for wear-leveling. 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 (see Section 4.2).

Whether in approved mode or not, the TCG Revert and RevertSP methods may be invoked by an appropriately authenticated Role to put the FCM2 into a 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 FCM2 has to be reinitialized before it can return to an 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.2 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 FCM2 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.2 References 5). This role is used to transition the FCM2 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 FCM2, and the FCM2 must have booted to that code level. If the FCM2 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.2 References 5).

When in approved mode, this role’s Authority corresponds to the AdminSP’s Admin1 role defined in Opal SSC (see Section

1.2 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.2 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.

Anyone who has the ability to remove and then restore power to a FCM2 can cause a power cycle which will cause a reset of the FCM2, that is one type of unauthenticated service. Note that since both the MSID and 26-byte PSID are public credentials, “authenticating” with either to gain MSID authority or PSID authority, respectively, amounts to operation in an unauthenticated role. Thus, entering the public PSID value enables unauthenticated invocation of some services (e.g. to invoke the “Revert via OFS” service). No authentication is required to perform the “FIPScode?” and “FIPSmode?” services.

Role-based authentication of operators is supported. For example, the Drive Owner role has its own unique ID which is associated with a dedicated PIN. The Drive Owner’s PIN can be personalized such that it is unique for that role. For some cases, the authentication is performed in a separate associated service. For example, the Read Unlock service is the authentication required to enable subsequent User Data Read service. If an attempt is made to use the User Data Read service without prior authentication, then the User Data Read will fail. Authentications which use the TCG interface can provide the operator and PIN in the StartSession method invocation. Or, an operator may use the Authenticate method to authenticate to a role within a Session that has already been started. Authentications persist until the associated session is closed.

Operators can authenticate by use of either the TCG Authenticate or StartSession methods. The host application can have only a single session open at a time. During a session the application can invoke services for which the authenticated operator(s) have authority. One of security rules enforced by the FCM2 is that the host must not authenticate to more than two operators’ roles while in a session. The host application can authenticate to the “Anybody” authority, which does not have a private credential, for the invocation of some services. Accordingly, the invoked services are effectively unauthenticated services.

On every startup, the FCM2 generates a fresh new RSA key pair. The RSA public key is discoverable on TCG protocol and the RSA private key is a secret. Operators first query the FCM2’s RSA public key and generate a key encryption key (KEK) outside of the drive. The operator encrypts the new KEK via RSA OAEP SHA2-256 method and sends it to the drive. FCM2 decrypts that message using the RSA private key, and then both parties have agreement upon the KEK. After establishment of the KEK, operators then authenticate with the FCM2 by PINs. Outside of the FCM2, any new PIN to be established is AES key wrapped by the KEK. Once sent inside the FCM2, the message is decrypted via AES Key unwrapping, the KEK is confirmed, and then both parties have agreement upon a new PIN. The provided PIN is salted, hashed and compared to the hash nonvolatilely stored when that PIN was established. The salt is stored in a different non-volatile location. Per the TCG SWG Core (see Section 1.2 References 4) specification, PINs have an associated retry attribute (“TryLimit”) that controls the number of unsuccessful attempts before the authentication is blocked. The default value of the TryLimit setting is 100 which specifies up to 100 retries and Persistence is TRUE which means that any count of incorrect authentications will not be reset on reboot. The count of incorrect authentications will be reset upon a successful authentication or TCG Revert via OFS (see Section 4.2). Neither the TryLimit nor the Persistence settings can be changed, both have their respective Writeable Flags permanently set to FALSE. The PINs have a variable length of 128 to 256 bits. Per the policy security rules, the FCM2 only allows programming of PINs that are of length 128 bits or longer (see Section 11.1’s Rule 7). This PIN length results in a probability of at most 1/2128 (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 FCM2 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/2128 = 4.52 x 10-36. For PIN-based authentications (e.g., TCG SID, TCG Admins 1-4, etc.), they’re considered as ‘memorized secret’ authentication mechanism.

The SID is initially set to the value of the manufactured value (MSID). This is a device-unique public value which is 128 to

256 bits long. The Security Rules (see Section 11) for the FCM2 requires that the PIN values must be “personalized” to

private values using the “Set PIN” 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 FCM2 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 and operator access control. Note the following:

• Use of the services described below is compliant only when the FCM2 is in approved mode.
• Not shown are the security functions which underlie 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
• 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. d s SHA256; ); P , W W W W E E W, E E SHA3384 E

SP80090Arev1 DRBG KTSOAEPbasic SHA2256 N/A N/A G, E G, E G, E W E R N/A 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.

FCM2 firmware image has a 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 NOR flash won’t be updated at all. On every startup, a similar check occurs and put the card in fault state when it fails.

N/A The FCM2 operates in a “limited operational environment”. Specifically, the operational environment cannot be modified while the FCM2 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 FCM2 will boot to it following the next cold boot and so will begin operating with the new firmware image. See Section 11.1 on how to configure and setup approved mode on FCM2.

The FCM2 is a multi-chip embedded module that 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-1 TEL1 BSMI Label” for placement of TEL1 and Figure 7 2 TEL2 BSMI Label 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 2 Assembly cover removal for access to or visibility of the solid-state memory Exterior of the FCM2 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 FCM2 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 If evidence of tampering is apparent, the operator must assume the FCM2 has been compromised and so should decommission that FCM2. At a minimum the operator must discontinue using that FCM2 in any way that relies on that FCM2’s cryptographic capabilities. Once tampering of a TEL has been detected, the FCM2 cannot thereafter ever be considered to be in approved mode.

Figure shows TEL1 the BSMI label and TEL2 Warrantee Label.

Figure 7-1 TEL1 BSMI Label Figure 7-2 TEL2 BSMI Label

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

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

Showing tamper evidence of TEL2

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

The FCM2 does not claim to 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:

• All non-volatile storage of keys and CSPs is internal to the FCM2 and to which there is no logical or physical access from outside of the FCM2
• The FCM2 uses a SP 800-90Arev1 DRBG and adopts the Hash_DRBG mechanism
• Non-SSPs are not shown in this table
• The module implements a manual distribution using an electronic entry mechanism for SSP input and output per IG 9.5.A.
• There is no audit feature supported which is security-relevant.
• The AES key wrap implemented by the FCM2 is used for key transport (unwrapping PIN CSPs passed into the module).
• A no security claimed AES-KW implemented by the FCM2 is used for obfuscating stored SSPs as described in the table below. e n Nonvolatile, via SHA256 Nonvolatile, via SHA256 Nonvolatile, via SHA256

Nonvolatile, via SHA256 SP800108 N/A N/A Nonvolatile, d N/A SP800108rev1 KDF Autozeroized SP800108rev1 N/A N/A N/A (P) (P) Autozeroized Autozeroized N/A N/A

e ) 6-4) 6-4) Preloaded; d N/A (P) N/A N/A N/A N/A N/A n. Table 9-1 SSPs Nonvolatile, N/A t t n * per https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Arev1r1.pdf; Table 2, seedlen

Table 9-2 Non-Deterministic Random Number Generation Specification

No matter if the FCM2 is in approved mode or non-compliant state, all the temporary keys and CSPs are zeroized when they are no longer needed.

No additional logical interface in FCM2 module.

The NVMe identify controller command indicates failure of self-tests. Instead of reporting “NoErrors” 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 Key1 and Key2. *2 The RSA PCT is performed upon module startup right after generation of the keypair and therefore prior to any export. The purpose of the keypair is only for key transport. The Entropy source is continuously tested by a Repetition Count Test (RCT) and Adaptive Proportion Test (APT). SP 800-90Arev1 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-90Arev1 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).

The FCM2 does not typically change mode across power cycles and resets. However, certain operations can result in the FCM2 exiting approved mode. In some of these situations (e.g. failure of the Power On Self Test), the FCM2 cannot be restored to approved mode and in that case could not provide any further Approved 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 FCM2 in the approved mode. 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 FCM2’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: A key encryption key needs 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 FCM2 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 FCM2 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

128 to 256 bits length by use of approved mode: Drive Owner, Admins, and Users. The default authentication data is

forcefully replaced upon first-time 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 the ReadLockEnabled and WriteLockEnabled 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 establishment is complete, do a power-on reset to clear authentications established during establishment.
12. Users: do a GenKey of each SLR’s Media Encryption Key (MEK)
13. Cryptographic Officers: verify that the FCM2 indicates it is running “FIPSmodeNoErrors”. If all of these steps are followed correctly, the FCM2 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 steps 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 FCM2 does not claim to mitigate against any other attacks relevant to FIPS 140-3 validation. -- End --

Referenced URLs

• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Arev1r1.pdf