Trusted Computing Group

What is the Trusted Computing Group (TCG)?

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.

What is the organizational structure of TCG?

TCG is an incorporated organization. Membership is open to a wide range of organizations and TCG invites active member participation. The organization has a majority rule structure to facilitate progress. The group provides for marketing programs, democratic organizational management and independent advocacy. Finally, the organization provides a reasonable and non-discriminatory (RAND) patent licensing policy. These terms typically streamline adoption of industry standards.

How do I join TCG? What are the dues for each type of membership?

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

What is available from TCG?

The organization has developed specifications for the Trusted Platform Module (TPM) used in PCs and other systems; a software interface specification to enable application development for systems using the TPM; a Trusted Server specification; the Trusted Network Connect architecture to enable protection of the network; and a specification for the Mobile Trusted Module for mobile phone security. Another work group is preparing a specification to address storage security.

What has the TCG done to preserve privacy?

TCG believes that privacy is a necessary element of a trusted system. The system owner has ultimate control and permissions over private information and must "opt-in" to utilize the TCG subsystem. Integrity metrics can be reported by the TCG subsystem but the specification will not restrict the choice and options of the owner preserving openness and the ability of the owner to choose.

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

How does a TCG-enabled system protect against malicious and unknown use of its functions by an unauthorized user?

The TPM capabilities that deal with sensitive or private information require the presentation of authorization data. Authorization data adds a layer of protection to sensitive or private information.

Was TCG formed to specify Digital Rights Management (DRM) technologies?

TCG specifications do not provide all the necessary technical elements required for DRM. It is conceivable that developers could build their own DRM solutions that would operate on systems with Trusted Platform Modules, but TCG specifications alone are not DRM solutions.

What is a Trusted Platform Module (TPM)?

The TPM is a microcontroller that stores keys, passwords and digital certificates. It typically is affixed to the motherboard of a PC. It potentially can be used in any computing device that requires these functions. The nature of this silicon ensures that the information stored there is made more secure from external software attack and physical theft. Security processes, such as digital signature and key exchange, are protected through the secure TCG subsystem. Access to data and secrets in a platform could be denied if the boot sequence is not as expected. Critical applications and capabilities such as secure email, secure web access and local protection of data are thereby made much more secure. TPM capabilities also can be integrated into other components in a system.

Who provides these TPMs?

TPMs currently are provided by Atmel, Broadcom Corporation, Infineon Technologies AG, STMicroelectronics, and Nuvoton Technology in discrete and integrated forms.

What about smaller devices that might not have the real estate or cost structure to support a separate piece of silicon for TPM functions?

TCG and its work groups are evaluating this issue and may end up offering vendors options in providing the functionality of the TPM for various devices. Vendors also can package the TPM or provide I/O suitable for systems other than PCs - the TCG specification is flexible in this regard. For example, some vendors already offer TPM functionality integrated into other chips.

What applications and services will benefit from systems with TPMs?

Systems with TPMs offer improved, hardware-based security in numerous applications, such as file and folder encryption, local password management, S-MIME e-mail, VPN and PKI authentication and wireless authentication for 802.1x and LEAP.

Are systems with TPMs available?

Desktop, notebook and tablet PCs with TPMs are available from Dell, Fujitsu, Gateway, HP, Intel, Lenovo, Toshiba and others - virtually all enterprise systems now include the TPM. Trusted servers also have started shipping.

What are the plans for TCG conformance?

A certification and compliance program is in review. TCG will define programs that best fit market needs and specifications.

Do the TPM specifications require a certain cryptographic algorithm (DES, AES, etc.)?

Yes. They require RSA SHA-1 and HMAC. AES is not required in v1.1 of the specification, but may be required in future versions. The use of symmetric encryption is not required in the TPM. TCG will continue to evaluate developments in cryptography.

How do TPMs compare with smart cards or biometrics?

They are complementary to the TPM, which is considered a fixed token that can be used to enhance user authentication, data, communications, and/or platform security. A smart card is a portable token traditionally used to provide more secure authentication for a specific user across multiple systems, while biometrics are providing that functionality in an increasing number of systems. Both technologies can have a role in the design of more secure computing environments.

