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: Security ISO/IEC 24759 Section 6 FIPS 140-3 Section Title Level

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: PAA / # Operating System Hardware Platform Processor Acceleration

1 Dell PowerMaxOS 10 PowerMax storage Intel Xeon® Gold 5218 Yes

2 Dell PowerMaxOS 10 PowerMax storage Intel Xeon Gold 5218 No

3 Dell PowerMaxOS 10 PowerMax storage Intel Xeon Gold 6240L Yes

4 Dell PowerMaxOS 10 PowerMax storage Intel Xeon Gold 6240L No

5 Dell PowerMaxOS 10 PowerMax storage Intel Xeon Gold 6254 Yes

6 Dell PowerMaxOS 10 PowerMax storage Intel Xeon Gold 6254 No

7 Dell PowerMaxOS 10 PowerMax storage Intel Xeon Platinum 8280L Yes

8 Dell PowerMaxOS 10 PowerMax storage Intel Xeon Platinum 8280L No

array compute node Table 2 Tested Operational Environments

Dell BSAFE affirms compliance for the following operational environment: # Operating System Hardware Platform

1 SUSE® Linux Enterprise Server 15 SP2 Intel x86_64 (64-bit)

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: Description / Key CAVP Algorithm and Mode/Method Size(s) / Key Use / Function Cert Standard Strength(s) A1204 AES ECB, CBC and CTR 128, 192, and 256 Symmetric SP 900-38A bit key sizes encryption A1204 AES CCM 128, 192, and 256 Symmetric SP 800-38C bit key sizes encryption A1204 AES GCM with automatic 128, 192, and 256 Symmetric SP 800-38D IV1 generation bit key sizes encryption A1204 AES XTS2 128 and 256 bit key Symmetric SP 800-38E sizes encryption A1204 RSA Key generation. 2048 to 4096-bit Key generation, FIPS 186-4 Signature generation key size signature and signature generation, and verification with signature SHA2-224, verification SHA2-256, SHA2-384, SHA2-512, SHA2-512/224, SHA2-512/256. Signature verification with SHA-1. A1204 CVL RSASP13 component 2048-bit key size Signature FIPS 186-4 generation A1204 CVL RSADP4 component 2048-bit key size Asymmetric SP 800-56B Rev. 2 encryption Table 4 Approved Algorithms

Description / Key CAVP Algorithm and Mode/Method Size(s) / Key Use / Function Cert Standard Strength(s) A1204 KDF PBKDF25 112-256 bits Key derivation SP 800-132 strength A1204 KTS AES Key Wrap, and 128, 192, and 256 Key wrapping SP 800-38F Key Wrap with bit key sizes Padding. A1204 DRBG6 AES-CTR 128, 192, and 256 Random bit SP 800-90A bit strengths generation A1204 DRBG HMAC SHA2-512 256 bits strength Random bit SP 800-90A generation A1204 SHS SHA-1, SHA2-224, 112-256 bits Message digesting FIPS 180-4 SHA2-256, strength SHA2-384, SHA2-512, SHA2-512/224, SHA2-512/256 A1204 HMAC7 HMAC with SHA-1, 112-256 bits MAC generation FIPS 198-1 SHA2-256, strength SHA2-384, SHA2-512 A1204 KAS-IFC-SSC / Schemes: KAS1 2048 to 8192-bit Shared secret SP 800-56B Rev.2 Key Generation key size generation methods: An RSA key pair with a private key in the basic format, with a random public exponent. VA8 CKG of symmetric Direct output of 128-256 bits Key Generation keys/ approved DRBG used strength to generate 128, 192, SP 800-133 Rev. 2 or 256 bit AES keys. FIPS 140-3 Implementation Guidance, IG D.H. VA CKG of asymmetric Direct output of 128-256 bits Key Generation keys/ approved DRBG used strength to generate prime SP 800-133 Rev. 2 number seeds and private key values. FIPS 140-3 Implementation Guidance, IG D.H. 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: Algorithm / Function Use / Function MD5 Message Digesting DES31 (three key) in ECB and CBC modes Symmetric encryption 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: Physical Logical Data that passes over port/interface Port Interface N/A Data input Service inputs N/A Data output Service outputs N/A Control input Configuration parameters for the API BCM_module_configure() which sets the mode of operation. N/A Status output Mode of operation indicator, from either the BCM_ctx_is_fips() or BCM_key_is_fips() APIs. The state of the module from the API BCM_module_state(). For other API status, refer to the Outputs column of Table 7, Roles, Service Commands, Input and Output. 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. Role Service Input Output CO AES Encryption Plaintext Ciphertext, Status CO AES Decryption Ciphertext Plaintext, Status CO Message Digest Message Digest, Status CO MAC Generation Secret, Message MAC, Status CO MAC Verification Secret, Message, MAC Verify Status, Status CO DRBG Initialization - CO Random Number - Random Bytes, Status Generation CO Key Generation - Status CO Key Import Key text Status CO Key Export - Key text, Status CO Key Deletion - Table 7 Roles, Service Commands, Input and Output

