ISC Cryptographic Development Kit (CDK)

Certificate

Approved Algorithms (78)

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

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

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

Security Policy, page by page

ISC Cryptographic Development Kit (CDK) Software Version: 8.1.2.3 Document Version: 4.1.8 Issue Date: March 14, 2025 Authors: Michael J. Markowitz, Roger S. Schlafly, Jonathan C. Schulze-Hewett Abstract: This document is a non-proprietary FIPS 140-3 Security Policy for ISC’s Cryptographic Development Kit (CDK). It applies to CDK Version 8.1.2.3 and to all subsequent versions until otherwise indicated in new editions. It describes how the CDK meets the security requirements of FIPS 140-3 and how to run the CDK in the Approved mode. This policy was prepared as part of the FIPS 140-3 Level 1 validation of the module.

Notices reserved. Contact ISC for licensing information. Use of the CDK is subject to the terms of your license agreement with ISC. This document may be freely reproduced and distributed in its entirety without modification. CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 2

Document History Page 3 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

References CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 4

Information Security Corporation’s Cryptographic Development Kit (CDK) Version 8.1.2.3 is a software module. The software module is a shared library that contains cryptographic primitives that are cryptographic software building blocks which may be used by application developers to build securityenhanced features into their own applications. The CDK provides public-key algorithms, as well as symmetric ciphers, hashing functions, and related cryptographic and PKI operations. The CDK was designed and implemented to meet FIPS 140-3 level 1 security requirements.

ISC’s submission for FIPS 140-3 validation includes this security policy document and:

• Vendor evidence (Entropy statement, Testing statement, Crypto Officer’s Guide, Cryptographic Key Management Document, Evaluator’s Guide, and the CDK User’s Guide),
• Finite state machine model diagram and explanation,
• Proprietary source code and build configurations for various target platforms. CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 6

The following table lists the validation level met by the CDK for each area in FIPS 140-3. The CDK meets the requirements for an overall FIPS 140-3 level 1 validation. Table 1 ꟷ Security Levels The “Physical Security” section is not applicable as the module is a software only, level 1, module. The “Non-Invasive Security” and “Mitigation of Other Attacks” sections are not relevant as the CDK is a software module and does not implement any countermeasures towards special attacks. Page 7 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

Federal Information Processing Standards Publication (FIPS PUB) 140-3, Security Requirements for Cryptographic Modules, details U.S. Government requirements for cryptographic modules. Below are hyperlinks to websites containing more information on NIST cryptographic programs, FIPS 140-3, and the CDK. NIST Cryptographic Module Validation https://csrc.nist.gov/projects/cryptographic-module-validationprogram Program (CMVP) FIPS 140-3 Security Requirements https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf ISC CDK https://infoseccorp.com/cdks.html NIST Validation Lists for Cryptographic https://csrc.nist.gov/projects/cryptographic-algorithm-validationprogram/validation-search Standards – this site contains the technical implementations of the algorithms that have been validated to conform to the NIST approved algorithm standards CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 8

The CDK cryptographic module is a multi-chip standalone software module running on a standalone general-purpose computing platform. The CDK provides cryptographic services to applications through a C++ language Application Program Interface (API). The “cryptographic boundary” is defined as the binary shared link library (cdkc8123Sx64.dll or libcdkc.so.81.2.3). The CDK was tested on the following operational environments on the general-purpose computer (GPC) platforms shown in Table 2. These are the TOEPP (Tested Operational Environment’s Physical Perimeter) of the module. Table 2 ꟷ Tested Operational Environments There are no Vendor Affirmed Operational Environments at this time.

The CDK supports a wide variety of cryptographic algorithms and can be configured to run in an Approved mode or a Non-Approved mode. The keys and CSPs used for cryptographic operations are not shared between the modes of operation. Whenever possible, all Approved algorithms designed for a particular cryptographic function (such as encryption, message and entity authentication, hashing, etc.) are provided.

