SAP CommonCryptoLib Crypto Kernel

Certificate

Approved Algorithms (60)

Security Levels (Table 1)

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

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

flowchart LR
  %% Deterministic clue tier for SAP CommonCryptoLib Crypto Kernel
  %% 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<br/>Recovery</i><br/>src: text:keyword"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>AES encryption / decryption<br/>AES CFB encryption / decryption<br/>Initialize and self-test</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C5,C6 clueLow;
  class C3 clueHigh;

Security Policy, page by page

SAP SE SAP CommonCryptoLib Crypto Kernel Document version: 1.4 Date: 2025-10-21 This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

This document is the non-proprietary FIPS 140-3 Security Policy for the cryptographic module “SAP CommonCryptoLib Crypto Kernel” (hereafter denoted as “module”) in its version 8.6.1 developed by SAP SE.

N/A N/A Table 1: Security Levels This document may be reproduced and distributed only in its original entirely without revision.

Purpose and Use: The module is a shared software library that implements various cryptographic functions such as encryption/decryption, signature generation/verification, key establishment, key generation, and random number generation. The module also implements an entropy source. It provides C/C++ APIs for key management and operation of the implemented cryptographic functions. The module itself is subdivided as shown in Figure

1. The arrows in this figure indicate the interactions between the different module components. The module is used by a single operator, which is the linked application using the library by calling its functions and methods. Typically, this application is the “SAP CommonCryptoLib” (not in scope of the validation), which itself is a library providing cryptographic protocols and services to an application using it. Module Type: Software Module Embodiment: MultiChipStand Cryptographic Boundary: The cryptographic boundary of the module comprises the shared library (including its executable code and data as well as its runtime representation) and a file containing the reference value for the software/firmware integrity test (see Section 5 Software/Firmware Security and Section 11.1 Installation, Initialization, and Startup Procedures for details). In Figure 2, the contents of the cryptographic boundary are indicated by the blue boxes. The “API” box shown in Figure 2 corresponds to the blue box shown in the block diagram in Figure
2. The linked application calling the module’s services and residing in the same shared volatile memory region is outside the cryptographic boundary. Tested Operational Environment’s Physical Perimeter (TOEPP): The TOEPP of the module is made up by the workstation, laptop, or server hardware the module is running on. Figure 2 shows the module and its interactions in context of the modifiable operational environment. The module interacts with the operating system within the TOEPP as well as the application it is linked to. At runtime, the module resides in the volatile memory provided by the TOEPP. This document may be reproduced and distributed only in its original entirely without revision.

Figure 1: Block Diagram Figure 2: Module in Context of its Operational Environment

Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): This document may be reproduced and distributed only in its original entirely without revision.

Table 2: Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets) The module is a shared library, i.e., it consists of software only. It provides an API in terms of C/C++ functions for operation of the implemented cryptographic functions and is delivered already compiled. The module comprises two files:
• A shared library file that implements the module’s cryptographic functionality.
• A text file that contains a hexadecimal representation of the SHA2-256 hash of, and the HMAC-SHA2-256 value computed over, the library file. This file is required for the integrity test performed during module’s initialization. Section 11.1 Installation, Initialization, and Startup Procedures provides a mapping between the unique package names listed in the above table for the module’s executable code sets and the actual file names. The version and name of the library can be queried separately using the sec_crypto_get_feature_info API (see also the service “show versioning information” in Section 4.3 Approved Services). The validated module has the version v8.6.1 and is called “SAP CommonCryptoLib Crypto Kernel”. Note that the package names provided in brackets for the version numbers are only listed here for reference in the following tables. They are not part of the versioning information output by the module. Tested Operational Environments - Software, Firmware, Hybrid:

This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

8.6.1 (windowsx86-64) Table 3: Tested Operational Environments - Software, Firmware, Hybrid All operational environments listed above with “Yes” in the “PAA/PAI” column can optionally use what is considered as a Processor Algorithm Acceleration (PAA) for certain approved algorithm implementations. For details on the PAAs supported by each binary, please refer to Table 4 and its footnotes as well as the CAVP certificate referenced in Section 2.5 Algorithms. The PAAs are also used when the listed algorithms are embedded into other higher cryptographic algorithms (e.g., SHA-256 used as part of an HMAC). AES-GCM 1 SHA512 2

1 The PAAs listed in this column are used for the counter logic of AES-GCM. They are used in addition to the PAAs listed in the “AES (all modes)”

2 Not supported by the tested operational environment using the Arm Neoverse-N1 CPU.

This document may be reproduced and distributed only in its original entirely without revision.

AES-GCM 1 Table 4: Optionally Available PAAs per Algorithm In compliance with IG 2.3.C, the module implements every algorithm utilizing a PAA also entirely in software. Different combinations of enabled and disabled PAAs were used during testing to cover all code paths of the implemented algorithms. Before module initialization, the crypt_disable_cpu_features API can be used to configure the activated PAAs. Reconfiguration of the activated PAAs is only possible after re-initializing the module (see Section 11.1 Installation, Initialization, and Startup Procedures for more details). Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: No vendor-affirmed operational environments are claimed. Nevertheless, the module may be ported to other operational environments that have the necessary capabilities (operating system, system libraries, sufficient hardware, etc.) per the CMVP porting rules specified in the FIPS 140-3 Management Manual. However, in this case the CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate. In addition, when running a module on such an untested platform the “No assurance of the minimum strength of generated SSPs (e.g., keys)” caveat applies per IG 9.3.A.

