TEE Flashcards

Question

TPM objects

Answer 1

These are the objects that are managed by the TPM: * **Primary keys**: **the TPM does never return the private value, so the private keys are inside the TPM, and it is not possible to extract them**. These keys can be recreated using the same parameters assuming that the primary seed has not been changed. So even if the private key is destroyed or lost, it can be recreated using the same seed and the same parameters. * **Keys and sealed data objects** (SDO): they are protected by a Storage Parent Key (SPK). The SPK is needed in the TPM to load or create a key or SDO. Randomness for these keys come from the TPM RNG which is internal to the TPM. The TPM returns the private part of these keys protected by the SPK, so the private part needs to be stored externally somewhere, but then it is needed the TPM, that SPK to decrypt it.

Answer 2

* **Public Area**: it is used to uniquely identify an object and it is accessible even without special permissions, allowing the listing of objects stored inside the TPM. * **Private Area**: contains the object’s secrets. It exists only inside the TPM, ensuring high security. * **Sensitive Area**: it represents an encrypted private area used for storage outside the TPM. This area is optional and not mandatory. * Public Area and Private Area: These are **mandatory** and reside within the TPM. * Sensitive Area: This is external to the TPM and optional, meaning it is not required for all objects.

Answer 3

The Trusted Platform Module (TPM) has the ability to report the current state of the system using a special set of registers called **Platform Configuration Registers** (PCRs), that are fundamental to the TPM’s implementation of the Root of Trust for Storage (RTS) and serve as the primary mechanism for recording platform integrity. Security features: * **Reset Mechanism**: PCRs can only be reset during a platform reset (e.g., after a system reboot) or via a **hardware signal that requires physical access**. When reset, all PCR values are initialized to 0. This prevents malicious code from modifying measurements or rolling back the PCR values once they have been updated. * **Extend Operation**: PCRs have an operation called EXTEND. This operation updates the PCR value by **concatenating the current PCR value with the digest of new data**, then hashing the result. Formally, this operation is defined as: `PCR_new = hash(PCR_old || digest_of_new_data)` The EXTEND operation ensures that the PCR value accumulates a **sequential history of all measurements**, making it impossible to overwrite or alter individual entries. Importantly, the operation is non-commutative, meaning that **the order of measurements affects the final value**.

Answer 4

The process involves several stages, where each step measures the integrity of the next and records the results in the Platform Configuration Registers (PCRs). Here is a description of how Measured Boot operates: 1. The **first stage of the boot loader, which is assumed to be trusted, constitutes the Core Root for Measurement**. Its hash value is computed and stored in the PCR. This forms the initial measurement of the system’s integrity. 2. The first stage boot loader then measures the second stage boot loader (e.g., UEFI/BIOS) by computing its hash. After taking this measurement, it loads and executes the second stage boot loader. The hash of this measurement is extended into the PCR using the EXTEND operation. 3. The second stage boot loader measures the operating system before loading and executing it. The new measurement is extended into the PCR. 4. Optionally, the operating system itself can be modified to continue this process. When the OS starts an application, it measures the application, computes its hash, and extends the value into the PCR. This can create a complete record of everything executed on the system, forming a history of all measurements in the PCR.

Answer 5

In remote attestation, there is a platform with the TPM and an external verifier, typically remote (via a network). The process proceeds as follows: 1. When the verifier wants to determine if the platform is in a trustworthy state, it sends a challenge (a nonce to avoid replay attacks) to the platform. 2. In response to the challenge, the TPM reads all the values present in the PCRs. This **list of values is digitally signed using the TPM’s Device Identifier** (DevID). This ensures that the values have not been tampered with, the response is unique to this specific TPM and this specific challenge, replay attacks are prevented because the response depends on the challenge, which is a nonce. 3. The external verifier performs validation in two steps: (1) Signature Validation: The verifier validates the signature cryptographically using the device’s identifier (DevID). (2) Measurement Comparison: The verifier compares the reported PCR values against Reference Measurements, also known as **golden values**. These reference values represent the **expected state of the platform**, including the software executed and the sequence in which it was executed.

