Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility

Certificate

Approved Algorithms (83)

Security Levels (Table 1)

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

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

flowchart LR
  %% Deterministic clue tier for Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility
  %% 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/>Show Status<br/>self-test</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<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,C5,C6 clueLow;

Security Policy, page by page

Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Document Version 1.2 July 30, 2025 Prepared for: Prepared by: Keysight Technologies

Bldg. 2, Suite 300 Austin, TX 78731 keysight.com KeyPair Consulting Inc.

San Luis Obispo, CA 93401 +1 805.316.5024 keypair.us

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Table of Contents

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility List of Tables List of Figures

Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Introduction This document defines the Security Policy for the Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility, hereafter denoted the module. The module is a cryptographic library and has a Multi-Chip Stand Alone embodiment. The module meets FIPS 140-3 overall Level 1 requirements. The SW version is 2.0.0. The FIPS 140-3 security levels for the module are given in Table 1 as follows: Table 1. Security Levels 1.1 N/A N/A Confirming the Module Checksum, Functionality, and Versioning The module checksum, functionality, and versioning can be confirmed by executing the command: java ‐cp bc‐fips‐2.0.0.jar org.bouncycastle.util.DumpInfo which should display: Version Info: BouncyCastle Security Provider (FIPS edition) v2.0.0 FIPS Ready Status: READY Module SHA‐256 HMAC: 164c8ae41945cb85fdc65666fc4de7301a65d29659ecd455ee5199c7d42d107e Indicating the jar represents the software release 2.0.0, that it has successfully passed all its startup tests, and that the software release is confirmed to have a HMAC of: 164c8ae41945cb85fdc65666fc4de7301a65d29659ecd455ee5199c7d42d107e

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Cryptographic Module Specification The module is intended for use by US Federal agencies and other markets that require a FIPS 140-3 validated Cryptographic Library. The module is of type software and the module has a Multi-Chip Stand Alone embodiment; the cryptographic boundary is the Java Archive (JAR) file, bc-fips2.0.0.jar. This module is the only software component within the Cryptographic Boundary and the only software component that carries out cryptographic functions covered by FIPS 140-3. Figure 1 shows the logical relationship of the cryptographic module to the other software and hardware components of the computer. The BC classes are executed on the Java Virtual Machine (JVM) using the classes of the Java Runtime Environment (JRE). The JVM is the interface to the computer’s Operating System (OS) that is the interface to the various physical components of the computer. Figure 1. Cryptographic Boundary

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility The cryptographic module was tested on the following operational environments on the general-purpose computer (GPC) platforms detailed in Table 2, which is also the TOEPP (Tested Operational Environment’s Physical Perimeter) of the module. Table

2. Tested Operational Environments # The cryptographic module will remain compliant with the FIPS 140-3 validation when operating on any general-purpose computer (GPC) provided that:
3. No source code has been modified.
4. The GPC uses the specified single-user platform, or another compatible single-user platform such as one of the Java SE Runtime Environments listed on any of the following: Table
5. Vendor Affirmed Operational Environments #

FIPS 140-3 Security Policy # Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility For the avoidance of doubt, it is hereby stated that the CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate. The module implements the Approved and Non-Approved but Allowed cryptographic functions with no security claimed listed in Table 4 and Table 5 below. There are algorithms, modes, and keys that have been CAVP tested but not used by the module. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in this table are used by the module. The module supports both Approved and Non-Approved mode of operation. Please see Section 6.3 for configuration of the module in Approved mode of operation. Please see Section 11 for initialization steps.

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Table 4. Approved Algorithms N/A N/A N/A N/A N/A N/A N/A N/A

1 GCM encryption with an internally generated IV, see section 2.2 concerning external IVs. IV generation is compliant with IG C.H.

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility N/A N/A N/A N/A N/A

3 Keys are not established directly into the module using the key agreement algorithms.

4 No parts of the protocols (TLS, SSHv2, X9.63, IKEv2, SRTP, SNMPv3), other than the approved cryptographic algorithms and the KDFs, have been reviewed or tested by the CAVP and CMVP.

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility N/A N/A N/A N/A N/A N/A

5 Note: CAVP testing is not provided for use of the PRFs SHA-512/224 and SHA-512/256. These must not be used in approved mode.

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility N/A N/A N/A N/A N/A N/A N/A D.H N/A Table 5. Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Table 6. Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