What role does Trusted Computing and the TPM play in authentication?

The TPM provides secure storage and key generation capabilities, similar to other hardware authentication devices, so it can be used to create and/or store both user and platform identity credentials for use in authentication. The TPM can also protect and authenticate user passwords, thereby providing an effective solution of integrating strong, multifactor authentication directly into the computing platform. With the addition of complementary technologies such as smart cards, tokens and biometrics, the TPM enables true machine and user authentication.

Can the Trusted Platform Module control what software runs?

No. There is no ability to do this. The subsystem can only act as a 'slave' to higher level services and applications by storing and reporting pre-runtime configuration information. Other applications determine what is done with this information. At no time can the TCG building blocks 'control' the system or report the status of applications that are running.

Is TCG creating specifications for just one operating system or type of platform?

No. Specifications are operating system-agnostic. Several members have Linux-based software stacks available. In addition to our work on the PC platform, we have specifications for Trusted Servers and mobile devices and are working to finalize specifications for other computing devices, including storage and infrastructure.

Does TCG require that software be certified to run on a TCG-enabled platform?

The TCG design does not have any requirement that software be “certified” in order to use it. The specification talks in some length about ways of using the platform to create certificates for keys that are provably secure and yet not identify the platform they came from.  TCG’s technology has a passive role in a system. It can be used to securely record data and to securely store (and sign with) digital keys. TCG architecture does not specify where to get these certificates or how much you pay for them. Free certificates work as well as certificates you pay for. There is no single source of certificates in the market today. Anyone can set themselves up as a Certificate Authority using any number of different Certificate Authority packages. TCG has recently put together an Infrastructure Work Group to look into some of the use cases to provide possible working models.

How does Microsoft’s BitLocker technology relate to the TPM and to the efforts of TCG?

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.

Is the TPM required for BitLocker? If so, is it only the 1.2 version?

For BitLocker™ to make use of a TPM, it must be a 1.2 version and the system must have a BIOS that meets TCG requirements. While it is possible to use BitLocker™ without a TPM by storing the keying material on a USB flash drive, this is not the preferred customer configuration, nor is it expected to be typical usage due to the cost and manageability challenges associated with this mode of use.

Where can I find more information about BitLocker™?

Additional information about BitLocker^TM can be found at: http://www.microsoft.com/technet/windowsvista/security/bitlockr.mspx

What is the TSS?

The TSS is a software specification that provides a standard API for accessing the functions of the TPM. Application developers can use this software specification to develop interoperable client applications for more tamper-resistant computing.

What effect will the TSS specification have on applications development?

The TSS ensures application execution will provide a level of confidence that the appropriate keys (cryptographic) have been generated and used in a more secure environment.

Will these TSS-enabled applications run on multiple operating systems?

Yes. The TSS is operating system agnostic. Members are using or have shown implementations with various operating systems including Linux, and some TCG members such as NTRU Cryptosystems, Inc. offer support for open source in their products for trusted computing.

How difficult will it be for developers to use the TSS?

If an application developer has experience writing with MSCAPI or PKCS#11, it will be easy to provide TCG-enabled applications.

What is Trusted Network Connect?

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.

Why is Trusted Network Connect necessary?

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.

What is the scope of the TNC specification?

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.

What Trusted Network Connect specifications are available?

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.

What features do these specifications provide?

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.

What else is new with TNC?

TCG has published a new specification supporting the Statement of Health. This new specification, IFTNCCS-SOH 1.0, is available beginning May 21, 2007 on the TCG website. Vendors can download this specification and begin development immediately.

What does this mean for customers?

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.

What are some attributes of TNC?

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.

Are TNC products compatible with today’s infrastructure?

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.

How does the architecture work? What are some key elements?

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.

What relationship does Trusted Network Connect have to the Trusted Platform Module (TPM) and other TCG efforts?

