Dell BSAFE™ Crypto Module for C

Certificate

Approved Algorithms (68)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Dell BSAFE™ Crypto Module for C
  %% 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>recovery</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Show Status<br/>Self-test<br/>Self-test Error</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Some services may process<br/>input 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["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 Dell BSAFE™ Crypto Module for C
  %% 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>recovery</i><br/>src: text:keyword"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Show Status<br/>Self-test<br/>Self-test Error</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</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,C5,C6 clueLow;
  class C3 clueHigh;

Security Policy, page by page

13.02.25 Dell Australia Pty Limited, BSAFE Product Team Dell BSAFE™ Crypto Module for C Module Version 3.0.1 FIPS 140-3 Security Policy Document Version 1.13

for C, version 3.0.1 (BSAFE Crypto Module) from Dell Australia Pty Limited, BSAFE Product Team. This document may be freely reproduced and distributed whole and intact including the Contents:

Preface With the exception of the non-proprietary Dell BSAFE™ Crypto Module for C Security Policy document, the overall FIPS 140-3 Security Level 1 validation submission documentation is proprietary to Dell Australia Pty Limited and is releasable only under appropriate non-disclosure agreements. For access to the documentation, contact Dell Support. This security policy describes how the BSAFE Crypto Module meets the Security Level 1 requirements for all aspects of FIPS 140-3, and how to securely operate it. Federal Information Processing Standards Publication 140-3 - Security Requirements for Cryptographic Modules (FIPS 140-3) details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-3 standard and validation program is available on the NIST website. This document deals only with operations and capabilities of the BSAFE Crypto Module in the technical terms of a FIPS 140-3 cryptographic module security policy. More information about BSAFE Crypto Module and the entire BSAFE product line is available from Dell Support. Terminology In this document, the term BSAFE Crypto Module denotes the BSAFE Crypto Module for C, version 3.0.1, FIPS 140-3 validated Cryptographic Module for Overall Security Level 1 for the C language. The BSAFE Crypto Module for C is also referred to as:

• The Cryptographic Module
• The BSAFE Crypto Module
• The module

BSAFE Crypto Module is validated with an overall FIPS 140-3 Security Level 1. Security levels for individual areas are shown in the following table: Table 1 N/A N/A Security Levels 1The module relies on the physical security provided by the host on which it runs.

BSAFE Crypto Module is a software module intended to be used as part of a software system, providing cryptographic services to that system. The module is provided in the following formats:

• Dell PowerMaxOS™ platform: Static library in Executable and Linkable Format (ELF) format, built for the Intel® x86_64 (64-bit architecture).
• Linux® platform: Shared library in ELF format, built for the Intel x86 (32-bit) and x86_64 (64-bit architecture).
• Windows® platform: Dynamic Link Library in Portable Executable (PE) format, built for the Intel x86_64 (64-bit architecture). For Linux and Windows platforms, the module is dynamically loaded into the address space of a user process. For the PowerMaxOS platform, it is linked directly into the user software system. The module follows the standard x86 and x86_64 calling conventions and provides a documented set of functions that can be called from user software. The following diagram illustrates the cryptographic module boundary and logical interfaces: Figure 1 Cryptographic boundary

The module is identified as Dell BSAFE™ Crypto Module for C, version 3.0.1. The constituents of the module are platform-specific:

• For a Linux platform, the module consists of a shared library, libdellbcm3.so For a PowerMaxOS platform, the module consists of a static library, libdellbcm3.a For a Windows platform, the module consists of a dynamic library, dellbcm3.dll The name and version of the module can be accessed from the APIs BCM_module_info() and BCM_module_version(). The FIPS 140-3 validation certificate can be located on the NIST Cryptographic Module Validation Program (CMVP) page using the module name and version reported.

BSAFE Crypto Module is classified as a multi-chip standalone software cryptographic module for the purposes of FIPS 140-3. As such, it is tested on specific operating systems and computer platforms. The cryptographic boundary includes the module running on selected platforms running selected operating systems. The module is packaged as a library containing the module’s entire executable code. The module relies on the physical security provided by the host computer in which it runs. The tested operational environment physical perimeter of the module is the case of the general-purpose computer, which encloses the hardware running the module. The physical interfaces for the module are the physical interfaces of the computer running the module, such as the keyboard, monitor, and network interface. The cryptographic module boundary is the library. This is a shared library for most platforms, dynamically loaded by the application. For some, it is a static library linked directly into the final application. The underlying logical interface to the module is the API, documented in the Dell BSAFE™ Crypto Module for C Developers Guide. The module provides Control Input through the API calls. Data Input and Output are provided in the variables passed with the API calls. Status Output is provided through the return status codes documented for each call. This is illustrated in Figure 1 Cryptographic boundary.

For FIPS 140-3 validation, the module is tested by an accredited FIPS 140-3 testing laboratory on the following operational environments: # Table 2 Tested Operational Environments

# Table 2 Tested Operational Environments (continued)

Table 2 # Tested Operational Environments (continued) Dell BSAFE affirms compliance for the following operational environments: # Table 3 Vendor Affirmed Operational Environments

# Table 3 Vendor Affirmed Operational Environments (continued) Note: When running the module on an affirmed platform, no assurances are made about the minimum strength of generated SSPs, such as keys.

The following table lists the BSAFE Crypto Module Approved algorithms, with the appropriate standards and CAVP validation certificate numbers: Table 4 Approved Algorithms

Table 4 Approved Algorithms (continued)

Table 4 Approved Algorithms (continued)

Table 4 Approved Algorithms (continued)

Table 4 Approved Algorithms (continued) 1Initialization Vector (IV). 2The TLSv1.2 protocol uses the fragment number as part of the IV. The module generates the remaining IV value using internally managed counter initialized at module load to ensure a probability of 2-32 or less, of reusing the same key and IV together. When using a partial IV, the module limits the use of a key and IV pair to 264 - 1 bytes. 3AES in XTS mode is approved only for hardware storage applications. The two keys concatenated to create the single double-length key must be checked to ensure they are different. 4Algorithms designated as “Legacy” can only be used on data that was generated prior to the Legacy Date specified in FIPS 140-3 IG C.M. 5RSA signature primitive 1 (RSASP1). RSA decryption primitive (RSADP). RSADP shall only be used within the context of an SP800-56B rev 2 Key Transport Scheme (KTS). 7Password-based key derivation function 2 (PBKDF2). As defined in SP 800-132, PBKDF2 can be used in the Approved Mode of Operation when used with Approved symmetric key and message digest algorithms. For more information, see Crypto Officer Guidance. Key-based KDF (KBKDF), using pseudo-random functions HMAC-based Feedback Mode. As defined by the HKDF expand step. 9Secure Shell key derivation function (SSH-KDF). SHA3 options for SSH-KDF and X9.63 KDF are vendor affirmed since CAVP testing was not available at the time of module submission. 11ANSI X9.63 KDF. 12Deterministic Random Bit Generator (DRBG). 13Hash-based Message Authentication Code (HMAC). HMAC-based Extract-and-Expand KDF (HKDF). Vendor-affirmed algorithms. The following table lists the BSAFE Crypto Module Non-Approved algorithms, not allowed Table 5 Non-Approved Algorithms Not Allowed in the Approved Mode of Operation 1Triple Data Encryption Standard.

Note: BSAFE Crypto Module does not support any non-approved but allowed algorithms nor non-approved but allowed algorithms with no security claimed.

BSAFE Crypto Module is validated with an overall Security Level 1 for FIPS 140-3, with Security Level 1 for each individual area. See Table 1, Security Levels for additional details.

The module can operate in Approved mode or Non-Approved mode. The mode selected affects which algorithms are available for use. The following section details the algorithms available in each mode:

• In the Approved mode (BCM_MODE_FIPS), the module allows only those cryptographic algorithms listed in Table 4, Approved Algorithms. Non-Approved algorithms not allowed in the approved mode of operation are not available.
• In Non-Approved mode (BCM_MODE_NON_FIPS), the module allows all available cryptographic algorithms. Approved mode is also referred to as FIPS 140-3 mode in the product documentation. In each mode of operation, the complete set of services listed in this Security Policy is available to the Crypto Officer. Warning: Critical Security Parameters must not be shared between modes. This is enforced by the module for key objects, but care must be taken when a key is exported from the module. For example, a key generated in the Approved mode of operation must not be exported and then imported to an application operating in Non-Approved mode.

The module operator must provide a definition of the configuration function BCM_get_config(BCM_CONFIG *config) that is called by the module during startup. The Module mode is set in the operator's function by assigning a value to config->mode. To start the module in the Approved mode of operation, the operator's configuration function should assign the value BCM_MODE_FIPS to the mode member of the configuration structure: BCM_STATUS BCM_get_config(BCM_CONFIG *config) { // Start the module in the Approved mode of operation config->mode = BCM_MODE_FIPS; // ... return BCM_OK; }

To start the module in the Non-Approved mode of operation, the operator's configuration function must assign the value BCM_MODE_NON_FIPS to the mode member of the configuration structure: BCM_STATUS BCM_get_config(BCM_CONFIG *config) { // Start the module in the Non-Approved mode of operation config->mode = BCM_MODE_NON_FIPS; // ... return BCM_OK; } Note: The default value of the mode member is set to BCM_MODE_FIPS. Therefore, if the operator's configuration function does not set the mode, the module starts in the Approved mode of operation. Once the module is initialized and the pre-operational self-tests (POST) have completed successfully, the overall operating mode of the module can be changed by calling the BCM_module_configure() API.

The module uses an approved mode indicator combined with a return status code from an approved security service to indicate the use of an approved service.

• Approved security services that operate on a BCM_CTX use the API BCM_ctx_is_fips() with a return code of 1 as an indicator that the context is operating in the approved mode.
• Approved security services that operate on a BCM_PARAM use the API BCM_param_is_fips() with a return code of 1 as an indicator that the parameters are operating in the approved mode.
• Approved security services that operate on a BCM_KEY use the API BCM_key_is_fips() with a return code of 1 as an indicator that the key is operating in the approved mode.

The module initializes itself automatically when it is loaded dynamically, or as part of the user software system, and runs the POST automatically, regardless of the mode of operation at startup. See Cryptographic Module Specification for the module file format for the supported platforms. The cryptographic algorithm self-tests are executed when the specific algorithm is accessed for the first time by the user software system. All the cryptographic algorithm self-tests can be run manually by calling BCM_module_selftest(). The module does not support degraded operation. If any self-test fails, the cryptographic services of the module are disabled for both modes of operation.

BSAFE Crypto Module is a software module that provides APIs only as logical interfaces. Physical ports and interfaces are not provided by the module. The module conforms to the FIPS 140-3 Security Level 1 requirements for Cryptographic Module Interfaces and does not support a Trusted Channel Interface.

The following table lists the ports and interfaces, and the data that passes over each: N/A N/A N/A N/A Ports and Interfaces Note: The module does not support a Control Output interface.

BSAFE Crypto Module meets all FIPS 140-3 Security Level 1 requirements for Roles, Services and Authentication, implementing only the Crypto Officer role. As allowed by FIPS 140-3, the module does not support identification or authentication of this role. There is no maintenance role, cryptographic bypass capability, or self-initiated cryptographic output. The module does not allow concurrent operators.

The Crypto Officer role is responsible for installing and loading the module and has access to all services provided by the module. This role is assumed automatically once the module has been loaded and the POST have run successfully. The POST are automatically run when the module is first loaded. They can be run manually at any time by calling BCM_module_selftest().

For each service, the Approved Mode indicator is obtained by checking the service status and the Approved mode of the Context, Key, or Key Parameters. A return status code indicates the service status. For information about individual functions that implement each service, see the Dell BSAFE™ Crypto Module for C Developers Guide.

The following is a list of services available to the single Crypto Officer (CO) role. Table 7 Roles, Service Commands, Input and Output

The following is a list of approved services provided by the module: E K E K C Table 8 Approved Services

W, E, Z C W, E, Z C G C E C G P W C R K Z K Table 8 Approved Services (continued)

W, E, Z R, Z C E K R E K W E K W E K E K Table 8 Approved Services (continued)

K W, Z E G C R P Table 8 Approved Services (continued) 1The indicator for the service is one of the following: C: The Approved Mode indicator is obtained by checking the service return status code and the mode of the operation's context by calling BCM_ctx_is_fips(). For approved services, the FIPS indicator function will return

1. K: The Approved Mode indicator is obtained by checking the service return status code and the mode of the operation's key by calling BCM_key_is_fips(). For approved services, the FIPS indicator function will return
2. P: The Approved Mode indicator is obtained by checking the service return status code and the mode of the operation's key parameters by calling BCM_param_is_fips(). For approved services, the FIPS indicator function will return
3. Algorithms designated as “Legacy” can only be used on data that was generated prior to the Legacy Date specified in FIPS 140-3 IG C.M.

The following is a list of non-approved services provided by the module: C Table 9 Non-Approved Services

K C K K Table 9 Non-Approved Services 1The indicator for the service is one of the following: C: The Approved Mode indicator is obtained by checking the service return status code and the mode of the operation's context by calling BCM_ctx_is_fips(). For these non-approved services, the FIPS indicator function will return 0. K: The Approved Mode indicator is obtained by checking the service return status code and the mode of the operation's key by calling BCM_key_is_fips(). For these non-approved services, the FIPS indicator function will return 0.

The module does not implement authentication. The Crypto Officer role is implicitly assumed once the module is loaded, and cleared on module unload.

This section covers integrity measures to demonstrate protection of the software component of BSAFE Crypto Module, which is the whole of the module.

Depending on the platform, the module is either a shared library, dynamic link library or an object file. When the module file is created, a MAC is calculated over the executable code and static data sections, with the resulting integrity block embedded into the object file. The built-in Integrity Test Key is used as the MAC secret. During the pre-operational software integrity test when the module is loaded, a MAC is again calculated over the executable code and static data. The resulting MAC is compared to the integrity block calculated when the module was created. If the MAC differs, the pre-operational software integrity test fails, the POST fails, the module enters the BCM_MODULE_STATE_INTEGRITY_FAILED state and cannot be used for any cryptographic operation. Any operation attempted will return the BCM_ERROR_FIPS_INTEGRITY_FAILURE error status code. The only way to clear this error condition is to unload the module and load it again. The pre-operational software integrity test uses HMAC-SHA2-256. The Cryptographic Algorithm Self-Test (CAST) for HMAC is run prior to the pre-operational software integrity test. This is done to ensure that the MAC implementation used in the integrity test has been self-tested before it is used in the pre-operational software integrity test.

The module provides the BCM_module_selftest() for on-demand integrity testing.

The module is built as either a single shared library, a dynamic link library or an object file that exports symbols for the operations it supports.

BSAFE Crypto Module is FIPS 140-3 validated to operate in a modifiable environment. The module is provided for operating systems running on a general purpose computer platform based on an Intel or AMD CPU.

Each instance of the module that is loaded within an operating system maintains its own instance of internal SSPs. Any additional SSPs loaded into a given instance of the module are not available to other instances. The supported operating environments provide process isolation, with resource and memory protection. Each instance of the module is isolated from others such that SSPs can be accessed or modified only in the module to which they belong. BSAFE Crypto Module does not spawn additional processes.

For FIPS 140-3 validation, the module is tested by an accredited FIPS 140-3 testing laboratory. For the tested operational environments, refer to Table 2, Tested Operational Environments.

For the vendor affirmed operational environments, refer to Table 3, Vendor Affirmed Operational Environments. The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when a specific operational environment that is not listed on the validation certificate, is used.

The module runs on a General Purpose Computer running one of the operational environments listed in Tested Operational Environments and Vendor Affirmed Operational Environments. Each supported operational environment manages its own processes and memory in a logically separated manner. The process management setting is not configurable on the supported operational environments.

BSAFE Crypto Module is classified as a multi-chip standalone cryptographic module. The module is comprised of software only, validated at FIPS 140-3 Security Level 1, and does not claim any physical security.

BSAFE Crypto Module does not implement any non-invasive mitigation techniques.

The following tables list the SSPs present in the module, the relevant standards and details of how they are used and accessed. Table 10 Storage Areas isolates the memory of separate processes Table 11 SSP Input-Output Methods 1The module's Tested Operational Environment's Physical Perimeter. The TOEPP for the BSAFE Crypto Module is the host computer. Sensitive security parameters are input and output using the module APIs. No security function or algorithm is used to transport the data. N/A N/A Table 12 SSP Zeroization Methods BSAFE Crypto Module encapsulates symmetric and asymmetric keys as BCM_KEY objects. For multi-part cryptographic operations, the module defines several object types to encapsulate the intermediate state of the operation.

Examples are BCM_CIPHER objects for symmetric ciphers and BCM_MAC objects for message authentication codes. These objects are created explicitly by the user with function calls to the module. The module defines a BCM_CTX object which can contain SSPs in the form of internal random number generator (RNG) state and associated entropy state. A single BCM_CTX is created automatically when the module starts and is retained by the module as the default context. BCM_CTX objects can be created explicitly by the user with function calls to the module. To zeroize all unprotected SSPs and key components, perform the following procedure:

1. For each object, delete all: a. BCM_CIPHER cryptographic objects with a call to BCM_cipher_delete(). b. BCM_MAC cryptographic objects with a call to BCM_mac_delete(). c. BCM_DIGEST cryptographic objects with a call to BCM_digest_delete(). d. BCM_KEY objects with a call to BCM_key_delete(). e. BCM_PARAM objects with a call to BCM_param_delete(). f. BCM_CTX objects with a call to BCM_ctx_delete().
2. Delete the default context created at startup. To do this, unload the module or call BCM_module_unload(). N/A N/A N/A N/A N/A N/A Table 13 SSPs

BSAFE Crypto Module provides the following approved DRBGs for use in both the Approved Mode of Operation and Non-Approved mode: Table 14 Approved Random Bit Generators 1CTR DRBG with AES-256 is the default DRBG. Table 15 DRBG Output Uses 1All seeds for asymmetric key generation are generated using the direct output of the approved DRBG. 2For details refer to SP 800-56B Rev. 2, Appendix C.

BSAFE Crypto Module for C provides an entropy source that is internal to the module. This entropy source generates entropy that is used to seed the Approved RBGs. The entropy source is provided as an ENT (NP) that is compliant with SP 800-90B, and is estimated to provide a min entropy of 7.96875 bits per byte. Table 16 Non-Deterministic Random Bit Generation Specification The BCM_CTX object manages an approved DRBG and an Entropy NDRBG. The first call to a random number generation service using the BCM_CTX object instantiates the Entropy NDRBG and the DRBG. At instantiation, the DRBG issues a GET call to the Entropy NDRBG for the number of bits of entropy equivalent to the security strength of the DRBG. A call to the BCM_random_seed() API with the BCM_CTX object resets the DRBG seed. The DRBG issues a GET call to the Entropy NDRBG for the number of bits of entropy equivalent to the security strength of the DRBG. A call to the BCM_secure_random_bytes() API with the BCM_CTX object adds a fixed number of bits of entropy to the DRBG state before the DRBG generates output. The DRBG issues a GET call to the Entropy NDRBG for 64 bits of entropy. The entropy is collected from the jitter in the CPU execution time for performing an HMAC over the state and previous noise sample. By collecting multiple jitter samples, a bit stream that meets the statistical measurements which indicate a bit stream is random, is produced and whitened.

The module addresses the requirements of FIPS 140-3. Transitioning the use of cryptographic algorithms and key lengths (SP 800-131A Rev. 2) provides more specific guidance concerning transition periods and time frames where an algorithm or key length transitions from Approved to Non-Approved. None of the Approved algorithms provided by the module are affected by transition periods or time frames. Recommendation for Key Management Part 1 (SP 800-57 Part 1 Rev. 5) specifies security strengths that are acceptable for protecting data going forward. Application writers should consider the specified acceptable use dates with respect to the expected deployment lifetime of the application and the lifespan of the data being protected. The lifespan depends on the type of key and use, but are from 1-3 years. For more information, refer to SP 800-57, Part 1. Table 17 Security Strength Time Frames The correspondence between security strength, algorithms and key size is specified in the following:

• Recommendation for Pair-wise Key Establishment Using Integer Factorization Cryptography (SP 800-56B Rev. 2)
• Recommendation for Key Management Part 1 (SP 800-57 Part 1 Rev. 5)
• Recommendation for Applications Using Approved Hash Algorithms (SP 800-107 Rev. 1). Refer to the latest NIST specifications for up-to-date recommendations on Security Table 18 Correspondence between Security Strength, Algorithms, and Key Size

Table 18 Correspondence between Security Strength, Algorithms, and Key Size (continued)

BSAFE Crypto Module performs a number of pre-operational and conditional self-tests to ensure proper operation. The cryptographic services of the module are disabled when the self-tests are running.

• When self-tests are running all cryptographic operations fail and return the BCM_ERROR_FIPS_MODULE_NOT_READY return status code. The BCM_module_state() control interface returns a state of BCM_MODULE_STATE_NOT_READY. The BCM_module_selftest() API runs self-tests on demand after the module has loaded. The on-demand self-tests are the software integrity test, the cryptographic algorithm self-tests, and the key generation pair-wise consistency tests. The module can also be reloaded to execute the self-tests on-demand. If a self-test that is run by BCM_module_selftest() fails, the module enters the self-test error state. For all self-test failures, the library notifies the user through the return status codes for the API.

The following table lists the pre-operational self-tests: Table 19 Pre-operational Self-tests

If all POST pass, the cryptographic services of the module are enabled and the module can be used. The BCM_module_state() control interface returns a state of BCM_MODULE_STATE_READY.

If the pre-operational software integrity test fails, the module enters the self-test error state. The repetition count test (RCT) and adaptive proportion test (APT) are defined in SP 800-90B. The pre-operational software integrity tests used are described in detail in Approved Integrity Techniques.

The following table lists the conditional self-tests: FaultDetection FaultDetection Table 20 Conditional Self-tests

Table 20 Conditional Self-tests (continued)

Table 20 Conditional Self-tests (continued)

FaultDetection Table 20 Conditional Self-tests (continued)

For the KATs, the module includes a set of fixed inputs for each algorithm along with corresponding pre-calculated expected outputs. The cryptographic algorithm is run with the fixed inputs and the algorithm outputs are compared with the expected outputs. If there is any difference the algorithm self-test fails, the CAST fail and the module enters the self-test error state. If a pair-wise consistency test fails, the key-generation operation fails and returns an error indicator through a return status code. The error is cleared by reattempting the If the Entropy source self-tests fail then the entropy collection operation returns an error indicator through a return status code. The error cannot be cleared from the NDRBG object. A new NDRBG object must be created to collect entropy.

The following table lists the error states: Table 21 Error States module can be re-enabled only by reloading the module.

For the PowerMaxOS platform, the module is linked into the application at compile time, and installed as part of the target application. For Linux and Windows platforms, the module must be installed with the target application. The Crypto Officer should follow a secure installation procedure to install the module. For all target platforms the installation process should check the integrity of the installed files by checking the hash value of the original files and installed files. A minimum privileged user on the operating system should be created solely to execute the application. This user should not share any other roles in the operating system. The installation process should set the minimum execution permission to the installed files for the user. If the module is dynamically loaded into the application, the installation process should ensure that the path to the module cannot be modified by other OS users.

There are no specific initialization steps required for the module.

The module is started by initiating the application that statically or dynamically linked it. The module uses operating system services to perform the module startup when the application is started. This module startup includes running the pre-operational software integrity test. These ensure that the application has made no modification to the module as part of its development or installation. Before cryptographic services are made available by the module, the pre-operational software integrity test must complete successfully. For more information about the pre-operational software integrity test, see Software/Firmware Security.

Maintenance applies only to the application maintainers. If modifications are made to the application, such as a new version or patch to the application, the module’s pre-operational software integrity test ensures that the module contained within, or dynamically loaded, is unaltered. Application writers should not attempt to modify the module library or object file as the module will refuse to load or perform cryptographic operations.

For details of the administrative functions, security parameters, and logical interfaces available to the Crypto Officer, refer to Crypto Officer Role. The following sections detail the requirements for algorithm use in the Approved Mode of Operation.

General Crypto Officer Guidance Users should take care to zeroize SSPs when they are no longer needed. BSAFE Crypto Module objects should be deleted when no longer needed, which will zeroize sensitive data managed by the module. User variables containing SSP data on the stack or heap should be zeroized after use or before going out of scope.

Using the CTR DRBG with AES-256 is recommended as it is fast and because it provides

256 bits of cryptographic strength, it is suitable for all purposes. This is the module default

When using an approved DRBG to generate keys, the security strength of the DRBG must be at least as great as the security strength of the key being generated. For details about the comparable security strengths of symmetric block ciphers and asymmetric key algorithms refer to Table 2 of SP 800-57 Part 1 Rev. 5. The default DRBG provides a security strength as great as that of any supported keys.

GCM Mode Ciphers An AES-GCM IV is constructed in compliance with either IG C.H scenario 1a or IG C.H scenario 2, depending on how the module is used. When using GCM feedback mode for symmetric encryption, the authentication tag length and authenticated data length may be specified as input parameters, but the IV must not be specified. It must be generated internally. IV generation operates in one of two ways:

• IG C.H scenario 2: In regular use the generated IV is fully random, generated by the module’s approved DRBG, with a default length of 96 bits. No special considerations are required provided the system has sufficient entropy.
• IG C.H scenario 1a: When used for TLSv1.2 protocol GCM cipher suites, as allowed by SP 800-52 Rev. 2 and defined in RFC 5288, the four-byte salt derived from the TLS handshake process must be input to the module to be used to form part of the IV. The salt value must be passed as iv in the call to BCM_cipher_new_AEAD() and the BCM_FLAG_CIPHER_PARTIAL_IV flag must be provided. The salt is used as the first four bytes of the IV.

The remaining eight bytes of the IV, referred to as nonce_explicit in RFC 5288, are generated deterministically by the module using a 64-bit global counter within the module. The module uses the current system time to initialize the counter when it is first used. The system time must be valid to prevent repetition of IVs. During a TLS connection, if the nonce_explicit part of the IV exhausts the maximum number of possible values for a given session key, a new handshake must be performed to establish a new key. XTS Mode Ciphers AES in XTS mode is approved only for hardware storage applications. The data encryption key and tweak key components of the double-length XTS key must be checked to ensure they are different. This check is performed automatically by the module. Triple DES Triple DES is not available as an approved algorithm in the Approved Mode of Operation. When triple DES is used in Non-Approved mode, the amount of data that can be encrypted is restricted to 216 64-bit blocks.

In the following, Protect refers to cryptographically protecting data for later use, for example, signing, encrypting or wrapping. Process refers to processing previously protected data, for example, verifying, decrypting or unwrapping. Table 22 Supported Elliptic Curves Table 23 Supported DSA key pair sizes Table 24 Supported Diffie-Hellman named domain parameters

Table 25 Approved RSA modulus length for digital signatures

Keys used for digital signature generation and verification shall not be used for any other purpose. The module generates or loads keys with a particular purpose that is one of signing, encryption or key exchange. The same purpose must always be used for a given key when exported and loaded into the module again. The length of an RSA key pair for digital signature generation must be greater than or equal to 2048 bits. For digital signature verification, the length must be greater than or equal to 2048 bits, however 1024 bits is allowed for legacy-use only. RSA keys must pass validation before use. Keys generated by the module will pass validation. For RSA PKCS #1 PSS, the size relationship between the hash function output block length (hLen) and the length of the salt (sLen) shall be 0 <= slen <= hLen. Elliptic curve key pairs for digital signature generation must have a strength of 112 bits or stronger. Table 22, Supported Elliptic Curves, lists these in the Protect and Process row. For verification of digital signatures, use curves from the Process only row which includes legacy-use keys of less than 112 bits of strength. For DSA signatures, only key pairs generated with parameters in the Protect and Process row of Table 23, Supported DSA key pair sizes are approved for signature generation. Additionally, parameters from which the keys are derived or the keys must have been validated before use. An approved DRBG must be used for digital signature generation, and this is provided by the module. The SHA-1 digest is disallowed for the generation of digital signatures. The digest must be an approved algorithm. Verification of signatures with a SHA-1 digest is allowed for legacy use. The security strength of both the key and the digest functions shall be chosen to meet or exceed the required security strength for the digital signature. The security strength of the digest function should be stronger or the same as that of the key.

HMACs The key length for an HMAC generation or verification must be between 112 and 256 bits, inclusive. For HMAC verification, a key length greater than or equal to 80 and less than 112 is allowed for legacy-use.

The module does not implement the TLS or SSH protocol, and CAVP and CMVP have not tested TLS PRF or SSH KDF when used as part of such protocols. HMAC-Based Extract-and-Expand Key Derivation Function An approved HMAC must be used for extract and expand operations. A particular key-derivation key must only be used for a single key-expansion step. For more information see SP 800-56C Rev.

1. The derived key must be used only as a secret key. The derived key shall not be used as a key stream for a stream cipher. When selecting an HMAC hash, the digest size must be equal to or greater than the desired security strength of the derived key. The pseudo-random key input to the expansion and the keying material output from the expansion must have lengths that are equal to or greater than the desired security strength of the derived key. One-Step Key Derivation Function An approved hash function must be used to derive key materials. The hash function must meet the security strength required by the cryptographic function for which the keying material is being generated. The security strengths of approved hash functions used in KDFs can be found in SP 800-57 Part 1 Rev.
2. When selecting a hash algorithm, the digest size must be equal to or greater than the desired security strength of the derived key. The derived key must be used only as a secret key. The derived key shall not be used as a key stream for a stream cipher. The secret data input into this KDF must have a length equal to or greater than the desired security strength of the derived key. The maximum length of a derived secret key is (232 - 1) * b, where b is the digest size of the message digest function in bytes. Password-based Key Derivation Keys generated using PBKDF2 shall only be used in data storage applications. The minimum password length is 14 characters, which has a strength of approximately

112 bits, assuming a randomly selected password using the extended ASCII printable

character set is used.

For random passwords, that is, a string of characters from a given set of characters in which each character is equally likely to be selected, the strength of the password is given by S = L *(log N / log 2) where: • N is the number of possible characters. For example: for the ASCII printable character set N = 95 for the extended ASCII printable character set N = 218. • L is the number of characters. A password of strength S can be guessed at random with the probability of 1 in 2S. The minimum length of the randomly-generated portion of the salt is 16 bytes. The iteration count is as large as possible, with a minimum of 10,000 iterations recommended. The derived key size can range from 1 byte to a maximum of (2 32 - 1) * b, where b is the digest size of the message digest function in bytes. Derived keys can be used as specified in SP 800-132, Section 5.4, option 1a. Secure Shell Key Derivation As defined in SP 800-135 Rev. 1, SSH-KDF can be used in the Approved Mode of Operation when it is used with an Approved hash function. The hash function must meet the security strength required by the cryptographic function for which the keying material is being generated. The security strengths of approved hash functions used in KDFs can be found in SP 800-57 Part 1 Rev.

5. The operation must be performed in the context of the SSH protocol. TLS PRF Key Derivation Function TLS v1.2 PRF KDF is allowed only when the following conditions are satisfied: • The KDF is performed in the context of the TLS protocol. • HMAC is as specified in FIPS 198-1. • P_HASH uses either SHA2-256, SHA2-384, or SHA2-512. For more information, see SP 800-135 Rev.
6. X9.63 Key Derivation Function As defined in SP 800-135 Rev. 1, X9.63 KDF can be used in the Approved Mode of Operation when it is used with an Approved hash function. The hash function must meet the security strength required by the cryptographic function for which the keying material is being generated. The security strengths of approved hash functions used in KDFs can be found in SP 800-57 Part 1 Rev.
7. When selecting a hash algorithm, the digest size must be equal to or greater than the desired security strength of the derived key.

The derived key must be used only as a secret key. The derived key shall not be used as a key stream for a stream cipher. The length of the derived key shall be less than (232 - 1) x b, where b is the digest size of the message digest function in bytes. The operation must be performed in the context of ANSI X9.63-2001 key agreement scheme.

Key pairs used in key agreement must not also be used to generate a digital signature. The shared secret must be:

• Used only as input to an approved KDF
• Treated as a CSP and destroyed after use. That is, after the secret has been used, the memory holding the secret must be zeroized. For all schemes:
• Both parties must use validated parameters to generate a key pair. BCM_param_validate() provides the validation service.
• Key pairs generated with an approved method such as provided by the module are assumed to be valid.
• A nonce used in a key agreement scheme must be a random value that is generated by the module's approved DRBG. The DRBG that generates a nonce for a scheme must have a security strength greater than or equal to the targeted security strength of the scheme.
• A nonce must have a bit length that is greater than or equal to the targeted security strength of the scheme. Where possible the bit length of a nonce should be at least twice the targeted security strength of the scheme. For schemes that use ephemeral keys:
• The key pair is used only for a single transaction.
• The key pair is destroyed after use. For schemes that use static key pairs:
• A public identifier must be authoritatively associated with the key pair.
• A public identifier must be associated with the public key to allow any peer to recognize the key pair.
• The receiving party must have assurance of the peer's ownership of the private key.
• It is noted that the scheme doesn't provide forward secrecy. For schemes that use key confirmation:
• Both parties must use a common approved MAC to generate confirmation values.
• The MAC key will be generated as one of the key material elements.

• The input values for MAC tag generation must be formatted as per SP 800-56A Rev. 3.
• The MAC key must be zeroized after use.
• If confirmation fails then destroy all calculated values. All key material is destroyed to prevent it from being used for any other purpose. ECC based DH key agreement schemes Curves with at least 112 bits of security strength are allowed. Table 22, Supported Elliptic Curves, lists these in the Protect and Process row. FFC based DH key agreement schemes Keys used for DH key agreement should be generated from the Protect and Process row of Table 24, Supported Diffie-Hellman named domain parameters. Keys from generated parameters should only be used for backwards compatibility with legacy applications, and then must have passed parameter validation.

Key Wrapping using AES The key establishment methodology provides between 128 and 256 bits (inclusive) of encryption strength. The security strength of the key encryption key must be greater than or equal to the security strength of the key being wrapped.

Asymmetric keys and parameters are validated as they enter the module for use in processing existing data. Before the keys are used to protect data, they must be validated. The module provides services for the validation of RSA, DSA, DH and ECC keys and parameters. Named EC and DH parameters are treated as valid. Only named EC parameters are supported. Key Parameter Generation The generation of DSA parameters is in accordance with the FIPS 186-4 standard for the generation of probable primes.

RSA, EC and DSA key operations implement blinding, a reversible way of modifying the input data, to make the operation immune to timing attacks. Blinding has no effect on the algorithm other than to mitigate attacks on the algorithm. This mitigation is enabled by default. For optimum security, it should not be disabled.

If necessary it can be disabled with BCM_FLAG_KEY_DISABLE_BLINDING. For more information, see Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems. RSA signing operations implement a verification step after private key operations. This verification step is in place to prevent potential faults in optimized Chinese Remainder Theorem (CRT) implementations. It has no effect on the signature algorithm. This mitigation is enabled by default. For optimum security, it should not be disabled. If necessary it can be disabled with BCM_FLAG_KEY_DISABLE_SIGNATURE_CHECK. For more information, see Breaking public key cryptosystems on tamper resistant devices in the presence of transient faults: Bao, Deng, Han, Jeng and On the Importance of Eliminating Errors in Cryptographic Computations. RSA PKCS #1 v1.5 encryption padding operations are implemented in constant time in order to make the operation immune to timing attacks. For this mitigation, constant time padding is built-in and cannot be disabled. For more information, see Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1.

The following table lists the acronyms and terms used with the module and their definitions: Table 26 Acronyms and Definitions

Table 26 Acronyms and Definitions (continued)

Table 26 Acronyms and Definitions (continued) Australia Pty. Ltd. or its subsidiaries. Other trademarks may be trademarks of their respective owners.

Table 26 Acronyms and Definitions (continued)