Dell™ BSAFE™ Crypto Module for Java 7.0

Certificate

Approved Algorithms (66)

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

flowchart LR
  %% Deterministic review-risk graph for Dell™ BSAFE™ Crypto Module for Java 7.0
  %% 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>update</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Self-test</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>DTLS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Dell™ BSAFE™ Crypto Module for Java 7.0
  %% 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>update</i><br/>src: text:keyword"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Self-test</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>DTLS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>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,C5,C6 clueLow;
  class C3 clueHigh;

Security Policy, page by page

ISO/IEC 19790 and FIPS 140-3 Non-Proprietary Security Policy for Dell™ BSAFE™ Crypto Module for Java 7.0 Software Version: 7.0 Last Updated: November 14, 2024, Version 1.2

Table of Content List of Figures List of Tables

for Java 7.0 (hereinafter referred to as the Module or JCM) with software version 7.0. The following details how this Module meets the security requirements of FIPS 140-3, SP800-140, and ISO/IEC 19790 The security requirements cover areas related to the design and implementation of a cryptographic module. attacks. Table 1 below indicates the actual security levels for each area of the cryptographic Module. N/A N/A Table 1 Security Levels 1The module relies on the physical security provided by the host on which it runs. The Module has an overall security level of 1. The Module is a multi-chip standalone software module intended to be used as part of a software system, providing cryptographic services to that system. The module’s operational environment is non-modifiable. The module is provided as a Java Archive (jar) file. It is intended to be distributed with, and used by, a Java application. The module consists of a jar file, jcmFIPS-7.0.jar. The name and version of the module can be accessed from the API ModuleConfig.getVersionInfo(). The FIPS 140-3 validation certificate can be located on the NIST Cryptographic Module Validation Program (CMVP) page using the module name and version reported. The Module has been tested on the following Operational Environments:

# N/A N/A N/A N/A Table 2 Tested Operational Environment In addition to the platforms listed in Table 2, Dell has also tested the module on the following platforms and claims vendor affirmation on them: #

Table 3 Vendor Affirmed Operational Environments The CMVP makes no statement about the correct operation of the module or the security strengths of the generated keys when ported to an operational environment which is not listed on the validation certificate. Mode of operation The Module supports both approved and non-approved modes of operation. It can operate in an approved mode after initial operations are performed, and all pre-operational self-tests have been completed successfully. The non-approved mode is entered when a non-approved algorithm or service is invoked. The Approved mode of operation can only be transitioned into the Non-Approved mode by calling one of the Non-Approved services. The Module does not claim implementation of a degraded mode of operation. If any self-test fails, the cryptographic services of the module are disabled for both Approved and NonApproved modes of operation. Section 4 provides details on the service indicator implemented by the Module. Table 4 below lists all the approved or vendor-affirmed security functions of the Module, including specific key size(s)

• in bits unless otherwise noted –employed for approved services and implemented modes of operation. There are some algorithm modes that were tested but not implemented by the Module. Only the algorithms, modes, and key sizes that are implemented by the Module are shown in this table. The mode of operation is identified by the following fields in the FIPS140Context interface:
• FIPS140Context.MODE_FIPS140: Only Approved Algorithms can be used in this mode.
• FIPS140Context.MODE_NON_FIPS140: Both approved and non-approved algorithms can be used in this mode. The ModuleLoader.load() API loads the Module for use in approved mode. This API returns the one and only instance of a ModuleConfig object. The ModuleConfig.newCryptoModule() API creates CryptoModule objects. This API supports a FIPS140Context parameter which specifies the FIPS 140-3 mode of operation of the CryptoModule. Refer to the API Javadoc for more information about these APIs. An application using Module must include the jar file, jcmFIPS-7.0.jar, in its Java classpath and call the ModuleLoader.load() API to load the Module. This API runs the pre-operational self-tests and cryptographic algorithm self-tests automatically and if the self-tests complete successfully, the cryptographic services of the Module can be used.

N/A N/A N/A N/A N/A Table 4 - Approved Algorithms 1Password-based key derivation function 2 (PBKDF2). As defined in NIST Special Publication 800-132, PBKDF2 can be used in Approved mode when used with Approved symmetric key and message digest algorithms. For more information, see Crypto Officer Guidance 2The module supports cryptographic key generation as described in section 4 of SP800-133rev2 where V is a constant string of binary zeroes. The module also

