Apple corecrypto Module v13.0 [Apple silicon, User, Software, SL1]

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Apple corecrypto Module v13.0 [Apple silicon, User, Software, SL1]
  %% 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>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"]
    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 v13.0 [Apple silicon, User, Software, SL1]
  %% 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>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 C2,C3,C5,C6 clueLow;

Security Policy, page by page

Apple Inc. Apple corecrypto Module v13.0 [Apple silicon, User, Software, SL1] 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.

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 v13.0 [Apple silicon, User, Software, SL1] 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

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 v13.0 [Apple silicon, User, Software, SL1] cryptographic module (hereafter referred to as “the module”) provides implementations of lowlevel cryptographic primitives to the Device OS’s (iOS 16, iPadOS 16, watchOS 9, tvOS 16, T2OS

13 and macOS 13 Ventura) Security Framework and Common Crypto. The module provides

services intended to protect data in transit and at rest. The module is optimized for library use within the Device OS user space and does not contain any terminating assertions or exceptions. It is implemented as a Device OS dynamically loadable library. After the library is loaded, its cryptographic functions are made available to the Device OS application. Any internal error detected by the module is returned to the caller with an appropriate return code. The calling Device OS 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. Caller-induced or internal errors do not reveal any sensitive material to callers. Module Type: Software Module Embodiment: MultiChipStand Module Characteristics: N/A Cryptographic Boundary: The module cryptographic boundary is delineated by the dotted green rectangle in the Figure

1. The module executes within the user space of the computing platforms and operating systems listed in the Tested Operational Environments Table section 2.2. Tested Operational Environment’s Physical Perimeter (TOEPP): The physical perimeter is represented by the most exterior black line in the block diagram Figure
2. This document may be reproduced and distributed only in its original entirely without revision.

Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Operational Environments - Software, Firmware, Hybrid: 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 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: This document may be reproduced and distributed only in its original entirely without revision.

Table 4: Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid 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 certificate.

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

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

Table 8: Approved Algorithms - AES-CFB128 Table 9: Approved Algorithms - AES-CFB8 Table 10: Approved Algorithms - AES-CMAC Table 11: Approved Algorithms - AES-CTR This document may be reproduced and distributed only in its original entirely without revision.

Table 12: Approved Algorithms - AES-ECB Table 13: Approved Algorithms - AES-GCM Table 14: Approved Algorithms - AES-KW This document may be reproduced and distributed only in its original entirely without revision.

Table 15: Approved Algorithms - AES-OFB Table 16: Approved Algorithms - AES-XTS CTR_DRBG Table 17: Approved Algorithms - CTR_DRBG This document may be reproduced and distributed only in its original entirely without revision.

Table 18: Approved Algorithms - ECDSA-KEYGEN Table 19: Approved Algorithms - ECDSA-KEYVER Table 20: Approved Algorithms - ECDSA-SIGGEN Table 21: Approved Algorithms - ECDSA-SIGVER HMAC-SHA1 This document may be reproduced and distributed only in its original entirely without revision.

Table 22: Approved Algorithms - HMAC-SHA1 HMAC-SHA224 Table 23: Approved Algorithms - HMAC-SHA224 HMAC-SHA256 Table 24: Approved Algorithms - HMAC-SHA256 HMAC-SHA384 Table 25: Approved Algorithms - HMAC-SHA384 This document may be reproduced and distributed only in its original entirely without revision.

HMAC-SHA512 Table 26: Approved Algorithms - HMAC-SHA512 Table 27: Approved Algorithms - HMAC-SHA512/256 Table 28: Approved Algorithms - KAS-ECC-SSC Table 29: Approved Algorithms - KAS-FFC-SSC KBKDF This document may be reproduced and distributed only in its original entirely without revision.

Table 30: Approved Algorithms - KBKDF Table 31: Approved Algorithms - PBKDF Table 32: Approved Algorithms - RSA-KEYGEN Table 33: Approved Algorithms - RSA-SIGGEN This document may be reproduced and distributed only in its original entirely without revision.

Table 34: Approved Algorithms - RSA-SIGVER SAFEPRIME-KEYGEN Table 35: Approved Algorithms - SAFEPRIME-KEYGEN SHA1 Table 36: Approved Algorithms - SHA1 SHA224 Table 37: Approved Algorithms - SHA224 SHA256 This document may be reproduced and distributed only in its original entirely without revision.

Table 38: Approved Algorithms - SHA256 SHA384 Table 39: Approved Algorithms - SHA384 SHA512 Table 40: Approved Algorithms - SHA512 SHA512/256 Table 41: Approved Algorithms - SHA512/256 Vendor-Affirmed Algorithms: This document may be reproduced and distributed only in its original entirely without revision.

Table 42: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: There are no non-Approved but “Allowed functions” with security claimed algorithms in 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.

Table 44: 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.

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 45: Security Function Implementations

GCM IV AES-GCM IV is constructed in compliance with IG C.H scenario 1 (TLS 1.2) and scenario 2 (IPsecv3). Users should consult IG C.H specific scenario for all the details and requirements of using AES-GCM mode. 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 11, column Storage, the module exclusively uses volatile storage. This means that AES-GCM 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 This document may be reproduced and distributed only in its original entirely without revision.

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 11) with subsequent KDF operations to establish a new GCM key/IV pair on either side of the network communication channel. AES-XTS 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. Key Derivation using SP 800-132 PBKDF2 The module implements a CAVP compliance tested key derivation function compliant to [SP800132]. The service returns the key derived from the provided password to the caller. The length of the password used as input to PBKDFv2 shall be at least 8 characters and the worst-case probability of guessing the value is 10^8 assuming all characters are digits only. The user shall choose the password length and the iteration count in such a way that the combination will make the key derivation computationally intensive. PBKDFv2 is implemented to support the option 1a specified in section 5.4 of [SP800-132]. The keys derived from [SP800-132] map to section 4.1 of [SP800-133rev2] as indirect generation from DRBG. The derived keys may only be used in storage applications.

Table 46: Entropy Sources Entropy sources: Two entropy sources (one non-physical entropy source and one physical entropy source) residing within the TOEPP provide the random bits. The entropy sources are located within the physical perimeter of the module (TOEPP) but outside the cryptographic boundary of the module. This document may be reproduced and distributed only in its original entirely without revision.

RBGs: The NIST [SP 800-90ARev1] approved deterministic random bit generators (DRBG) used for random number generation is a CTR_DRBG using AES-256 with derivation function and without prediction resistance. The module performs DRBG health tests according to [SP800-90ARev1 section 11.3]. The deterministic random bit generators are seeded by /dev/random. The /dev/random is the User Space interface. RBG Output: The output of entropy sources provides 256-bits of entropy to seed and reseed SP800-90ARev1 DRBG during initialization (seed) and reseeding (reseed).

The module generates RSA, Diffie-Hellman, and ECDSA and EC Diffie-Hellman 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 and 5.1 [SP800-133r2] (vendor affirmed), compliant with [FIPS186-4], and using DRBG compliant with [SP800-90ARev1]. A seed (i.e., the random value) used in asymmetric key generation is a direct output from [SP800-90ARev1] CTR_DRBG. The key generation service for RSA, Diffie-Hellman, ECDSA and EC Diffie-Hellman key pairs as well as the [SP 800-90ARev1] DRBG have been ACVT tested with algorithm certificates found in the Approved Algorithms Table.

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

• PBKDF Key Derivation The module implements a CAVP compliance tested key derivation function compliant to [SP800132]. The service returns the key derived from the provided password to the caller. The length of the password used as input to PBKDFv2 shall be at least 8 characters and the worst-case probability of guessing the value is 10^8 assuming all characters are digits only. The user shall choose the password length and the iteration count in such a way that the combination will make the key derivation computationally intensive. PBKDFv2 is implemented to support the option 1a specified in section 5.4 of [SP800-132]. The keys derived from [SP800-132] map to section 4.1 of [SP800-133Rev2] as indirect generation from DRBG. The derived keys may only be used in storage applications.
• KBKDF Key Derivation The KBKDF is compliant to [SP800-108Rev1]. The module implements both Counter and Feedback modes with HMAC-SHA-1, HMAC-SHA2-224, HMAC-SHA2-256, HMAC-SHA2-384, or HMAC-SHA2-512 as the PRF. Key Agreement Information: See - Security Function Implementations Table, line KAS and details below:
• Diffie-Hellman Shared Secret Computation This document may be reproduced and distributed only in its original entirely without revision.

The module provides SP800-56ARev3 compliant key establishment according to FIPS 140-3 IG D.F scenario 2 path (1) with Diffie-Hellman shared secret computation. The shared secret computation provides between 112 and 200 bits of encryption strength.

• EC Diffie-Hellman Shared Secret Computation The module provides SP800-56ARev3 compliant key establishment according to FIPS 140-3 IG D.F scenario 2 path (1) with EC Diffie-Hellman shared secret computation. The shared secret computation provides between 112 and 256 bits of encryption strength. Key Transport Information: See - Security Function Implementations Table, line KTS and details below:
• AES-Key Wrapping The module implements a Key Transport Scheme (KTS) using AES-KW compliant to [SP800-38F]. The SSP establishment methodology provides between 128 and 256 bits of encryption strength.

No parts of the TLS or IPsec protocols, other than those mentioned above, have been tested by the CAVP and CMVP. This document may be reproduced and distributed only in its original entirely without revision.

Table 47: Ports and Interfaces 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 support an authentication mechanism for Crypto Officer. The Crypto Officer role is authorized to access all services provided by the module (see Table - Approved Services and Table - Non-Approved Services).

The module implements a dedicated API function to indicate if a requested service utilizes an approved security function (see also section 2.4). This document may be reproduced and distributed only in its original entirely without revision.

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

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

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

G,R,W,E G,R,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.

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

Z Z Z Table 49: Approved Services The abbreviations of the access rights to SSPs have the following interpretation: 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.

Table 50: Non-Approved Services

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

A software 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.

The module’s integrity test can be performed on demand by power-cycling the computing platform. Integrity tests on demand is 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.

Type of Operational Environment: Modifiable

The module is supplied as part of Device OS, a commercially available general-purpose operating system executing on the computing platforms specified in section 2.2. This document may be reproduced and distributed only in its original entirely without revision.

The FIPS 140-3 physical security requirements do not apply to the Apple corecrypto Module v12.0 [Apple silicon, User, Software, SL1] since it is a software module. 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 52: SSP Input-Output Methods

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

Table 53: 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 N/A This document may be reproduced and distributed only in its original entirely without revision.

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

h Table 54: SSP Table 1 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 55: 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 software integrity automatically when the module is loaded into memory (i.e., at power on) before the module transitions to the operational state. A used to perform the approved integrity technique. Prior to using HMAC-SHA-256, a Conditional Cryptographic Algorithm Self-Tests (CAST) is performed. Table 56: 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.

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.

Name

Description signature failed to verify successfully in the Conditional PCT. No cryptographic services are provided, and data output is prohibited

Conditions

Recovery Method

Indicator

The module permits operators to initiate the pre-operational or conditional self-tests on demand for periodic testing of the module by rebooting the system (i.e., power-cycling). This document may be reproduced and distributed only in its original entirely without revision.

Startup Procedures: The module is built into Device OS defined in section 2 and delivered/ installed with the respective Device OS. There is no standalone delivery of the module as a software library. 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 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 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/CSRC/media/projects/cryptographic-module-validationprogram/documents/entropy/E14_PublicUse.pdf The ESV Public Use Document (PUD) reference for non-physical entropy source is: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validationprogram/documents/entropy/E15_PublicUse.pdf 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.

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

The Crypto Officer shall consider the following requirements and restrictions when using the module.  AES-GCM see section 2.7.  AES-XTS see section 2.7.  PBKDF see section 2.7.

The module secure sanitization is accomplished through the Lost Mode, remote wipe, and remote lock sections of the provided vendor document [platform certifications]. The operator can initiate sanitization. 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 CAVP                  Cryptographic Algorithm Validation Program API                   Application Programming Interfaces CAST                  Cryptographic Algorithm Self-Test CAST5                 A symmetric-key 64-bit block cipher with 128-bit key CBC                   Cipher Block Chaining CCM                   Counter with Cipher Block Chaining-Message Authentication Code CFB                   Cipher Feedback CMAC                  Cipher-based Message Authentication Code CMVP                  Cryptographic Module Validation Program CSP                   Critical Security Parameter CTR                   Counter Mode DRBG                  Deterministic Random Bit Generator ECB                   Electronic Code Book ESVP                  Entropy Source Validation Program FFC                   Finite Field Cryptography FIPS                  Federal Information Processing Standards Publication GCM                   Galois Counter Mode HMAC                  Hash Message Authentication Code KAS                   Key Agreement Schema KAT                   Known Answer Test KBKDF                 Key Based Key Derivation Function KDF                   Key Derivation Function KW                    AES Key Wrap MAC                   Message Authentication Code NIST                  National Institute of Science and Technology OAEP                  Optimal Asymmetric Encryption Padding OFB                   Output Feedback PAA                   Processor Algorithm Acceleration PBKDF                 Password Based Key Derivation Function PRF                   Pseudo-Random Function PSS                   Probabilistic Signature Scheme PUD                   Public Use Document (ESVP) RSA                   Rivest, Shamir, Addleman SHA                   Secure Hash Algorithm SHS                   Secure Hash Standard SSC                   Shared Secret Computation TOEPP                 Tested Operational Environment Physical Perimeter XTS                   XEX-based Tweaked-codebook mode with cipher text Stealing This document may be reproduced and distributed only in its original entirely without revision.