| Standard | FIPS 140-3 |
|---|---|
| Overall level | 1 |
| Module type | Software |
| Embodiment | Multi-Chip Stand Alone |
| Status | Active |
| Sunset date | 7/11/2029 |
| Caveat | When operated in approved mode |
| Vendor | Google, LLC. |
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;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.
| # | Section | Page |
|---|
1. General 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. ISO/IEC 24759 Section 6 Security FIPS 140-3 Section Title [Number Below] Level
1 General 1
2 Cryptographic module specification 1
3 Cryptographic module interfaces 1
4 Roles, services, and authentication 1
5 Software/Firmware security 1
6 Operational environment 1
7 Physical security N/A
8 Non-invasive security N/A
9 Sensitive security parameter management 1
10 Self-tests 1
11 Life-cycle assurance 1
12 Mitigation of other attacks N/A
Table 1 - Security Levels The module is designed to meet an overall security level of 1. 2. Cryptographic module specification 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 selfcontained Linux Kernel Module (LKM). The module has been tested on the following platforms: # Operating System Hardware Platform Processor PAA/Acceleration
1 Linux kernel 5.10 Google Pixel 6 Google Tensor processor with PAA
2 Linux kernel 5.10 Google Pixel 6 Google Tensor processor without PAA
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. CAVP Algorithm and Mode/Method Description / Key Size(s) Use / Function Cert Standard / Key Strength(s) #A2268 AES AES-CBC 128, 192, 256 bits Data encryption/decryption [FIPS 197, SP 800 38A] #A2268 AES AES-ECB 128, 192, 256 bits Data encryption/decryption [FIPS 197, SP 800 38A] #A2268 AES AES-CBC-CS3 128, 192, 256 bits Data encryption/decryption [FIPS 197, SP 800 38A] #A2268 AES AES-CTR 128, 192, 256 bits Data encryption/decryption [FIPS 197, SP 800 38A] #A2268 AES AES-XTS 128, 192, 256 bits Data encryption/decryption [FIPS 197, SP 800 38A] #A2268 AES AES-CMAC 128, 192, 256 bits MAC generation and [FIPS 197, verification SP 800 38B] N/A ENT (NP) N/A N/A Non-physical entropy source [SP800-90B] used for seeding DRBG #A2268 DRBG HMAC-DRBG N/A Random number generation [SP800-90Ar1] (HMAC-SHA-1) #A2268 DRBG HMAC-DRBG N/A Random number generation [SP800-90Ar1] (HMAC-SHA2-256) #A2268 DRBG HMAC-DRBG N/A Random number generation [SP800-90Ar1] (HMAC-SHA2-384) #A2268 DRBG HMAC-DRBG N/A Random number generation [SP800-90Ar1] (HMAC-SHA2-512) #A2268 HMAC HMAC-SHA-1 112 bits or greater Message authentication [FIPS 198-1]
CAVP Algorithm and Mode/Method Description / Key Size(s) Use / Function Cert Standard / Key Strength(s) #A2268 HMAC HMAC-SHA2-224 112 bits or greater Message authentication [FIPS 198-1] #A2268 HMAC HMAC-SHA2-256 112 bits or greater Message authentication [FIPS 198-1] #A2268 HMAC HMAC-SHA2-384 112 bits or greater Message authentication [FIPS 198-1] #A2268 HMAC HMAC-SHA2-512 112 bits or greater Message authentication [FIPS 198-1] #A2268 SHS SHA-1 N/A Message Digest [FIPS 180-4] Message Length: Note: SHA-1 is not used for 0-65528 digital signature generation Increment 8 #A2268 SHS SHA2-224 N/A Message digest [FIPS 180-4] Message Length: 0-65528 Increment 8 #A2268 SHS SHA2-256 N/A Message digest [FIPS 180-4] Message Length: 0-65528 Increment 8 #A2268 SHS SHA2-384 N/A Message digest [FIPS 180-4] Message Length: 0-65528 Increment 8 #A2268 SHS SHA2-512 N/A Message digest [FIPS 180-4] Message Length: 0-65528 Increment 8 Table 3 - Approved Algorithms Table 4 below lists all non-Approved algorithms not allowed in the approved mode of operation implemented by the module. Algorithm/Function Use/Function AES-GCM Authenticated Encryption/Decryption AES-XCBC Message Authentication Code AES-CBC-MAC Message Authentication Code ESSIV-CBC-AES Salt Generation 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) Calling 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 Physical port Logical interface Data that passes over port/interface N/A Data Input Interface Arguments for an API call that provide the data to be used or processed by the module N/A Data Output Interface Output data returned to calling function N/A Control Input Interface Arguments for an API call used to control and configure module operation N/A Status Output Interface Return values from the Module’s API used to obtain information on the status of the module. The Status Output Interface also includes the log file where the module messages are output N/A Control Output Interface N/A Table 5 - Ports and Interfaces
4. Roles, services, and authentication Role Service Input Output Crypto Initialization Command to start the Module initialization Officer (CO) initialization status Crypto Symmetric Encryption Command to conduct the Encrypted or Officer (CO) and Decryption encryption and decryption Decrypted message operation Crypto Message Authentication Command to conduct the HMAC MAC value Officer (CO) Code (MAC) or AES-CMAC operation Crypto Message Digest Command to conduct the Hashed message Officer (CO) Message Digest operation Crypto Random Number Command to conduct the Random value Officer (CO) Generation HMAC_DRBG generation Crypto Perform Self-Test (Pre- Command to conduct the self- Status of self-tests Officer (CO) operational Self-Tests and tests Conditional Self-Tests) Crypto Show Status Command to check the status Module’s current Officer (CO) status Crypto Show Version Command to get module’s Module’s name/ID Officer (CO) software version and versions Crypto Zeroization Command to zeroize all SSPs Status of zeroization Officer (CO) completion Table 6 - Roles, Service Commands, Input and Output No authentication is required at security level 1 and the assumption of the role is implicit by the service being performed. Role Authentication Method Authentication Strength Crypto Officer (CO) N/A N/A Table 7 - Roles and Authentication Service Description Approved Keys Roles Access rights Indicator Security Functions and/or to Keys SSPs and/or SSPs Initialization Conduct N/A N/A Crypto N/A N/A module’s Officer initialization (CO) Symmetric Conduct AES-CBC; AES Key Crypto R, W, E Approved Encryption and Symmetric AES-ECB; Officer service Decryption Encryption and AES-CBC-CS3; (CO) execution Decryption AES-CTR; return value AES-XTS “true” Message Conduct Key AES-CMAC; AES Key; Crypto R, W, E Approved authentication Hash operation HMAC-SHA-1; HMAC Officer service code HMAC-SHA2-224; Key (CO) execution (MAC) HMAC-SHA2-256; return value HMAC-SHA2-384; “true” HMAC-SHA2-512 Message Conduct SHA-1; N/A Crypto N/A Approved Digest Message SHA2-224; Officer service SHA2-256; (CO) execution
Service Description Approved Keys Roles Access rights Indicator Security Functions and/or to Keys SSPs and/or SSPs digest SHA2-384; return value operation SHA2-512 “true” Random Conduct HMAC_DRBG Entropy Crypto R, W, E Approved Number HMAC_DRBG Input; Officer service Generation generation DRBG (CO) execution Seed; return value DRBG V; “true” DRBG Key Self-Test (Pre- Run Pre- AES-CBC; Software Crypto R, E Self-test operational operational AES-ECB; Integrity Officer completion Self-Tests and Self-Test and AES-CBC-CS3; Key (non- (CO) message Conditional Conditional AES-CTR; SSP) Self-Tests) Algorithm Self- AES-XTS; Tests AES-CMAC; DRBG; HMAC-SHA-1; HMAC-SHA2-224; HMAC-SHA2-256; HMAC-SHA2-384; HMAC-SHA2-512 SHA-1; SHA2-224; SHA2-256; SHA2-384; SHA2-512 Show Status Provides the N/A N/A Crypto N/A N/A module’s Officer current status (CO) Show Version Provides the N/A N/A Crypto N/A N/A module’s Officer name/ID and (CO) versions Zeroization Zeroize the N/A All SSPs Crypto Z Zeroize SSPs stored in Officer completion the module (CO) message Table 8
Service Description Algorithms Role Indicator Accessed Authenticated Conduct Authenticated Non-approved service execution Encryption/Dec AES-GCM N/A Encryption/Decryption return value “false” ryption Message Digest Conduct Message Non-approved service execution using AES- AES-XCBC N/A digest operation return value “false” XCBC, Message Digest Conduct Message Non-approved service execution using AES-CBC- AES-CBC-MAC N/A digest operation return value “false” MAC Conduct Salt ESSIV-CBC- Non-approved service execution Salt Generation N/A Generation operation SHA256 return value “false” Table 9 – Non-Approved Services
9. Sensitive security parameters management Key/ Strength Security Generation Import Establish Storage Zero- Use & SSP Function /Export -ment isation related Name/ and Cert. keys Type # AES Key 128, 192 AES Cert. N/A Import: MD/EE Stored in Automatic Used for or 256 # A2268 Electronic RAM zeroization Symmetric bits Entry (EE) memory when the Encryption, via the API; of the tested Decryption, Export: tested platform is and AESNo platform powered CMAC down generation and verification HMAC 112 or HMAC N/A Import: MD/EE Stored in Automatic Used for Key greater Cert. # Electronic RAM zeroization HMAC A2268 Entry (EE) memory when the generation via the API; of the tested and Export: tested platform is verification No platform powered down Entropy At least DRBG N/A Import: MD/EE Stored in Automatic Used for Input 256 bits of Cert. # Electronic RAM zeroization DRBG security A2268 Entry (EE) memory when the Generation strength via the of the tested API; tested platform is Export: platform powered No down DRBG 256 bits DRBG N/A Import: No; N/A Stored in Automatic Used for Seed Cert. # Export: No RAM zeroization DRBG A2268 memory when the Generation of the tested tested platform is platform powered down DRBG V 256 bits DRBG N/A Import: No; N/A Stored in Automatic Used for Cert. # Export: RAM zeroization DRBG A2268 No memory when the Generation of the tested tested platform is platform powered down DRBG 256 bits DRBG N/A Import: N/A Stored in Automatic Used for Key Cert. # No; RAM zeroization DRBG A2268 Export: memory when the Generation No of the tested tested platform is platform powered down Table 10
Random number generation 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. RBG entropy source Entropy sources Minimum number Details of bits of entropy CPU Jitter Random Number 0.908 bits/sample bit CPU Jitter Random Number Generator (Jitter Generator (Jitter Entropy Entropy Library v2.2.0) from Stephen Muller Library v2.2.0) provides at least 256 bits 256-bits of security strength entropy. Please see https://www.chronox.de/jent/doc/CPU-JitterNPTRNG.pdf for more information. The entropy source falls into IG 9.3.A, Scenario #1(b): A software module that contains an approved DRBG, that is seeded exclusively from one or more known entropy sources, located within the physical perimeter of the operational environment. 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
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