Apple corecrypto Module v12.0 [Apple silicon, Kernel, Software, SL1]

Certificate

Approved Algorithms (88)

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

flowchart LR
  %% Deterministic review-risk graph for Apple corecrypto Module v12.0 [Apple silicon, Kernel, Software, SL1]
  %% 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<br/>update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status Output<br/>Self-test<br/>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>IKEV<br/>IPSEC<br/>HTTPS</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>kernel<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 Apple corecrypto Module v12.0 [Apple silicon, Kernel, Software, SL1]
  %% 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<br/>update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Status Output<br/>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>IKEV<br/>IPSEC<br/>HTTPS</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>kernel<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

Apple Inc. Apple corecrypto Module v12.0 [Apple silicon, Kernel, Software, SL1] October 2024 Prepared for: Apple One Apple Park Way Cupertino, CA 95014 Prepared by: atsec information security corporation

4516 Seton Center Parkway, Suite 250

Austin, TX 78759 www.atsec.com

Trademarks Apple’s trademarks applicable to this document are listed in https://www.apple.com/legal/intellectualproperty/trademark/appletmlist.html. Other company, product, and service names may be trademarks or service marks of others. This document may be reproduced and distributed only in its original entirely without revision.

2 of 35

This document is the non-proprietary FIPS 140-3 Security Policy for Apple corecrypto Module v12.0 [Apple silicon, Kernel, Software, SL1] cryptographic module. It contains the security 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 module. This document provides all tables and diagrams (when applicable) required by NIST SP 800-140B. The column names of the tables follow the template tables provided in NIST SP 800-140B. Table 1 describes the individual security areas of FIPS 140-3, as well as the Security Levels of those individual areas. Table 1 - Security Levels This document may be reproduced and distributed only in its original entirely without revision.

5 of 35

The Apple corecrypto Module v12.0 [Apple silicon, Kernel, Software, SL1] cryptographic module (hereafter referred to as “the module”) is a Software module running on a multi-chip standalone general-purpose computing platform. The version of module is 12.0. The module provides implementations of low-level Monterey) Security Framework and Common Crypto.

Table 2 - Tested Operational Environments

This document may be reproduced and distributed only in its original entirely without revision.

6 of 35

The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate. the service utilized. The table below provides a summary of the implementation. This document may be reproduced and distributed only in its original entirely without revision.

7 of 35

The table below lists all Approved or Vendor-affirmed security functions of the module, including specific key size(s) employed for approved services, and implemented modes of operation. This document may be reproduced and distributed only in its original entirely without revision.

8 of 35

This document may be reproduced and distributed only in its original entirely without revision.

9 of 35

Table 6 - Approved Algorithms This document may be reproduced and distributed only in its original entirely without revision.

10 of 35

2.6 Non-Approved Algorithms Allowed in the Approved Mode of Operation

There are no non-Approved but “Allowed functions” with security claimed algorithms in approved mode.

2.7 Non-Approved Algorithms Allowed in the Approved Mode of Operation with No

Security Claimed There are no non-Approved Allowed functions with no security claimed algorithms in approved mode.

2.8 Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

The table below lists the non-Approved algorithms and security functions that are used in the non-Approved mode of operation: This document may be reproduced and distributed only in its original entirely without revision.

11 of 35

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

Table 8 - Executable Code Sets The module cryptographic boundary is delineated by the dotted green rectangle in the Figure

1. The Apple corecrypto Module v12.0 [Apple silicon, Kernel, Software, SL1] executes within the kernel space of the computing platforms and operating systems listed in Table 2 - Tested Operational Environments. In the block diagram below, the Kernel Extension (KEXT) is a bundle that performs low-level tasks. KEXTs run in kernel space, which gives them elevated privileges and the ability to perform tasks that user-space apps can’t. The tested operational environment’s physical perimeter (TOEPP) is represented by the most exterior black line in the block diagram Figure
2. Figure 1 - Block diagram This document may be reproduced and distributed only in its original entirely without revision.

12 of 35