The Approved cryptographic algorithms implemented in the CDK and the corresponding NIST standards (or alternate standards referenced by NIST) are listed in Table 3 along with CAVP certificate numbers. When the CDK is run in the Approved mode, only algorithms in Table 3, Table 4, and Table 5 can be used. Page 9 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 10

Internal IV generation only. The AES-GCM IV is generated internally randomly (scenario 2) or as a counter (scenario 1) per IG C.H. Only Approved for Storage Applications. Page 11 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

SSP establishment methodology provides between 112 and 256-bits of encryption strength. CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 12

Page 13 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

SSP establishment methodology provides between 112 and 256-bits of encryption strength. The module implements PBKDF in a manner that is compliant with option 1a from SP 800-132, section 5.4. With the minimum password length of 8 characters, the probability of randomly guessing this parameter is 1 in 256^8. The module supports a variable iteration count as low as 1, but based on SP 800-132, section 5.2 a minimum of 1,000 is recommended. Keys derived from passwords, as shown in SP 800-132, may only be used in storage applications. Modulo sizes 6144 and 8192 are supported but have not been CAVP tested.

7 Legacy usage only. These legacy algorithms can only be used on data that was generated prior to the Legacy Date specified in

FIPS 140-3 IG C.M. CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 14

Page 15 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

Table 3 - Approved Algorithms The CDK provides the Approved methods in Table 4 for which there are no algorithm tests, but whose use is nevertheless allowed in the Approved mode. The proper implementation and functionality of CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 16

[SP 800-133 rev2]

SP 800- 133rev2 (Section 4, 5.1, 6.1, and 6.3) and IG D.H. Unmodified output DRBG used for generation of symmetric keys and seeds for asymmetric keys. DRBGs are instantiated to 256 bits of security strength

Table 4 - Vendor Affirmed Algorithms

As required per SP 800-56Arev3, the CDK conditionally performs the necessary checks when generating, importing, or using domain parameters and keys according to sections 5.5.2, 5.6.2, and/or 5.6.3 of the special publication.

If HMAC is used for the protection of data, the operator must ensure that a key length of at least 112 bits minimum is used.

In the Approved mode only internal 96-bit IV generation is allowed. The CDK supports both SP800-38D Section 8.1 and 8.2 for internal IV generation and therefore complies with both Scenario 1 and Scenario

2.2.1.4.1.1 TLS – Section 8.1 SP800-38D, Scenario 1 IG C.H

The CDK does not implement the TLS protocol. The CDK implements cryptographic operations that can be used to implement the TLS protocol. The CDK’s AES GCM TLS internal IV generation is in compliance with TLS 1.2 per RFC 5288, TLS 1.3 per RFC 8446, and in support of the GCM cipher suites listed in SP80052rev2. For TLS 1.2 the AES GCM IV is generated internally using a deterministic counter as the nonce_explicit value and takes as input a 16-bit salt. For TLS 1.3 the AES GCM IV is generated internally by XOR’ing an internally maintained counter with the 12-byte IV. In each case, the resulting IV is exactly 96-bits in length.

2.2.1.4.1.2 Random – Section 8.2 SP800-38D, Scenario 2 IG C.H

The CDK implements random internal IV generation that uses the module’s Approved DRBG. The seed used by the CDK’s DRBG is provided by the CDK’s jitter entropy component. The IV is exactly 96-bits in length.

In the event that module power is lost and restored, the application using the CDK must ensure that any of its AES-GCM keys used for encryption are re-established or re-generated. Page 17 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

The CDK enforces the following limits on the number of encryption operations that can be performed - TLS IV 64-bit Deterministic Counter with 16-bit salt

• if the counter exceeds 264 the CDK returns a CDK_INVALID_IV error with value 1064. - Random IV
• if the number of AES operations exceeds 232-1 the CDK returns CDK_INPUT_LENGTH_ERR error with value 1151. The CDK does not support any non-approved algorithms that are allowed in the Approved mode.