There are no excluded components within the cryptographic boundary.

This document may be reproduced and distributed only in its original entirely without revision.

Modes List and Description: Nonapproved NonApproved Table 5: Modes List and Description As the module supports both an approved mode and non-approved modes, the caveat “when operated in approved mode” is applicable. The module further supports a non-compliant test mode that is off by default. This mode allows for additional controls for functional testing that violate the FIPS 140-3 requirements. As the test mode is non-compliant, the caveat “when installed, initialized, and configured as specified in Section 11.1 of the Security Policy” is additionally applicable. When this mode is activated, the module is not considered to be FIPS 140-3 validated. Mode Change Instructions and Status: With the module’s default configuration, both approved and non-approved services are available at the same time. There is no transitioning procedure to switch between different modes. The return codes of the called security services indicate whether they were executed in the approved mode or the non-approved mode depending on the provided input parameters. For more details, please see Section 4.3 Approved Services. The module’s non-compliant test mode can be activated by passing the “TESTMODE” value to the crypt_control API before module initialization. When this mode is activated, all the module’s security services, including those that are usually approved, are non-approved services. This is reflected by the implemented approved service indicator. The test mode can be deactivated by reloading the module or by passing the value “PRODUCTIONMODE” to the crypt_control API. This document may be reproduced and distributed only in its original entirely without revision.

Approved Algorithms: General This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

Table 6: Approved Algorithms - General Legacy Table 7: Approved Algorithms - Legacy This document may be reproduced and distributed only in its original entirely without revision.

Table 8: Approved Algorithms - CVL Before approved signature verification is performed, the module performs a partial public key validation as required by

• FIPS 186-4 Section 3.3 (DSA) and
• FIPS 186-5 Section 3.3 (ECDSA, EdDSA, and RSA) in accordance with
• SP 800-56Ar3 Section 5.6.2.3.4 and SP 800-186 Section D.1.1.1 (ECDSA),
• SP 800-186 Section D.1.3.1 (EdDSA), and The module further performs the following explicit private key validations before approved signature generation: Assurance of the domain parameter validity for ECDSA and EdDSA is ensured by only supporting the approved curves specified in the CAVP certificate referenced in the above table (also see Section 2.6 Security Function Implementations). When using the FIPS 186-type FFC domain parameters for DSA, the module performs an explicit domain parameter validation for the unverifiable generation method of g as specified in SP 800-89 Section 4.1 and FIPS 186-4 Section A.1.1.3 and Section A.2.2. Vendor-Affirmed Algorithms: N/A This document may be reproduced and distributed only in its original entirely without revision.

N/A N/A Table 9: Vendor-Affirmed Algorithms For the approved key generation algorithms used together with the CKG claimed according to IG D.H, please see the approved algorithms table above and Section 2.6 Security Function Implementations. Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

Table 10: Non-Approved, Not Allowed Algorithms This document may be reproduced and distributed only in its original entirely without revision.

Note that “non-approved” in the above non-approved, not allowed algorithms table refers to algorithms or parameter sets (e.g., modulus sizes or curves) not listed as approved in either the approved algorithms table or the vendor-affirmed algorithms table. Please further note the algorithm specific information provided in Section 2.7 Algorithm Specific Information. Note that some of the functions listed in the above table are non-compliant implementations of what appear to be approved algorithms. For a description of the security strength as a function of the key length respectively the algorithm parameters of the listed non-approved security functions, please see SP 800-57 Part 1 Revision 5 Section 5.6.1.

This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

AsymKeyPairPubKeyVal AsymKeyPairPubKeyVal () This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

Table 11: Security Function Implementations Unless identified otherwise in the above table, all tested capabilities (e.g., key sizes, curves, modes) of the listed algorithms are used by the security function implementations. For details, please refer to Section 2.5 Algorithms. Note that the “random number generation” SFI also makes use of the module’s validated entropy source (cf. 2.8 RBG and Entropy).

When using the approved security functions (see Section 2.6 Security Function Implementations), the Crypto Officer shall observe the following algorithm-specific requirements: KAS-SSC FFC / ECC: The module does not establish SSPs using an approved key agreement scheme (KAS). However, it does offer some or all of the underlying KAS cryptographic functionality to be used by an external operator/application as part of an approved KTS-IFC: The module does not establish SSPs using an approved key transport scheme (KTS). However, it does offer approved authenticated algorithms that can be used by an external operator/application as part of an approved KTS. AES-CTR Encryption: Externally loaded counter values shall have the properties required by SP 800-38A Section 6.5. This document may be reproduced and distributed only in its original entirely without revision.

