SafeZone FIPS SW Cryptographic Module

Certificate

Approved Algorithms (54)

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

flowchart LR
  %% Deterministic review-risk graph for SafeZone FIPS SW 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>firmware load</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>status output<br/>self-test</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>IKEV<br/>IPSEC</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 SafeZone FIPS SW 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>firmware load</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>status output<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/>IKEV<br/>IPSEC</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

FIPS 140-3 Non-Proprietary Security Policy SafeZone FIPS SW Cryptographic Module Software Version v2.0 Rambus Global Inc., Finnish branch Sokerilinnantie 11 C FI-02600 Espoo Phone: +358 50 3560966 Rambus Inc. North First Street, Suite 100 San Jose, CA 95134 United States of America https://www.rambus.com/ 2024-11-8

SafeZone SW Cryptographic Module 2.0 11.3.1 11.3.2 11.3.3 11.3.4 11.3.5 11.3.6 11.3.7 11.3.8 11.3.9 FFC) NIST SP 800-56A Rev 3: Pair-Wise Key-Establishment Schemes (KAS-ECC and KAS31 Appendix A. Appendix B.

SafeZone SW Cryptographic Module 2.0 This document is the non-proprietary FIPS 140-3 Security Policy for the SafeZone FIPS SW Cryptographic Module version 2.0, hereafter referred to as the module. It contains a specification of the rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 [FIPS 140-3] for a Security It has a one-to-one mapping to the NIST Special Publication 800-140B [NIST SP 800-140B] starting with section B.2.1 named “General” that maps to section 1 in this document and ending with section B.2.12 named “Mitigation of other attacks” that maps to section 12 in this document. N/A N/A N/A Table 1 - Security Levels cryptographic module from Rambus. The module provides a set of commonly used cryptographic primitives by exposing a custom API for a wide range of applications, typically running on a general-purpose operating system. There are 4 different binary versions of the module to suit the target environments. The identification string of the SafeZone FIPS SW Cryptographic Module can be acquired with the FLS_LibDescription function. The returned identification string is:

• ”SafeZone FL 2.0 NOHASH” The cryptographic module has been tested for validation on operational environments listed in the Table 2 below. # -

SafeZone SW Cryptographic Module 2.0 Table 2 - Tested Operational Environments In addition to the tested operational environments the module has been confirmed by the vendor to be operational on the following platforms. # Table 3 - Vendor Affirmed Operational Environments The Table 4 below lists the Approved Algorithms implemented by the module. The CAVP certs may list more algorithms than are actually utilized by the module. Only those listed below are used by the module.

SafeZone SW Cryptographic Module 2.0 (L,N) = (L,N) = (L,N) = (L,N) = (L,N) =

SafeZone SW Cryptographic Module 2.0

SafeZone SW Cryptographic Module 2.0

SafeZone SW Cryptographic Module 2.0 N/A D.G. Legacy usage only. These legacy algorithms can only be used on data that was generated prior to the Legacy Date specified in FIPS 140-3 IG C.M

SafeZone SW Cryptographic Module 2.0 N/A N/A N/A Table 4

• Approved Algorithms The module does not implement Non-Approved Algorithms Allowed in the Approved Mode of Operation or Non-Approved Algorithms Allowed in the approved Mode of Operation with No Security Claimed. The Table 5 below lists the Non-approved Algorithms Not Allowed in the Approved Mode of Operation implemented by the module. The module restricts these algorithms to only be available as part of the non-approved mode.

SafeZone SW Cryptographic Module 2.0 Table 5 -Non-Approved Algorithms Not Allowed in the Approved Mode of Operation The Finite State Model (FSM) of the module is provided in a separate document SafeZoneFIPS-Lib-2.0-FSM distributed with this security policy. The cryptographic boundary of the module is defined in the Figure 1 below. Control Output Figure 1 - Cryptographic Boundary

By default, the module is in Approved mode once initialized and does not require any special initialization. The module will remain in approved mode of operation and the operator must avoid using any non-approved services. Any use of non-approved services (as determined by the indicator) will move module into the non-approved mode of operation. Any keys generated using non-approved mode or services must not be used in the approved mode of operation. The module needs to be re-initialized in order to move back into the approved mode of operation.

As a software-only module, SafeZone FIPS SW Cryptographic Module provides a Cprogramming language API for invocation of the FIPS 140-3 approved cryptographic functions.

SafeZone SW Cryptographic Module 2.0 The functions shall be called by the application which assumes the operator role during values, defines the four FIPS 140-3 logical interfaces: data input, data output, control input Table 6. Ports and Interfaces

The SafeZone FIPS SW Cryptographic Module supports the Crypto Officer (CO) and User (U) roles. The operator of the module will assume one of these two roles. Only one role may be active at a time. The Crypto Officer role is assumed implicitly upon module installation, uninstallation, initialization, zeroization, and power-up self-testing. If initialization and selftesting are successful, a transition to the User role is allowed and the User will be able to use all keys and cryptographic operations provided by the module, and to create any CSPs (except Trusted Root Key CSPs which may only be created in the Crypto Officer role). The four unique run-time services given only to the Crypto Officer role are the ability to initialize the module, to set-up key material for Trusted Root Key CSP(s), to modify the entropy source, and to switch to the User role to perform any activities allowed for the User role. The SafeZone FIPS SW Cryptographic Module does not support concurrent operators. The module does not authenticate the User or the Crypto Officer role. The roles, services, and the API are described in the table below.

SafeZone SW Cryptographic Module 2.0 () c()

SafeZone SW Cryptographic Module 2.0

SafeZone SW Cryptographic Module 2.0

SafeZone SW Cryptographic Module 2.0 Table 7. Roles, Service Commands, Input and Output The approved services are described in the table below. The indicator column maybe None or ARG. None is used for non-security functions, and they do not utilize the approved indicator. For services utilizing security functions the indicator is specified as ARG. In this case the user of the service or function passes a pointer as argument and the indicator value is returned to that pointer. A value of 0 means that the service is approved and any non-zero value means it is a non-approved service. 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.

SafeZone SW Cryptographic Module 2.0 Z = Zeroize: The module zeroizes the SSP. The previous value is overwritten by zeroes and is no longer accessible. N/A U N/A N/A N/A N/A U U U N/A N/A U U N/A N/A U N/A N/A Z N/A Z N/A U U G N/A U G, W N/A R, W N/A Z N/A U U U R N/A U R module selftests

SafeZone SW Cryptographic Module 2.0 DRBG CTR256 DRBG CTR256 U U U G, W G, W G, W U U U U G, W E E E U U E E U U E E U R U W U W U W

SafeZone SW Cryptographic Module 2.0 Extraction-thenexpansion DSA/DiffieHellman U W U W U W U W U U U E E W U R, E U R, E U R, E U E U U E E

SafeZone SW Cryptographic Module 2.0 U U U U U U U U U U E E E E E E E E E E U U E E U E U U U Table 8. Approved Services

SafeZone SW Cryptographic Module 2.0 ECC DiffieHellman, ChaCha20Poly1305, TripleDES Encryption Table 9. Non-approved Services

SafeZone SW Cryptographic Module 2.0

The SafeZone FIPS SW Cryptographic Module must be linked with an application to become executable. The software code of the module (libsafezone-sw-fips.so dynamically loadable library) is linked with an end application producing an executable application for the target platform. The application is installed in a platform-specific way, e.g., when purchased from an application store for the platform. In some cases, there is no need for installation, e.g., when a mobile equipment vendor includes the application with the equipment. The SafeZone FIPS SW Cryptographic Module is loaded by loading an application that links the library statically. The SafeZone FIPS SW Cryptographic Module is initialized automatically upon loading. On some platforms the module is implemented as a dynamically loadable module. In this case, the module is loaded as needed by the dynamic linker. The integrity check of the cryptographic module is described in section 10. The SafeZone FIPS SW Cryptographic Module does not support operator authentication and thus does not require any authentication itself.

The operational environments are defined in Table 2 - Tested Operational Environments and Table 3 - Vendor Affirmed Operational Environments. The module runs in a modifiable operating environment and uses modern operating systems, i.e., Linux. All processes spawned by the module are child processes of the module, and ownership of a process cannot be changed.

The cryptographic module is software-only and does not have any physical security mechanisms.

The cryptographic module does not have non-invasive attack mitigation mechanisms.

SafeZone SW Cryptographic Module 2.0 (KTS), AESKWP (KTS) N/A TripleDES 112512 HMAC-SHA1, HMACSHA2-224, HMAC-SHA2256, HMACSHA2-384, N/A N/A (L,N) = NIST P224, P256, P384, P521 N/A (SP 800133r2 5.1, N/A 20488192 N/A

SafeZone SW Cryptographic Module 2.0 NIST P224, P256, P384 and P521 N/A 20488192 N/A N/A N/A N/A NIST P224, P256, P384 and P521 112200 KDF SP800108, KDF N/A N/A 112200 N/A CTR256 2561024 N/A N/A CTR256 2561024 N/A N/A CTR256 N/A N/A

SafeZone SW Cryptographic Module 2.0 CTR256 N/A N/A N/A N/A N/A N/A e NIST P224 N/A N/A Table 10. SSPs

The cryptographic module contains a Counter DRBG which uses AES-256 and derivation function. By default, the DRBG is seeded with CPU Time Jitter Based Non-Physical True Random Number Generator (JitterEntropy). It is also possible that the crypto officer may install another entropy source to the cryptographic module. The installed entropy source must be NIST SP 800-90B and FIPS 140-3 compliant. Enough bits of entropy must be provided according to the need of cryptographic algorithms. The RBG entropy sources are defined in the table below.

SafeZone SW Cryptographic Module 2.0 Table 11. Non-Deterministic Random Number Generation Specification

The SafeZone FIPS SW Cryptographic Module includes the following self-tests:

• Pre-operational self-tests:
• Pre-operational software integrity test:
• Integrity test by ECDSA signature verify with NIST P-224 and SHA2-224 Conditional self-tests:
• Conditional cryptographic algorithm self-tests (CAST):
• KAT test for SHA-1
• KAT test for SHA2-512
• KAT test for SHA3-224
• KAT test for HMAC-SHA2-256
• KAT test for AES-CBC encryption (128-bit key)
• KAT test for AES-CBC decryption (128-bit key)
• KAT test for AES-CCM encryption (128-bit key)
• KAT test for AES-CCM decryption (128-bit key)
• KAT test for AES-GCM encryption (128-bit key)
• KAT test for AES-GCM decryption (128-bit key)
• KAT test for AES-XTS encryption (128-bit key strength)
• KAT test for AES-XTS decryption (128-bit key strength)
• KAT test for AES-CMAC, 192-bit key

SafeZone SW Cryptographic Module 2.0

• KAT test for TDES-CBC encryption (192-bit key) KAT test for TDES-CBC decryption (192-bit key) KAT for Counter DRBG AES-256 (instantiate, generate and reseed; includes AES-ECB mode encryption)
• KAT for RSA SigGen 2048-bit with SHA2-256 (PKCS #1 v1.5)
• KAT for RSA SigVer 2048-bit with SHA2-256 (PKCS #1 v1.5)
• KAT for DSA SigGen (P=2048/N=256 with SHA2-224)
• KAT for DSA SigVer (P=1024/N=160 with SHA2-224)
• KAT for ECDSA SigGen (NIST P-224 with SHA2-224)
• KAT for ECDSA SigVer (NIST P-224 with SHA2-224)
• KAT for KTS-IFC Key Encapsulation 2048-bit (RSA-OAEP)
• KAT for KTS-IFC Key Un-encapsulation 2048-bit (RSA-OAEP)
• KAT for KAS-FFC-SSC (P=2048/N=224)
• KAT for KAS-ECC-SSC (NIST P-224)
• KAT for KDF SP800-108 (Counter Mode)
• KAT for KDA HKDF (includes KDF SP800-108 Feedback Mode)
• KAT for KDF SP800-108 (Double Pipeline Mode)
• KAT for KDF IKEv1
• KAT for KDF IKEv2
• KAT for TLS v1.2 KDF RFC7627
• KAT for SP 800-90A-r1, Section 11.3 (Instantiate/Generate) health tests for Counter DRBG AES-256
• KAT for SP 800-90A-r1, Section 11.3 (Reseed) health test Counter DRBG AES-256
• Fault Detection Tests for SP 800-90B, Section 4 start-up and continuous health tests (RCT and APT) for JitterEntropy ENT (NP).
• Conditional pair-wise consistency tests:
• Pair-wise consistency check for key pairs created for digital signature purposes (DSA, FIPS 186-4)
• Pair-wise consistency check for key pairs created for digital signature purposes (ECDSA, FIPS 186-4)
• Pair-wise consistency check for RSA key pairs created for digital signature (FIPS 186-4) or key transport (NIST SP 800-56B) purposes.
• Pair-wise consistency check for key pairs created for key establishment purposes (FFC DH and ECC DH, NIST SP 800-56A rev3) All CAST are performed before pre-operational self-tests. The KAT’s are done by performing memory comparing (C library function memcmp) between calculations with known inputs and the expected correct results matching the inputs. Self-tests are invoked automatically upon loading the cryptographic module. The initialization function FLS_LibInit is executed automatically. Any error during the selftests will result the module in an error state, from where only recovered by invoking the FLS_LibUninit or FLS_LibInit function.

SafeZone SW Cryptographic Module 2.0 The FL_LibStatus API function can be used to obtain the module status. It returns FL_STATUS_INIT when the module has not yet been initialized and FL_STATUS_ERROR when the module is in error state. As it is recommended to self-test cryptographic components (like DRBG) frequently, the module provides the capability to invoke the self-tests manually (on demand) with the FL_LibSelfTest API function. The important difference between the manually invoked self-tests and the automatically invoked self-tests when initializing the module is that the manually invoked self-tests will not cause zeroization of the key material currently loaded in the module, providing the tests execute successfully. In general, if a self-test fails, the module will transition to the error state and the return value (status) of the invoked API function will be something other than FLR_OK, depending on the current situation. Conditional self-tests for manual key entry and software/firmware load or bypass are not provided, as these are not applicable. Any error during the conditional self-tests will result in a module transition to the error state The cryptographic module uses the ECDSA NIST P-224 signature of the module binary for the integrity tests with SHA2-224 as the hash function. The public part of the key is always included with the module. The private part is stored in Rambus version control system and signing of the module is performed automatically by Rambus build system. Before running the integrity test, tests for the signature algorithms are executed. In case of failure in the integrity test the module will immediately transition to error state.

The SafeZone FIPS SW Cryptographic Module source code is maintained in a version control system (Mercurial). Changes are reviewed and automatically built and tested with continuous integration system (Jenkins).

There are no CVE’s which currently affect the module as the module is published.

Some of the FIPS Publications or NIST Special Publications require that the Cryptographic Module Security Policy mentions important configuration items for those algorithms. The user of the module shall observe these rules.

All three key derivation functions, Counter Mode, Feedback Mode and Double-Pipeline Iteration Mode are supported.

SafeZone SW Cryptographic Module 2.0

11.3.2 NIST SP 800-56C Rev 2: Key-Derivation Methods in Key-Establishment Schemes

The SafeZone FIPS SW Cryptographic module provides hash and HMAC functions that can be used for One-Step Key Derivation as introduced in NIST SP 800-56C Rev

2. The module also offers Extraction-then-Expansion function that can be used for Two-Step Key Derivation as introduced in NIST SP 800-56C Rev
3. The Two-Step Key Derivation function uses HMAC with SHA-1/SHA224/SHA256/SHA384 or AES-CMAC and SHA512 and NIST SP 800-108 Key Derivation Function with Feedback Mode. The construct is compatible with some uses of RFC 5869. The following rules the user of the functions for NIST SP 800-56C Rev 2 Key Derivation functions shall observe: • • • • • • • • • • • • Key derived using NIST SP 800-56C Rev 2 shall only be used as secret keying material — such as a symmetric key used for data encryption or message integrity, a secret initialization vector, or, perhaps, a key-derivation key that will be used to generate additional keying material. The derived keying material shall not be used as a key stream for a stream cipher. When using HMAC algorithm for key derivation, the algorithms require a key. This key corresponds to salt in NIST SP 800-56C Rev
4. If salt is to be omitted, use allzero-byte key at exactly the bit length of the hash algorithm. HKDF expansion function always uses NIST SP 800-108 Feedback Mode Key Derivation Function with single byte counter. This is interoperable with RFC 5869. The two-part extraction and expansion operation always uses the same underlying hash function or AES-CMAC for both extraction and expansion. AES-CMAC can be used to generate keys up to 128 bit security. For higher security hash- or HMAC-based schemes shall be used. HMAC-SHA-1 and HMAC-SHA-2 functions can be used to generate keys with 112512 bit strength. See table below for details. If HMAC is used for key derivation, salt can be up-to one hash input block. If AES-CMAC is used, the key extraction phase may use 128 bit, 192 bit or 256 bit salt, but the key-expansion step will always use AES-128-CMAC. The module does not support NIST SP 800-56C Rev 2 Single-Step Key Derivation. If the input for NIST SP 800-56C Key Derivation Function is a shared secret, the input must be destroyed after extraction (e.g., with FLS_AssetFree). Two-Step Key Derivation will make use of both salt and KDK. The input attributes and security strength of generated keys follows this table: (HMAC-)SHA1 (HMAC-)SHA224 HMAC-SHA224

SafeZone SW Cryptographic Module 2.0 (HMAC-)SHA256 HMAC-SHA256 (HMAC-)SHA384 HMAC-SHA384 (HMAC-)SHA512 HMAC-SHA512 AES-128CMAC AES-128CMAC AES-192CMAC AES-192CMAC AES-256CMAC AES-256CMAC

The SafeZone FIPS SW Cryptographic module provides HMAC-based Key Derivation Function from RFC 5869, known as HKDF. This function is similar to NIST SP 800-56C Rev 2 Two-Step Key Derivation, but not the same.

The key derived using NIST SP 800-132 shall only be used for storage purposes. The options 1a, 1b, 2a and 2b presented in NIST SP 800-132 for deriving the DPK (Data Protection Key) from the MK (Master Key) are supported. The SafeZone FIPS Lib does not limit the length of the password used in NIST SP 800-132 PBKDF key derivation. The upper bound for the strength of passwords usually used is between 5 or 6 bits per character, which indicates the upper bound for the probability of the password being randomly guessed is 1 / (64 ^ length_of_password). To achieve security over 64 bits, the passwords must generally be longer than 12 characters. With compliance to NIST SP 800-132 and the FIPS 140-3 Implementation Guidance D.N, these requirements and limits must be followed by user:

• There is no maximum length of salt used, but at least 128 bits (16 bytes) of salt value must be randomly generated. The iteration count shall be as large as possible. The iteration count used must be at least 1000 to meet the minimum requirements of NIST SP 800-132. However, often it is recommendable to use much larger iteration counts, such as 100000 or 1000000, when user-perceived performance is not critical. Resulting MK must be used in the way as one of the following options as stated in NIST SP 800-132:
• Option 1a, the MK is used directly as the DPK.

SafeZone SW Cryptographic Module 2.0

• Option 1b, the MK is used as input to an approved KDF (NIST SP 800-108 or NIST SP 800-56C-r2) in order to derive the DPK.
• Option 2a, the MK is used to protect a randomly generated DPK, the DPK is protected with approved authenticated encryption algorithm (AES-GCM or AES-CCM) or approved authentication technique (HMAC or AESGMAC/CMAC) and approved encryption algorithm (AESECB/CBC/CTR/OFB/XTS).
• Option 2b, the MK is used as input to an approved KDF (NIST SP 800-108 or NIST SP 800-56C-r2) in order to derive the key to protect a randomly generated DPK, the DPK is protected with approved authenticated encryption algorithm (AES-GCM or AES-CCM) or approved authentication technique (HMAC or AES-GMAC/CMAC) and approved encryption algorithm (AESECB/CBC/CTR/OFB/XTS).

The FIPS 140-3 Implementation Guidance C.H applies to AES-GCM and GMAC usage with this module. Scenario/technique 1, 2 and 3 in IG C.H are supported by this module. With compliance to technique 1 in IG C.H, the module supports AES-GCM with IPSec and TLS v1.2, both must be initialized with FLS_EncryptAuthInitDeterministic function for encryption and with FLS_CryptAuthInit for decryption. The FLS_CryptAuthInit function is also used for subsequent encryption operations for operation sequences started with the FLS_EncryptAuthInitDeterministic function (In this case the input IV/Nonce must be NULL since IG C.H forbids using external IV for encryption). With compliance to technique 2 or 3 in IG C.H, the operator must use the FLS_EncryptAuthInitRandom function if random IV generation (IG C.H Technique 2) is required, or in case of deterministic IV generation (IG C.H Technique 3), the FLS_EncryptAuthInitDeterministic function. It is not possible to use random IV generated externally. The module supports AES-GCM with SRTP (RFC 7714). For SRTP, functions FLS_EncryptAuthSrtp, FLS_EncryptAuthSrtcp have been introduced. These functions provide equivalent functionality than FLS_EncryptAuthInitDeterministic, but work with SRTP protocols. SRTP IV consists of 32-bit field, SSRC (synchronization source), which acts like 32-bit Module Name of IG C.H Technique 3. SRTP uses 48-bit counter ROC || SEQ. This counter is incremented internal to the cryptographic module. The module will detect overflow of counter. It is the responsibility of the users to rekey upon counter overflow. In addition, SRTP uses 96-bit Encryption Salt that is XORed with other fields. For control purposes, SRTP has an additional protocol, SRTCP. SRTCP protocol is otherwise identical to SRTP, but it uses different keys, and IV format where ROC || SEQ is replaced by SRTCP index. SRTCP index is incremented internal to the cryptographic module. The module will allow only 2^31 packets to be produced with SRTCP prior rekeying.

SafeZone SW Cryptographic Module 2.0

• Note: If IV is generated internally in a deterministic manner, then in case a module’s power is lost and then restored, the key used for the AES GCM encryption/decryption must be re-distributed.

The module supports XTS Mode for Confidentiality on Storage Devices. Both XTS-AES-128 (256 bit key) and XTS-AES-256 (512 bit key) are supported. The XTS-AES key is parsed as concatenation of two AES keys Key_1 and Key_2. As is explained in FIPS 140-3 Implementation Guidance C.I, it is required that Key_1 ≠ Key_2. If Key_1 = Key_2, attempt to perform XTS-AES encryption or decryption will fail. The XTS Mode is only approved for usage in storage applications.

The module allows key generation and generates keys according to the following NIST SP 800-133-r2 sections: 5.1, 5.2, 6.1. Key generation will use NIST SP 800-90A Rev1 DRBGCTR AES-256. The output of the approved DRBG is used unmodified when symmetric keys are generated. It is also used unmodified as random input for asymmetric key generation.

The module supports truncation of HMAC results for all SHA-1 and SHA-2 family hash functions. These include e.g., HMAC-SHA-1-80, HMAC-SHA-1-96, HMAC-SHA-256-128, HMAC-SHA-384-192 and HMAC-SHA-512-256. Following guidance of NIST SP 800-107 Rev 1, it is not allowed to truncate HMAC to less than 32-bits. Therefore, minimum allowed mac output length argument for the FLS_MacGenerateFinish or FLS_MacVerifyFinish is 4.

11.3.9 NIST SP 800-56A Rev 3: Pair-Wise Key-Establishment Schemes (KAS-ECC and KAS-FFC)

The module provides Discrete Logarithm Cryptographic-based key agreements compliant with NIST SP 800-56A-r3 according to scenario 2 path (1) of FIPS 140-3 Implementation Guidance D.F. The KAS-ECC-SSC schemes provide between 112 and 256 bits of security strength. The KAS-FFC-SSC schemes provide between 112 and 200 bits of security strength.

SafeZone FIPS 140-3 product is typically delivered in binary format. The product in binary format is validated for platforms mentioned in the validation certificate. There is also another product available from Rambus: source code product. This package can be recompiled by the user for their target platform. However, if changes to the module are required, they need to be processed as a revalidation for FIPS 140-3.

SafeZone SW Cryptographic Module 2.0 When ported to an operational environment which is not listed on the validation certificate, no claims can be made as to the correct operation of the module and the security strengths of any keys generated by the module.

The cryptographic module does not implement security mechanisms to mitigate other attacks.

SafeZone SW Cryptographic Module 2.0 Appendix A. Glossary and Abbreviations AES Advanced Encryption Standard CAVP Cryptographic Algorithm Validation Program CBC Cipher Block Chaining CFB Cipher Feedback CMAC Cipher-based Message Authentication Code CMVP Cryptographic Module Validation Program CO Crypto Officer CTR Counter Mode DSA Digital Signature Algorithm DRBG Deterministic Random Bit Generator ECB Electronic Code Book ECC Elliptic Curve Cryptography FIPS Federal Information Processing Standards Publication FSM Finite State Model GCM Galois Counter Mode HMAC Hash Message Authentication Code KAS Key Agreement Scheme KAT Known Answer Test KDF Key Derivation Function KW AES Key Wrap KWP AES Key Wrap with Padding MAC Message Authentication Code NIST National Institute of Science and Technology OFB Output Feedback PSS Probabilistic Signature Scheme RNG Random Number Generator RSA Rivest, Shamir, Adleman SHA Secure Hash Algorithm SHS Secure Hash Standard SSP Sensitive Security Parameter U User

SafeZone SW Cryptographic Module 2.0 Appendix B. References FIPS 140-3 FIPS PUB 140-3

• Security Requirements for Cryptographic Modules March 2021 FIPS 140-3 IG Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program November 2021 FIPS 180-4 FIPS PUB 180-4
• Secure Hash Standard (SHS) August 2015 FIPS 186-4 FIPS PUB 186-4
• Digital Signature Standard (DSS) July 2013 FIPS 198-1 FIPS PUB 198-1
• The Keyed-Hash Message Authentication Code (HMAC) July 2008 FIPS 202 FIPS PUB 202
• SHA-3 Standard: Permutation-Based Hash and ExtendableOutput Functions August 2015 ISO/IEC 24759 ISO/IEC 24759
• Information technology
• Security techniques
• Test requirements for cryptographic modules March 2017 NIST SP 800-38A NIST Special Publication 800-38A
• Recommendation for Block Cipher Modes of Operation: Methods and Techniques December 2001 NIST SP 800-38B NIST Special Publication 800-38B
• Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication May 2005 NIST SP 800-38C NIST Special Publication 800-38C
• Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality May 2004 NIST SP 800-38D NIST Special Publication 800-38C
• Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC November 2007

SafeZone SW Cryptographic Module 2.0 NIST SP 800-38E NIST Special Publication 800-38E

• Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices January 2010 NIST SP 800-38F NIST Special Publication 800-38F
• Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping December 2012 NIST SP 800-56A-r3 NIST Special Publication 800-56A Revision 3
• Recommendation for PairWise Key-Establishment Schemes Using Discrete Logarithm Cryptography April 2018 NIST SP 800-56B-r2 NIST Special Publication 800-56B Revision 2
• Recommendation for PairWise Key Establishment Using Integer Factorization Cryptography March 2019 NIST SP 800-56C-r2 NIST Special Publication 800-56C Revision 2
• Recommendation for KeyDerivation Methods in Key-Establishment Schemes August 2020 NIST SP 800-67-r2 NIST Special Publication 800-67 Revision 2
• Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher November 2017 NIST SP 800-90A-r1 NIST Special Publication 800-90A Revision 1
• Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 NIST SP 800-108 NIST Special Publication 800-108
• Recommendation for Key Derivation Using Pseudorandom Functions (Revised) October 2009 NIST SP 800-132 NIST Special Publication 800-132
• Recommendation for PBKDF, Part 1: Storage Applications December 2010 NIST SP 800-133-r2 NIST Special Publication 800-133 Revision 2
• Recommendation for Cryptographic Key Generation December 2011 NIST SP 800-135-r1 NIST Special Publication 800-135 Revision 1
• Recommendation for Existing Application-Specific Key Derivation Functions December 2011

SafeZone SW Cryptographic Module 2.0 NIST SP 800-140B NIST Special Publication 800-140B

• CMVP Security Policy Requirements March 2020

Referenced URLs

• https://www.rambus.com/
• https://www.chronox.de/jent.html