Riverbed Cryptographic Module

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Riverbed Cryptographic 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>Self-Test<br/>UnAuth<br/>Unauthenticated</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>library named: openssl</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."]
    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 Riverbed Cryptographic 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>Self-Test<br/>UnAuth<br/>Unauthenticated</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>library named: openssl</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,C5,C6 clueLow;

Security Policy, page by page

Riverbed Technology, LLC Riverbed Cryptographic Module Software Version: 2.0.1 FIPS Security Level: 1 Document Version: 0.5 Prepared for: Prepared by: Riverbed Technology, LLC Corsec Security, Inc.

275 Shoreline Drive 12600 Fair Lakes Circle, Suite 210

Redwood City, CA 94065 Fairfax, VA 22033 United States of America United States of America Phone: +1 415.247.8800 Phone: +1 703.267.6050 www.riverbed.com www.corsec.com

Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

This is a non-proprietary Cryptographic Module Security Policy for the Riverbed Cryptographic Module (software version: 2.0.1) from Riverbed Technology, LLC (Riverbed). This Security Policy describes how the Riverbed Cryptographic Module meets the security requirements of Federal Information Processing Standards (FIPS) Publication 140-3, which details the U.S. and Canadian government requirements for cryptographic modules. More information about the FIPS 140-3 standard and validation program is available on the Cryptographic Module Validation Program (CMVP) website, which is maintained by the National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security (CCCS). This document also describes how to run the module in a secure Approved mode of operation. This policy was prepared as part of the Level 1 FIPS 140-3 validation of the module. The Riverbed Cryptographic Module is referred to in this document as Riverbed Crypto Module or the module.

This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-3 cryptographic module security policy. More information is available on the module from the following sources:

• The Riverbed website (www.riverbed.com) contains information on the full line of products from Riverbed.
• The search page on the CMVP website (https://csrc.nist.gov/Projects/cryptographic-module-validationprogram/Validated-Modules/Search) can be used to locate and obtain vendor contact information for technical or sales-related questions about the module.

ISO/IEC 19790 Annex B uses the same section naming convention as ISO/IEC 19790 section 7 - Security requirements. For example, Annex B section B.2.1 is named “General” and B.2.2 is named “Cryptographic module specification,” which is the same as ISO/IEC 19790 section 7.1 and section 7.2, respectively. Therefore, the format of this Security Policy is presented in the same order as indicated in Annex B, starting with “General” and ending with “Mitigation of other attacks.” If sections are not applicable, they have been marked as such in this document.

The Riverbed Cryptographic Module is validated at the FIPS 140-3 section levels shown in the table below. ©2025 Riverbed Technology, LLC

Table 1: Security Levels ©2025 Riverbed Technology, LLC

Since its inception in 2002, Riverbed Technology, LLC has helped the world’s largest organizations maximize the performance of their networks and applications so they can reach the full potential of their IT investments. Riverbed’s products consist of software and hardware focused on network performance monitoring, application performance management, and wide area networks (WANs). The Riverbed Network and Application Performance Platform enables organizations to visualize, optimize, accelerate, and remediate the performance of any network for any application. Only Riverbed addresses performance and visibility holistically with best-in-class WAN optimization, network performance management, application acceleration, and enterprise-grade SD-WAN 1. The Riverbed Cryptographic Module v2.0.1 is a software library providing a C language API 2 for use by Riverbed applications requiring cryptographic functionality. The Riverbed Cryptographic Module offers symmetric encryption/decryption, digital signature generation/verification, hashing, cryptographic key generation, random number generation, message authentication, and key establishment functions to secure data-at-rest/data-inflight and to support secure communications protocols (including TLS 3 1.2/1.3).

The Riverbed Cryptographic Module 2.0.1 is a Software module.

The Riverbed Cryptographic Module has a MultiChipStand embodiment.

The cryptographic boundary is the contiguous perimeter that surrounds all memory-mapped functionality provided by the module when loaded and stored in the host platform’s memory. Figure 2 is a block diagram of the module executing in memory and its interactions with surrounding software components, as well as the module’s cryptographic boundary and Tested Operational Environment’s Physical Perimeter (TOEPP).

1 SD-WAN – Software-Defined Wide Area Network

API – Application Programming Interface

3 TLS – Transport Layer Security

Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Figure 1. Module Block Diagram (with Cryptographic Boundary) The module is entirely contained within the physical perimeter.

(TOEPP) As a software cryptographic module, the TOEPP of the cryptographic module is defined by each host platform on which the module is installed. Figure 2 below illustrates a block diagram of a typical GPC (the black dotted line represents the module’s physical perimeter). Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Hardware                                  Network                            DVD RAM Management                                 Interface HDD Clock                                                                 SCSI/SATA Generator                                                              Controller LEDs/LCD CPU                                                                                      Serial I/O Hub Audio Cache                      PCI/PCIe Slots                                                           USB BIOS Power                   Graphics                                                 PCI/PCIe Interface                 Controller                                                Slots External Power Supply KEY: BIOS – Basic Input/Output System                 PCIe – PCI express CPU – Central Processing Unit                    HDD – Hard Disk Drive SATA – Serial Advanced Technology Attachment     DVD – Digital Video Disc SCSI – Small Computer System Interface           USB – Universal Serial Bus PCI – Peripheral Component Interconnect          RAM – Random Access Memory LED – Light Emitting Diode                       LCD – Liquid Crystal Display Figure 2. GPC Block Diagram

2.2.1 Tested Module Identification – Hardware

This section is only applicable for hardware modules. N/A for this module. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

2.2.2 Tested Module Identification – Software, Firmware, Hybrid

(Executable Code Sets) The table below lists the executable code sets of the module. Table 2: Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets)