Answer 6

The first decision in remote attestation is whether to perform **static** attestation, focusing **only on boot processes**, or **dynamic** attestation, which involves **periodic checks during runtime**. The choice depends on the attack model: * **Static Attestation**: Suitable for systems targeting **static threats** and the system is verified only once, during startup. * **Dynamic Attestation**: Necessary for environments where **runtime vulnerabilities exist**, in such cases, periodic checks are essential. For dynamic attestation, the **frequency** of checks becomes critical. Periodic checks introduce the following considerations: * **Speed of Attack**: The periodicity must match the potential attack window. For example, checking once an hour may leave the system vulnerable during that interval. * **Physical and Performance Constraints**: The attestation cycle involves generating a nonce, extracting PCR values, signing them, transmitting results, and performing a database lookup. Among these, the TPM’s cryptographic signature operation is typically the slowest step due to hardware limitations. Current implementations support checks as frequently as every five seconds, which balances security and system constraints for many use cases. **Managing golden values** (reference measurements) is a significant challenge in remote attestation, particularly in dynamic and complex environments. Some key points include: * **Whitelist Generation**: For general-purpose systems like clouds, generating a comprehensive whitelist is challenging because it requires enumerating all possible software components and configurations. Conversely, this is more manageable in limited environments such as IoT devices, edge devices, SDN (Software Defined Networks), or NFV (Network Function Virtualization). * **Labeling**: Maintaining a labeled database of golden values can improve management. Labels such as **good, old, buggy**, and **vulnerable** help administrators make informed decisions. In addition to measuring software components, **remote attestation should consider system configurations**. Configurations can originate from various sources: * **File-Based Configurations**: These are easier to measure because the TPM can compute a hash of the configuration file contents. For example, an iptables configuration file can be measured when iptables is loaded. * **Memory-Based Configurations**: These are more challenging as they depend on platform-specific implementations. For example, a router configured via NETCONF stores its configuration in memory, making file-based measurement infeasible. Addressing this requires memory inspection tools that can extract and hash in-memory configuration states for verification.

Answer 7

* PCR0 is measuring the Platform firmware from system board ROM and it is a fixed value given one version of the firmware. Typically, in a database there are different values for PCR0 according to the version of the firmware and the version running in a device could be deduced by these values. It also stores the UEFI boot services, UEFI runtime services. * PCR1 contains the hash of various extensions of the firmware (ACPI, SMBIOS, OTHER). * PCR2 drivers loaded from the disk. * PCR4 is the part of the UEFI OS loader and of the Legacy OS Loader * PCR5 is for the Platform hardware, for example it is reading and computing the hash of the partition table. That is important if someone manipulated the hardware. * PCR7 contains the Policy for Secure Boot. * All registers from PCR8 to above are given to the OS to decide what will be used for.

Answer 8