When run in the Approved mode the following additional algorithms, modes, and sizes are allowed to be used internally with No Security Claimed. Note these algorithms are not accessible through the CDK’s API and calling applications are unable to use them. Claimed When run in the Non-Approved mode all the algorithms, modes, and sizes described above are available as well as the following additional algorithms, modes, and sizes which are not allowed to be used in the CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 18

Table 6 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

When the CDK is run in the Approved mode, only FIPS 140-3 approved algorithms are allowed to be used. The CDK will error if a non-approved algorithm is used. In order to operate in the Approved mode, the CO must ensure that applications loaded by the operating system call the “Configure” service (enableFIPS() method) at startup. The CO may use the “Show Status” service (isFIPS()method) in their application to determine whether or not the CDK is operating in the Approved mode. The CO’s application must provide an indication of the mode of operation by either calling the “Show Status” service (isFIPS()function) and outputting a custom message, or by outputting the output of the “Show Status” service (StrVersion()method).

If the “Configure” service (enableFIPS() function) is not called, the CDK will operate in the NonApproved mode. The “Show Status” service (isFIPS()function) will return false to indicate that the CDK is not operating in the Approved mode. The output of the “Show Status” service Page 19 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

(StrVersion()function) will not include the statement that the module is operating in the Approved mode.

The CDK does not support a degraded mode of operation.

As noted above, the isFIPS() function will return true or false to indicate whether or not the CDK is operating in the Approved mode and only allowing approved algorithms to be used. Additionally, in the Approved or Non-Approved mode individual algorithms can be queried:

• by calling the isFIPS() member method, if the algorithm is represented by a C++ class
• by calling isHashFIPS() or isKDFFIPS() with appropriate inputs

The following diagram (Figure 1) illustrates the TOEPP and the relationship between a typical software application (such as the supplied CDK test program), the ISC CDK, the computer’s operating system, the system’s BIOS, and the physical general-purpose computer (GPC) on which it all executes. The cryptographic boundary is the ISC CDK shared library itself as shown inside of the red dashed lines labels cryptographic boundary. CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 20

GPC Application Cryptographic Boundary ISC CDK .dll or .so Operating System BIOS TOEPP Figure 1 ꟷ Cryptographic Boundary The following diagram (Figure 2) is a block diagram displaying the most important components of the CDK software. (Certain dependencies between the various components are suppressed for simplicity.) strings, self-tests utilities CDK API (data and control I/O, error handling) message symmetric digests ciphers public key DRBG algorithms groups, rings, fields, curves high-precision arithmetic Figure 2 ꟷ Important Components of the CDK Page 21 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

3. Cryptographic Module Interfaces As a FIPS 140-3 multi-chip standalone module, the CDK has a physical power interface and physical input and output data paths, which are the computer system’s standard input/output ports and power interface. The input/output ports on the computer are used for connecting external devices such as monitors and keyboards however these devices are outside the cryptographic boundary of the CDK. The CDK does not support a control output interface. The CDK software is written in C++; its logical interfaces are the application program interfaces (API) defined by C++ classes and global methods. The calling program inputs control and data to the CDK through the input fields of the API and receives output data and/or status information through the output parameters of the API. Vendor documentation describes what output indicates an error and what output constitutes successful completion of the operation. A “show status” service is provided by the static Algorithm::isErrorState(), isFIPS(), and StrVersion() methods which may be called at any time to determine if the CDK is in the hard error state and whether or not the CDK is operating in the Approved mode. If the CDK enters the hard error state, an error code is returned through the API interface, and no data output is returned. Methods performing key generation do not output intermediate key values. Methods performing key zeroization only return status output describing success or failure of the operation. Below is a table that maps the logical interfaces to the physical interfaces, with the exclusion of the Control Output interface and Power Interface which the module does not support: Table 7 – Ports and Interfaces CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 22