AES-GCM: The module provides APIs to use AES-GCM encryption as specified in SP 800-38D as an approved service according to the following scenarios of IG C.H:

• 1a (GCM cipher suites in TLS 1.2),
• 2 (for encryption: random IV generated by the internal Counter DRBG instance with a length of at least 96 bits), and
• 5 (GCM cipher suites in TLS 1.3). The use of AES-GCM encryption with a user-provided IV is not approved. The APIs provided for scenarios 1a and 5 shall only be used in context of the TLS 1.2 and TLS 1.3 protocol, respectively. The module itself does not implement the full TLS protocol but just the AES-GCM mode of operation and the IV / nonce management logic according to RFC 5246 and RFC 5288 for TLS 1.2, and RFC 8446 for TLS 1.3. For this reason, the following statement of IG D.C case 3 is applicable: no parts of these protocols, other than the approved AES-GCM algorithm, have been tested by the CAVP and CMVP. The module ensures that an error is provided to the linked application before the IV exhausts the maximum number of values for a given key in all three scenarios. A new key shall be established in this case. The module itself is not capable of restoring the IV state after a power loss, therefore, in case the module’s power is lost and then restored, a new (session) key for use with the AES-GCM encryption shall be established by the Crypto Officer. Component Algorithms (CVLs): For the following algorithms (cf. Section 2.5 Algorithms) usage restrictions apply:
• ECDSA signature generation without the computation of a hash: This component shall only be used within the context of a FIPS 186-5 signature generation.
• RSA signature generation without the computation of a hash: This component shall only be used within the context of a FIPS 186-5 signature generation.
• RSA decryption primitive: This component shall only be used within the context of a SP 800-56Br2 KTS.
• KAS-ECC CDH-Component: This component shall only be used within the context of a SP 800-56Ar3 KAS. Legacy Algorithms: The following algorithms are only approved for legacy use (cf. Section 2.5 Algorithms):
• FIPS 186-4 DSA signature verification and domain parameter verification,
• FIPS 186-4 ECDSA signature verification with curve P-192 or using SHA-1 and ECDSA public key validation using curve P-192,
• FIPS 186-4 RSA signature verification with a modulus size of 1024 bits or using SHA-1. These legacy algorithms shall only be used on data that was generated prior to the Legacy Date specified in FIPS 140-3 IG C.M. This document may be reproduced and distributed only in its original entirely without revision.

SHA-1: SHA-1 shall only be used for digital signature generation where specifically allowed by NIST protocol-specific guidance. For all other applications, SHA-1 shall not be used for digital signature generation. When used for digital signature verification, SHA-1 shall only be used in legacy applications. For non-digital-signature applications, SHA-1 shall only be used in applications that do not require collision resistance. Table 12: Entropy Certificates NonPhysical Table 13: Entropy Sources The entropy source is within the cryptographical boundary of the module. The module’s entropy source provides 512 bits of minentropy per conditioned 512-bit output. The module implements an internal Counter DRBG instance using AES-256 with derivation function, but without support for reseeding and predication resistance (i.e., the Counter DRBG is only seeded once during module initialization). This DBRG instance is managed internally by the module and used for all random number generation in the approved security functions, for SSP generation, and SSP establishment. It is seeded entirely by the validated entropy source during module initialization and thus provides a security strength of 256 bits. After the allowed maximum number of random bits was requested from the Counter DRBG, further output is blocked, and the module shall be reinitialized to request additional outputs. The Counter DRBG’s additional input and personalization string used for its initialization are derived from additional outputs of the entropy source and, if available, data obtained from the operating system (“dev/urandom” on operating systems that provide this file) as well as data provided by the linked application during module initialization. Note that this additional data is not considered in the security strength estimate of the approved Counter DRBG. This document may be reproduced and distributed only in its original entirely without revision.

In compliance with IG 2.4.A, the internal Counter DRBG is used by approved and non-approved services for the following purposes by the module: In Approved Services:

• Blinding of RSA decryption and signature generation as well as ECDSA signature generation operations (see Section 12 Mitigation of Other Attacks).
• ECDSA signature generation (per-message secret number).
• Generation of random bit strings with variable length (as requested by the operator).
• IV generation for the CBC, CBC-CS3, CFB, OFB, CTR, and GCM modes of operation.
• Key and domain parameter generation for the approved symmetric and asymmetric cryptographic functions (see Section 2.5 Algorithms and Section 2.9 Key Generation).
• Pair-Wise Consistency Tests (PCTs) for approved ECDSA, KAS-SSC ECC, KTS-IFC, and RSA.
• Primality testing for RSA assurance checks (see Section 2.5 Algorithms and Section 2.10 Key Establishment).
• RSA-OAEP encryption (seed).
• RSA-PSS signature generation (salt). In Non-Approved Services:
• DSA signature generation (per-message secret number).
• Generation of random numbers / primes and primality testing within the implemented long number arithmetic functions.
• Key generation for the non-approved symmetric and asymmetric cryptographic functions (see Section 2.5 Algorithms and Section 2.9 Key Generation).
• Pair-Wise Consistency Tests (PCTs) for DSA and non-approved ECDSA, KAS-SSC ECC, KTS-IFC, and RSA key pairs.
• RSA PKCS1-v1.5 encryption (PS). The state information of the internal Counter DRBG instance as well as its entropy inputs are considered as CSPs (also see Section 9.4 SSPs). The additional data used for deriving personalization string and additional input are not considered as SSPs as they cannot degrade the module’s security. The operator of the module is also able to instantiate their own non-approved Counter DRBG instance using AES-128, AES-192, or AES-256. This instance must be seeded entirely by the operator. It uses the derivation function and supports reseeding but does not support prediction resistance. This document may be reproduced and distributed only in its original entirely without revision.