IMA is **Integrity Measurement Architecture**, is an additional **component inside Linux** which extends the Root of Trust to the applications (extends attestation to dynamic execution) and perform various **operations**: * **Collect**: **Every time the kernel is invoked for accessing a file** (exec,read, write... system call), **the IMA measures the binary before running it**. * **Store**: After measuring, IMA stores the value in one of the PCRs (typically **PCRs 8 to 15**). The **measurement is added to a kernel-resident list**, and the corresponding IMA PCR is extended with the new value. * **Appraise** (Optional): IMA can optionally enforce local validation of a measurement against a good value stored in an extended attribute of the file. Certain Linux file systems allow files to have extended attributes in addition to standard ones (e.g., owner, group, permissions). If this feature is enabled: – The good value (expected hash) is stored in the file’s extended attributes. – When the binary is executed, its hash is compared against the stored value. – If the hashes do not match, the binary will not be executed. This ensures that binaries and their expected values are not altered. – However, this approach relies on trust that the extended attributes themselves have not been modified. * **Protect**: IMA protects a file’s security extended attributes (including the appraisal hash) against offline attacks. For instance: – An attacker could unplug the disk, attach it to another machine, and modify the hash values stored in the extended attributes. – To counter such attacks, IMA computes an HMAC over the attributes using a secret key. Without this key, an attacker cannot recompute the HMAC, and any tampering will result in a mismatch The measurement configuration of what IMA measures is determined by the IMA template, which defines the data structure for measurements. Most systems use the ima-ng template, but this can be customized as needed. All measurements performed by IMA are recorded in a file located at /sys/kernel/security/ima/ascii_runtime_measure This file resides in the kernel’s securityfs and contains a table summarizing the measurements. The table provides a human-readable format, listing each measured object and its corresponding hash values. The IMA measurement table provides detailed information about the components being executed and ex- tended into PCR10. The table includes entries showing the PCR number, the initial template-hash value, and subsequent updates made using the specified template. Each entry includes the filedata-hash value and the corresponding name filename-hint, which identifies the component. This table is crucial because, by examining only the value stored in PCR10, it is impossible to determine whether the value is correct or not. The table provides the necessary context, detailing which commands were executed and in what order. This information allows for precise verification of the measurements and ensures the integrity of the recorded data.

Answer 9

To verify the integrity of the system when IMA is enabled, the **attestation process includes not only the nonce and PCR values but also the Measurement List **(ML). Verifying **PCR10** is particularly challenging because its value **depends on two factors**: (A) the **applications** executed and (B) the **order** of their execution. To determine whether the returned PCR10 value is correct, the following steps are performed: 1. Start with an initial **PCR10** value of **0** in the verifier (representing the reset state). 2. Extend the **boot_aggregate** value, which is derived from the **concatenation of PCRs 0 through 7**. This value is added to the verifier’s **PCR10** using the same EXTEND operation performed by the TPM. 3. **Process each measurement m of a component c from the Measurement List (ML) in the same order as they were performed on the system**: * If the measure of component c **differs** from its golden value, raise an **alarm**. This indicates that either the component is not permitted or has been manipulated, compromising the system integrity. * If the measure **matches** the golden value, **extend** PCR10 in the verifier with the measure of c. This operation simulates the actual TPM EXTEND operation but is performed in the verifier’s memory. 4. Continue processing all measurements in the list. **Once the entire list has been scanned and processed, compare the verifier’s PCR10 value with the PCR10 value returned in the attestation response from the system**. * If the values match, the system is verified as intact. * If the values differ, raise an alarm, as this indicates tampering at some point in the boot, OS, or application execution process. This approach allows comprehensive attestation, covering all system components from the boot process to the operating system, including applications and file-based configurations. By re-performing the EXTEND operations in memory, the verifier can accurately validate the integrity of the system.

Answer 10

To mitigate these risks, efforts can be made to improve confidence in the TCB through techniques such as: * **Static Verification**: Analyzing the source code to identify potential issues. * **Code Inspection**: Manually reviewing the code for correctness. * **Testing**: Running tests to validate the behavior of the TCB. * **Formal Methods**: Using mathematical approaches to prove the correctness of the TCB. * While these methods can be effective, they are also **expensive and time-consuming**. Therefore, reducing the complexity of the TCB remains a critical objective in modern systems. The TPM attempts to create the TCB via Core Root of Trust for Measurement (CRTM), which serves as a foundation for trusted measurements. However, even with this approach, the TCB has become too large and too dynamic, leading to additional complications: * The increasing number of components results in a growing list of expected measurements, making it difficult to maintain an accurate set of golden values. * Variability between systems means that two computational nodes, even if perfectly fine, can produce very different measurements due to differences in their configurations, environments, or execution orders.

Answer 11