TNC is an excellent application for the TPM in that it helps establish a link to a decision point where integrity reports may be evaluated. Use of the TPM by TNC is optional, but for platforms with a TPM, the convenient reporting infrastructure enables the TPM reports to be factored into network access control decisions. A system with the TPM can protect sensitive data such as encryption keys and collected measurements. The TPM safely stores those measurements in a protected location until ready for reporting. It can protect the measurements from man-in-the-middle attacks that might occur anytime thereafter. Products based on TNC architecture can operate in today's environments with and without TPMs, but if present, there is greater assurance that TNC integrity reports originated from the expected platform.

When will Trusted Network Connect solutions be available?

Companies currently providing compatible products include Extreme Networks, HP ProCurve, Juniper Networks, Meru Networks, OpSwat, Patchlink, Q1 Labs, StillSecure, Wave Systems, General Dynamics and others.

How will Trusted Network Connect compare with other efforts in this area?

The TNC architecture is differentiated from Cisco Network Admission Control (C-NAC) and Microsoft Network Access Protection (NAP) by the following key attributes and benefits:

• Supports multi-vendor interoperability
• Leverages existing standards
• Empowers enterprises with choice

Also, the TNC architecture provides organizations with a clear future path. Future integration with the TPM - the IF-PTS specification - enables a complete trusted network trail from the client straight through to the network. This level of future roadmap and integration with standards-based hardware security is not available with any other endpoint integrity/network access architecture. Microsoft is a TCG member and previously has announced the alignment of the NAP architecture with TNC and planned interoperability. There are also additional solutions available from other vendors which attempt to address endpoint integrity and access control in different, various ways. TCG welcomes participation and membership by any companies in the TNC effort and believes that interoperable approaches to network access control are in the best interests of customers and users.

Does the Trusted Network Connect architecture use any existing industry standards?

Trusted Network Connect architecture uses existing industry standards, such as EAP, TLS, the 802.1x specification and others.

What access methods are supported by the TNC architecture?

The architecture supports all commonly used enterprise access methods such as VPN-based or dialup remote access; wireless networks; 802.1x infrastructures; and traditional LAN technologies.

How will users know that products are interoperable? Is there any certification or compliance program planned?

TCG is evaluating a compliance program.

What is the TCG Trusted Server Specification?

This effort defines the architecture of a trusted server and how these servers are created, managed and maintained. The specification also provides a blueprint for communication between trusted servers and clients.

Why is this necessary when there already are trusted clients?

TCG was founded with the goal of providing the building blocks for end-to-end trusted computing. With some 15 million trusted clients in use and millions more anticipated to be deployed in the next few years, it was logical to offer developers a complementary specification to secure the server and allow trusted communications between servers and clients.

What kinds of servers does this specification cover?

Like all TCG specifications, the server specification has been created to support a variety of platforms and architectures including x86 and Itanium architectures, MIPs, Sparc, Power and others.

What form factor will trusted servers take? Will blade servers be supported?

The specification was written to allow platform vendors to build trusted servers in all form factors, so over time it is anticipated that trusted servers would ship in all form factors, including blade servers.

How does the server specification relate to the Trusted Platform Modules (TPMs)? Is a TPM required for these servers?

Trusted servers are required to contain TPM functionality that meets the requirements of the TPM specification (1.1b or 1.2). The specification is complementary to the TPM specification and defines the behavior and requirements of a trusted server.

Will server TPMs be different from PC ones? How is TCG addressing this?

Currently, the trusted server may be designed using the same TPMs found in trusted clients. There is no reason, however, that a TPM or system vendor could not develop TPMs with higher bandwidth capabilities, as long as the interface specifications are met. In the future, TCG may add additional TPM commands to provide for additional server operational or management capabilities.

What does the TPM do in a server?

The TPM provides that same functionality as it does in a trusted client: it stores and protects digital keys, passwords and certificates. The applications built on that functionality will almost certainly be different than those on the trusted client.

Does a trusted server impact server throughput? Will more servers be required?

