Apple corecrypto Module v13.0 [Intel, User, Software, SL1]

Certificate

Approved Algorithms (158)

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

flowchart LR
  %% Deterministic review-risk graph for Apple corecrypto Module v13.0 [Intel, User, 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>Firmware Load</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>TLS<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 v13.0 [Intel, User, 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>Firmware Load</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>TLS<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 v13.0 [Intel, User, Software, SL1] Document Version 2.0 January 2025 Prepared by: Lightship Security Inc. 1101-150 Isabella Street, Ottawa, ON, K1S 1V7 www.lightshipsec.com This document may be reproduced and distributed only in its original entirety without revision.

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 entirety without revision.

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

Tables Table 5 – Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed 10 This document may be reproduced and distributed only in its original entirety without revision.

This document is the non-proprietary FIPS 140-3 Security Policy for Apple corecrypto Module v13.0 [Intel, User, 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 The Module has an overall security level of 1. This document may be reproduced and distributed only in its original entirety without revision.

2. Cryptographic Module Specification The Apple corecrypto Module v13.0 [Intel, User, 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 13 written as v13.0. The module provides implementations of low-level cryptographic primitives to the Host OS's (macOS Ventura v13) Security Framework and Common Crypto. The module has been tested by Lightship Security, Inc. CST lab on the following platforms with and without Table 2 – Tested operational environments. In addition to the platforms listed above, Apple Inc. has also tested the module on the following platforms and claims vendor affirmation on them: This document may be reproduced and distributed only in its original entirety without revision.

Table 3

• Affirmed operational environments. 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 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. The module is in the Approved mode of operation when the module utilizes the services that use the security functions listed in the table below. 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 10
• Non-approved services. 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 entirety without revision.

The TLS and IPSec/IKE protocols have not been reviewed or tested by the CAVP and CMVP. The TLS and IPSec/IKE protocols have not been reviewed or tested by the CAVP and CMVP. This document may be reproduced and distributed only in its original entirety without revision.

Table 4 – Approved algorithms The table below list non-Approved but Allowed algorithm in Approved mode of operation when used as part of an approved key transport scheme where no security is provided by the algorithm. This document may be reproduced and distributed only in its original entirety without revision.

Table 5

• Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed The table below lists Non-Approved security functions that are not Allowed in the Approved Mode of Operation: Table 6
• Non-approved algorithms Not Allowed in the Approved Mode of Operation Triple-DES encryption/decryption was tested as part of CAVP algorithm testing, but is not utilized for any services implemented/supported by the module in Approved mode of operation. This document may be reproduced and distributed only in its original entirety without revision.

The Apple corecrypto Module v13.0 [Inter, User, Software, SL1] executes within the user space of the computing platforms and operating systems listed in Table 2

• Tested operational environments. Figure 1 below shows the logical block diagram representing the following information:
• The location of the logical object of the module with respect to the operating system, other supporting applications and the cryptographic boundary so that all the logical and physical layers between the logical object and the cryptographic boundary are clearly defined; and
• The interactions of the logical object of the module with the operating system and other supporting applications resident within the cryptographic boundary. Figure 1
• Logical block diagram. This document may be reproduced and distributed only in its original entirety without revision.

3. Cryptographic Module Interfaces As a software-only module, the module does not have physical ports. For the purpose of the FIPS 140-3 validation, the physical ports are interpreted to be the physical ports of the hardware platform on which it runs. (APIs). In detail these interfaces are described in the table below. Table 7 – Ports and interfaces The module is optimized for library use within the macOS user space and does not contain any terminating assertions or exceptions. It is implemented as a macOS dynamically loadable library. After the dynamically loadable library is loaded, its cryptographic functions are made available to the macOS application. Any internal error detected by the module is reflected back to the caller with an appropriate return code. The calling macOS application must examine the return code and act accordingly. The module communicates any error status synchronously using its documented return codes, thus indicating the module's status. It is the responsibility of the caller to handle exceptional conditions in a FIPS 140-3 appropriate manner. Caller-induced or internal errors do not reveal any sensitive material to callers. Cryptographic bypass The Module does not output control information, and thus has no specified control output interface. This document may be reproduced and distributed only in its original entirety without revision.

The Module supports a single instance of one authorized role, designated as the Crypto-Officer. No support is provided for multiple concurrent operators or a Maintenance Operator The table below lists the services available to the Crypto Officer: This document may be reproduced and distributed only in its original entirety without revision.

Table 8 – Roles, Services, Input and Output

FIPS 140-3 does not require an authentication mechanism for level 1 modules. Therefore, the module does not implement an authentication mechanism for Crypto Officer. The Crypto Officer role is authorized to access all services provided by the module (see Table 9

• Approved services and Table 10
• Non-approved services below).

The module implements a dedicated API function to indicate if a requested service utilizes an approved security function. For services listed in Table 9 – Approved services, the indicator function returns

1. For services listed in Table 10 – Non-approved services, the indicator function returns
2. The table below lists all approved services that can be used in the approved mode of operation. The 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 In accordance with Section 4 and 5.1 of NIST [SP 800-133r2] (CKG), the module uses its approved DRBG to generate random bits and seeds used to generate asymmetric keys. Each generated seed is an unmodified output from the DRBG. This document may be reproduced and distributed only in its original entirety without revision.

In accordance with Section 4 and 5.1 of NIST [SP 800-133r2] (CKG), the module uses its approved DRBG to generate random bits and seeds used to generate asymmetric keys. Each generated seed is an unmodified output from the DRBG. This document may be reproduced and distributed only in its original entirety without revision.

Table 9 – Approved services The table below lists all non-Approved services that can only be used in the non-Approved mode of operation. This document may be reproduced and distributed only in its original entirety without revision.

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

Input for Decryption: key and cipher text Output for Decryption: plain text

Table 10 – Non-approved services This document may be reproduced and distributed only in its original entirety without revision.

The Apple corecrypto Module v13.0 [Intel, User, 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-SHA2-256 implemented in the module is used as an 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. In this state the module is not operational.

Integrity tests are performed as part of the Pre-Operational Self-Tests. The software integrity test is automatically executed at power-on. It can also be invoked by self-test service or powering-off and reloading the module. This document may be reproduced and distributed only in its original entirety without revision.

The Apple corecrypto Module v13.0 [Intel, User, Software, SL1] operates in a modifiable operational environment per FIPS 140-3 level 1 specifications. The module is supplied as part of macOS, 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 entirety without revision.

7. Physical Security The FIPS 140-3 physical security requirements do not apply to the Apple corecrypto Module v13.0 [Intel, User, Software, SL1] since it is a software module. This document may be reproduced and distributed only in its original entirety without revision.

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

9. Sensitive Security Parameter Management 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 entirety without revision.

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

A NIST approved deterministic random bit generator based on a block cipher as specified in NIST [SP 80090Ar1] is used. The default Approved DRBG used for random number generation 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-90Ar1], the internal state of CTR_DRBG is the value V and Key. The deterministic random bit generators are seeded by /dev/random. The /dev/random is the User Space interface that extracts random bits from the entropy pool. Two entropy sources (one non-physical entropy source and one physical entropy source) residing within the TOEPP provide the random bits. The output of (seed) and reseeding (reseed). The module also employs a HMAC_DRBG for random number generation. The HMAC_DRBG is only used at the early boot time of macOS kernel for memory randomization. The output of HMAC_DRBG is not used for key generation. Per section 10.1.2.1 of [SP 800-90Ar1], the internal state of HMAC_DRBG is the value V, Key. For both Apple Entropy sources tested in the OEs listed in Table 2, the customer does not have the ability to modify the ES configuration settings (see details in Public Use Document referenced in 3 and 4). The module also performs DRBG health tests according to section 11.3 of [SP 800-90Ar1]. Table 12 – Non-Deterministic Random Number Generation Specification

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 keys as per [SP 800-133r2] Section 4 (vendor affirmed), compliant with [FIPS186-4], and using DRBG compliant with [SP 800-90Ar1]. A seed (the random value) used in asymmetric key generation is obtained from [SP 800-90Ar1] DRBG. The key generation service for RSA, Diffie-Hellman and EC key pairs as well as the [SP 800-90Ar1] DRBG have been ACVT tested with algorithm certificates found in Table 4. This document may be reproduced and distributed only in its original entirety without revision.

The module also implements the following key derivation functions:

The module provides the following SSP establishment related services in the Approved mode:

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. Keys/SSPs are output from the module in plain text form if required by the calling application. The module allows the output of plaintext CSPs (for example: EC/DH/RSA Key Pairs). To prevent inadvertent output of sensitive information, the module performs the following two independent internal actions:

1. The module will internally request the random number generation service to obtain the random numbers and verify that the service completed without errors.
2. Once the keys are generated the module will perform the pairwise consistency test and verify that the test is completed without errors. Only after successful completion of both actions, are the generated CSPs output via the API output parameter in plaintext.

The Module stores keys/SSPs in volatile memory only. They are received for use or generated by the module only at the command of the calling application. The module does not provide persistent keys/SSPs storage. The module protects all keys/SSPs through the memory separation and protection mechanisms provided by the operating system. No process other than the module itself can access the keys/SSPs in its process memory. This document may be reproduced and distributed only in its original entirety without revision.

Keys and SSPs are 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 entirety without revision.

10. Self-tests This section specifies the pre-operational and conditional self-tests performed by the module. The preoperational and conditional self-tests ensure that the module is not corrupted and that the cryptographic algorithms work as expected. The module does not implement a bypass mode nor security functions critical to the secure operation of the cryptographic module and thus, does not implement either a pre-operational bypass test or pre-operational critical functions test. While the module is executing the self-tests, services are not available and input and output are inhibited. If any pre-operational or conditional self-tests fail, 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 preoperational or conditional self-tests on demand for periodic testing of the module by rebooting the system (i.e., power-cycling).

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 software integrity test is performed on the runtime image of the Apple corecrypto Module v13.0 [Intel, User, Software, SL1] with HMAC-SHA2-256 used to perform the approved integrity technique. Prior to using HMAC-SHA2-256, Conditional Cryptographic Algorithm Self-Test (CAST) is performed. If the CAST on the HMAC-SHA2-256 is successful, the HMAC value of the runtime image is recalculated and compared with the stored HMAC value pre-computed at compilation time.

Conditional self-tests are performed by a cryptographic module when the conditions specified for the following tests occur: Cryptographic Algorithm Self-Test, Pair-Wise Consistency Test. The module does not implement any functions requiring a Software/Firmware Load Test, Manual Entry Test, Conditional Bypass Test nor Conditional Critical Functions Test; therefore, these tests are not performed by The following sub-sections describe the conditional tests supported by the Apple corecrypto Module v13.0 [Intel, User, Software, SL1]. 10.2.1. Conditional Cryptographic Algorithm Self-Tests In addition to the pre-operational software integrity test described in Section 10.1, the Apple corecrypto Module v13.0 [Intel, User, Software, SL1] also runs the Conditional Cryptographic Algorithm Self-Tests (CAST) for all cryptographic functions of each approved cryptographic algorithm implemented by the module during power-up as well. All CASTs are performed prior to the first operational use of the cryptographic algorithm. These tests are detailed in Table 13 – Conditional Cryptographic Algorithm Self-tests below. This document may be reproduced and distributed only in its original entirety without revision.

The Apple corecrypto Module v13.0 [Intel, User, Software, SL1] does generate RSA, DH and EC keys and performs the required pair-wise consistency tests on the newly generated key pairs.

If any of the above-mentioned 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 software integrity test and the Conditional CASTs. The module will only enter into the operational state after successfully passing the preoperational software integrity test and the Conditional CASTs. The table below shows the different causes that lead to the Error State and the status indicators reported. Table 14 – Error Indicators This document may be reproduced and distributed only in its original entirety without revision.

The module is built into macOS Ventura v13 and delivered with the respective device. 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 macOS version. For additional assurance, the module is digitally signed by vendor and it is verified during the integration into macOS. This digital signature-based integrity protection during the delivery/integration process is not to be confused with the HMAC-SHA2-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 10 – 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/E110_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:

is met implicitly. The module does not retain any state when power is lost. As indicated in Table 11, column Storage, the module exclusively uses volatile storage. This means that AES-GCM key/IVs are not persistently stored during power off: therefore, there is no re-connection possible when the power is back on with re-generation of the key used for GCM. After restoration of the power, the user of the module (e.g., TLS, IKE) along with User application that implements the protocol, must perform a complete new key establishment operation using new random numbers (Entropy input string, DRBG seed, DRBG internal state V and Key, shared secret values that are not retained during power cycle, see table 11) with subsequent KDF operations to establish a new GCM key/IV pair on either side of the network communication channel. These protocols have not been reviewed or tested by the CAVP and CMVP. • 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. This document may be reproduced and distributed only in its original entirety without revision.

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

Appendix A.                    Glossary and Abbreviations AES             Advanced Encryption Standard AES-NI          Advanced Encryption Standard New Instructions CAVP            Cryptographic Algorithm Validation Program CAST            Cryptographic Algorithm Self-Test CBC             Cipher Block Chaining CCM             Counter with Cipher Block Chaining-Message Authentication Code CFB             Cipher Feedback CMAC            Cipher-based Message Authentication Code CMVP            Cryptographic Module Validation Program CSP             Critical Security Parameter CTR             Counter Mode DRBG            Deterministic Random Bit Generator ECB             Electronic Code Book ENT             NIST SP 800-90B Compliant Entropy Source FFC             Finite Field Cryptography FIPS            Federal Information Processing Standards Publication GCM             Galois Counter Mode HMAC            Hash Message Authentication Code KAS             Key Agreement Scheme KAT             Known Answer Test KBKDF           Key Based Key Derivation Function KDF             Key Derivation Function KW              AES Key Wrap MAC             Message Authentication Code NIST            National Institute of Science and Technology OAEP            Optimal Asymmetric Encryption Padding OFB             Output Feedback PAA             Processor Algorithm Acceleration PBKDF           Password Based Key Derivation Function PKG             Key-Pair Generation PKV             Public Key Validation PRF             Pseudo-Random Function PSS             Probabilistic Signature Scheme RSA             Rivest, Shamir, Addleman SHA             Secure Hash Algorithm SHS             Secure Hash Standard SSC             Shared Secret Computation TOEPP           Tested Operational Environment Physical Perimeter XTS             XEX Tweakable Block Ciphertext Stealing This document may be reproduced and distributed only in its original entirety without revision.