Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2)

Certificate

Approved Algorithms (78)

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

flowchart LR
  %% Deterministic review-risk graph for Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2)
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    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/>kernel<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    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"]
    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"]
    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
  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 C3,C5,C6 clue;
  class I3,I5,I6 infer;
  class R3,R5,R6 risk;
  class E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2)
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    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/>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 C3,C5,C6 clueLow;

Security Policy, page by page

Apple Inc. Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) document version 1.1 July 2024 Prepared for: Apple One Apple Park Way Cupertino, CA 95014 Prepared by: atsec information security corporation

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/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.

This document is the non-proprietary FIPS 140-3 Security Policy for Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) 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 2 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. The overall Security Rating of the module is SL2. ISO/IEC 24759 Section 6. FIPS 140-3 Section Title Security Level [Number Below]

1 General 2

2 Cryptographic Module Specification 2

3 Cryptographic Module Interfaces 2

4 Roles, Services, and Authentication 2

5 Software/Firmware Security 2

6 Operational Environment Not Applicable

7 Physical Security 2

8 Non-invasive Security Not Applicable

9 Sensitive Security Parameter Management 2

10 Self-tests 2

11 Life-cycle Assurance 2

12 Mitigation of Other Attacks Not Applicable

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

The Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) cryptographic module (hereafter referred to as “the module”) is a Hardware module implemented as a sub-chip running on a single-chip processor. The version of module’s firmware is 11.1 and the Hardware version is 2.0. The sub-chip module is embedded in the hardware listed in Table 2. The sub-chip module’s firmware is bundled together with the underlying Device OS.

The module consists of both firmware and hardware components. The Secure Key Store (SKS) application is the module’s firmware which operates within the sepOS execution environment which is separate from the Device OS’s (iOS 14.2, iPadOS 14.2, watchOS 7.1, tvOS 14.2, and TxFW 11.0.1) execution environment. The firmware boundary is defined as the API offered by the mailbox interface to callers from the Device OS execution environment. SKS has an API layer that provides consistent interfaces to the supported services and therefore the supported cryptographic algorithms. The sepOS execution environment is driven by its own SoC and operates from a dedicated region of the device’s memory. Both the Device’s and sepOS’ execution environments are physically separated on the SoC and thus execute independently of each other. The cryptographic module boundary includes the following hardware components:

• Hardware Random Number Generator composed of an SP800-90ARev1 Approved CTR_DRBG and a physical entropy source (ESV) compliant to SP800-90B.
• Hardware AES implementations using 128-bit to 256-bit keys.
• Hardware Public Key Accelerator (PKA) used for generating non-approved P-224, P-256, P-384 or P-521 asymmetric key pairs.
• A shared memory segment (called Mailbox) that can be accessed by both SKS and the Device OS’s XNU kernel, supported with an interrupt system and used by XNU to request services of the SKS module.
• A volatile RAM for storing runtime SSPs.
• A non-volatile Flash for storing Class D key and encrypted user keybag.

The photograph of each hardware module is shown below: Figure 1: Apple A9 Figure 2: Apple A9X Figure 3: Apple A10 Fusion Figure 4: Apple A10X Fusion Figure 5: Apple A111 Bionic Figure 6: Apple A12 Figure 8: Apple S3 Figure 9: Apple S4 Figure 10: Apple S5 Figure 7: Apple A12X Bionic Bionic / A12Z2 Bionic

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

Figure 11: Apple S6 Figure 12: Apple T2 The block diagram below depicts the following information:

• The location of the logical object of the firmware components of the hardware 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.
• The interactions of the logical object of the module with the operating system and other supporting applications resident within the cryptographic Figure 13-Block Diagram

The hardware module has been tested by atsec CST lab on the following platforms: Model Hardware Firmware Processor(s) Distinguishing version(s) version(s) Features iPad (5th generation) running sepOS distributed with iPadOS 14.2 2.0 11.1 Apple A9 N/A iPad Pro 9.7-inch running sepOS distributed with iPadOS 14.2 2.0 11.1 Apple A9X N/A iPad (7th generation) running sepOS distributed with iPadOS 14.2 2.0 11.1 Apple A10 N/A Fusion iPad Pro 10.5 inch running sepOS distributed with iPadOS 14.2 2.0 11.1 Apple A10X N/A Fusion iPad mini (5th generation) running sepOS distributed with iPadOS 2.0 11.1 Apple A12 N/A

14.2 Bionic

iPad Pro 11-inch (1st generation) running sepOS distributed with 2.0 11.1 Apple A12X N/A iPadOS 14.2 Bionic This document may be reproduced and distributed only in its original entirely without revision.

iPad Pro 11-inch (2nd generation) running sepOS distributed with 2.0 11.1 Apple A12Z N/A iPadOS 14.2 Bionic iPhone 6S running sepOS distributed with iOS 14.2 2.0 11.1 Apple A9 N/A iPhone 7 Plus running sepOS distributed with iOS 14.2 2.0 11.1 Apple A10 N/A Fusion iPhone X running sepOS distributed with iOS 14.2 2.0 11.1 Apple A11 N/A Bionic iPhone XS Max running sepOS distributed with iOS 14.2 2.0 11.1 Apple A12 N/A Bionic Apple Watch Series S3 running sepOS distributed with watchOS 7.1 2.0 11.1 Apple S3 N/A Apple Watch Series S4 running sepOS distributed with watchOS 2.0 11.1 Apple S4 N/A 7.1 Apple Watch Series S5 running sepOS distributed with watchOS 7.1 2.0 11.1 Apple S5 N/A Apple Watch Series S6 running sepOS distributed with watchOS 2.0 11.1 Apple S6 N/A 7.1 Apple TV 4K running sepOS distributed with tvOS 14.2 2.0 11.1 Apple A10X N/A Fusion Apple Security Chip T2 running sepOS distributed with TxFW 11.0.1 2.0 11.1 Apple T2 N/A Table 2 - Tested Operational Environments

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. Some of the CAVP certificates, show testing for AES CTR, CCM or OFB modes but they are not used by the module. 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.

Algorithm and Description / Key Size(s) / Key CAVP Cert. Mode / Method Use / Function Standard Strength(s) AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption A1342 CBC 800-38 A] 192, 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption A1343 CBC 800-38 A] 192, 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption A1344 CBC 800-38 A] 192, 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption A1345 CBC 800-38 A] 192, 256 and Decryption AES [FIPS 197] [SP Key Length / Key Strength: 128, Symmetric Encryption A510 CBC 800-38 A] 192, 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C314 CBC 800-38 A] 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C315 CBC 800-38 A] 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C317 CBC 800-38 A] 256 and Decryption This document may be reproduced and distributed only in its original entirely without revision.