This will depend on the application that is built on the new trusted server features. It is assumed that early applications will not rely on the TPM for high throughput operations, but over time, as TPM performance is enhanced, more operations may be handled by the TPM, which will require the platform vendors to engineer the solution to limit any impact to server throughput.

What does the specification require for servers? How much redesign is required to incorporate Trusted Computing into future servers?

The specification communicates baseline requirements, providing server vendors with a definition that allows for efficient transition of server designs to trusted server designs. It also provides for the transition of trusted client designs to trusted server designs. Much of the work in the trusted client space can be leveraged into an X86 trusted server design, requiring minimal redesign.

When do you expect to see products incorporating the server specification?

Trusted servers have started shipping from some vendors.

Do you anticipate servers conforming to this spec to be more expensive? If so how much additional cost will be incurred?

The pricing model of trusted servers is not known but it's anticipated that additional costs will be minimal, based on the scenario of trusted clients.

Will trusted servers require new or additional management tools and services? Will trusted servers be compatible with today’s applications?

There will certainly be new tools to manage the security capabilities of trusted servers. Trusted servers will be compatible with today's applications, although to take full advantage of the new security features, updated applications will most likely be necessary.

Can IT managers deploy a mix of trusted and non-trusted servers?

Yes. As with trusted clients, we anticipate most organizations will deploy a few trusted servers initially then gradually switch as they replace older systems.

What are some of the anticipated uses for a trusted server?

The TCG trusted server specification provides for use cases including:

Asset management
Configuration management
Data migration and back-up
Distributed trusted computing
Document management
Financial transactions
Management of endpoint integrity and network access control
User and platform authentication

What are some examples of these?

One is ensuring a trusted client is connecting to the intended server. The specification also provides for a usage model in which the server is verified to meet minimum standards before being allowed to perform sensitive transactions. Another example: ensuring that data stored on servers is sealed (using a TPM based on the 1.2 specification) to protect it from unauthorized access.

Why was the Trusted Computing Group (TCG) Mobile Trusted Module (MTM) specification developed?

The TCG, as the trusted computing security authority, has developed the Mobile Trusted Module specification to enable mobile phone information security assurance and the potential application benefits associated with that assurance. TCG security assurance directly translates into trust in a platform's capability to protect its information and functional assets, and to attest to those protections.

TCG has always had the mission of providing specifications for any device that touches the network. While its initial work has been in PC clients, the network and servers, it is logical for TCG to apply its expertise and Trusted Computing concepts to mobile devices. From the perspective of users and vendors, mobile phones are becoming increasingly sophisticated and are being used for basic computing tasks, Internet connectivity, network access to corporate data, and mobile commerce and banking services. Smartphones also are being used as storage for personal, confidential information. All these new phenomena require increased trust and security functionality.
The TCG Mobile Phone Work Group has completed the world's first open security standard for Mobile Trusted Platforms, using the Mobile Trusted Module (MTM), whose specification was published already in September 2006.

When will the actual specification be available? When will we see product implementations?

The specifications are now complete and available. The Mobile Phone Work Group released the Reference Architecture specification and the Mobile Trusted Module specification in June 2007. A draft version of the MTM specification, called "Commands and Structures", was released previously in September 2006. Like all TCG specifications, the specification is available on the organization's website, free of charge. While we can't forecast specific product plans, generally products follow specifications by several quarters or so, depending on product development cycles.

What do you mean by mobile security?

TCG's definition of trust as it applies to trusted computing is "hardware and software behaves as expected". With regard to mobile devices, this implies that the operating system, platform, and application level functionalities, as well as SIM, USIM, UICC cards etc, interact in a secure, trusted manner. The Mobile Trusted Module is designed to complement existing mobile phone security components. The Reference Architecture specification describes a platform that uses the MTM to provide enhanced platform security. While existing standards address subscriber information security from a network carrier perspective, the TCG specifications enable trust in the mobile phone equipment itself from the more interoperable and privacy sensitive TCG trust perspective.

Who benefits from this specification?

