Bridging the GAP between Software Certification and Trusted Computing for securing Cloud Computing

Cloud Computing offers a powerful and fast growing approach to the provision of infrastructure, platform and software services – known as IaaS, PaaS and SaaS services respectively – without the high costs of owning, operating and maintaining the computational infrastructures required for this purpose. However, despite its appeal from the economic, operational and even energy consumption perspectives, cloud technology still raises concerns regarding the security, privacy, governance and compliance of the data and software services offered through it. Such concerns arise from the difficulty to verify security properties of the different types of applications and services available through cloud technology and the uncertainty of the owners and users of such services about the security of their services, and of the applications based on them, once they are deployed and offered through a cloud. This difficulty stems from two facts: (i) that the provision and security of a cloud service is sensitive to potential interference between the features and behaviour of all the inter-dependent services in all layers of the cloud stack, as well as dynamic changes in them; and (ii) that current cloud models do not include support for trust-focused communication between layers.
Trusted Computing (TC) technologies are well suited to provide proofs of the trustworthiness on the lower level of the cloud stack (starting with the hardware layer). One key aspect of these technologies is that they are based on a secure hardware device called Trusted Platform Module (TPM). A TPM is a special- purpose processor capable of providing secure storage and basic cryptography primitives (including key generation/storage, encryption and digital signatures). The TPM is therefore a trusted element that is physically secure (tamperproof) and serves as the origin of a trust chain that can ensure the security of a platform.
Based on the TPM the Trusted Computing Group defines a series of functionalities that can be used to increase the security of different systems. Among these, remote attestation is one of the core functionalities. The basic idea is to verify that a given platform is trustworthy (i.e. the platform is in a known and trusted state) before establishing a communication with it. To achieve this goal, the TPM provides dedicated registers called Platform Configuration Registers (PCR) to store a platform configuration in the form of a hash value. Depending on the scenario, PCRs can also be digitally signed. Based on stored PCRs, the remote attestation mechanism allows changes to a user’s computer configuration to be detected by authorized parties (validating parties). Although the hash would only validate contents of the image of the program but not what the program does computationally. Consequently, the concept of remote attestation works by having the TPM generate a certificate stating what software is currently running. The computer can then present this certificate to a remote party to show that unaltered software is currently executing.
One important criticism that has been raised frequently is that the remote attestation mechanism is very rigid, and valid only for “closed” systems. Thus, it is capable of enforcing compliance with a certain security policy by being tightly controlled and are usually manufactured to rigid specifications. In this way designers have complete control over the whole system and build it specifically to conform to a given security policy. When one closed system communicates with another, it knows within very tight bounds the expected behaviour of the other party. This mechanism fits for lower level of the cloud stack where the hardware configuration is rather static and tightly controlled, but in the higher levels, the frequent changes in user demands and the intrinsic dynamism of cloud computing makes the mechanism difficult to apply in practice.
As defined above, one of the main drawbacks of the remote attestation is that it is completely static and inflexible. It can convey no dynamic information about the program, such as its runtime state, or the properties of the input it is acting upon. It is a one-time operation done at the beginning of a network protocol. Similarly, software upgrades and patches are hard to deal with. Remote attestation, with its stress on certifying particular platform-specific binaries, is fundamentally incompatible with current reality, especially in the case of cloud computing environments. Just as with managing upgraded and patched versions of software, certifying programs that run on a variety of platforms and that must inter-operate with each other, quickly becomes intractable. Remote attestation inherits a problem from public-key cryptography – revocation. Once a certification authority issues a certificate, it is very hard to revoke. One method is to adopt the usage of certificate revocation lists (CRLs), which are looked up at regular intervals. Thus, there may be some time lapse between a certificate being revoked, and access being denied to it. Checking with some revocation infrastructure (such as a CRL) at every attestation would be very inefficient.
A variant of the standard remote attestation called semantic attestation has been proposed in order to overcome the static and inflexible aspects of the remote attestation, making the attestation more flexible and expressive by leveraging language-based techniques and virtual machines. Still, semantic attestation is hard to apply in practice, especially in open cloud computing scenarios. The main problem that semantic attestation does not solve is that it does not provide proofs and guarantees of the security properties that a given piece of software has. In other words, it does not cover assurance and compliance in open environments.
Cloud computing architectures are based on a hardware, software and firmware underlying basis that is stable, in the sense that few changes are done in this basis. However, in the most abstract layers of the software (i.e., applications) changes are produced frequently, different applications are launched in systems sharing resources with a large heterogeneity of other applications with different timelines, resulting in many changes in the system execution stack. The software certification approach is perfectly suited for supporting assurance and compliance.
Although certification has been traditionally targeting humans and has not been able to support automated processing of certifications (i.e. verification, selection based on certifications, etc.), recent advances in this field resulting from the

European research project ASSERT4SOA have produced, computer oriented formats, processes and tools to support the automated validation of certifications and the selection of services based on their certificates (a computer-oriented form of certification called ASSERTS).
These advances represent a solid ground that allows us to undertake the design of a certification system especially tailored to the cloud computing paradigm, where the security of the lower levels of the could stack is based on Trusted Computing, while the security of the higher levels is supported by certification. The approach will also bridge the gap between the two technologies by defining a new type of certifications and an associated infrastructure allowing certifications of the higher levels to refer to TC-based proofs for the lower ones, and by complementing the two with continuous assurance based on runtime monitoring. Consequently, in this presentation I will describe the problems of securing cloud applications, and will present the envisaged solution that will be developed by the CUMULUS project and how this solution will constitute an appropriate mechanism for building a comprehensive trust chain covering the full cloud stack.