Table 5 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation As there are no non-Approved algorithms allowed in the approved mode of operation, the tables defined in SP800-140B for the following categories are missing from this document:

• Non-Approved Algorithms Allowed in Approved Mode of Operation Non-Approved Algorithms Allowed in Approved Mode of Operation with No Security Claimed Cryptographic boundary The 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 jar 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 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 exceptions documented for each call. This is illustrated in Figure 1, which depicts the Module’s cryptographic boundary and physical perimeter. The cryptographic boundary includes all of the software components of the cryptographic libraries. The physical perimeter is the Tested Operational Environment’s Physical Perimeter (TOEPP) on which the Module runs.

Figure 1 Module’s Block Diagram Cryptographic module interfaces The Module’s physical perimeter encompasses the case of the tested platform mentioned in Table 2 Tested Operational Environment. The Module provides its logical interfaces via API calls. The logical interfaces provided by the Module are mapped onto the FIPS 140-3 logical interfaces (Data Input, Data Output, Control Input, Control Output, and Status Output) as follows: N/A N/A N/A N/A N/A N/A Table 6 Ports and Interfaces

Roles, services, and authentication The Module meets all FIPS 140-3 Security Level 1 requirements for Roles, Services; and Authentication, implementing a Crypto Officer Role. As allowed by FIPS 140-3, the module does not support identification or authentication for this role. The Crypto Officer Role is implicitly assumed once the Module is loaded, and the role is cleared on Module unload. There is no maintenance role, cryptographic bypass capability, or self-initiated cryptographic output. The module does not allow concurrent operators. Table 7 Roles, Service Commands, Input, and Output The abbreviations of the access rights to keys and SSPs have the following interpretation: G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module. W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroize: The module zeroizes the SSP. N/A = Not applicable: The service does not access any SSP during its operation.

Table 8 below lists all approved services that can be used in the approved mode of operation. E E E E N/A R EC DiffieHellman E Z N/A

N/A EC DiffieHellman EC DiffieHellman G, R R G

Table 9 Non-Approved Services N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A

The Module doesn’t support self-initiated cryptographic output capability and cryptographic Bypass capability services. Software/Firmware security Integrity techniques Module integrity check is implemented by first calculating a MAC over each of the files listed in module.files, using HMAC-SHA-1 with a fixed key. Another MAC is then calculated over all file MACs in the order that they are listed, using the same algorithm and key as for the file MACs. This two-step process is intended to allow the jar file to be processed sequentially without having to load the entire jar file into memory even after the order of the jar file entries has been changed. The expected integrity check MAC is stored in the jar file manifest. During the Integrity Test when the module is loaded, a MAC is again calculated and compared with the pre-computed MAC value contained in the jar file manifest. If these values are equal, then the software integrity check has passed and power-up of the Module can continue. Otherwise, the test has failed, and the Module is disabled. Integrity test on-demand The integrity test is performed as part of the pre-operational self-tests. It is automatically executed at power-on. The module provides the ModuleConfig.runSelfTests() API to allow the operator to perform on-demand integrity testing. The operator can also power-cycle or reboot the tested platform to initiate the software integrity test on-demand. Operational environment The Module is a software module, which is operated in a modifiable operational environment per FIPS 140-3 level 1 specifications. The module is provided for operating systems running on a general-purpose computer platform based on an Intel CPU. The Module has control over its own SSPs. The process and memory management functionality of the host device’s OS prevents unauthorized access to plaintext private and secret keys, intermediate key generation values, and other SSPs by external processes during module execution. The Module only allows access to SSPs through its well-defined API. The operational environments provide the capability to separate individual application processes from each other by preventing uncontrolled access to CSPs and uncontrolled modifications of SSPs regardless of whether this data is in the process memory or stored on persistent storage within the operational environment. Processes that are spawned by the Module are owned by the Module and are not owned by external processes or operators. Physical security The FIPS 140-3 physical security requirements do not apply to the Module since it is a software module. Non-invasive security Currently, non-invasive security is not required by FIPS 140-3 (see NIST SP800-140F). The requirements of this area are not applicable to the Module.

