May 28, 2019 Installs the Intel® Trusted Execution Engine (Intel® TXE) driver and firmware. The Intel TXE driver is required for Secure Boot and platform security features. Not sure if this is the right driver for your Intel NUC? Run Intel® Driver & Support Assistant to automatically detect driver updates. Installs the Intel® Trusted Execution Engine (Intel® TXE) driver and firmware for Windows® 10, Windows 8.1. and Windows 7. The Intel TXE driver is required for Secure Boot and platform security features. Not sure if this is the right driver for your Intel NUC? Run Intel® Driver & Support Assistant to automatically detect driver updates. Ubuntu (starting with version 10.10 with kernel 2.6.35) Xen Virtual Machine Monitor (starting with version 3.4) 4.2.3 VMware ESXi 4.1 and 5.x. To implement Intel TXT on VMware ESXi, follow the procedure given below that is appropriate to the version of the environment in use.
Hi Curt, Greg is here (an Independent advisor).
If you specifically refer to Windows 10 OS, my answer is “no” because this driver is not part of the OS. But TXE driver is installed by the system manufacturer in Intel NUC devices because it is required for secure boot and platform security features. If you want to check if TXE installed on your machine, follow the steps: > Right click on Windows logo > Tap on Device Manager > Try to find the Intel(R) Trusted Execution Engine under System devices, if it is there, the driver is installed on your PC. If you need further information, refer to the article: Intel:registered: Trusted Execution Engine (Intel:registered: TXE) Driver for Intel:registered: NUC devices > https://www.intel.com/content/www/us/en/support.. Note: This is a non-Microsoft website. The page appears to be providing accurate, safe information. Watch out for ads on the site that may advertise products frequently classified as a PUP (Potentially Unwanted Products). Thoroughly research any product advertised on the site before you decide to download and install it.
Intel® Trusted Execution Engine (Intel® TXE) Intel® Server Platform Services (SPS) Intel has identified security vulnerabilities that could potentially impact certain PCs, servers, and IoT platforms. Systems using Intel ME Firmware versions 6.x-11.x, servers using SPS Firmware version 4.0, and systems using TXE version 3.0 are impacted. Intel Trusted Execution Technology (Intel TXT, formerly known as LaGrande Technology) is a computer hardware technology whose primary goals are: Attestation of the authenticity of a platform and its operating system. Assuring that an authentic operating system starts in a trusted environment, which can then be considered trusted. Mine is acer aspire es1-411-c32x.I installed windows 10 pro.Intel TXE: Intel Trusted Execution Engine driver can not install on my laptop. I tried possible ways. Including kmdf version 1.11.does not work.w10 shipped with kmdf v1.15. But i can not install kmdf 1.11 on my laptop.how can I solve this. Please guide me.
By David Mulnix, published on March 28, 2014, updated January 21, 2015
This is a computer translation of the original content. It is provided for general information only and should not be relied upon as complete or accurate.
Sorry, we can't translate this content right now, please try again later.
Contents
Revision History
1 Overview of Benefits from Intel® Trusted Execution Technology (Intel® TXT)
Intel TXT is the hardware basis for mechanisms that validate platform trustworthiness during boot and launch, which enables reliable evaluation of the computing platform and its protection level. Intel TXT is compact and difficult to defeat or subvert, and it allows for flexibility and extensibility to verify the integrity of platform components during boot and launch, including BIOS, operating system loader, and hypervisor. Because of the escalating sophistication of malicious threats, mainstream organizations must employ ever-more stringent security requirements and scrutinize every aspect of the execution environment.
Intel TXT reduces the overall attack surface for both individual systems and compute pools. The technology provides a signature that represents the state of an intact system’s launch environment. The corresponding signature at the time of future launches can then be compared against that known-good state to verify a trusted software launch, to execute system software, and to ensure that cloud infrastructure as a service (IaaS) has not been tampered with. Security policies based on a trusted platform or pool status can then be set to restrict (or allow) the deployment or redeployment of virtual machines (VMs) and data to trusted platforms with known security profiles. Rather than relying on the detection of malware, Intel TXT builds trust into a known software environment and thus ensures that the software being executed hasn’t been compromised. This advances security to address key stealth attack mechanisms used to gain access to parts of the data center in order to access or compromise information. Intel TXT works with Intel® Virtualization Technology (Intel® VT) to create a trusted, isolated environment for VMs.
Figure 1 is a simplified diagram of Intel TXT stages and components. Later sections of this document describe the hardware and software requirements associated with Intel TXT in greater detail.
Figure 1. Simplified Intel® TXT component diagram.
Intel TXT must be enabled at multiple levels, including hardware, BIOS, OS, and hypervisor. Attestation and cloud-management software work with those components to enable management and reporting for the trusted system environment.
2 Hardware and Software Prerequisites
To create a trusted environment and enable the management layer within it, certain hardware and software requirements must be met. The following discussion summarizes, at a high level, the components that must be present and properly configured before management can be fully realized for a trusted platform, a trusted VM, or a group of trusted VMs. Figure 2 illustrates these requirements.
NOTE: To choose server platforms, operating environments, and hypervisors that support Intel TXT, please refer to the Intel® Trusted Execution Technology Server Platform Availability Matrix.[1] This document assumes the presence of supported hardware and software components, as defined in that matrix.
Figure 2. Component overview of a Measured Launch Environment (MLE).
2.1 Hardware-Layer Requirements
2.1.1 Processor
Server platforms in the measured launch environment must be based on the Intel® Xeon® processor, with support for Intel TXT and Intel VT-x (VMX and SMX). These features were introduced with the Intel Xeon processor 5600 series.
2.1.2 Chipset
A Trusted Platform Module (TPM) must be integrated with the chipset. The chipset and the TPM work together to ensure that the measurements and security properties of the system are not spoofed by untrusted components. TPMs are devices manufactured by various third-party silicon providers that attach to the chipset via the Low Pin Count (LPC) bus or Serial Peripheral Interface (SPI), and they provide a number of security functions. TPM capabilities and requirements are defined by the Trusted Computing Group (TCG)[2], an industry initiative “formed to develop, define and promote open, vendor-neutral, industry standards for trusted computing building blocks and software interfaces across multiple platforms.” TPM Details can be found in the main TPM specification[3].
An Intel chipset with Intel VT must be present to provide the isolation capabilities for the MLE (based on Intel VT-d and Intel VT-x).
2.1.3 BIOS
Intel TXT and the TPM must enabled within BIOS.
Authenticated Code Modules (ACMs) created and signed by Intel must be present inside the BIOS. The ACM contains platform-specific code which is authenticated to the chipset and executed in an isolated environment within the processor and the trusted environment (authenticated code mode), enabling the ACM to perform secure tasks.
2.2 Software-Layer Requirements
2.2.1 Operating System and Hypervisor
An MLE provides a software-verification process to attest that all of the critical components of the pre-OS launch environment have been verified against a known good source, ensuring a secure chain of custody from the moment a system is powered on until the system kernel or hypervisor takes control. An Intel TXT-aware hypervisor provides isolation for host OSs and applications. To identify operating environments and hypervisors that support Intel TXT, please refer to the Intel® Trusted Execution Technology Server Platform Availability Matrix[4].
3 Measured Launch Environment and Trusted Launch Sequence3.1 Measuring and Validating the Environment
The primary goal of using Intel TXT is to validate that there have been no unauthorized changes to critical parts of the code that provides the secure environment. This check is performed each time the environment launches, whether it is a cold boot, warm boot, or exiting one hypervisor and launching a new one.
3.2 Measured Launch Environment (MLE)
The MLE includes the following components:
A successful measured launch requires that the ACM is valid, the server platform (as measured by the BIOS) has passed the launch control policy, and the MLE code measurement has passed the launch control policy.
These components are measured by creating an SHA-1 hash of the component and validating that hash against a set of securely stored values. Adding launch control policy assures that OS/hypervisor execution is allowed to continue if and only if the policy is satisfied. Policy consists of the platform owner specifying the minimum version of ACM, platform configuration as measured by Platform Configuration Registers (PCRs) 0-7 in the TPM containing known good values, and the MLE measurement being a known good value.
3.2.1 Measured Launch Phases
To better understand the role of the OS/hypervisor and the corresponding role of the developer, consider the platform phases associated with measured launch, which are illustrated in Figure 3.
Figure 3. Measured launch timeline.
The phases are as follows:
3.2.2 Platform Configuration Registers (PCRs)
PCRs are registers dedicated to the TPM , which capture measured information about the platform during the boot sequence. Descriptions of the types of content stored in each PCR are summarized in Table 1.
Table 1. Contents stored in various PCRs.
4 Implementing Intel® TXT on Supported Hardware and Software
The steps defined in this section can be used to set up Intel TXT functionality on a supported system, as defined in the “Hardware and Software Prerequisites” section of this document and the Intel® Trusted Execution Technology Server Platform Availability Matrix[5].
4.1 Hardware Deployment Process (BIOS)
Before the rest of the implementation can be accomplished, the TPM and Intel TXT must both be enabled in BIOS. Typically, the TPM must be enabled before enabling Intel TXT, and the entire process often requires a few reboots to accomplish, as illustrated in the following example:
The following blog posts give specific examples on Dell and IBM servers:
4.2 Software Deployment Process
Deploying Intel TXT at the OS or virtual manager level requires different steps depending on which software vendor you are using.
4.2.1 Linux* Open Source
The steps given in this section cover installation of an open source tBoot solution under the following:
TrouSerS and trousers-devel packages must be installed in order to build the Intel TXT Launch Control Policy lcptools sub-project.
You must install a module that is able to verify that the platform hardware is running in an MLE before the OS loads.
Trusted Boot (tBoot) is an open-source, pre-kernel/hypervisor module that uses Intel TXT to perform measured and verified launch of an OS kernel/hypervisor.
4.2.2 SUSE, Red Hat, Ubuntu*, and Xen
SUSE, Red Hat, and Ubuntu Linux distributions provide tBoot installation packages, which include detailed installation instructions with the readme file. Note that the steps are similar to the open source solution steps given above. Supported versions include the following:
4.2.3 VMware ESXi 4.1 and 5.x
To implement Intel TXT on VMware ESXi, follow the procedure given below that is appropriate to the version of the environment in use.
NOTE: This section draws from the Dell Tech Center article, “Enabling Intel TXT on Dell PowerEdge Servers with VMware ESXi[9].”
4.2.3.1 VMware ESXi 4.1 Update 1 through 4.1 Update 3
~# esxcfg-advcfg –k 1 /Misc/enableTboot
esxcfg-advcfg –g /Misc/enabletboot
4.2.3.2 VMware ESXi 5.x or later
bootOption –o
4.2.4 VMware, HyTrust, and VMotion*
For implementing Intel TXT on HyTrust and VMotion within a VMware environment, see the Intel® Cloud Builders Guide for Enhanced Cloud Security withHyTrust and VMware[10].
5 Trusted versus Untrusted Systems
It is beneficial to be able to identify and manage the trusted systems protected by Intel TXT within your environment. Insight into which systems are trusted and which are untrusted can be used to set up trusted lists or trusted pools. Those systems that are trusted can be assigned tasks that require higher security; this capability is particularly valuable in virtualized and cloud-based implementations.
For example, virtual environments allow migration of running VMs among physical hosts. Trusted systems can be grouped into trusted compute pools, to which policy can be applied to ensure that VMs are only migrated to trusted systems within the cloud. Figure 4 shows how VM migration can be controlled across resource pools, using trust as control instrumentation for migration policy. This approach enables IT managers to restrict confidential data or sensitive workloads to platforms that are well controlled and have had their configurations thoroughly evaluated with the aid of Intel TXT.
Figure 4. Migrating VMs among hosts while protecting data, using trusted compute pools enabled by Intel TXT.
6 Management of Trusted Systems with Use Cases
Software cloud-management solutions are available for various use cases, including policy and compliance enforcement, automation, auditing, reporting, workload migration, etc. Trusted compute pools can be combined with these solutions to enhance security.
This section discusses ecosystem solutions that address various use cases for trusted compute pools; the use cases themselves are discussed at greater length later in this document.
Figure 5 illustrates, at a high level, potential interactions between different management solutions and a trusted system or trusted VM.
Figure 5. Interaction between cloud-management software and trusted compute pools.
6.1 Policy Management
Security policy management software can set policies that dictate how trusted compute pools will be used. Examples include restricting or allowing VMs, sensitive workloads, or data migration based on platform security or trust profiles. A simplified approach for policy enforcement could include using the scheduler with an OpenStack solution, or even labeling sensitive workloads in a virtual cloud infrastructure. Third-party policy engines also specialize in the compliance requirements for specific business verticals with built-in policy templates to assist in implementation.
Intel does not endorse any particular software vendor (nor is this a comprehensive list), but software vendors that have policy engine solutions that work with Intel TXT-enabled systems include Hytrust[11], VMware[12], EMC[13], McAfee[14], Trapezoid[15], M2Mi[16], and Ubuntu[17].
The following use cases illustrate a few ways that a policy management solution can interact with Intel TXT-enabled systems.
6.1.1 Confidential Data and Sensitive Workloads
As already mentioned in this document, the ability to assign sensitive workloads or ensure that confidential data is only executed on trusted platforms or trusted VMs can have substantial benefits. Consider the case where a patient wants to access his or her detailed medical history. A web hosting server with a trusted status could display the information to the end user once they have logged on, but if the web hosting server was found to be on a non-trusted host, the policy engine could reduce functionality and prevent logins.
For an example of how to set up a filter using Open Attestation that can be used to schedule workloads on trusted compute pools, see Openstack Nova Scheduler[18]. This code sample will provide insight for those who wish to use an open source approach for this particular use case.
6.1.2 Integrity Checks
The first level of integrity checking occurs upon cold boot of a server with Intel TXT at the hardware layer and moves to the software layer. The MLE helps to insure the integrity of the server.
An additional layer of integrity checking can be implemented using Intel TXT; for example, one could periodically check for compromised hypervisors without interruption to business applications. This capability could enable faster detection of compromises, helping to contain the spread of malware and reduce the need to rebuild hypervisors if a compromise is detected.
Some of the advantages with this use case include the following:
The use case shown in Figure 6 employs live migration to move all VMs off each server within a cluster in turn, allowing the server to be restarted and an integrity check to be conducted without application downtime. This use case assumes that the servers in the cluster are Intel TXT-capable and enable a hypervisor to be launched securely.
Figure 6. Proposed use case: Integrity check in a virtualization server cluster.
For each server, the steps are as follows:
The use case should be a policy-driven, automated activity that can be scheduled to run at night or at other times of low activity. In a large cluster, several servers could execute the use case concurrently. With the appropriate ecosystem enabling for Intel TXT, this use case could significantly enhance security in a virtualized environment.
Another example of automating warm resets of a server within a cluster while maintaining redundancy to help maintain integrity is the Self Cleansing Intrusion Tolerance (SCIT)[19] research project at George Mason University. For more information, please see the research paper, “Closing Cluster Attack Windows through Server Redundancy and Rotations[20].”
6.1.3 Multi-tenancy
In cloud computing environments, workloads are migrated to available compute resources. In a secure cloud system, when workloads land on a single trusted server, they are segregated to avoid interfering with each other, gaining access to each other’s sensitive data, or otherwise compromising security or privacy. These properties can help make it more difficult to subvert multitenant environments. Strong security safeguards are imperative for cloud service providers that wish to attract new customers and workloads.
6.2 Security Information Event Management (SIEM)
SIEM software creates a general security control point that aggregates the real-time alerts, event information, and reports from various security applications and activities into a database that can be queried, including the status of trusted compute pools.
SIEM can assist with generating reports that can help automate gathering data used for compliance purposes, identifying patterns in event data and assisting with automated analysis of alerts and correlated events.
Intel does not endorse any particular software vendor (nor is this a comprehensive list), but software vendors that have SIEM solutions that work with Intel TXT-enabled systems include Hytrust[21], EMC[22], McAfee[23], and Trapezoid[24].
6.2.1 ODCA Provider Assurance
The ODCA Provider Assurance Usage Model[25] has certain security requirements that can be met more easily with a SIEM solution combined with a trusted compute pool.
For example, a company can verify at any given moment that medical data containing patient records is only accessible from systems within a trusted compute pool to help ensure compliance.
6.3 Governance, Risk, and Compliance (GRC)
GRC software produces specific audit and compliance reports, often utilizing the information gathered by an SIEM solution. Administrators can use this information to create new policies or to refine existing ones for use by the policy engine. The GRC software may also query the infrastructure to make sure policies are in place and active. Various solutions may specialize in the compliance requirements for specific business verticals, perhaps providing with built-in policy templates to help implementation.
A GRC platform combined with trusted compute pools can enable auditing information on a trusted platform or a trusted compute pool. This capability can help provide real-time or historical metrics, verifying that platforms are trusted as expected and that workload controls for trust and location are enforced.
When combined with trusted compute pools, GRC can make it easier to comply with specific data-access regulatory requirements such as PCI DSS[26], HIPAA[27], NERC-CIP[28], FISMA[29], GLBA[30], and SOX[31].
Intel does not endorse any particular software vendor (nor is this a comprehensive list), but software vendors that have GRC solutions that work with Intel TXT-enabled systems include Hytrust[32], EMC[33], RSA[34], Symantec[35], McAfee[36], and Trapezoid[37].
6.4 Geolocation / Asset Tagging
The MLE provides the ability to assign a secure geolocation tag to a non-volatile index in the TPM on the trusted server during the provisioning process. An Intel TXT-enabled hypervisor has the capability to insert or extend the contents of the tag into one of the PCRs in the TPM. Attestation or restful APIs can provide an interface to the geolocation tag information, including geolocation tag lookup and user-readable/presentable strings and descriptions that can be used for asset tagging. The benefits of utilizing this tag for geolocation or asset tagging are discussed in greater detail below.
6.4.1 Geolocation
Geolocation can help address security and regulatory compliance issues with workloads migrating within the cloud between servers in two different countries. Each country may have its own set of laws for data security, privacy, and other considerations. Because the requirements of these laws may conflict with an organization’s policies, it may be necessary to ensure that workloads use only cloud servers physically located in specific countries. This process involves determining the server’s location, which is known as geolocation.
A platform that is not trustworthy places the workload at risk of compromise and cannot provide assurance that the claimed geolocation of the cloud server is accurate. Geo-located platforms in which there is a hardware root of trust are aggregated into trusted compute pools, segregating them from untrusted resources and enabling trusted geolocation. This capability allows for enforcement of geolocation restrictions and auditing.
Some examples of regulatory compliance requirements that geolocation can help with include the following:
REST APIs can be used to retrieve information from the TPM, including geolocation information. Additional examples of REST APIs are available from virtualization vendors and the OpenStack: Open Attestation SDK[40].
An example of a JSON-based request for attestation and its response is shown in Figure 7. Geolocation enables IT to build a policy that avoids placement of workloads on systems outside approved locations. For more information on attestation, please see the “Attestation” section of this document.
Figure 7. Example of JSON-based request/response for attestation.
For use case implementation examples, please see the following resources:
6.4.2 Asset Tagging
Using an Intel TXT-enabled hypervisor to assign descriptive information into the contents of the geolocation tag that has been extended into one of the PCRs of the TPM provides an opportunity for asset tagging. Asset tagging can help with multi-tenant segregation or segregation of confidential data or sensitive workloads, as described elsewhere in this document. It can also assist with meeting regulatory compliance requirements, including PCI DSS[43] and HIPAA[44].
7 Attestation7.1 Attestation
Building on the security provided by Intel TXT attestation provides assurance that the protected environment is correctly invoked and measures the integrity of software running in the protected environment. The information exchanged during this process, which is known as the “attestation identity key credential,” is used to establish mutual trust between parties. Attestation is a foundational component for building trusted compute pools. Deploying attestation within your network requires at a minimum, an attestation server and an attestation client whose hardware and software provide protection within an MLE.
OpenAttestation is an open-source, Linux-based attestation solution that provides the ability to more readily identify MLE-protected systems.
Intel’s offering, the Intel Trust Attestation Solution (Enterprise Edition), uses APIs to provide ease of access to attestation. Additional benefits include auditing capabilities, automation for ease of deployment, integration with OpenStack, and productivity tools. Intel Trust Attestation Solution (Enterprise Edition) provides an off-the-shelf solution that integrates with OpenAttestation, making it easier for the end user to deploy Intel TXT expediently.
7.2 OpenAttestation (OAT)
The Trusted Computing Group has defined a series of specifications that define how a commercial computing platform can support code measurement in a trusted manner. Intel developed an OpenAttestation SDK, released to open source, that takes advantage of the Infrastructure Work Group Integrity Report Schema Specification[45].
The OpenAttestation SDK[46] supports web APIs for third-party software to integrate and access web-based attestation appraisals, in support of cloud usage models. The OpenAttestation SDK is intended to be merged, modified, and distributed as part of third-party software vendors’ cloud management stacks. Key features include the following:
7.2.1 Supported Software
OpenAttestation has currently been validated on Ubuntu 12.10 and Fedora 19.
7.2.2 General OAT Deployment Guidelines
Deploying OAT in a network environment requires a server running the OAT service, as well as MLE-protected systems running the OAT service.
Deploying OAT requires the following steps (please see the OpenAttestation documentation[47] for details):
These steps enable easier identification of the trustworthiness of hosts within the network environment using OAT. The OAT SDK is expected to be enhanced with security features and integrated into third-party cloud-management software, and then to be distributed by independent software vendors to cloud service providers.
7.2.3 Red Hat Fedora*-Specific OAT Deployment Guidelines
Please see the oVirt manual, “Trusted Compute Pools Deployment[49]” for guidelines on deploying OAT within a Red Hat Fedora environment.
7.2.4 OpenAttestation SDK
The OpenAttestation SDK[50] can be used to grow your own management solution from the ground up. Having the ability to communicate with trusted systems or trusted virtual machines via APIs or through a trust agent can be used for basic policy enforcement. Table 2 shows example service APIs, from the OpenAttestation SDK documentation.
Table 2. OpenAttestation service APIs.
The following sample query from the OpenAttestation SDK uses an API to retrieve a list of the hosts registered with OpenAttestation (OAT), based on the search criteria specified. If no search criteria are given, then either all the hosts are retrieved, or else only the specific hosts whose names match the criteria are retrieved.
Method Type: GET
Sample Call: https://Server_Name:8443/ AttestationService/resources/hosts?searchCriteria=192
Sample Output:
Intel Txe Firmware
7.2.5 Sample Code for Attestation
Some examples of sample code can be found in the Build and Install OpenAttestation (2.0)[51] documentation, such as adding detailed information to white lists. Broken angel mp3 song download.
For an example of how to set up a filter on Open Attestation that can be used to schedule workloads on trusted compute pools, see Openstack Nova Scheduler[52]. This could be used for use cases where confidential or sensitive workloads need to be isolated to a trusted compute pool.
7.3 Intel Trust Attestation Solution (Enterprise Edition)
The Intel Trust Attestation Solution (Enterprise Edition), code-named “Mount Wilson, is a multi-hypervisor, multi-device, Trust Attestation/Verification Solution, for servers, clients, network/storage, and embedded devices. It can be used by cloud resource schedulers, SIEMs, policy engines, and GRC tools for trust verification, remediation, reporting, and compliance. It can also be used by a trust broker for secure access to trusted services from trusted clients. For additional information on Intel Trust Attestation Solution (Enterprise Edition), contact your Intel Field Applications Engineer (FAE) or submit a request for more information[53].
7.3.1 Supported Software
The Intel Trust Attestation Solution (Enterprise Edition) assists the end user with PCR and module-based attestation/verification, starting with the following versions of software:
7.3.2 Architecture Overview
A high-level representation of the Intel Trust Attestation Solution (Enterprise Edition) architecture is shown in Figure 8.
Figure 8. Intel® Trust Attestation Solution (Enterprise Edition) architecture.
In addition to providing assistance with identifying MLE platforms by means of attestation, Intel Trust Attestation Solution (Enterprise Edition) uses RESTful API interfaces, providing policy-based trust definition by MLE/OS, white list definition and management, TrustQuery APIs, management and provisioning APIs, and reporting APIs.
Further security enhancements provide secure communications by means of the following:
7.3.3 Deploying Intel Trust Attestation Solution (Enterprise Edition)
Deployment requires a server running the Intel Trust Attestation Solution (Enterprise Edition), as well as MLE-protected systems running the Intel Trust Attestation Solution (Enterprise Edition) trust agent.
Deploying Intel Trust Attestation Solution (Enterprise Edition) requires the following steps:
For more detailed instructions on the deployment process, see Cloud Security and Infrastructure[54], by Raghuram Yeluri and Enrique Castro-Leon.
7.3.4 Intel Trust Attestation Solution (Enterprise Edition) Dashboard
Intel Trust Attestation Solution (Enterprise Edition) provides a web interface for ease of administration of trusted compute hosts, shown in Figure 9.
Figure 9. Intel Trust Attestation Solution (Enterprise Edition) dashboard.
The Trust Dashboard displays and refreshes the trust attestation of all registered hosts.
Controls on the dashboard include the following:
Additional benefits of the Intel Trust Attestation Solution (Enterprise Edition) Dashboard include the following:
8 Additional Resources9 Acknowledgements
The author would like to recognize the following individuals for their contributions to this document.
William Futral, Todd Christ, Uttam Shetty, Belinda Liviero, Steve Orrin, Quoc-Thai Le, Gang Wei, Michihiro Koyama, and Tracie Zenti
About the Author
David Mulnix is a software engineer and has been with Intel Corporation for over 15 years. His areas of focus have included software automation, server power and performance analysis, and cloud security.
Intel Txe Windows 10 2017
For more complete information about compiler optimizations, see our Optimization Notice.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |