Digital.ai Key & Data Protection Module

Certificate

Approved Algorithms (6)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Digital.ai Key & Data Protection Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Recoverable errors from the normal</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Self-test service is</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    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?"]
    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["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"]
    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
  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,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Digital.ai Key & Data Protection Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Recoverable errors from the normal</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Self-test service is</i><br/>src: securityPolicy.services"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<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 clueHigh;
  class C6 clueLow;

Security Policy, page by page

Digital.ai Key & Data Protection Module Version 1.0 This document may be freely reproduced and distributed, but only in its entirety and without modification.

1. GENERAL INFORMATION 1.1 O VERVIEW 1.2 S ECURITY L EVELS This document defines the Security Policy for the Digital.ai Key & Data Protection Module software cryptographic module. The module is a sophisticated implementation of whitebox cryptography (Class A safety-critical software per IEC 62304) that ingests cryptographic keys for use in the cryptographic operations performed by methods in the module’s libraries. Whitebox cryptography is a field of study and a set of techniques aimed at protecting cryptographic algorithms and keys from being compromised in a hostile environment where an attacker has complete access to the implementation and execution of the cryptographic algorithms. The module is designed to allow a user to use both obfuscation and encryption on sensitive data and chain together to reduce or remove the possibility of a successful attack. The module meets FIPS 140-3 overall Security Level 1 requirements and is intended for use by US Federal agencies and other markets that require FIPS 140-3 validation. The cryptographic boundary of the module is the entire monolithic library file. Table 1

• Security Levels N/A N/A N/A

2. CRYPTOGRAPHIC MODULE SPECIFICATION 2.1 D ESCRIPTION Purpose and Use: The module is a sophisticated implementation of whitebox cryptography that ingests keys for use in the cryptographic operations performed by methods in the Digital.ai Key & Data Protection Module libraries. Module Type: The module is defined as a software module (refer to ISO/IEC 19790, Section 7.2.2) Module Embodiment: The module and OE are defined as a multi-chip standalone module. Module Characteristics: The module comprises a single, dynamic library built as an object file (libtfit_fips_module.so). Cryptographic Boundary: The cryptographic boundary is defined as the Digital.ai Key & Data Protection Module. The boundary encompasses the entire monolithic library file named ‘libtfit_fips_module.so’. Figure 1

• Cryptographic Boundary Figure 1 describes the module operational environment. The boundary is the entire monolithic library files. The logical interface is defined as the API for the library. The Digital.ai Key & Data Protection Module is loaded as a dynamic library as part of a software application. 2.2 V ERSION I NFORMATION The Digital.ai Key & Data Protection Module is a software cryptographic module developed to meet the requirements of FIPS 140-3 Security Level 1 (refer to Table 1).

Table 2

• Version Information 8.3.1 2.3 O PERATING E NVIRONMENT (OE)

The module’s operational environment (OE) is defined as modifiable and includes all the module’s components, the hardware platform, and the operating system. N/A

N/A The module comprises a dynamic library in the form of an object file that can in turn be linked with an executable overarching application. Table 4

• Code Sets libtfit_fips_module.so 8.3.1 HMAC-SHA-256

The module does not support any vendor affirmed operating environments. 2.4 E XCLUDED C OMPONENTS 2.5 M ODES OF O PERATION The module does not exclude any components from the requirements of FIPS 140-3. The Digital.ai Key & Data Protection Module only has an ‘approved’ mode of operation. There are no undefined or ‘non-approved’ modes or services within the module. By default, the approved mode is entered into when powering on the module. When called successfully, each of the approved services returns a ‘0’ integer value. If any other value is returned, the module transitions to its defined error state. The module returns ‘Digital.ai Key & Data Protection Module Version: 8.3.1’ to indicate its approved mode of operation. N.B. The module does not incorporate a degraded mode of operation (refer to ISO/IEC 19790 Section 7.2.4.3).

The module implements the following approved cryptographic functions listed in the following table: Table 5

• Approved Algorithms HMACSHA-256 Encryption / Decryption N/A SHA-512 N/A

Hash Generation There are no vendor affirmed algorithms within boundaries of the module. Table 6

• Vendor Affirmed Algorithms N/A N/A N/A

There are no non-approved allowed algorithms within boundaries of the module. Table 7

• Non-Approved Allowed Algorithms N/A N/A N/A

There are no non-approved algorithms within boundaries of the module. Table 8

• Non-Approved Allowed with No Security Claimed N/A N/A N/A

There are no non-approved not allowed algorithms within boundaries of the module. Table 9