Because the specification addresses both information and functional asset integrity, both functional users such as consumers, professional users, enterprises, industry and governments as well as content providers and information owners benefit from the assured protections enabled by this specification. As defined in the Mobile Trusted Module use cases (published in 2005) a variety of practical applications match with current needs from both end-users' perspective and enterprises' viewpoint. Practical implementation of the use cases enable enterprises and other parties to develop more sophisticated services and expand their business field.

What does the Mobile Trusted Module specification cover? How will it work?

The specification provides the core framework, commands and control specifications needed to provide a TCG based security building block solution in mobile phones. This will allow mobile chip, software, and handset companies to begin to design the MTM functions into their products.

What else is required for a mobile phone handset maker or other party to use this specification?

Vendors need to provide software and hardware that provides standard TCG roots of trust, such as the root of trust for measurement, an additional root of trust to verify software before loading it, and (optionally) an additional root of trust for instantiating other roots of trust. Vendors also need to provide software that can take advantage of the functions provided by TCG technology. This may include adaptation and further development of operating systems. These functions are described in the Reference Architecture component that forms the second half of TCG's Mobile specifications. The Reference Architecture was published in June 2007.

What are the benefits of standardizing mobile security? Aren’t handset OEMs, software makers and service providers working on this issue individually?

Standardization has proven to be a highly successful path to foster interoperability across computing and communications. Effective standards allow different manufacturers to streamline R&D, to take advantage of the combined expertise of the industry, to cut costs and to increase adoption by users and other participants in the economic ecosystem. By embedding standardized security into mobile devices, the various providers of hardware and services can ensure security and interoperability while adding value through their devices or applications.

To what extent will today’s phone architecture need to be modified to accommodate this specification?

As there are numerous different implementations across various handset OEMs, it is not possible to know how TCG's Mobile specifications might impact their current designs. However, the open standards for security functions included in the Mobile Trusted Module specification are in many cases similar to current functions implemented by each vendor and the specification is deliberately formulated to be abstract and implementation neutral. Participation of various organizations in the specification design process and continuous cross-industrial collaboration has supported the aim of developing an implementation neutral specification. The benefit of the specification is that it would provide a common description of the functions that need to be provided to meet platform security objectives and of the security properties and capabilities of those functions.

TCG has talked about the fact that enabling a TPM in a PC is an opt-in procedure, allowing users to decide whether they want that security or not. Will phones operate in the same way?

In the mobile phone environment, there are different requirements about what the user can and cannot do, and these are different from PCs. One example could be the subscriber information that is used for billing the phone usage - a user should not be able to change that.

Does the work of the Mobile Phone Work Group cover just phones or does it include PDAs?

The published use cases and Mobile Trusted Module specification have been designed to address mobile phones. These could include smartphones with PDA functions.

Do these use cases apply to other handheld devices?

The first set of use cases targets the products that include cellular technology. However, the specifications might be used to implement mobile security in other products.

Where does the responsibility on security reside when a security module is built into a device; can the interests of the service providers be assured?

The responsibility for security is always a shared responsibility between the security service provider and the service user. Any security module can only offer assurance for the behavior and assets within its own domain. The behavior and the assurances of a security module include the protections employed to address the particular threats that exist in a specified environment. The interests of service providers are assured to the extent that they understand the protections offered by the module and their own responsibilities for its effective application.

What will be the estimated cost of using the specification?

TCG cannot speculate about costs because the specifications are deliberately implementation agnostic. The costs mainly depend on the way the specification is implemented among volumes and environment.

Which companies are participating in the TCG Mobile Phone Work Group?

A number of companies representing handset makers, service providers, silicon providers and applications are active in the Work Group. These companies include AuthenTec, Ericsson, France Telecom, HP, IBM, Infineon, Intel, Lenovo, Motorola, Nokia, Panasonic, Philips, Samsung, Sony, STMicroelectronics, Texas Instruments, VeriSign, Vodafone, Wave Systems and many others.

Is TCG working with other standardization bodies?

