Apple corecrypto Module v12 [Intel, User, Software]

Certificate

Approved Algorithms (152)

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

flowchart LR
  %% Deterministic review-risk graph for Apple corecrypto Module v12 [Intel, User, Software]
  %% 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>Status output<br/>Self-test<br/>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>IPSEC<br/>HTTPS</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>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 v12 [Intel, User, Software]
  %% 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>Status output<br/>Self-test<br/>Show Status</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>IPSEC<br/>HTTPS</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>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 v12 [Intel, User, Software] Document version: 1.0 January 15, 2025 Prepared by: www.acumensecurity.net This document may be reproduced and distributed only in its original entirely without revision

1. General 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 is the non-proprietary FIPS 140-3 Security Policy for the Apple, Inc. corecrypto Module v12 [Intel, User, Software] 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 1 module. This document provides all tables and diagrams (when applicable) required by NIST SP 800-140B. The column names of the tables follow the template tables provided in NIST SP 800-140B. Table 1 describes the individual security areas of FIPS 140-3, as well as the Security Levels of those individual areas. This document may be reproduced and distributed only in its original entirely without revision

9 1

Table 1 – Security Levels The module claims an overall Security Level 1. This document may be reproduced and distributed only in its original entirely without revision

2. Cryptographic Module Specification The Apple corecrypto Module v12 [Intel, User, Software] cryptographic module (hereafter referred to as “the module”) is a software module running on a multi-chip standalone general-purpose computing platform. The version of module is 12, written as v12. The module provides implementations of low-level cryptographic primitives to the Host OS’s (macOS Monterey
3. Security Framework and Common Crypto. The module has been tested by Acumen Security, LLC. CST lab on the following platforms with and without AES-NI: Table 2 – Tested Operational Environments This document may be reproduced and distributed only in its original entirely without revision

In addition to the platforms listed in Table 2, Apple Inc. has also tested the module on the following platforms and claims vendor affirmation on them (the processor and year per platform have also been specified): Table 3 – Vendor Affirmed Operational Environments The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation This document may be reproduced and distributed only in its original entirely without revision

certificate. The physical perimeter of the module which is also the Tested Operational Environment’s Physical Perimeter (TOEPP), is the physical perimeter of the macOS device that contains the module. Consequently, the embodiment of the module is a multi-chip standalone cryptographic module. (Figure 1) below depicts the following information:

• The location of the module with respect to the operating system (blue dotted outline), other supporting applications so that all the logical and physical layers between the cryptographic boundary and the physical perimeter are clearly defined; and
• The interactions of the logical object of the module with the operating system and other supporting applications resident within the physical perimeter boundary. Figure 1
• Cryptographic boundary and physical perimeter The table below lists all Approved or Vendor-affirmed security functions of the module, including specific key size(s) employed for approved services, and implemented modes of operation. The module This document may be reproduced and distributed only in its original entirely without revision

is in the Approved mode of operation when the module utilizes the services that use the security functions listed in the table below. The module supports an Approved mode and a non-Approved mode of operation. The module does not support a degraded operation. The Approved mode of operation is configured in the system by default and can only be transitioned into the non-Approved mode by calling one of the non-Approved services listed in Table 10 - NonApproved Services. If the device starts up successfully, then the module has passed all self-tests and is operating in the Approved mode. This document may be reproduced and distributed only in its original 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

KAS-1

KAS-FFC-SSC

Sp800-

56Ar3/A2820

SP 800-56Arev3.

KAS-FFC-SSC per IG

D.F Scenario 2 path

KAS

KAS-2

KAS-ECC-SSC

Sp800-

56Ar3/A2820

SP 800-56Arev3.

KAS-ECC-SSC per IG

D.F Scenario 2 path

KAS

SP 800-38D and SP

800-38F; key

wrapping per IG D.G

KTS

(1) Table 4 – Approved Algorithms This module does not have non-Approved but Allowed Algorithms used in the Approved mode of operation. This document may be reproduced and distributed only in its original entirely without revision

The table below list non-Approved but Allowed security functions with no security claimed: Table 5 – Non-Approved Algorithms Not Allowed in the Approved Mode of Operation with No Security 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

Table 6

• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation Overall Security Rules of Operation
• AES-GCM IV is constructed in compliance with IG C.H scenario 1a (TLS 1.2) and scenario 1b (IPsec-v3). The TLS and IPSec/IKE protocols have not been reviewed or tested by the CAVP and CMVP. The GCM IV generation follows RFC 5288 and shall only be used for the TLS protocol version 1.2. The counter portion of the IV is set by the module within its cryptographic boundary. The module does not implement the TLS protocol. The module’s implementation of AES-GCM is used together with an application that runs outside the module’s cryptographic boundary. The design of the TLS protocol implicitly ensures that the nonce_explicit, or counter portion of the IV will not exhaust all of its possible values. The GCM IV generation follows RFC 4106 and shall only be used for the IPsec-v3 protocol version 3. The counter portion of the IV is set by the module within its cryptographic boundary. The module does not implement the IPsec protocol. The module’s implementation of AES-GCM is used together with an application that runs outside the module’s cryptographic boundary. The design of the IPsec protocol implicitly ensures that the nonce_explicit, or counter portion of the IV will not exhaust all of its possible values. In both protocols in case the module’s power is lost and then restored, the key used for the AES GCM encryption/decryption shall be re-distributed. This condition is not enforced by the module; however, it is met implicitly. The module does not retain any state when power is lost. As indicated in Table 10, column Storage, the module exclusively uses volatile storage. This means that AESGCM key/IVs are not persistently stored during power off: therefore, there is no re-connection possible when the power is back on with re-generation of the key used for GCM. After restoration of the power, the user of the module (e.g., TLS, IKE) along with User application that implements the protocol, must perform a complete new key establishment operation using new random numbers (Entropy input string, DRBG seed, DRBG internal state V and Key, shared secret values that are not retained during power cycle, see table 10) with subsequent KDF operations to establish a new GCM key/IV pair on either side of the network communication channel.
• AES-XTS mode is only approved for hardware storage applications. The length of the AES-XTS data unit does not exceed 220 blocks. The module checks explicitly that Key_1 ≠ Key_2 before using the keys in the XTS-Algorithm to process data with them compliant with IG C.I. This document may be reproduced and distributed only in its original entirely without revision

3. Cryptographic Module Interfaces As a software-only module, the module does not have physical ports. For the purpose of the FIPS 140-

3 validation, the physical ports are interpreted to be the physical ports of the hardware platform on

which it runs. The logical interfaces are the application program interface (API) through which applications request services and the Operating System calls that the module invokes. these interfaces are described in (Table 7): Table 7 – Ports and Interfaces The module is optimized for library use within the macOS User space and does not contain any terminating assertions or exceptions. It is implemented as a macOS dynamically loadable library. The dynamically loadable library is loaded into the macOS User and its cryptographic functions are made available to the macOS application. Any internal error detected by the module is reflected back to the caller with an appropriate return code. The calling macOS application must examine the return code and act accordingly. The module communicates any error status synchronously through the use of its documented return codes, thus indicating the module’s status. It is the responsibility of the caller to handle exceptional conditions in a FIPS 140-3 appropriate manner. Caller-induced or internal errors do not reveal any sensitive material to callers. Cryptographic bypass This document may be reproduced and distributed only in its original entirely without revision

capability is not supported by the module. This document may be reproduced and distributed only in its original entirely without revision

4. Roles, Services, and Authentication The module supports a single instance of one authorized role: The Crypto Officer. No support is provided for multiple concurrent operators or a Maintenance Operator. This document may be reproduced and distributed only in its original entirely without revision

Table 8 – Roles, Service Commands, Input and Output This document may be reproduced and distributed only in its original entirely without revision

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

10 - Non-Approved Services below).

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