A Dynamic Root of Trust for Measurement (DRTM) was **introduced to address limitations of relying solely on secure boot**. Instead of trusting the entire process starting from the BIOS, **DRTM creates a new starting point for trusted measurements**. **Once Secure Boot completes**, ensuring that the initial components cannot be modified, **the system performs a reset and begins measuring components from that point**. The assumption is that the first stage is secure, and now measurements start from a new baseline. **Since TPM version 1.2, a set of dynamic PCRs (PCRs 17 to 23) was added to support this process**. These dynamic PCRs differ from the standard PCRs (0 to 15) in several ways: * Dynamic PCRs (17-23) are **initialized to -1 at boot**, whereas other PCRs are initialized to 0. This distinction highlights their different purpose. * Dynamic PCRs (17-23) **can be reset to 0 by the operating system, unlike standard PCRs**, which can only be reset by a hardware reset. * **PCR 17**, the first dynamic PCR, is special because its value **can only be set using a specific hardware instruction**: – SKINIT for AMD systems with virtualization. – SENTER for Intel systems using Intel TXT (Trusted Execution Technology). These hardware instructions have the same effect regardless of the architecture. They disable Direct Memory Access (DMA), interrupts, and debugging modes, ensuring that the program executing the instruction is the only active process on the system. This isolation guarantees that no other process can access memory, interrupt execution, or trace/debug the operation. The program executing these instructions measures the secure loader block and transfers control to it. This creates a new Dynamic Root of Trust for Measurement (DRTM). The DRTM ensures that the secure loader block and the memory region it operates on are measured and verified before execution. After stopping all processing on the platform via the special processor commands (SKINIT, SENTER), the DRTM hashes the content of the specific memory regions and stores the measurements are then stored in the dynamic PCRs. The secure loader block continues the process, transferring control to a specific memory location. **This process is referred to as a late launch**, as it occurs after the normal system launch. The late launch addresses challenges such as: * **Firmware Updates**: When the firmware is updated, PCR values change, causing issues with sealing operations. Sealing requires the exact system state to unseal data, meaning any firmware update would prevent access to sealed data, even if the update is legitimate. * **Sealing After DRTM**: By sealing data against the operational state established after the DRTM, rather than the initial firmware measurements, this issue is mitigated. Sealing is tied to a dynamic and operational state, ensuring compatibility after updates.

Answer 12

Originally, the Dynamic Root of Trust for Measurement (DRTM) was intended to allow the loading of hypervisors. A hypervisor is the software layer responsible for creating and managing virtual machines (VMs). Once the hypervisor is loaded, it isolates and manages the virtual machines. The **TPM attests to the integrity of the hypervisor**, as it is the first software layer loaded. TPM sealed storage is designed to release its protected memory only to a properly loaded and unaltered hypervisor. This ensures that: * **Data is sealed against the hypervisor, meaning it is accessible only if the correct hypervisor is executed without modifications**. * Protected memory, often needed for specific virtual machines, is released to the hypervisor when these conditions are met. * When saving the state of a virtual machine, this state is sealed against the TPM to ensure its integrity and confidentiality. This approach makes DRTM particularly useful for cloud computing, which heavily relies on virtualization technologies. However, there are significant challenges with this model. Hypervisors such as Xen and VMware ESX consist of a massive amount of code, often comparable to a full Linux distribution. Xen, for instance, includes a complete copy of Linux, while VMware ESX has a similarly large codebase. This is problematic because the Trusted Computing Base (TCB) is intended to be as small as possible to reduce the risk of vulnerabilities.

Answer 13

