DRAFT Protection Profile for General-Purpose Computing Platforms DRAFT

Version: 2.0
2025-06-27
National Information Assurance Partnership

Revision History

Contents

1 Introduction

1.1 Overview

• NIST SP 800-147 BIOS Protection Guidelines, April 2011
• NIST SP 800-147B BIOS Protection Guidelines for Servers, August 2014
• NIST SP 800-193 Platform Firmware Resiliency Guidelines, May 2018

• NIST SP 800-155 (Draft) BIOS Integrity Measurement Guidelines (Draft), December 2011
• NIST SP 1800-34 (Draft) Validating the Integrity of Computing Devices, December 2022
• Trusted Computing Group, TCG PC Client Platform Firmware Integrity Measurement Version 1.0 Revision Specification 43 Family 2.0, May 7, 2021
• IEEE Std 802.1AR-2018, Secure Device Identity

1.3 TOE Overview

1.3.1 TOE Boundary

Figure 1: High-Level Architecture of a Generic Platform

1.3.2 TOE Operational Environment

1.4 Use Cases

• a TOE that meets [USE CASE 2] Server-Class Platform, Enhanced Security Requirements also meets [USE CASE 1] Server-Class Platform, Physically Secure Environment

[USE CASE 1] Server-Class Platform, Physically Secure Environment

This use case encompasses server-class hardware in a data center. There are no additional physical protections required because the platform is assumed to be protected by the operational environment as indicated by A.PHYSICAL_PROTECTION. The platform is administered using a management controller that is accessed remotely or through a console.

This use case adds audit requirements and Administrator authentication requirements to the base mandatory requirements.

For changes to included SFRs, selections, and assignments required for this use case, see G.1 Server-Class Platform, Physically Secure Environment.

[USE CASE 2] Server-Class Platform, Enhanced Security Requirements

This use case adds physical protections to the base requirements for server-class hardware. Additional physical protections are required because the platform is assumed to not be protected by the operational environment, or because of enhanced security requirements imposed by data center or operational policies.

This use case adds requirements for audit, physical protections, and Administrator authentication to the base mandatory SFRs.

For changes to included SFRs, selections, and assignments required for this use case, see G.2 Server-Class Platform, Enhanced Security Requirements.

[USE CASE 3] Portable Clients (laptops, tablets), Enhanced Security Requirements

This use case adds physical protections to the base requirements for portable clients or end-user devices. It is intended for devices are used in high-assurance scenarios.

For changes to included SFRs, selections, and assignments required for this use case, see G.3 Portable Clients (laptops, tablets), Enhanced Security Requirements.

[USE CASE 4] CSfC EUD

EUDs used in accordance with the CSfC Mobile Access Capability Package can include smart phones, tablets, desktops, and laptops. This use case covers the basic CSfC requirements for EUDs other than mobile devices (mobile devices are out of scope for this PP).

CSfC requires that users maintain physical control of EUDs at all times. This use case adds requirements for audit and for protection of debug ports .

The CSfC Use Case requires that End User Devices prohibit the use of removable media either through configuration, policy, or physical modification.

For changes to included SFRs, selections, and assignments required for this use case, see G.4 CSfC EUD.

[USE CASE 5] Tactical EUD

This use case adds requirements for portable end user computing devices in a tactical environment.

For changes to included SFRs, selections, and assignments required for this use case, see G.5 Tactical EUD.

[USE CASE 6] Enterprise Desktop clients

This use case covers the requirements for non-portable desktop computing devices in a low-threat enterprise physical environment.

This use case adds only audit to the base mandatory SFRs.

For changes to included SFRs, selections, and assignments required for this use case, see G.6 Enterprise Desktop clients.

1.5 Roles

1. Users (unprivileged users)
2. Administrators (privileged users)

2 Conformance Claims

Conformance Statement

An ST must claim exact conformance to this PP.

The evaluation methods used for evaluating the TOE are a combination of the workunits defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs and SARs have a sufficient level of supporting evidence in the Security Target and guidance documentation and have been sufficiently tested by the laboratory as part of completing ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation Activities that are used in this same manner.

CC Conformance Claims

This PP is conformant to Part 2 (extended) and Part 3 (extended) of Common Criteria CC:2022, Revision 1 as corrected and interpreted in [ERR], Version 1.1.

PP Claim

This PP does not claim conformance to any Protection Profile.