9 Support for additional key sizes and the establishment of keys of less than 112 bits of security strength.

10 Deterministic signature calculation, support for additional digests, and key sizes.

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility

11 Keys are not directly established into the module using key agreement or transport techniques.

12 Support for additional digests and signature formats, PKCS#1 1.5 key wrapping, support for additional key sizes.

13 Support for additional key sizes and the establishment of keys of less than 112 bits of security strength.

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility 2.1 Basic Enforcement The module design corresponds to the module security rules. This section documents the security rules enforced by the cryptographic module to implement the security requirements of this FIPS 140-3 Level 1 module: 1. 2. 3. 4.

5. The module shall provide two distinct operator roles: User and Cryptographic Officer. The module does not provide authentication. The operator shall be capable of commanding the module to perform the power up self-tests by cycling power or resetting the module. Power up self-tests do not require any operator action. Data output shall be inhibited during self-tests, zeroization, and error states. Output related to keys and their use is inhibited until the key concerned has been fully generated.
6. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module.
7. There are no restrictions on which keys or CSPs are zeroized by the zeroization service.
8. The module does not support concurrent operators.
9. The module does not have any external input/output devices used for entry/output of data.
10. The module does not enter or output plaintext CSPs from the module’s physical perimeter.
11. The module does not output intermediate key values. HMAC algorithms specified in the Approved Algorithms table produce truncated versions of the HMAC in question. The right most bits are truncated as per the NIST SP 800-107 rev1. When the module is used within the context of Java Security Manager or the system/security property org.bouncycastle.fips.approved_only is set to true, the module will start in approved mode and non-approved services are not accessible in this mode. When the module is not used within the context of Java Security Manager, the module will start in a non-approved mode by default. From non-approved mode to approved mode: It is a combination of granted permission (a) and request to change mode (b): a. org.bouncycastle.crypto.CryptoServicesPermission “changeToApprovedModeEnabled” b. CryptoServicesRegistrar.setApprovedMode(true) The CSPs made available in non-approved mode will not be accessible, once the thread transitions into approved mode. The CSPs generated using the nonapproved mode cannot be passed or shared with algorithms operating in approved mode, and vice-versa. This is done by indicating within the class (object), instantiating the key, as being created in an approved mode or non-approved mode.

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Any attempt by a thread within the execution of the module to use the key in an opposite mode will result in an exception being generated by the module. For example, if an RSA private key has been created in either approved or non-approved mode, then any request to access that key will first need to see if the thread making the request is in the same mode. From approved mode to non-approved mode: The module cannot transition from approved mode to non-approved mode. To initiate the module in nonapproved mode, either it should not be used in the context of Java Security Manager, or the module should have the permission “org.bouncycastle.crypto.CryptoServicesPermissionunapprovedModeEnabled” granted by the Java Security Manager. 2.2 Enforcement and Guidance for GCM IVs IVs for GCM can be generated randomly, or via a FipsNonceGenerator. Where an IV is not generated within the module the module supports the importing of GCM IVs. In approved mode, when a GCM IV is generated randomly, the module enforces the use of an approved DRBG in line with Section 8.2.2 of SP 800-38D. In approved mode, when a GCM IV is generated using the FipsNonceGenerator a counter is used as the basis for the nonce and the IV is generated in accordance with TLS protocol. Rollover of the counter in the FipsNonceGenerator will result in an IllegalStateException indicating the FipsNonceGenerator is exhausted and, as per IG C.H, where used for TLS 1.2, rollover will terminate any TLS session in process using the current key and the exception can only be recovered from by using a new handshake and creating a new FipsNonceGenerator. In approved mode, importing a GCM IV for encryption that originates from outside the module is non-conformant. A service indicator for IV usage is provided in the module through Java logging. Setting the logging level to Level.FINE for the named logger “org.bouncycastle.jcajce.provider.BaseCipher” will produce a log message when an IV which may have been produced outside the module and/or not from a compliant source is detected. The log message will be of the standard form including the detail: FINE: Passed in GCM nonce detected: <IV value> where <IV value> is a HEX representation of the IV in use. Setting the logging level to Level.FINER will produce an additional log message for any GCM IV which is used if the previous Level.FINE message is not activated. Log messages in this case will show the detail as: FINER: GCM nonce detected: <IV value> where <IV value> is a HEX representation of the IV in use. Per IG C.H, in the event module power is lost and restored the consuming application must ensure that any of its AES-GCM keys used for encryption or decryption are re-distributed. The AES-GCM Mode falls under:

• IG C.H scenario 2: GCM IV is generated randomly, and the module uses an Approved DRBG that is internal to the module’s boundary. The IV length is 96 bits.
• IG C.H scenario 1 for TLSv1.2 protocol: The module is compatible with TLSv1.2 protocol and supports acceptable AES-GCM ciphersuites from Section

FIPS 140-3 Security Policy 2.3 Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Enforcement and Guidance for use of the Approved PBKDF In line with the requirements for SP 800-132, keys generated using the approved PBKDF must only be used for storage applications. Any other use of the approved PBKDF is non-conformant. In approved mode the module enforces that any password used must encode to at least 14 bytes (112 bits) and that the salt is at least 16 bytes (128 bits) long. The iteration count associated with the PBKDF should be as large as practical. As the module is a general-purpose software module, it is not possible to anticipate all the levels of use for the PBKDF, however a user of the module should also note that a password should at least contain enough entropy to be unguessable and also contain enough entropy to reflect the security strength required for the key being generated. In the event a password encoding is simply based on ASCII a 14 byte password is unlikely to contain sufficient entropy for most purposes as the standard set of printable characters only allows for as much as 6 bits of entropy per byte, giving a password which for the case of 14 bytes, yields a key that has been generated using 14 * 6 bits, giving only 84 bits of security, well below what is required for a key with the same level of hardness as a 112 bit one. Users are referred to Appendix A, “Security Considerations” of SP 800-132 for further information on password, salt, and iteration count selection. The iteration count value is provided by the user

• and should be appropriate to the way the algorithm is being used (the memory hard augmentation of PBKDF provided by SCRYPT uses an iteration count of 1), for straight PBKDF with no memory hard support, the iteration count provided by the user should be at point where the maximum cost bearable by the user carrying out the key derivation in the normal course of usage. To ensure sufficient whitening of the password in both cases, the module enforces a salt size of 128 bits in approved-only mode. For users interested in introducing memory hardness as a layer on top of the PBKDF the scrypt augmentation to PBDKF based on HMAC SHA-256 (as described in RFC 7914) is also available. 2.4 Rules for setting the N and the S String in cSHAKE The cSHAKE algorithm offers to input string for customizing the output of the cSHAKE function, the Function-Name input (N) and the Customization String (S). The Function-Name input (N) is reserved for values specified by NIST and should only be set to the appropriate NIST specified value. Any other use of N is non-conformant. The Customization String (S) is available to allow users to customize the cSHAKE function as they wish. The length of S is limited to the available size of a byte array in the JVM running the module.

FIPS 140-3 Security Policy 2.5 Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Guidance for the use of Format-Preserving Encryption The module supports both FF1 and, in non-approved mode, FF3-1 format preserving encryption. Below shows the parameter constraints applicable to the module’s implementation. SP800-38G Format-Preserving Encryption Constraints: radix radixminlen minlen maxlen maxTlen in range of 2..216 >= 1000000 >= 2 octets < 232 octets >= 0 octets in range of 2..216 >= 1000000

An attempt to use the FF1 or FF3-1 without meeting the radixminlen constraint or by exceeding maxlen will result in an IllegalArgumentException. Note: only FF1 should be used in approved mode. 2.6 Cryptographic Key Generation The module performs Cryptographic Key Generation in conformance to FIPS 140-3 IG D.H. The CKG for symmetric keys and seeds used for generating asymmetric keys is performed as per Section 4 of the SP800-133r2 and compliant with FIPS 186-4 and SP800-90Arev1 for DRBG. The seed used in asymmetric key generation is the direct output of SP800-90Arev1 DRBG. Cryptographic Module Interfaces The module is a software module, and, therefore, control of the physical ports is outside of the module’s scope. The module does provide a set of logical interfaces which are mapped to the following FIPS 140-3 defined logical interfaces: data input, data output, control input, status output, and power. When the module performs self-tests, is in an error state, is generating keys, or performing zeroization, the module prevents all output on the logical data output interface as only the thread performing the operation has access to the data. The module is single-threaded, and in an error state, the module does not return any output data, only an error value. The module does not implement control output interface. The mapping of the FIPS 140-3 logical interfaces to the module is described in Table