TCG has an active liaison program with the purpose of coordinating its open specifications with other organizations. Open, interactive discussion between different organizations overcomes any potential gaps or overlaps in standardization work. Many of the TCG Mobile Phone Work Group members also participate in other key standardization organizations, such as OMA, OMTP, 3GPP, MIPI, ITU and others. In addition to ongoing liaison by members of the organization, TCG is publishing the relevant technical materials and inviting comments and participation of other companies.

What are the specifications being published?

The specifications published are related to integrity management of trusted platforms. These specifications can be best understood in the following groupings by function:

        Integrity Management Architecture: This document provides the architecture for the management of integrity in systems.

• Integrity Management Architecture (v1.0)

        Measurement agent: This specification defines the trusted software capable of measuring, verifying and reporting                         software.

• PTS Interface specification (v1.0)

        Integrity Schema specifications: These specifications define the XML-based schemas for reporting and verification of                     software.

• Core Integrity Schema (v1.0)
• Integrity Report Schema (v1.0)
• Reference Manifest Schema (v1.0)
• Security Qualities Schema (v1.0 and V1.1)
•  Simple Objects Schema (v1.0)
• Verification Results Schema (v1.0)

        Certificate formats: This specification defines the profiles of TPM-related certificates based on the X.509 standard.

• Credentials Profile (v1.1)

What do the specifications cover?

The set of specifications consists of the Integrity Management Architecture, the interface specification for a measurement agent called the Platform Trust Service (or PTS), and a common XML-based data format for capturing and reporting integrity information about a system.

The Integrity Management Architecture provides the common framework for defining, collecting and reporting information pertaining to the integrity of the software and configuration of a system. Such information includes the components (software and hardware) constituting the platform, the elements that participated in its booting-up and the software that establishes the computing environment in the platform.

The Platform Trust Service (PTS) interface specification defines the API to a measurement agent that performs the collection, measurement and reporting of the integrity information on the platform. The PTS interface specification has been written to be platform independent, meaning that it is applicable to the various types of platforms or devices (e.g. PC client, server, mobile phones, etc).

In order for the integrity information to be meaningful and verifiable by external entities (e.g. other devices), a common XML-based data format for representing this information has been defined in the Integrity Schema specifications. The Integrity Schema itself can be understood as consisting of three major pieces derived from a single XML schema. These are the data formats for collecting and reporting integrity information, the format for representing reference measurement of known values, and the format for the verification results from evaluating a report.

What is integrity management and what is it relationship to trusted platforms?

The TCG uses the term "integrity management" to mean the broad aspects around the measuring, reporting and verifying of the state of a given computer system, including the infrastructure support (e.g. architectures, protocols, data formats, etc) to accomplish these tasks.

There are numerous aspects of a trusted platform that can be subject to measurements and quantification. These include the register values inside the TPM hardware, files on the system, in-memory images and others. Which aspect of a trusted platform to be measured is largely dependent on the use case of the measurement (e.g. verified boot, network access control, etc).

Who benefits from this specification?

These specifications allow users to have confidence in the security mechanisms in their system. This stems from the fact that the integrity of these mechanisms can be verified (locally or remotely) as being free from alteration by malicious code.

How do these specifications relate to the Trusted Platform Module (TPM) shipping in PCs today?

These specifications are directly relevant to the TPM in PCs today and represent the next phase of infrastructure support for the operations of the platforms containing the TPM.

The TPM represents the trust anchor within the platform for the truthful reporting of the state of the platform. This feature is called "attestation" of the platform and represents a core value proposition of trustworthy computing. With the PTS specification, not only can the TPM be used to protect sensitive information, it can also be used to produce irrefutable reports (in a standardized format) regarding the TPM and the platform as a whole.

Do these specifications work with the TNC specifications that do not require TPMs?

This set of IWG specifications can be implemented without the presence of a TPM. The value of these IWG specifications is dramatically increased when the root of trust (of the platform deploying them) is based in hardware.

In the context of the TNC specifications, the Platform Trust Service (PTS) interface specification provides an agent that can be employed (called by) the TNC Client to perform measurements of the components of the TNC Client device, as well as other client components. Furthermore, the set of IWG Integrity Schema specifications provides a standardized format for TNC implementers and vendors to report on the integrity status of a target device (e.g. TNC client). This standardized format promotes greater interoperability across TNC vendors.