• Non-Approved Not Allowed Algorithms N/A N/A N/A 2.7 S ECURITY F UNCTION I MPLEMENTATIONS (SFI) Table 10
• Security function implementation ECDH Computation A3516 2.8 A LGORITHM S PECIFIC I NFORMATION The module utilizes only approved algorithms that are tested and validated under the Cryptographic Algorithm Validation Program (CAVP): − − − − − 2.9 AES per FIPS 197 ECDSA per FIPS 186-4 HMAC per FIPS 198-1 KAS-ECC CDH-Component per NIST SP800-56Ar3 SHA-256 and SHA-512 per FIPS 180-4 RNG AND E NTROPY The module does not support RNG or entropy generation.

The module does not support the generation of cryptographic keys. The module does not implement random number generation.

The module does not support key establishment methods.

The module does not support any industry standard protocols.

The module design corresponds to the module security rules. This section documents the security rules enforced by the cryptographic module to implement the security requirements of this FIPS 140-3 Level 1 module. − − − − − − − − − − − − − The operator shall be capable of commanding the module to perform the power up selftests by power cycling the system or by re-loading the library into the application. Power up self-tests do not require any operator action. Data output shall be inhibited by self-tests, zeroization and error states. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module. The module does not support concurrent operators. The module does not support a maintenance interface or role. The module does not support manual key entry. The module does not have any external input/output devices used for entry/output of data. All CSPs are protected from unauthorized access, use, disclosure, modification, and substitution. The module does not persistently store CSPs. CSPs are provided to the module for the purpose of executing cryptographic operation. All PSPs are protected from unauthorized modification and substitution. The module does not output cryptographic keys. The operator can command the module to perform the Pre-Operational and Conditional self-tests at any time by loading the module in memory space of an application requiring its services. When the module is in an error state, the operator shall not have access to any cryptographic service.

The module does not require specific initialization as no CSPs are stored within its cryptographic boundary. The module is loaded into an application address space requiring its services. On load, the module immediately performs self-testing of all its cryptographic functions and output status of the tests (refer to Section 10).

3.1 P ORTS & I NTERFACES Table 11

• Ports and Interface N/A N/A N/A N/A N/A N/A API service parameter return values. 4. ROLES, SERVICES, AND AUTHENTICATION 4.1 A UTHENTICATION M ETHODS 4.2 R OLES The module does not implement any authentication methods. has access to all services. No other roles are supported. The module does not support a maintenance role or bypass capability. The module does not support concurrent operators. Table 12
• Roles, Services, Input & Output N/A & algorithm

Self-Test N/A N/A N/A N/A Table 13

• Roles 4.3 Cryptographic Officer N/A N/A A PPROVED S ERVICES All services implemented by the module are listed in the table below. Each service description also describes all usage of CSPs by the service. Table 14
• Approved Services N/A

N/A N/A HMAC-SHA256 HMAC-SHA256 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A 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. N ON -A PPROVED S ERVICES The module does not implement any non-Approved services. 4.4 E XTERNAL S OFTWARE L OADED The module does not implement external software loading capabilities.

5. SOFTWARE/FIRMWARE SECURITY The executable code is provided as a dynamic library (libtfit_fips_module.so) to a consuming application which interfaces to the library. The library’s integrity is protected using HMAC-SHA256 at the time of development. The Conditional and Pre-Operational Self-Tests run upon instantiation of the module. All cryptographic algorithm self-tests (CAST) must successfully pass its applicable self-test for the module to transition to its ‘normal’ operation. If a Self-Test fails for any reason, a message is printed to standard error (the assert logcat on Android) and forces termination of the application. 5.1 I NTEGRITY T ECHNIQUES 5.2 I NITIATE ON D EMAND As part of the pre-operational self-tests, a software integrity test comprising HMAC-SHA-256 is performed. If the software integrity test fails, the module does not load and returns an error over stderr (refer to Section 10.1). The module's consuming application can be restarted at any time to perform a periodic self-test.
6. OPERATIONAL ENVIRONMENT The module’s operational environment supports process isolation. Each process is logically separated from all other processes by the operating system and hardware. The module functions entirely within a single process. The operational environment enforces process separation using virtual memory. The virtual memory system uses the memory management unit (MMU) hardware to prevent processes from accessing the memory image of another process. 6.1 O PERATIONAL E NVIRONMENT T YPE AND REQUIREMENTS 6.2 C ONFIGURATION S ETTINGS AND R ESTRICTION The module is designed to run on an Android v12 operational environment (OE). The OE is classified as modifiable. The tested OE and platforms are detailed in Table
7. The module has no interaction with the OE, so all requirements for FIPS 140-3 Security Level 1 are satisfied. There are no security rules, settings, or restrictions on the configuration of the operational environment imposed by the module. The module has no interaction with the operational environment.