2.2.3 Tested Module Identification – Hybrid Disjoint Hardware

This section is only applicable to hybrid modules. N/A for this module.

2.2.4 Tested Operational Environments – Software, Firmware,

Hybrid The module was tested and found to be compliant with FIPS 140-3 requirements on the environments listed in the table below. Table 3: Tested Operational Environments - Software, Firmware, Hybrid The module is designed to utilize the AES-NI extended instruction set when available by the host platform’s CPU for processor algorithm acceleration (PAA) of its AES implementation.

2.2.5 Vendor-Affirmed Operational Environments – Software,

Firmware, Hybrid There are no vendor-affirmed operational environments claimed. N/A for this module.

The module does not exclude any components from the requirements. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

described in the table below. Table 4: Modes List and Description Section 4.3 of this Security Policy lists the services that constitute the Approved mode of operation. Section 4.4 below lists the services that constitute the non-Approved mode. When following the guidance in section 11.3 of this Security Policy, CSPs are not shared between Approved and non-Approved services and modes of operation. The module does not support degraded operation.

The module employs cryptographic algorithm implementations from the following sources:

• Riverbed Cryptographic Module (libcrypto) version 2.0.1 (Cert. A5835)
• Riverbed Cryptographic Module (libssl) version 2.0.1 (Cert. A5836) Validation certificates for each Approved algorithm are listed in the table below. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

The vendor affirms the following cryptographic security methods: Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

• Cryptographic key generation
• In compliance with section 4 of NIST SP 800-133rev2, the module uses its Approved DRBG to generate random values and seeds used for asymmetric key generation. The generated seed is an unmodified output from the DRBG. Table 6: Vendor-Affirmed Algorithms

The table below lists the non-Approved algorithms implemented by the module that are allowed for use in the Approved mode of operation. Table 7: Non-Approved, Allowed Algorithms

The module does not implement any non-Approved algorithms allowed in the Approved mode of operation for which no security is claimed. N/A for this module. ©2025 Riverbed Technology, LLC

The table below lists the non-Approved algorithms that are not allowed for use in the Approved mode of operation. Table 8: Non-Approved, Not Allowed Algorithms

The table below lists the security function implementations for this module. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Table 9: Security Function Implementations

The module supports internal IV generation using its Approved DRBG. The IV is at least 96 bits in length per section

8.2.2 of NIST SP 800‐38D, and the Approved DRBG generates outputs such that the (key, IV) pair collision

probability is less than 2‐32 per section 8 of NIST SP 800‐38D. The module also supports AES GCM encryption used in the context of the TLS protocol versions 1.2 and 1.3. To meet the AES GCM (key/IV) pair uniqueness requirements from NIST SP 800-38D, the module complies with FIPS 140-3 IG C.H as follows:

