Android Kernel Cryptographic Module

Certificate

Approved Algorithms (20)

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

flowchart LR
  %% Deterministic review-risk graph for Android Kernel Cryptographic Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>self-test<br/>Status Output<br/>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["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 Android Kernel Cryptographic Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>self-test<br/>Status Output<br/>Show Status</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

Google LLC. Android Kernel Cryptographic Module Software Version: 5.10.66-android12-9-00072-g143ac63130f0-ab7955824 Document Version: 0.4 Last Update Date: 6-27-2024 This document may be freely distributed in its entirety without modification.

This document is the non-proprietary FIPS 140-3 Security Policy for the Android Kernel Cryptographic Module from Google LLC. It contains a specification of the rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for a Security Level 1 Software cryptographic module. This security policy is for the validation of the Android Kernel Cryptographic Module. In this document, the terms “Android Kernel Cryptographic Module”, “AKC”, “cryptographic module” or “module” are used interchangeably to refer to the module’s software version 5.10.66-android12-9-00072g143ac63130f0-ab7955824. Below is a table indicating the individual clause levels. Table 1 - Security Levels The module is designed to meet an overall security level of 1. The Android Kernel Cryptographic Module is a multi-chip standalone software only module designed to provide encryption services for the Linux kernel of the device. The module is implemented as a selfThe module has been tested on the following platforms: Table 2 - Tested Operational Environments 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 which is not listed on the validation certificate.

Mode of operation When the module starts up successfully, after passing the pre-operational self-test and the cryptographic algorithms self-tests (CASTs), the module is operating in the approved mode of operation by default and can only be transitioned into the non-approved mode by calling one of the non-approved services listed in Table 9. Section 4 provides details on the service indicator is implemented by the module. The service indicator identifies when an approved service is called. The Crypto Officer shall not configure the use of non-approved algorithms while the module is operating in an approved mode. If a non-Approved algorithm is used, then the module is operating in a non-Approved mode. Prior to using any of the non-approved services, the Crypto Officer shall zeroize all CSPs which places the module into the non-approved mode of operation. Table 3 below lists all Approved or Vendor-affirmed security functions of the module, including specific key size(s) -in bits unless otherwise noted- employed for approved services, and implemented modes of operation. There are algorithms, modes, and key moduli sizes that have been CAVP-tested but are not used by any approved services of the module. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in the tables below are used by an approved service of the module.

Table 3 - Approved Algorithms Table 4 below lists all non-Approved algorithms not allowed in the approved mode of operation implemented by the module. Table 4 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation In addition, the module does not implement Non-Approved Algorithms Allowed in Approved Mode of Operation and Non-Approved Algorithms Allowed in Approved Mode of Operation with No Security Claimed. Cryptographic boundary Figure 1 below depicts the module’s Block Diagram. Please note that the bold RED rectangle in the block diagram represents the Tested Operational Environment’s Physical Perimeter (TOEPP) containing the Module (the thin RED rectangle).

Tested Operational Environment’s Physical Perimeter (TOEPP) Operating System Android Kernel Cryptographic Module (5.10.66-android12-900072-g143ac63130f0-ab7955824) Application Figure 1 - Cryptographic Boundary The module is a single object module (fips140.ko) which is implemented as a Linux Kernel Module and bundled into the tested device’s boot image (vendor_boot.img). 3. Cryptographic module interfaces Table 5 - Ports and Interfaces

No authentication is required at security level 1 and the assumption of the role is implicit by the service being performed.

Table 8 – Approved Services 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.

Table 9 – Non-Approved Services

5. Software security Integrity techniques The module is software-only and performs self-tests during the loading of the module to ensure the integrity of the module and its services. To ensure software security, the module is protected by an HMACSHA2-256 (HMAC Cert. #A2268) algorithm. The software integrity test key (non-SSP) was preloaded to the module’s binary at the factory and used only for the pre-operational software integrity self-test. During initialization of the module, the integrity of the runtime executable is verified using an HMAC-SHA2-256 which is compared to a value computed at build time. If at load time the MAC does not match the stored, known MAC value, the module enters a critical error state where all crypto functionality is inhibited. The module must be reloaded to attempt the integrity test again. Integrity test on-demand The integrity test is performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. The operator can power-cycle or reboot the tested platform to initiate the integrity test ondemand.
6. Operational environment The module is operated in a modifiable operational environment per the definition in FIPS 140-3. The operation system shall be restricted to a single operator mode of operation (i.e., concurrent operators are explicitly excluded). The external application calling the module is a single user of the cryptographic module, even when the application is serving multiple clients.
7. Physical security The module is software-only and so does not claim any physical security.
8. Non-invasive security The module claims no non-invasive security techniques.

9. Sensitive security parameters management Table 10 – SSPs

The module implements an Approved SP 800-90Ar1 DRBG (HMAC-DRBG Cert. #A2268), which shall be called by the Application Client for key generation. Key generation The module does not provide any key generation service or perform key generation for any of its Approved algorithms. Keys/CSPs are passed in from calling applications via the algorithm API parameters. Key entry and output The module does not support manual key entry or key output. Keys/CSPs can only be exchanged between the module and the calling application via the appropriate algorithm API calls within the TOEPP. Key storage The SSPs are not stored inside the module. A pointer to a plaintext key is passed to the module through the algorithm APIs. Intermediate key/CSP storage locations are immediately zeroized in memory after use. Key zeroization The module is passed keys as part of a function call from a calling application and does not store keys persistently. All SSPs can be zeroized by powering down the tested platform. Table 11- Non-Deterministic Random Number Generation Specification 10. Self-tests When the module is loaded or instantiated (after being powered off, rebooted, etc.), the module runs preoperational self-tests. The operating system is responsible for the initialization process and loading of the library. The module is designed with a default entry point (DEP) which ensures that the self-tests are initiated automatically when the module is loaded. Prior to the module providing any data output via the data output interface, the module would perform and pass the pre-operational self-tests. Following the successful pre-operational self-tests, the module would execute the Conditional Cryptographic Algorithm Self-tests (CASTs).

The self-test success or failure is output as a return value of the library load API call, which is functioning as the self-test status indicator. If one of the self-tests fails, the module transitions into the error state (there is only one error state if any one of self-tests fails) and outputs the error message via the module’s status output interface. While the module is in the error state, all data through the data output interface and all cryptographic operations are disabled. The error state can only be cleared by reloading the module. All self-tests must be completed successfully before the module transitions to the operational state. Below are the details of the self-tests conducted by the module. Pre-operational self-test

• HMAC-SHA2-256 KAT
• Software Integrity Test (using HMAC-SHA256) During the build-time the hash value is calculated over the module (the original code and read-only data of the fips140.ko file). To calculate the hash of the loaded module, the segments of the code are concatenated to each other with the relocations unapplied. The hash of this code is then calculated and compared to the build-time hash value. If the value does not match the module will enter the error state. Conditional algorithm self-tests After the successful Pre-operational self-tests, the module will perform Conditional algorithm self-tests (CASTs). The following Known Answer Tests (KATs) are performed, automatically and without any intervention. Any failure of a KAT will result in the module entering the error state.
• AES-ECB Encryption KAT (128 bits), PAA and non-PAA tested separately
• AES-ECB Decryption KAT (128 bits), PAA and non-PAA tested separately
• AES-CCB Encryption KAT (128 bits), PAA and non-PAA tested separately
• AES-CBC Decryption KAT (128 bits), PAA and non-PAA tested separately
• AES-XTS Encryption KAT (128 bits), PAA and non-PAA tested separately
• AES-XTS Decryption KAT (128 bits), PAA and non-PAA tested separately
• AES-CMAC Encryption KAT (128 bits), PAA and non-PAA tested separately
• AES-CMAC Decryption KAT (128 bits), PAA and non-PAA tested separately
• DRBG Instantiate KAT, PAA and non-PAA tested separately
• DRBG Generate KAT, PAA and non-PAA tested separately
• DRBG Reseed KAT, PAA and non-PAA tested separately
• Note: DRBG Health Tests as specified in SP800-90Arev1 Section 11.3 are performed)
• HMAC-SHA-1 KAT, PAA and non-PAA tested separately
• HMAC-SHA2-256 KAT, PAA and non-PAA tested separately
• HMAC-SHA2-512 KAT, PAA and non-PAA tested separately
• SHA-1 KAT, PAA and non-PAA tested separately
• SHA2-256 KAT, PAA and non-PAA tested separately
• SHA2-512 KAT, PAA and non-PAA tested separately In addition, the module’s entropy source also conducts the following entropy health tests: Entropy source health tests 1. ENT (NP) SP800-90B start-up health tests:
• Repetition Count Test (RCT)
• Adaptive Proportion Test (APT) Note: Please refer to SP800-90B, sections 4.4.1 and 4.4.2 for more information about the RCT and APT.

2. ENT (NP) SP800-90B continuous health tests: • Repetition Count Test (RCT) • Adaptive Proportion Test (APT) Periodic/on-demand self-test The module performs on-demand self-tests initiated by the operator, by power cycling or rebooting the tested platform. The full suite of self-tests is then executed. The same procedure may be employed by the operator to perform periodic self-tests. It is recommended that the User perform periodic testing of the module’s on-demand self-tests every 60 days to ensure all components are functioning correctly. Error handling If any one of the above-mentioned self-tests fails, including pre-operational self-test, CASTs, entropy source health tests, the module enters the Error state (there is only one error state). In the case of the module entering the Error State, the module sends a kernel panic signal to the kernel causing a reboot, preventing access to any non cryptographic services or data output from the module. The only method to recover from the error state is to reboot the module (triggered automatically by the kernel panic), and then pass the self-tests, including the pre-operational software integrity test and the conditional CASTs again. The module will only enter into the operational state after successfully passing the pre-operational software integrity test and the conditional CASTs.
3. Life-cycle assurance Secure initialization and startup The module is initialized during the loading of the module before any cryptographic functionality is available. The operating system is responsible for the initialization and loading processes of the module. The module is designed with constructor (default entry point of the module) which ensures that the Cryptographic Algorithm Self-Tests (CASTs) and Pre-operational Self-Test are initiated automatically when the module is loaded. Secure operation The module is provided directly to solution developers and is not intended for direct download by the general public. The module is installed on an operating system (Linux kernel) specified in Section
4. Additional Rules of Operation:
5. The writable memory areas of the module (data and stack segments) are accessible only by the kernel itself so that the operating system is in "single user" mode. The module does not support concurrent operators.
6. The operating system is responsible for multitasking operations so that other processes cannot access the address space of the process containing the module.
7. Only the approved services defined in Section 4 above shall be used in approved mode of operation.
8. The length of a single data unit encrypted or decrypted with the AES-XTS shall not exceed 2²⁰ AES blocks; that is, 16 MB of data per AES-XTS instance. An XTS instance is defined in section 4 of NIST SP 800-38E.
9. The AES-XTS mode shall only be used for the cryptographic protection of data on storage devices. The AES-XTS shall not be used for other purposes, such as the encryption of data in transit. The module implements the check to ensure that the two AES keys used in the XTS-AES algorithm are not identical

The module is not distributed as a standalone library as an Android developer must integrate the module into the Android system image. The end user of the operating system is also responsible for zeroizing SSPs via powering down the tested platform that the module executes on to zeroize all SSPs used by the module. Configuration management The source code for the module is maintained in a git repository. While in process work on the code is maintained internally, code is eventually released to https://ci.android.com where it can be accessed by anyone. The source code manifest includes a build configuration providing a list of the specific tools needed to reproduce the module. The version number is generated by git based on the commit automatically. Documentation related to the module is maintained in Google Docs. All documents (whether spreadsheets, documents, presentations or anything else) are automatically version tracked along with the owner. Like git, Docs uses access control lists to control access to the design documentation for the module. Delivery and operation The module is released as source code for other users to utilize as needed, but the module is only tested on the specific devices listed in section

2. Google follows the same build steps to produce the binary version of the module as laid out in the configuration management solution when creating the software that will be installed on the device. The build process is strictly controlled within Google, including access controls on the generation and certification of the builds to be used on a device for production. The module is a built-in component of the overall Linux kernel image that is installed on the devices under test. The binary image produced from the build process is then installed onto the mobile devices at the factory, or updated via the device update process (OTA, or Over-the-Air updates). OTA updates follow the same build requirements as a factory installed image (which includes the module), but can be delivered after the device is purchased and in customer hands. All builds are signed and checked by the device (using checks burned into one-time fuses in the processor) to ensure that unauthorized binaries cannot be installed.
3. Mitigation of other attacks The module does not claim mitigation of other attacks.