Apple corecrypto Module v14.1 [Apple silicon, Kernel, Software, SL1]

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Apple corecrypto Module v14.1 [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>Self-Test<br/>UnAuth<br/>Status output</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 v14.1 [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>Self-Test<br/>UnAuth<br/>Status output</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 v14.1 [Apple silicon, Kernel, Software, SL1] Prepared for: Apple Inc. 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

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

Trademarks Apple’s trademarks applicable to this document are listed in https://www.apple.com/legal/intellectual-property/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.

This document is the non-proprietary FIPS 140-3 Security Policy for Apple corecrypto Module v14.1 [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 This document provides all tables and diagrams (when applicable) required by NIST SP 800140Br1.

Table 1: Security Levels This document may be reproduced and distributed only in its original entirely without revision.

Purpose and Use: The Apple corecrypto Module v14.1 [Apple silicon, Kernel, Software, SL1] cryptographic module (hereafter referred to as “the module”) provides implementations of lowlevel cryptographic primitives to the visionOS’s kernels Security Framework and Common Crypto. The module provides services intended to protect data in transit and at rest. The module is optimized for library use within the visionOS kernel space and does not contain any terminating assertions or exceptions. It is implemented as a visionOS dynamically loadable library. The library is loaded into the visionOS kernel and its cryptographic functions are made available to visionOS kernel services only. Any internal error detected by the module is returned to the caller with an appropriate return code. The calling visionOS 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 indicating the module’s status. Caller-induced or internal errors do not reveal any sensitive material to callers. Module Type: Software Module Embodiment: MultiChipStand Cryptographic Boundary: The module cryptographic boundary is delineated by the dotted green rectangle in the Figure 1 where 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. Tested Operational Environment’s Physical Perimeter (TOEPP): The physical perimeter is represented by the most exterior black line in the block diagram Figure 1. The module executes within the kernel space of the computing platforms and operating systems listed in the Tested Operational Environments Table section 2.2. This document may be reproduced and distributed only in its original entirely without revision.

Tested Module Identification

• Hardware: N/A for this module. Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Module Identification
• Hybrid Disjoint Hardware: N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid: Table 3: Tested Operational Environments - Software, Firmware, Hybrid This document may be reproduced and distributed only in its original entirely without revision.

Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid:

None for this module. Modes List and Description: Operation is assumed automatically without any specific configuration. If the device starts up successfully then the module has passed all self-tests and is operating in the Approved mode. This document may be reproduced and distributed only in its original entirely without revision.

Table 5: Approved Algorithms The FIPS 186-4 CAVP tests in the listed ACVP certificates above are mathematically identical to the FIPS 186-5 CAVP tests. Per FIPS 140-3 C.K Additional Comments 2, the module claims compliance with FIPS 186-5 tests. Vendor-Affirmed Algorithms: Table 6: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: This document may be reproduced and distributed only in its original entirely without revision.

N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: Table 7: Non-Approved, Not Allowed Algorithms

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

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

Table 8: Security Function Implementations

AES-GCM AES-GCM IV is constructed in compliance with IG C.H scenario 1 (IPsec-v3). This document may be reproduced and distributed only in its original entirely without revision.

The GCM IV generation follows RFC 4106 and shall only be used for the IPsec protocol version 3. 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 AESGCM encryption keys are derived. In compliance with IG C.H section 3, if 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. AES-XTS 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. Digital signature generation using SHA-1 is non-approved and not allowed in approved services. Digital signature verification using SHA-1 is considered approved (“Legacy”). HMAC using SHA-1 is approved. The SHA-1 algorithm, as implemented by the module, will be non-approved for all purposes except signature verification, starting January 1, 2031. Note: Algorithms designated as “Legacy” can only be used on data that was generated prior to the Legacy Date specified in FIPS 140-3 IG C.M.

Table 10: Entropy Sources This document may be reproduced and distributed only in its original entirely without revision.

Entropy source(s): The random bits used to seed and reseed the module’s approved DRBG comes from a physical entropy source residing within the TOEPP. The entropy source includes a vetted conditioning component in the form of a SHA-256. The min-entropy rate at the output of the entropy source (h_out for the output of the conditioning component per Section 3.1.5 of SP 800-90B) is 256 bits per 256-bit output. The entropy source follows IG 9.3.A scenario 1.(b) i.e., the module is a software module and the entropy sources reside outside of the cryptographic boundary but inside the module’s TOEPP. DRBG(s): The module implements an SP 800-90ARev1 approved deterministic random bit generator (DRBG) in the form of a CTR_DRBG using AES-256 with derivation function and without prediction resistance. The module performs DRBG health tests according to SP800-90ARev1 section 11.3. DRBG Output: The output of CTR_DRBG provides up to 256-bits of security strength.

The module implements asymmetric key generation compliant to SP800-133r2 Section 4 examples 1 and is listed as a vendor affirmed algorithm per FIPS 140_3 IG D.H. The seed material used to generate the asymmetric key pairs is provided directly output from the module’s CTR_DRBG. The module does not implement symmetric key generation.

The module does not implement key establishment.

No parts of the IPSec, other than those mentioned above, have been tested by the CAVP and CMVP. This document may be reproduced and distributed only in its original entirely without revision.

Table 11: Ports and Interfaces This document may be reproduced and distributed only in its original entirely without revision.

N/A for this module. 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 - Approved Services and Table - Non-Approved Services).

The abbreviations of the access rights to SSPs have the following interpretation: 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.

G,W,E W,E G,R This document may be reproduced and distributed only in its original entirely without revision.

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

Z Table 13: Approved Services Table 14: Non-Approved Services

The module does not support the loading of external software/firmware. This document may be reproduced and distributed only in its original entirely without revision.

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

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.

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

Type of Operational Environment: Modifiable

The module is supplied as part of visionOS, a commercially available general-purpose operating system executing on the computing platforms specified in section 2.2. This document may be reproduced and distributed only in its original entirely without revision.

The FIPS 140-3 physical security requirements do not apply to the Apple corecrypto Module v14.1 [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.

Per IG 12.A, until the requirements of NIST SP 800-140F are defined, non-invasive mechanisms fall under ISO/IEC 19790:2012 Section 7.12 Mitigation of other attacks. 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.

Table 15: Storage Areas Table 16: SSP Input-Output Methods Table 17: SSP Zeroization Methods This document may be reproduced and distributed only in its original entirely without revision.

Table 18: SSP Table 1 This document may be reproduced and distributed only in its original entirely without revision.

Table 19: SSP Table 2 This document may be reproduced and distributed only in its original entirely without revision.

While the module is executing the self-tests, services are not available, and input and output are inhibited.

The module performs a pre-operational software integrity automatically when the module is loaded into memory (i.e., at power on) before the module transitions to the operational state. A used to perform the approved integrity technique. Prior to using HMAC-SHA-256, a Conditional Cryptographic Algorithm Self-Tests (CAST) is performed. Table 20: Pre-Operational Self-Tests

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

Table 21: Conditional Self-Tests

Table 22: Pre-Operational Periodic Information This document may be reproduced and distributed only in its original entirely without revision.

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

The module permits operators to initiate the pre-operational or conditional self-tests on demand for periodic testing of the module by rebooting the system (i.e., power-cycling). This document may be reproduced and distributed only in its original entirely without revision.

Startup Procedures: The module is built into visionOS defined in section 2 and delivered/ installed with the respective visionOS. There is no standalone delivery of the module as a software library. Installation Process and Authentication Mechanisms: The vendor’s internal development process guarantees that the correct version of module goes with its intended visionOS version. For additional assurance, the module is digitally signed by vendor, and it is verified during the integration into Host visionOS. 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 - Non-Approved Services. If the device starts up successfully, then the module has passed all self-tests and is operating in the Approved mode. Apple Platform Certifications guide and Apple Platform Security guide 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.

No non-administrator guidance.

The Crypto Officer shall consider the following requirements and restrictions when using the module.

• AES-GCM see section 2.7.
• AES-XTS see section 2.7. This document may be reproduced and distributed only in its original entirely without revision.

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 corecrypto-1638.100.62 binary file listed in Table 2. This document may be reproduced and distributed only in its original entirely without revision.

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