Apple corecrypto Module v12.0 [Apple silicon, Secure Key Store, Hardware, SL2]

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Apple corecrypto Module v12.0 [Apple silicon, Secure Key Store, Hardware, SL2]
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Unauthenticated<br/>UnAuth</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"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Apple corecrypto Module v12.0 [Apple silicon, 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)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Unauthenticated<br/>UnAuth</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 C2,C3,C5,C6 clueLow;

Security Policy, page by page

Apple Inc. Apple corecrypto Module v12.0 [Apple silicon, Secure Key Store, Hardware, SL2] Prepared for: Apple Inc. One Apple Park Way Cupertino, CA 95014 Prepared by: atsec information security corporation

4516 Seton Center Parkway, Suite 250

Austin, TX 78759 www.atsec.com

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

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

List of Tables Table 3: Tested Module Identification – Software/Firmware/Hybrid (Executable Code Sets) .. Error! Bookmark not defined. defined. Bookmark not defined. defined. This document may be reproduced and distributed only in its original entirely without revision.

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

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

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

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

Purpose and Use: The Apple corecrypto Module v12.0 [Apple silicon, Secure Key Store, Hardware, SL2] cryptographic module (hereafter referred to as “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’ (iPadOS 15, iOS 15, tvOS 15, watchOS 8) execution environment. The firmware interface is defined as the API offered by the module's 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 Inter-Process Communication (IPC) interfaces to other applications executing within the sepOS execution environment. The sepOS execution environment is driven by its own CPU 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. Module Type: Hardware Module Embodiment: SingleChip Module Characteristics: SubChip Cryptographic Boundary: The module cryptographic boundary is delineated by the dotted blue rectangle in the Figure 1. The cryptographic module boundary includes the following hardware components:

The physical perimeter is represented by the most exterior black line in the block diagram Figure 1. This document may be reproduced and distributed only in its original entirely without revision.

Figure 1: Block Diagram Tested Operational Environment’s Physical Perimeter (TOEPP): A photograph of each hardware module is shown below: Figure 3: Apple Figure 4: Apple Figure 6: Apple Figure 2: Apple A9 Figure 5: Apple A9X A10 Fusion A11 Bionic A10X Fusion This document may be reproduced and distributed only in its original entirely without revision.

Figure 12: Apple Figure 13: Apple Figure 14: Apple S5 S6 S7

Tested Module Identification – Hardware: This document may be reproduced and distributed only in its original entirely without revision.

None for this module Modes List and Description: This document may be reproduced and distributed only in its original entirely without revision.

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

Table 4: Approved Algorithms - AES-CBC This document may be reproduced and distributed only in its original entirely without revision.

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

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

Table 8: Approved Algorithms - HMAC Message-Digest This document may be reproduced and distributed only in its original entirely without revision.

Table 9: Approved Algorithms - Message-Digest Vendor-Affirmed Algorithms: Table 10: Vendor-Affirmed Algorithms Non-Approved, Not Allowed Algorithms: This document may be reproduced and distributed only in its original entirely without revision.

Table 11: Non-Approved, Not Allowed Algorithms

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

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

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

Table 12: Security Function Implementations

The SHA-1 algorithm as implemented by the module will be non-approved for all purposes except signature verification, starting January 1, 2030.

Table 13: Entropy Certificates Table 14: Entropy Sources Entropy sources : The internal physical noise source consisting of ring oscillators. RBGs: The NIST [SP 800-90ARev1] approved deterministic random bit generators (DRBG) used for random number generation is a CTR_DRBG using AES-256 without derivation function and with prediction resistance. The module performs DRBG health tests according to [SP800-90ARev1 section 11.3]. The deterministic random bit generators are seeded by the physical noise source. RBG Output: The output of hardware entropy source provides 256-bits of security strength in instantiating and reseeding the module approved DRBGs. This document may be reproduced and distributed only in its original entirely without revision.

See vendor affirmed algorithms (CKG) in section 2.5.

The Module implements AES key wrapping and unwrapping as part of KTS in accordance with IG D.G method 2 and SP800-38F.

None for this module This document may be reproduced and distributed only in its original entirely without revision.

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

Table 16: Authentication Methods Within the constraints of FIPS 140-3 overall security level 2 (with physical security at security level 3), 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 keybag that is stored encrypted under SP800-38F AES Key Wrapping (AES-KW) within the module. The module performs obfuscation on the Operator provided credential. 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 SP800-38F AES Key Unwrapping function (i.e., AES-KW-AD). 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 APKU 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 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 module does not support concurrent operators. This document may be reproduced and distributed only in its original entirely without revision.

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

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

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

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

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

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

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

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

Table 18: Approved Services The abbreviations of the access rights to SSPs have the following interpretation: G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g., the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. N/A = The service does not access any SSP during its operation

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

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

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

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

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

Table 19: Non-Approved Services

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

The Apple corecrypto Module v12.0 [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 the approved algorithm for the integrity test. If the test fails, the module enters an error state where no cryptographic services are provided, and data output is prohibited i.e. the module is not operational. As the module is delivered built with the Device OS, there is no standalone delivery of the module. The vendor’s internal development process guarantees that the correct version of module goes with its intended Device OS version

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

Type of Operational Environment: Non-Modifiable

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 v12 [Apple silicon, Secure Key Store, Hardware, SL2] is the entire System-on-Chip (SoC) listed in the Tested Module Identification table. Consequently, the physical embodiment of each SoC is considered to be that of a single-chip cryptographic module. The hardware module conforms to the Level 2 requirements for physical security. The physical components that comprise the module are of production grade components with industry direct observation, probing, or manipulation of the single-chip as detailed in the Physical Security Mechanisms and Actions Required table.

Table 20: Mechanisms and Actions Required This document may be reproduced and distributed only in its original entirely without revision.

Per IG 12.A, until the requirements of NIST SP 800-140F are defined, non-invasive mechanisms fall under ISO/IEC 19790:2012 Section 7.12 Mitigation of other attacks. The requirements of this area are not applicable to the module. This document may be reproduced and distributed only in its original entirely without revision.

Table 22: SSP Input-Output Methods This document may be reproduced and distributed only in its original entirely without revision.

Table 23: SSP Zeroization Methods Data output interfaces are inhibited while zeroisation is performed. h This document may be reproduced and distributed only in its original entirely without revision.

h G s Table 24: SSP Table 1 This document may be reproduced and distributed only in its original entirely without revision.

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

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

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

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

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

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

Table 27: Conditional Self-Tests

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

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

The module permits operators to initiate the pre-operational or conditional self-tests on demand for periodic testing of the module by reloading the module. This document may be reproduced and distributed only in its original entirely without revision.

Startup Procedures: As the module is delivered built with the Device OS, there is no standalone delivery of the module. Installation Process and Authentication Mechanisms: The vendor’s internal development process guarantees that the correct version of module goes with its intended Device OS version. For additional assurance, the module is digitally signed by vendor, and it is verified during the integration into Host Device OS. This digital signature-based integrity protection used during the delivery/integration process is not to be confused with the HMAC-256 based integrity check performed by the module itself as part of its pre-operational self- tests.

The 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 - Non-Approved Services. If the device starts up successfully, then the module has passed all self-tests and is operating in the Approved mode. The ESV Public Use Document (PUD) reference for physical entropy source is: https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropyvalidations/certificate/113 Apple Platform Certifications guide [platform certifications] and Apple Platform Security guide [SEC] are provided by Apple which offers IT System Administrators with the necessary technical information to ensure FIPS 140-3 Compliance of the deployed systems. This guide walks the reader through the system’s assertion of cryptographic module integrity and the steps necessary if module integrity requires remediation.

The User role is authenticated with the mechanism described in section 4. 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 - Approved Algorithms. As stated in the Administrator Guidance section above, 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. 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. This document may be reproduced and distributed only in its original entirely without revision.

The Device Wipe service erases the module content. 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                   NIST entropy source validation program providing SP 800-90B compliant entropy validation certificate 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 This document may be reproduced and distributed only in its original entirely without revision.