7. Table
8. Ports and Interfaces

FIPS 140-3 Security Policy Roles, Services, and Authentication 4.1 Basic Guidance Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility The jar file representing the module needs to be installed in a JVM’s class path in a manner appropriate to its use in applications running on the JVM. Functionality in the module is provided in two ways. At the lowest level there are distinct classes that provide access to the approved and non-approved services provided by the module. A more abstract level of access can also be gained using strings providing operation names passed into the module’s Java cryptography provider through the APIs described in the Java Cryptography Architecture (JCA) and the Java Cryptography Extension (JCE). When the module is being used in approved mode, classes providing implementations of algorithms which are not approved, or allowed, are explicitly disabled. SSPs such as private and secret keys implement the Destroyable interface. Where appropriate these SSPs can be zeroized on demand by invoking the destroy() method. The return of the destroy() method indicates that the zeroization is complete. Roles, with corresponding service with input and output is specified in Table 8 below: Table 8. Roles, Service Commands, Input and Output N/A N/A N/A N/A N/A

FIPS 140-3 Security Policy 4.2 Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility N/A N/A N/A N/A N/A Assumption of Roles The module supports two distinct operator roles, User and Cryptographic Officer (CO). The cryptographic module implicitly maps the two roles to the services. A user is considered the owner of the thread that instantiates the module and, therefore, only one concurrent user is allowed. Table 9 lists all operator roles supported by the module. The module does not support a maintenance role and/or bypass capability. The module does not support authentication. Table 9. Roles and Authentication 4.3 N/A N/A Services Table 10 lists the services and a description of each service with the usage and roles. Services in the module are accessed via the public APIs of the jar file. The ability of a thread to invoke non-approved services depends on whether it has been registered with the module as approved mode only. In approved only mode no non-approved services are accessible. In the presence of a Java SecurityManager approved mode services specific to a context, such as DSA and ECDSA for use in TLS, require specific permissions to be configured in the JVM configuration by the Cryptographic Officer or User. In the absence of a Java SecurityManager specific services related to protocols such as TLS are available, however must only be used in relation to those protocols.

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility The modes of access shown in the table are defined as:

• G = Generate: The module generates or derives the SSP.
• E = Execute: The module uses the SSP in performing a cryptographic operation.
• R = Read: The SSP is read from the module (e.g. the SSP is output).
• W = Write: The SSP is updated, imported, or written to the module. Table 10. Approved Services N/A N/A N/A N/A N/A N/A N/A Z E N/A N/A N/A

14 Flag is accessed by calling the method CryptoServicesRegistrar.isInApprovedOnlyMode() - this method will return true if the thread is running in approved mode, false otherwise.

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility E E E E G E

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility N/A E E E E G E G E E E G E N/A

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility N/A G E E E E E G N/A

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility R N/A N/A N/A N/A Table 11. Non-Approved Services

15 Flag is accessed by calling the method CryptoServicesRegistrar.isInApprovedOnlyMode() - this method will return true if the thread is running in approved mode, false otherwise.

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Software/Firmware Security The module type is software. The module has a Multi-Chip Stand Alone embodiment; the cryptographic boundary is the Java Archive (JAR) file, bc-fips2.0.0.jar. Each time the module is powered up, it runs the pre-operational tests to ensure that the integrity of the module has been maintained. Self–tests are available on demand by power cycling the module. The integrity is verified using HMAC-SHA2-256. The HMAC of the module JAR file excluding directories and metadata is calculated and compared to the expected value embedded within the module’s properties. If the calculated value does not match the expected value, the module raises an error and fails to load. The integrity test can be performed on demand by power cycling the host platform. CASTs are performed prior to the first use of services related to the test target. CASTs also run periodically on service invocation. Initial CAST self–tests are available on demand by power cycling the module and then invoking the service related to the test target. Operational Environment The module operates in a modifiable operational environment under the FIPS 140-3 definitions. The module runs on a GPC running one of the operating systems specified in the approved operational environment list in Table 2. Each approved operating system manages processes and threads in a logically separated manner. The module’s user is considered the owner of the calling application that instantiates the module within the process space of the Java Virtual Machine. The module optionally uses the Java Security Manager and starts in approved mode by default when used with the Java Security Manager. 6.1 Use of External RNG The module makes use of the JVM's configured SecureRandom entropy source to provide entropy when required. The module will request entropy as appropriate to the security strength and seeding configuration for the DRBG that is using it and for the default DRBG will request a minimum of 256 bits of entropy. In approved mode the minimum amount of entropy that can be requested by a DRBG is 112 bits. The module will wait until the SecureRandom.generateSeed() returns the requested amount of entropy, blocking if necessary. The JVMs entropy source can be configured through setting the security property: securerandom.strongAlgorithms in the JVM's java.security file. 6.2 Additional Enforcement with a Java SecurityManager In the presence of a Java SecurityManager approved mode services specific to a context, such as DSA and ECDSA for use in TLS, require specific policy permissions to be configured in the JVM configuration by the Cryptographic Officer or User. The SecurityManager can also be used to restrict the ability of particular code bases to examine CSPs. See Section 6.3 for further advice. In the absence of a Java SecurityManager, specific services related to protocols such as TLS are available, however must only be used in relation to those protocols.

FIPS 140-3 Security Policy 6.3 Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Approved Mode Configuration In default operation the module will start with all algorithms and services enabled. If the module detects that the system property org.bouncycastle.fips.approved_only is set to true the module will start in approved mode and non-approved mode functionality will not be available. If the underlying JVM is running with a Java Security Manager installed the module will be running in approved mode with secret and private key export disabled. When the module is not used within the context of the Java Security Manager, it will start by default in the non-approved mode. Use of the module with a Java Security manager requires the setting of some basic permissions to allow the module HMAC-SHA-256 software integrity test to take place as well as to allow the module itself to examine secret and private keys. The basic permissions required for the module to operate correctly with a Java Security manager are indicated by a Y: Available Java Permissions RuntimePermission RuntimePermission PropertyPermission SecurityPermission CryptoServicesPermission CryptoServicesPermission CryptoServicesPermission CryptoServicesPermission CryptoServicesPermission CryptoServicesPermission CryptoServicesPermission CryptoServicesPermission CryptoServicesPermission CryptoServicesPermission CryptoServicesPermission “getProtectionDomain” “accessDeclaredMembers” “java.runtime.name”, “read” "putProviderProperty.BCFIPS" “unapprovedModeEnabled” “changeToApprovedModeEnabled” “exportSecretKey” “exportPrivateKey” “exportKeys” “tlsNullDigestEnabled” “tlsPKCS15KeyWrapEnabled” “tlsAlgorithmsEnabled” “defaultRandomConfig” “threadLocalConfig” “globalConfig” Y Y N N N N N N Y N N N N N N Allows checksum to be carried out on jar. Allows use of reflection API within the provider. Only if configuration properties are used. Only if provider installed during execution. Only if non-approved mode algorithms required. Only if threads allowed to change modes. To allow export of secret keys only. To allow export of private keys only. Required to be applied for the module itself. Optional for any other codebase. Only required for TLS digest calculations. Only required if TLS is used with RSA encryption. Enables both NullDigest and PKCS15KeyWrap. Allows setting of default SecureRandom. Required to set a thread local property in the CryptoServicesRegistrar. Required to set a global property in the CryptoServicesRegistrar. The JVM's entropy source is checked according to SP 800-90B, Section 4.4 using the suggest C values for the Repetition Count Test (Section 4.4.1) and the Adaptive Proportion Test (Section 4.4.2) by default. These values can also be configured by the Cryptographic Officer using the security property: “org.bouncycastle.entropy.factors” which takes a comma separated list of C values, one for 4.4.1 and one for 4.4.2, and a value of H.

FIPS 140-3 Security Policy 6.4 Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Guidance for the use of DRBGs and Configuring the JVM's Entropy Source A user can instantiate the default Approved DRBG for the module explicitly by using SecureRandom.getInstance("DEFAULT", "BCFIPS"), or by using a BouncyCastleFipsProvider object instead of the provider name as appropriate. This will seed the Approved DRBG from the live entropy source of the JVM with a number of bits of entropy appropriate to the security strength of the default Approved DRBG configured for the module. The JVM's entropy source is checked according to SP 800-90B, Section 4.4 using the suggest C values for the Repetition Count Test (Section 4.4.1) and the Adaptive Proportion Test (Section 4.4.2). These values can also be configured by the user using the security property: “org.bouncycastle.entropy.factors” which takes a comma separated list of C values, one for 4.4.1 and one for 4.4.2, and a value of H. For the default the property would be set as: org.bouncycastle.entropy.factors: 4, 13, 8.0 in the java.security property file. An additional option is available using the Approved Hash_DRBG and the process outlined in SP800 90A, Section 8.6.5. This can be turned on by following the instructions in Section 2.3 of the User Guide. The two DRBGs are instantiated in a chain as a "Source DRBG" to seed the "Target DRBG" in accordance with Section 7 of Draft NIST SP 800-90C, where the Target DRBG is the default Approved DRBG used by the module. The initial seed and the subsequent reseeds for the DRBG chain come from the live entropy source configured for the JVM. The DRBG chain will reseed automatically by pausing for 20 requests (which will usually equate to 5120 bytes). An entropy gathering thread reseeds the DRBG chain when it has gathered sufficient entropy (currently 256 bits) from the live entropy source. Once reseeded, the request counter is reset and the reseed process begins again. The “Source DRBG” in the chain is internal to the module and inaccessible to the user to ensure it is only used for generating seeds for the default Approved DRBG of the module. The user shall ensure that the entropy source is configured per Section 6.1 of this Security Policy and will block, or fail, if it is unable to provide the amount of entropy requested. Physical Security This section is not applicable as the module is a software module. Non-Invasive Security This section is not applicable to this module. Sensitive Security Parameter Management All Sensitive Security Parameters (SSPs) used by the module are described in this section in Table 12. All usage of these SSPs by the module (including all SSP lifecycle states) is described in the services detailed in Section 4.3. Please note that the module does not perform automatic SSP establishment, it only provides the components to the calling application which can be used in SSP establishment.

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Table 12. SSPs N/A N/A N/A N/A N/A N/A

18 Export done via key recovery using getEncoded() method and followed by separate step to export key details as either plaintext or encrypted (Electronic Entry).

19 The AES-GCM key and IV is generated randomly per IG C.H, and the Initialization Vector (IV) is a minimum of 96 bits. In the event module power is lost and restored, the consuming application

must ensure that any of its AES-GCM keys used for encryption or decryption are re-distributed.

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility N/A N/A N/A N/A N/A N/A N/A

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility N/A N/A N/A N/A

20 RSA key transport using PKCS#1 1.5 padding is deprecated through 2023 and disallowed after 2023.

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A

FIPS 140-3 Security Policy 9.1 Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility The module’s use of Non-Deterministic Random Number Generators is determined by the settings described in Section 6.1. Table 13. Non-Deterministic Random Number Generation Specification

CASTs are performed prior to the first use of services related to the test target. CASTs also run periodically on service invocation. Initial CAST self–tests are available on demand by power cycling the module and then invoking the service related to the test target.

Each time the module is powered up, it performs the pre-operational self-tests to confirm that sensitive data have not been damaged. The pre-operational tests include the Software Integrity test, which verifies the module using HMAC-SHA2-256, and the HMAC and SHS Conditional Cryptographic Algorithm SelfTests (CAST) which are run prior to the Software Integrity test to ensure the correctness of the HMAC used. Pre-operational self–tests are available on demand by power cycling the module.

The module performs conditional self-tests when the conditions specified for cryptographic algorithm self-test and pair-wise consistency tests occur. Below are the self-tests implemented: Conditional Cryptographic Algorithm Self-Tests:

• AES-ECB Encryption KAT (128 bits)
• AES-ECB Decryption KAT (128 bits)
• AES-CCM Encryption KAT (128 bits)
• AES-CCM Decryption KAT (128 bits)
• AES-CMAC Generation KAT (128 bits)
• AES-CMAC Verification KAT (128 bits)
• KAS-ECC Primitive “Z” Computation KAT (P-256, B-233)
• KAS-FFC Primitive “Z” Computation KAT (ffdhe2048)
• HASH_DRBG SHA2-256 KAT (Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP800-90Arev1)
• HMAC-DRBG HMAC-SHA2-256 KAT (Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP800-90Arev1)

FIPS 140-3 Security Policy

• Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility CTR_DRBG AES-CTR 256 bits KAT (Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP800-90Arev1) DSA Signature Generation KAT (2048 bits) DSA Signature Verification KAT (2048 bits) ECDSA Signature Generation KAT (P-256) ECSDA Signature Verification KAT (P-256) AES-GCM Encrypt KAT (128 bits) AES-GCM Decrypt KAT (128 bits) HMAC-SHA2-256 KAT HMAC-SHA2-512 KAT HMAC-SHA3-256 KAT KDA OneStep KAT KDA TwoStep KAT KBKDF KAT (Counter, Feedback, Double Pipeline) PBKDF KAT (HMAC-SHA2-256) SHA-3 KAT (cSHAKE-128) RSA Signature Generation KAT (2048 bits) RSA Signature Verification KAT (2048 bits) RSA Encryption KAT SP800-56Brev2 (2048 bits) RSA Decryption KAT SP800-56Brev2 (2048 bits) SHA-1 KAT SHA2-256 KAT SHA2-512 KAT SHAKE256 KAT ANS 9.63 KDF KAT IKEv2 KDF KAT SNMP KDF KAT SRTP KDF KAT SSH KDF KAT TLS 1.0 KDF KAT TLS 1.1 KDF KAT TLS 1.2 KDF KAT

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Conditional Pair-wise Consistency Tests:

• DH pair-wise consistency test
• DSA pair-wise consistency test
• EC DH pair-wise consistency test
• ECDSA pair-wise consistency test
• RSA pair-wise consistency test

If any of the above-mentioned self-tests fail, the module enters an error state called “Hard Error” state. Upon entering the error state, the module outputs status by way of an exception. An example exception for AES Encryption failure is mentioned below: “Failed self-test on encryption: AES” The module can be recovered by power cycling the module which results in execution of preoperational self-tests and conditional cryptographic algorithm self-tests. If the tests pass, then the module will be available for use.

Vulnerabilities found in the module will be reported on the National Vulnerability Database, located at https://nvd.nist.gov/. Researchers and users are encouraged to report any security related concerns to feedbackcrypto@bouncycastle.org. A PGP public key can be provided if confidentiality is required around the report. Please find the procedures for secure installation, initialization, startup and operation of the module: The module exists as part of the running JVM as such:

• Secure installation of the module requires the use of the unchanged jar to loaded into a JVM via either the class-path or the module-path as appropriate to the JVM and its usage.
• Initialization of the module will occur on startup of the module by the JVM. The user can trigger initialization by attempting to invoke any service in the module or simply calling FipsStatus.isReady() which will only return true if the module has been successfully initialized.
• Once the JVM has loaded the module and the module has been initialized, the startup phase can be over, and the module is able to provide services.
• Operation of the module consists of calling the various APIs providing services, the module code will make use of the current thread for doing any required CASTs and health tests and then provide a service object to the user capable of performing the requested service. BC-FJA 2.0.0 User guide can be downloaded here: https://downloads.bouncycastle.org/fipsjava/BC-FJA-UserGuide-2.0.0.pdf

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility

The module implements basic protections to mitigate against timing-based attacks against its internal implementations. There are two countermeasures used. The first is Constant Time Comparisons, which protect the digest and integrity algorithms by strictly avoiding “fast fail” comparison of MACs, signatures, and digests so the time taken to compare a MAC, signature, or digest is constant regardless of whether the comparison passes or fails. The second is made up of Numeric Blinding and decryption/signing verification which both protect the RSA algorithm. Numeric Blinding prevents timing attacks against RSA decryption and signing by providing a random input into the operation which is subsequently eliminated when the result is produced. The random input makes it impossible for a third party observing the private key operation to attempt a timing attack on the operation as they do not have knowledge of the random input and consequently the time taken for the operation tells them nothing about the private value of the RSA key. Decryption/signing verification is carried out by calculating a primitive encryption or signature verification operation after a corresponding decryption or signing operation before the result of the decryption or signing operation is returned. The purpose of this is to protect against Lenstra's CRT attack by verifying the correctness of the private key calculations involved. Lenstra's CRT attack takes advantage of undetected errors in the use of RSA private keys with CRT values and, if exploitable, can be used to discover the private value of the RSA key.

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility Appendix: References and Definitions The following standards are referred to in this Security Policy: ANSI X9.31 FIPS 140-3 FIPS 180-4 FIPS 186-3 FIPS 186-4 FIPS 197 FIPS 198-1 FIPS 202 IG PKCS#1 v2.1 PKCS#5 PKCS#12 SP 800-38A SP 800-38B SP 800-38C SP 800-38D SP 800-38F SP 800-38G SP 800-56A-rev3 SP 800-56B-rev2 SP 800-56C-rev2 SP 800-67-rev2 SP 800-89 SP 800-90A SP 800-90B SP 800-108-rev1 SP 800-132 SP 800-133-rev2 SP 800-135-rev1 X9.31-1998, Digital Signatures using Reversible Public Key Cryptography for the Financial Services Industry (rDSA), September 9, 1998 Security Requirements for Cryptographic modules, March 22, 2019 Secure Hash Standard (SHS) Digital Signature Standard (DSS) Digital Signature Standard (DSS) Advanced Encryption Standard The Keyed-Hash Message Authentication Code (HMAC) SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program RSA Cryptography Standard Password-Based Cryptography Standard Personal Information Exchange Syntax Standard Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography Recommendation for Key Derivation through Extraction-then-Expansion Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher Recommendation for Obtaining Assurances for Digital Signature Applications Recommendation for Random Number Generation Using Deterministic Random Bit Generators Recommendation for the Entropy Sources Used for Random Bit Generation Recommendation for Key Derivation Using Pseudorandom Functions Recommendation for Password-Based Key Derivation Recommendation for Cryptographic Key Generation Recommendation for Existing Application