Role Service Input Output CO Key Derivation Secret Key text, Status CO Key Wrap - Wrapped key text, Status CO Key Unwrap Wrapped key text Status CO Key Encapsulation Encapsulated key text Status (decrypt) CO Digital Signature Message Digest Signature, Status Generation CO Digital Signature Message Digest, Verify Status, Status Verification Signature CO Show Module - Module Version, Status Version Information CO Show Status - Module Status CO Self-test - Status Table 7 Roles, Service Commands, Input and Output

The following is a list of approved services provided by the module: Access Approved Keys and/or rights to Service Description Security Roles Indicator 1 SSPs Keys and/or Functions SSPs AES Encryption Encrypt with AES AES keys CO E K symmetric cipher AES Decryption Decrypt with AES AES keys CO E K symmetric cipher Message Digest Digest a SHS - CO - C message MAC Generation Generate a HMAC MAC secret CO W, E, Z C Message Authentication Code MAC Verification Verify a Message HMAC MAC secret CO W, E, Z C Authentication Code Table 8 Approved Services

Access Approved Keys and/or rights to Service Description Security Roles Indicator 1 SSPs Keys and/or Functions SSPs DRBG Initialization Prepare for DRBG Entropy State, CO G C random number DRBG entropy or key generation input, DRBG seed, CTR DRBG key value, CTR DRBG V value, HMAC DRBG key value, HMAC DRBG V value Random Number Generate a DRBG DRBG entropy CO E C Generation random number input, DRBG seed, CTR DRBG key value, CTR DRBG V value, HMAC DRBG key value, HMAC DRBG V value Key Generation Generate a CKG AES keys, CO G P symmetric or RSA Key RSA keys asymmetric key generation Key Import Import a key into - AES keys, CO W C the module RSA keys Key Export Export a key - AES keys, CO R K from the module RSA keys Key Deletion Delete a key - AES keys, CO Z K from the module RSA keys Key Derivation Derive key text KDF (PBKDF2) KDF secret CO W, E, Z C given input Derived key text R, Z secret Key Wrap Encrypt an AES KTS AES key CO E K key with an AES (wrapping key) key encryption R AES key key (wrapped key) Key Unwrap Decrypt an AES KTS AES key CO E K key with an AES (wrapping key) key encryption W AES key key (unwrapped key) Table 8 Approved Services

Access Approved Keys and/or rights to Service Description Security Roles Indicator 1 SSPs Keys and/or Functions SSPs Key Encapsulation Decrypt an AES CVL (RSADP) RSA key CO E K (decrypt) or RSA key with (key encryption an RSA key key) encryption key AES key or RSA W key (decrypted key) Digital Signature Sign a message RSA RSA keys CO E K Generation (signature (private key) generation), CVL (RSASP1) Digital Signature Verify the RSA RSA keys CO E K Verification signature for a (signature (public key) message verification) Key Agreement Establish a KAS-IFC-SSC RSA keys CO W, Z K shared secret (peer public key) RSA keys (peer public key, E private key) Show Module Provide module - - CO - Version Information version to user Show Status Provide module - - CO - status to user Self-test Run module HMAC Integrity test key CO - self-tests on-demand 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: Service Description Algorithm Accessed Role Indicator1 Message Digest Digest a MD5 CO C message Symmetric Encrypt with DES3 with ECB and CO K Encryption symmetric cipher CBC modes Symmetric Decrypt with DES3 with ECB and CO K Decryption symmetric cipher CBC modes 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. Name Description Type VM Memory in the Operational Volatile Environment of the module. Table 10 Storage Areas Protection of the SSPs in volatile memory is provided by the operating environment which isolates the memory of separate processes Distribution Name From To Format Type Entry Type Type App Write Operator VM Plaintext Manual Electronic Application in TOEPP1 App Read VM Operator Plaintext Manual Electronic Application in TOEPP 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. Operator Method Description Rationale Initiated Capability Immediate Temporary SSPs are zeroized Intermediate values are N/A immediately after use zeroised at the end of a calculation Implicit SSPs are zeroized when the SSPs are zeroized when the N/A cryptographic object is deleted BCM_CTX object is deleted by the module Explict SSPs are zeroized when the SSPs are zeroized when the API call to associated key or application no longer needs delete object cryptographic object is deleted them by the application 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(). Key / SSP Name / Security Function Import / Establis Strength Generation Storage Zeroisation Use & related keys Type and Cert. Number Export hment RSA keys 112 - RSA CKG SP 800-133 Rev.
8. App N/A VM Explicit Signature (public key / PSP; 150 KAS-IFC-SSC FIPS 186-4 method Write, generation and private key / CSP) bits (A1204) App verification. Read Key agreement. AES keys 128, AES, KTS CKG, SP 800-133 Rev.
9. App N/A VM Explicit Symmetric (CSP) 192, (A1204) Direct output of approved Write, encryption. and DRBG. App Key wrapping.