Sensitive security parameters management The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the Module: shment SP80090Arev1. SP80090Arev1. SP80090Arev1. using SP80090ARev1 (SP80056Arev3). Zeroisatio n derive DiffieHellman derive DiffieHellman

N/A EC DiffieHellman N/A SP800133rev2 DiffieHellman key using SP80090Arev1 (SP80056Arev3). N/A SP800Export: No derive DiffieHellman DiffieHellman DiffieHellman DiffieHellman

using SP80090Arev1 using SP80090Arev1 SP800133rev2 using SP80090Arev1

N/A SP800133rev2 using SP800133rev2 using HMAC-SHA2224 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512 HMAC-SHA3256 HMAC-SHA3384 HMAC-SHA3512 N/A

N/A N/A N/A N/A N/A SP800down Table 10 SSPs Table 11 Non-Deterministic Random Number Generation Specification The Module is passively receiving the entropy while exercising no control over the amount or the quality

provide the required security strength, and to ensure the security strength of a DRBG is equal to or greater than the security strength of any SSPs generated using that DRBG. Entropy can be supplied to the Module using the following APIs:

• com.rsa.crypto.SecureRandom.setSeed() com.rsa.crypto.ModuleConfig.setEntropySource() When generating SSPs, the DRBG used in key generation must be seeded with a number of bits of entropy that is equal to or greater than the security strength of the SSP being generated. The entropy supplied to the DRBG is referred to as the DRBG security strength which represents the minimum amount of entropy that should be provided to the DRBG prior to generating the SSP. The following table lists each of the keys that can be generated by the JCM, with the key sizes available, security strengths for each key size, and the security strength required to initialize the DRBG: Table 12 Generated Key Sizes and Strength

When the Module is loaded or instantiated after being power-cycled or rebooted, the Module runs preoperational self-tests. The operating system is responsible for the initialization process and loading the Module. The Module is designed with a default entry point (DEP) that ensures automatic initiation of the self-tests when the Module is loaded. Before the Module provides any data output via the data output interface, the Module performs the pre-operational self-tests, ensuring all pass. A software integrity test is performed on the runtime image of the Module with an HMAC-SHA-1 algorithm. Prior to the firmware integrity test, the Module conducts an HMAC-SHA-1 Cryptographic Algorithm Self-test (CAST). If the CAST on the HMAC-SHA-1 is successful, the HMAC value of the runtime image is recalculated and compared with the stored HMAC value pre-computed at compilation time. During power-up, and following the successful pre-operational self-tests, the Module executes the Conditional CASTs for all approved cryptographic algorithms implemented by the Module. The self-test success or failure messages, for example, Error: Signature RSA test failure or ECDH P-256 test failure, are logged and function as the self-test status indicator. If any one of the self-tests fails, the Module transitions into a FIPS140State.FAILED error state and outputs the error message via the Module’s status output interface, SecurityException. While the Module is in the error state, all data through the data output interface and all cryptographic operations are disabled. The only method to recover from the error state is to power cycle the device. This results in the Module being reloaded into memory and reperforming the pre-operational software integrity test and the

Conditional CASTs. The module will only enter the operational state after successfully passing the preoperational software integrity test and the Conditional CASTs. Pre-operational self-tests Pre-operational self-tests are executed automatically when the Module is loaded into memory. They can be re-run manually after the module has loaded, by calling the ModuleConfig.runSelfTests() API. The pre-operational self-tests include the Software Integrity Test. The Software Integrity Test is comprised of an HMAC-SHA-1 verification of the files listed in fips140/module.files. The cryptographic services of the Module are disabled when the self-tests are running. When the self-tests are running, the following stands true:

• All cryptographic operations, if called, throw a CryptoException.
• The CryptoModule.getState() status output interface, if called, returns a state of com.rsa.crypto.FIPS140State.UNDER_SELF_TEST. If any pre-operational self-test fails, all cryptographic services of the Module are disabled. When the selftests fail, the following stands true:
• All cryptographic operations, if called, throw a CryptoException.
• The CryptoModule.getState() status output interface, if called, returns a state of com.rsa.crypto.FIPS140State.FAILED. If the pre-operational self-tests pass, the cryptographic services of the Module are enabled, and the module can be used. The CryptoModule.getState() status output interface returns a state of com.rsa.crypto.FIPS140State.OPERATIONAL. Pre-operational software integrity test
• HMAC-SHA-1 KAT
• Software Integrity Test (using HMAC-SHA-1) Note: The Module conducts HMAC-SHA-1 KAT self-test before the integrity test is performed. Conditional self-tests
• Cryptographic Algorithm Self-Tests (CASTs)
• AES-CBC 256 bits Encrypt KAT
• AES-CBC 256 bits Decrypt KAT
• AES-GCM 256 bits Authenticated Encrypt KAT
• AES-GCM 256 bits Authenticated Decrypt KAT
• CMAC 128 bits KAT
• CTR_DRBG Instantiate KAT
• CTR_DRBG Generate KAT
• CTR_DRBG Reseed KAT Note: CTR_DRBG Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP800-90Arev1
• DSA SigGen with SHA-256 KAT
• DSA SigVer with SHA-256 KAT
• ECDSA P-256 with SHA-256 SigGen KAT
• ECDSA P-256 with SHA-256 SigVer KAT
• HASH-DRBG with SHA-1 KAT
• HMAC-DRBG with SHA-1 KAT

o o o o o o o o o o o o o o o

• HMAC-SHA-1 KAT HMAC-SHA-256 KAT HMAC-SHA-384 KAT HMAC-SHA-512 KAT KAS-ECC-SSC Primitive Z KAT KAS-FFC-SSC Primitive Z KAT KDFTLS12 SHA-256 KAT OneStepKDF KAT PBKDF2 with SHA-1 KAT RSA 2048 bits modulus with SHA-256 SigGen KAT RSA 2048 bits modulus with SHA-256 SigVer KAT SHA-1 KAT SHA2-512 KAT SHA3-512 KAT SHAKE256 KAT SP800-108 KDF KAT The Module generates RSA, ECDSA, KAS-ECC, and KAS-FFC asymmetric keys and performs all required pair-wise consistency tests on the newly generated key pairs as detailed in the “Pair-wise consistency tests” section below. If the Pair-wise Consistency conditional test fails, the Module throws a SecurityException and aborts the operation. A Pair-wise Consistency test failure does not disable the Module. Pair-wise consistency tests (PCTs):
• ECDSA PCT
• DSA PCT
• RSA PCT
• KAS-ECC PCT
• KAS-FFC PCT Periodic self-tests The Module performs on-demand self-tests initiated by the operator, by power-cycling or rebooting the tested platform. The full suite of self-tests is then executed. The same procedure may be employed by the operator to perform periodic self-tests. In addition, it is recommended for the Crypto Officer to perform the periodic tests a minimum of once every 60 days to ensure all components are functioning correctly. Error handling If any of the above-mentioned self-tests fail, the Module reports the cause of the error and enters a FIPS140State.FAILED error state (there is only one error state). In the Error State, no cryptographic services are provided, and data output is prohibited. The only method to recover from the error state is to power-cycle or reboot to reload the Module and perform the self-tests, including the pre-operational software integrity test and the conditional CASTs. The module will only enter the operational state after successfully passing the pre-operational software integrity test and the conditional CASTs. Note: FIPS140State.FAILED is the only error state.

Installation, Initialization, Startup, Operation and Maintenance The module is installed by adding jcmFIPS-7.0.jar to the application's classpath. The module is started by starting the application that references it. The module uses JDK services to perform the module startup when the application loads it. When loading the module, the com.rsa.crypto.jcm.ModuleLoader.load() method extracts arguments from the com.rsa.cryptoj.jcm.JavaModuleProperties class, which is created using the com.rsa.cryptoj.jcm.CryptoJModulePropertiesFactory class. The following arguments are extracted:

• The module jar file. The security level, specified as the constant ModuleConfig.LEVEL_1 which should have the value of 1. An optional SelfTestEventListener argument used for logging power-up self-test events. An optional java.util.concurrent.ExecutorService argument used for running the power-up self-tests. An optional file to be used for reading and writing the status of the algorithm power-up self-tests. Using the specified securityLevelensures that the module is loaded for use in an approved mode. Loading the module runs the integrity tests that must be completed successfully before any cryptographic services are made available by the module. This ensures that the application has made no modification to the module as part of its development or installation. For more information about the Integrity Tests, see Software/Firmware Security. The module starts in an approved mode and in the Crypto Officer Role by default. Otherwise, to assume a role once the module is operational, construct a FIPS140Context object for the desired role using the FIPS140Context.getFIPS140Context(int mode, int role) method.
• The mode argument must be the value FIPS140Context.MODE_FIPS140. To retrieve the current mode of operation, call FIPS140Context.getMode().
• The available role value is the constant FIPS140Context.ROLE_CRYPTO_OFFICER. No role authentication is required to operate the module in Security Level 1 mode. This object can then be used to perform cryptographic operations using the module. The only permitted maintenance operation is to add a signature to the jar file by re-signing with an application certificate. Otherwise, application writers should not attempt to modify the module jar file as the module will refuse to load or perform cryptographic operations. Crypto Officer Guidance For details of the administrative functions, security parameters, and logical interfaces available to the Crypto Officer. The following table details the requirements for algorithm use in the Approved mode operation:

• Both parties must use validated parameters to generate a key pair.
• The Module generates the key establishment key pair according to the required standards.
• Choose a FIPS Approved DRBG like HMAC DRBG to generate the key pair.
• Both parties validate the key pair: The Module provides the following APIs to explicitly validate the public and private keys according to SP800-56A Rev.3: com.rsa.crypto.PublicKey.isValid(SecureRandom random) com.rsa.crypto.PrivateKey.isValid(). The module provides the APIs to explicitly validate the key pair according to the pairwise consistency requirements in SP800-56A Rev. 3: com.rsa.crypto.KeyPair.validate(SecureRandom random) com.rsa.crypto.KeyPair.validate(AlgorithmParams params, SecureRandom random) If the key pair is generated with an approved method, then validation is assumed.
• For schemes that use static key pairs, a public identifier must be:
• Authoritatively associated with the key pair.
• Associated with the public key to allow any peer to recognize the key pair.
• For schemes that use ephemeral keys, the key pair must be:
• Used only for a single agreement transaction.
• Destroyed after use.
• For schemes that generate an FFC key pair from selected parameters, the key pair must not be used to generate a digital signature. Receive the peer's public key:
• For all schemes, the receiving party must validate the peer's public key.
• For schemes that use static keys, the receiving party must have assurance of:
• The peer's ownership of the private key.
• The identifier is bound to the public key. Generate the Shared Secret:
• For all schemes, the shared secret must be:
• Used only as input to an approved KDF.
• Treated as a CSP and destroyed after use.
• If the shared secret generation fails then the party must destroy all intermediate values. Generate and Confirm Secret Key Material:
• For all schemes:
• Approved key-derivation method(s), including the format of FixedInfo as specified in SP800-56A Rev. 3.
• When the shared secret is used as input to the KDF the outputs must be used as secret keys.

N L

• Table 13 Algorithm Requirements for Approved Mode of Operation

RSA, EC, and DSA key operations implement blinding by default, a reversible way of modifying the input data, to make the operation immune to timing attacks. Blinding has no effect on the algorithm other than to mitigate attacks on the algorithm. For more information, see Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems. RSA, EC, and DSA blinding is implemented through blinding modes, for which the following options are available:

• Blinding mode off.
• Blinding mode with no update, where the blinding value is squared for each operation. This mitigation is enabled by default. For optimum security, it should not be disabled. 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. For more information, see Modulus Fault Attacks Against RSA-CRT Signatures and On the Importance of Eliminating Errors in Cryptographic Computations. This mitigation is enabled by default. For optimum security, it should not be disabled. RSA PKCS #1 v1.5 encryption padding operations are implemented in constant time in order to make the operation immune to timing attacks. For more information, see Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1. Time invariant comparisons are also used for HMAC and RSA verify operations. For this mitigation, constant time padding is built-in and cannot be disabled.