Algorithm and Description / Key Size(s) / Key CAVP Cert. Mode / Method Use / Function Standard Strength(s) AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C318 CBC 800-38 A] 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C319 CBC 800-38 A] 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C320 CBC 800-38 A] 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C322 CBC 800-38 A] 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C326 CBC 800-38 A] 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C330 CBC 800-38 A] 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C358 CBC 800-38 A] 256 and Decryption AES [FIPS 197] [SP Symmetric Encryption AES 5261 ECB Key Length/ Key Strength: 256 800-38 A] and Decryption AES [FIPS 197] [SP Symmetric Encryption AES 5272 ECB Key Length/ Key Strength: 256 800-38 A] and Decryption AES [FIPS 197] [SP Symmetric Encryption AES 5273 ECB Key Length/ Key Strength: 256 800-38 A] and Decryption AES [FIPS 197] [SP Symmetric Encryption AES 5274 ECB Key Length/ Key Strength: 256 800-38 A] and Decryption AES [FIPS 197] [SP Symmetric Encryption AES 5275 ECB Key Length/ Key Strength: 256 800-38 A] and Decryption AES [FIPS 197] [SP Symmetric Encryption AES 5278 ECB Key Length/ Key Strength: 256 800-38 A] and Decryption AES [FIPS 197] [SP Symmetric Encryption AES 5279 ECB Key Length/ Key Strength: 256 800-38 A] and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption A1342 ECB 800-38 A] 192, 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption A1343 ECB 800-38 A] 192, 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption A1345 ECB 800-38 A] 192, 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption A1346 ECB 800-38 A] 192, 256 and Decryption AES [FIPS 197] [SP Symmetric Encryption A501 ECB Key Length/ Key Strength: 256 800-38 A] and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption A510 ECB 800-38 A] 192, 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C314 ECB 800-38 A] 256 and Decryption This document may be reproduced and distributed only in its original entirely without revision.

Algorithm and Description / Key Size(s) / Key CAVP Cert. Mode / Method Use / Function Standard Strength(s) AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C315 ECB 800-38 A] 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C317 ECB 800-38 A] 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C318 ECB 800-38 A] 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C319 ECB 800-38 A] 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C320 ECB 800-38 A] 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C322 ECB 800-38 A] 256 and Decryption AES [FIPS 197] [SP Symmetric Encryption C323 ECB Key Length/ Key Strength: 256 800-38 A] and Decryption AES [FIPS 197] [SP Symmetric Encryption C324 ECB Key Length/ Key Strength: 256 800-38 A] and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C326 ECB 800-38 A] 256 and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C330 ECB 800-38 A] 256 and Decryption AES [FIPS 197] [SP Symmetric Encryption C331 ECB Key Length/ Key Strength: 256 800-38 A] and Decryption AES [FIPS 197] [SP Key Length/ Key Strength: 128, Symmetric Encryption C358 ECB 800-38 A] 256 and Decryption CTR_DRBG AES-256; No Derivation Function; Random Number DRBG 2014 Key Length/ Key Strength: 256 [SP800-90ARev1] Prediction Resistance Enabled Generation CTR_DRBG AES-256; No Derivation Function; Random Number DRBG 2022 Key Length/ Key Strength: 256 [SP800-90ARev1] Prediction Resistance Enabled Generation CTR_DRBG AES-256; No Derivation Function; Random Number DRBG 2023 Key Length/ Key Strength: 256 [SP800-90ARev1] Prediction Resistance Enabled Generation CTR_DRBG AES-256; No Derivation Function; Random Number DRBG 2024 Key Length/ Key Strength: 256 [SP800-90ARev1] Prediction Resistance Enabled Generation CTR_DRBG AES-256; No Derivation Function; Random Number DRBG 2025 Key Length/ Key Strength: 256 [SP800-90ARev1] Prediction Resistance Enabled Generation CTR_DRBG AES-256; No Derivation Function; Random Number DRBG 2028 Key Length/ Key Strength: 256 [SP800-90ARev1] Prediction Resistance Enabled Generation CTR_DRBG AES-256; No Derivation Function; Random Number DRBG 2029 Key Length/ Key Strength: 256 [SP800-90ARev1] Prediction Resistance Enabled Generation CTR_DRBG AES-256; No Derivation Function; Random Number A501 Key Length/ Key Strength: 256 [SP800-90ARev1] Prediction Resistance Enabled Generation CTR_DRBG AES-256; No Derivation Function; Random Number C323 Key Length/ Key Strength: 256 [SP800-90ARev1] Prediction Resistance Enabled Generation This document may be reproduced and distributed only in its original entirely without revision.

