There has been a growing interest by commercial organisations in providing portable, trusted and secure computing platforms that may be used in the scenarios such as those outlined in the Introduction section. A number of solutions have been proposed from a variety of vendors, ranging from IronKey[6], and Gemalto[7], to the Singapore Government’s DIVA[8]. Some of these solutions are strongly tamper resistant and locally tamper evident.
The Trust Extension Device (TED) was developed with similar goals of providing a portable, secure and trusted computing platform. However, its key differentiator is that it adopted and implemented the Trusted Computing Group’s (TCG)[9] standards and architectures into a small, portable device. In particular, the TED provides an issuing enterprise a truly trusted computing platform whose root of trust and associated functionality is based on the Trusted Platform Module (TPM v1.2b[10]) cryptographic microcontroller hardware. The TPM becomes a root of trust for the TED platform, and allows the remote validation of its hardware and software through the use of cryptographically secure integrity measurement and attestation protocols.
In the TCG architecture, a specialised Privacy Certifying Authority service is required to participate and provide supporting validation of credentials and keys that are used by the TPM to encrypt and sign messages (including integrity measurements) between the TED and the service provider’s cloud infrastructure. Together, the TED, Privacy Certifying Authority and the service provider’s cloud infrastructure, develop and maintain a provable, measurable trust relationship between themselves.
It should be noted here that there are two significant points need to be addressed when implementing and ultimately deploying such a system.
First, in every TPM enabled enterprise system, the enterprise application servers need to have complete knowledge of the hardware and software characteristics of all their client computers in order to engage, and successfully complete, the integrity measurements and attestation protocol. Each variation from a standard, known environment needs to be identified, captured and maintained within the application server so that the attestation protocols can continue to operate correctly. However, the variety of software images and hardware configurations, the rate at which these change, coupled with the typically large number of computers connecting to the enterprise server makes the task of maintaining and managing this information difficult and challenging.
The TED and associated infrastructure addresses the management issue by (i) reducing the complexity of the device and associated operating system and application software, (ii) having the device issued by a controlling enterprise/authority and (iii) being sufficiently cheap and portable for a new one to be easily re-issued if required. The TED’s environment (drivers, operating system and applications) was specifically designed and optimised for execution speed and offers a restricted and controlled set of applications and services. It is completely under the control of the issuer. By design, the TED cannot be altered or modified once it has been configured and issued by the enterprise. Any changes or deviation from expected configuration are remotely detected by the application server through the TPM integrity measurements and attestation protocols. Should a change be detected, the issuer can take appropriate action, such as not engaging in the critical transaction, or notifying the client that their TED has been compromised and will be revoked, etc.
Second, data and services are now available (for example, when enabled to utilize cloud computing infrastructures) to a wider cross-section of users, operating under unknown and unpredictable computing environments that lie beyond the control of a single enterprise. In many cases, the users themselves operate beyond a single organizational boundary.
These uncertainties are addressed by TED being able to be plugged into a USB port of any host computer, without the need for specialised hardware interfaces or readers, to create a known (to the issuing enterprise), trusted computing platform and associated environment and applications that are isolated (from the host’s hardware up through to its operating system and applications) from the host computer.
The design and implementation of the TED prototype (both the hardware and software) are presented in detail in another paper ([11]). We summarise its salient features here.
An overview of the TED hardware and software
For completeness, the design requirements for the TED prototype (and its associated software components/system) were as follows: The selection of the USB 2.0 connection was based on pragmatic reasons - USB 2.0 reduced the hardware costs, complexity and software development time substantially over other design options.
DR-1 Should be small and cheap enough to be portable and easily re-issued to a client by the owner enterprise or cloud service provider.
DR-2 Must be able to physically plug into any host PC with a USB 2.0 compliant port.
DR-3 Must use the USB port solely for power and for establishing a secure network connection (tunnel) to well-known servers after it has successfully booted.
DR-4 Must be able execute owner enterprise or cloud service provider developed applications on an embedded operating system.
DR-5 Must include and use a TPM v1.2 compliant cryptographic microcontroller.
DR-6 Must be able to implement and participate in attestation and identity management protocols as per TCG specifications.
DR-7 Must not require that the host needs to be rebooted for correct operation.
DR-8 Must not rely on the host PC being interrupted from normal operation.
DR-9 Must be able to be inserted or removed from the host PC at any time without causing either the host or the TED to enter an error state.
In principle, a TED may be regarded as a stand-alone networked device. According to the above design requirements, the TED really only requires the host PC for power and network connectivity (using either wired Ethernet or WiFi). It operates its own isolated memory address space, running on a separate CPU, all of which may be attested as operating within the strictly controlled environment provided by the issuing enterprise (which may be a cloud service provider). There were no requirements for having any traditional user screen or keyboards to interface to it; any such interfaces were to be provided through appropriately secured connections to the host PC.
As such, we did consider other designs, including having a keypad and single LCD screen mounted on the device that the user may interact with independent of the host PC (which again was only providing power and secure network connectivity). This design was never implemented due to time and project resourcing issues. Another design was a natural development from the “small keypad single LCD screen” version, where the TED was connected to a cellular phone platform providing power and that utilised 3G data network for secure network connectivity. However the initial design investigations revealed that the power requirements of this TED variant exceeded the capacity of a cellular phone’s supply, and so this option was never pursued.
Figure1 shows the TED prototype hardware that consisted of two boards: a motherboard containing the CPU, memory and associated control logic (out of view) and a daughterboard, carrying the TPM chip, USB interface and associated power supplies for both boards.
The TED internal software architecture is shown in Figure2. It is based on an embedded Linux operating system, and required the development of dedicated extensions and drivers to accommodate the TPM device and USB interface. Above the operating system, the TED utilised a light-weight TCG Software Stack (TSS) Library and TSS server that allows applications to interface to the TPM functions.
A user’s applications execute on the TED (again, that are under the control of the issuing cloud service provider) to access external systems. Its execution and memory spaces are isolated from the host PC, and only uses the host PC for power and to establish secured Internet connection to the cloud provider’s service. The secured Internet connection is tunneled from the TED’s USB port, through the host PC’s network connections and finally onto the cloud provider’s service.
Integrity measurement and attestation
Without entering into details of the TCG’s recommended integrity measurement and attestation (of the TED platform and its complete operational environment)[12], most (except for the Direct Anonymous Attestation protocols) follow the similar structure of the protocol given in Figure3. Section 4.2 in the TCG Specification Architecture Overview[4] gives an excellent overview of this topic.
At step (1), a challenge message with a fresh nonce is issued to a platform (in this case, the TED) to attest its identity and integrity with the application service. Once this message is received, the TED platform at step (2) calls a TPM function to generate an Attestation Identity Key (AIK) and the TPM credentials. These credentials, along with other credentialsa the public part of the AIK and the original challenge nonce are signed by the private TPM Endorsement Key. The resulting signed credential is then encrypted using the public part of the certifying authority’s key. This is then sent at step (3) to the certifying authority as a request to validate its credentials. If successful, the certifying authority creates a signed, encrypted credential that is sent back to the platform at step (4). Step (5) is used to produce an encrypted summary of measurements of the environment held in sealed storage (the Platform Configuration Registers, or PCR) in the TPM chip. (e.g. one measurement may be a list of loaded and running processes just after boot, another measurement may be a new list of running processes several hours after boot). This encrypted measurement information is then sent back to the challenger, along with the identity credential received from the certifying authority at step (6). Upon reception of the message, the challenging application service now validates at step (7) the measured environment and compares it to its own expected measurements that it holds. During this process, the challenging application service checks the identity credential to determine that it was signed by the certifying authority, as well as verifying the signature of the measured values and that it contains the original challenge nonce. Depending on the application requirements, step (8) may optionally be used to signal to the application client the success of the measurement and attestation process.