| Standard | FIPS 140-3 |
|---|---|
| Overall level | 2 |
| Module type | Hardware |
| Embodiment | Multi-Chip Embedded |
| Status | Active |
| Sunset date | 11/2/2030 |
| Caveat | When installed, initialized and configured as specified in Section 11.1 of the Security Policy. No operator authentication is enforced for executing security services that were unlocked by an authenticated service |
| Vendor | IBM(R) Corporation |
| Algorithm | ACVP Cert |
|---|---|
| AES-CBC | A6888 |
| AES-ECB | A2687 |
| AES-ECB | A6888 |
| AES-ECB | AES 5897 |
| AES-KW | A6888 |
| AES-KWP | A6888 |
| AES-XTS | AES 5897 |
| AES-XTS Testing Revision 2.0 | A2687 |
| Conditioning Component AES-CBC-MAC SP800-90B | A6888 |
| Hash DRBG | A6888 |
| HMAC-SHA2-256 | A6888 |
| KDF SP800-108 | A6888 |
| KTS-IFC | A6888 |
| RSA KeyGen (FIPS186-4) | A6888 |
| SHA2-256 | A6888 |
| SHA2-512 | A6888 |
| SHA3-384 | A1883 |
| SHA3-384 | A2686 |
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;IBM® NVMe FlashCore™ Module 3 Security Level 2 Rev. 3.9
| # | Section | Page |
|---|
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.
ISO/IEC 24759 Section 6. [Number FIPS 140-3 Section Title Security Level Below]
1 General 2
2 Cryptographic module specification 2
3 Cryptographic module interfaces 2
4 Roles, services, and authentication 2
5 Software/Firmware security 2
6 Operational environment N/A
7 Physical security 2
8 Non-invasive security N/A
9 Sensitive security parameter management 2
10 Self-tests 2
11 Life-cycle assurance 2
12 Mitigation of other attacks N/A
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:
The following FCM3 configurations have been validated: Model Hardware Firmware Distinguishing Version Features IBM NVMe FlashCore Module 3 Xlarge 03GH930 3.1.5.99 38.4TB physical capacity TEL part number: 03JN363 IBM NVMe FlashCore Module 3 Large 03GH932 3.1.5.99 19.2TB physical capacity TEL part number: 03JN363 IBM NVMe FlashCore Module 3 Medium 03GH934 3.1.5.99 9.6TB physical capacity TEL part number: 03JN363 IBM NVMe FlashCore Module 3 Small 03GH936 3.1.5.99 4.8TB physical capacity TEL part number: 03JN363 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:
CAVP Cert Algorithm and Mode / Description / Key Size(s) / Use / Standard Method Key Strength(s) Function Decrypt KEK (key encryption key) by A6888 KTS-IFC KTS Modulo: 3072; Hash RSA private key with Algorithms: SHA2-256 OAEP SHA2-256 method 3072-bit modulus Unencapsulation KTS OAEP basic providing 128 bits of KEK (key encryption A6888 KTS-IFC (F/W) responder with encryption strength key) by RSA private SP 800-56B Rev. 2 SHA2-256 key with OAEP (*5) SHA2-256 method
384bits digest As part of verification of a code SHA3-384 (H/W) A1883 SHA3 load’s digital FIPS 202 signature (4 byte aligned only *2) 384bits digest As part of verification of a code SHA3-384 (H/W) A2686 SHA3 load’s digital FIPS 202 signature (4 byte aligned only) 256-bits key A primitive used by XTS-AES-256 AES-ECB (H/W) AES ECB A2687 FIPS 197 encrypt/decrypt 256-bits key User Data written by a host application is encrypted; AES-XTS (H/W)* A2687 XTS-AES Enc/Dec decryption is SP 800-38E performed on read 128bits key A primitive used by the AES-CBC-MAC AES-CBC conditioning A6888 SP 800-38A AES CBC mode component for whitening performed as part of entropy processing
by AES key wrap & AES-ECB (F/W) AES ECB A6888 unwrap FIPS 197 Encrypt/Decrypt A6888 256 bits key It’s used in the AES-KW (F/W) AES-KEY-WRAP context of TCG SP 800-38F AES-KEY-UNWRAP authentication A6888 AES-KEY-WRAP with 256 bits key It’s used in the AES-KWP (F/W) Padding context of TCG SP 800-38F AES-KEY-UNWRAP authentication with Padding A6888 SP 800-38F. KTS (key 256-bit keys providing 256 It’s used in the AES-KWP KTS wrapping and bits of encryption strength context of TCG SP 800-38F unwrapping) per IG authentication D.G Whitening Conditioning Component Key Length: 128; Payload performed as part of A6888 AES-CBC-MAC AES-CBC-MAC SP800-90B Length: 384 entropy processing
A6888 Hash DRBG-SHA-512 DRBG with sha SHA2-512 Random number (F/W) DRBG generation SP 800-90Arev1 A6888 256 bits digest Hash of PINs used to authenticate, as well HMAC-SHA2-256 (F/W) HMAC-SHA2-256 as a primitive used FIPS 198-1 by the KDF A6888 KDF Key derivation function Key derivation KDF SP 800-108 (rev1) with HMAC-SHA2-256 A6888 RSA Key Generation RSA 3072-bits Generation of RSA B.3.3 key pair at startup FIPS 186-4 A6888 256-bits digest A primitive used by SHA2-256 (F/W) SHA2-256 HMAC-SHA2-256 FIPS 180-4 A6888 SHA2-512 (F/W) 512-bits digest A primitive used by SHA2-512 FIPS 180-4 DRBG-SHA-512 AES-ECB (H/W) AES ECB mode 256-bits key A primitive used by AES #5897 FIPS 197 encrypt/decrypt XTS-AES-256 256-bits key User Data written by a host application is encrypted; AES-XTS (H/W)* AES #5897 XTS-AES Enc/Dec decryption is SP 800-38E performed on read Physical entropy source Seeding the DRBG ENT (P) N/A ENT based on hardware ring SP 800-90B oscillators
Vendor Affirmed RSA SigVer (H/W) PKCS scheme v1.5, verification of a code RSA *3 FIPS 186-4 SHA3-384 hash function load’s digital signature Vendor Affirmed CKG (F/W) Cryptographic Key Cryptographic Key CKG *4 SP 800-133rev2 Generation Generation Table 2-2 Approved Algorithms The modules does not support any of the following:
*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
Physical port Logical interface Data that passes over port/interface PCIe connector Data Input NVMe protocol commands in PCIe connector Data Output NVMe protocol commands out PCIe connector Control Input Drive control operations PCIe connector Status Output Drive status PCIe connector Power N/A 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.
Anyone who has the ability to remove and then restore power to a FCM3 can cause a power cycle which will cause a reset of the FCM3, 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 PI 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. For PIN-based authentications (e.g., TCG SID, TCG Admins 1- , etc.), they’re considered as ‘memorized secret’ authentication mechanism.
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 FCM3 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 and upon Revert via OFS, the FCM3 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 initiate a key establishment process by querying the RSA public key, generating one or two key encryption keys (KEKs) - two can take advantage of the dual port architecture, and encrypting it/them via RSA OAEP SHA2-256 method. FCM3 decrypts the message, checks the key encryption key and then both parties have agreement upon the KEK(s). Operators then authenticate with the FCM3 by providing a PIN. The PIN is AES key wrapped/unwrapped by the established KEK. The provided PIN is salted, hashed and compared to the hash non-volatilely stored when that PIN was established. The salt is stored in a different non-volatile location. Per the TCG SWG Core (see Section 1.3 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. Neither the TryLimit nor the Persistence settings can be changed, both have their respective Writeable Flags permanently set to FALSE.
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:
Role Service Input Output Set PIN PIN Operation status Activate SLR PIN Operation status Enable / Disable AdminSP PIN Operation status Drive Owner Admin Revert via OFS PIN Operation status Enable Secure Key Passing TCG vendor specific Operation status ** command Set PIN PIN Operation status AdminSP Admin1 Revert via OFS PIN Operation status Set PIN PIN Operation status Enable / Disable LockingSP PIN Operation status Admin(s) LockingSP Admin1-4 Crypto-Erase of SLR PIN Operation status Revert via OFS PIN Operation status Set PIN PIN Operation status Set Geometry PIN Operation status LockingSP User2 Lock / Unlock SLR for Rd/Wr PIN Operation status Crypto-Erase of SLR PIN Operation status User Data Read * NVMe read command Operation status with data User Data Write * NVMe write command with Operation status data Cold boot Reseat FCM3 drive Card boots up Reset module NVMe reset command Card resets and boots up FIPSmode? NVMe identify controller Operation status with Unauthenticated command identify controller response FIPScode? NVMe identify controller Operation status with command identify controller response Get Version NVMe identify controller Operation status with command identify controller response KEK(s) setup TCG vendor specific Operation status command Board report NVMe vendor specific Operation status with board command report data
DRBG generate bytes TCG random service Operation status with command random bytes Firmware download Firmware image Operation status 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 Role Authentication Method Authentication Strength Drive Owner (CO) PIN (Memorized Secret) 1 in 2^256 per attempt, with a maximum of protected by AES key wrap 1,538 attempts per minute. (Memorized (Single Factor Cryptographic Secret). Software)
maximum of 7.85 attempts per minute. (Single Factor Cryptographic Software). AdminSP Admin1 (CO) PIN (Memorized Secret) 1 in 2^256 per attempt, with a maximum of protected by AES key wrap 1,538 attempts per minute. (Memorized (Single Factor Cryptographic Secret) Software)
maximum of 7.85 attempts per minute. (Single Factor Cryptographic Software) LockingSP Admin1-4 (CO) PIN (Memorized Secret) 1 in 2^256 per attempt, with a maximum of protected by AES key wrap 1,538 attempts per minute. (Memorized (Single Factor Cryptographic Secret) Software)
maximum of 7.85 attempts per minute. (Single Factor Cryptographic Software) LockingSP User2 (User) PIN (Memorized Secret) 1 in 2^256 per attempt, with a maximum of protected by AES key wrap 1,538 attempts per minute. (Memorized (Single Factor Cryptographic Secret) Software)
maximum of 7.85 attempts per minute. (Single Factor Cryptographic Software) Table 4-2 Roles and Authentication Service Description Approved Keys and/or Roles Access rights to Keys and/or SSPs* Indicator Security SSPs Functions Set PIN Change operator AES-KWP; SID PIN; Drive SID PIN W TCG set method returns authentication data SHA2-256; LockingSP Owner, GOOD AES-KWP Admin1-4 AdminSP LockingSP Admin1-4 W KTS PINs; Admin1, PINs
AdminSP LockingSP AdminSP Admin1 PIN W Admin1 Admin1PIN; 4/User1-8 LockingSP User2 PIN W, E LockingSP User2; KEK E PIN; KEKs; LBA Range LBA Range Root Key E Root Key Activate SLR Allocate a SUM AES-KWP; SID PIN; Drive SID PIN W, E TCG activate method Locking Range (SLR) SHA2-256; KEKs Owner returns GOOD AES-KWP KEK E KTS Firmware Load firmware image. RSA SigVer; FW None * E New code boots on boot load If the downloaded SHA3-384 Verification following firmware load firmware image Key signature checks, then the FCM3 will boot to the new code at next reboot. Any firmware loaded into this module that is not shown on the module certificate, is out of the scope of this validation and requires a separate FIPS 140-3 validation. Enable / Enable / Disable the AES-KWP; SID PIN Drive SID PIN W, E TCG set method returns Disable AdminSP Admin1 SHA2-256; KEKs Owner GOOD AdminSP AES-KWP KEK E Admin KTS Enable / Enable / Disable a AES-KWP; LockingSP LockingSP LockingSP W, E TCG set method returns Disable LockingSP Admin SHA2-256; Admin1-4 Admin1- 4 Admin1-4 PINs GOOD LockingSP AES-KWP PINs; KEK E Admin(s) KTS KEKs Set Set the starting LBA AES-KWP; LockingSP LockingSP LockingSP W, E TCG set method returns Geometry and size of the SLR. SHA2-256; User2 PIN; User2 User2 PIN GOOD AES-KWP KEKs KTS KEK E Lock / Block or allow read AES-KWP; LockingSP LockingSP LockingSP W, E TCG set method returns Unlock SLR (decrypt) / write SHA2-256; User2 PIN; User2 User2 PIN GOOD for Rd/Wr (encrypt) of user data AES-KWP KEKs; in a range. KTS LBA Range KEK; E; Root Key
LBA Range E Root Key User Data Encryption/decryption AES-XTS LBA Range None E NVMe read/write Read / Write of user data to/from a MEKs command returns GOOD SLR. Access control to this service is provided through Lock/Unlock SLR for Rd/Wr Crypto-Erase Erase user data in a CKG; Admin1-4 LockingSP LockingSP W, E TCG Erase Method of SLR SUM Locking range by AES-KWP; PINs; Admin1- 4 Admin1-4 returns GOOD changing its SHA2-256; LockingSP PINs; associated MEK AES-KWP User2 PIN; LockingSP E KTS KEK; User2 PIN; LBA Range KEK; Z Root Key; LBA Range Z LBA Range Root Key; MEKs; LockingSP Locking SP W, E; TCG GenKey/Erase DRBG EI; User2 User2 PIN Method returns GOOD DRBG KEK E; Seed; LBA Range G, E, Z; DRBG C; Root Key DRBG V; LBA Range G, Z; MEKs DRBG EI G, E; DRBG Seed G, E; DRBG C G, E; DRBG V G, E; Revert via Exit Approved mode. CKG; SID PIN; Drive SID PIN W, E, Z TCG OFS Note: FCM3 will enter AES-KWP; LockingSP Owner LockingSP Z LockingSPObj.Revert(), unestablished state. SHA2-256; Admin1-4 Admin1-4 PINs TCG AES-KWP PINs; AdminSP Z AdminSPObj.Revert() KTS AdminSP Admin1 PIN returns GOOD Admin1 LockingSP Z PIN; User2 PIN LockingSP KEK E, Z User2 PIN; LBA RangeRoot G, E, Z KEK; Key LBA Range LBA Range G, Z Root Key; MEKs LBA Range RSA private Z MEKs; key RSA private RSA public key Z key; DRBG EI G, E, Z RSA public DRBG Seed G, E, Z key; DRBG C G, E, Z DRBG EI; DRBG V G, E, Z DRBG AdminSP SID PIN Z TCG Seed; Admin1 LockingSP Z AdminSPObj.Revert() DRBG C; Admin1-4 PINs
DRBG V; AdminSP W, E, Z Admin1 PIN LockingSP Z User2 PIN KEK E, Z LBA RangeRoot G, E, Z Key LBA Range G, Z MEKs RSA private Z key RSA public key Z DRBG EI G, E, Z DRBG Seed G, E, Z DRBG C G, E, Z DRBG V G, E, Z LockingSP LockingSP W, E, Z TCG Admin1- 4 Admin1-4 PINs LockingSP.RevertSP() LockingSP Z User2 PIN KEK E, Z LBA RangeRoot Z Key LBA Range Z MEKs Power On Firmware integrity RSA SigVer; FW None FW Verification E Cold-Boot or Power-Oncheck on boot (Pre- RSA Verification Key Reset and drive boots operational self-test). KeyGen Key; RSA private G, Z up This maps to the RSA private key ‘Performs Self-Tests’ key; RSA public key G, Z mandatory service. RSA public key; KEK Z KEK; DRBG EI Z DRBG EI; DRBG DRBG Seed Z Seed; DRBG C; DRBG C Z DRBG V; DRBG V Z Reset Runs all POSTs and None None None All SSPs Z Factory Reset Module zeroizes keys & CSPs in RAM. This maps to the ‘Perform zeroization’ mandatory service. FIPSmode? Reports whether, None None None N/A NVMe Identify: from a drive Controller Identify, perspective, the drive bytes 3600-3607 (set to is in Approved mode. “FIPSmode”) This corresponds to
the Show Status mandatory service. FIPScode? Reports whether the None None None N/A NVMe Identify: code level in Controller Identify, operation was FIPS bytes 3616-3623 (set to validated “FIPScode”) Get Version Report code version. None None None N/A NVMe Identify: This maps to the Controller Identify, Show Module’s bytes 64-71 Versioning Information mandatory service. DRBG Returns a SP800- DRBG DRBG EI; None DRBG EI G, E TCG Random() method Generate 90Ar1 DRBG Random DRBG DRBG Seed G, E returns GOOD Bytes Number of # of bytes Seed; DRBG C G, E requested up to 50 DRBG C; DRBG V; DRBG V G, E Enable Enable secure key SHA2-256 SID PIN Drive E TCG skp enable() Secure Key passing Owner method returns GOOD Passing (SKP) KEK(s) setup Establish KEK(s) KTS-IFC KEKs; None KEK W TCG kek setup() method during startup RSA public returns GOOD key; RSA private E RSA private key key RSA public key R Board report Dump FCM status N/A N/A None N/A Board report trigger and dump commands return GOOD 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. Physical Security Mechanism Recommended Frequency of Inspection/Test Guidance Details Inspection/Test Inspect physical tamper evidence At least once per month Visual inspection on the tamper TEL1-2 evidence TELs Table 7-1 Physical Security Inspection Guidelines The operator is required to inspect the FCM3 periodically for any of the following types of tamper evidence:
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:
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 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:
#A6888, RAM, After AES-KWP Plaintext authentication KTS RAM, service #A6888 encrypted via AESKWP if SKP enabled LockingSP 256 bits size SHA2- Set by Import N/A Non- Revert via OFS Use to User2 / 256 bits 256 operator Encrypted volatile, authenticate PIN strength #A6888, via AES-KWP hashed via as a LockingSP AES-KW KTS SHA2-256 User. #A6888, RAM, After Used to AES-KWP Plaintext authentication encrypt the KTS RAM, service LBA Range #A6888 encrypted Root Key in via AES- storage KWP if SKP enabled LBA Range 256 bits size KDF Generated N/A N/A Non- Revert via Use to derive Root Key / 256 bits SP800- from volatile, OFS; LBA Range strength 108 DRBG encrypted Crypto-Erase MEKs #A6888 via AES-KW of SLR LBA Range 256 bits size AES-XTS These 2 N/A N/A CPU RAM, Revert via Use in Encrypt MEKs each / 256 #AES keys are plaintext OFS; / Decrypt User bits strength 5897, derived Crypto-Erase Data each from the of SLR; AES-XTS LBA range Auto-zeroized #A2687 root key after use using the approved SP800108rev1 KDF DRBG EI 1024 bits Hash Generated N/A N/A CPU RAM, Revert via Use in services (03GH934 DRBG using the plaintext OFS; which use the and #A6888 module’s Power On; DRBG 03GH936) ENT (P) Auto-zeroized after use
(03GH932 and 03GH930) DRBG Seed 1024 bits Hash Generated N/A N/A CPU RAM, Power On; Use in services (03GH934 DRBG using the plaintext Auto -zeroized which use the and #A6888 module’s after use DRBG 03GH936)* ENT (P)
DRBG C DRBG Hash Generated N/A N/A CPU RAM, Revert via Use in services intermediate DRBG using the plaintext OFS; which use the values C #A6888 module’s Power On DRBG (888 bits ENT (P) each) DRBG V DRBG Hash Generated N/A N/A CPU RAM, Revert via Use in services intermediate DRBG using the plaintext OFS; which use the values V #A6888 module’s Power On DRBG (888 bits ENT (P) each) FW 4096 bits RSA Pre- N/A N/A Non- N/A Use in Verification size / 152 SigVer loaded; volatile, firmware load Key** bits strength (Vendor Generated plaintext test signature Affirmed) externally verification and hardcoded into the module RSA private 3072 bits KTS-IFC RSA N/A N/A CPU RAM, Revert via Use in KEKs key size / 128 KeyGen plaintext OFS; establishment bits strength (FIPS186- Power On 4) #A6888 RSA public 3072 bits KTS-IFC RSA Exported in N/A CPU RAM, Revert via Use in KEKs key size / 128 KeyGen plaintext plaintext OFS; establishment bits strength (FIPS186- Power On 4) #A6888 KEKs 256 bits size AES-KWP N/A Import N/A CPU RAM, Revert via Use in unwrap / 256 bits #A6888, Encrypted plaintext OFS; of any strength AES-KWP via KTS-IFC Power On encrypted PIN KTS during #A6888 authentication 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.
RBG entropy source: Entropy sources Minimum number of bits of Details entropy Hardware ring oscillator 1024 bits (03GH934 and 03GH936) The entropy source provides 128bits of entropy per 128-bits of output from the AES-CBC-MAC vetted conditioner (CAVP Cert. #A6888) for the 03GH934 and 03GH936 modules. The entropy source provides 74-bits of entropy per 128-bits of output from the
for the 03GH932 and 03GH930 modules. Due to oversampling and conditioning the module's DRBG is seeded with 1024 bits of entropy data, which is enough to support its maximum security strength. 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. Function Tested Self-Test KAT Implementation If this KAT test fails Firmware Integrity Test Pre-Operational RSA-4096 with SHA3-384 Enters FIPS Self-Test Fail Self-Test State Firmware Load Test Conditional RSA-4096 with SHA3-384 Firmware Load operation Firmware Load fails Test SHA2-256 CAST Hash KAT performed Enters FIPS Self-Test Fail State AES-256-KW-WRAP CAST Encrypt KAT performed Enters FIPS Self-Test Fail State AES-256-KW-UNWRAP CAST Decrypt KAT performed Enters FIPS Self-Test Fail State AES-256-KWP-WRAP CAST Encrypt KAT performed Enters FIPS Self-Test Fail State AES-256-KWP-UNWRAP CAST Decrypt KAT performed Enters FIPS Self-Test Fail State Hash DRBG (SHA-512) CAST DRBG KAT performed Enters FIPS Self-Test Fail State HMAC-SHA2-256 CAST HMAC KAT performed Enters FIPS Self-Test Fail State ECB-AES-256 CAST Encrypt KAT performed Enters FIPS Self-Test Fail State XTS-AES-256 CAST Encrypt KAT performed Enters FIPS Self-Test Fail State CBC-AES-128 CAST Encrypt KAT performed Enters FIPS Self-Test Fail State SHA3-384 (H/W) CAST Digest KAT performed Enters FIPS Self-Test Fail State RSA-4096 (H/W) CAST Verify KAT performed Enters FIPS Self-Test Fail State AES-ECB-256 (H/W) CAST Encrypt performed Enters FIPS Self-Test Fail State
AES-ECB-256 (H/W) CAST Decrypt performed Enters FIPS Self-Test Fail State XTS-AES-256 (H/W) CAST Encrypt KAT performed Enters FIPS Self-Test Fail State SP 800-108rev1 KDF CAST KDF KAT performed Enters FIPS Self-Test Fail with HMAC-SHA2-256 State XTS Key1 != XTS Key 2 Conditional Not a KAT Enters FIPS Self-Test Fail critical function State test (Before Key Usage)* KTS-OAEP 3072 with CAST RSA decrypt KAT performed Enters FIPS Self-Test Fail SHA2-256 State RSA pair-wise Conditional Encrypt with public key and Enters FIPS Self-Test Fail consistency (3072 bit pair-wise decrypt with private key, then State modulus) consistency test compare the answer (Before Key Usage) *2 Entropy source APT & CAST (at APT and RCT performed on Enters FIPS Self-Test Fail RCT Power-On and entropy source samples State during Entropy Generation) 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.
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 --