interfaces are described in (Table 9 ): Table 9 - Ports and Interfaces The module is optimized for library use within the Device OS kernel space and does not contain any terminating assertions or exceptions. It is implemented as a Device OS dynamically loadable library. The dynamically loadable library is loaded into the Device OS kernel and its cryptographic functions are made available to Device OS kernel services only. Any internal error detected by the module is returned to the caller with an appropriate return code. The calling Device OS kernel service must examine the return code and act accordingly. The module communicates any error status synchronously through the use of its documented return codes, thus Caller-induced or internal errors do not reveal any sensitive material to callers. This document may be reproduced and distributed only in its original entirely without revision.

13 of 35

The module supports a single instance of one authorized role: The Crypto Officer. No support is provided for multiple concurrent operators. Table 10 - Roles FIPS 140-3 does not require an authentication mechanism for level 1 modules. Therefore, the module does not support an authentication mechanism for Crypto Officer. The Crypto Officer role is authorized to access all services provided by the module (see Table 12 - Approved Services and Table 13 - Non-Approved Services below).

Table 11 - Security Function Implementations The module implements a dedicated KPI function to indicate if a requested service utilizes an approved security function. For services listed in Table 12 - Approved Services, the indicator function returns 1 to indicate that the security function is approved. This document may be reproduced and distributed only in its original entirely without revision.

14 of 35

This document may be reproduced and distributed only in its original entirely without revision.

15 of 35

Table 12 - 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. Z = Zeroise: The module zeroises the SSP. N/A= The service does not access any SSP during its operation This document may be reproduced and distributed only in its original entirely without revision.

16 of 35

Table 13 - Non-Approved Services This document may be reproduced and distributed only in its original entirely without revision.

17 of 35

The Apple corecrypto Module v12.0 [Apple silicon, Kernel, Software, SL1], which is made up of a single component, is provided in the form of binary executable code. A software integrity test is performed on the runtime image of the module. The HMAC-SHA256 implemented in the module is used as the approved algorithm for the integrity test. If the test fails, the module enters an error state where no cryptographic services are provided, and data output is prohibited i.e., the module is not operational.

Integrity test is performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. Integrity test on demand is performed by power-cycling the computing platform . This document may be reproduced and distributed only in its original entirely without revision.

18 of 35

The Apple corecrypto Module v12.0 [Apple silicon, Kernel, Software, SL1] operates in a modifiable operational environment per FIPS 140-3 level 1 specifications. The module is supplied as part of Device OS, a commercially available general-purpose operating system executing on the computing platforms specified in section 2. This document may be reproduced and distributed only in its original entirely without revision.

19 of 35

The FIPS 140-3 physical security requirements do not apply to the Apple corecrypto Module v12.0 [Apple silicon, Kernel, Software, SL1], since it is a software module. This document may be reproduced and distributed only in its original entirely without revision.

20 of 35

Currently, the ISO/IEC 19790:2012 non-invasive security area is not required by FIPS 140-3 (see NIST SP 800140F). The requirements of this area are not applicable to the module. This document may be reproduced and distributed only in its original entirely without revision.

21 of 35

The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module: This document may be reproduced and distributed only in its original entirely without revision.

22 of 35

This document may be reproduced and distributed only in its original entirely without revision.

23 of 35

A NIST approved deterministic random bit generator based on a block cipher as specified in NIST [SP 80090ARev1] is used. The DRBG is a CTR_DRBG using AES-256 with derivation function and without prediction resistance. The random numbers used for key generation are all generated by CTR_DRBG in this module. Per section 10.2.1.1 of [SP 800-90ARev1], the internal state of CTR_DRBG is the value V and Key. The module performs DRBG health tests according to section 11.3 of [SP800-90Arev1]. The module also performs DRBG health tests according to section 11.3 of [SP800-90ARev1]. No non-DRBG functions or instances are able to access the DRBG internal state The deterministic random bit generators are seeded by “read_random”. The read_random is the kernel space interface. Two entropy sources (one non-physical entropy source and one physical entropy source) residing within the TOEPP provide the random bits. The output of entropy pool provides 256-bits of entropy to seed and reseed SP800-90ARev1 DRBG during initialization (seed) and reseeding (reseed). Table 15 – Entropy Sources

