Copyright © 2021 Riverbed
This non-proprietary Security Policy document may be freely reproduced anddistributedin its entirety without modification.
Riverbed Cryptographic Module v1.1
FIPS 140-2 Non-Proprietary Security Policy
Document Version1.0
November 9, 2021
Prepared for: Prepared by:
Riverbed
680 Folsom Street
San Francisco, CA 94107
riverbed.com
Corsec Security, Inc.
13921 Park Center Rd., Ste. 460
Herndon, VA 20171
corsec.com
+1 703.276.6050
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 2 of 16
References
Reference FullSpecification Name
[ANS X9.31] Digital Signatures UsingReversiblePublicKey Cryptographyforthe Financial Services
Industry (rDSA)
[FIPS 140-2] Security RequirementsforCryptographicModules,May 25,2001
[FIPS 180-4] SecureHash Standard (SHS)
[FIPS 186-2] Digital SignatureStandard (DSS)[withdrawn]
[FIPS 186-4] Digital SignatureStandard (DSS)
[FIPS 197] Advanced EncryptionStandard (AES)
[FIPS 198-1] TheKeyed-Hash MessageAuthenticationCode(HMAC)
[IG] Implementation GuidanceforFIPS 140-2 and theCryptographicModuleValidationProgram
[SP 800-38A] RecommendationforBlock CipherModesof Operation:MethodsandTechniques
[SP 800-38B] RecommendationforBlock CipherModesof Operation:TheCMACModefor Authentication
[SP 800-38C] RecommendationforBlock CipherModesof Operation:TheCCMModeforAuthentication
and Confidentiality
[SP 800-38D] RecommendationforBlock CipherModesof Operation:Galois/CounterMode(GCM)and
GMAC
[SP 800-38E] RecommendationforBlock CipherModesof Operation:theXTS-AES ModeforConfidentiality
on StorageDevices
[SP 800-56Ar1] RecommendationforPair-WiseKey-EstablishmentSchemesUsing DiscreteLogarithm
Cryptography
[SP 800-56Ar3] RecommendationforPair-WiseKey-EstablishmentSchemesUsing DiscreteLogarithm
Cryptography
[SP 800-57r5] RecommendationforKey Management: Part1 - General
[SP 800-67r2] RecommendationfortheTripleData Encryption Algorithm(TDEA) BlockCipher
[SP 800-89] RecommendationforObtaining AssurancesforDigital SignatureApplications
[SP 800-90Ar1] RecommendationforRandomNumberGenerationUsing DeterministicRandomBit
Generators
[SP 800-131Ar2] Transitioning theUseof CryptographicAlgorithmsandKey Lengths
[SP 800-133r2] RecommendationforCryptographicKey Generation
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 3 of 16
Table of Contents
References ............................................................................................................................... 2
1 Introduction ...................................................................................................................... 4
2 Ports and Interfaces............................................................................................................ 5
3 Modes ofOperation and Cryptographic Functionality............................................................. 6
3.1 Approved Mode ............................................................................................................ 6
3.2 Non-Approved but Allowed Services ................................................................................ 7
3.3 Non-Approved Services.................................................................................................. 7
3.4 Critical Security Parameters and Public Keys...................................................................... 8
4 Roles, Authentication and Services......................................................................................10
5 Self-Tests..........................................................................................................................12
6 Operational Environment...................................................................................................13
7 Mitigation of other Attacks.................................................................................................14
Appendix A - Installation and Usage Guidance.............................................................................15
Appendix B - Controlled Distribution ..........................................................................................16
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 4 of 16
1 Introduction
This document is the non-proprietary security policy for the Riverbed Cryptographic Module v1.1,
hereafter referredto as the Module.
The Module is a software library providing a C language application program interface (API) for use by
other processes that require cryptographic functionality. The Module is classified by FIPS 140-2 as a
softwaremodule, multi-chip standalonemodule embodiment. The physicalcryptographicboundary is the
general-purpose computer on which the module is installed. The logical cryptographic boundary of the
Module is the fipscanister object module, a single object module file named fipscanister.o. The Module
performs no communications other thanwiththecalling application(the process that invokes theModule
services).
The current version of the Module is 1.1.
The FIPS 140-2 security levels for theModule areas follows:
Table 1: Security Level of Security Requirements
SecurityRequirement SecurityLevel
CryptographicModuleSpecification 1
CryptographicModulePortsand Interfaces 1
Roles,Services,and Authentication 2
Finite State Model 1
Physical Security NA
OperationalEnvironment 1
CryptographicKeyManagement 1
EMI/EMC 1
Self-Tests 1
Design Assurance 3
Mitigation ofOther Attacks NA
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 5 of 16
Figure 1: Module Block Diagram
2 Ports and Interfaces
Thephysicalports of theModule arethesameas thecomputer systemonwhichit is executing. Thelogical
interfaceis a C languageapplication programinterface(API).
Table 2: Logical Interfaces
Logicalinterface type Description
Controlinput APIentry pointand correspondingstack parameters
Datainput APIentry pointdatainputstack parameters
Statusoutput APIentry pointreturnvaluesand statusstack parameters
Dataoutput APIentry pointdataoutputstack parameters
As a software module, control of the physical ports is outside module scope; however, when the module
is performing self-tests, oris in an errorstate, all output on the logical data output interface is inhibited.
The module is single-threaded and in error scenarios returns only an error value (no data output is
returned).
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 6 of 16
3 Modes of Operation and CryptographicFunctionality
TheModule supports FIPS140-2 Approved, Allowed and Non-Approved algorithms ina singlemixedmode
of operation.
3.1 Approved Mode
The Module supports thefollowing services and algorithms in FIPS Approved mode:
Table 3: FIPS Approved Cryptographic Functions
Function Algorithm Options Cert. #
Random Number
Generation;
SymmetricKey
Generation
[SP 800-90Ar1] DRBG1
Prediction resistance
supported for all
variations
Hash_Based DRBG:All SHA sizes
HMAC_Based DRBG:All SHA sizes
CTR_DRBG: AES-128,AES-192,AES-256 (with and without
derivation function)
C1318
A2089
CryptographicKey
Generation (CKG)
[SP 800-133r2] CKG Vendor
affirmed
Encryption,
Decryption and
CMAC
[SP 800-67r2] Triple-DES
[SP 800-38B] CMAC
TECB, TCBC,TCFB,TOFB: 3-Key
CMAC generate and verify:3-Key
C1318
A2089
[FIPS 197] AES
[SP 800-38B] CMAC
[SP 800-38C] CCM
[SP 800-38D] GCM
[SP 800-38E] XTS
ECB, CBC,OFB,CFB,CTR: 128/192/256
CMAC generate and verify:128/192/256
CCM: 128/192/256
GCM: 128/192/256
XTS: 128/256
C1318
A2089
Message Digests [FIPS 180-4] SHA SHA-1,SHA-2 (224,256,384,512) C1318
A2089
Keyed Hash [FIPS 198] HMAC SHA-1,SHA-2 (224,256,384,512) C1318
A2089
DigitalSignature
and Asymmetric
KeyGeneration
[FIPS 186-2] RSA SigGen9.31,SigGenPKCS1.5,SigGenPSS:4096with all
SHA-2 sizes
SigVer9.31,SigVerPKCS1.5,SigVerPSS:1024/1536/2048/
3072/4096 with all SHA sizes
C1318
[FIPS 186-2] RSA SigVer9.31,SigVerPKCS1.5,SigVerPSS:1024/1536/2048/
3072/4096 with all SHA sizes
A2089
[FIPS 186-4] RSA KeyGen:2048/3072
SigGen9.31,SigGenPKCS1.5,SigGenPSS:2048/3072with all
SHA-2 sizes
C1318
[FIPS 186-4] RSA KeyGen:2048/3072
SigGen9.31,SigGenPKCS1.5,SigGenPSS:2048/3072/4096
with all SHA-2 sizes
A2089
[FIPS 186-4] DSA KeyPairGen:2048/3072
PQGGen,SigGen:2048/3072with all SHA-2 sizes
PQGVer,SigVer:1024/2048/3072with all SHA sizes
C1318
A2089
[FIPS 186-4] ECDSA PKG: P-224,P-256,P-384,P-521,K-233,K-283,K-409,
K-571,B-233,B-283,B-409,B-571;ExtraRandomBits,
TestingCandidates
PKV: All NISTdefined B,K and P curves
SigGen: P-224,P-256,P-384,P-521,K-233,K-283,K-409,
K-571,B-233,B-283,B-409,B-571;all SHA-2sizes
SigVer: All NISTdefined B,K and P curves;all SHA sizes
C1318
A2089
1 For all DRBGs the "supported security strengths"is just the highest supported security strength per [SP 800 -90Ar1]and [SP 800-
57r5].
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 7 of 16
Function Algorithm Options Cert. #
KAS-SSC [X1]2
[SP 800-56Ar3] Diffie-Hellman≥ 2048 bits
ECDHB, K,and P curves≥ 256-bitcurves
Vendor
affirmed
3.2 Non-Approved but Allowed Services
The Module supports thefollowing non-Approved but allowed services:
Table 4: Non-FIPS Approved but Allowed Cryptographic Functions
Category Algorithm Description
KeyEncryption/
Decryption
RSA RSA may be used to performkey establishmentwith anothermoduleby securely
exchangingsymmetric encryptionkeyswith anothermodule.
The module supports the following non-FIPS 140-2 approved but allowed algorithms:
● RSA (key wrapping; key establishment methodology provides between 112 and 256 bits of
encryption strength; non-compliant less than 112 bits of encryption strength)
3.3 Non-Approved Services
The Module implements the following services which are non-approved per the [SP 800-131Ar2]
transition:
Table 5: Non-FIPS Approved Cryptographic Functions
Function Algorithm Options
DigitalSignature
and Asymmetric
KeyGeneration
[FIPS 186-2] RSA GenKey9.31,SigGen9.31,SigGenPKCS1.5, SigGenPSS (1024/1536with all
SHA sizes,2048/3072/4096with SHA-1)
[FIPS 186-2] DSA PQGGen,KeyPairGen,SigGen(1024with all SHA sizes,2048/3072 with
SHA-1)
[FIPS 186-4] DSA PQGGen,KeyPairGen,SigGen(1024with all SHA sizes,2048/3072 with
SHA-1)
[FIPS 186-2] ECDSA PKG: P-192,K-163,B-163
SigGen: P-192,P-224,P-256,P-384,P-521,K-163,K-233,K-283,K-409,K-
571,B-163,B-233,B-283,B-409,B-571
[FIPS 186-4] ECDSA PKG: P-192,K-163,B-163
SigGen: P-192,K-163,B-163with all SHA sizes; P-224,P-256,P-384,P-521,
K-233,K-283,K-409,K-571,B-233,B-283,B-409,B-571with SHA-1
ECC CDH(KAS) [SP 800-56Ar1]
(§5.7.1.2)
P-192,K-163,B-163
These algorithms shall not be used when operating in the FIPS Approved mode of operation. Use of the
non-conformant algorithms listedin Table 5 will placethe module in a non-approved mode of operation.
2 In the approved mode, KAS-SSC can only be used in conjunction with an Approved KDF from SP 800-56C or SP 800-135.
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 8 of 16
3.4 Critical Security Parameters and Public Keys
All CSPs used by the Module aredescribed in this section. All access to theseCSPs by Module services is
described in Section 4. The CSP names aregeneric, corresponding to API parameter data structures.
Table 6: Critical Security Parameters
CSP Name Description
RSA SGK RSA (2048 to 15360 bits) signaturegeneration key
RSA KDK RSA (2048 to 16384 bits) keydecryption (privatekey transport) key
DSA SGK [FIPS 186-4] DSA(2048/3072) signature generation key
DH Private Diffie-Hellman> 2048 privatekey agreementkey
ECDSA SGK ECDSA (All NISTdefined B,K,and P curvesexceptsizes163and 192) signaturegeneration
key
EC DHPrivate EC DH(All NISTdefined B,K,and P curvesexceptsizes163 and 192) private keyagreement
key
AESEDK AES (128/192/256) encrypt/ decryptkey
AESCMAC AES (128/192/256) CMACgenerate / verify key
AESGCM3 AES (128/192/256) encrypt/ decrypt/ generate/ verifykey
AESXTS AES (256/512)XTS encrypt/ decryptkey
Triple-DESEDK Triple-DES (3-Key) encrypt/ decryptkey
Triple-DESCMAC Triple-DES (3-Key) CMACgenerate / verify key
HMAC Key Keyed hash key(160/224/256/384/512)
Hash_DRBGCSPs V (440/888 bits) and C (440/888 bits),entropy input(lengthdependenton security strength)
HMAC_DRBGCSPs V (160/224/256/384/512bits) and Key(160/224/256/384/512bits),entropy input(length
dependenton security strength)
CTR_DRBGCSPs V (128 bits) and Key (AES 128/192/256),entropy input(length dependenton security
strength)
CO-AD-Digest Pre-calculated HMAC-SHA-1 digestusedfor Crypto Officerroleauthentication
User-AD-Digest Pre-calculated HMAC-SHA-1 digestusedfor Userroleauthentication
Authentication data is loaded into the module during the module build process, performed by an
authorizedoperator (Crypto Officer), and otherwisecannot be accessed.
The module does not output intermediatekey generationvalues.
Table 7: Public Keys
PublicKeyName Description
RSA SVK RSA (1024 to 16384 bits) signatureverificationpublickey
RSA KEK RSA (2048 to 16384 bits) keyencryption (publickey transport) key
DSA SVK [FIPS 186-4] DSA(2048/3072) signature verification key
ECDSA SVK ECDSA (All NISTdefined B,K and P curves)signatureverification key
DH Public Diffie-Hellmanpublickeyagreementkey
EC DHPublic EC DH(All NISTdefined B,K and P curves) public key agreementkey
3 The Module’s IV is generated internally by the Module’s Approved DRBG. The DRBG seed is generated inside the Module’s
physical boundary. The IV is 96 bits in length per [SP 800-38D]§8.2.2 and [IG] A.5 scenario 2. The selection ofthe IV construction
method is the responsibility of the user of this Module. In Approved mode, users of the Module must not utilize GCM with an
externally generated IV. The only Approved use of GCM is with TLS and with a randomly generated IV.
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 9 of 16
For all CSPs and Public Keys:
Storage: RAM, associated to entities by memory location. The Module stores DRBG statevalues for the
lifetime of theDRBG instance. Themodule uses CSPs passedinby thecalling application on thestack. The
Module does not store any CSP persistently (beyond the lifetime of an API call), with the exception of
DRBG statevalues usedfor the Module’s default key generation service.
Generation: TheModuleimplements SP800-90Acompliant DRBG services forcreationofsymmetrickeys,
and for generation of DSA, elliptic curve, and RSA keys as shown in Table 3. The calling application is
responsiblefor storageofgeneratedkeys returned by the Module. For operation in the Approved mode,
Module users (the calling applications) shalluse entropy sources that containat least 112 bits of entropy.
To ensure full DRBG strength, theentropy sources must meet or exceed the securitystrengths shown in
the tablebelow:
Table 8: DRBG Entropy Requirements
DRBG Type UnderlyingAlgorithm Minimum Seed Entropy
Hash_DRBGor HMAC_DRBG
SHA-1 128
SHA-224 192
SHA-256 256
SHA-384 256
SHA-512 256
CTR DRBG
AES-128 128
AES-192 192
AES-256 256
Entry: AllCSPs enter theModule’s logicalboundary in plaintext as API parameters, associatedbymemory
location; however, none cross the physicalboundary.
Output: The Module does not output CSPs, other than as explicit results of key generation services;
however, none cross the physical boundary.
Destruction:Zeroizationofsensitivedata is performed automaticallyby API function calls for temporarily
stored CSPs. In addition, the module provides functions to explicitly destroy CSPs related to random
number generationservices. Thecalling application is responsiblefor parameters passed into and out of
the module.
Private and secret keys as well as seeds and entropy input are provided to the Module by the calling
application, and are destroyed when released by the appropriate API function calls. Keys residing in
internally allocated data structures (during the lifetime of an API call) can only be accessed using the
Module defined API. Theoperating systemprotects memoryandprocess spacefromunauthorizedaccess.
Only thecalling application that creates orimports keys can useor export such keys. All API functions are
executedby theinvoking calling application in a non-overlapping sequencesuchthat notwo API functions
will executeconcurrently. An authorizedapplicationas user (Crypto-Officer and User)has access toallkey
data generatedduring the operation of the Module.
Use: In thecaseof AES-GCM, theIV generationmethod is user selectableand thevalue can be computed
in more than one manner.
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 10 of 16
Following RFC 5288 for TLS, the module ensures that it's strictlyincreasing andthus cannot repeat. When
the IV exhausts the maximum number of possible values for a given session key, the first party, client or
server, to encounter this condition may either trigger a handshake to establish a new encryption key in
accordancewithRFC 5246, orfail. Ineither case, themoduleprevents andIVduplicationandthus enforces
the securityproperty.
In the event that Module power is lost and restored, the calling application must ensure that any AES-
GCMkeys usedfor encryption or decryption arere-distributed.
The calling application shallensure that the sameTriple-DESkey is not usedto encrypt more than 216 64-
bit blocks of data.
4 Roles, Authentication and Services
The Module implements the required User and CryptoOfficer roles and requires authenticationfor those
roles. Only one role may be active at a time, and the Module does not allow concurrent operators. The
User or Crypto Officer role is assumed by passing the appropriate password to the
FIPS_module_mode_set()function. Thepasswordvalues maybespecifiedat buildtimeandmust have
a minimum lengthof 16 characters. Anyattempt toauthenticatewithaninvalid passwordwillresult in an
immediate and permanent failure condition rendering the Module unable to enter the FIPS mode of
operation, even with subsequent useof a correct password.
Authenticationdata is loaded into the Module during theModule build process, performedby the Crypto
Officer, and otherwisecannot be accessed.
Since the minimum password length is 16 characters, the probability of a random successful
authenticationattempt in one tryis a maximum of 1/25616, or less than1/1038. The Module permanently
disables further authenticationattempts after a singlefailure, sothis probability is independent of time.
Both roles have access toall of theservices provided by theModule.
● User Role (User): Loading theModule and calling any of the API functions.
● Crypto Officer Role (CO): Installationof the Module on the host computer systemand calling of
any API functions.
All services implemented by the Module arelisted below, along with a description of service CSP access.
The access types aredeterminedas follows:
- Generate(G): Generatethe CriticalSecurity Parameter (CSP)using an approved Random Bit Generator
- Read (R): Export the CSP
- Write (W): Enter/establishand storea CSP
- Destroy(D): Overwritethe CSP
- Execute(E): Employ the CSP
- None: No access toCSPs
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 11 of 16
Table 9: Services and CSP Access
Service Role Description Access
Type
Initialize User,CO Module initialization.DoesnotaccessCSPs.
CO-AD-Digest,User-AD-Digest
E
Self-test User,CO Performself-tests(FIPS_selftest). None
Show Status User,CO Functionsthatprovide modulestatusinformation:
● Version (asunsigned longor constchar*)
● FIPS Mode (Boolean)
None
Zeroize User,CO FunctionsthatdestroyCSPs:
● fips_drbg_uninstantiate
DRBGCSPs(Hash_DRBGCSPs,HMAC_DRBGCSPs,CTR_DRBGCSPs)
All other servicesautomatically overwriteCSPsstoredin allocated
memory.Stack cleanup isthe responsibility of the callingapplication.
D
Random
Number
Generation
User,CO Used for randomnumberand symmetrickey generation
● Seed or reseed aDRBGinstance
● Determinesecurity strength of aDRBGinstance
● Obtain randomdata
DRBGCSPs(Hash_DRBGCSPs,HMAC_DRBGCSPs,CTR_DRBGCSPs)
E
AsymmetricKey
Generation
User,CO Used to generate DSA,ECDSA and RSAkeys:
RSA SGK,RSA SVK; DSA SGK,DSA SVK;ECDSA SGK,ECDSASVK
G
Symmetric
Encrypt/
Decrypt
User,CO Used to encryptor decryptdata.
AES EDK,Triple-DES EDK,AES GCM,AES XTS (passed in by the calling
process)
E
Symmetric
Digest
User,CO Used to generate or verify dataintegrity with CMAC.
AES CMAC,Triple-DESCMAC (passedin by the callingprocess)
E
Message Digest User,CO Used to generate aSHA-1or SHA-2messagedigest. None
Keyed Hash User,CO Used to generate or verify dataintegrity with HMAC.
HMAC Key (passedin by the callingprocess)
E
KeyTransport4
User,CO Used to encryptor decryptakey value on behalf of the callingprocess
(doesnotestablish keysinto the module).
RSA KDK,RSA KEK (passed in by the callingprocess)
E
KeyAgreement User,CO Used to performkeyagreementprimitiveson behalf of the callingprocess
(doesnotestablish keysinto the module).
Diffie-Hellman/EC Diffie-HellmanPrivate,Diffie-Hellman/EC Diffie-Hellman
Public (passedin by the callingprocess)
E
DigitalSignature User,CO Used to generate or verify RSA,DSAor ECDSAdigital signatures.
RSA SGK,RSA SVK; DSA SGK,DSA SVK;ECDSA SGK,ECDSASVK (passed in
by the callingprocess)
E
Utility User,CO Miscellaneoushelperfunctions. None
4 "Key transport" can refer to a) moving keys in and out of the module or b) the use ofkeys by an external application. The latter
definition is the one that applies to the Module.
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 12 of 16
5 Self-Tests
The Module performs the self-tests listedbelowon invocation of “initialize” or “self-test”.
Table 10: Power-On Self-Tests (KAT = Known answer test; PCT= Pairwise consistency test)
Algorithm Type Test Attributes
Software integrity KAT HMAC-SHA1
HMAC KAT One KATper SHA-1,SHA-224,SHA-256,SHA-384and SHA-512
Per [IG] 9.3,thistestingcoversSHA POSTrequirements.
AES KAT Separate encryptand decrypt,ECBmode,128-bitkey length
AESCCM KAT Separate encryptand decrypt,192-bitkeylength
AESGCM KAT Separate encryptand decrypt,256-bitkeylength
XTS-AES KAT 128,256-bitkey sizesto supporteither the 256-bitkeysize (forXTS-AES-128) or the
512-bitkey size (forXTS-AES-256)
AESCMAC KAT Generate and verify CBC mode,128,192,256-bitkey lengths
Triple-DES KAT Separate encryptand decrypt,ECBmode,3-Key
Triple-DESCMAC KAT CMAC generate and verify,CBC mode,3-Key
RSA KAT Sign and verify using2048-bitkey,SHA-256,PKCS#1
DSA PCT Sign and verify using2048-bitkey,SHA-384
DRBG KAT CTR_DRBG: AES,256bitswith and withoutderivationfunction
HASH_DRBG:SHA-256
HMAC_DRBG:SHA-256
ECDSA PCT Key gen,sign,verify usingP-224,K-233 andSHA-512
ECC CDH KAT Shared secretcalculationperSP 800-56A§5.7.1.2,[IG] 9.6
The Module is installed using one of the set of instructions in Appendix A, as appropriate for the target
system. The HMAC-SHA-1 of the Module distribution file as tested by the CMT Laboratory and listed in
Appendix A is verified during installation of the Module file as described in Appendix A.
Per [IG]9.10, theModule implements a default entry point andautomaticallyruns theFIPS self-tests upon
startup.
The module has a function called FIPS_module_mode_set() withintheinit code that is automatically
set to enable “FIPS Mode” by default. When the Module is initialized, it will always run its power-on self-
tests, meeting the[IG]9.10 requirement.
The module also has a Boolean check value to verify whether the module has run its power-on self-tests
upon subsequent instantiations. Ifthe module is determined to have already run its power-on self-tests,
future instantiations willonly run thepower-up integritytest andnot thefull set of POSTs. Ifpower is lost
to the module, the Boolean check value “1” is zeroized and the module will run its power-up self-tests
again to verify the correctness of the module operation. Upon successful completion of the POSTs, the
Boolean check value is restored. This is consistent with the requirement described in [IG] 9.11.
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 13 of 16
The Module also implements the following conditional tests:
Table 11: Conditional Tests
Algorithm Test
DRBG Tested asrequiredby [SP 800-90Ar1]Section 11
DRBG FIPS 140-2 continuoustestforstuck fault
NDRNG FIPS 140-2 continuoustestforNDRNG
DSA Pairwise consistencyteston each generation of akey pair
ECDSA Pairwise consistencyteston each generation of akey pair
RSA Pairwise consistencyteston each generation of akey pair
In the event of a DRBG self-test failure, the calling application must uninstantiate and re-instantiate the
DRBG per the requirements of [SP 800-90Ar1]; this is not something theModule can do itself.
Pairwise consistency tests are performed for both possible modes of use, e.g. Sign/Verify and
Encrypt/Decrypt.
6 Operational Environment
The testedoperating systems segregateuser processes intoseparateprocess spaces. Eachprocess space
is logically separated from all other processes by the operating system software and hardware. The
Module functions entirely within the process space of the calling application, and implicitly satisfies the
FIPS 140-2 requirement for a single user mode of operation.
The module was testedin thefollowing configurations.
Table 12: Tested Configurations
#
Module
Version OperatingSystem Processor
Optimizations
(Target) Platform
1 1.1 CentOS 7 Intel Xeon E5-2609 PAA HPEProLiantDL60Gen9
2 1.1 CentOS 7 Intel Xeon E5-2609 None HPEProLiantDL60Gen9
3 1.1 Scientific Linux6 Intel Xeon D-1513N(x86-64) PAA SteelHead CXA580
4 1.1 Scientific Linux6 Intel Xeon D-1513N(x86-64) None SteelHead CXA580
As described in [IG]1.21, ProcessorAlgorithm Acceleration(PAA) describes mathematicalconstructs and
not the complete cryptographic algorithm(as defined in the NIST standards). Examples ofPAA supported
by theModule include AES-NI and NEON.
See Appendix A for additional information on installationand usage.
As allowedby [IG]G.5, Maintainingvalidation compliance of software or firmware cryptographic modules,
the validation status of the Module is maintained when operated in the following additional operating
environments:
• Scientific Linux 6, RIOS 9.12.2(and higher) on x86-64
• Scientific Linux 6, Client AcceleratorController v6.3.1(and higher) on x86-64
• Scientific Linux 6, SteelHeadInterceptorv8.1 (and higher) on x86-64
• Scientific Linux 6, SteelFusion v6.5(and higher) on x86-64
The CMVPmakes no statement as tothecorrect operation of theModule or thesecuritystrengths ofthe
generated keys when the module is ported to an operational environment that is not listed on the
validation certificate.
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 14 of 16
7 Mitigation of other Attacks
The module is not designed to mitigateagainst attackswhichareoutside of thescope of FIPS 140-2.
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 15 of 16
Appendix A - Installation and Usage Guidance
During the manufacturing process, Riverbed executes the build and installation instructions for the
Module. The Module is pre-installed and configured in supported Riverbed solutions. FIPS mode is
enabled by default. There areno additional installation, configuration, orusageinstructions foroperators
intending to use the Module.
FIPS 140-2 Security Policy Riverbed Cryptographic Module v1.1
Page 16 of 16
Appendix B - Controlled Distribution
The Module is distributed as part of the Riverbed solution. It is unavailable as a stand-alonelibrary.