What other infrastructure specifications has TCG released and how do they relate to the PTS Specification?

The current set of infrastructure specifications represents a second phase of specifications, with the first phase infrastructure specifications published in 2005. The first phase specifications focused on the operational infrastructure required for a single system (containing to a TPM) to function, allowing applications to make use of the basic features of the TPM. These specifications focused on key management, backup of keying material, certificate issuance and management, and others.

In the current (second phase) specifications the focus is on the infrastructure support required for one platform to attest its state to another platform, which is a core value proposition of trustworthy computing. Thus, the current set of specifications includes a common architecture for understanding attestation using a TPM, as well as an interface to a measurement agent (the PTS) that can measure state, issue a report and verify attestations. The PTS builds on these previous first phase infrastructure specifications, and make use of a number of crucial functionalities provided by these specifications.

What is a typical use case for using TCG infrastructure specifications?

One of the core value propositions of trusted computing is that of providing attestation to the integrity of a given system. Thus, in addition to user authentication, a broad use case would be that of reporting the integrity status of the system (as measured and reported by the PTS) as part of access control to resources. There are numerous specific use cases for platform attestation. These include network access control (as exemplified by TNC), remote management and control of systems, security and integrity of financial transactions, verified boot of platforms, and others.

Are there any privacy concerns with using PTS or other infrastructure specifications from TCG?

Consistent with the vision and practices of the TCG and its specifications, the infrastructure specifications have been designed to preserve the privacy of users. Similar to the TPM case, users must specifically choose to opt-in to deploy the PTS and other infrastructure functions. The PTS itself can be deployed without the TPM. The PTS vendors can implement administrative interfaces that allow control over the information that may be reported by the PTS, thereby ensuring user privacy. Finally, the PTS can be configured to perform only local verifications and thus privacy sensitive data can remain local to the platform. The PTS configuration should be driven by IT policies that will ensure that privacy sensitive values are not disclosed.

Will implementing PTS restrict users to any operating system or applications? Can these be changed on a platform with PTS capability?

The PTS specification has been written to be agnostic across platforms (PC-Client, Server, Mobile, etc), and across operating systems and applications. The need for an agent to measure and report the integrity state of devices covering the entire software stack is a fundamental need of all devices. For vendors implementing the PTS, it is important to note that each implementation may be dependent on the hardware architecture and operating system upon which the PTS is implemented. For application developers that make use of the PTS, the same interface will be available independent of the operating system and underlying hardware platform.

What is the TCG Storage Specification?

The TCG Storage Workgroup has developed the TCG Storage Specification Overview and Core Architecture Specification as Version 1.0, Revision 0.9, which describes in detail how to implement and utilize trust and security services on storage devices. TCG is making it publicly available for critical review and analysis by the larger I.T., storage, and software application and end-user communities. Storage device developers can design trusted storage devices based on this Specification and application developers can examine how their applications might exploit trusted storage devices.

Why is the Specification being released as "Version 1.0, Revision 0.9 - draft"?

The TCG is following the usual practice with storage-related standards (such as SCSI and ATA) of releasing a version for wider industry review, before publishing a final version. This version of the Specification is complete, self-contained, and capable of being implemented, and was developed by our broad base of storage industry members. Vendors can begin to engineer products based on the Specification. If a vendor would like to contribute to the final Specification, we encourage that vendor to join TCG and to participate in the Storage Workgroup.

Who would use the Storage Specification?

There are two primary audiences for this Specification:

For storage device manufacturers, TCG's Specification provides the architecture for how to implement trust and security services on storage devices.

For platform-based application developers (ISVs), the Specification describes the interface to trust and security services on storage devices, so that the application can take advantage of such services.       
Of course, the ultimate benefactors of the Storage Specification are the end-users who purchase and take advantage of the security-enhanced applications that will result from using the Specification.   