bits MAC secret 128 - HMAC N/A App N/A VM Immediate MAC generation (CSP) 256 (A1204) (Application input) Write and verification bits KDF secret 112 - KDF (PBKDF2) N/A App N/A VM Immediate Key derivation (CSP) 256 (A1204) (Application input) Write bits Derived key text 112 - KDF (PBKDF2) PBKDF2 App N/A VM Immediate Key derivation (CSP) 256 (A1204) Read bits CTR DRBG key 128, DRBG, CKG Obtained from SP N/A N/A VM Implicit Random bit value 192, (A1204) 800-90B compliant generation (CSP) and entropy source bits Table 13 SSPs

Key / SSP Name Security Function Import / Establis Strength Generation Storage Zeroisation Use & related keys (continued)/ Type and Cert. Number Export hment CTR DRBG V 128 DRBG, CKG Obtained from SP N/A N/A VM Implicit Random bit value bits (A1204) 800-90B compliant generation (CSP) entropy source HMAC DRBG key 256 DRBG, CKG Obtained from SP N/A N/A VM Implicit Random bit value bits (A1204) 800-90B compliant generation (CSP) entropy source HMAC DRBG V 256 DRBG, CKG Obtained from SP N/A N/A VM Implicit Random bit value bits (A1204) 800-90B compliant generation (CSP) entropy source DRBG entropy 128, DRBG Obtained from SP N/A N/A VM Implicit Random bit input 192, (A1204) 800-90B compliant generation (CSP) and entropy source bits DRBG seed 128, DRBG Obtained from SP N/A N/A VM Implicit Random bit (CSP) 192, (A1204) 800-90B compliant generation and entropy source bits Entropy state 256 DRBG Internal state of SP N/A N/A VM Implicit Random bit (CSP) bits (A1204) 800-90B compliant generation entropy source. Obtained from noise source. Integrity test key 144 HMAC Built-in constant value. N/A N/A Built N/A Self-test (not considered an bits (A1204) into SSP) module image Table 13 SSPs

BSAFE Crypto Module provides the following approved DRBGs for use in both Approved and Non-Approved modes: DRBG Entropy Obtained (bits) CTR DRBG with AES-128 128 CTR DRBG with AES-192 192 CTR DRBG with AES-2561 256 HMAC DRBG with SHA2-512 256 Table 14 Approved Random Bit Generators 1CTR DRBG with AES-256 is the default DRBG. Use Details RSA key-pair generation Prime generation, and Miller-Rabin prime number testing1 Blinding of random values RSA key validation Prime recovery testing2 Symmetric key generation Direct generation of symmetric keys Initialization vector generation Direct generation of IVs for symmetric encryption RSA PKCS #1 PSS signing Generation of random value for message encoding 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. Entropy Minimum Number of Details Sources Bits of Entropy Execution 256 Instantiation of HMAC DRBG time jitter Execution 128 Instantiation of CTR DRBG with AES-128 time jitter Execution 192 Instantiation of CTR DRBG with AES-192 time jitter Execution 256 Instantiation of CTR DRBG with AES-256 time jitter Execution DRBG instantiation Application calls BCM_random_seed() time jitter bits Execution 64 Application calls time jitter BCM_secure_random_bytes() 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.. Strength Last Date Acceptable < 112 Already disallowed

>= 128 Acceptable to 2031 and beyond 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). Strength Symmetric RSA Hash MAC and KDF < 80 1024 SHA-1

256 AES-256 15360 SHA2-512 SHA2-256, SHA2-512/256, SHA2-384,