There are no PPs or PP-Modules that are allowed in a PP-Configuration with this PP.

Package Claim

• This PP is Functional Package for Secure Shell (SSH) Version 2.0 conformant.
• This PP is Functional Package for Transport Layer Security Version 2.1 conformant.
• This PP is Functional Package for X.509 Version 1.0 conformant.
• This PP does not conform to any assurance packages.

The functional packages to which the PP conforms may include SFRs that are not mandatory to claim for the sake of conformance. An ST that claims one or more of these functional packages may include any non-mandatory SFRs that are appropriate to claim based on the capabilities of the TSF and on any triggers for their inclusion based inherently on the SFR selections made.

3 Security Problem Definition

• ensuring the integrity of its own firmware and hardware
• ensuring that it is resilient
• providing security services to tenant workloads

• Platform firmware and hardware
• Platform firmware updates
• Tenant initialization (boot)

3.1 Threats

T.PHYSICAL

An attacker with physical access might be able to compromise TOE integrity, subvert TOE protections, or access tenant data through hardware attacks such as probing, physical manipulation, fault-injection, side-channel analysis, environmental stress, or activating disabled features or pre-delivery services.

T.SIDE_CHANNEL_LEAKAGE

An attacker running in a tenant context might be able to leverage physical effects caused by the operation of the TOE to derive sensitive information about other tenants or the TOE.

T.PERSISTENCE

An attacker might be able to establish a permanent presence on the TOE in firmware. This could result in permanent compromise of tenant information, as well as TOE updates. This threat does not encompass attacker presence in tenant software, as tenant software is not part of the TOE.

T.UPDATE_COMPROMISE

An attacker may attempt to provide a compromised update of TOE firmware. Such updates can undermine the security functionality of the device if they are unauthorized, unauthenticated, or are improperly validated using non-secure or weak cryptography.

T.SECURITY_FUNCTIONALITY_FAILURE

An attacker could leverage failed or compromised security functionality to access, change, or modify tenant data, TOE data, or other security functionality of the device.

T.TENANT_BASED_ATTACK

An attacker running software as a tenant can attempt to access or modify TOE firmware or functionality. Note that direct tenant attacks against other tenants are not encompassed by this threat as they are out of scope.

T.NETWORK_BASED_ATTACK

An attacker from off the TOE can attempt to compromise the TOE through a network interface connected to an active TOE component, such as a management subsystem.

T.UNAUTHORIZED_RECONFIGURATION

An attacker might be able to modify the configuration of the TOE and alter its functionality. This might include, activating dormant subsystems, disabling hardware assists, or altering boot-time behaviors.

T.UNAUTHORIZED_PLATFORM_ADMINISTRATOR

An attacker might be able to attain platform administrator status by defeating or bypassing authentication measures.

3.2 Assumptions

A.PHYSICAL_PROTECTION

The TOE is assumed to benefit from varying levels of protections depending on use case and operational environment.

A.ROT_INTEGRITY

The TOE includes one or more Roots of Trust composed of TOE firmware, hardware, and pre-installed credentials. Roots of Trust are assumed to be free of malicious capabilities as their integrity cannot be verified.

A.TRUSTED_ADMIN

TOE Security Administrator are assumed to be trusted and to act in the best interest of security for the organization. The TOE is not expected to be capable of defending against a malicious Administrator that actively works to bypass or compromise the security of the platform.

A.MFR_ROT

The root signing credential of the manufacturer is assumed to be secure and has not been compromised.

A.TRUSTED_DEVELOPMENT_AND_BUILD_PROCESSES

The TOE cannot protect itself during its own development and build processes. Therefore it is assumed that the developers and participants in the build process are not hostile.

A.SUPPLY_CHAIN_SECURITY

The hardware components that comprise the TOE are assumed to be non-hostile and not compromised at the time of TOE construction. Likewise, the TOE is assumed to retain its integrity throughout transportation until delivery to its operational site.

A.CORRECT_INITIAL_CONFIGURATION

It is assumed that the initial setup and configuration of the TOE at its operational site is correct and in accordance with organizational security policy and operational use case.

A.TRUSTED_USERS

Physically present non-administrative users of the TOE are assumed to be trusted as far as they are assumed to not be actively trying to subvert the system. (Not for all use cases).

A.REGULAR_UPDATES