Algorithm and Description / Key Size(s) / Key CAVP Cert. Mode / Method Use / Function Standard Strength(s) CTR_DRBG AES-256; No Derivation Function; Random Number C324 Key Length/ Key Strength: 256 [SP800-90ARev1] Prediction Resistance Enabled Generation CTR_DRBG AES-256; No Derivation Function; Random Number C331 Key Length/ Key Strength: 256 [SP800-90ARev1] Prediction Resistance Enabled Generation CKG [SP800vendor affirmed AES key Key Length/ Key Strength: 256 Key Generation 133Rev2] Key Length/ Key Strength: 112 A1340 HMAC [FIPS 198] SHA-1 Keyed Hash bits or greater Key Length/ Key Strength: 112 A1345 HMAC [FIPS 198] SHA-1 Keyed Hash bits or greater Key Length/ Key Strength: 112 A1340 HMAC [FIPS 198] SHA2-224 Keyed Hash bits or greater Key Length/ Key Strength: 112 A1345 HMAC [FIPS 198] SHA2-224 Keyed Hash bits or greater Key Length/ Key Strength: 112 A1340 HMAC [FIPS 198] SHA2-256 Keyed Hash bits or greater Key Length/ Key Strength: 112 A1345 HMAC [FIPS 198] SHA2-256 Keyed Hash bits or greater SHA2-256 (for all SoCs but S3 that Key Length/ Key Strength: 112 A1341 HMAC [FIPS 198] Keyed Hash doesn't implement vng_neon) bits or greater Key Length/ Key Strength: 112 A1340 HMAC [FIPS 198] SHA2-384 Keyed Hash bits or greater Key Length/ Key Strength: 112 A1345 HMAC [FIPS 198] SHA2-384 Keyed Hash bits or greater Key Length/ Key Strength: 112 A1340 HMAC [FIPS 198] SHA2-512 Keyed Hash bits or greater Key Length/ Key Strength: 112 A1345 HMAC [FIPS 198] SHA2-512 Keyed Hash bits or greater Key Length/ Key Strength: 112 A1340 HMAC [FIPS 198] SHA2-512/256 Keyed Hash bits or greater Key Length/ Key Strength: 128, A1343 KTS [SP 800-38 F] AES-KW Key Wrapping 192, 256 Key Length/ Key Strength: 128, A1345 KTS [SP 800-38 F] AES-KW Key Wrapping 192, 256 A1340 SHS [FIPS 180-4] SHA-1 N/A Message Digest A1345 SHS [FIPS 180-4] SHA-1 N/A Message Digest A1340 SHS [FIPS 180-4] SHA2-224 N/A Message Digest A1345 SHS [FIPS 180-4] SHA2-224 N/A Message Digest A1340 SHS [FIPS 180-4] SHA2-256 N/A Message Digest A1345 SHS [FIPS 180-4] SHA2-256 N/A Message Digest This document may be reproduced and distributed only in its original entirely without revision.

Algorithm and Description / Key Size(s) / Key CAVP Cert. Mode / Method Use / Function Standard Strength(s) SHA2-256 (for all SoCs but S3 that A1341 SHS [FIPS 180-4] N/A Message Digest doesn't implement vng_neon) A1340 SHS [FIPS 180-4] SHA2-384 N/A Message Digest A1345 SHS [FIPS 180-4] SHA2-384 N/A Message Digest A1340 SHS [FIPS 180-4] SHA2-512 N/A Message Digest A1345 SHS [FIPS 180-4] SHA2-512 N/A Message Digest A1340 SHS [FIPS 180-4] SHA2-512/256 N/A Message Digest Table 3 - Approved Algorithms This module does not implement non-approved algorithms allowed in the approved mode of operation nor non-approved algorithms used in approved mode of operation with no security claimed.

The table below lists non-approved security functions that are not allowed in approved mode of operation: Algorithm/Functions Use / Function Ed25519 Key Generation EdDSA signature scheme Ed25519 shared secret generation EdDSA shared secret generation Curve 25519 key generation Key generation Curve 25519 shared secret generation shared secret generation ECDH Key Pair Generation Elliptic Curve Integrated Encryption Scheme (ECIES) key generation ECDH Shared Secret Computation Elliptic Curve Integrated Encryption Scheme (ECIES) Encryption ANSI X9.63 KDF AES-GCM ECDH Shared Secret Computation Elliptic Curve Integrated Encryption Scheme (ECIES) Decryption ANSI X9.63 KDF AES-GCM HKDF RFC5869 HMAC based Key Derivation Function PBKDF Key Derivation ECDSA implemented in FW Key generation as part of Ref key generation service and validation, Signature generation and verification as part of Device keybag service ECDSA implemented in HW PKA Key generation as part of Ref key generation service Signature generation primitive ECDH implemented in FW Shared secret computation ECDH implemented in HW PKA Shared secret computation AES KW using class D key, keys from Device keybag, keys Key wrapping and unwrapping from iCloud keybag, keys from Escrow keybag, keys from any keybag used with Class B Curve 25519 encrypt/decrypt, keys from Backup keybag used for wrapping Ed25519 keys, or NVM storage controller key Table 4 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation This document may be reproduced and distributed only in its original entirely without revision.

The cryptographic interfaces of the module are provided through the mailbox interface that is used between the module and the Device OS kernel. In detail these interfaces are described in (Table 5): Physical Port3 Logical Interface Data that passes over port/interface Mailbox Memory, IPC channel Data Input Data inputs are provided through the memory used for mailbox and IPC. Mailbox Memory, IPC channel Data Output Data outputs are provided through the memory used for mailbox and IPC. Mailbox Memory, IPC channel Control Input Control input which controls the module’s operation is provided through the mailbox by the Device OS’ kernel and to applications located within sepOS execution environment through IPC. Mailbox Memory, IPC channel Status Output Status output is provided in return codes and through messages returned via the mailbox or IPC. Documentation for each service invocation lists possible return codes. A complete list of all return codes returned by the C language APIs within the module is provided in the header files and the API documentation. Messages are also documented in the API documentation. single chip's Power port Power interface Power Table 5 - Ports and Interfaces The module’s logical interfaces used for input data and control information are logically disconnected from the logical paths used for the output of data and status information by virtue of the module's API. The module’s API distinguishes all output data from SSP information. 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. Cryptographic bypass capability is not supported by the module. The module does not implement or support the use of a trusted channel.

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

The module supports two authorized roles: the User and the Crypto Officer. No support is provided for multiple concurrent operators or a maintenance operator. The module authentication mechanism is defined by IG 4.4.A case 2 as follows. The User role is authenticated with the mechanism described in section 4.1. The User role can access the module via mailbox interface using the Device OS’s XNU kernel. The User role can perform subset of services from Table 8. The Crypto Officer performs services from Table 8 and Table 9 that do not affect the module’s security, per IG 4.1.A . The services are performed either via mailbox interface using the Device OS’s XNU kernel or via IPC channel using software applications running on sepOS. The Crypto Officer and User are assumed implicitly. Role Service Input Output User User keybag Services via Mailbox User credential, reference to class C/A status (success/error) key from the user keybag General Authentication service User credential, reference to class C/A status (success/error) key from the user keybag Generation of DEK reference to class C/A key from the wrapped DEK User keybag Backup keybag generation N/A status (success/error) Backup keybag service wrapped DEK, reference to class C or A wrapped DEK key from the user keybag Keychain DEK service using AK/ AKU/ AKPU/ pointer to AK/AKU/ AKPU/ CK/ CKU unwrapped DEK CK/ CKU class key class key, wrapped DEK Escrow keybag creation N/A status (success/error) Export keybag reference to a keybag to be exported keybag with HMAC tag Crypto Show Status N/A status (success/error) Officer Device Wipe N/A N/A (CO) Show Module Information N/A Module name and version Class D File System Services to wrap or unwrap Pointer to Class D key from Backup wrapped or unwrapped file DEK (Non-approved) keybag or Flash in SEP, wrapped or DEK unwrapped DEK Class D key service to encrypt or decrypt data Pointer to Class D key from Device or ciphertext or plaintext data (non-approved) iCloud Keybag, plaintext or ciphertext data Class DK/DKU File System Services to wrap or Pointer to Class DK/DKU key from wrapped or unwrapped file unwrap keychain (non-approved) Backup or User Keybag, wrapped or keychain unwrapped keychain Class DK/DKU key used for encrypting or Pointer to Class DK/DKU key from ciphertext or plaintext data decrypting of data (non-approved) Device or iCloud Keybag, plaintext or ciphertext data Generate Ref-Keys (Non-approved) N/A status success/error, ref-key Signature generation using Ref-key (non- pointer to ref-key, data signed data approved) Signature verification using Ref-key (non- pointer to ref-key, signed data verification result pass/error approved) Encryption using Ref-key (non-approved) Pointer to ref key, data ciphertext Decryption using Ref-key (non-approved) Ciphertext, Pointer to ref key plaintext Generate Shared Secret using Ref-key (non- pointer to ref-key, remote public key shared secret approved) Device Keybag Services for data encrypt or pointer to class key from device keybag, ciphertext or plaintext data decrypt (non-approved) plaintext or ciphertext data iCloud Keybag services for data encrypt or pointer to class key from device keybag, ciphertext during encryption; decrypt (non-approved) plaintext during encryption or ciphertext plaintext data during data during decryption decryption This document may be reproduced and distributed only in its original entirely without revision.

Escrow keybag service for key wrapping and pointer to any key from Escrow keybag, wrapped key during wrapping; unwrapping (non-approved) plaintext key wrapping or wrapped key plaintext key during during unwrapping operation unwrapping Encrypt or Decrypt service using Class B Curve Pointer to class B key from any keybag, ciphertext and ephemeral

25519 key from any keybag (non-approved) plaintext or ciphertext data public key during encryption;

plaintext data during decryption Wrap or unwrap service for DEK or keychain Pointer to D/C/A key from asymmetric wrapped DEK or keychain using D/C/A Curve 25519 key from asymmetric keybag, plaintext DEK or keychain during wrapping; plaintext keybag (non-approved) during wrapping operation or wrapped DEK or keychain during DEK or keychain during unwrapping unwrapping operation Wrap and unwrap service for keychain using Pointer to DK/ DKU/ CK/ CKU/AK/ AKU/ wrapped keychain during DK/DKU/CK/ CKU/AK/AKU/AKPU Ed25519 key AKPU key from asymmetric keybag, wrapping; plaintext keychain from asymmetric keybag (non-approved) plaintext keychain during wrapping during unwrapping operation or wrapped keychain during unwrapping operation Asymmetric (Ed25519) backup keybag wrap Pointer to Ed 25519 key from backup ciphertext or plaintext data and unwrap (non-approved) keybag, plaintext or ciphertext data NVM Storage Controller Key Service (non- pointer to NVM storage controller key, Wrapped DEK approved) DEK Elliptic Curve Integrated Encryption Scheme data, public key encrypted data (ECIES) Encryption (non-approved) Elliptic Curve Integrated Encryption Scheme data, private key decrypted data (ECIES) Decryption (non-approved) PBKDF Key Derivation (non-approved) password derived key Filesystem DEK services (non-approved) wrapped DEK, class key reference from Wrapped DEK or Error User keybag. Generation of DEK via IPC using class D key N/A DEK wrapped with class D key (non-approved) Requesting backup keybag service via IPC DEK wrapped with class D key DEK wrapped with back up using class D key (non-approved) keybag key Table 6

• Roles, Service Commands, Input and Output

Within the constraints of FIPS 140-3 level 2, the module implements a role-based authentication mechanism for authentication of the user role. The module implements authenticated encryption-based mechanism in the following way: to request an authenticated service from the module the user must provide the credential and a reference to the class C or A keys of the user keybag4 that is stored encrypted under SP800-38F AES Key Wrapping (AES-KW) within the module. The module performs obfuscation on the Operator provided credential and the resulting value -called REK (Root Encryption Key)- is used as the 256-bit AES key. Using this key, the module decrypts all the class C or A keys in the referenced user keybag with SP80038F AES Key Unwrapping function (i.e., AES-KW-AD5). As AES-KW is an authentication cipher, the decryption operation will only succeed if there is no authentication error. If the user keybag can be successfully decrypted, the user is authenticated to the module and the requested crypto service will then be proceeded with the decrypted user key. The failure of decrypting the user keybag is also a user authentication failure and the Operator will be denied access to the module. The User keybags are configured in the module during factory install. Each User keybag consists of set of class C, A and D keys. Specifically, class C keys include C key, CK key, CKU keys and the class A keys include A key, AK key, AKU key and AKPU key. Only the class A or C keys are considered as approved. Any use of class D keys is considered as non-approved. The module maintains authenticated session from the time the User keybags are unwrapped until the power off. Upon power off, the unwrapped User keybags are zeroized and at the next power on the User credential needs to be provided again to

4 A keybag is a data structure used to store a collection of class keys. Each type (User, device, escrow, backup, or iCloud) has the same

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

unwrap the User keybag. All authentication data is provided electronically from the calling application/service and hence is not in visible form.

The AES-KW 256-bit key unwrapping function provides 256 bits of strength. Therefore, the strength of the authentication mechanism in use is 1/ 2^256. Even using a rate of 1µs per failed authentication, which would allow 60,000,000 consecutive attempts per minute (60s / 0.000001s), only provides a probability of successfully authenticating that is less than or equal to 60,000,000 * 1 / 2^256. The SP 800-63B requirements are not applicable here based on the type of authentication mechanism deployed by the module because the authenticated decryption is not one of the methods listed in SP 800-63B. Role Authentication Method Authentication Strength User AES-KW unwrapping function 256 bits Crypto Officer (CO) No authentication N/A Table 7– Roles and Authentication

The module has an approved and non-approved mode of operation. The approved mode of operation is assumed automatically without any specific configuration. If the device starts up successfully then the module has passed all selftests and is operating in the approved mode. Any calls to the non-approved security functions listed in Table 9 will cause the module to assume the non-approved mode of operation. The module implements a dedicated API function to indicate if a requested service utilizes an approved security function. The approved service indicator utilizes one of two functions (fips_allowed and fips_allowed_mode) depending on the service in question. Calling fips_allowed_mode with AES-ECB, AES-CBC or AES-KW will return a zero to indicate it is an approved algorithm. Similarly, calling fips_allowed with any other approved algorithm will return zero. Calling either of these with an algorithm not listed in the Approved Algorithms Table will return a non-zero value, and as such indicates a non-approved service. The table below lists all approved services that can be used in the approved mode of operation by authorized operators of either the User or Crypto Officer Roles. The abbreviations of the access rights to keys and 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= Not Applicable: The service does not access any SSP during its operation

The table below includes the Approved Security Functions utilized by the service and Roles and access writes provided to the Keys and/or SSPs affected by the services. The last column provides a description of the service indicator reported by the service to show that the service utilizes an approved cryptographic algorithm, security function or process in an approved manner. This document may be reproduced and distributed only in its original entirely without revision.

Approved Access rights Indi # Service Description Security Keys and/or SSPs Role to Keys and/ cato Functions or SSPs r

1 User Keybag Step 1. The module receives User Key Unwrapping: User credential, REK, User W, E 0

Services via credential and the reference to the class AES-KW User keybag (Class A key, Mailbox C or A key from the User keybag Class AK key, Class AKU key, Step

2. Obfuscation operation is Class AKPU key, Class C key, performed on the User provided Class CK key, Class CKU key) credential resulting into a value called REK. Step
3. REK is used as a key for the AES KW operation to unwrap the referenced class A or C keys in the user keybag stored in the module. Step
4. Status of unwrapping operation of class keys is returned via mailbox interface and the REK is zeroized

2 General The module invokes the User keybag Key Unwrapping: User credential, REK, User W, E 0

Authentication Services via Mailbox (i.e., #1 above) AES-KW User keybag (Class A key, service Class AK key, Class AKU key, Class AKPU key, Class C key, Class CK key, Class CKU key)

3 Generation of Step 1: The module receives the Symmetric Key Entropy input string, DRBG User E 0

Data reference to the class C or A key from Generation (CKG internal state Encryption the user keybag using method in Key (DEK) Step 2: The module generates a new Section 4 [SP 800- User keybag (Class A key, W, E 133Rev2] AES- Class AK key, Class AKU key, DEK using the DRBG Class AKPU key, Class C key, ECB, AES-CBC) Step 3: Referenced class C or A key is Class CK key, Class CKU key) used to wrap the DEK using AES-KW DEK G,E Step 4: Wrapped DEK is sent out of the Key Wrapping: module AES-KW Wrapped DEK R

4 Keychain DEK Step 1. The module receives wrapped Key Wrapping: User keybag (Class A key, User E 0

service using DEK (that was sent as part of service 3 AES-KW Class AK key, Class AKU key, AK/ AKU/ above) and the pointer to class key AK/ Class AKPU key, Class C key, AKPU/ CK/ AKU/AKPU/CK/ CKU from the user Class CK key, Class CKU key) CKU class key keybag. Step 2. Using the referenced class key, DEK R, E the module unwraps the DEK using AES-KW. If the class key is not Wrapped DEK W, E available, an error is returned. Step 3. plaintext DEK is sent out to the User.

5 Backup The module generates new set of back Symmetric Key Entropy input string, DRBG User E 0

keybag up keybags using the DRBG Generation (CKG internal state generation using method in Backup Section 4 [SP 800- Backup keybag (Class A key, G, E keybag 133Rev2], AES- Class AK key, Class C key, service ECB, AES-CBC) Class CK key)

6 Step 1. The module receives wrapped Key Wrapping and DEK, User keybag (Class A User W, E 0

DEK and the class key reference for C Unwrapping: AES- key, Class AK key, Class AKU and A from the user keybag. KW key, Class AKPU key, Class C Step

2. Using the referenced class key, Symmetric Key key, Class CK key, Class CKU the module unwraps the DEK using Generation (CKG key) AES-KW. If the class key is not using method in Entropy input string, DRBG E available, an error is returned. Section 4 example internal state Step
3. The module generates a set of 1 [SP 800backup key bag using DRBG 133Rev2] AESECB, AES-CBC) This document may be reproduced and distributed only in its original entirely without revision.

Approved Access rights Indi # Service Description Security Keys and/or SSPs Role to Keys and/ cato Functions or SSPs r Step

4. Unwrapped DEK is re-wrapped Wrapped DEK R with backup key bag key using AES-KW Backup keybag (Class A key, G, E Step
5. Wrapped DEK is sent out. Class AK key, Class C key, Class CK key) HMAC key

7 Escrow The module generates new set of Symmetric Key Entropy input string, DRBG User E 0

keybag escrow key bag using the DRBG Generation (CKG internal state creation using method in Section 4 [SP 800133Rev2] AESEscrow keybag (Class A key, G,E ECB, AES-CBC) Class AK key, Class AKU key, Class AKPU key, Class C key)

8 Export Step 1. The module receives reference Message HMAC key User W, E 0

Keybag to a keybag. Authentication Step 2: A HMAC key is taken as input HMAC based on the hardware specific data for the SKS Keybag to be exported (User or R, E Step 3: HMAC value is calculated on the Backup or Escrow keybag) entire referenced keybag that includes encrypted6 keys. Step 4: HMAC is appended at the end of the keybag Step 5: Keybag with the appended HMAC is output to the User

9 Device Wipe7 Erase all content (Factory Reset) N/A All SSPs CO Z N/A

10 Show Status N/A N/A N/A CO N/A N/A

11 Show Module N/A N/A N/A CO N/A N/A

12 Perform Self- Perform all pre-operational self-tests All N/A CO N/A N/A

Test and cryptographic algorithm self-tests (CASTs) Table 8 - Approved Services

The table below lists all non-approved services that can only be used in the non-approved mode of operation and the services are non-authenticated. Service Description Algorithms Accessed Role Indicator Class D File System Services to Wrapping of provided plaintext DEK or unwrapping of provided AES-KW CO non-zero wrap or unwrap DEK wrapped DEK using class D key from Backup keybag or secure value storage in SEP Class D key service to encrypt or Encryption of provided plaintext or decryption of provided AES-KW CO non-zero decrypt data ciphertext using class D key from Device or iCloud Keybag value

6 Note: only class A and C keys in the keybag are encrypted with REK whereas class D keys are in plaintext as they are non-approved and not

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

Service Description Algorithms Accessed Role Indicator Class DK/DKU File System Wrapping of provided plaintext keychain or unwrapping of AES-KW CO non-zero Services to wrap or unwrap provided wrapped keychain using class DK/DKU key from value keychain Backup keybag or User keybag Class DK/DKU key service for Encryption of provided plaintext or decryption of provided AES-KW CO non-zero data encrypt or decrypt ciphertext using DK/DKU key from Device or iCloud keybag value Generate Ref-Keys Key Generation ECDSA KeyGen CO non-zero value Sign and verify using Ref-key Signature Generation and Verification ECDSA SigGen, CO non-zero ECDSA SigVer value Encryption and decryption using shared secret is generated using user provided key and existing ECDSA CO non-zero Ref-key ref key followed by HKDF is applied to derive a key which is HKDF value used to encrypt the provided plaintext or decrypt the provided ciphertext AES-GCM AES-KW Generate Shared Secret using Shared secret generation ECDH CO non-zero Ref-key value Device keybag service for data Encryption of provided plaintext or decryption of provided AES-KW CO non-zero encrypt or decrypt ciphertext using any key from Device keybag value iCloud keybag service for data Encryption of provided plaintext or decryption of provided AES-KW CO non-zero encrypt or decrypt ciphertext using any key from iCloud keybag value Escrow keybag service for key Wrapping of provided plaintext key or unwrapping of provided AES-KW CO non-zero wrapping and unwrapping wrapped key using any key from Escrow keybag value Encrypt or Decrypt service using shared secret is computed by generating new ephemeral AES-KW CO non-zero Class B Curve 22519 key from keypair and existing Curve25519 key followed by HKDF is HKDF value any key bag applied to derive a key which is used for data encryption or decryption. During encryption operations, the wrapped key and Curve 25519 the ephemeral public key are sent to the user Wrap or unwrap service for DEK shared secret is computed by generating new ephemeral AES-KW CO non-zero or keychain using any Curve keypair and existing Curve25519 key followed by HKDF is HKDF value

22519 key from asymmetric key applied to derive a key which is used to wrap and unwrap DEK

bag or keychain. During wrapping operation, the wrapped key and Curve 25519 the ephemeral public key are sent to the user Asymmetric (Ed25519) backup shared secret is computed by generating new ephemeral AES-KW CO non-zero keybag wrap and unwrap keypair and existing Curve25519 key followed by HKDF is HKDF value applied to derive a key which is used to wrap and unwrap. The wrapped key and the ephemeral public key are sent to the user Ed25519 Wrap or unwrap service for Pointer to DK/DKU/CK/CKU/AK/AKU/AKPU key from AES-KW CO non-zero keychain using DK/DKU/CK/ asymmetric keybag, plaintext keychain during wrapping HKDF value CKU/AK/AKU/AKPU Ed25519 operation or wrapped keychain during unwrapping operation key from asymmetric key bag Ed25519 NVM Storage Controller Key wrapping DEK using NVM storage controller key AES KW CO non-zero value Elliptic Curve Integrated Encryption ECDH CO non-zero Encryption Scheme (ECIES) AES-GCM value Encryption ANSI X9.63 Key Derivation Elliptic Curve Integrated Decryption ECDH CO non-zero Encryption Scheme (ECIES) AES-GCM value Decryption ANSI X9.63 Key Derivation PBKDF Key Derivation Hash-based Key Derivation PBKDF CO non-zero value File system DEK service Unwrap the DEK using referenced class key and re-wrap using AES KW CO non-zero NVM storage controller key value Generation of DEK using class D Requesting generate DEK service via IPC using class D keys AES KW CO non-zero key DRBG value This document may be reproduced and distributed only in its original entirely without revision.

Service Description Algorithms Accessed Role Indicator Requesting backup keybag Requesting backup keybag service via IPC using class D keys AES KW CO non-zero service using class D key DRBG value Table 9 - Non-Approved and non-authenticated Services This document may be reproduced and distributed only in its original entirely without revision.

The Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) is in the form of binary executable code. A firmware integrity test is performed on the runtime image of the module. The HMAC-SHA256 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 i.e., the module is not operational.

The Integrity tests are performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. This document may be reproduced and distributed only in its original entirely without revision.

The Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) operates in a limited operational environment per FIPS 140-3 security level 2 specifications. The module operates within the sepOS execution environment which is separate from the Device OS execution environment. The SEP operating system provides memory isolation between all applications executing on it. The Device OS is unable to access the module's memory or observe the module's operation. This document may be reproduced and distributed only in its original entirely without revision.

The defined physical boundary of the Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) is the entire System-on-Chip (SoC) listed in Table

