Crypto Module for Intel® Alder Point PCH Converged Security and Manageability Engine (CSME)

Certificate

Approved Algorithms (31)

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

flowchart LR
  %% Deterministic review-risk graph for Crypto Module for Intel® Alder Point PCH Converged Security and Manageability Engine (CSME)
  %% 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>Firmware Load<br/>recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>status output<br/>Show Status<br/>Self-Test</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/>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 Crypto Module for Intel® Alder Point PCH Converged Security and Manageability Engine (CSME)
  %% 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>Firmware Load<br/>recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>status output<br/>Show Status<br/>Self-Test</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/>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

Crypto Module for Intel® Alder Point PCH Converged Security and Manageability Engine (CSME) Hardware Version 4.6.0.0 Firmware Version 5.2.0.0 Prepared by: atsec information security corporation

4516 Seton Center Parkway, Suite 250

Austin, TX 78759 www.atsec.com © 2024 Intel® Corporation / atsec information security.

3 of 45

© 2024 Intel® Corporation / atsec information security corporation.

© 2024 Intel® Corporation / atsec information security corporation. This document can be

4 of 45

© 2024 Intel® Corporation / atsec information security corporation.

This document is the non-proprietary FIPS 140-3 Security Policy of the Crypto Module for Intel® Alder Point PCH Converged Security and Manageability Engine (CSME). 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 for a Hybrid Firmware module at an overall security level 2. The table below shows the security level claimed for each of the security requirement area that comprise the Table 1 - Security Levels

5 of 45

© 2024 Intel® Corporation / atsec information security corporation.

2.1. Module Overview is classified as a Hybrid Firmware module operating in a single-chip environment. In this document, “CSME”, and “module” are used interchangeably. They all refer to the Crypto Module for Intel® The components of the hybrid cryptographic module are specified in the following table:

6 of 45

© 2024 Intel® Corporation / atsec information security corporation.

The module has been tested on the following single-chip platform: Table 3 - Operational Environments 2.3. Cryptographic Boundary The module is a firmware hybrid module implemented in the physical embodiment of either a Alder Point PCH-S with Alder Lake S (referred to as ADL-S), Raptor Lake S (RPL-S) or Raptor Lake HX (RPL-

7 of 45

© 2024 Intel® Corporation / atsec information security corporation.

HX) CPU or an Alder Point PCH-M/P with Alder Lake M (ADL-M) or Raptor Lake P (RPL-P) CPU. The Tested Operational Environment’s Physical Perimeter (TOEPP) is represented by the dashed purple lines in the block diagram shown below. The module provides cryptographic services to operators through an application program interface (API). The cryptographic boundary consists of the OCS ROM, CSME Driver FW, the AES, ECC, and HCU hardware cryptographic engines along with the fips_hmac integrity file. The cryptographic boundary is represented by the dashed red lines below. Figure 5

• Logical cryptographic boundary and physical boundary block diagram 2.4. Modes of operation The module supports two modes of operation:
• In "Approved mode" (the Approved mode of operation) only approved or allowed security functions with sufficient security strength can be used. Table 4 lists the approved security functions.
• In "Non-approved mode" (the non-Approved mode of operation) only non-approved security functions can be used. Table 5 lists the non-FIPS functions. The mode of operation is implicitly assumed contingent on the service that is being requested. In other words, if an approved service is requested, the module assumes the approved mode of operation; if a non-approved service is requested, the module assumes the non-approved mode of operation. The module does not implement a degraded mode of operation. 2.5. Approved Algorithms The module supports the following Approved cryptographic algorithms. Table 4 lists the algorithms validated by the CAVP Certificate:

8 of 45

© 2024 Intel® Corporation / atsec information security corporation.

9 of 45

© 2024 Intel® Corporation / atsec information security corporation.

3 Although other sizes were validated by CAVP, only modulus size 2048 is considered approved for key un-encapsulation.

See Section 6.3.1 for more details.

10 of 45

© 2024 Intel® Corporation / atsec information security corporation.

11 of 45

© 2024 Intel® Corporation / atsec information security corporation.