Addressing the challenges of remote attestation and measurements in virtualized environments introduces new complexities. While a hardware root of trust is fundamental for ensuring security, virtualization creates complications. **In full virtualization, such as virtual machines (VMs), the root of trust is often implemented as a Virtual TPM (vTPM) which is only a software emulation of a TPM and lacks the hardware protection of a Physical TPM (pTPM). ** This distinction is critical: * A vTPM, being software-based, is susceptible to attacks. * A single pTPM can typically support only one machine, making it impractical for environments with multiple virtual machines. To bridge this gap, a **strong link between the vTPM and the pTPM is required**. This concept is referred to as deep attestation, which ensures that: * The **vTPM is validated by the pTPM**, creating a trusted connection to real hardware. * **Sealed objects can be stored in the pTPM to protect the vTPM**. Additionally, major cloud providers, such as Amazon, Google, and Microsoft, often rely solely on vTPMs and claim equivalence to pTPMs. However, this equivalence does not provide the same level of security, as vTPMs lack hardware protection. **Ligth Virtualization as an Alternative** An alternative to full virtualization is the use of **containers**, such as those provided by Docker. Containers operate differently: * The host operating system (OS) runs directly on the physical hardware and interacts with the pTPM. * Containers do not require a separate virtualization layer. Instead, they rely on the host OS to manage resources and operations. * **Separation between containers is achieved through namespaces**, such as: – Storage namespaces for isolating storage. – Networking namespaces for isolating network operations. * **Despite appearing as virtual resources, all operations in containers are mapped to the host OS, which interacts directly with the pTPM**. This approach offers significant advantages for attestation: * The host OS, regardless of the number of containers, is the single entity interacting with the PTPM. * This simplifies attestation, as the operations are not affected by a separate virtualization layer.

Answer 14

This approach is generic and not tied to a specific containerization technology. The **key point** is that **containers are executed on a host in contact with the physical hardware**. This solution is transparent to the container runtime and containerized workloads, enabling the **remote attestation of** two essential components: * **The Host**: The host must always be attested first. If the base layer is compromised, the security of everything running on it is invalidated. * **Containers**: Once the host is verified, any or all containers can be attested as needed. The **remote attestation of host + containers is based on hardware RoT**. The architecture consists of the following key elements: * A **hardware root of trust**. * An **attestation agent**. * A **virtualization layer** for container-based workloads. **Within the virtualization layer, every operation is labeled to specify its execution environment**. For example: * If an operation is executed on the host, it is labeled as such. * If an operation is executed inside a container, it is labeled with the specific container’s identifier (e.g., container 1, container 2, container 3). This **labeling is possible because all operations**, even those appearing to be executed in containers, are **ultimately handled by the host operating system**. The **verification** process involves several steps: 1. The verifier sends an attestation request containing a nonce. 2. The attestation response includes: The measurement list, The nonce, The PCR values, all signed by the physical TPM. 3. The verifier performs the following checks sequentially: (a) **Verify TPM authenticity**: Check the digital signature and certificate to ensure it matches the expected node. (b) **Validate TPM quote**: Ensure the signature corresponds to the values inside the response. (c) **Check trusted boot PCRs**: Confirm that PCRs related to the trusted boot have the correct values. (d) **Validate the IMA measurement list**: Compare all values in the measurement list againstgolden values. (e) **Verify the host OS**: Ensure the host operating system part is correct. (f) **Verify containers**

Answer 15

Each TPM contains a pre-generated key called the **Endorsement Key** (EK). This key is **created by the TPM vendor** and accompanied by a certificate signed by the vendor, verifying that the TPM is genuine and was man- ufactured by a trusted source. The EK and its certificate serve as the root of trust, proving the authenticity of the hardware. When a TPM is incorporated into a device, such as a computer or server, the OEM (Other Equipment Manufacturer) generates an **Initial Device Identifier** (IDevID). This new key is based on the Endorsement Key (EK) and the endorsement certificate provided by the TPM vendor. The **IDevID is signed by the OEM** and provides a new identity for the device. It proves that the device itself (not just the TPM) was created and configured by a trusted manufacturer. When the device is deployed into a specific environment (e.g., a corporate infrastructure), a **Local Device Identifier** (LDevID) is created. The LDevID is based on the IDevID and the OEM certificate and is signed by the customer (e.g., the IT operator or system owner). * Provides a unique identifier for the device within the network infrastructure. The **LDevID ensures privacy and prevents tracking**, as there is no way to trace: * The LDevID back to the IDevID. * The IDevID back to the Endorsement Key (EK). This separation preserves privacy while maintaining a secure chain of trust. This is the chain of trust: **the initial certification tells that it is a genuine TPM really created by that manufacturer, the second certification tells that it is a genuine device and finally the third certificate says that the device is a registered component of a certain infrastructure and avoid being traced the LDevID will be used in all network operations**. There is no possibility to go from the LDevID to the IdevID and from the IDevID to the EK.