SHA2-512 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: Algorithm Test Properties Type Details HMAC HMAC-SHA2-256 KAT Pre-operational signature:32 software integrity bytes test executes HMAC secret:18 automatically bytes when the module is loaded into memory Entropy source 1024 noise RCT and APT Pre-operational samples critical functions test runs when a BCM_CTX objects creates an entropy source 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: Algorithm Test Type Details Condition AES 128, 192 and KAT Encrypt and Module startup 256-bit AES decrypt self-tests keys KTS 128, 192 and KAT Wrap and unwrap Module startup 256-bit AES self-tests keys DRBG 128, 192 and KAT Random bit Module startup (AES-CTR) 256-bit strength generation self-tests DRBG 128, 192 and Fault- SP 800-90A Rev. 1 Module startup (AES-CTR) 256-bit strength Detection health test. Test Instantiate, generate, reseed, uninstantiate tests DRBG 256-bit strength KAT Random bit Module startup (HMAC generation self-test SHA2-512) DRBG 256-bit strength Fault- SP 800-90A Rev. 1 Module startup (HMAC Detection health test. SHA2-512) Test Instantiate, generate, reseed, uninstantiate tests HMAC HMAC with KAT MAC generation Module startup (SHA-1) SHA-1 self-test HMAC HMAC with KAT MAC generation Module startup (SHA2) SHA2-256, self-test SHA2-384, SHA2-512 KDF PBKDF2 with KAT Key derivation Module startup SHA2-256, self-test

RSA 2048-bit RSA KAT RSA signature and Module startup key verification self-tests Table 20 Conditional Self-tests

Algorithm Test Type Details Condition RSA 2048-bit RSA KAT RSA encryption Module startup key and decryption self-tests SHS SHA-1 KAT Message digest Module startup (SHA-1) generation self-test SHS SHA2-224, KAT Message digest Module startup (SHA2) SHA2-256, generation self-test SHA2-384, SHA2-512, SHA2-512/224, SHA2-512/256 RSA 2048-bit to PCT RSA sign and Generation of (key 4096-bit signing verify RSA signature generation) keys key pair RSA 2048-bit to PCT RSA encrypt and Generation of (key 4096-bit decrypt RSA encryption generation) encryption keys key pair Entropy 1 bit of entropy Fault- Entropy continuous Creation of new source per byte Detection RCT and APT DRBG instance Test testing, as defined Reseed of DRBG in SP 800-90B instance Generation of secure random bytes 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 key-generation operation. 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: State Name Description Indicator Self-test Error Module pre-operational Cryptographic services return integrity test failure BCM_ERROR_FIPS_INTEGRITY_FAILURE error code. The BCM_module_state() status interface returns a state of BCM_MODULE_STATE_INTEGRITY_FAILED. Self-test Error CAST failure Cryptographic services return BCM_ERROR_FIPS_SELFTEST_FAILURE error code. The BCM_module_state() status interface returns a state of BCM_MODULE_STATE_SELFTEST_FAILED. Self-test Error On-demand integrity test Cryptographic services return failure BCM_ERROR_FIPS_INTEGRITY_FAILURE error code. The BCM_module_state() status interface returns a state of BCM_MODULE_STATE_INTEGRITY_FAILED. Self-test Error On-demand CAST failure Cryptographic services return BCM_ERROR_FIPS_SELFTEST_FAILURE error code. The BCM_module_state() status interface returns a state of BCM_MODULE_STATE_SELFTEST_FAILED. Table 21 Error States When the module enters the self-test error state then cryptographic services for the 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. Purpose RSA modulus length Note Protect and Process 2048, 3072, 4096 Sizes approved in FIPS 186-4 and FIPS 140-3 IG. (CAVP validated) Table 22 Approved RSA modulus length for digital signatures

