Trusted Computing Group

The Trusted Computing Group was formed in 2003 to develop and support open industry specifications for trusted computing across multiple platform types. To enable open specification development, the group is incorporated, has a patent policy and provides industry advocacy programs, including marketing programs. Information on how to join the TCG can be found at www.trustedcomputinggroup.org/join_now/.

TCG has approximately 100 members from across computing, including component vendors, software developers, systems vendors and network and infrastructure companies. A complete list is online at www.trustedcomputinggroup.org/members.

Potential members can obtain a TCG Membership Agreement and related documents by completing the online request form here, www.trustedcomputinggroup.org/join_now/request_membership_information.

The web site contains additional information on the dues structure and membership benefits for each membership type at www.trustedcomputinggroup.org/join_now/.

The TCG specifications support privacy principles in a number of ways:

1.  The owner controls personalization.
2. The owner controls the trust relationship.
3. The system provides private object storage and digital signature capability.
4. Private personalization information is never exposed.
5. Owner keys are encrypted prior to transmission.

It is also important to know what the solutions are not:

1. They are not global identifiers.
2. They are not personalized before user interaction.
3. They are not fixed functions-they can be disabled permanently.
4. They are not controlled by others (only the owner controls them).

• Provide unique, unspoofable identity to the embedded system that incorporates a TPM.
• Participate in integrity measurement services upon the firmware and software in the embedded system and store the results of measurement for subsequent reporting.
• How will management of TPM-protected secrets be done in the embedded market?

In specific environments, narrower use cases will be considered, for example:

• More complex embedded systems may require trust services based on cryptographic material protected by a TPM.
• Communications among embedded systems may be protected using a VPN, and the TPMs involved in these communications may be used to protect authentication and encryption certificates required by the VPN.
• Privacy requirements due to handling of legally protected personal data, e.g., in medical applications.
• There may be circumstances in which an embedded device protects secrets as a service to a number of other devices.

Other use cases will be considered as well.

The primary purpose of the Embedded Systems Work Group is to facilitate the continued evolution of Trusted Computing as a source for security in these markets and to help facilitate the ecosystem to support the concepts of a hardware root of trust.

Microsoft BitLocker™ Drive Encryption is designed to make use of a Trusted Platform Module (TPM) 1.2 and the associated PC Client Specifications developed by TCG to protect critical system files and user data and to help ensure that a computer running Windows Vista has not been tampered with while the system was offline.

• IF-TNCCS, which specifies interoperability between the TNC Client (TNCC) and the TNC Server (TNCS);
• IF-T for Tunneled EAP Methods, which is the specification for support of various transports; and,
• IF-PEP for RADIUS, specifying a standard integration with Policy Enforcement Points (PEP).

These specifications are in addition to the existing TNC specifications - IF-IMC and IF-IMV, which provide standardized APIs for client plug-ins (IMCs) and server plug-ins (IMVs) to enable TNC functionality; and the TNC architecture specification - which were all published in May 2005. All TNC specifications are available free to anyone who wishes to download them from the TCG website, www.trustedcomputinggroup.org.

These specifications are intended to be used in the following manner:

• IF-TNCCS describes a standard method for the TNC Client (TNCC) and the TNC Server (TNCS) to exchange messages. Since the TNC architecture is layered, IF-TNCCS carries messages from IMCs to IMVs and vice versa. It also carries control messages between the TNCC and TNCS. IFTNCCS is transport-independent so it can be carried over a variety of transports.
• IF-T for Tunneled EAP Methods specifies how IF-TNCCS should be carried over Extensible Authentication Protocol (EAP) tunneled methods such as EAP-TTLS, EAP-FAST, and EAPPEAP.  Supporting these EAP methods allows the TNC architecture to work with a variety of network technologies that support EAP authentication: 802.1x, IKEv2, etc.
• IF-PEP for RADIUS specifies how to use the RADIUS protocol for communications between a Network Access Authority (NAA) - typically an AAA/RADIUS server - and a Policy Enforcement Point (PEP). IF-PEP is used to send network access decisions from the NAA to the PEP, enabling the PEP to enforce the access decisions on an endpoint's network traffic. The network access decision will trigger enforcement action by the PEP, such as allowing access, denying access, or granting limited access.

• Java Platform Binding to IF-IMC (integrity measurement collector) and IF-IMV (integrity measurement verifier)
• Support allowing each IMV to give a human-readable, localized reason string explaining itsrecommendation (in IF-IMV and IF-TNCCS)
• Support for VLAN-aware endpoints(in IF-PEP (policy enforcement point)

The main benefits of these features are:

• TNC client software can be deployed more quickly and easily since it can be dynamically downloaded over the network as Java code.
• TNC client and server software can be developed to run on any system that supports Java 2 Standard Edition version 1.4.2 or later.
• In case of problems, messages can be presented in the user's native language.
• Endpoints can employ multiple VLANs for applications like telephony.

As a result of making SOH part of TNC, customers benefit in several ways:

• Interoperability: Customers can now be assured of interoperability between Microsoft NAP and other TNC implementations.
• Choice: Customers can now choose from any of the wide array of products that support Microsoft NAP and TCG TNC based on customer needs.
• Compatibility: Network access control products will now be much more compatible, allowing customers to interconnect a wide range of network, client, and server components.
• Clarification: Customers who have been waiting for consolidation and clarification in the confusing maze of network access control architectures and standards can now proceed with deployments of NAP and TNC products, confident that they will interoperate.
• Single Client Agent: Computers running Windows Vista, Windows Server "Longhorn", and future versions of Windows XP include the NAP Agent component as part of the core operating system. The NAP Agent will be used for both NAP and TNC, greatly simplifying deployment of a network access control solution. To support client operating systems other than Windows, Microsoft will license elements of the NAP client technology that support both NAP and TCG TNC to third-party software developers.