• For TLS v1.2, the module supports acceptable AES GCM cipher suites from section 3.3.1.1 of NIST SP 80052rev2. The mechanism for IV generation falls into scenario 1 in FIPS 140-3 IG C.H and is compliant with RFC 5288. The 64-bit counter portion of the IV is strictly increasing. The module explicitly ensures that the counter does not exhaust the maximum number of possible values of 264‐1 for a given session key. If this exhaustion condition is observed, the module will return an error indication to the calling application, which will then need to either abort the connection, or trigger a handshake to establish a new encryption key. It is the responsibility of the module operator (i.e., the first party, client, or server) to trigger this handshake when this condition is encountered.
• For TLS v1.3, the module supports acceptable AES GCM cipher suites from section 3.3.1.2 of NIST SP 80052rev2. The protocol’s implementation is contained within the boundary of the module, and the generated IV is only used in the context of the AES GCM encryption executing the provisions of the TLS

The mechanism for IV generation falls into scenario 5 in FIPS 140-3 IG C.H and is compliant with RFC 8446. Each session employs a “per-record nonce”, a 64-bit sequence number (or IV) maintained separately for reading and writing records. Each sequence number is set to 0 at the beginning of a connection and whenever the key is changed (the first record transmitted under a particular traffic key uses sequence number 0), and the appropriate sequence number is incremented by one after reading or writing each record. Because the size of sequence numbers is 64 bits, they should not wrap. If a sequence number needs to wrap, it is the responsibility of the module operator to either re-key with a new key for AES-GCM or terminate the connection. In case the module’s power is lost and then restored, the calling application is responsible for ensuring that a new key for use with the AES-GCM encryption/decryption shall be established. This condition is not enforced by the Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

module but is met implicitly. The module does not retain any state across resets or power‐cycles, and AES‐GCM key/IVs are not stored in non‐volatile persistent memory (i.e., disk). Hence, no reconnection can occur without a fresh key establishment operation and the associated SSPs. When a GCM IV is used for decryption, the responsibility for the IV generation lies with the party that performs the AES GCM encryption.

The length of a single data unit encrypted or decrypted with the AES-XTS shall not exceed 2²⁰ AES blocks; that is,

16 MB of data per AES-XTS instance. An XTS instance is defined in section 4 of NIST SP 800-38E.

In compliance with FIPS 140-3 IG C.I, the module implements a check to ensure that the two AES keys used in the XTS-AES algorithm are not identical. As specified in NIST SP 800-132, AES-XTS mode shall only be used for the cryptographic protection of data on storage devices. The AES-XTS shall not be used for other purposes, such as the encryption of data in transit.

The module uses PBKDF2 option 1a from section 5.4 of NIST SP 800-132. The iteration count shall be selected as large as possible, as long as the time required to generate the resultant key is acceptable for module operators. The minimum iteration count shall be 1000. The length of the password/passphrase used in the PBKDF shall be of at least 20 characters, and shall consist of lower-case, upper-case, and numeric characters. The upper bound for the probability of guessing the value is estimated to be 1/6220 = 10-36, which is less than 2-112. As specified in NIST SP 800-132, keys derived from passwords/passphrases may only be used in storage applications.

The cryptographic module invokes a GET command to obtain entropy for random number generation (the module requests 256 bits of entropy from the calling application per request), and then passively receives entropy from the calling application while having no knowledge of the entropy source and exercising no control over the amount or the quality of the obtained entropy. The calling application and its entropy sources are located within the operational environment inside the module’s physical perimeter but outside the cryptographic boundary. Thus, there is no assurance of the minimum strength of the generated keys.

The cryptographic module uses its counter-based DRBG to generate seeds used for asymmetric key generation. The generated seed is an unmodified output from the DRBG. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

The cryptographic module provides the cryptographic primitives necessary to support key agreement schemes and key transport methods utilized by the calling application to establish keys.

The module implements the following Approved key agreement schemes (as specified in FIPS 140‐3 IG D.F Scenario 2, path 1) which have been CAVP tested and validated:

• KAS‐ECC‐SSC
• KAS‐FFC‐SSC The module performs assurances for its key agreement schemes as specified in the following sections of NIST SP 800-56Arev3:
• Section 5.5.2 (for assurances of domain parameter validity)
• Section 5.6.2.1 (for assurances required by the key pair owner) The module includes the capability to provide the required recipient assurance of ephemeral public key validity specified in section 5.6.2.2.2 of NIST SP 800-56Arev3. However, since public keys from other modules are not received directly by this module (those keys are received by the calling application), the module has no knowledge of when a public key is received. Invocation of the proper module services to validate another module’s public key is the responsibility of the calling application. Key confirmation is not supported by the module. These methods are not used to establish keys into the module.

The module implements the following Approved/allowed key transport methods (as specified in FIPS 140‐3 IG D.G) which have been CAVP tested and validated: •    AES + MAC wrap/unwrap •    AES-CCM wrap/unwrap •    AES-GCM wrap/unwrap •    AES-KW wrap/unwrap •    AES-KWP wrap/unwrap •    AES unwrap (legacy) •    TDES unwrap (legacy) •    TDES + MAC unwrap (legacy) These methods are not used to establish keys into the module. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

The module supports the following industry protocols in the Approved mode of operation:

• TLS 1.2 (per RFC 7627)
• TLS 1.3 The KDFs associated with these protocols shall only be used within the context of their respective protocols. No parts of these protocols, other than the Approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP.

Algorithms designated as “legacy” can only be used on data that was generated prior to the Legacy Date specified in FIPS 140-3 IG C.M. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

The module supports the following four logical interfaces: As a software library, the cryptographic module has no direct access to any of the host platform’s physical ports, as it communicates only to the calling application via its well-defined API. A mapping of the FIPS-defined interface to the module’s physical ports and logical interfaces can be found in the table below. Note that the module does Table 10: Ports and Interfaces Data output via the data output interface is inhibited when the module is performing pre-operational and conditional tests, zeroization, or when the module is in the error state. ©2025 Riverbed Technology, LLC

4. Roles, Services, and Authentication The module does not support authentication methods; operators implicitly assume an authorized role based on the service selected. N/A for this module.

The table below lists the supported roles. Table 11: Roles The module does not support multiple concurrent operators. The calling application that loaded the module is its only operator.

This module is a software library that provides cryptographic functionality to calling applications. As such, the security functions provided by the module are considered the module’s security services. Indicators for Approved services (in the case of this module, those security functions with algorithm validation certificates and all required self-tests) are provided via API return value. When invoking a security function, the calling application provides inputs via an internal structure, or “context”. Upon each service invocation, the module will determine if the invoked security function is an Approved service. To access the resulting value, the calling application must pass the finalized context to the indicator API associated with that security function (note the indicator check must be performed by the calling application before any context cleanup is performed). The indicator API will return “1” to indicate the usage of an Approved service. Indicators for services providing non-Approved security functions (as well as for services not requiring an indicator) will have a value other than “1”, ensuring that the indicators for Approved services are unambiguous. Additional details on the APIs used for the Approved service indicators are provided in Appendix B below. The keys and Sensitive Security Parameters (SSPs) listed in the table indicate the type of access required using the following notation:

• G = Generate: The module generates or derives the SSP.
• 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.
• E = Execute: The module uses the SSP in performing a cryptographic operation. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

• Z = Zeroize: The module zeroizes the SSP. Descriptions of the services available are provided in the table below. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Zeroize

Zeroize and de- allocate memory containing sensitive data

N/A

Restart calling application; reboot or power-cycle host platform

None

None

Crypto Officer - AES key: Z - AES CCM key : Z - AES GCM key : Z - AES XTS key : Z - AES CMAC key : Z - AES GMAC key : Z - Triple-DES key : Z - Triple-DES CMAC key : Z - HMAC key : Z - DSA public key : Z - ECDSA private key : Z - ECDSA public key : Z - RSA private key : Z - RSA public key : Z - DH private component : Z - DH public component : Z - ECDH private component : Z - ECDH public component : Z - Passphrase: Z - AES GCM IV: Z - TLS pre- master secret: Z - TLS master secret: Z - DRBG entropy input: Z

Z Z Z Z Z Z Z Z Z Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Z Z W,E G,E Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

G W,E Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

W,E W,E G,R W,E G,R Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