The consuming application may define security rules, configuration settings, or restrictions on the OE.

7. PHYSICAL SECURITY Physical Security requirements are not applicable, as the module is a FIPS 140-3 Security Level 1 software module.
8. NON-INVASIVE SECURITY The module does not claim any security from non-invasive attack methods.

9. SENSITIVE SECURITY PARAMETER (SSP) MANAGEMENT The module incorporates both Critical Security Parameters (CSPs) and Public Security Parameters (PSPs). 9.1 SSP S The module incorporates SSPs as defined with Table
10. Table 15 – SSPs N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A

9.2 Z EROIZATION 10. SELF-TESTS SSPs are not persistently stored. During normal operation, the module explicitly erases copies of SSPs in volatile memory (e.g., RAM) by overwriting with zeros after their use. SSPs temporarily stored in volatile memory can be zeroized via the ‘Zeroize’ service. On instantiating the consuming application, the module performs the self-tests described in Tables

16 & 17 below. All KATs must be completed successfully prior to any use of cryptography by the

module. If one of the KATs fails, the module transitions to its appropriate error state.

The module implements both preoperational and conditional self-tests. Since the pre-operational Table 16

• Pre-Operational Self-Tests HMAC-SHA256

Table 17

• Conditional Self-Tests

The module is designed to meet the requirements of FIPS 140-3 Security Level 1. It does not implement automated periodic self-testing. However, the module's consuming application may be restarted at any time to perform a periodic self-test.

The module supports the following error states. Table 18

• Error States 11. restarted. LIFE-CYCLE ASSURANCE Module code and documentation is stored and managed within a private and secure configuration management system.

Module code utilizes semantic versioning to each release indicating major, minor or patch releases along with release notes providing guidance in the use of each iteration of module’s code. The module has a semantic version number. The Git configuration management system assigned a message digest to each commit which uniquely identifies the version. Configuration management systems retaining module code are periodically backed up using a solution that allows both full and incremental restoration. The procedures for secure installation, initialization, startup, and operation of the module are provided in sections 11.1, 11.2, and 11.3 of this Security Policy and the module’s user guidance. A comprehensive developer guide documenting the entire API is provided. The developer guide provides all Administrator guidance. The developer guide is versioned and managed within the same secure configuration management systems. The configuration management system is protected with user authentication measures to prevent unauthorized access. All changes can be made only by authorized individuals. An automated system is in place to notify other users when any change has been made to prevent unknown changes from being made. All changes are made on development branches in Git and are reviewed by separate people before releasing to production. The only maintenance required is to install new versions of the module when they are made available to fix discrepancies or add features. The update procedure is the same as the installation procedure, with the new module file(s) replacing the existing ones. Any new version of the module is outside the scope of this validation and requires a separate FIPS 140-3 validation. The procedures for secure installation, initialization, startup, and operation of the module are provided in module’s user guidance. Additionally, a comprehensive developer guide documenting the entire API is provided. The developer guide provides all Administrator guidance. The developer guide is versioned and managed within the same secure configuration management system. The configuration management system is protected with user authentication measures to prevent unauthorized access. All changes can be made only by authorized individuals via access rights (i.e., read/write). An automated system is in place to notify other users when any change has been made. All changes are made on development branches in Git and are reviewed by separate people before releasing to production. The only maintenance required is to install new versions of the module when they are made available to fix discrepancies or add features. The update procedure is the same as the installation procedure, with the new module file(s) replacing the existing ones. Any new version of the module is outside the scope of this validation and requires a separate FIPS 140-3 validation. 11.1.1 S TARTUP P ROCEDURES The module does not provide a non-approved mode of operation and is as such always in an approved mode once loaded into memory by the calling application and its automated self-tests are executed successfully. Since the module does not generate keys or support authentication, it does not need to be initialized.

11.1.2 S ANITIZATION The module is a software module that does not store any persistent SSPs. The module should be uninstalled from the OE when no longer needed.

The Crypto Officer shall configure their Android app project according to instructions detailed in the module’s user guidance.

There is no authentication component to the Module, so no further setup is required. No zeroization is required during installation. 12. MITIGATION OF OTHER ATTACKS The module does not claim any attack mitigation beyond FIPS 140-3 Security Level 1 requirements.

13. APPENDIX A: REFERENCES Table 19

• References [1] [3] [2] [4] [5] [6] [7] [8] [9]

14. APPENDIX B: ABBREVIATIONS AND DEFINITIONS Table 20

• Abbreviations and Definitions TOEPP Tested Operational Environment’s Physical Perimeter