2. Consequently, the physical embodiment of each SoC is that of a singlechip cryptographic module. The hardware module conforms to the Level 2 requirements for physical security as detailed in Table
3. Physical Security Mechanism Recommended Frequency Inspection/Test of Inspection/Text Guidance Details Production Grade Components that include standard passivation No operator-performed N/A testing is recommended - Tamper-evident coating or black hard coated material or metal No operator-performed N/A coating testing is recommended - The Ball Grid Array (BGA back side of the SoC soldered on the logic board.) The components listed above are opaque within the visible spectrum. Table 10 – Physical Security Inspection Guidelines This document may be reproduced and distributed only in its original entirely without revision.

Currently, the non-invasive security 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 entirely without revision.

The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module: Establi Use & Security Function shment related keys Key / SSP Name / Stora Strength and Cert. Generation Import / Export (see Zeroization (Service # Type ge Number section in section

Class A, 128, 192, AES-KW with CAVP N/A: Preloaded at Entry: N/A N/A Flash Device Wipe 1,2,3,4,6,8 Class C, 256-bits Certs. # A1343, factory Output: encrypted A1345 (for services using AES-KW for Class AK, Class 1,2,3,4,

6. AKU, Class CK, service #8 only Class CKU in User Keybag (AES keys) Class A, 128, 192, CTR_DRBG with Generated using Entry: N/A N/A RAM Context 5,6,8 Class C, 256-bits CAVP Certs. # direct output of CTR Output: encrypted object DRBG 2014, DRBG compliant to using AES-KW for destruction; Class AK, Class section 4 of SP800- Device Wipe AKU, Class CK, DRBG 2022, service #8 only 133r2. CKG (vendor Class CKU keys in DRBG 2023, affirmed) backup keybag (AES keys) DRBG 2024, DRBG 2025, Class A, 128, 192, DRBG 2028, Generated using Entry: N/A N/A RAM Context 7,8 Class C, 256-bits direct output of CTR Output: encrypted object DRBG 2029 DRBG compliant to destruction; Class AK, Class using AES-KW for C323, C324, C331, section 4 of SP800- service #8 only Device Wipe AKU, Class CK, A501 (for services 133r2. CKG (vendor Class CKU keys in 3, 5, 6, 7) affirmed) escrow keybag (AES keys) Data Encryption 128, 192, AES-KW with CAVP Symmetric key Entry: In N/A RAM Context 3,4,6 Key (DEK) 256-bits Certs. # A1343, generation services of encrypted form object (AES key) A1345 (for services the module using destruction; Output in 1,2,3,4,
7. DRBG compliant to Device Wipe encrypted form section 4 of SP800via service 3/6, or 133r2. CKG (vendor plaintext via affirmed) service 4 Entropy input string 256-bits Random Number Obtained from No import N/A RAM Device Wipe 3,5,6,7 Generation physical entropy No export ESV #E113 source DRBG internal 256-bits Random Number Updated during DRBG No import N/A RAM Device Wipe 3,5,6,7 state: V value, key, Generation initialization No export and seed material CTR_DRBG with CAVP Certs. # DRBG 2014, DRBG 2022, DRBG 2023, DRBG 2024, DRBG 2025, DRBG 2028, DRBG 2029, C323, C324, C331, A501 This document may be reproduced and distributed only in its original entirely without revision.

Establi Use & Security Function shment related keys Key / SSP Name / Stora Strength and Cert. Generation Import / Export (see Zeroization (Service # Type ge Number section in section

HMAC Key 112-bits or HMAC-SHA-256 N/A Entry: taken as N/A RAM Context 8 greater A1340, input based on the object hardware specific destruction; A1341, data Device Wipe A1345 Output: N/A User Credential N/A N/A N/A Entry: input by N/A RAM Device Wipe 1,2 User Output: N/A REK 256-bits N/A N/A: based on Entry: N/A N/A RAM Device Wipe 1,2 obfuscation Output: N/A performed on the User provided credential Table 11 - SSPs

A [SP800-90ARev1] approved deterministic random bit generator based on block cipher is used: CTR_DRBG using AES-256 without derivation function and with 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 consists of the V, Key, and a seed. In accordance with FIPS 140-3 IG D.L, the 'Entropy input string', 'seed', 'DRBG internal state (V and key values)' are considered CSPs by the module. 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 an internal physical noise source. The physical entropy source provides 256-bits of security strength in instantiating and reseeding the module approved DRBGs. Entropy Source Minimum number of bits of entropy Details ESV #E113 (physical 256 The entropy source is a hardware entropy source consisting entropy source) of twenty-four Free Ring Oscillator (FROs). The entropy source has been shown to provide full 256-bits of entropy at the output of the vetted conditioning function, SHA2-256 (#C1223). Table 12 - Non-Deterministic Random Number Generation Specification

The module provides a key generation service for symmetric cipher i.e. AES in accordance with FIPS 140-3 IG D.H. The cryptographic module performs Cryptographic Key Generation (CKG) for symmetric keys as per section 4 [SP800-133r2]. The implementation follows example 1 from Section 4 whereby V is a string of binary zeroes, such that B = U (i.e., the output of an approved RBG). The symmetric keys are generated directly output from an approved DRBG compliant with [SP80090ARev1].

The module provides the following key/SSP establishment service in the Approved mode:

• AES-Key Wrapping: The module implements a Key Transport Scheme (KTS) using AES-KW compliant to [SP80038F] per IG D.G. The SSP establishment methodology provides between 128 and 256 bits of encryption strength. This document may be reproduced and distributed only in its original entirely without revision.

Per the definition in IG 2.3.B, "Transferring SSPs including the entropy input between a sub-chip cryptographic subsystem and an intervening functional subsystem for Security Levels 1 and 2 on the same single chip is considered as not having Sensitive Security Parameter Establishment crossing the HMI". As such, the import or export Keys/SSP as defined in Table 1 of IG 9.5.A do not apply. Within the TOEPP, keys and SSPs can either be entered, or output from the Apple Secure Key Store Cryptographic Module to/from intervening functional subsystems in plaintext .

During runtime operation, the Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) module stores keys/SSPs in volatile memory, except for the user keybag that is stored in Flash. The module protects all keys/SSPs through the memory separation and protection mechanisms provided by the operating system while the Flash component only provides exclusive access to the module. No process other than the module itself can access the keys/SSPs in its process memory or Flash component.

Keys and SSPs (including temporary SSPs) are zeroised when the appropriate context object is destroyed by overwriting the entire context object with all zeros. Zeroization occurs at the end of an API function that uses the CSPs. Zeroization is also performed by calling the "Device Wipe" service. The "Device Wipe" service performs end of life of the device. Input and output interfaces are inhibited while zeroisation is performed. Zeroisation is immediate and uninterruptible, preventing the retrieval and reuse of the zeroised values. The module provides an implicit indication that the zeroisation has successfully completed by returning access to the User, ready to service the next request. This document may be reproduced and distributed only in its original entirely without revision.

The module performs pre-operational self-tests automatically when the module is loaded into memory; the pre-operational self-tests triggered at power-on ensure that the module is not corrupted and that the cryptographic algorithms work as expected. The module transitions to approved Mode upon successful completion of the pre-operational self-tests and CASTs. FIPS 140-3 only requires that software/firmware integrity test(s) and the requisite cryptographic algorithm(s) be tested during power-up, but the Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) runs all Cryptographic Algorithm Self-Tests (CASTs) during power-up as well. The following tests (Table 13) are performed each time the Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) starts. If any of the following tests fail the device fails to startup. While the module is executing the self-tests, services are not available, and input and output are inhibited. Cryptographic Algorithm Notes HMAC-SHA256 CAST performed prior to module’s firmware integrity test Pre-operational firmware integrity test Firmware integrity test using HMAC-SHA-256 AES-ECB Separate encryption / decryption CAST performed using 128-bit key AES-CBC Separate encryption / decryption CAST performed using 128-bit key AES-KW Separate encryption / decryption CAST performed using 128-bit key CTR_DRBG CAST and Health test per SP800-90ARev1 section 11.3 with 256-bit key HMAC-SHA-1, HMAC-SHA-512 CAST performed SHA-1, SHA-256, SHA-512 Covered by HMAC CAST ESV APT and RCT Table 13 - Self-Tests

A pre-operational integrity test is performed on the firmware component of the Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2). The module’s HMAC-SHA2-256 is used as an approved algorithm for the integrity test. If the test fails, then the module enters an Error State. The HMAC value is pre-computed at build time and stored in the module. The HMAC value is recalculated during runtime and compared with the stored value.