The module’s key generation methods as well as the related vendor-affirmed CKG entries per IG D.H are specified in Section 2.5 Algorithms and Section 2.6 Security Function Implementations. The approved services for key generation cover

• symmetric key generation for AES,
• asymmetric key pair generation for ECDSA, EdDSA, KAS-SSC ECC, KTS-IFC, and RSA as well as
• asymmetric key pair and domain parameter generation for KAS-SSC FFC. For the pair-wise consistency tests performed after key pair generation please see Section 11.2 Administrator Guidance. All random numbers used during the key generation processes are taken from the approved internal Counter DRBG instance (see Section 2.8 RBG and Entropy). As the claimed security strength of this Counter DRBG is 256 bits and at the time of publication of this SP the claimed security strength of any approved algorithm may not be greater than 256 bits, no entropy caveat is applicable for key generation. All intermediate key generation values processed by the module’s approved services are considered as CSPs (also see Section 9.4 SSPs). They are not output.

The key establishment schemes in terms of the implemented Key Agreement Schemes Shared Secret Computation (KAS-SSC) and Key Transport Schemes (KTS) as specified in SP 800-56Ar3 and SP 800-56Br2 implemented by the module are listed in Section 2.5 Algorithms and Section 2.6 Security Function Implementations. The module only supports the shared secret computation. It does not implement key derivation or key confirmation. It can act both in the initiator and responder roles. As required by IG D.F, for the implemented approved schemes, the module obtains all assurances required by the respective standards for which the module has the necessary inputs either using explicit assurance checks or by generating all values as specified in the respective algorithm standard. The coverage of the required assurances, other than the pair-wise consistency tests that are always performed when a key pair (i.e., both a private and a public key) is generated or imported (see Section 11.2 Administrator Guidance for details), are explained in Table 14. When not stated otherwise, the assurances are obtained directly by the dedicated KAS-SSC and KTS APIs. Some assurances must be manually obtained by the operator of the module as the module does not have the necessary inputs to perform the validations by itself. For the implemented KAS-SSC, the owner’s private key and received public key are validated at the latest before generating the shared secret. It is also ensured that the owner’s static or ephemeral private / public key is validated before it is first exported. This document may be reproduced and distributed only in its original entirely without revision.

5.6.2.2.2 5.6.2.1.2 5.6.2.3.1 5.6.2.2.1 5.6.2.3.3 5.6.2.1.2 5.6.2.3.3 This document may be reproduced and distributed only in its original entirely without revision.

The module further provides the following standalone functions, which can be used independently of the dedicated KAS-SSC and KTS APIs addressed in Table 14, to manually obtain assurances:

• sec_crypto_keypair_sp800_56b_validate_RSA: rsakpv1-crt key pair validation as specified in SP 800-56Br2 Section

• sec_crypto_ecc_sp800_56a_checkKeyFull: Full public key validation as specified in SP 800-56Ar3 Section 5.6.2.3.3 respectively SP 800-186 Section D.1.1.2 for ECDSA / KAS-SSC ECC key pairs respectively SP 800-186 Section D.1.3.2 for EdDSA key pairs.
• sec_crypto_ffc_parameterValidate: Validation of the probably primes p and q for KAS-SSC FFC (DSA) as specified in FIPS 186-4 Section A.1.1.3. As the module only implements the shared secret computation part of the KAS (i.e., no key derivation or use of a nonce), the difference between using the KAS-SSC with static and ephemeral key pairs lies in the assurances obtained and the use of additional module-internal checks that prevent using the freshly generated ephemeral keys for multiple key establishments. Key generation is addressed in Section 2.9 Key Generation. SSP entry in form of plaintext SSP input from and output to the application linked to the module are addressed in Section 9.2 SSP Input-Output Methods. Key derivation is not supported by the module, and it does not contain any pre-loaded SSPs.

The module itself does not implement any industry protocols. However, note the information provided in Section 2.7 Algorithm Specific Information for the use of AES-GCM encryption in context of the TLS 1.2 and 1.3 protocols. This document may be reproduced and distributed only in its original entirely without revision.