It is assumed that the manufacturer provides updates to TOE firmware in a timely manner in response to known vulnerabilities, and that Administrators apply these updates when they are received.

3.3 Organizational Security Policies

4 Security Objectives

4.1 Security Objectives for the Operational Environment

OE.PHYSICAL_PROTECTION

A TOE may benefit from different levels of protection provided by its operational environment. Platforms that operate within data centers or in other access-controlled environments are expected to receive a considerable degree of protection from these environments. In addition to physical protection, these environments often provide malware-detection and behavior-monitoring services for networked computing assets. On the other hand, a TOE would receive very little protection from a tactical environment.

OE.SUPPLY_CHAIN

The manufacturer is expected to implement processes to ensure that TOE hardware and firmware is not compromised between time of TOE manufacture and delivery to its operational site.

OE.TRUSTED_ADMIN

The administrator of the GPCP is not careless, willfully negligent or hostile, and administers the platform within compliance of enterprise security policy.

4.2 Security Objectives Rationale

5 Security Requirements

• Refinement operation (denoted by bold text or strikethrough text): Is used to add details to a requirement or to remove part of the requirement that is made irrelevant through the completion of another operation, and thus further restricts a requirement.
• Selection (denoted by italicized text): Is used to select one or more options provided by the [CC] in stating a requirement.
• Assignment operation (denoted by italicized text): Is used to assign a specific value to an unspecified parameter, such as the length of a password. Showing the value in square brackets indicates assignment.
• Iteration operation: Is indicated by appending the SFR name with a slash and unique identifier suggesting the purpose of the operation, e.g. "/EXAMPLE1."

5.1 Security Functional Requirements

5.1.1 Auditable Events for Mandatory SFRs

5.1.2 Class: Security Management (FMT)

5.1.3 Class: Protection of the TSF (FPT)

5.1.4 TOE Security Functional Requirements Rationale

The following rationale provides justification for each SFR for the TOE, showing that the SFRs are suitable to address the specified threats:

5.2 Security Assurance Requirements

5.2.1 Class ASE: Security Target

5.2.2 Class ADV: Development

5.2.3 Class AGD: Guidance Documentation

5.2.4 Class ALC: Life-cycle Support

5.2.5 Class ATE: Tests

5.2.6 Class AVA: Vulnerability Assessment

Appendix A - Optional Requirements

A.1 Strictly Optional Requirements

A.1.1 Auditable Events for Strictly Optional Requirements

A.1.2 Class ALC: Life-cycle Support

A.1.3 Class: Cryptographic Support (FCS)

A.1.4 Class: User Data Protection (FDP)

A.1.5 Class: Identification and Authentication (FIA)

A.2 Objective Requirements

A.2.1 Auditable Events for Objective Requirements

A.2.2 Class: Protection of the TSF (FPT)

A.3 Implementation-dependent Requirements

This PP does not define any Implementation-dependent requirements.

Appendix B - Selection-based Requirements

B.1 Auditable Events for Selection-based Requirements

B.2 Class: Security Audit (FAU)

B.3 Class: Cryptographic Support (FCS)

		For j = 0 to 99
			A = B = C = SEED
			For i = 0 to 999
				MSG = A || B || C
				MD = SHA(MSG)
				A = B
				B = C
				C = MD
			Output MD
			SEED = MD
						

		INITIAL_SEED_LENGTH = LEN(SEED)
		For j = 0 to 99
			A = B = C = SEED
			For i = 0 to 999
				MSG = A || B || C
				if LEN(MSG) >= INITIAL_SEED_LENGTH:
					MSG = leftmost INITIAL_SEED_LENGTH bits of MSG
				else:
					MSG = MSG || INITIAL_SEED_LENGTH - LEN(MSG) 0 bits
				MD = SHA(MSG)
				A = B
				B = C
				C = MD
			Output MD
			SEED = MD	
						

		MD[0] = SEED
		INITIAL_SEED_LENGTH = LEN(SEED)
		For 100 iterations
			For i = 1 to 1000
				MSG = MD[i-1];
				if LEN(MSG) >= INITIAL_SEED_LENGTH:
					MSG = leftmost INITIAL_SEED_LENGTH bits of MSG
				else:
					MSG = MSG || INITIAL_SEED_LENGTH - LEN(MSG) 0 bits
				MD[i] = SHA3(MSG)
			MD[0] = MD[1000]
			Output MD[0]