Dell BSAFE™ Crypto Module

Certificate

Approved Algorithms (28)

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

flowchart LR
  %% Deterministic review-risk graph for Dell BSAFE™ Crypto Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status Output<br/>self-test<br/>Show Status</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>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."]
    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?"]
    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"]
    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
  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,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Dell BSAFE™ Crypto Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Status Output<br/>self-test<br/>Show Status</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>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,C6 clueLow;

Security Policy, page by page

18.12.24 Dell Australia Pty Limited, BSAFE Product Team Dell BSAFE™ Crypto Module Module Version 2.0.0.0 FIPS 140-3 Security Policy Document Version 1.8

version 2.0.0.0 (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 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, please 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 Dell BSAFE™ Crypto Module, version 2.0.0.0, FIPS 140-3 validated Cryptographic Module for Overall Security Level 1. The BSAFE Crypto Module is also referred to as:

• The Cryptographic 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 Security Levels The 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 as a static library in Executable and Linkable Format (ELF) format, built for the Intel® x86_64 (64-bit) architecture. It follows the standard x86_64 calling conventions and provides a documented set of functions that can be called from user software. It is intended to be linked directly into the user software system. The following diagram illustrates the cryptographic module boundary and logical interfaces: Figure 1 Cryptographic boundary

The module is identified as Dell BSAFE™ Crypto Module, version 2.0.0.0, and consists of a single object file, fipsobj.o, in the static library libdellbcm.a. 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 CMVP page using the module name and version reported.

Dell 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 with an object file 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 linked object file within the final application. The underlying logical interface to the module is the API, documented in the Dell BSAFE™ Crypto Module Developers Guide. The module accepts 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 returns and error 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

Dell BSAFE affirms compliance for the following operational environment: Table 3 Vendor Affirmed Operational Environments 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 Dell BSAFE™ Crypto Module Approved algorithms, with the appropriate standards and CAVP validation certificate numbers: Table 4 Approved Algorithms

Table 4 Approved Algorithms (continued) 1Initialization Vector (IV). 2AES 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.

RSA 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). Password-based key derivation function 2 (PBKDF2). As defined in the NIST Special Publication 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. 6Deterministic Random Number Generator (DRBG). 7Hash-based Message Authentication Code (MAC). 8Vendor-affirmed algorithms. The following table lists the Dell BSAFE™ Crypto Module Non-Approved algorithms, not allowed in the Approved Mode of Operation: Table 5 Non-Approved Algorithms Not Allowed in the Approved Mode of Operation Triple 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.

Dell 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 the cryptographic algorithms listed in Table 4, Approved Algorithms. Non-Approved algorithms not allowed in the approved mode of operation are not available.
• 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 are available to the Crypto Officer. Note: Critical Security Parameters must not be shared between modes. For example, a key generated in the Approved mode of operation must not be exported and then imported to an application running 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_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.

An application using BSAFE Crypto Module is linked to the module file, libdellbcm.a, which is then loaded and initialized as part of the application that linked it. The module initializes itself automatically when loaded, and runs the POST automatically regardless of the mode of operation at startup. If the self-tests complete successfully, the cryptographic services of the module can be used. 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: Table 6 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 or Key. A return status code indicates the service status. For information about individual functions that implement each service, see the Dell BSAFE™ Crypto Module 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: Table 8 Approved Services

Table 8 Approved Services The 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 1.

The following is a list of non-approved services provided by the module: 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.

The module is an object file. When the module object 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-Tests (CASTs) are run prior to the pre-operational software integrity test to ensure 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() API for on-demand integrity testing.

The module is built as a single ELF object file with an embedded FIPS 140-3 integrity signature. The ELF object file 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 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 only be accessed or modified 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 Cryptographic Module Validation Program (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. 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:
2. BCM_CIPHER cryptographic objects with a call to BCM_cipher_delete().
3. BCM_MAC cryptographic objects with a call to BCM_mac_delete().
4. BCM_DIGEST cryptographic objects with a call to BCM_digest_delete().
5. BCM_KEY objects with a call to BCM_key_delete().
6. BCM_CTX objects with a call to BCM_ctx_delete().
7. Delete the default context created at startup. To do this, unload the module or call BCM_module_unload(). Table 13 SSPs

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

BSAFE Crypto Module 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. If the bits of entropy are not available on a GET call then the Entropy NDRBG generates an error status code that is returned to the application by the random number generation service.

The module addresses the requirements of FIPS 140-3. Transitioning the use of cryptographic algorithms and key lengths (NIST SP 800-131A Rev. 2) provides more specific guidance in regards to transition periods or 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 (NIST SP 800-57 Part 1 Rev. 5) specifies security strengths that are acceptable for protecting data going forward. Application writers should consider these acceptable use dates with respect to the expected deployment lifetime of the application and the life of the data being protected. This life depends on the type of key and use, but are from 1-3 years. Refer to NIST SP 800-57, Part 1 for more explanation.. 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 (NIST SP 800-56B Rev. 2)
• Recommendation for Key Management Part 1 (NIST SP 800-57 Part 1 Rev. 5)
• Recommendation for Applications Using Approved Hash Algorithms (NIST SP 800-107 Rev. 1). Table 18 Correspondence between Security Strength, Algorithms and Key Size

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_selftest() status 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 and the cryptographic algorithm self-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() status 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: Table 20 Conditional Self-tests

Table 20 Conditional Self-tests

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.

The module is linked into the application at compile time, and installed as part of the target application. There is no physical installation, operation or maintenance of the module.

There are no specific initialization steps required for the module.

The module is started by starting the application that includes 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 integrity test. Before cryptographic services are made available by the module, the pre-operational integrity tests must complete successfully. These ensure that the application has made no modification to the module as part of its development or installation. For more information about the pre-operational 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 integrity test ensures that the module contained within is unaltered. Application writers should not attempt to modify the module ELF 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 provides 256 bits of cryptographic strength, so it is suitable for all purposes. This is the module default DRBG.

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 module’s default DRBG provides a security strength as great as that of any supported keys.

GCM Mode Ciphers 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. For compliance with IG C.H scenario 2 it must be generated internally. 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. 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, e.g. signing, encrypting or wrapping. Process refers to processing previously protected data, e.g. verifying, decrypting or unwrapping. Table 22 Approved RSA modulus length for digital signatures

Table 22 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 either signing or encryption. 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. 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 length of the secret key greater than or equal to 80 and less than 112 is allowed for legacy-use.

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.

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 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 keys.

RSA key operations implement blinding, a reversible way of modifying the input data, so as 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 used with the module and their definitions: Table 23 Acronyms and Definitions

Table 23 Acronyms and Definitions

Table 23 Acronyms and Definitions of Dell Australia Pty. Ltd. or its subsidiaries. Other trademarks may be trademarks of their respective owners.