4. Roles, Services, and Authentication The CDK module supports one role: “Crypto-Officer” (CO). The CO is the human being who configures an application that uses services provided by the CDK. The CDK provides no maintenance access interface and therefore does not support a Maintenance role. FIPS 140-3 Level 1 cryptographic modules are not required to employ authentication as a means of controlling access to the module. Such authentication mechanisms are not supported by the CDK for the CO role. No other roles are supported. The CO configures the computer system, operating system, and the application using services provided by the CDK to operate in a secure Approved mode, if that is desired (this may include configuring the system on which the application is installed as part of the installation process). Additional conditions for meeting FIPS 140-3 requirements are provided in a separate document: Crypto Officer’s Guide. Self-test services are described in Section 9 of this document. Bypass services are not provided. Tables 8, 9 and 10 provide details on the services available to each role, and each role’s access rights with respect to those services. Page 23 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 24

The Show Status service also satisfies the “Show Module Version Information” Service. Page 25 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 26

4] Table 9 - Approved Services MD5 (No Security Claimed) is only used for TLS 1.0/1.1 KDF. Page 27 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

Table 10 - Non-Approved Services 5. Software/Firmware Security The CDK integrity is checked on startup using HMAC-SHA2-256 as described in section Pre-Operational Tests. The integrity check can be initiated on demand using the mechanisms specified in section OnCDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 28

Demand Self-Tests. The module executable is provided in the compiled form described in section Platform Availability below. 6. Operational Environment The CDK is a software module that operates in a modifiable operational environment running on a general-purpose computer. The CDK is a single shared library. Within the tested environments user processes are segregated into their own process space. Processes are logically separated from all other processes by the operating system and underlying hardware. As the module exists within the process space of the calling application, acting in the Crypto Officer role, and no other process can access the same instance of the module, the module operates in single user mode.

The CDK software was designed for use on a variety of operating systems and hardware platforms. For FIPS 140-3 validation purposes, operational testing was performed on the tested platforms listed in section 2.1. The CDK software is provided as compiled code in the form of shared link libraries that can be run on Microsoft Windows (CDKC8123S.DLL) and Linux (libcdkc.so.81.2.3) operating systems. There are no security rules, settings, or restrictions to the configuration of the operational environment. The module’s application programming interface (API), which provides access to the supported cryptographic primitives, consists of a set of C++ classes as documented in ‘cdk_fips.h’, the other header files referenced therein, and related documentation. For FIPS 140-3 validation, the CDK was loaded by multiple test applications (one for each algorithm family) and executed on each of the supported platforms.

7. Physical Security The module is a software-only module and the physical security requirements of FIPS 140-3 level 1 do not apply.
8. Non-Invasive Security Non-invasive security is Non Applicable as there are currently no requirements in SP 800-140F.
9. Sensitive Security Parameters Management The CDK uses, creates, and/or manages: Page 29 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

• symmetric keys (for use with a symmetric cipher or keyed hash functions), and
• asymmetric key pairs (for digital signatures and key transport/agreement protocols based on public key schemes)

The CDK is a low-level cryptographic toolkit and does not provide any key storage. As detailed in section Pre-Operational Tests, a single, special purpose, integrity key is hard coded in the module in plaintext form and is used to verify the integrity of the module.

The CDK does not manage any manually distributed cryptographic keys, either entry or output, external to the cryptographic boundary. However, the logical C++ API exposed by the CDK provides methods for loading and unloading symmetric keys and public/private key pairs in electronic form for manual10 key distribution by the application. An instantiated CDK object may contain a cryptographic key during its lifetime. Such keys are available to the user for manipulation, but when the object is released, its memory and all keys in it are cleared. Under normal operations all internal memory allocated by the CDK for temporary key storage is zeroized when the object owning that memory is destroyed. The CO is responsible for ensuring that CDK objects are destroyed properly (i.e., the application must allow the C++ destructors to be called by properly exiting the application or by deleting all heap allocated CDK objects before application termination). To zeroize the special purpose integrity key embedded in the CDK in plaintext form, the CDK shared library must be securely erased from the hard disk.