1. For services listed in Table 10 - Non-Approved Services, the indicator function returns
2. The table below lists all approved services that can be used in the approved mode of operation. The abbreviations of the access rights to keys and SSPs have the following interpretation: 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

#A2818) This document may be reproduced and distributed only in its original entirely without revision

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

CKG CKG CKG 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

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

Services

Description

Approved Security Functions AES-ECB (#A2820, #A2815, #A2814, #A2812, #A2813, #A2821, #A2822) HMAC_DRBG (#A2820, #A2817, #A2816, #A2818) CTR_DRBG, #A2820, #A2821, #A2815, #A2814, #A2822 HMAC (#A2820, #A2818 #A2823, #A2817, #A2816) RSA Signature Generation (#A2820, #A2817, #A2816, #A2818) RSA Signature Verification (#A2820, #A2817, #A2816, #A2818) ECDSA Signature Generation (#A2820, #A2817, #A2816, #A2818)

Keys and/or SSPs

Roles

Access rights to Keys and/or SSPs

Indicator

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

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

Table 10 – Non-Approved Services This document may be reproduced and distributed only in its original entirely without revision

5. Software/Firmware Security Integrity Techniques The Apple corecrypto Module v12 [Intel, User, Software] is in the form of binary executable code. A software integrity test is performed on the runtime image of the module. The HMAC-SHA2-256 implemented in the module is used as an approved algorithm for the integrity test. If the test fails, the module enters an error state where no cryptographic services are provided and data output is prohibited i.e. the module is not operational. The Software Integrity Key (HMAC-SHA2-256 with 256 bits of security strength), a non-SSP, is stored in the module binary computed during build. On-Demand Integrity Test The integrity test is also performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. It can also be invoked by powering-off and reloading the module to meet the on-demand request for integrity test. In addition, the module provides the Self-Test service to perform self-tests, including integrity test and algorithm tests, on demand. Software Loading The module does not support loading of any additional software. This document may be reproduced and distributed only in its original entirely without revision

6. Operational Environment Applicability The Apple corecrypto Module v12 [Intel, User, Software] operates in a modifiable operational environment per FIPS 140-3 level 1 specifications. The module is supplied as part of macOS Monterey 12, a commercially available general-purpose operating system executing on the hardware specified in section
7. Policy The operating system is restricted to a single operator (single-user mode; i.e. concurrent operators are explicitly excluded). When the operating system loads the module into memory, it invokes the Self-Test functionality, which in turn runs the mandatory self-tests. This document may be reproduced and distributed only in its original entirely without revision

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

8. Non-invasive Security 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

9. Sensitive Security Parameter Management The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module: Symmetric Encryption Decryption AES-CBC (#A2820, #A2815, #A2814, A9819, #A2812, #A2813) AES-ECB (#A2820, #A2815,                                                              Automati Size:                                                                 N/A: #A2814,                                                                  c 128,                                                                 The #A2812,                                                             zeroisatio 192,                                  Import                       module #A2813,                                                               n when     Symmet
256                                     and                         does
#A2821,                                                              structure     ric Export                         not AES Key                #A2822)                                                                  is      Encrypti N/A           to            N/A         provide (CSP)                AES-CCM                                                              deallocat   on and Strengt                                 calling                      persist (#A2820,                                                               ed or     Decrypti h:                                  applicati                       ent #A2815,                                                             when the       on 128,                                     on                        keys/S #A2814,                                                             system is 192,                                                                 SPs #A2821,                                                              powered

256 storage

#A2822) down AES-GCM (#A2820, #A2815, #A2814, #A2821, #A2822) AESCFB128(#A2 820, #A2815, #A2814) AESCFB8(#A282 This document may be reproduced and distributed only in its original entirely without revision

ECDSA         The key ECDSA                    Keygen        pairs are                                                      Digital Key Pair     Curves                    generate                      N/A                              Signatu This document may be reproduced and distributed only in its original entirely without revision

s: h: (CSP) #A2821, #A2815, #A2814, #A2822 HMAC_DRB Derived G (SHA-1, from SHA-224, entropy SHA-512) defined This document may be reproduced and distributed only in its original entirely without revision

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

n Key                    Derivation Derivatio               KDF Mode:           N/A                       N/A (CSP)                   Feedback MAC Mode:       Internally HMAC-SHA-       generate 1, HMAC-          d via SHA2-224,        SP800KBKDF         Min:        HMAC-           108 HMAC-             n SHA2-512 This document may be reproduced and distributed only in its original entirely without revision

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

: Table 11 – SSPs The Software Integrity Key (HMAC-SHA2-256 with 256 bits of security strength), a non-SSP, is stored in the module binary computed during build. A NIST approved deterministic random bit generator based on a block cipher as specified in NIST [SP 800-90Ar1] is used. The default Approved DRBG used for random number generation is a CTR_DRBG This document may be reproduced and distributed only in its original entirely without revision

using AES-256 with derivation function and without prediction resistance. The random numbers used for key generation are all generated by CTR_DRBG in this module. Per section 10.2.1.1 of [SP 800-90Ar1], the internal state of CTR_DRBG is the value V, Key and a reseed counter. The module also employs a HMAC_DRBG for random number generation. The HMAC_DRBG is only used at the early boot time of macOS User for memory randomization. The output of HMAC_DRBG is not used for key generation. Per section 10.1.2.1 of [SP 800-90Ar1], the internal state of HMAC_DRBG is the value V, Key and a reseed counter. The deterministic random bit generators are seeded by read_random. The read_random is the User Space interface that extracts random bits from the entropy pool. The output of entropy pool provides 256-bits of entropy to seed and reseed SP800-90B DRBG during initialization (seed) and reseeding (reseed). Table 12 – Non-Deterministic Random Number Generation Specification Key / SSP Generation The module generates Keys and SSPs in accordance with FIPS 140-3 IG D.H. The cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys as per sections 4, 5.1, 5.2, 6.2.2 and

6.2.3 [SP800-133r2] (vendor affirmed), compliant with [FIPS186-4], and using DRBG compliant with

[SP800-90Ar1]. A seed (i.e., the random value) used in asymmetric key pair generation is a direct output from [SP800-90Ar1] CTR_DRBG. The key generation service for RSA, Diffie-Hellman, and EC key pairs as well as the [SP 800-90Ar1] DRBG have been ACVT tested with algorithm certificates found in Table 4. Keys/SSPs Establishment The module provides the following key/SSP establishment services in the Approved mode:

• AES-Key Wrapping
• The module implements a Key Transport Scheme (KTS) using AES-KW compliant to [SP80038F]. The SSP establishment methodology provides between 128 and 256 bits of encryption strength.
• Diffie-Hellman Shared Secret Computation
• The module implements a shared secret compliant to [SP800-56Ar3]. The shared secret computation provides between 112 and 200 bits of encryption strength. This document may be reproduced and distributed only in its original entirely without revision

• EC Diffie-Hellman Shared Secret Computation
• The module implements a shared secret Z compliant to [SP800-56Ar3]. The shared secret computation provides between 112 and 256 bits of encryption strength.
• PBKDF Key Derivation
• The module implements a CAVP compliance tested key derivation function compliant to [SP800-132]. The service returns the key derived from the provided password to the caller. The password consists of at least eight alphanumeric characters from the ninety-six (96) printable and human- readable characters2. PBKDFv2 is implemented to support all options specified in section 5.4 of [SP800-132]. The keys derived from [SP800-132] map to section

4.1 of [SP800-133r2] as indirect generation from DRBG. The derived keys may only be used in

storage applications. • KBKDF Key Derivation o The KBKDF is compliant to [SP800-108]. The module implements both Counter and Feedback modes with HMAC-SHA-1, HMAC-SHA2-224, HMAC-SHA2-256, HMAC-SHA2-384, or HMACSHA2-512 as the PRF. Keys/SSPs Import/Export All keys and SSPs that are entered from, or output to module, are entered from or output to the invoking application running on the same device. Keys/SSPs entered into the module are electronically entered in plain text form. Keys/SSPs are output from the module in plain text form if required by the calling application. The module allows the output of plaintext CSPs (i.e., EC/DH/RSA Key Pairs). To prevent inadvertent output of sensitive information, the module performs the following two independent internal actions:

1. The module will internally request the random number generation service to obtain the random numbers and verify that the service completed without errors.
2. Once the keys are generated the module will perform the pairwise consistency test and verify that the test is completed without errors. Only after successful completion of both actions, are the generated CSPs output via the KPI output parameter in plaintext. Keys/SSPs Storage The Apple corecrypto Module v12 [Intel, User, Software] stores ephemeral keys/SSPs in memory only. They are received for use or generated by the module only at the command of the calling application. The module does not provide persistent keys/SSPs storage. This document may be reproduced and distributed only in its original entirely without revision

The module protects all keys/SSPs through the memory separation and protection mechanisms provided by the operating system. No process other than the module itself can access the keys/SSPs in its process’ memory. Keys/SSPs Zeroization Keys and SSPs are zeroised when the appropriate context object is destroyed or when the system is powered down. Input and output interfaces are inhibited while zeroisation is performed. This document may be reproduced and distributed only in its original entirely without revision

10. Self-tests 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. 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 v12 [Intel, User, Software] runs all Cryptographic Algorithm Tests (CASTs) during power-up as well. The following tests are performed each time the Apple corecrypto Module v12 [Intel, User, Software] starts. If any of the following tests fails the device (tested platform) fails to startup. To invoke the self-tests (pre-operational and CASTs) on demand (and periodically), the user may reboot the system. While the module is executing the self-tests, services are not available and input and output are inhibited. The self-tests are implemented for the following algorithms:

• Pre-operational Self-Tests:
• HMAC-SHA2-256: Used for module integrity test
• Conditional Self-Tests:
• Conditional Cryptographic Algorithm Self-tests (CAST):  AES CBC 128 bits Encrypt KAT  AES CCM 128 bits Encrypt KAT  AES GCM 128 bits Encrypt KAT  AES XTS 128 bits Encrypt KAT  AES ECB 128 bits Encrypt KAT  AES CMAC 128 bits Encrypt KAT  AES CBC 128 bits Decrypt KAT  AES CCM 128 bits Decrypt KAT  AES GCM 128 bits Decrypt KAT  AES XTS 128 bits Decrypt KAT  AES ECB 128 bits Decrypt KAT  AES CMAC 128 bits Decrypt KAT  CTR_DRBG KAT
• Generate, Instantiate and Reseed  HMAC_DRBG KAT
• Generate, Instantiate and Reseed  HMAC-SHA-1 KAT; covers SHA-1 KAT  HMAC-SHA2-256 KAT; covers SHA2-256 KAT  HMAC-SHA2-512 KAT; covers SHA2-512 KAT Public Material
• May be reproduced only in its original entirety (without revision).

 RSA 2048 bits SHA2-256 Signature Generation KAT  RSA 2048 bits SHA2-256 Verify KAT  ECDSA P-224 SHA2-224 Sig Gen KAT  ECDSA P-224 SHA2-224 Sig Ver KAT  KAS-FFC-SSC KAT  KAS-ECC-SSC KAT  PBKDF KAT  KBKDF counter KAT  NIST SP 800-90B Repetitive Count Test (RCT)  NIST SP 800-90B Adaptive Proportion Test (APT)

• Pairwise consistency test when generating ECDSA key pairs (for signature generation/verification/key agreement (KAS-ECC-SSC))
• Pairwise consistency test when generating RSA key pairs (for signature generation/verification)
• Pairwise consistency test when generating DH key pairs (for key agreement) Integrity Test A software integrity test is performed on the runtime image of the Apple corecrypto Module v12 [Intel, User, Software]. The module’s HMAC-SHA2-256 is used as an approved algorithm for the integrity test. If the test fails, then the device powers itself off. 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. Conditional Tests The following sub-sections describe the conditional tests supported by the Apple corecrypto Module v12 [Intel, User, Software]. Cryptographic algorithm tests The Apple corecrypto Module v12 [Intel, User, Software] runs all Cryptographic Algorithm Tests during power-up. These tests are detailed above in this section. Pairwise Consistency Test The Apple corecrypto Module v12 [Intel, User, Software] does generate asymmetric keys and performs all required pair-wise consistency tests on the newly generated key pairs. Error Handling If any of the above-mentioned self-tests fail, the module reports the cause of the error and enters an error state where no cryptographic services are provided and data output is Public Material
• May be reproduced only in its original entirety (without revision).

prohibited. The only method to clear the error state is to power cycle the device. The module will only enter into the operational state after successfully passing the preoperational software integrity test and the Conditional CASTs. The module returns the “FAILED: fipspost_post_integrity” error indicator in case of a software integrity test failure, “FAILED: <algorithm>” in case of a CAST failure. Public Material – May be reproduced only in its original entirety (without revision).

11. Life-cycle Assurance Delivery and Operation The module is built into macOS Monterey 12 and delivered with macOS. There is no standalone delivery of the module as a software library. The vendor’s internal development process guarantees that the correct version of module goes with its intended macOS version. For additional assurance, the module is digitally signed by vendor and it is verified during the integration into macOS. This digital signature-based integrity protection during the delivery/integration process is not to be confused with the HMAC-SHA2-256 based integrity check performed by the module itself as its pre-operational self-test. No additional maintenance requirements apply. 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 10 - Non-Approved Services. If the device starts up successfully, then the module has passed all self-tests and is operating in the Approved mode. 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 macOS Monterey 12 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. Public Material – May be reproduced only in its original entirety (without revision).

12. Mitigation of Other Attacks The module does not claim mitigation of other attacks. Public Material – May be reproduced only in its original entirety (without revision).