The following sub-sections describe the conditional self-tests supported by the Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2).

The Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) runs all Cryptographic Algorithm SelfTests during power-up. These tests are detailed in Table 13.

The Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) does not provide asymmetric key generation service in the approved mode. Therefore, this section is not applicable. This document may be reproduced and distributed only in its original entirely without revision.

On demand and periodic self-tests are performed by powering off the module and powering it on again. This service performs the same cryptographic algorithm tests executed during pre-operational self-tests and CASTs. During the execution of the periodic and on-demand self-tests, crypto services are not available and no data output or input is possible.

If any of the self-tests described in the above 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 restarting and reperforming the pre-operational firmware integrity test and the Conditional Cryptographic Algorithm Self-Tests (CASTs). The module will only enter the operational state after successfully passing the pre-operational firmware integrity test and the all CASTs. The table below shows the different causes that lead to the Error State and the status indicators reported. Cause of Error Error Indicator Failed Pre-operational Software Integrity Test Error message “FAILED: fipspost_post_integrity” sent to caller Failed CAST Error message “FAILED:<event>” sent to caller (<event> refers to any of the cryptographic functions listed in Table 13) Table 14

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

The module’s firmware with the sepOS is delivered as part of the Device OS image. 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 the 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-SHA-256 based integrity check performed by the module itself as part of its pre-operational self-tests. The biometric authentication option provided by the underlying test platform shall be disabled in order to run the module in the FIPS validated manner.

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 9 - Non-Approved and non-authenticated Services. If the device starts up successfully, then the module has passed all self-tests and is operating in the Approved mode. A Crypto Officer Role Guide is 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. A link to the Guide can be found on the Product security, validations, and guidance page found in [Device OS]. The ESV Public Use Document (PUD) reference for physical entropy source is published at https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropy-validations/certificate/113