Table 4 – Approved Algorithms 2.6. Non-Approved Algorithms The module does not implement any Non-Approved Algorithms Allowed in the Approved Mode of Operation nor Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed. The module implements the following non-Approved algorithms Not Allowed in the Approved Mode of Operation listed in the table below.

12 of 45

© 2024 Intel® Corporation / atsec information security corporation.

Table 5 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

13 of 45

© 2024 Intel® Corporation / atsec information security corporation.

The cryptographic module is defined as a Firmware-Hybrid module. The logical interfaces are the application program interface (API) through which operators request services from the module power interfaces are provided by the computing platform on which it runs. The module does not implement a control output interface. The following table summarizes the four logical interfaces: Table 6 - Ports and Interfaces

4 Control Output Interface is not implemented in the module and thus omitted from this table.

14 of 45

© 2024 Intel® Corporation / atsec information security corporation.

4. Roles, Services and Authentication 4.1. Roles The module supports the following roles:

• User Role: Performs all the services (in both approved mode and non-approved mode), except for the module installation and configuration.
• Crypto Officer role: performs module initialization (installation, configuration). The module does not support a maintenance role The User and Crypto Officer roles are assumed by the entity accessing the module services contingent on the authentication, as described in Section 4.3. The Crypto Officer and User Roles are separated by function. The Crypto Officer is only available during initialization of the module as instructed in Section 11.1. After the module is operational, only the User Role is available to request services of the module.

15 of 45

© 2024 Intel® Corporation / atsec information security corporation.

16 of 45

© 2024 Intel® Corporation / atsec information security corporation.

Table 7 - Roles, Service Commands, Input and Output 4.2. Services The module provides services to the operator that assumes one of the authorized roles, User role after operator is authenticated or CO role which is not authenticated but can only perform

17 of 45

© 2024 Intel® Corporation / atsec information security corporation.

fips_indicator

FIPS_APPROVED_SEC_FUN

initialization service. All services are described in detail in the user documentation. For Approved services, a fips_indicator flag is enabled in the crypto_ioctl_status_t structure and is set to FIPS_APPROVED_SEC_FUN when a function is an approved service. After the module completes the requested service, it will report the status as an output parameter indicating whether the service was Approved (i.e., set to “1”). The following table lists the Approved services and the non-Approved but allowed services in approved mode of operation, the roles that can perform the service, the Critical Security Parameters involved and how they are accessed: Generate: The module generates or derives the SSP. Read: The SSP is read from the module (e.g., the SSP is output). Write: The SSP is updated, imported, or written to the module. Execute: The module uses the SSP in performing a cryptographic operation. Zeroise: The module zeroises the SSP.

18 of 45

© 2024 Intel® Corporation / atsec information security corporation.

19 of 45

© 2024 Intel® Corporation / atsec information security corporation.

20 of 45

© 2024 Intel® Corporation / atsec information security corporation.

21 of 45

© 2024 Intel® Corporation / atsec information security corporation.

Table 8 – Approved Services The following table lists the services only available in non-approved mode of operation:

22 of 45

© 2024 Intel® Corporation / atsec information security corporation.

