Trusted Computing Group

The Embedded Systems Work Group has recently organized and has started work in the sub-groups. Drafts of use cases and frameworks for use of existing specifications should be available late in 2011. Drafts of new specifications should be available in 2012 and early 2013. When working directly with customers, we anticipate a project timeline of six to nine months for a project that involves direct experimentation to solve a current problem using existing technologies.

The "Internet of Things," referring to the explosion of Internet-connected devices beyond the typical PC, has already exploded beyond an estimated two billion devices and is growing quickly. These devices range from critical infrastructure to personal household devices. All devices, whether network-connected or even offline, are open to attack and compromise in many ways. TCG believes that its groundbreaking work in Trusted Computing, based on the concept of a hardware root of trust, can contribute in a meaningful way to the need for embedded or built-in security in the devices that constitute the Internet of Things.

The Trusted Platform Module was designed to serve several functions within a larger computing system. These functions are as important to the interaction and operation of embedded systems as they are to the interaction between PCs, servers, and other network devices. For example, when communicating across a network, it is just as important to be able to uniquely identify a sensor as it is to identify a PC. It is also equally important to be able to establish whether the sensor has been compromised or can be trusted to behave as designed. These are the same platform integrity values that Trusted Platform Modules provide in PCs.

The Embedded Systems Work Group is operating on the assumption that the TPM 1.2 implementations now widely deployed will address most of the requirements of embedded systems. Because of the need for different interfaces in typical embedded computing platforms and also some specific functionality requirements, an embedded TPM platform standard will soon be published to cover these requirements.

Initial high-level, universal use cases are clear:

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

 

Yes. There are printers, video game consoles, kiosks and other devices already in the market that contain TPMs. The most common use of the TPM in those devices is validation that the code has not been tampered with. The TPM may also be used to protect a unique identifier as well. These are the two foundation functions of a TPM in any device.

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.

A major difference is less emphasis on the "take ownership" requirements found in PC implementations. In many cases, like set-top boxes and cars, the TPMs could be provisioned once on the manufacturing line and never again for the lifetime of the box. In other cases, provisioning on the manufacturing line might be done in order to make sure that the device has an initial identity. The purchasing device owner might be given a tool for rejecting that identity and then creating a new one.

Beyond initial provisioning, there will be use cases that require key management. There are some examples of fully automated, built-in key management in products today (for example, the Lotus Notes built-in PKI but also free open source PKI modules). This will be one of the bodies of work that the Embedded Systems Work Group will have to address - how will key management be done in either a "hands-free," fully automated fashion or in a low-touch fashion.

 

A core Trusted Computing technology is the TCG Storage Opal 1.0 specification for the self-encrypting hard drives that are now widely available and are expected to ship as standard equipment on many new PCs in the near future. These drives can also provide protected storage for keys as well as generation of new keys.

Many of the devices in the Internet of Things generate data as their primary function. Sensors of all sorts are examples of this sort of device. Often the data collected by sensors is of a sensitive nature and those devices are only connected to the Internet intermittently.

Sensors in vehicles are an important example. Another example is sensors used in collecting terrain and geological information for a company exploring for oil, minerals or metal. This prospecting data may have significant value. It could affect the valuation of a parcel of land. It could affect global commodity markets or even governments in some cases (think of the effect of the discovery of oil deposits in the North Sea). In situations like this, automatic encryption of data at rest is clearly of value.

Another example is that a great deal of personal financial information could end up stored on many embedded systems. Disclosure of this information is hardly likely to shake the pillars of Wall Street, but it certainly could be a disaster for an individual or a company. In today's market, the primary reason people give for not engaging in on-line banking is their concern over the security of their personal financial information. The same concerns apply to the use of embedded systems that may be required to store this same information.

 

At the level of firmware, there is a command set that is available for addressing the TPM directly for service. This command set is used by nearly all business PCs in the market today, every time that the PC is turned on. BIOS execution involves communication with the on-board TPM. There are many embedded devices that operate at a firmware level only when they are turned on.

However, there are also many embedded devices that run some form of embedded operating system. Examples include various Real Time Operating Systems (RTOSs) and the embedded versions of Windows and Linux. In the case of Windows running on an embedded system, it is possible that existing Windows-based support for TPMs (the TCG Software Stack and other operating system-supplied middleware that supports TPMs) could be made available on embedded devices. For the RTOSs, Linux implementations, and other embedded operating systems, there is an opportunity for innovation and new development to provide middleware in these environments that facilitates communication with on-board TPMs.

For high security environments, there are already a number of trusted operating systems for embedded platforms. These trusted operating systems are available as products and apply virtualization technologies to achieve high security. The methods for this virtualization are either based on hypervisor technology or the microkernel architecture. These operating systems already provide extensive support for the trust and security functions of a TPM.

The charter for the Embedded Systems Work Group requires that we re-use existing work from the other TCG WGs whenever possible. As noted above, there are many embedded environments that have unique requirements and limitations that TCG has never before tried to respond to. The Embedded Systems Work Group understands that this will sometimes require modification of existing specifications and also creation of new specifications.

The Embedded Systems Work Group is actively seeking participants who require secure and trustworthy embedded systems. We are interested in your problems and your requirements. We are willing to work with members to determine whether and how Trusted Computing can solve those problems. This is a cooperative, experimental approach seeking the best possible answers to customer problems by using existing security technologies and best practices. A serious effort will be made to succeed with each problem case.

The Embedded Systems Work Group is a hybrid work group. Part of the group's responsibility is to write specifications that apply Trusted Computing technologies to the security problems of embedded systems. The other part is to work directly with customers who depend upon embedded systems in their business and who require those embedded systems to operate in a secure and trustworthy manner.