3.6.2 Authorization Mechanisms

Some recovery and administrative actions can make significant changes to either the Platform Firmware or software. For example, firmware settings may control the boot order, and a software recovery agent may restore a backup erasing recently created data. Modifying these settings could require Platform-level Authorization to demonstrate that the entity requesting a change is authorized to do so. For some environments, like large organizations or data centers, a professional Platform Administrator may authorize actions remotely using credentials provisioned to manage the platform. In other environments, e.g., consumers or smaller enterprises, there may not be a remote Platform Administrator. Some systems, however, may have Platform Administrator credentials that can be used locally. Alternatively, some systems may allow users to assert platform-level authorization by ensuring that a physically-present user has issued a command or requested a change. On these systems, the platform must unambiguously verify that a physically present user has authorized the action. If done correctly, malware cannot impersonate an authorization check that involves confirmation from a physically present user. We use the term Unambiguous Physical Presence to indicate a local user that cannot be impersonated by malware.

Unambiguous Physical Presence allows for assertion of Platform-level Authorization (or a portion of Platform-level Authorization) by demonstrating that a person is physically interacting with a device or platform. By ensuring that recovery actions or critical data changes are authorized by a physically present person, Unambiguous Physical Presence provides a management path that is intended to be protected from influence by malware.

Creating platforms and devices that properly and reliably verify confirmation of a physically present person is complex. Dedicated physical buttons or hardware jumpers could provide a relatively direct and explicit method by which to demonstrate physical presence. Platform design or deployment considerations may prevent a person from having direct physical mechanisms to interact with each device supporting a function that relies on Unambiguous Physical Presence. In these cases, there will need to be a trusted path between the mechanisms used to verify Unambiguous Physical Presence, and the device which will perform an action on behalf of the Administrator. To satisfy the non-bypassability guidelines found later in this document, this trusted path, which could include I/O devices (e.g., human interface device, graphics card, etc.) and internal buses, needs to be protected from manipulation by malware.

There are a variety of techniques that could provide a trusted path between a physical mechanism that verifies Unambiguous Physical Presence and a platform or device. One example could be to accept or confirm commands from a physically-present person only when the platform can be trusted to be in a state with integrity, before malware could disturb these processes, such as early in the boot process. In other cases, system architectures may provide trusted paths between a Service Processor (e.g., EC, BMC) and other platform devices.

Devices which rely on Unambiguous Physical Presence in place of Platform Administrator credentials to authorize administrative actions may be vulnerable to attacks by individuals with physical access to the device. As such, its usage may not be suitable in applications or environments that lack strong physical security.

`3.6.2` Authorization Mechanisms

Title

Control