Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3]

Certificate

Approved Algorithms (38)

Security Levels (Table 1)

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/PHY3]
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>11.1</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>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"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I3["Some services may process<br/>input 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"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    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"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E3["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
  C1 --> I1 --> R1 --> E1
  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 C1,C3,C5,C6 clue;
  class I1,I3,I5,I6 infer;
  class R1,R3,R5,R6 risk;
  class E1,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3]
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>11.1</i><br/>src: certificate.firmwareVersions"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Show Status</i><br/>src: securityPolicy.services"]
    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 C1,C3 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Apple Inc. Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] 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

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] Trademarks Apple’s trademarks applicable to this document are listed in https://www.apple.com/legal/intellectual-property/trademark/appletmlist.html. Other company, product, and service names may be trademarks or service marks of others. This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] Table of Contents 2.1 2.1.1 2.2 2.3 2.3.1 2.3.2 4.1 4.2 4.3 4.3.1 4.3.2 5.1 5.2 9.1 9.2 9.3 9.4 9.5 9.6 10.1 10.2 10.2.1 10.2.2 10.2.3 10.3 11.1 11.2 11.3 Appendix A. Appendix B. This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] List of Tables This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] This document is the non-proprietary FIPS 140-3 Security Policy for Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] 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 an overall 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. Table 1 - Security Levels This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3]

The Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] 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, and macOS 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. In addition, the module provides InterProcess Communication (IPC) interfaces to other applications executing within the sepOS execution environment. 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 compliant SP800-90B physical entropy source.  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 module physical boundary is defined by the SoC perimeter. Figure 1 - Picture of the SoC tested (Apple A13 Bionic, Apple A14 Bionic and Apple M1) 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 boundary. This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] Figure 2 - Block diagram

The hardware module has been tested by atsec CST lab on the following platforms: 2.0 N/A 2.0 N/A 2.0 N/A 2.0 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. This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3]

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

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A 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 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: This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] 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.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3]

are described in (Table 5): Table 5 - Ports and Interfaces data from SSP information. The module communicates any error status synchronously through the use of its documented return codes, thus indicating Caller-induced or internal errors do not reveal any sensitive material to callers. Cryptographic bypass capability is not 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.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] 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 Table 9 that do not affect the module’s security, per IG 4.1.A. The services are performed via mailbox interface using the Device OS’s XNU kernel or via IPC channel using the software applications running on sepOS. N/A N/A N/A N/A N/A N/A N/A This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] N/A 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 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-AD3). 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 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 format. Section 6.2 SP800-38F, Algorithm 4: KW-AD(C) This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] 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 zeroised and at the next power on the User credential needs to be provided again in order to 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. 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 to 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.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] # ‍ ‍ ‍ ‍ ‍ W, E W, E E W, E G, E R E R, E W, E This document may be reproduced and distributed only in its original entirely without revision. E G, E W, E E

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] # R G, E G,E N/A Z N/A N/A N/A N/A N/A N/A Perform SelfTest N/A N/A N/A N/A N/A N/A N/A N/A E W, E R, E 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. 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 considered as CSP This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] Table 9 - Non-Approved and non-authenticated Services This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3]

The Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] 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.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3]

The Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] 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.

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

2. Consequently, the physical embodiment of each SoC is a single-chip cryptographic module. The hardware module conforms to the Level 3 requirements for physical security as detailed in Table
3. N/A N/A N/A N/A Table 10 – Physical Security Inspection Guidelines The module correctly implements the Environmental Failure Protection (EFP) features as detailed in Table
4. Table 11 – EFP/EFT Table 12 – Hardness testing temperature ranges This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3]

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.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3]

