Dynatrace Cryptographic Module

Certificate

Approved Algorithms (44)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Dynatrace Cryptographic Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>library named: openssl</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    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"]
    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"]
    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
  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 C3,C5,C6 clue;
  class I3,I5,I6 infer;
  class R3,R5,R6 risk;
  class E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Dynatrace Cryptographic Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Show Status</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>library named: openssl</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C3 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Dynatrace LLC Dynatrace Cryptographic Module Software Version: 1.1 FIPS Security Level: 1 Document Version: 0.9 Prepared for: Prepared by: Dynatrace LLC

Waltham, MA 02451 United States of America Corsec Security, Inc.

Fairfax, VA 22033 United States of America Phone: +1 781 530 1000 www.dynatrace.com Phone: +1 703 267 6050 www.corsec.com

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

• The Dynatrace website (www.dynatrace.com) contains information on the full line of products from Dynatrace.
• The search page on the CMVP website (https://csrc.nist.gov/Projects/cryptographic-module-validationprogram/Validated-Modules/Search) can be used to locate and obtain vendor contact information for technical or sales-related questions about the module. Document Organization ISO/IEC 19790 Annex B uses the same section naming convention as ISO/IEC 19790 section 7 - Security requirements. For example, Annex B section B.2.1 is named “General” and B.2.2 is named “Cryptographic module specification,” which is the same as ISO/IEC 19790 section 7.1 and section 7.2, respectively. Therefore, the format of this Security Policy is presented in the same order as indicated in Annex B, starting with “General” and ending with “Mitigation of other attacks.” If sections are not applicable, they have been marked as such in this document. Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 Table of Contents 1. 2. 2.1 2.2 2.3 2.4 3. 4. 4.1 4.2 4.3 5. 6. 7. 8. 9. 9.1 9.2 9.3 9.4 9.5 Appendix A. Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

Appendix B. February 6, 2025 Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 List of Tables List of Figures Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

1. February 6, 2025 underlying infrastructure, and end user experiences. Dynatrace consists of OneAgent, ActiveGate, and Cluster software components. Dynatrace OneAgent software is installed on hosts to automatically discover and collect monitoring data from an information technology environment. Important metrics can be forwarded to a Dynatrace Cluster either directly or via a Dynatrace ActiveGate. The Dynatrace Cryptographic Module 1.1 is a cryptographic library embedded in Dynatrace’s OneAgent and ActiveGate application software. The Dynatrace Cryptographic Module v1.1 supplies the cryptographic functionality for encryption and decryption, digital signature functions, hashing, message authentication, key establishment, and random number generation in support of general data protection functionality and secure communications protocols, including TLS1 1.2/1.3. The Dynatrace Cryptographic Module is validated at the FIPS 140-3 section levels shown in Table 1. [Number Below] N/A N/A N/A

2. February 6, 2025 Cryptographic Module Specification The Dynatrace Cryptographic Module 1.1 is a software module with a multi-chip standalone embodiment. The module is designed to operate within a modifiable operational environment. 2.1 Operational Environments The module was tested and found to be compliant with FIPS 140-3 requirements on the environment listed in Table
3. Table 2 – Tested Operational Environments # The module is designed to utilize the AES-NI2 extended instruction set when available on the host platform’s CPU for processor algorithm acceleration (PAA) of its AES implementation. The vendor affirms the module’s continued validation compliance when operating on the environments listed in Table
4. Table 3 – Vendor-Affirmed Operational Environments #

Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 # 4.5, 4.6, 4.7 Please refer to https://www.dynatrace.com/support/help/technology-support/ for details on the vendor affirmed OEs. The cryptographic module maintains validation compliance when operating on any general-purpose computer (GPC) provided that the GPC uses any single-user operating system/mode specified on the validation certificate, or another compatible single-user operating system. The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported to an operational environment not listed on the validation certificate. Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

2.2 February 6, 2025 Algorithm Implementations The module implements cryptographic algorithms in the following providers:

• Dynatrace Cryptographic Module (libssl) version 1.1 (Cert. A3359) Validation certificates for each Approved security function are listed in Table 4. Table 4
• Approved Algorithms

3 This table includes vendor-affirmed algorithms that are approved but CAVP testing is not yet available.

Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

24 KAS-ECC-SSC

• Key Agreement Scheme
• Elliptic Curve Cryptography - Shared Secret Computation

25 KAS-FFC-SSC

• Key Agreement Scheme - Finite Field Cryptography - Shared Secret Computation

CVL

• Component Validation List

Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

PSS

• Probabilistic Signature Scheme ©2025 Dynatrace LLC

February 6, 2025 D.G. D.G. D.G. D.G. NOTE: The module offers algorithms in the Approved mode of operation that provide less than 112 bits of security strength. These algorithms are Approved for legacy use only (refer to NIST SP 800-131Arev2 for additional details). KTS

• Key Transport Scheme Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 The vendor affirms the following cryptographic security methods:

• Cryptographic key generation
• In compliance with sections 4 and 5.1 of NIST SP 800-133rev2, the module uses its Approved DRBG to generate random values and seeds used for asymmetric key generation. The generated seed is an unmodified output from the DRBG. The cryptographic module invokes a GET function to obtain entropy for random number generation (the module requests 256 bits of entropy from the calling application per request), and then passively receives entropy from the calling application while having no knowledge of the entropy source and exercising no control over the amount or the quality of the obtained entropy. The calling application and its entropy sources are located within the operational environment inside the module’s physical perimeter but outside the cryptographic boundary. Thus, there is no assurance of the minimum strength of the generated SSPs (e.g., keys). The module implements the non-Approved but allowed algorithms shown in Table 5 below. Table 5
• Non-Approved Algorithms Allowed in the Approved Mode of Operation The module does not offer non-Approved algorithms allowed for use in the Approved mode of operation with no security claimed on their use. The module employs the non-Approved algorithms shown in Table 6 below. These algorithms shall not be used in the module’s Approved mode of operation. Table 6
• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 2.3 Cryptographic Boundary As a software cryptographic module, the module has no physical components. The physical perimeter of the cryptographic module is defined by each host device on which the module is installed. Figure 1 below illustrates a block diagram of a typical GPC and the module’s physical perimeter.

Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

Hardware Management February 6, 2025 DVD Network Interface RAM HDD Clock Generator SCSI/SATA Controller LEDs/LCD Serial CPU I/O Hub Audio Cache Power Interface PCI/PCIe Slots USB BIOS Graphics Controller PCI/PCIe Slots External Power Supply KEY: BIOS

• Basic Input/Output System CPU
• Central Processing Unit SATA
• Serial Advanced Technology Attachment SCSI
• Small Computer System Interface PCI
• Peripheral Component Interconnect LED
• Light Emitting Diode PCIe
• PCI express HDD
• Hard Disk Drive DVD
• Digital Video Disc USB
• Universal Serial Bus RAM
• Random Access Memory LCD
• Liquid Crystal Display Figure 1
• GPC Block Diagram The module’s cryptographic boundary consists of all functionalities contained within the module’s compiled source code and comprises the following components:
• libcrypto (cryptographic primitives library file) libssl (TLS protocol library file) HMAC digest file for libcrypto and libssl integrity checks (digest file name dependent on file name of library/executable to which the libcrypto and libssl components are statically linked) The cryptographic boundary is the contiguous perimeter that surrounds all memory-mapped functionality provided by the module when loaded and stored in the host device’s memory. The module is entirely contained within the physical perimeter. Figure 2 shows the logical block diagram of the module executing in memory and its interactions with surrounding software components, as well as the module’s physical perimeter and cryptographic boundary. Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 libssl HMAC digest Calling Application KEY: libcrypto Cryptographic Boundary Physical Perimeter Data Input Data Output Control Input Control Output Status Output System Calls Operating System CPU Memory Storage Ports Host Device Figure 2

• Module Block Diagram (with Cryptographic Boundaries) 2.4 Modes of Operation The module supports two modes of operation: Approved and Non-Approved. The module operates in the Approved mode when all pre-operational self-tests have completed successfully, and only Approved services are invoked. Table 4 and Table 5 list the Approved and allowed algorithms, while Table 9 provides descriptions of the Approved services. The module alternates on a service-by-service basis between Approved and non-Approved modes of operation. The module will switch to the non-Approved mode upon execution of a non-Approved service. The module will switch back to the Approved mode upon execution of an Approved service. Table 6 lists the non-Approved algorithms implemented by the module, while Table 10 below lists the services that constitute the non-Approved mode. When following the guidance in section 11.5 of this document, CSPs are not shared between Approved and nonApproved services and modes of operation. Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

3. February 6, 2025 FIPS 140-3 defines the following logical interfaces for cryptographic modules: • • • • • As a software library, the cryptographic module has no direct access to any of the host platform’s physical ports, as it communicates only to the calling application via its well-defined API. A mapping of the approved interfaces and the module’s logical ports and interfaces can be found in Table
4. Note that the module does not output Table 7 – Ports and Interfaces ©2025 Dynatrace LLC

4. February 6, 2025 Roles, Services, and Authentication The sections below describe the module’s authorized roles, services, and operator authentication methods. 4.1 Authorized Roles The module supports two roles that authorized operators can assume:

• Crypto Officer - The CO role performs cryptographic initialization or management functions and general security services.
• User
• The User role performs general security services, including cryptographic operations and other approved security functions. The module does not support multiple concurrent operators. The calling application that loaded the module is its only operator. Table 8 below lists the supported roles, along with the services (including input and output) available to each role. Table 8
• Roles, Service Commands, Input and Output

Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

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

• G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g., the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

• February 6, 2025 Table 9
• Approved Services Perform preoperational selftests Perform selftests ondemand N/A E N/A N/A N/A N/A N/A N/A Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 N/A * Per FIPS 140-3 IG 2.4.C, the Show Status, Zeroize, and Show Versioning Information services do not require an Approved service indicator. The following services/algorithms are allowed for legacy use only:

• Digital signature verification using ECDSA with curves B-163, K-163, and P-192 Digital signature verification using DSA with key lengths of 1024 bits Digital signature verification using RSA with modulus lengths of 1024 bits Table 10 below lists the non-approved services available to module operators. Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 Table 10

• Non-Approved Services Perform key unencapsulation (nonapproved) Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

5. February 6, 2025 Software/Firmware Security All software components within the cryptographic boundary are verified using an approved integrity technique implemented within the cryptographic module itself. The module implements an integrity test technique consisting of a single encompassing HMAC SHA2-256 digest file that covers both library files; failure of the integrity test will cause the module to enter a critical error state. Details regarding the keys used for the integrity checks can be found in Table
6. The module’s integrity check is performed automatically at module instantiation (i.e., when the module is loaded into memory for execution) without action from the module operator. The CO can initiate the pre-operational tests on demand by restarting the calling application, rebooting/power-cycling the host server, or issuing the FIPS_selftest() API command. The Dynatrace Cryptographic Module is not delivered to end-users as a standalone offering. Rather, it is a prebuilt integrated component of Dynatrace’s application software. Dynatrace does not provide end-users with any mechanisms to directly access the module, its source code, its APIs, or any information sent to/from the module. Thus, end-users have no ability to independently load the module onto target platforms. No configuration steps are required to be performed by end-users, and no end-user action is required to initialize the module for operation. The module is designed with a default entry point (DEP) that ensures that the pre-operational tests and conditional CASTs are initiated automatically when the module is loaded. Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

6. February 6, 2025 Operational Environment The Dynatrace Cryptographic Module comprises a software cryptographic library that executes in a modifiable operational environment. The cryptographic module has control over its own SSPs. The process and memory management functionality of the host device’s OS prevents unauthorized access to plaintext private and secret keys, intermediate key generation values and other SSPs by external processes during module execution. The module only allows access to SSPs through its well-defined API. The operational environment provides the capability to separate individual application processes from each other by preventing uncontrolled access to CSPs and uncontrolled modifications of SSPs regardless of whether this data is in the process memory or stored on persistent storage within the operational environment. Processes that are spawned by the module are owned by the module and are not owned by external processes/operators. Please refer to section 2.1 of this document for a list/description of the applicable operational environments. Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

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

8. February 6, 2025 Non-Invasive Security This section is not applicable. There are currently no approved non-invasive mitigation techniques references in ISO/IEC 19790:2021 Annex F. Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025

9. Management 9.1 Keys and Other SSPs The module supports the keys and other SSPs listed in Table
10. Table 11 – Keys Preoperational Preoperational Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 9.2 DRBGs The module implements the following Approved DRBG(s):

• This DRBG is used to generate random values at the request of the calling application. Outputs from the DRBGs are also used in the generation of seeds for asymmetric key pair generation. The module implements the following non-Approved DRBG(s):
• 9.3 ANSI X9.31 RNG Hash-based DRBG (non-approved) HMAC-based DRBG (non-approved) There is no mechanism within the module’s cryptographic boundary for the persistent storage of SSPs. The module stores DRBG state values for the lifetime of the DRBG instance. The module uses SSPs passed in on the stack by the calling application and does not store these SSPs beyond the lifetime of the API call. Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

9.4 February 6, 2025 SSP Zeroization Methods Maintenance, including protection and zeroization, of any keys and CSPs that exist outside the module’s cryptographic boundary are the responsibility of the end-user. For the zeroization of keys in volatile memory, module operators can unload the module from memory or reboot/power-cycle the host device. 9.5 Table 12

• Non-Deterministic Random Number Generation Specification ©2025 Dynatrace LLC

February 6, 2025 10. Self-Tests Both pre-operational and conditional self-tests are performed by the module. Pre-operational tests are performed between the time the cryptographic module is instantiated and before the module transitions to the operational state. Conditional self-tests are performed by the module during module operation when certain conditions exist. The following sections list the self-tests performed by the module, their expected error status, and the error resolutions. 10.1 Pre-Operational Self-Tests The module performs the following pre-operational self-test(s):

• 10.2 Software integrity test for libcrypto and libssl (using an HMAC SHA2-256 digest) Conditional Self-Tests The module performs the following conditional self-tests:
• Conditional cryptographic algorithm self-tests (CASTs)
• AES ECB decrypt KAT38 (128-bit)
• AES CCM encrypt KAT (192-bit)
• AES CCM decrypt KAT (192-bit)
• AES GCM encrypt KAT (128-bit)
• AES GCM decrypt KAT (128-bit)
• AES CMAC generate KAT (CBC mode; 128/192/256-bit key lengths)
• AES CMAC verify KAT (CBC mode; 128/192/256-bit key lengths)
• CTR_DRBG KAT (AES, 256-bit, with derivation function)
• CTR_DRBG instantiate/generate/reseed KAT (AES, 256-bit)
• DSA sign KAT (2048-bit; SHA2-256)
• DSA verify KAT (2048-bit; SHA2-256)
• ECDSA sign KAT (P-224 and K-233 curve, SHA2-256)
• ECDSA verify KAT (P-224 and K-233 curve, SHA2-256)
• RSA sign KAT (2048-bit; SHA2-256; PKCS#1.5 scheme)
• RSA verify KAT (2048-bit; SHA2-256; PKCS#1.5 scheme)
• HMAC KATs (SHA-1, SHA2-224, SHA2-256, SHA2-384, SHA2-512)
• SHA-1 KAT
• SHA-2 KATs (SHA2-224, SHA2-256, SHA2-384, SHA2-512)
• FFC DH Shared Secret “Z” Computation KAT (2048-bit)
• ECC CDH Shared Secret “Z” Computation KAT (P-224 curve)
• TLS 1.2 KDF KAT
• TLS 1.3 KDF KAT

Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 To ensure all CASTs are performed prior to the first operational use of the associated algorithm, all CASTs are performed during the module’s initial power-up sequence. The SHA and HMAC KATs are performed prior to the pre-operational software integrity test; all other CASTs are executed after the successful completion of the software integrity test.

• Conditional pair-wise consistency tests (PCTs)
• DSA sign/verify PCT39
• ECDSA sign/verify PCT
• RSA sign/verify PCT
• DH key generation PCT
• ECDH key generation PCT 10.3 On-Demand Self-Testing The CO can initiate the pre-operational self-tests and conditional CASTs on demand for periodic testing of the module by re-instantiating the module, rebooting/power-cycling the host device, or issuing the FIPS_selftest() API command. 10.4 Self-Test Failure Handling The module reaches the critical error state when any self-test fails. Upon test failure, the module immediately terminates the calling application’s API call with a returned error code and sets an internal flag, signaling the error condition. For any subsequent request made by the calling application for cryptographic services, the module will return a failure indicator, thereby disabling all access to its cryptographic functions, sensitive security parameters (SSPs), and data output services while the error condition persists. To recover, the module must be reinitialized by restarting the calling application or via reboot/power-cycle of the host platform. If the pre-operational self-tests complete successfully, then the module can resume normal operations. If the module continues to experience self-test failures after reinitializing, then the module will not be able to resume normal operations, and the CO should contact Dynatrace LLC for assistance.

Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 11. Life-Cycle Assurance The sections below describe how to ensure the module is operating in its validated configuration, including the following:

• Procedures for secure installation, initialization, startup, and operation of the module Maintenance requirements Administrator and non-Administrator guidance Operating the module without following the guidance herein will result in non-compliant behavior and is outside the scope of this Security Policy. 11.1 Secure Installation As the module is an integrated component of Dynatrace’s application software, module operators have no ability to independently load the module onto the target platform. The module and its calling application are to be installed on a platform specified in section 2.1 or one where portability is maintained. Dynatrace does not provide any mechanisms to directly access the module, its source code, its APIs, or any information sent between it and other Dynatrace applications. 11.2 Initialization This module is designed to support Dynatrace applications, and these applications are the sole consumers of the cryptographic services provided by the module. No end-user action is required to initialize the module for operation; the calling application performs any actions required to initialize the module. The pre-operational integrity test and conditional CASTs are performed automatically via a default entry point (DEP) when the module is loaded for execution, without any specific action from the calling application or the end-user. End-users have no means to short-circuit or bypass these actions. Failure of any of the initialization actions will result in a failure of the module to load for execution. 11.3 Startup No setup steps are required to be performed by end-users. 11.4 Administrator Guidance There are no specific management activities required of the CO role to ensure that the module runs securely. However, if any irregular activity is noticed or the module is consistently reporting errors, then Dynatrace Customer Support should be contacted. The following list provides additional guidance for the CO: Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025

• The fips_post_status()API can be used to determine the module’s operational status. A non-zero return value indicates that the module has passed all pre-operational self-tests and is currently in its Approved mode.
• The OpenSSL_version() API can be used to obtain the module’s versioning information. This information will include the module name and version, which can be correlated with the module’s validation record. 11.5 Non-Administrator Guidance The following list provides additional policies for the User role:
• The cryptographic module’s services are designed to be provided to a calling application. Excluding the use of the NIST-defined elliptic curves as trusted third-party domain parameters, all other assurances from FIPS PUB 186-4 (including those required of the intended signatory and the signature verifier) are outside the scope of the module and are the responsibility of the calling application.
• The module performs assurances for its key agreement schemes as specified in the following sections of NIST SP 800-56Arev3: o
• Section 5.5.2 (for assurances of domain parameter validity) Section 5.6.2.1 (for assurances required by the key pair owner) The module includes the capability to provide the required recipient assurance of ephemeral public key validity specified in section 5.6.2.2.2 of NIST SP 800-56Arev3. However, since public keys from other modules are not received directly by this module (those keys are received by the calling application), the module has no knowledge of when a public key is received. Invocation of the proper module services to validate another module’s public key is the responsibility of the calling application.
• AES GCM encryption is used in the context of the TLS protocol versions 1.2 and 1.3. To meet the AES GCM (key/IV) pair uniqueness requirements from NIST SP 800-38D, the module complies with FIPS 140-3 IG C.H as follows:
• For TLS v1.2, the counter portion of the IV is strictly increasing. When the IV exhausts the maximum number of possible values for a given session key, a failure in encryption will occur and a handshake to establish a new encryption key will be required. It is the responsibility of the module operator (i.e., the first party, client, or server) to trigger this handshake in accordance with RFC 5246 when this condition is encountered. The module supports acceptable AES GCM cipher suites from section 3.3.1 of NIST SP 800-52rev2. The AES GCM IV generation is performed internally, is compliant with the RFC 5288, and shall only be used for the TLS 1.2 protocol to be compliant with scenario 1 in FIPS 140-3 IG C.H; thus, the module is compliant with NIST SP 800-52rev2.
• For TLS v1.3, a 64-bit sequence number is maintained separately for reading and writing records. Each sequence number is set to zero at the beginning of a connection and is incremented by one after reading or writing each record. Because the size of sequence numbers is 64-bit, they should Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 not wrap. If a sequence number needs to wrap, the TLS implementation is responsible for either rekeying or terminating the connection. The module supports the TLS 1.3 GCM cipher suite from section 3.3.1.2 of NIST SP 800-52rev2. The AES GCM IV generation is performed internally, is compliant with the RFC 8446, and shall only be used for the TLS 1.3 protocol to be compliant with scenario 5 in FIPS 140-3 IG C.H; thus, the module is compliant with NIST SP 800-52rev2. The module also supports internal IV generation using the module’s Approved DRBG. The IV is at least 96 bits in length per section 8.2.2 of NIST SP 800-38D. Per NIST SP 800-38D and scenario 2 of FIPS 140-3 IG C.H, the DRBG generates outputs such that the (key/IV) pair collision probability is less than 2-32. In the event that power to the module is lost and subsequently restored, the calling application must ensure that any AES-GCM keys used for encryption or decryption are re-distributed.

• The calling application is responsible for ensuring that CSPs are not shared between Approved and nonApproved services and modes of operation.
• The calling application is responsible for using entropy sources that meet the minimum security strength of 112 bits required for the CTR_DRBG as shown in NIST SP 800-90Arev1, Table 3. 11.6 Common Vulnerabilities and Exposures The Common Vulnerabilities and Exposures (CVE) program is a dictionary or glossary of vulnerabilities that have been identified for specific code bases, such as software applications or open libraries. This list allows interested parties to acquire the details of vulnerabilities by referring to a unique identifier known as the CVE ID.

The following table lists the applicable CVEs impacting the module, as well as methods of mitigation. Table 13

• CVEs

Post-submission, the module has been continually updated to provide mitigations for the CVEs listed above. These mitigations will be included in a future revalidation of the module. Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

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

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

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

February 6, 2025

• CMAC_get_service_indicator() is used to return the appropriate Approved service indicator status for CMAC requests that use AES or Triple DES. You must include the mode you want the indicator for, which are specified in the CMAC_MODE_t enum.
• HMAC_get_service_indicator() is used to return the appropriate Approved service indicator status for HMAC requests and the associated SHS algorithm.
• TLSKDF_get_service_indicator() is used to return the appropriate Approved service indicator status for TLS KDF usage excluding TLS 1.3.
• TLS1_3_kdf_get_service_indicator() is used to return the appropriate Approved service indicator status for TLS 1.3 KDF usage. This function requires the ssl.h file and is used to call the TLS1_3_get_service_indicator() function because of the SSL struct requirement. You cannot call TLS1_3_get_service_indicator() directly unless you have the SSL struct that was used.
• DRBG_get_service_indicator() is used to return the appropriate Approved service indicator status for DRBG usage. Return Values Each function returns “1” when indicating the usage of Approved services and “0” for non-approved services. Notes When calling a I<get> function, always call it after the variables have been finalized but before they are freed or destroyed. Examples The code sample below provides examples of how to check the Approved service indicators for Triple DES (3-key, in ECB mode) encryption and decryption: int 3des_indicator_test() { static EVP_CIPHER *cipher = NULL; static EVP_CIPHER_CTX *ctx; int outLen; unsigned char pltmp[8]; unsigned char citmp[8]; unsigned char key[] = { 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18, 19,20,21,22,23,24}; unsigned char plaintext[] = { 'e', 't', 'a', 'o', 'n', 'r', 'i', 's' }; cipher = EVP_des_ede3_ecb(); //Encrypt ctx = EVP_CIPHER_CTX_new(); EVP_EncryptInit_ex(ctx, cipher, NULL, key, NULL); EVP_CIPHER_CTX_set_key_length(ctx, 24); EVP_EncryptUpdate(ctx, citmp, &outLen, plaintext, 8); // Check the indicator int NID = EVP_CIPHER_CTX_nid(ctx); fprintf(stdout,"EVP_des_ede3_ecb (NID %i) encrypt indicator = %i\n", NID, EVP_cipher_get_service_indicator(ctx)); Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 EVP_CIPHER_CTX_cleanup(ctx); //Decrypt ctx = EVP_CIPHER_CTX_new(); EVP_DecryptInit_ex(ctx, cipher, NULL, key, NULL); EVP_CIPHER_CTX_set_key_length(ctx, 24); EVP_DecryptUpdate(ctx, pltmp, &outLen, citmp, 8); // Check the indicator fprintf(stdout,"EVP_des_ede3_ecb (NID %i) decrypt indicator = %i\n", NID, EVP_cipher_get_service_indicator(ctx)); EVP_CIPHER_CTX_cleanup(ctx); EVP_CIPHER_CTX_free(ctx); } Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

February 6, 2025 Appendix B. Acronyms and Abbreviations Table 14 provides definitions for the acronyms and abbreviations used in this document. Table 14

• Acronyms and Abbreviations ©2025 Dynatrace LLC

February 6, 2025 Dynatrace Cryptographic Module 1.1 ©2025 Dynatrace LLC

Prepared by: Corsec Security, Inc.

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

Referenced URLs

• www.dynatrace.com
• www.corsec.com
• https://csrc.nist.gov/Projects/cryptographic-module-validation-
• https://www.dynatrace.com/support/help/technology-support/