The table below lists the non-Approved services available to module operators. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Table 13: Non-Approved Services

The module does not provide the capability to load software from external sources. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

All software components within the cryptographic boundary are verified using an Approved integrity technique implemented within the cryptographic module itself. The module implements independent HMAC SHA2-256 digest checks to test the integrity of each library file; failure of the integrity test for either library file will cause the module to enter a critical error state. The module’s integrity check is performed automatically at module instantiation (i.e., when the module is loaded into memory for execution) without action from the module operator.

The CO can initiate the pre-operational tests on demand by re-instantiating the module or issuing the FIPS_selftest() API command. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

The module is a software cryptographic library that executes in a Non-Modifiable operational environment. The cryptographic module has control over its own SSPs. The process and memory management functionality of the host platform’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 environment provides 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/operators. Please refer to section 2.1 of this document for a list/description of the applicable operational environments. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

7. Physical Security This section is not applicable. Per section 7.7.1 of ISO/IEC 19790:2012, the requirements of this section are “applicable to hardware and firmware modules, and hardware and firmware components of hybrid modules”. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

8. Non-Invasive Security This section is not applicable. There are currently no approved non-invasive mitigation techniques references in Annex F of ISO/IEC 19790. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

9. Sensitive Security Parameters Management

There are no mechanisms within the module’s cryptographic boundary for the persistent storage of SSPs. SSPs are stored in volatile RAM during module operation. The table below lists the storage areas used by the module. Table 14: Storage Areas The module stores DRBG state values for the lifetime of the DRBG instance. The module uses SSPs passed in on the stack by the calling application and does not store these SSPs beyond the lifetime of the API call.

The table below lists input and output methods for the module’s SSPs. Section 9.4 below selects from the input and output methods listed and specifies the appropriate method(s) in the “Inputs - Outputs” column applicable to each SSP. Table 15: SSP Input-Output Methods

The table below lists SSP zeroization methods available to module operators. Section 9.4 below selects from the zeroization methods listed and specifies the appropriate method(s) in the “Zeroization” column applicable to each SSP. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Table 16: SSP Zeroization Methods At the end of each applicable function call, temporary SSPs in memory are automatically overwritten with zeroes and the space is deallocated. Maintenance of any keys and CSPs that exist outside the module’s cryptographic boundary, including protection and zeroization, are the responsibility of the module operator. The module supports the keys and other SSPs listed in the table below. All SSP imports and exports are electronic and performed within the TOEPP. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

N/A N/A Table 17: SSP Table 1 Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Table 18: SSP Table 2 Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

The module performs the pre-operational self-tests listed in the following table. Table 19: Pre-Operational Self-Tests

The module performs the conditional self-tests listed in the following table. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Table 20: Conditional Self-Tests

The table below specifies the module’s periodic self-test information. Table 21: Pre-Operational Periodic Information Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Table 22: Conditional Periodic Information The CO can initiate the pre-operational self-tests and conditional CASTs on demand for periodic testing of the module by re-instantiating the module or issuing the FIPS_selftest() API command.

The table below specifies the module’s error state information. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

The Riverbed Cryptographic Module is not delivered to end-users as a standalone offering. Rather, it is a pre-built integrated component of Riverbed’s application software, and these applications are the sole consumers of the cryptographic services provided by the module. The module and its calling application are delivered pre-installed on one of the Riverbed platforms specified in section 6 above or one where portability is maintained. Riverbed does not provide end-users with any mechanisms to directly access the module, its source code, its APIs, or any information sent to/from the module. The module’s integrity check is performed automatically at module instantiation (i.e., when the module is loaded into memory for execution) without action from the module operator, and end-users have no ability to bypass the automatic integrity check. No setup steps are required to be performed by end-users.

There are no specific management activities required of the CO role to ensure that the module runs securely. If any irregular activity is observed, or if the module is consistently reporting errors, then Riverbed Customer Support should be contacted. The following list provides additional guidance for the CO:

• The fips_post_status() API can be used to determine the module’s operational status. A non-zero return value indicates that the module has passed all pre-operational self-tests and is currently in its Approved mode.
• The OpenSSL_version() API can be used to obtain the module’s versioning information. This information will include the module name and version, which can be correlated with the module’s validation record.