The User role is authenticated with the mechanism described in section 4.1. The User role can access the module via mailbox interface using the Device OS’s XNU kernel. The User role can perform subset of services from Table 8. As stated in the Crypto Officer Guidance, 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 9 - NonApproved and non-authenticated Services. This transition cannot be made by the User directly, as all non-approved services require an implicit transition into the Crypto-Officer role. Any calling of such services is therefore implicitly performed by the Crypto Officer. If the device starts up successfully, then the module has passed all self-tests and is operating in the Approved mode. When performing a Device Wipe service to erase all content of the module, the procedure must be performed under the control of the Operator. 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.

Appendix A. Glossary and Abbreviations AES Advanced Encryption Standard API Application Programming Interfaces APT Adaptive Proportion Test (SP800-90B health test) BGA Ball Grid Array (Physical Security) CAVP Cryptographic Algorithm Validation Program CBC Cipher Block Chaining CCM Counter with Cipher Block Chaining-Message Authentication Code CMVP Cryptographic Module Validation Program CST Cryptographic and Security Testing CTR Counter Mode DEK Data Encryption Key DRBG Deterministic Random Bit Generator ECB Electronic Code Book ECDSA DSA (Digital Signature Algorithm) based on Elliptic Curve Cryptography (ECC) EMI Electromagnetic Interference (Physical Security) ESV Entropy Source Validation FIPS Federal Information Processing Standards Publication GCM Galois Counter Mode HMAC Hash Message Authentication Code IHS Integrated Heat Spreader (Physical Security) IPC Inter-Process Communication KAT Known Answer Test KDF Key Derivation Function KEK Key Encryption Key KW AES Key Wrap MAC Message Authentication Code NIST National Institute of Science and Technology NVM Non-Volatile Memory OFB Output Feedback OS Operating System PBKDF Password Based Key Derivation Function RCT Repetition Count Test (SP800-90B health test) SEP Secure Enclave Processor SHA Secure Hash Algorithm SHS Secure Hash Standard SKS Secure Key Store SoC System on Chip SSP Sensitive Security Parameters This document may be reproduced and distributed only in its original entirely without revision.