The module generates Keys and SSPs in accordance with FIPS 140-3 IG D.H. The cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric (ECDSA) keys as per [SP800-133r2] section 4 example 1 (vendor affirmed), compliant with [FIPS186-4], and using DRBG compliant with [SP800-90ARev1]. A seed (i.e., the random value) used in asymmetric key generation is obtained from [SP800-90ARev1] DRBG. The key generation service for ECDSA as well as the [SP 800-90ARev1] DRBG have been ACVT tested with algorithm certificates found in Table 6.

The module provides the following key/SSP establishment services in the Approved mode: • AES-Key Wrapping: The module implements a Key Transport Scheme (KTS) using AES-KW compliant to [SP800-38F], IG D.G. The SSP establishment methodology provides between 128 and 256 bits of encryption strength.

All keys and SSPs that are entered from, or output to module, are entered from or output to the invoking application running on the same device. Keys/ SSPs entered into the module are electronically entered in plain text form. The module only outputs ECDSA keys in plain text form when key generation service is requested by the calling application. This document may be reproduced and distributed only in its original entirely without revision.

24 of 35

Table 16 - Storage Areas Keys and SSPs are explicitly zeroised when the appropriate context object is destroyed or when the system is powered down. Input and output interfaces are inhibited while zeroisation is performed. This document may be reproduced and distributed only in its original entirely without revision.

25 of 35

While the module is executing the self-tests, services are not available, and input and output are inhibited. If the test fails either pre-operational and conditional self-tests, the module reports an error message indicating the cause of the failure and enters the Error State (See section 10.3). The module permits operators to initiate the pre-operational and conditional self-tests on demand and periodic testing of the module by rebooting the system (i.e., power-cycling). The module performs a pre-operational software integrity test automatically when the module is loaded into performed on the runtime image of the Apple corecrypto Module v12.0 [Apple silicon, Kernel, Software, SL1] with HMAC-SHA256 which is an approved integrity technique. Prior to using HMAC-SHA-256, a Conditional Cryptographic Algorithm Self-Tests (CASTs) is performed. Table 17 – Pre-Operational Self-Tests

10.2.1Conditional Cryptographic Algorithm Self-Tests In addition to the pre-operational software integrity test described in Section 10.1, the module runs the CASTs for all cryptographic functions of each approved cryptographic algorithm implemented by the module each time This document may be reproduced and distributed only in its original entirely without revision.

26 of 35

Table 18 - Self-Tests 10.2.2Conditional Pairwise Consistency Test The Apple corecrypto Module v12.0 [Apple silicon, Kernel, Software, SL1] generates ECDSA asymmetric key pairs and performs a pair-wise consistency tests on the newly generated key pairs.

If any of the self-tests described in Sections 10.1, 10.2.1 or 10.2.2 fail, the module reports the cause of the error and enters an error state. In the Error State, no cryptographic services are provided, and data output is prohibited. The only method to recover from the error state is to power cycle the device which results in the module being reloaded into memory and reperforming the pre-operational test and the Conditional algorithm self-tests. The module will only enter into the operational state after successfully passing the pre-operational self-test and the conditional self-tests. This document may be reproduced and distributed only in its original entirely without revision.

27 of 35

Table 19- Error states This document may be reproduced and distributed only in its original entirely without revision.

28 of 35

The module is built into DeviceOS defined in section 2 and delivered with Device OS. There is no standalone delivery of the module as a software library. The vendor’s internal development process guarantees that the correct version of module goes with its intended Device OS version. For additional assurance, the module is digitally signed by vendor, and it is verified during the integration into Device OS. This digital signature-based integrity protection during the delivery/integration process is not to be confused with the HMAC-256 based integrity check performed by the module itself as part of its pre-operational self-tests.

The Approved mode of operation is configured in the system by default and can only be transitioned into the non-Approved mode by calling one of the non-Approved services listed in Table 13 - Non-Approved Services. If the device starts up successfully, then the module has passed all self-tests and is operating in the Approved mode. The ESV Public Use Document (PUD) reference for physical entropy source is: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validationprogram/documents/entropy/E14_PublicUse.pdf The ESV Public Use Document (PUD) reference for non-physical entropy source is: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validationprogram/documents/entropy/E15_PublicUse.pdf Apple Platform Certifications guide [platform certifications] and Apple Platform Security guide [SEC] are provided by Apple which offers IT System Administrators with the necessary technical information to ensure FIPS 140-3 Compliance of the deployed systems. This guide walks the reader through the system’s assertion of cryptographic module integrity and the steps necessary if module integrity requires remediation.