The following list provides additional policies for the User role: • The cryptographic module’s services are designed to be provided to a calling application. Excluding the use of the NIST-defined elliptic curves as trusted third-party domain parameters, all other assurances from FIPS PUB 186-5 (including those required of the intended signatory and the signature verifier) are outside the scope of the module and are the responsibility of the calling application. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

• The calling application is responsible for ensuring that CSPs are not shared between Approved and nonApproved services and modes of operation.
• The calling application is responsible for using entropy sources that meet the minimum security strength of 112 bits required for the CTR_DRBG as shown in NIST SP 800-90Arev1, Table 3. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

12. Mitigation of Other Attacks This section is not applicable. The module does not claim to mitigate any attacks beyond the FIPS 140-3 Level 1 requirements for this validation. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Appendix A. Acronyms and Abbreviations Table 24 provides definitions for the acronyms and abbreviations used in this document. Table 24. Acronyms and Abbreviations ©2025 Riverbed Technology, LLC

Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Appendix B. Approved Service Indicators This appendix specifies the APIs that are externally accessible and return the Approved service indicators. Synopsis #include <openssl/service_indicator.h> #include <openssl/ssl.h> int EVP_cipher_get_service_indicator(EVP_CIPHER_CTX *ctx); int DSA_get_service_indicator(DSA * ptr_dsa, DSA_MODES_t mode); int RSA_key_get_service_indicator(RSA * ptr_rsa); int PBKDF_get_service_indicator(); int EVP_Digest_get_service_indicator(EVP_MD_CTX *ctx); int EC_key_get_service_indicator(EC_KEY *ec_key); int CMAC_get_service_indicator(CMAC_CTX *cmac_ctx, CMAC_MODE_t mode); int HMAC_get_service_indicator(HMAC_CTX *ctx); int TLSKDF_get_service_indicator(EVP_PKEY_CTX *tls_ctx); int TLS1_3_kdf_get_service_indicator(EVP_MD *md); int TLS1_3_get_service_indicator(SSL *s); int DRBG_get_service_indicator(RAND_DRBG *drbg); Description These APIs are high-level interfaces that return the Approved service indicator value based on the parameter(s) passed to them.

• EVP_cipher_get_service_indicator() is used to return the appropriate Approved service indicator status for block ciphers like AES and Triple DES.
• DSA_get_service_indicator() is used to return the appropriate Approved service indicator status for the DSA algorithm and its modes. You must include the mode you want the indicator for, which are specified in the DSA_MODES_t enum.
• RSA_key_get_service_indicator() is used to return the appropriate Approved service indicator status for RSA algorithm and its modes.
• PBKDF_get_service_indicator() is used to return the appropriate Approved service indicator status for PBKDF usage.
• EVP_Digest_get_service_indicator() is used to return the appropriate Approved service indicator status for SHS algorithms like SHA-1 and SHAKE.
• EC_key_get_service_indicator() is used to return the appropriate Approved service indicator status for elliptic curve algorithms like ECDSA and its modes. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

• CMAC_get_service_indicator() is used to return the appropriate Approved service indicator status for CMAC requests that use AES or Triple DES. You must include the mode you want the indicator for, which are specified in the CMAC_MODE_t enum.
• HMAC_get_service_indicator() is used to return the appropriate Approved service indicator status for HMAC requests and the associated SHS algorithm.
• TLSKDF_get_service_indicator() is used to return the appropriate Approved service indicator status for TLS KDF usage excluding TLS 1.3.
• TLS1_3_kdf_get_service_indicator() is used to return the appropriate Approved service indicator status for TLS 1.3 KDF usage. This function requires the ssl.h file and is used to call the TLS1_3_get_service_indicator() function because of the SSL struct requirement. You cannot call TLS1_3_get_service_indicator() directly unless you have the SSL struct that was used.
• DRBG_get_service_indicator() is used to return the appropriate Approved service indicator status for DRBG usage. Riverbed Cryptographic Module 2.0.1 ©2025 Riverbed Technology, LLC

Prepared by: Corsec Security, Inc.

12600 Fair Lakes Circle, Suite 210

Fairfax, VA 22033 United States of America Phone: +1 703 267 6050 Email: info@corsec.com http://www.corsec.com