Towards a cloud-based integrity measurement service

Today there is a strong interest within Enterprises to move some or all their IT infrastructure and services to the cloud, with the aim among others of reducing the cost of IT operations as a whole. However, there are a number of security and privacy issues relating to cloud-based services, including the issues relating to providing access to external entities.

Two of the common cloud deployment scenarios faced by many Enterprises today are as follows:

An additional aspect of these scenarios is that Enterprises have already invested in and deployed strong authentication infrastructure and identity management services. Many seek to extend and re-use these infrastructures to address the needs of the new cloud environment.

Parallel to the recent developments in cloud-based services is that of the development of loosely connected federated identity and authentication services in the low-value consumer space. These low-value federated identity services have been exemplified by social networks where one simple password-based login to one social network allows the user to access other social networks without needing to perform further authentications. Although Enterprises have been interested in using this model to expand their customer base, one stumbling block remains that of the low security-quality of these loosely connected federated identity services.

Partly in response to this poor security quality, several organizations have emerged with the aim of defining the so-called standard trust frameworks as a means to boot-strap trust among entities in the identity ecosystem[1, 2]. These trust frameworks provide a foundation for entities to transact based on an agreed common legal contract, thereby overcoming the limitations and non-scalability of bilateral agreements. One common aspect of many of these trust frameworks is the use of a Level of Assurance (LOA) as a means to denote the quality of authentication performed by (and therefore confidence in) an identity provider. The LOA is a way to express the quality of the authentication event from the perspective of security. Thus, for example, a user wielding a hardware token in a two-factor authentication event will obtain a higher LOA value compared to a user that authenticates merely using a password. The US National Institute for Standards and Technology (NIST) has issued a publication defining a granular level of LOA values[3].

In this paper we argue that in addition to strong authentication with high LOA values, identity-based services in the cloud need to also perform access decisions based on the quality of the computing platforms or devices from which clients (e.g. employees, customers, or users) perform remote access to these cloud-based applications and services. We believe that a measured trustworthiness indicator or the so-called trust score of a given computing platform should be part of the authentication and authorization of that platform when it seeks access to services in the cloud. In so far as possible, the computing platform elements being measured include all softwares and firmwares, and also the hardware component identifiers[4].

We also argue that in order for new cloud-based services to be acceptable by Enterprises today, a high degree of interoperability with existing “Enterprise-grade” authentication and authorization infrastructures is required.

In this paper we propose an architecture for a cloud-based Integrity Measurement Service (cIMS). The cIMS performs the evaluation of the integrity measurements received about the client, and issues a trust score reflecting its evaluation against one or more predetermined profiles for client measurements. We use the classic SAML 2.0 ecosystem[5] as a means to illustrate usage of the cIMS. In this model, a client seeking access to a Service Provider (SP) must first be authenticated by an Identity Provider (IdP), who issues SAML assertions pertaining to the client. Here we extend the SAML2.0 model by having the IdP request also from the client an integrity measurement report. In order to satisfy the need for a high LOA level, we propose the use of a trustworthy portable computing platform, the Trust Extension Device (TED) to provide the client-side trusted computing environment capable of performing integrity measurements of the client-side components.

Since the NIST Recommendations[3] already point to the need of hardware tokens to achieve a Level of Assurance (LOA) Level-3 or higher, we believe that the TED device offers a flexible and portable computing environment that satisfies the NIST Requirements. We believe the TED device represents a strong token for the subscribers within the e-Authentication model defined within the NIST Recommendation.

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 credentials^a 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.

Trustworthiness and being able of assure identity claims with high degree of confidence also arises in broader collaborative situations, where organizations have to partner with each other over a specific period of time each to achieve a set of mutually desirable outcomes. Typically, each participant will have their own respective policies in place about control and sharing of information, as well as policies that cover exceptions. When brought together, the establishment of identity, who has access to information and the control of access and the information itself forces each participant to consider how to evaluate the trustworthiness of the collaboration and the respective partners.

In terms of the identity claims that are made within a collaboration, adopting the approach taken in this paper would be of benefit to each individual participant. Further, as the cloud service provider is key in establishing and maintaining the collaborative “infrastructure”, the addition of services such as accountability and provenance increases the level of trust in the system and between the participants by providing (if required) additional evidence of “good” behaviour as well as irrefutable evidence of “bad” behaviour.

The goal of this paper is to proposed the use of a cloud-based integrity management service coupled with a trustworthy client component in the form of the portable trust extension device (TED), as a means to to increase the quality of the security evaluation of a client. In addition to performing authentication of the client (e.g. as part of Single Sign-On), the IdP asks that the integrity of the client platform be computed and then be evaluated by a trustworthy and independent Cloud-based Integrity Measurement Service (cIMS).

The portable TED device performs an integrity measurement of the client platform, and sends an integrity report to the cIMS the cIMS validates the measurements performed by the TED device, reports a trust score to the Identity Provider (IdP). The IdP takes into account the reported trust score when the IdP computes and issues a Level of Assurance (LOA) value to the client platform.

This approach provides a path forward for Service Providers to obtain better picture of the state of client end-points, and thereby providing them better assurance of the quality of the client’s computing environment.

It is our intention to demonstrate a prototype system in the near future to elaborate upon, and evaluate, the ideas presented in this paper. Of particular interest to the authors is using concepts behind this paper in extending standard authentication systems such as Kerberos to offer a higher level of assurance of identity claims made to cloud service providers.

^aThese that are unique to each TPM hardware chip and “burnt in” during its manufacture.