Appendix B. References FIPS140-3 FIPS PUB 140-3 - Security Requirements for Cryptographic Modules March 2019 https://doi.org/10.6028/NIST.FIPS.140-3 SP 800-140x CMVP FIPS 140-3 Related Reference https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-standards FIPS140-3_IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program September 2020 https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-ig-announcements FIPS140-3_MM CMVP FIPS 140-3 Draft Management Manual https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%201403/Draft%20FIPS-140-3-CMVP%20Management%20Manual%2009-18-2020.pdf SP 800-140 FIPS 140-3 Derived Test Requirements (DTR) https://csrc.nist.gov/publications/detail/sp/800-140/final SP 800-140A CMVP Documentation Requirements https://csrc.nist.gov/publications/detail/sp/800-140a/final SP 800-140B CMVP Security Policy Requirements https://csrc.nist.gov/publications/detail/sp/800-140b/final SP 800-140C CMVP Approved Security Functions https://csrc.nist.gov/publications/detail/sp/800-140c/final SP 800-140D CMVP Approved Sensitive Security Parameter Generation and Establishment Methods https://csrc.nist.gov/publications/detail/sp/800-140d/final SP 800-140E CMVP Approved Authentication Mechanisms https://csrc.nist.gov/publications/detail/sp/800-140e/final SP 800-140F CMVP Approved Non-Invasive Attack Mitigation Test Metrics https://csrc.nist.gov/publications/detail/sp/800-140f/final FIPS180-4 Secure Hash Standard (SHS) March 2012 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf FIPS186-4 Digital Signature Standard (DSS) July 2013 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf FIPS197 Advanced Encryption Standard November 2001 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf FIPS198-1 The Keyed Hash Message Authentication Code (HMAC) July 2008 http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf This document may be reproduced and distributed only in its original entirely without revision.

RFC3394 Advanced Encryption Standard (AES) Key Wrap Algorithm September 2002 http://www.ietf.org/rfc/rfc3394.txt RFC5649 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm September 2009 http://www.ietf.org/rfc/rfc5649.txt SP800-38A NIST Special Publication 800-38A - Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf SP800-38D NIST Special Publication 800-38D - Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC November 2007 http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf SP800-38F NIST Special Publication 800-38F - Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping December 2012 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf SP800-57 NIST Special Publication 800-57 Part 1 Revision 5 - Recommendation for Key Management Part 1: General May 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf SP800-90ARev1 NIST Special Publication 800-90A - Revision 1 - Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf SP800-90B NIST Special Publication 800-90B - Recommendation for the Entropy Sources Used for Random Bit Generation January 2018 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf SP800-131Ar2 Transitioning the Use of Cryptographic Algorithms and Key Lengths March 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf SP800-133r2 Recommendation for Cryptographic Key Generation June 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf Developer Device OS Technical Overview https://developer.apple.com 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 Device OS Product security certifications for Device OS https://support.apple.com/en-gw/guide/certifications/welcome/web This document may be reproduced and distributed only in its original entirely without revision.