BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

5.1 Solution Overview

NIST platform security: roots of trust, firmware and secure enclaves IR 8320A
All changes in this version
first version loaded 5 Server B launches workloads that require trusted infrastructure only on server platforms that have part of 5

Title

Solution Overview

Control

Stage 2 adds the monitoring of measurements in a governance, risk, and compliance dashboard. One chart that might appear in such a dashboard could reflect the relative size of the pools of trusted and untrusted cloud servers. This could be displayed by percentage and/or count.

Table 1 is a drill-down page from the high-level dashboard view. It provides more details on all the servers within the cloud. In this example, there are three servers. Information listed for each server includes the server’s IP address and universally unique identifier (UUID), and the status of the measurements (trusted boot validation and system health validation).

Table 1: Trusted Boot Compliance View

Cloud Host IP Hardware UUID Trusted Boot Validation System Health Validation <Host 1> <UUID 1> Yes/No Yes/No <Host 2> <UUID 2> Yes/No Yes/No <Host 3> <UUID 3> Yes/No Yes/No

Figure 4 shows a drill-down from Table 1 for an individual server. It includes a detailed measurement data for the trusted boot validation, alongside the connection status and asset tag list which may include asset tag value. It also shows when the server was measured and when the validity of this measurement expires. Measuring each server’s characteristics frequently (such as every five minutes) helps to achieve a continuous monitoring solution for the servers.

Figure 4: Single Server Overview References

References for this publication are listed below.

[1] Bartock MJ, Souppaya MP, Savino R, Knoll T, Shetty U, Cherfaoui M, Yeluri R, Malhotra A, Scarfone KA (2021) Hardware-Enabled Security: Enabling a Layered Approach to Platform Security for Cloud and Edge Computing Use Cases. (National Institute of Standards and Technology, Gaithersburg, MD), Draft NIST Interagency or Internal Report (IR) 8320. https://doi.org/10.6028/NIST.IR.8320-draft

[2] Souppaya MP, Scarfone KA, Morello J (2017) Application Container Security Guide. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-190. https://doi.org/10.6028/NIST.SP.800-190

[3] Bartock MJ, Souppaya MP, Yeluri R, Shetty U, Greene J, Orrin S, Prafullchandra H, McLeese J, Scarfone KA (2015) Trusted Geolocation in the Cloud: Proof of Concept Implementation. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 7904. https://doi.org/10.6028/NIST.IR.7904

[4] Greene J (2012) Intel Trusted Execution Technology: Hardware-based Technology for Enhancing Server Platform Security. (Intel Corporation). Available at http://www.intel.com/content/www/us/en/architecture-and-technology/trusted-execution- technology/trusted-execution-technology-security-paper.html

[5] AMI (2020) AMI TruE Trusted Environment. Available at https://ami.com/en/products/security-services-and-solutions/ami-true-trusted-environment/