Purpose RSA modulus length Note Process only 1024 May be used for verification only. 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: Term Definition AES Advanced Encryption Standard. A fast symmetric key algorithm with a 128-bit block, and keys of lengths 128, 192, and 256 bits. AES replaces DES as the US symmetric encryption standard. API Application Programming Interface. Attack An attempt, either a successful or unsuccessful, to break part or all of a cryptosystem. Attack types include an algebraic attack, birthday attack, brute force attack, chosen ciphertext attack, chosen plaintext attack, differential cryptanalysis, known plaintext attack, linear cryptanalysis, and middle person attack. CAST Cryptographic Algorithm Self-Tests. A test of all cryptographic functions of an approved cryptographic algorithm that must be performed prior to the first operational use of the cryptographic algorithm. A CAST may be a KAT, a comparison test or a fault-detection test. CBC Cipher Block Chaining. A mode of encryption in which each ciphertext depends upon all previous ciphertexts. Changing the IV alters the ciphertext produced by successive encryptions of an identical plaintext. CCM Counter with Cipher block chaining Message authentication code. A mode of encryption combining the Counter mode of encryption with Cipher Block Chaining Message Authentication Code (CBC-MAC) for authentication. CMVP Cryptographic Module Validation Program. CSP Critical Security Parameters are security related information, such as keys or passwords, whose disclosure or modification can compromise security. CTR Counter Mode. A mode of encryption which turns a block cipher into a stream cipher. It generates the next keystream block by encrypting successive values of a counter. CTR DRBG Counter mode Deterministic Random Bit Generator. Decryption The conversion of encrypted data, ciphertext, into its original form. Generally, the reverse of encryption. DES Data Encryption Standard. A symmetric encryption algorithm with a 56-bit key with eight parity bits. DES3 Triple Data Encryption Standard. A symmetric encryption algorithm with three 56-bit key with eight parity bits. Also known as Triple-DES and TDEA. DRBG Deterministic Random Bit Generator. ECB Electronic Codebook. A mode of encryption which divides a message into blocks and encrypts each block separately. Encryption The transformation of plaintext into an apparently less readable form, called ciphertext, using a mathematical process. The ciphertext can be read by anyone who has the key and decrypts (undoes the encryption) the ciphertext. FIPS Federal Information Processing Standards. Table 23 Acronyms and Definitions

Term Definition GCM Galois/Counter Mode. A mode of encryption combining the Counter mode of encryption with Galois field multiplication for authentication. HMAC Keyed-Hashing for Message Authentication Code. HMAC DRBG HMAC Deterministic Random Bit Generator. IV Initialization Vector. Used as a seed value for an encryption operation. KAT Known Answer Test. Key A string of bits used in cryptography, allowing people to encrypt and decrypt data. Can be used to perform other mathematical operations as well. Given a cipher, a key determines the mapping of the plaintext to the ciphertext. The types of keys include distributed key, private key, public key, secret key, session key, shared key, subkey, symmetric key, and weak key. Key wrapping A method of encrypting key data for protection on untrusted storage devices or during transmission over an insecure channel. MAC Message Authentication Code. MD5 A message digest algorithm, which hashes an arbitrary-length input into a 16-byte digest. Designed as a replacement for MD4. NDRBG Non-Deterministic Random Bit Generator. NIST National Institute of Standards and Technology. A division of the US Department of Commerce (formerly known as the NBS) which produces security and cryptography-related standards. OS Operating System. PBKDF2 Password-based Key Derivation Function 2. A method of password-based key derivation, which applies a MAC algorithm to derive the key. POST Pre-Operational Self-Tests. privacy The state or quality of being secluded from the view or presence of others. private key The secret key in public key cryptography. Primarily used for decryption but also used for encryption with digital signatures. PRNG Pseudo-Random Number Generator. PSP Public Security Parameters are security related public information (e.g. public keys) whose modification can compromise the security of the cryptographic module. RNG Random Number Generator. RSA Public key (asymmetric) algorithm providing the ability to encrypt data and create and verify digital signatures. RSA stands for Rivest, Shamir, and Adleman, the developers of the RSA public key cryptosystem. SHA Secure Hash Algorithm. An algorithm, which creates a unique hash value for each possible input. SHA takes an arbitrary input, which is hashed into a 160-bit digest. SHA-1 A revision to SHA to correct a weakness. It produces 160-bit digests. SHA-1 takes an arbitrary input, which is hashed into a 20-byte digest. Table 23 Acronyms and Definitions

Term Definition SHA-2 The NIST-mandated successor to SHA-1, to complement the Advanced Encryption Standard. It is a family of message digest algorithms (SHA2-224, SHA2-256, SHA2-384, SHA2-512, SHA2-512/224, and SHA2-512/256), which produce digests of 224, 256, 384, 512, 224, and 256 bits respectively. SSP Sensitive Security Parameters include both Critical Security Parameters (CSP) and Public Security Parameters (PSP). Triple-DES See DES3. XTS XEX-based Tweaked Codebook mode with ciphertext stealing. A mode of encryption used with AES. Table 23 Acronyms and Definitions of Dell Australia Pty. Ltd. or its subsidiaries. Other trademarks may be trademarks of their respective owners.