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

Certificate

Approved Algorithms (78)

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

flowchart LR
  %% Deterministic review-risk graph for Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2)
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Status Output<br/>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>kernel<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C3,C5,C6 clue;
  class I3,I5,I6 infer;
  class R3,R5,R6 risk;
  class E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2)
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Status Output<br/>Show Status</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>kernel<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C3,C5,C6 clueLow;

Security Policy, page by page

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

4516 Seton Center Pkwy, Suite 250

Austin, TX 78759 www.atsec.com This document may be reproduced and distributed only in its original entirely without revision.

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

2 of 34

This document is the non-proprietary FIPS 140-3 Security Policy for Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) cryptographic module. It contains the security rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for a Security Level 2 module. This document provides all tables and diagrams (when applicable) required by NIST SP 800-140B. The column names of the tables follow the template tables provided in NIST SP 800-140B. Table 1 describes the individual security areas of FIPS 140-3, as well as the Security Levels of those individual areas. The overall Security Rating of the module is SL2. Table 1 - Security Levels This document may be reproduced and distributed only in its original entirely without revision.

5 of 34

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

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

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

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

1 A11 SoC shown soldered down on device PCB. SoC is outlined by red box.

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

6 of 34

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

• The location of the logical object of the firmware components of the hardware module with respect to the operating system, other supporting applications, and the cryptographic boundary so that all the logical and physical layers between the logical object and the cryptographic boundary are clearly defined.
• The interactions of the logical object of the module with the operating system and other supporting applications resident within the cryptographic Figure 13-Block Diagram

The hardware module has been tested by atsec CST lab on the following platforms: This document may be reproduced and distributed only in its original entirely without revision.

7 of 34

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

8 of 34

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

9 of 34

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

10 of 34

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

11 of 34

Table 3 - Approved Algorithms This module does not implement non-approved algorithms allowed in the approved mode of operation nor non-approved algorithms used in approved mode of operation with no security claimed.

The table below lists non-approved security functions that are not allowed in approved mode of operation: 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.

12 of 34

the Device OS kernel. In detail these interfaces 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.

13 of 34

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 either via mailbox interface using the Device OS’s XNU kernel or via IPC channel using software applications running on sepOS. This document may be reproduced and distributed only in its original entirely without revision.

14 of 34

Table 6 – Roles, Service Commands, Input and Output

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

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

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

15 of 34

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. Table 7– Roles and Authentication

The module has an approved and non-approved mode of operation. The approved mode of operation is assumed automatically without any specific configuration. If the device starts up successfully then the module has passed all selftests and is operating in the approved mode. Any calls to the non-approved security functions listed in Table 9 will cause the module to assume the non-approved mode of operation. The module implements a dedicated API function to indicate if a requested service utilizes an approved security function. The approved service indicator utilizes one of two functions (fips_allowed and fips_allowed_mode) depending on the service in question. Calling fips_allowed_mode with AES-ECB, AES-CBC or AES-KW will return a zero to indicate it is an approved algorithm. Similarly, calling fips_allowed with any other approved algorithm will return zero. Calling either of these with an algorithm not listed in the Approved Algorithms Table will return a non-zero value, and as such indicates a non-approved service. The table below lists all approved services that can be used in the approved mode of operation by authorized operators of either the User or Crypto Officer Roles. The abbreviations of the access rights to keys and SSPs have the following interpretation: G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g., the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. N/A= Not Applicable: The service does not access any SSP during its operation

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

16 of 34

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

17 of 34

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.

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

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

18 of 34

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

19 of 34

Table 9 - Non-Approved and non-authenticated Services This document may be reproduced and distributed only in its original entirely without revision.

20 of 34

The Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) is in the form of binary executable code. A firmware integrity test is performed on the runtime image of the module. The HMAC-SHA256 implemented in the module is used as an approved algorithm for the integrity test. If the test fails, the module enters an error state where no cryptographic services are provided, and data output is prohibited i.e., the module is not operational.

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

21 of 34

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

22 of 34

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

2. Consequently, the physical embodiment of each SoC is that of a singlechip cryptographic module. The hardware module conforms to the Level 2 requirements for physical security as detailed in Table
3. Table 10 – Physical Security Inspection Guidelines This document may be reproduced and distributed only in its original entirely without revision.

23 of 34

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.

24 of 34

The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic

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

25 of 34

