TC-Based Certification Models

Trusted Computing-Based Certification Models (TCCMs) represent how a ToC, residing on a TC-enabled cloud platform, can be certified based on TC mechanisms, namely, the TPM [7] and the required hardware and software for that.

Security property. The security property supported by the CUMULUS TC certifi-cation is software integrity with subject of the property the software or applicertifi-cation running on a cloud platform. Given the nature of TC, the trust chain for software integrity measurement and validation is bottom-up, starting with the trust on the TPM and physical platform hosting the TPM chip (i.e., the motherboard) and building up the chain by measuring and reporting the integrity of the firmware and software upper in a platform stack reaching the application layer on the top.

In that case, integrity of applications (software) running on a platform (regardless if physical or virtual in case of cloud) is in function of the integrity state of the underlying platform. The security property supported by CUMULUS TC certification approach is called software integrity bound to platform state. We say

Fig. 8.5 TC-based multi-layer certification

“bound” because the software integrity is assured only for a given integrity state of the underlying platform.

Target of Certification and assessment scheme. The assessment scheme of TC-based certification is TC-based on remote attestation of ToC integrity, a core func-tionality provided by trusted computing platforms [7]. A remote attestation process underpins any CUMULUS TC certification process, i.e., we perform attestation of ToC and its underling platform layers to certify integrity of a ToC. The outcome of such integrity attestation is a TC-based certificate. Correspondingly, an attestation process is also used to validate the ToC’s TC-based certificate and determine if the current ToC’s integrity state matches the one at the time the ToC was certified.

TC-based certification requires TPM virtualization on the corresponding Cloud platform [18]. Figure8.5shows the reference TC-aware cloud computing architec-ture and layers to be reflected by a TCCM:

• Physical Platform Layer. The bottom layer comprises the physical platform and associated to that physical hardware TPM (pTPM) and physical Root of Trust for Measurement (pRTM). The pRTM is responsible for measuring integrity of software (e.g., hypervisor) running on a physical platform and reports those measurements into pTPM’s Platform Configuration Registers (PCRs).

• Hypervisor Layer. The software layer running on top of the physical (hardware) platform. Importantly, upon creation of a new VM, the hypervisor creates also an instance of a virtual TPM (vTPM) associated to that VM and triggers virtual RTM (vRTM), which in turn measures the first code execution of a VM and reports that to vTPM’s PCRs. The hypervisor is in charge of creation and destruction of vTPM and vRTM instances for each VM. The vTPM component

is defined as hardware and/or software realization of the functionality described in the TPM specification [7]. The goal of the instantiated vRTM and vTPM is to make those appear the same as their physical equivalents (pRTM, pTPM).

• Virtual Machine Layer. The top layer of the cloud architecture where VMs reside.

Each VM runs an attestation agent serving (remote) attestation requests from challengers by following a specific attestation protocol, the same as in the case of a non-virtualized platform. The attestation agent in a VM provides attestation evidence about the state of the VM, i.e., about the state of the VM’s system platform and applications running on it by using the vTPM.

There is a dedicated service on the hypervisor layer, called Deep Attestation Service, used to create attestation evidence about the state of the hypervisor [18].

For instance, after an attestation of a VM has succeeded, a Remote Challenger might wish to attest the hypervisor below the VM to determine if it is trustworthy enough to not modify the VM behavior and attestation reporting. Because the hypervisor (the layer below VMs) might also be operating on top of a virtualized platform, the concept of iteratively attesting each individual lower virtualization layer in order to establish the trustworthiness of a VM (and applications running in the VM) is known as a “deep attestation.” In that case, the remote challenger may need to repeatedly attest virtualization layers down until it reaches the bottom-most layer operating on top of a physical trusted platform (with pTPM).

An important aspect of a TCCM is the representation of the available TC support by the underlying to the ToC cloud infrastructure. In fact, such representation is crucial to allow the ToC integrity be properly measured and validated following the TC-specific bottom-up chain of trust (of integrity measurements). To do so, we defined a specific data structure as part of ToC definition, called Target of Integrity (ToI). The role of ToI is to represent all necessary information about the ToC and its underlying platform and cloud infrastructure layers down to a physical platform with a physical TPM.

Important and complementary artifacts to the ToI are the Evidence Collector and Evidence Aggregator. An Evidence Collector is defined per each layer of the ToI, and its role is to represent all necessary information about how software integrity of a given ToI layer is to be attested (collected). An Evidence Aggregator defines how to perform the complete ToI integrity attestation process starting top-down from the top-level application components of a ToI (located in a VM) down through all layers to a physical platform.

Life cycle. There are three main life cycle states defined for TC certificates –

“Issued,” “Expired,” and “Revoked.” The state “Issued” is defined by having evidence collection for ToC integrity and all layers down the cloud stack to the physical layer. The transition from state “Issued” to “Expired” is defined when the certificate is expired according to its time validity period. The transition from

“Issued” to “Revoked” is defined by having a contradictory evidence either of ToC integrity or integrity states of any of the virtualization layers down the cloud stack.

Multi-layer certification. TC-based certification for SaaS-level services requires that a CA/Evaluation Lab must ensure not only the integrity state of all layers down the cloud stack but also must recognize that all virtualization layers down the stack provide correct TPM virtualization (e.g., according to TCG specification [18]). Given that a cloud provider may need to offer several thousands of VMs for customers’ needs, it may become impractical to manage TCCMs if for each SaaS-level service requesting certification the CA/Evaluation lab has to explicitly recognize the hypervisor’s state and its correct TPM virtualization. To address that issue, TC-based certification allows a CA/Evaluation lab to certify services at SaaS level without the need to recognize hypervisor integrity state supporting TPM virtualization but instead to express external integrity state condition to a TCCM certifying the hypervisor state. In that way, the CA/evaluation lab issuing a TCCM for a SaaS-level service does not need privileged access to the hypervisor layer but instead would only need to examine the TCCM of the hypervisor and indicate in the TCCM of the SaaS-level service an external integrity state dependence on the hypervisor’s TCCM. In other words, multi-layer TC-based certification provides layered assurance for cloud services and plat-forms based on the assurance of the integrity states of lower layers of the cloud stack as provided by the relevant TC-based certification processes for those layers. Figure 8.5 illustrates the main aspects of TC-based multi-layer certification.

A TC-based certificate states the TC proofs (integrity evidence) of the ToC’s software and all layers below. Given the multi-layer certification, upon certificate generation, the TC certification manager component (see Fig.8.3) will first check if a certificate exists for the referenced hypervisor’s TCCM and will then validate the hypervisor’s certificate (i.e., whether the hypervisor integrity state still holds according to the certificate-stated evidence). If successful validation, the certifica-tion manager will generate the corresponding TC-based certificate for the SaaS-level service 1 and will include in the certificate an external integrity state condition pointing to the corresponding hypervisor’s certificate. In that way, each time the TC-based certificate of service 1 is validated, the certification manager will first validate the corresponding hypervisor certificate to ensure the referenced hypervisor state holds.