Listed in Table 11 are the keys and SSPs used by the module in the Approved mode. IG 9.5.A MD/EE - CM Software to/from App via TOEPP Path CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 30

The AES-GCM IV is generated internally randomly or as a counter per IG C.H. In the former case the IV is exactly 96-bits. In the latter case the IV may be 8- to 1024-bits in length. Page 31 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 32

Table 11 – SSPs Page 33 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

The CDK includes a non-physical entropy source within the module boundary which complies with SP 800-90B and has been validated using the guidance set out in the FIPS 140-3 Implementation Guidance. Table 12 - Non-Deterministic Random Number Generation Specification The CDK generates keys for the approved and vendor affirmed algorithms listed in section Algorithms and Parameters Allowed in the Approved mode. The CDK also generates Non-Approved keys for algorithms listed in section Non-Approved Algorithms Allowed in the Approved Mode of Operation The CDK does not support any non-approved algorithms that are allowed in the Approved mode. Non-Approved-mode Algorithms The CDK can generate symmetric keys (for a symmetric cipher or keyed hash function) using its DRBG. To generate key pairs, the public key generation methods use the CDK’s random number generator. The calling application is responsible for maintaining the SSPs that it establishes using the module, inclusive of assuring that SSPs established while operating in the Approved mode are not shared or used in the Non-Approved mode (and vice versa).

The CDK doesn’t perform key distribution. The CDK has basic cryptographic functions which can be used by developers to build key distribution capabilities into their applications. The key distribution techniques available for use include RSA Key Establishment, ECC Diffie-Hellman Key Agreement, and AES key wrapping. CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 34

10. Self-Tests The CDK performs self-tests to ensure that it is functioning properly. If the message digest value computed over the CDK does not match the embedded expected value, or if an algorithm KAT fails, then the module enters the hard error state and no further cryptographic operations are possible. To recover from the hard error state, the application using the CDK’s services must be restarted. The CDK returns non-zero error codes from its API to indicate failure. Most error codes are output when the CDK transitions through the soft error state (which is immediately and automatically cleared), but there are two special error codes that the CDK returns to indicate it has entered the hard error state. The CDK returns CDK_ERROR_STATE with value 1470 from its interfaces when it is in the hard error state for any reason other than a pairwise key test failure. The CDK returns CDK_KEYPAIR_INCONSISTENT with value

1234 when a pairwise key test fails during an on-demand self-test and the CDK enters the hard error

state. Additionally, a static function, Algorithm::isErrorState(),may be called to determine if the CDK is in the hard error state. Table 13 contains details on the error states. Page 35 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

Table 13

• Error States When the CDK module is loaded from disk by the operating system, it executes a pre-operational software integrity test as well as conditional cryptographic algorithm self-tests. Basic self-test and library verification is performed at library load by using a C++ static constructor to call the self-test and integrity test methods in Table 14
• Self-Tests. The conditional tests include known answer tests (KATs) or pairwise consistency tests (PCTs) for each of the Approved algorithms in the CDK (see Section 2.2.1). Table 14
• Pre-Operational Self-Tests also lists those algorithms whose cryptographic algorithm self-test is run on first use as opposed to at module start. The integrity test operates by calculating a 256-bit HMAC (HMAC-SHA2-256) over the module and comparing it to an expected value embedded (along with the key) in the module itself at the factory. These tests are performed at startup regardless of whether the module is put into the Approved mode. If the software integrity test fails or if any self-test fails, the module displays a message on the output interface, enters the error state, and inhibits all cryptographic services. The integrity test executes after the HMAC KATs on which it relies. On all platforms but Microsoft Windows, the integrity test is performed over the entire module binary except for the seventy-two (72) byte MAC field. On Microsoft Windows, the integrity test is performed over the entire module binary except for the seventy-two (72) byte MAC field and the Windows PE header IMAGE_DIRECTORY_ENTRY_SECURITY field that contains (or CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 36

will contain) a digital signature and certificate applied by Microsoft tooling post the population of the MAC integrity field. Table 14 – Pre-Operational Self-Tests