[6] Joint Task Force (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 5. https://doi.org/10.6028/NIST.SP.800-53r5

[7] National Institute of Standards and Technology (2018) Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1. (National Institute of Standards and Technology, Gaithersburg, MD). https://doi.org/10.6028/NIST.CSWP.04162018 Appendix A—Hardware Architecture and Prerequisites

This appendix provides an overview of the high-level hardware architecture of the prototype implementation, as well as details on how Intel® platforms implement hardware modules and enhanced hardware-based security functions [4] .

A.1 High-Level Implementation Architecture

The prototype implementation network is a flat management network for the AMI components and Intel compute servers with a generic laptop to use as a workstation. The Intel servers utilize an overlay network for communication between the containers that run on top of them. Each Intel server has a socketed BIOS and Baseboard Management Controller (BMC) slot so that a BIOS and BMC chip could be flashed with AMI firmware and installed on the server. There are more technical details regarding the AMI components and Intel server configurations and installation in Appendices B and C. Table 2 displays the hostname and IP configuration of each system, and Figure 5 shows the logical network architecture of the implementation.

Table 2: System Hostnames and IP Configurations

Hostname Management IP Address BMC IP Address AMI-TruE 172.16.100.50 N/A AMI-HVS 172.16.100.51 N/A Purley1 172.16.100.61 172.16.100.161 Purley2 172.16.100.62 172.16.100.162 Purley3 172.16.100.63 172.16.100.163 Workstation 172.16.100.21 N/A

Figure 5: Logical Network Architecture of the Prototype Implementation

A.2 Intel Trusted Execution Technology (Intel TXT) & Trusted Platform Module (TPM)

Hardware-based root-of-trust, when coupled with an enabled BIOS, OS, and components, constitutes the foundation for a more secure computing platform. This secure platform ensures BIOS and OS integrity at boot from rootkits and other low-level attacks. It establishes the trustworthiness of the server and host platforms. There are three roots of trust in a trusted platform: RTM, RTR, and RTS. They are the foundational elements of a single platform. These are the system elements that must be trusted because misbehavior in these normally would not be detectable in the higher layers. In an Intel TXT-enabled platform the RTM is the Intel microcode: the Core-RTM (CRTM). An RTM is the first component to send integrity-relevant information (measurements) to the RTS. Trust in this component is the basis for trust in all the other measurements. RTS contains the component identities (measurements) and other sensitive information. A trusted platform module (TPM) provides the RTS and RTR capabilities in a trusted computing platform. Intel Trusted Execution Technology (Intel TXT) is the RTM, and it is a mechanism to enable visibility, trust, and control in the cloud. Intel TXT is a set of enhanced hardware components designed to protect sensitive information from software-based attacks. Intel TXT features include capabilities in the microprocessor, chipset, I/O subsystems, and other platform components. When coupled with an enabled OS and enabled applications, these capabilities provide confidentiality and integrity of data in the face of increasingly hostile environments. Intel TXT incorporates a number of secure processing innovations, including:
• Protected execution: Lets applications run in isolated environments so that no unauthorized software on the platform can observe or tamper with the operational information. Each of these isolated environments executes with the use of dedicated resources managed by the platform.
• Sealed storage: Provides the ability to encrypt and store keys, data, and other sensitive information within the hardware. This can only be decrypted by the same environment that encrypted it.
• Attestation: Enables a system to provide assurance that the protected environment has been correctly invoked and to take a measurement of the software running in the protected space. This is achieved by the attestation process defined in Section 3.1 . The information exchanged during this process is known as the attestation identity key credential and is used to establish mutual trust between parties.
• Protected launch: Provides the controlled launch and registration of critical system software components in a protected execution environment.

Intel Xeon® Platinum Scalable processor series and the previous generation Xeon Processor E3, Xeon Processor E5, and Xeon Processor E7 series processors support Intel TXT.

Intel TXT works through the creation of a measured launch environment (MLE) enabling an accurate comparison of all the critical elements of the launch environment against a known good source. Intel TXT creates a cryptographically unique identifier for each approved launch-enabled component and then provides a hardware-based enforcement mechanism to block the launch of any code that does not match or, alternately, indicate when an expected trusted launch has not happened through a process of secure remote attestation. In the latter case, when an attestation indicates that one or more measured components in the MLE do not match expectations, orchestration of workloads can be prevented on the suspect platform, even though the platform itself still launches. This hardware-based solution provides the foundation on which IT administrators can build trusted platform solutions to protect against aggressive software-based attacks and to better control their virtualized or cloud environments. For additional information on TXT and other RTM technologies, see NISTIR 8320, Hardware-Enabled Security: Enabling a Layered Approach to Platform Security for Cloud and Edge Computing Use Cases [1] . A.3 Attestation

There are two main considerations for use cases to be instantiated and delivered in a cloud:
• How would the entity needing this information know if a specific platform has Intel TXT enabled or if a specific server has a defined or compliant BIOS or OS running on it (i.e., can it be trusted)?
• Why should the entity requesting this information (which, in a cloud environment, could be a resource scheduler or orchestrator trying to schedule a service on a set of available nodes or servers) trust the response from the platform?

An attestation authority provides the definitive answers to these questions. Attestation provides cryptographic proof of compliance, utilizing the root of trust concept to provide actionable security controls by making the information from various roots of trust visible and usable by other entities. Figure 6 illustrates the attestation protocol providing the means for conveying measurements to the challenger. The endpoint attesting device must have a means of measuring the BIOS firmware, low-level device drivers, and OS and other measured components, and forwarding those measurements to the attestation authority. The attesting device must do this while protecting the integrity, authenticity, nonrepudiation, and in some cases, confidentiality of those measurements.

Figure 6: Remote Attestation Protocol

Here are the steps shown in Figure 6 for the remote attestation protocol: 1. The challenger, at the request of a requester, creates a non-predictable nonce (NC) and sends it to the attestation agent on the attesting node, along with the selected list of Platform Configuration Registers (PCRs). 2. The attestation agent sends that request to the TPM as a TPMQuoteRequest with the nonce and the PCR List.