• Specific Key Derivation Functions

FIPS 140-3 Security Policy Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility The following are acronyms used in this Security Policy: AES API BC BC-FJA CBC CCM CDH CFB CMAC CMVP CO CPU CS CSP CTR CVL DES DH DRAM DRBG DSA DSTU4145 EC ECB ECC ECDSA EdDSA EMC EMI FIPS GCM GMAC GOST Advanced Encryption Standard Application Programming Interface Bouncy Castle Bouncy Castle FIPS Java API Cipher-Block Chaining Counter with CBC-MAC Computational Diffie-Hellman Cipher Feedback Mode Cipher-based Message Authentication Code Crypto Module Validation Program Cryptographic Officer Central Processing Unit Ciphertext Stealing Critical Security Parameter Counter-mode Component Validation List Data Encryption Standard Diffie-Hellman Dynamic Random Access Memory Deterministic Random Bit Generator Digital Signature Authority Ukrainian DSTU-4145-2002 Elliptic Curve Scheme Elliptic Curve Electronic Code Book Elliptic Curve Cryptography Elliptic Curve Digital Signature Authority Edwards Curve DSA using Ed25519, Ed448 Electromagnetic Compatibility Electromagnetic Interference Federal Information Processing Standards Galois/Counter Mode Galois Message Authentication Code Gosudarstvennyi Standard Soyuza SSR/Government Standard of the Union of Soviet Socialist Republics

FIPS 140-3 Security Policy GPC HMAC IG JAR JCA JCE JDK JRE JVM IV KAS KAT KDF KW KWP KMAC MAC MD5 N/A OCB OFB OS PBKDF PKCS PQG RC RIPEMD RSA SHA SSP TCBC TCFB TDEA TDES Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility General Purpose Computer key-Hashed Message Authentication Code See References Java ARchive Java Cryptography Architecture Java Cryptography Extension Java Development Kit Java Runtime Environment Java Virtual Machine Initialization Vector Key Agreement Scheme Known Answer Test Key Derivation Function Key Wrap Key Wrap with Padding KECCAK Message Authentication Code Message Authentication Code Message Digest algorithm MD5 Non Applicable Offset Codebook Mode Output Feedback Operating System Password-Based Key Derivation Function Public Key Cryptography Standards Diffie-Hellman Parameters P, Q and G Rivest Cipher, Ron’s Code RACE Integrity Primitives Evaluation Message Digest Rivest Shamir Adleman Secure Hash Algorithm Sensitive Security Parameter TDEA Cipher-Block Chaining TDEA Cipher Feedback Mode Triple Data Encryption Algorithm Triple Data Encryption Standard

FIPS 140-3 Security Policy TECB TOFB TLS USB XDH XOF Keysight BC-FJA (Bouncy Castle FIPS Java API) for Network Visibility TDEA Electronic Codebook TDEA Output Feedback Transport Layer Security Universal Serial Bus Edwards Curve Diffie-Hellman using X25519, X448 Extendable-Output Function

Referenced URLs

• https://nvd.nist.gov/
• https://downloads.bouncycastle.org/fipsjava/BC-FJA-UserGuide-2.0.0.pdf