Answer 16

The process involves interaction between the TPM, the host platform, and a Certificate Authority (CA): 1. The TPM’s host platform instruct the TPM to create a key. 2. The TPM generates the key and provides the public part of the requested key to the host platform. 3. The host platform sends the following to the Certificate Authority (CA): the newly created public key, the TPM Endorsement Credential, which proves the authenticity of the TPM. 4. The CA verifies the endorsement credential and creates a certificate for the new key. The certificate is encrypted using the TPM’s Endorsement Key (EK). The encryption serves as a mechanism to verify that the TPM indeed possesses the EK, as by decrypting the certificate there’s proof of possession of the EK. 5. The encrypted certificate is sent back to the TPM, which checks if it can decrypt and certify the new key using its EK. If successful, this proves the TPM’s ownership of the Endorsement Key. 6. Finally, the TPM returns the verified certificate to the TPM’s host platform. This step constitutes **Proof of Possession** (POP), as the certificate is provided to an entity that can demonstrate ownership of the corresponding key. In this procedure, there is **no signature performed during the certificate request phase**. This **differs from typical processes like PKCS#10**. Here, the operation with the private key occurs during the distribution of the certificate.

Answer 17

When using the TPM, authorization mechanisms are required to execute commands securely. * **Direct Password-Based Authorization**: The simplest form of authorization involves providing a **password when issuing a command to the TPM**. However, this method presents a significant risk if an attacker is able to sniff commands, for example, on the bus of a personal computer. * **password-based HMAC Authorization**: A more secure alternative is to use HMAC authentication for commands and responses. HMAC-based authorization ensures that: – Even if the internal bus is compromised, no useful information can be extracted by sniffing commands. – Nonces are used to protect against replay attacks: ∗ A caller_nonce is included in the request. ∗ A TPM_nonce is returned in the response. This approach significantly improves security, especially when the platform’s internals are at risk of compromise. While basic mechanisms address authentication, additional authorization policies can be configured to en- force specific conditions before an object can be used, since the TPM knows a lot about the platform states. These advanced features include: * PCR-Based Authorization: even if the password is known or if an HMAC command is received, if the PCRs have not the specific values the operation will not be performed. * Time-Limited Authorization: Object usage can be prevented to a specific timeframe, e.g., valid for only two days. * Multi-Entity Authorization: For highly secure operations, authorization may require approval from multiple entities. Examples include: Requiring two individuals to input their passwords. Using a command that requires double HMAC, where the HMAC is computed using two separate passwords.

Answer 18

Attestation is increasingly recognized as a vital mechanism for analyzing and validating the behavior of mod- ern systems. This need is particularly pronounced as computational intelligence shifts away from centralized infrastructures to edge nodes and distributed networks. In this evolving landscape, it becomes imperative to ensure that systems function as intended and that any anomalies can be thoroughly investigated. In today’s interconnected systems, behaviors of nodes, such as IoT devices or Electronic Control Units (ECUs) in autonomous vehicles, can no longer be assumed to be reliable. The complexity of software, combined with potential vulnerabilities, makes it critical to validate both the state and actions of these nodes. As more intelligence and computational tasks move to edge environments, the challenges of ensuring correct behavior become even more significant. When something goes wrong, TPM is also good to perform audit and forensic analysis for understanding what occurred. For instance, if an autonomous vehicle crashes, it is vital to determine the system state at the time T of the incident. Was the software functioning as intended, or was the system compromised by malware? Attestation can provide the evidence needed.

Answer 19

To illustrate how attestation can be applied in practical scenarios, we refer to a European project, known as SHIELD. This project focused on security as a service (SAAS), which leverages Network Function Virtualization (NFV) and Software-Defined Networking (SDN) to create and manage specific virtualized security functions, such as firewalls, intrusion detection systems, and VPN channels. The project’s architecture consisted of the following key components: * **Software-Defined Network (SDN)/NFV Infrastructure**: This was the target platform for deploying the virtualized security functions. * **Orchestrator**: The vNSF orchestrator was responsible for deciding which security functions must be placed and where within the infrastructure. * **vNSF Store**: A repository of virtualized network security functions (vNSFs), which were software objects to be downloaded and deployed as needed. * **Security Dashboard**: Provided an interface for monitoring and managing the security state of the infrastructure, which could include intrusion detection systems or network monitoring tools. * **Trust Monitor**: This component used remote attestation to verify the integrity of the entire infrastructure. Since the infrastructure was software-based, the trust monitor ensured that nodes and their virtual functions were not compromised. * **Analysis and Remediation Module**: Reacted to any detected misconfigurations or integrity violations. The **trust monitor** was the main component for attestation, receiving **inputs** from two main sources: 1. **The SDN/NFV Infrastructure**: This provided the **attestation results or measurements**. Periodically, the trust monitor queried each node in the infrastructure, asking for its current measurements to validate its state and the state of its deployed virtual functions. 2. The **vNSF Store**: This repository supplied the golden measurements. These values served as the benchmark for verifying the integrity of the infrastructure. The trust monitor compared the measurements from the infrastructure with the golden measurements from the vNSF store. If a mismatch was detected, indicating a possible integrity violation, the trust monitor triggered an alarm. This alarm was sent to the Analysis and Remediation Module, which analyzed the issue, identified the root cause, and initiated corrective actions to restore the system’s integrity.

Answer 20

One important thing (in SHIELD but also in general) is the golden value creation. The trust monitor is initially going to the vNSF store containing all the virtual network security function, requesting the manifest (the list of the elements inside that virtual function) and then the measurements are extracted from the manifest. If a measurement corresponds to a component already present in the database, it is skipped, as it has already been verified as authorized. However, if the measurement is new and not yet encountered in other vNSFs, the database is updated to include it. This database is often referred to as a **whitelist or accept list**, representing the set of components authorized to run on the system. In this way, the trust monitor dynamically maintains a record of trusted components, ensuring that only validated elements are executed within the infrastructure.

Answer 21

When a security function is deployed, the orchestrator initiates the process by requesting the attestation result for the host, referred to as the middle box. Before deploying a virtual network security function (vNSF), the trust monitor verifies the integrity of the host by checking its current state. This includes validating the operating system, container runtime, and other essential components to ensure that the box is in a secure state. Upon receiving this request, the trust monitor performs a remote attestation by sending a nonce to the designated host. The host then provides a TPM quote along with the event log as proof of its current state. If the attestation proof matches the expected values, the trust monitor sends an attestation success response to the orchestrator, allowing the inclusion of the middle box in the network. If the attestation fails, the trust monitor reports the failure, isolates the compromised node, and raises an alarm for the security manager to investigate the issue. The compromised node is excluded from further orchestration processes to ensure the integrity of the infrastructure.

Answer 22

Periodic attestation is performed automatically by the trust monitor at intervals determined by the manager, based on the speed of the attack. The periodicity can range from 10 seconds to 30 seconds or up to one minute, with typical intervals being in the order of minutes, rather than hours. During each cycle, the trust monitor requests the network state from the vNSF orchestrator. The network state provides information on the nodes currently involved in executing the security functions. This approach avoids the need to attest the entire network and focuses on the specific nodes relevant to the protection being provided. This information is retrieved from the orchestrator. For each middle box in the subnetwork, the trust monitor requests a remote attestation proof from the deployed security function. Each middle box responds with its TPM quote and event log, which are then verified against expected values. If an attestation fails, the security dashboard issues a notification, highlighting the issue within the network. In such cases, decisions regarding the compromised node can include terminating, excluding, or reconfiguring it. Although artificial intelligence could be employed to automate these decisions, the preferred approach involves maintaining a human in the loop for final decision-making. The system generates an alarm, allowing the operator to decide the most appropriate course of action.

TEE Flashcards

(52 cards)