Have you taken into account existing standards such as those for SCSI and ATA? How are you working with other standards bodies?

SCSI (T10) and ATA (T13) are ANSI/INCITS standards committees that input their standards to ISO and provide the interface standards for a great variety of storage devices, including USB-attached storage (i.e., SCSI command set). After interaction with TCG, T10 and T13 both have defined a Trusted Send (In) and Trusted Receive (Out) command set, which have subsequently been dually standardized. Trusted Send/Receive provides the "container" commands for specific "payload" security commands. The TCG Storage Specification provides the "payload" definition for the specific Protocol ID = TCG. Other Protocol IDs can be assigned to other protocol suites, as needed.

Additionally, the Storage Specification reference adopts other trust and security standards, as appropriate (e.g., public key, cryptography, hashing).

What does this Storage Specification enable?

The Specification enables platform-based applications to take advantage of trust and security services provided by "trusted" storage devices.

What are examples of trust and security services detailed in the Storage Specification?

The Specification enables applications to take advantage of a number of trust and security services on a storage device:
Cryptography
Public key cryptography and digital signature
Hashing functions
Random number generation (RNG)
Secure storage

Is the Storage Specification complete? Will there be later versions?

The Specification is complete, but is being released as a Version 1.0, Revision 0.9 - draft. Even though all the major hard drive manufacturers and a number of flash, optical, and tape manufacturers have been working together to develop this Specification, we are providing this version to the larger I.T., storage, software application and end-user communities. If a vendor would like to contribute to the final Specification, due in the near future, we encourage that vendor to join TCG and to participate in the Storage Workgroup. However, ISVs and storage device manufacturers can begin to devise implementations based on this version of the Specification now.

Will products created using today’s Storage Specification work with those based on later versions?

Yes; any enhancements and additions should be upward compatible or require minimal changes.

Will products based on the Storage Specification work in today’s PC architectures?

Yes; the Storage Specification targets applications running on either PC or server platforms and therefore takes advantage of and is compatible with PC and server architectures.

What change of behavior is required from IT managers to use products based on the Storage Specification?

Traditionally, storage devices have been viewed as "simply" storage. However, storage devices can have powerful computing systems on board and lots of available memory, all protected behind a tightly closed and access-controlled environment, largely immune to the vulnerabilities of the operating system-based platform itself (e.g., viruses). And, the data is on the storage device. Why not put the security functions related to data protection directly on the device housing the data?

TCG and its members believe that IT managers will appreciate the advantages of pairing security and data storage in the same device.

Does implementing this Storage Specification cost storage device makers more? If so, how much?

Yes; the implied firmware and hardware enhancements needed to support the Specification cost money and development resources. But, the storage device industry has a tradition of efficient and cost-effective development, as well as an "economy of scale" across such huge product volumes.

Does implementing this Storage Specification require any new or different parts for storage devices? If so, who is providing those and when will they be available?

Yes; the internal computing environment of a storage device must be enhanced to support the Specification. The storage device manufacturers themselves typically develop those core components themselves. TCG cannot speculate on availability, except to note that the storage device industry had been aggressively cooperating on the development of the Specification.

How will PC makers and users know that storage devices based on the Storage Specification meet all of its requirements? Are you planning a certification program?

The TCG Storage WG is working on security evaluation/compliance requirements as a follow-on effort.

Some companies have announced hard drives already that incorporate some of the work that was done in TCG before the Storage Specification became available. Will these products be compatible with future products based on the actual Specification?

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.

Will secure storage devices require a separate TPM?

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.

Which companies are participating in the Storage Specification effort?

More than 60 of the approximately 170+ 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.

What are some potential applications for trusted storage?

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.

Is the Storage Specification targeted for content protection?

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.

How does trusted storage work, exactly?

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.

Why is the storage subsystem appropriate for security? Why not put security further out, for example, in the SAN or the RAID device?

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.

Is TCG going to address security issues for data centers as well as notebooks?

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.

What is TCG doing to address issues related to key management?

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.

Does the Storage Specification address flash drives and other portable storage devices?

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