Trusted Computing Group

Full Disk Encrypting (FDE) hard drives are available now that enable the functionality incorporated in the Specification, with the encrypting hardware directly on the hard drive and a programming interface supported for ISVs to provide security management of the FDE function.

It is anticipated that such products will evolve to Specification-based products in the future.

The requirements derived from the Storage WG use cases do not mandate a Trusted Platform Module (TPM) for storage devices. However, a "root of trust" for storage devices is required to extend the trust boundary of trusted platforms. This ‘root of trust' is detailed in the Specification and can be realized by a combination of hardware and firmware.

More than 60 of the approximately 100+ TCG members have registered for participation in the development of the Storage WG Specification. Not only all major hard drive vendors, but flash, tape, and optical storage vendors are participating. We also have participation from storage and security management and storage integration vendors. A complete list of TCG members is online at www.trustedcomputinggroup.org.

Every application that depends on the integrity, trustworthiness, and security of relevant data will critically benefit from the TCG Storage Work Group Specification. The published storage use case white paper implicates a number of such applications.

The Specification does not define a complete, full-life-cycle content protection scheme. However, the Specification does provide a number of security "building blocks" that could be used by developers of content protection schemes.

Once the trust and security functions from the Specification are implemented in firmware and hardware on the storage device, then platform-based applications utilize this function through the SCSI/ATA Trusted Send/Receive command interface, under versatile access control.

Storage is where the data resides! Plus, storage devices contain powerful computing subsystems and lots of available memory, as well as being "closed" to vulnerabilities that plague the operating system-based platform. SAN, RAID, and other complex storage device manufacturers are reacting favorably to such trust and security functions being provided by the constituent storage devices; e.g., scale and extensibility, shorter path lengths, risk mitigation, etc.

Yes; the Specification applies to ALL storage devices, both client (PC) and server. The initial interest is for PC-based products, but the Storage Specification will appear in all storage, equally satisfying requirements that are specific to servers and data centers.

The manufacturers of enterprise storage and storage complexes participating in the Storage WG have chartered a Key Management Services Subgroup (KMSS) focusing specifically on key management and related issues. A KMSS Specification is expected in the near future.

Yes; the Specification applies to ALL storage devices and we have participation in developing the Specification from all storage device types

No, the single successful attack compromises only the data protected by a single TPM, not all TPM's (or all Infineon TPM's).

Trusted Network Connect (TNC) is an open, non-proprietary specification that enables the application and enforcement of security requirements for endpoints connecting to the corporate network. The TNC architecture helps IT organizations enforce corporate configuration requirements and to prevent and detect malware outbreaks, as well as the resulting security breaches and downtime in multi-vendor networks.

The TNC architecture has been designed to assist network administrators in protecting networks by allowing them to audit endpoint configurations and impose enterprise security policies before network connectivity is established. This can help prevent inappropriate and unauthorized access that can result in viruses and email worms, Trojan horses, denial of service attacks, and other malicious activities.

First, the specification focuses on the collection of endpoint configuration data in conjunction with user authentication information, for comparison with a pre-defined set of organization criteria for access to the protected network. This creates a "security" or "safe computing" profile for a system. Second, the specification addresses providing an appropriate level of network access based on the detected level of policy compliance, including full access, partial access or directed access, or no access.

In 2006, the TNC made available three new specifications. These specifications are:

• 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.

In February 2007, the TCG announced the release of updates to four existing specifications. The new specification names are IF-IMC 1.2, IF-IMV 1.2, IF-TNCCS 1.1, and IF-PEP for RADIUS 1.1. These updated specifications provide valuable enhancements to the original versions, adding features requested by customers and incorporating fixes in response to feedback from implementers.

The following new features are provided:

• 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.

The IF-TNCCS-SOH 1.0 protocol now is an open standard published by TCG (under the TCG royalty free cross-licensing model) and available for anyone to implement for free. It is implemented in Windows Vista and to be implemented in Windows XP and Windows "Longhorn". We believe it will become the prevalent method for network access control client-server protocols. SOH will enable any device to participate in a TNC or NAP network and have its health checked.

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.

TNC is based on the twin concepts of integrity and identity. Integrity is used in this case to describe the desired state of an endpoint's "health" or configuration, as defined by IT policies. Examples might be to check if the system adheres to pre-determined policies and determine the system is not engaged in unusual or malicious behavior. Identity ensures that systems are authenticated for authorized users only; clients with the TPM offer additional security in that identity is established through hardware. The TPM also provides a trusted boot mechanism that uniquely helps thwart root kits, stealthy infections that are otherwise almost impossible to detect.

Another key attribute of TNC is its focus on heterogeneous networking environments, with products from a variety of vendors. TNC support will enhance many existing products. Users can benefit quickly because they can implement TNC within the infrastructure products and vendors already deployed on their networks. The architecture is based on existing, widely used standards such as EAP and TLS, and integrates with mature technologies such as IPsec and 802.1x.

The TNC architecture is constructed on top of traditional network access architecture - for instance, the switches in a wired LAN. A Network Access Requester (NAR) is client software on the endpoint that begins the network access attempt. 802.1x supplicants, VPN clients or Web browsers initiating SSL connections could all be NARs in a TNC environment.

The Policy Enforcement Point (PEP) - usually a network infrastructure device like a switch or a VPN concentrator - is configured to require 802.1X authentication, and forwards information about the NAR and its network connection attempt to a Policy Decision Point (PDP), where a Network Access Authority (NAA) determines whether the endpoint should be admitted to the network.

The TNC extends this standard architecture with two layers on the endpoint and two layers on the PDP. On the endpoint, a TNC Client gathers reports from Integrity Measurement Collectors (IMCs, plug-in modules that report on the endpoint's health). The TNC client delivers these reports ("integrity measurements"), using the 802.1X connection, to Integrity Measurement Verifiers (IMVs) on the PDP, which check the client state against integrity policies. A TNC Server on the PDP manages the integrity check handshake, delivering messages to and from the IMVs and combining the IMV's recommendations into a final access recommendation to the NAA.