N/A N/A N/A N/A Table 15: Ports and Interfaces As the module is a software library, its logical interfaces are realized in terms of a set of APIs. The above table maps the FIPS 140-3 logical interfaces to the distinct parts of these APIs. All functionality of the module is made available to the calling application (i.e., the operator of the module) in terms of exported functions (APIs). Some of these functions are also used internally, e.g., the self-test service makes use of some of those functions when performing cryptographic algorithm self-tests. For a full reference of all exported APIs, please see the guidance documents referenced in Section 11.2 Administrator Guidance. Because the module is a software library, it does not have any physical ports or manual controls of its own and does not support any external input or output devices. It also does not have a maintenance access interface.

The module does not implement a trusted channel.

Not applicable as the module does not implement a control output interface.

The module uses technical means to inhibit the data output interface during pre-operational self-tests, during zeroization of nontemporary SSPs that are under control of the module, and when in an error state. This document may be reproduced and distributed only in its original entirely without revision.

The module does not implement operator authentication.

Table 16: Roles mechanisms, the Crypto Officer role is implicitly assumed by the operator when calling any of the module’s APIs. Note that the module does not allow the operator to perform maintenance services and thus does not support a maintenance role.

G This document may be reproduced and distributed only in its original entirely without revision.

RSA PKCS1v1.5 with precomputed with precomputed This document may be reproduced and distributed only in its original entirely without revision.

W,E This document may be reproduced and distributed only in its original entirely without revision.

W,E This document may be reproduced and distributed only in its original entirely without revision.

RSA PKCS1v1.5 G,R,W,E G,R,W,E W,E R,W,E W,E W,E This document may be reproduced and distributed only in its original entirely without revision.

with precomputed with precomputed RSA PKCS1v1.5 W,E W,E This document may be reproduced and distributed only in its original entirely without revision.

G,R,W,E G,R,W,E W,E G,R,W,E G,R,W,E This document may be reproduced and distributed only in its original entirely without revision.

W,E R,W,E G,R,W,E W,E W,E W,E W,E This document may be reproduced and distributed only in its original entirely without revision.

W,E W,E W,E G,R G,R This document may be reproduced and distributed only in its original entirely without revision.

G,R G,R G,R R,W R,W R,W R,W R,W This document may be reproduced and distributed only in its original entirely without revision.

R,W R,W R,W R,W R,W R,W R,W R,W This document may be reproduced and distributed only in its original entirely without revision.

R,W R,W Table 17: Approved Services For the table above, the following notation is used to indicate the type of SSP access:

• 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.
• Z = Zeroize: The module zeroizes the SSP. The module operator can identify whether a security service was performed as an approved or non-approved service using the implemented approved service indicator. The implemented service indicator is compliant with IG 2.4.C example scenario 1. This indicator is provided by every API that can determine from the passed parameters whether the service is approved or not. The expected return value for a successfully performed call of an approved security service is RC_FIPS_APPROVED (value “1”). Other successful approved and non-approved operations either return the value “0” or do not have a return code. Failed operations return a value less than “0”. Some APIs may be executed as either an approved or non-approved security service depending on the provided parameters. For example, for some algorithms there are restrictions concerning the key length or the underlying elliptic curves that are considered approved. The approved state of services further depends on the module’s mode of operation. For more information on this, please refer to Section 2.4 Modes of Operation describing the available modes of operation, and Section 2.5 Algorithms listing implemented approved and non-approved algorithms. Note that when key pairs are imported for digital signature generation / verification, the approved service indicator for both operations is set based on the properties of the private key. Other than for the self-tests of non-approved algorithms during module initialization or when manually invoked by the operator, the module does not utilize any non-approved algorithms as part of an approved service. This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

Table 18: Non-Approved Services Note that the approved internal Counter DRBG instance is used by some of the non-approved services per the allowance in IG 2.4.A. For a detailed description of the purposes for which this DRBG instance is used, please refer to Section 2.8 RBG and Entropy.

The module does not support software/firmware loading.

The module does not implement a bypass capability. This document may be reproduced and distributed only in its original entirely without revision.

The module does not implement a self-initiated output capability. This document may be reproduced and distributed only in its original entirely without revision.

The module uses an HMAC-SHA2-256 (see Section 2.5 Algorithms for the CAVP certificate number) as the approved integrity technique for the software/firmware integrity test. The HMAC is computed over the entire shared library file during module initialization. The reference value for the integrity test is stored in a separate file, with the exact delivery format depending on the used platform (see Section 11.1 Installation, Initialization, and Startup Procedures for more details):

• On Windows platforms, the module comprises the dynamic link library file slcryptokernel.dll accompanied by the file slcryptokernel.dll.sha256 containing the reference value for the software/firmware integrity test.
• On Linux and UNIX based platforms, the module comprises the shared library file libslcryptokernel.<extension> accompanied by the file libslcryptokernel.<extension>.sha256 containing the reference value for the software/firmware integrity test. Where “<extension>” stands for the OS-specific extension for shared libraries. These extensions are “dylib” for macOS and “so” for the other Linux/Unix operating systems.

The integrity test can be executed on demand by re-initializing the module. This process is described in more detail in Section 10.5 Operator Initiation of Self-Tests. This document may be reproduced and distributed only in its original entirely without revision.

Type of Operational Environment: Modifiable How Requirements are Satisfied: This module is expected to be run in operational environments where each user application runs in a virtually-separated, independent process with its own address space. By default, all tested operating systems (Windows as well as the Unix derivates) provide such a separation so that no other, unauthorized process can access or modify SSPs while the cryptographic module is in use. The virtual memory provided by the operating systems also ensures that every instance of the module has exclusive control over its own SSPs. The module does not spawn any processes or threads. It uses only memory within the virtual address space of the process and does not communicate with any other process in any way (e.g., using inter-process communication such as pipes). The application linked to the module and running in the same virtual memory area is expected to only interact with the module through the defined interfaces.

The operator of the module shall not configure the operating systems in a way that disables the process separation mechanisms referenced in Section 6.1 Operational Environment Type and Requirements. This document may be reproduced and distributed only in its original entirely without revision.

The module comprises only software. It runs on operational environments with a multiple-chip standalone embodiment. It has no physical protection mechanisms. Therefore, the physical security requirements are not applicable. This document may be reproduced and distributed only in its original entirely without revision.

The module does not implement any non-invasive security measures that are referenced in SP 800-140F. This document may be reproduced and distributed only in its original entirely without revision.

Table 19: Storage Areas The state of the internal Counter DRBG instance is stored at most until the end of the module’s runtime in volatile memory allocated by the module itself. All other SSPs used by the module are stored in the volatile memory shared with the linked application. SSPs passed to the module via memory pointers by the linked application are only accessed and used within a single API call. The module does not keep references to these SSPs after the API call is done. To allow chaining of related APIs (e.g., for encrypting multiple blocks of data) the state of certain security functions is stored in context objects that include any required SSPs (either by reference or directly as byte arrays). These objects are passed back and forth between the module and the linked application for each API call. Where necessary to allow for procedural zeroization of such objects, the module provides information about the location and size of allocated memory to the linked application (see also Section

Note that the linked application mentioned above runs inside the module’s Tested Operational Environment’s Physical Perimeter (TOEPP) but outside its cryptographic boundary. It resides in the same volatile memory area as the module.

Table 20: SSP Input-Output Methods This document may be reproduced and distributed only in its original entirely without revision.

SSPs are passed between the module and the linked application running via API input and output parameters in plaintext. The parameters contain pointers to memory locations inside the shared volatile memory. As required, the module does not output any SSPs to locations outside the TOEPP. For other key establishment methods, please refer to Section 2.10 Key Establishment.

Table 21: SSP Zeroization Methods As detailed in Section 9.1 Storage Areas, the module does not store any references to SSPs other than for the internal Counter control of the module only for individual API calls because these SSPs are otherwise under full control of the linked application. This document may be reproduced and distributed only in its original entirely without revision.

• Generated internally by the module (e.g., during intermediate steps of cryptographic operations), or
• Derived from operator-supplied inputs within a single API call are automatically overwritten with zeroes before control is returned to the calling application. This ensures that no residual sensitive data remains in memory once the cryptographic operation is complete. This process is performed internally by the module and does not require caller intervention. The internal Counter DRBG instance can be explicitly zeroized by invoking the module_final() API function. This function securely terminates the module and overwrites the DRBG state with zeroes, ensuring complete zeroization. Additionally, when the module is unloaded—either by the application or due to process termination—the module’s destructor is automatically invoked. This destructor calls the same internal zeroization logic, ensuring that the DRBG state is securely overwritten with zeroes before the module is fully deallocated. A successful return from the module_final() function, or the confirmed unloading of the module, indicates that all persistent SSPs maintained by the module have been securely zeroized. The operator can procedurally zeroize SSPs not under control of the module by overwriting the volatile memory where they are located. Successful zeroization can be ensured by re-reading the zeroized memory and checking whether it was completely overwritten before it is deallocated.

1.2) This document may be reproduced and distributed only in its original entirely without revision.

1.3) This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

V This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

Table 22: SSP Table 1 This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

Table 23: SSP Table 2 This document may be reproduced and distributed only in its original entirely without revision.

For the use of the above SSPs by the module’s approved services, please refer to Section 4.3 Approved Services. The module’s non-approved services do not access any of the module’s SSPs other than the Counter DRBG state, which is permitted per IG 2.4.A. For details on the use of the DRBG by the approved and non-approved services, please refer to Section 2.8 RBG and Entropy. Note that the HMAC key used for the integrity test is not considered as an SSP. Keys used by non-approved services are also not considered as SSPs.

Information on the transitions for the CMVP-approved algorithms and security functions are provided in SP 800-57 Part 1 Revision 5 and SP 800-131A Revision 2 as well as on the NIST website. At the time of publication of this Security Policy, the following transitions are identified, which take effect in 2031:

• Transition of the minimum security strength from 112 to 128 bits.
• Deprecation of SHA-1. This document may be reproduced and distributed only in its original entirely without revision.