Table 11 - SSPs A [SP800-90ARev1] approved deterministic random bit generator based on block cipher is used: CTR_DRBG using AES-256 without derivation function and with prediction resistance. The random numbers used for key generation are all generated by CTR_DRBG in this module. Per section 10.2.1.1 of [SP 800-90ARev1], the internal state of CTR_DRBG consists of the V, Key, and a seed. In accordance with FIPS 140-3 IG D.L, the 'Entropy input string', 'seed', 'DRBG internal state (V and key values)' are considered CSPs by the module. The module also performs DRBG health tests according to section 11.3 of [SP800-90ARev1]. No non-DRBG functions or instances are able to access the DRBG internal state. The deterministic random bit generators are seeded by an internal physical noise source. The physical entropy source provides 256-bits of security strength in instantiating and reseeding the module approved DRBGs. Table 12 - Non-Deterministic Random Number Generation Specification The module provides a key generation service for symmetric cipher i.e. AES in accordance with FIPS 140-3 IG D.H. The cryptographic module performs Cryptographic Key Generation (CKG) for symmetric keys as per section 4 [SP800-133r2]. The implementation follows example 1 from Section 4 whereby V is a string of binary zeroes, such that B = U (i.e., the output of an approved RBG). The symmetric keys are generated directly output from an approved DRBG compliant with [SP80090ARev1].

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

26 of 34

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

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

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

27 of 34

The module performs pre-operational self-tests automatically when the module is loaded into memory; the pre-operational self-tests triggered at power-on ensure that the module is not corrupted and that the cryptographic algorithms work as expected. The module transitions to approved Mode upon successful completion of the pre-operational self-tests and CASTs. FIPS 140-3 only requires that software/firmware integrity test(s) and the requisite cryptographic algorithm(s) be tested during power-up, but the Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) runs all Cryptographic Algorithm Self-Tests (CASTs) during power-up as well. The following tests (Table 13) are performed each time the Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2) starts. If any of the following tests fail the device fails to startup. While the module is executing the self-tests, services are not available, and input and output are inhibited. Table 13 - Self-Tests A pre-operational integrity test is performed on the firmware component of the Apple corecrypto Module v11.1 [Apple silicon, Secure Key Store, Hardware] (SL2). The module’s HMAC-SHA2-256 is used as an approved algorithm for the integrity test. If the test fails, then the module enters an Error State. The HMAC value is pre-computed at build time and stored in the module. The HMAC value is recalculated during runtime and compared with the stored value.

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

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

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

28 of 34

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

If any of the self-tests described in the above fail, the module reports the cause of the error and enters an error state. In the Error State, no cryptographic services are provided, and data output is prohibited. The only method to recover from the error state is to power cycle the device which results in the module restarting and reperforming the pre-operational firmware integrity test and the Conditional Cryptographic Algorithm Self-Tests (CASTs). The module will only enter the operational state after successfully passing the pre-operational firmware integrity test and the all CASTs. The table below shows the different causes that lead to the Error State and the status indicators reported. Table 14 – Error States This document may be reproduced and distributed only in its original entirely without revision.

29 of 34

The module’s firmware with the sepOS is delivered as part of the Device OS image. The vendor’s internal development process guarantees that the correct version of module goes with its intended Device OS version. For additional assurance, the module is digitally signed by the vendor, and it is verified during the integration into Device OS. This digital signature-based integrity protection during the delivery/ integration process is not to be confused with the HMAC-SHA-256 based integrity check performed by the module itself as part of its pre-operational self-tests. The biometric authentication option provided by the underlying test platform shall be disabled in order to run the module in the FIPS validated manner.

The Approved mode of operation is configured in the system by default and can only be transitioned into the non-Approved mode by calling one of the non-Approved services listed in Table 9 - Non-Approved and non-authenticated Services. If the device starts up successfully, then the module has passed all self-tests and is operating in the Approved mode. A Crypto Officer Role Guide is provided by Apple which offers IT System Administrators with the necessary technical information to ensure FIPS 140-3 Compliance of the deployed systems. This guide walks the reader through the system’s assertion of cryptographic module integrity and the steps necessary if module integrity requires remediation. A link to the Guide can be found on the Product security, validations, and guidance page found in [Device OS]. The ESV Public Use Document (PUD) reference for physical entropy source is published at https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropy-validations/certificate/113

The User role is authenticated with the mechanism described in section 4.1. The User role can access the module via mailbox interface using the Device OS’s XNU kernel. The User role can perform subset of services from Table 8. As stated in the Crypto Officer Guidance, the Approved mode of operation is configured in the system by default and can only be transitioned into the non-Approved mode by calling one of the non-Approved services listed in Table 9 - NonApproved and non-authenticated Services. This transition cannot be made by the User directly, as all non-approved services require an implicit transition into the Crypto-Officer role. Any calling of such services is therefore implicitly performed by the Crypto Officer. If the device starts up successfully, then the module has passed all self-tests and is operating in the Approved mode. When performing a Device Wipe service to erase all content of the module, the procedure must be performed under the control of the Operator. This document may be reproduced and distributed only in its original entirely without revision.

30 of 34

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

31 of 34

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

32 of 34