The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic 1,2,3,4, 6) 9.3 4.3.1) N/A N/A 5,6,8 N/A 7,8 N/A 3,4, 6 6) N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Table 13 - SSPs This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3]

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. The module also performs DRBG health tests according to section 11.3 of [SP800-90ARev1]. 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. 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 hardware based entropy source provides 256-bits of security strength in instantiating and reseeding the module approved DRBGs. Table 14 - 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.

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 into, 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/PHY3] 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. This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3]

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.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3]

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/PHY3] runs all The following tests (Table 15) are performed each time the Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] 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. Table 15 - 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/PHY3]. The module’s HMAC-SHA2-256 is used as an approved algorithm for the integrity pre-operational 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/PHY3]. 10.2.1 Cryptographic algorithm self-tests The Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] runs all Cryptographic Algorithm Self-Tests during power-up. These tests are detailed in Table 15. 10.2.2 Pairwise Consistency Test The Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] 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.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] 10.2.3 On-Demand Self-Test 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 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 restarting and re-performing the preoperational firmware integrity test and the Conditional Self-Test CASTs. The module will only enter into the operational state after successfully passing the pre-operational firmware integrity test and the CASTs. The table below shows the different causes that lead to the Error State and the status indicators reported. Table 16

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

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3]

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 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 Approved mode of operation is configured in the system by default and can only be transitioned into the non-Approved mode by calling one of the non-Approved services listed in Table - Non-Approved 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 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 - 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.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3]

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

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] 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 IPC Inter-Process Communication IHS Integrated Heat Spreader (Physical Security) 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.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] Appendix B. FIPS140-3 References 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 FIPS140-3_IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-standards 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 SP 800-140 FIPS 140-3 Derived Test Requirements (DTR) SP 800-140A CMVP Documentation Requirements https://csrc.nist.gov/publications/detail/sp/800-140a/final SP 800-140B CMVP Security Policy Requirements SP 800-140C CMVP Approved Security Functions SP 800-140D CMVP Approved Sensitive Security Parameter Generation and Establishment Methods SP 800-140E CMVP Approved Authentication Mechanisms 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 https://csrc.nist.gov/publications/detail/sp/800-140/final https://csrc.nist.gov/publications/detail/sp/800-140b/final https://csrc.nist.gov/publications/detail/sp/800-140c/final https://csrc.nist.gov/publications/detail/sp/800-140d/final 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 RFC3394 Advanced Encryption Standard (AES) Key Wrap Algorithm September 2002 http://www.ietf.org/rfc/rfc3394.txt This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] 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-38C NIST Special Publication 800-38C - Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality May 2004 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.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-56Cr2 Recommendation for Key-Derivation Methods in Key-Establishment Schemes August 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.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-67 NIST Special Publication 800-67 Revision 1 - Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher January 2012 http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.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-108 NIST Special Publication 800-108 - Recommendation for Key Derivation Using Pseudorandom Functions (Revised) October 2009 http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.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 This document may be reproduced and distributed only in its original entirely without revision.

Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware, SL2/PHY3] SP800-132 NIST Special Publication 800-132 - Recommendation for Password-Based Key Derivation - Part 1: Storage Applications December 2010 http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.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.

Referenced URLs

• www.atsec.com
• https://www.apple.com/legal/intellectual-property/trademark/appletmlist.html
• https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropy-validations/certificate/113
• https://doi.org/10.6028/NIST.FIPS.140-3
• https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-standards
• https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-ig-announcements
• https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-
• https://csrc.nist.gov/publications/detail/sp/800-140/final
• https://csrc.nist.gov/publications/detail/sp/800-140a/final
• https://csrc.nist.gov/publications/detail/sp/800-140b/final
• https://csrc.nist.gov/publications/detail/sp/800-140c/final
• https://csrc.nist.gov/publications/detail/sp/800-140d/final
• https://csrc.nist.gov/publications/detail/sp/800-140e/final
• https://csrc.nist.gov/publications/detail/sp/800-140f/final
• http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
• http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
• http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
• http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf
• http://www.ietf.org/rfc/rfc3394.txt
• http://www.ietf.org/rfc/rfc5649.txt
• http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
• http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf
• http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
• http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf
• http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdf
• http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf
• http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf
• http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf
• https://developer.apple.com
• https://support.apple.com/guide/security/welcome/web
• https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/apple-platform-security-guide.pdf
• https://support.apple.com/en-gw/guide/certifications/welcome/web