HMACSHA2-256 Table 24: Pre-Operational Self-Tests The module only implements one pre-operational self-test. This test is performed under control of the module when the function crypt_init is called by the operator after the module was loaded. This function either returns RC_FIPS_APPROVED (value “1”) when all self-tests passed or an error code when something went wrong during initialization. Only when the return value is RC_FIPS_APPROVED, the module returns pointers to the exported APIs required to execute the module’s other security services. In addition to the pre-operational self-test described above, the module also automatically executes the Cryptographic Algorithm SelfTests (CASTs) described in Section 10.2 Conditional Self-Tests during its initialization. In case of a failure in at least one of the selftests executed during start-up, the module enters an error state (see Section 10.4 Error States for details). Please note that the module neither implements a pre-operational bypass test, as it does not implement a bypass functionality, nor a pre-operational critical function test, as all functions critical to its secure operation are already covered by other self-tests.

N/A This document may be reproduced and distributed only in its original entirely without revision.

N/A N/A N/A N/A N/A N/A N/A N/A This document may be reproduced and distributed only in its original entirely without revision.

N/A N/A This document may be reproduced and distributed only in its original entirely without revision.

Padding: PKCS1v1.5 Padding: PKCS1v1.5 This document may be reproduced and distributed only in its original entirely without revision.

N/A Faultdetection Padding: PKCS1v1.5 N/A N/A This document may be reproduced and distributed only in its original entirely without revision.

N/A N/A N/A Table 25: Conditional Self-Tests Since the module does not implement the corresponding functionality, it does not implement a conditional software/firmware load test, manual entry test, bypass test, or critical function test. As explained in Section 2.2 Tested and Vendor Affirmed Module Version and Identification, the module can be configured to use different PAAs for certain algorithms. These PAAs must be configured before the module’s self-tests are performed during module initialization. During module initialization, the module performs the conditional self-tests using the activated PAAs. While the module is in its initialized state, re-configuration of the activated PAAs is blocked. Changing the activated PAAs thus requires a re-initialization of the module (see Section 11.2 Administrator Guidance for details). Note that the module also implements self-tests for some non-approved algorithms (e.g., MD5 and RC4), but these self-tests are not listed here.

This document may be reproduced and distributed only in its original entirely without revision.

Table 26: Pre-Operational Periodic Information This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision.

Table 27: Conditional Periodic Information The module does not perform any periodic self-testing on its own. When desired, the operator can manually perform periodic selftesting using the means described in Section 10.5 Operator Initiation of Self-Tests.

Table 28: Error States The module implements two different error states. In case of a failure during the self-tests performed during module start-up (i.e., the pre-operational integrity test and the CASTs), the module enters an error state that requires operator intervention to recover from. An initialization. If the module initialization fails due to failed self-tests or any other problem, the module does not return pointers to its other APIs, which are required to execute the module’s cryptographic security services. It also behaves as if it is still in its uninitialized state, thereby preventing the use of any previously returned function pointers. Exiting this error state is possible by reinitializing the module (see Section 10.5 Operator Initiation of Self-Tests for details). This document may be reproduced and distributed only in its original entirely without revision.

In case of a failure during a conditional self-test that is not automatically performed during start-up (see Section 10.2 Conditional SelfTests), the module briefly enters a different, transient error state. An error indicator is provided by the return value of the function that invoked the self-test. Output of the generated or imported key pair that caused the conditional self-test error is inhibited. Afterwards, the module automatically recovers from this error state. The concerned conditional self-test is repeated the next time the corresponding operation is performed (e.g., the pair-wise consistency tests are performed for each generated key pair). Table 29 lists the expected error codes (error indicators) related to failures of performed self-tests. More detailed information about which self-tests performed during module initialization failed can be obtained using the sec_crypto_get_feature_info API. Table 29: Error Causes and Expected Return Codes Please note that the module does not enter an error state when a failure unrelated to the conditional self-tests is detected after successful module initialization (e.g., because an invalid padding was detected, memory could not be allocated, or an assurance check failed). Instead, the function return values indicate to the operator the type of occurred failure.

All self-tests listed in Section 10.3 Periodic Self-Test Information with “module initialization” listed as their execution condition can be executed on-demand using the ‘initialize and self-test’ service described in Section 4.3 Approved Services. The exact procedure to use this service depends on the current state of the module:

• When the module is in its initialized state, the module must first be finalized using the module_final function. Then, the module must be re-initialized by calling crypt_init function.
• When the module is not yet initialized or is in its error state, only the crypt_init function must be called. This document may be reproduced and distributed only in its original entirely without revision.

Two files are provided for the installation of the module as explained in Section 2.2 Tested and Vendor Affirmed Module Version and Identification. The file names depend on the operating system for which the module is provided. The file names for the tested operational environments are listed in Table 30. Table 30: Module File Names and Checksums The module is delivered as part of multiple applications developed by SAP SE. Each application’s installation package contains the FIPS 140-3 certified module. The Crypto Officer should use the SHA2-256 checksum provided in Table 30 to check that the desired version of the module is installed. This document may be reproduced and distributed only in its original entirely without revision.

The Crypto Officer should also make sure that the files are installed with the access permissions shown in Table 31. The following terms are used in this table:

• Administrator: A Crypto Officer with administrative rights of the system on which the module is to be installed. This may also refer to any program executed using the administrator’s account on the system.
• Non-Administrator: A Crypto Officer without administrative rights on the system on which the module is to be installed. This may also refer to any program executed without administrative rights on the system. Table 31: File Access Permissions Afterwards, the module can be linked to the operator’s target application at link time or runtime as a shared library. After the module is linked and then loaded by the operating system, the Crypto Officer shall call the crypt_init function to initialize the module under consideration of the restrictions given in Section 2.4 Modes of Operation. Thereby, they can provide additional data to be used in the derivation of the additional input and personalization string used for the instantiation of the module’s internal Counter DRBG instance (see Section 2.8 RBG and Entropy). When the crypt_init function is called, the module performs the self-tests as indicated in Section 10 Self-Tests to verify the correct operation of the module's functionality and its integrity. The Crypto Officer shall make sure that the HMAC file, which contains the HMAC-SHA2-256 reference value for the integrity test, has not been modified. After the function terminates, the Crypto Officer shall check its return value. If this value does not equal “1”, then the module’s initialization has failed, and the module’s cryptographic functionality cannot be used. If initialization fails, the Crypto Officer should further examine the return value to determine the cause of failure and attempt to rectify the problem. If initialization succeeds, the Crypto Officer will receive a list of function pointers that allow using the module’s approved cryptographic methods. After the module’s successful initialization, the Crypto Officer may, at any time, finalize the module by calling module_final and initialize it by invoking crypt_init again. As this constitutes a re-initialization of the module, they shall again follow the initialization procedure outlined above. After the module has been finalized, the function pointers returned by the crypt_init function are disabled thereby preventing the further use of the module’s cryptographic security services. Detailed explanations of the functions crypt_init and module_final including their parameters and return values can be found in the guidance documentation (see Section 11.2 Administrator Guidance for details). This document may be reproduced and distributed only in its original entirely without revision.

The administrator and non-administrator guidance is provided in the following documents that are provided by SAP SE together with the module:

• “FIPS PUB 140-3, Installation Guide of SAP CommonCryptoLib Crypto Kernel v8.6.1” (v1.2, dated 2024-07-26),
• “FIPS PUB 140-3, Cryptographic Ports and Interfaces of SAP CommonCryptoLib Crypto Kernel v8.6.1” (v1.7, dated 2024-08-13). These documents provide a full reference of all Application Programming Interfaces (APIs) that can be used to invoke the module’s services. Important excerpts of these documents are also reproduced in this Security Policy (see Section 11.1 Installation, Initialization, and Startup Procedures). More information on the use of the implemented entropy source is provided in the document “FIPS PUB 140-3, SP 800-90B NonProprietary Public Use Document, SAP CommonCryptoLib Entropy Collector 1.0.0” (v1.3, dated 2024-08-07). Besides the information provided in these guidance documents and the previous sections of this Security Policy, the Crypto Officer shall also consider the following statements when intending to operate the module in an approved way:
• The module shall be operated in its approved mode described in Section 2.4 Modes of Operation. It shall not be used in its noncompliant state.
• The requirements for the implemented cryptographic algorithms citied in Section 2.7 Algorithm Specific Information shall be followed.
• The application linked to the module shall only interact with the module through the defined interfaces and not modify any objects allocated by the module while they are in use or if a pointer to the objects is to be passed to the module for another API call.
• The steps for procedural zeroization given in Section 9.3 SSP Zeroization Methods shall be observed.

The same set of guidance is applicable to administrator and non-administrator users of the module. Therefore, please refer to Section 11.2 Administrator Guidance for the non-administrator guidance.

Please refer to Section 11.1 Installation, Initialization, and Startup Procedures and Section 11.2 Administrator Guidance for a description of the module’s rules of operation. This document may be reproduced and distributed only in its original entirely without revision.

The module does not require any maintenance.

The module does not store any SSPs persistently. Secure sanitation of the module can thus be performed by using the ‘finalize and zeroize service to zeroize all SSPs that are under control of the module and by procedurally zeroizing of all other SSPs that are under control of the operator. For details, please see Section 4.3 Approved Services and Section 9.3 SSP Zeroization Methods. This document may be reproduced and distributed only in its original entirely without revision.

The module implements the following measures to mitigate attacks other than those already addressed by functionality required by FIPS 140-3 Security Level 1:

• The module implements blinding for RSA private key operations (decryption and signature generation) and ECDSA signature generation to mitigate timing attacks and other side-channel attacks. The blinding factor is randomly generated.

The use of a random blinding factor that is unknown to an attacker makes it more difficult to perform successful timing attacks on RSA private key and ECDSA signature generation operations, as the execution time is not only dependent on the private key value. However, it is important to note that blinding does not completely eliminate these attacks.

As blinding is performed transparently within the boundary of the cryptographic module, no user configuration or interaction is involved. This document may be reproduced and distributed only in its original entirely without revision.

This document may be reproduced and distributed only in its original entirely without revision. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies. See

Referenced URLs

• http://www.sap.com/corporate-en/legal/copyright/index.epx