The Crypto Officer shall consider the following requirements and restrictions when using the module: o AES-GCM internal IV is constructed in compliance with IG C.H scenario

1. The GCM IV generation follows RFC 4106 and shall only be used for the IPsec protocol version
2. When the IV in RFC 4106 exhausts the maximum number of possible values for a given security association, either party to the security association that encounters this condition triggers a rekeying with IKEv2 to establish a new encryption key for the security association. The module uses RFC 7296 compliant IKEv2 to establish the shared secret SKEYSEED from which the AES-GCM encryption keys are derived. In case the module’s power is lost and then restored, the key used for the AES GCM encryption/decryption shall be re-distributed. This condition is not enforced by the module. This protocol has not been reviewed or tested by the CAVP and CMVP. This document may be reproduced and distributed only in its original entirely without revision.

29 of 35

• AES-XTS mode is only approved for hardware storage applications. The length of the AES-XTS data unit does not exceed 220 blocks. The module checks explicitly that Key_1 ≠ Key_2 before using the keys in the XTS-Algorithm to process data with them compliant with IG C.I.
• RSA modulus size (IG C.F): In compliance with FIPS 186-4, the RSA signature verification is greater or equal to 1024 bits. All supported RSA modulus sizes have been CAVP tested.
• Legacy use (IG C.M): Per SP800-131r2, the SHA-1 within FIPS 186-4 RSA and ECDSA Digital Signature Verification is used in approved mode (for legacy use), the RSA 1024-bit modulus is used in approved mode for FIPS 186-4 signature verification (for legacy use).

The module secure sanitization is accomplished by first powering the module down, which will zeroize all SSPs within volatile memory. Following the power-down, an uninstall by way of system wipe or system update will zeroize the binary file listed in section 2.9. This document may be reproduced and distributed only in its original entirely without revision.

30 of 35

The module does not claim mitigation of other attacks. This document may be reproduced and distributed only in its original entirely without revision.

31 of 35

Appendix A.                  Glossary and Abbreviations AES                    Advanced Encryption Standard CAVP                   Cryptographic Algorithm Validation Program CAST                   Cryptographic Algorithm Self-Test CAST5                  A symmetric-key 64-bit block cipher with 128-bit key CBC                    Cipher Block Chaining CCM                    Counter with Cipher Block Chaining-Message Authentication Code CFB                    Cipher Feedback CMVP                   Cryptographic Module Validation Program CSP                    Critical Security Parameter CTR                    Counter Mode DRBG                   Deterministic Random Bit Generator ECB                    Electronic Code Book ESVP                   Entropy Source Validation Program FIPS                   Federal Information Processing Standards Publication GCM                    Galois Counter Mode HMAC                   Hash Message Authentication Code KAT                    Known Answer Test KDF                    Key Derivation Function KEXT                   Kernel Extension KW                     AES Key Wrap MAC                    Message Authentication Code KPI                    Kernel Programming Interface NIST                   National Institute of Science and Technology OFB                    Output Feedback PAA                    Processor Algorithm Acceleration PKG                    Key-Pair Generation PKV                    Public Key Validation PSS                    Probabilistic Signature Scheme PUD                    Public Use Document RSA                    Rivest, Shamir, Addleman SHA                    Secure Hash Algorithm SHS                    Secure Hash Standard TOEPP                  Tested Operational Environment Physical Perimeter XTS                    XEX-based Tweaked-codebook mode with cipher text Stealing This document may be reproduced and distributed only in its original entirely without revision.

32 of 35

SP800-135 NIST Special Publication 800-135 Revision 1 - Recommendation for Existing Application-Specific Key Derivation Functions December 2011 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-135r1.pdf SEC Apple Platform Security https://support.apple.com/guide/security/welcome/web https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/apple-platform-security-guide.pdf platform certifications Apple Platform Certifications https://support.apple.com/guide/certifications/welcome/web This document may be reproduced and distributed only in its original entirely without revision.

35 of 35