Conditional self-tests are performed when certain specific conditions arise within the CDK. The conditional self-tests are described in the following paragraphs. If any conditional self-test fails, the module displays a message on the output interface, enters the error state, and inhibits all cryptographic services. Interruption of the module’s operation results in the module terminating and causes the module to be unloaded from memory. This most likely occurs when the application using the module terminates. When the application using the module is started again, the module is loaded in the initial state, the start-up self-tests will run, the integrity test will run, and any conditional test states (i.e., counters) will be reset. Page 37 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

Table 15 – Conditional Self-Tests

The DRBG KAT detailed in Table 14 – Pre-Operational Self-Tests exercises the DRBG’s instantiate, reseed, and generate functions and covers the required health tests specified in SP 800-90A, Section 11.3. SP 800-90A, Section 11.3 also requires that the generate function be tested at reasonable intervals. In the CDK, the self-test interval for calls to the generate function is 32,768 and was chosen arbitrarily: every 32,768th call to the generate function causes the DRBG to run its self-tests again.

All ECDSA public/private key pairs are automatically tested for pair-wise consistency upon generation by generating a signature and verifying the signature for an embedded message. All Elliptic Curve Diffie-Hellman public/private key pairs are automatically tested for pair-wise consistency upon generation by computing a shared secret, deriving the key, and encrypting a message and then decrypting the message. All RSA key pairs are automatically tested for pair-wise consistency upon generation by generating a signature and verifying the signature over, and by encrypting and decrypting, an embedded message. Table 16 – Pair-Wise Consistency Tests CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 38

As required by SP800-90B the CDK’s jitter entropy component implements a continuous Repetition Count Test and a continuous Adaptive Proportion Test. If either test fails, entropy cannot be obtained, the operation is aborted, and the CDK enters the error state.

As required per IG C.I, when the XTS-AES object is initialized by an operator the CDK ensures that the key and tweak values are not identical. If they are identical, the CDK returns error code 1038, CDK_INVALID_KEY from its API.

As documented in the Crypto Officer’s Guide and the User’s Guide, the CO may, on-demand, invoke any of the self-tests listed in Table 14 – Pre-Operational Self-Tests to ensure the integrity of specific algorithms by configuring their application to call the desired self-test function in the API (e.g., ISC_CDK::Test_SHA256()). There is also a master test function (ISC_CDK::SelfTest()) that the CO may call to run all self and integrity tests. 11. Life-Cycle Assurance

The CDK was designed around a Finite State Model (FSM) that is detailed in a proprietary document submitted with this security policy.

The ISC CDK is delivered to the CO as a compressed file archive (zip or tar) electronically or on physical media for each target platform with the version and platform indicated in the package name.

• cdk8.1.Y.X.win.x86_64.zip
• cdk8.1.Y.Z.lin.x64.tgz The ISC CDK is delivered in binary form as a pre-compiled shared library. The deliverables also include Cheader files, crypto officer’s guide, and FIPS 140-3 security policy. When a CO receives the module, in .zip or .tgz form, they should extract the contents on to the computer in a folder of their choice and then follow the user’s guide to integrate it into applications. The CO is responsible for installing the ISC CDK on systems as part of their own application’s installation. 12. Mitigation of Other Attacks The CDK has not been designed to mitigate any specific attacks. The CDK does not employ any mitigation techniques against non-invasive attacks. Page 39 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy

13. Acronyms CDK 8.1.2.3 Security Policy © 2002-2025 Information Security Corporation. Page 40

Page 41 © 2002-2025 Information Security Corporation CDK 8.1.2.3 Security Policy