Table 9 – Non-Approved Services 4.3. Operator Authentication The module implements role-based operator authentication to authenticate the User Role. The authentication mechanism is based on the RSASSA-PSS signature algorithm with 3072-bit modulus (Cert. #A3362). The Crypto Officer role is not authenticated. The Crypto Officer role can only perform the initialization service, which is a non-authenticated service and does not affect the security of the module per IG 4.1.A. An operator with the User role is the CSME firmware application (Figure 5). There can be only one CSME application running and interfacing with the module during the module’s operation, enforced by the design of the module. Thus, the module does not support concurrent operators. The manufacturer utilizes their unique RSA private key to sign the CSME application images. The private signing keys are kept in a HSM (Hardware Security Module) within an Intel secured facility and remain unknown to both the module and the CSME application. The public key and the signature are provided as part of the firmware manifest. The hash of the public key is also hardcoded in the module. During runtime, the public key in the provided firmware manifest is first hashed, then compared with the hash stored in module. If the hash matches, the module proceeds to assert whether the signature of the CSME application verifies, using the public key. If the signature verification succeeds, the CSME application firmware is authenticated and hence can be loaded and executed. The module does not maintain authentication after computing platform power loss (power-off, reset, etc.). The authentication process occurs within the physical perimeter of the module, and thus it is not visible outside of this perimeter. The authentication data is essentially composed of public data (signature and public key); therefore, their disclosure does not affect the security of the authentication mechanism. 4.3.1. Strength of Authentication The digital signature verification authentication mechanism using RSA PSS with 3072-bit modulus provides an encryption strength of 128 bits. The strength of this mechanism is equivalent to the probability of correctly guessing the private signing key, and this probability is 1/2128 (or 2.94e39).

23 of 45

© 2024 Intel® Corporation / atsec information security corporation.

If attempts are made to authenticate an operator by guessing the private key and presenting the corresponding signature of the CSME firmware, we may suppose a rate of 1μs per attempted authentication (i.e., per guess of the private key and respective signature). This rate would allow 60,000,000 consecutive attempts per minute. The probability of successfully authenticating at this rate is less than or equal to 60,000,000 * 1/2128 (≤1.7632e-31). Table 10 - Roles and Authentication

24 of 45

© 2024 Intel® Corporation / atsec information security corporation.

5. Software/Firmware Security 5.1. Integrity Techniques 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 OCS ROM component of the module is a non-reconfigurable memory (specifically masked ROM), which is exempt from the requirements of integrity test. The vendor performed memory degradation testing to assert that the memory will not degrade before 10 (ten) years of manufacture date, thus complying with the requirements of IG 5.A. 5.2. On-Demand Integrity Test The on-demand integrity self-tests can be invoked by the user performing reboot, the device which will cause pre-operational and conditional self-tests to run. 5.3. Executable Code The Converged Security Management Engine (CSME) Driver i.e., module’s firmware, is made up of a single component, provided in the form of binary executable code. The firmware wholly contains the executable form without further compilation.

25 of 45

© 2024 Intel® Corporation / atsec information security corporation.

6. Operational Environment 6.1. Applicability The module operates in a non-modifiable operational environment per FIPS 140-3 security level 2 specifications. The operator cannot modify the firmware component of the module. The module runs on an internal customized proprietary OS (i.e., CSME OS) within the Intel SoC.

26 of 45

© 2024 Intel® Corporation / atsec information security corporation.

7. Physical Security The module is a hybrid firmware module that operates on a single-chip standalone platform which conforms to the Level 2 requirements for physical security. The single chip cryptographic module is a production grade component that include standard passivation (e.g., a sealing coat applied over the chip circuitry to protect it against environmental and other physical damage). The layering process which is used to embed the die into the PCB of the single chip computing platform also provides opacity that prevents viewing internal construction within the visible spectrum. The single chip enclosure prevents accessing of the module’s hardware components without leaving physical tamper evidence.

27 of 45

© 2024 Intel® Corporation / atsec information security corporation.

8. Non-invasive Security This module does not implement any non-invasive security mechanism, and therefore this section is not applicable.

28 of 45

© 2024 Intel® Corporation / atsec information security corporation.

9. Sensitive Security Parameter Management Keys residing in internal storage can only be accessed using the defined API. Memory and process space is protected from unauthorized access by the operating system. Only the process that According to FIPS 140-3, Sensitive Security Parameters (SSPs) consist of Critical Security Parameters (CSPs) and Public Security Parameters (PSPs). The following table summarizes all CSPs, and PSPs

29 of 45

© 2024 Intel® Corporation / atsec information security corporation.

30 of 45

© 2024 Intel® Corporation / atsec information security corporation.

31 of 45

© 2024 Intel® Corporation / atsec information security corporation.

32 of 45

© 2024 Intel® Corporation / atsec information security corporation.

33 of 45

© 2024 Intel® Corporation / atsec information security corporation.

Table 11 - Life cycle of Sensitive Security Parameters (SSP) derivation function and without prediction resistance as the approved Random Number Generator. The CTR_DRBG is implemented in the firmware (i.e., CSME Crypto Driver) and provides between 128 and 65536 bits of output data per each request. (V and key values)' are considered CSPs by the module. Non-DRBG functions cannot access the DRBG internal state. for seeding the CTR_DRBG inside the module. The entropy source provides a 128-bit output. At the Table 12 - Non-Deterministic Random Number Generation (Entropy Source) Specification The module implements asymmetric key generation services for RSA7, ECDSA and EC Diffie-Hellman keys, compliant to SP800-133rev2 Cryptographic Key Generation (CKG, vendor affirmed) in accordance with IG D.H. For generating RSA and ECDSA keys, a seed (i.e., random value) used in asymmetric key generation obtained directly from the module’s approved SP800-90Arev1 DRBG (i.e., CTR_DRBG, Cert. #A3362). This follows asymmetric key generation method compliant with FIPS186-4 and defined in Section 5.1 of SP 800-133rev2 . The EC Diffie-Hellman keys are generated internally by the module using the ECDSA key generation method compliant with FIPS186-4 and SP800-56Arev3 as defined in section 5.2 of SP800-133rev2. The module does not offer a dedicated service for generating symmetric keys.

7 Approved RSA Key Generation will only use public key exponent e = 2 16 + 1

34 of 45

© 2024 Intel® Corporation / atsec information security corporation.

9.3. SSP Establishment The module provides an approved [SP800-56Arev3] EC Diffie-Hellman Key Agreement Scheme. The key agreement scheme is compliant with IG D.F scenario 2 path (2). The CAVP testing was performed end-to-end, using the Ephemeral Unified Model with approved domain parameters (i.e., P-256 and P-384 curves and SHA-224, SHA-256, SHA-384, and SHA-512 auxiliary function) resulting in a KASECC Cert. #A3362. The module provides key derivation service using SP800-108 KBKDF. The module supports SP800-56Brev2 Key Transport using KTS-OAEP-basic8. RSA-KTS encapsulation is approved with the key sizes of 2048, 3072 and 4096 bits in approved mode while RSA-KTS unencapsulation is approved only with a key size of 2048 bits in the approved mode. 9.3.1. Assurances The following statements explain the SP800-56Brev2 assurances found in its Section 5:

• Section 5.1
• The module uses an approved hash function (SHS, Cert. #A3362) for mask generation during RSA-OEAP encryption.
• Section 5.2
• N/A, the module does not implement key confirmation.
• Section 5.3
• The module uses an approved random bit generator (CTR_DRBG, Cert. #A3362) when generating random values.
• Section 5.4 and Section 5.5
• N/A, the module does not implement a key agreement scheme (i.e., KAS1).
• Section 5.6
• N/A, the module does not implement key confirmation. In addition, the following statements explain the SP800-56Brev2 assurances found in its Section 6 (specifically SP800-56Brev2 Section 6.4 Required Assurances):
• Prior to the use of the key pair in a key-establishment transaction, assurances required by the key-pair owner are obtained in the following way (Note: only keys generated following this guidance shall be compliant to SP800-56Brev2): 1) The entity requesting the RSA key unwrapping (decapsulation)service from the module, shall only use an RSA private key that was generated by an active FIPS validated module that implements FIPS 186-4 compliant RSA key generation service and performs the key pair validity and the pairwise consistency as stated in section

6.4.1.1 of the SP 800-56BRev2. Additionally the entity shall renew these assurances

over time by using any method described in section 6.4.1.5 of the SP 800-56BRev2. 2) For use of an RSA key wrapping (encapsulation) service in the context of key transport per IG D.G,

• the entity using the module, shall verify the validity of the peer's public key using the public key validation service of the module.
• the entity using the module, shall confirm the peer's possession of private key by using any method specified in section 6.4.2.3 of the SP 800-56BRev2. Only after the above assurances are successfully met, shall the entity use the peer's public key to perform the RSA key wrapping (encapsulation) service of the module. CAVEAT:
• EC Diffie-Hellman key establishment methodology provides 128 or 192 bits of encryption strength.
• RSA key wrapping provides between 112 and 150 bits of encryption strength.

8 KTS-OAEP-basic is the basic scheme without key confirmation defined in section 9.2.3 of SP800-56Brev2.

35 of 45

© 2024 Intel® Corporation / atsec information security corporation.

9.4. SSP Entry / Output The module does not support manual key entry or intermediate key generation key output. SSPs entered into the module are electronically entered in plain text form. SSPs are output from the module in plain text form if required by the calling application. 9.5. SSP Storage The symmetric keys and HMAC keys are provided to the module via API input parameters and are zeroized by the module before they are released in the memory. Asymmetric public and private keys are provided to the module via API input parameters and are destroyed by the module before they are released in the memory. 9.6. SSP Zeroization The memory occupied by SSPs is stored in RAM during runtime, allocated by regular memory allocation operating system calls. Every service of the module performs a zeroization operation as the last step before exiting from the function. The zeroization operation overwrites the memory occupied by keys with “zeros” before de-allocating the memory with the regular memory deallocation operating system call. In addition, the RAM is volatile so zeroization of all SSPs can be performed by power-cycling (i.e., reset) or power-off the computing platform. Additionally, while zeroization is in progress, data output is inhibited. Once a SSP is zeroized, it is no longer retrievable. The module uses an implicit indicator to express the completion of the zeroization operation. Zeroization is performed by the module through the course of executing its services. The module implicitly indicates the success of the zeroization by accepting the proceeding request. If the module accepts the next service request, this implicitly indicates that the zeroization of the previous service request successfully completed. Lastly, temporary SSPs are zeroized when they are no longer needed.

36 of 45

© 2024 Intel® Corporation / atsec information security corporation.

10. Self-Tests The module performs pre-operational firmware integrity test and conditional algorithm self-tests to ensure the correctness of the cryptographic algorithm implementations within the module boundary. The pre-operational and conditional cryptographic algorithm self-tests (CAST) are performed automatically at power-up or reset without any user interaction and must successfully pass all tests prior to providing any services to the caller. While the module is performing self-test, all access through data input, data output, control input and status output are inhibited. The module executes functions sequentially. While the self-tests are executing, no interaction is possible. The module does not implement a Software/Firmware Load Test, Manual Entry Test, Conditional Bypass Test nor Conditional Critical Functions Test, as the related functions are not implemented. If any test fails, the module reports an error message through the status interface and enters the Error State. No data output and cryptographic operation are performed while the module is in the Error State. To recover from the Error State, the module must transition to the power off state, then to the power on state by a power cycle and must successfully pass both pre-operational integrity test and conditional algorithm self-tests. That is to say, when an error condition is detected and the error state is entered, all data output via the data output interface is inhibited, until error recovery occurs. 10.1. Pre-operational Firmware Integrity Test The module performs pre-operational firmware integrity tests automatically when the computing platform is powered on, and the module is loaded into memory. The module’s OCS ROM first performs an HMAC-SHA-256 conditional cryptographic algorithm self-test (CAST) and after successfully passing, the module performs an integrity test of the module’s firmware component (Converged Security Management Engine (CSME) Driver) by computing an HMAC-SHA-256 value of the binary and comparing it with the value stored in the module that was computed at build time. If the HMAC values do not match, the test fails, and the module enters the Error state. While the module is performing pre-operational firmware integrity test, the module’s data output is inhibited. 10.2. Conditional Cryptographic Algorithm Self-Tests The module performs a conditional cryptographic algorithm self-test (CAST) on all FIPS-Approved cryptographic algorithms supported in the approved mode of operation and per IG 10.3.A. The conditional cryptographic algorithm self-tests are performed before the first use of the related algorithm: First the AES ECB, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512,and KAS-SSC are selftested in hardware, prior to the integrity test of the firmware component, and then the rest of the CASTs are automatically performed after the integrity test completes successfully (and before the module enters the operational state 9). If any of the cryptographic algorithm self-test fails, the module will enter the Error State, wherein all data output is inhibited. The pre-operational and conditional algorithm tests performed are shown in the following table:

9 Operational State is the state where the operator can request services of the module.

37 of 45

© 2024 Intel® Corporation / atsec information security corporation.

Table 13 - Conditional Cryptographic Algorithm Self-Tests 10.2.1. Entropy Related Health Tests Intel has designed a proprietary Online Health Test (OHT) for the ENT (P) that can detect when:

1. Some value is consecutively repeated more times than expected, given the assessed entropy per sample of the source.
2. Some value becomes much more common in the sequence of noise source outputs than expected, given the assessed entropy per sample of the source. After each reset, the OHT is automatically started and runs continuously until power-off or the next reset. A constant stream of 256-bit samples is outputted from the noise source into the OHT where it tracks the entropy health. The OHT is designed to have the same functionality and health coverage as the following health tests required by NIST SP 800-90B: • Start-Up Tests • Repetitive Counter Test (RCT) • Adaptive Proportion Test (APT) The OHT was designed to detect repeating patterns from the ENT (P). The OHT accomplishes this by continuously monitoring the statistical arrival rate of short bit patterns. As the bit patterns arrive, they are counted and then tested to see if the total pattern number lay within the expected binomial distribution. 10.2.2. Conditional Pair-wise Consistency Tests The module performs a Conditional Pair-wise Consistency Tests upon generating RSA and ECDSA/ECDH asymmetric key pairs. The test is implemented by calculating a signature on a

38 of 45

© 2024 Intel® Corporation / atsec information security corporation.

predetermined data and subsequently performing a verification of the signature. If the signature cannot be verified, the generated key-pair is discarded, and the module enters the Error State. 10.3. On-Demand and Periodic Self-Tests The on-demand and periodic self-tests can be invoked by the user performing reboot, the device which will cause pre-operational and conditional self-tests to run. 10.4. Error State The module implements one error state. If any of the self-tests described in sections above fails, the module indicates the error indicator associated with the specific error by invoking the crypto_fips_error_handler() function and causes the module to enter the error state. In the error state, no cryptographic services are provided, and data output is prohibited. When the module is in the error state, the only method to recover is to reset the computing platform which results in the module reperforming the pre-operational firmware integrity test and the conditional cryptographic algorithm self-tests. The module will only enter the operational state after successfully passing both.

39 of 45

© 2024 Intel® Corporation / atsec information security corporation.

11. Life-cycle Assurance 11.1. Operator’s Guidance The following security guidance for Crypto Officer role is described below: • To enable the module for use in a FIPS validated configuration, the Crypto Officer must first perform initialization of the module. If FIPS operations are not enabled within the BIOS settings, then the module is not a 140-3 validated module and cannot enter the approved mode which means no FIPS services will be available. The Crypto Officer shall perform the following steps to initialize the module. o Power on the Host Platform and enter the BIOS menu setting. o Enter “FIPS mode” submenu. o Set “FIPS Mode Select” to <Enabled>. o Save and exit the BIOS menu. The Host Platform will the power-cycle (i.e., reset) and proceed to boot. Once “FIPS Mode Select” is Enabled, the CSME OS will set the crypto_fips_en file which serves the control input the module and initializing it as a FIPS 140-3 validated module following power-on. The following security guidance for User role is described below: • The User of the module can call the API function crypto_drv_fips_mode_status() to check if the module is an FIPS 140-3 validated module. If the call returns 1, the module is an FIPS 140-3 validated module; it returns 0 if the module is not an FIPS 140-3 validated module. Note, this is not the service indicator; the service indicator is provided as described in Section 4.2. Services. 11.2. Delivery Procedure The firmware component of the module is distributed as part of the CSME Device Driver firmware. Firmware is released on VIP site https://platformsw.intel.com. Only Original Equipment Manufacturers (OEM) with signed Intel agreements can download this firmware. The module is contained within one of the platforms listed in Table
12. These Intel platforms are a tightly coupled component of 12th Generation Intel® Core™ chipsets. These platforms can be bundled with CPU as a kit, or outside the CPU packages as a discreet component mounted on the Printed Circuit Board (PCB). Intel requires their Original Equipment Manufacturer (OEM) partners that create, market, and sell these systems to meet the brand validation requirements and testing to ensure they have been designed and constructed with the proper components including CPU and Intel chipsets. Intel’s brand validation tool would detect any mismatch of CPU and chipset for any system being designed. Intel manages and implements security best practices throughout every step of their supply chain and works closely with their partners (i.e., Original Design Manufacturer and Original Equipment Manufacturer) to ensure that they meet Intel’s requirements for secure supply chain processes as specified in partner contract agreements. Therefore, end customers can be assured that any system had been designed and tested to conform to Intel’s requirements will always have an Intel PCH that contains the module. 11.3. AES GCM IV The User shall consider the following requirements and restrictions when using the module. AESGCM IV is constructed in accordance with SP800-38D in compliance with IG C.H scenario
13. GCM IV generation uses an approved CTR_DRBG that is internal to the module’s boundary and the IV length is at least 96 bits (per SP 800-38D).

40 of 45

© 2024 Intel® Corporation / atsec information security corporation.

11.4. End of Life The module automatically performs secure sanitization at the conclusion of any service performed by the module. Since the module does not retain any persistent SSPs, the procedures for secure sanitization of the cryptographic module are inherently met.

41 of 45

© 2024 Intel® Corporation / atsec information security corporation.

12. Mitigation of Other Attacks The module provides mechanism to protect against RSA timing attacks. The OCS's (i.e., module’s hardware component) big-number arithmetic can perform the modular exponentiation operations in constant time. This means, the time taken is only dependent on the size of operands and not dependent on the value of the operands. During modular exponentiation, an extra mathematical step is needed when the processed bit of the key is 1 compared to a zero bit. The OCS’s big-number arithmetic implements a “dummy” step when processing a zero bit from the key such that this processing time is identical to the processing time of a set bit. Using this approach, an observer is unable to determine the number of set and unset bits from observing the timing behavior of the modular exponentiation operation. The CSME Crypto Driver takes advantage of this feature by enabling the functionality in the OCS for private key operations. This implies that the computation time using the private key is constant, hence mitigating timing attacks. The OCS’s AES block cipher in OCS supports an implementation that is resistant to DPA (Differential Power Analysis) attacks. The mechanism implemented is based on masking AES inputs at every stage with a pseudo-random mask. The seed for the pseudorandom mask generator is programmable. The OCS’s ECC has protection against known DPA Attacks. This is achieved by randomizing the inputs so there is no correlation to the power consumed and ECC operations. This is done by transforming inputs from one coordinate system (Affine) to another coordinate system (Randomized Jacobian).

42 of 45

© 2024 Intel® Corporation / atsec information security corporation.

Appendix A. Glossary and Abbreviations AES                Advanced Encryption Standard ADL-P              Alder Lake P ADL-S              Alder Lake S API                Application Program Interface CBC                Cipher Block Chaining CMVP               Cryptographic Module Validation Program CSME               Converged Security and Manageability Engine CSP                Critical Security Parameter CTR                Counter Mode CVL                Component Validation List DRBG               Deterministic Random Bit Generator ECB                Electronic Code Book ECC                Elliptic Curve Cryptography ECDAA              Elliptic Curve Direct Anonymous Attestation ECSCHNORR          Schnorr-type Digital Signature Scheme over Elliptic Curve FIPS               Federal Information Processing Standards Publication HMAC               Hash Message Authentication Code HCU                Hash Computation Unit KAS                Key Agreement Scheme KAT                Known Answer Test MAC                Message Authentication Code NIST               National Institute of Science and Technology OAEP               Optimal Asymmetric Encryption Padding PCH                Platform Controller Hub PCT                Pair-wise Consistency Test PSS                Probabilistic Signature Scheme RPL-M              Raptor Lake M RPL-P              Raptor Lake P RPL-S              Raptor Lake S RSA                Rivest, Shamir, Addleman SHA                Secure Hash Algorithm

43 of 45

© 2024 Intel® Corporation / atsec information security corporation.