The trusted third party hosts the trust verifier and the Resource Integrity Measurement Manifest (RIMM) datastore (Figure 4.14). The trust verifier registers the IaaS server’s domain controller and the VM, and verifies the state of the controller and VM in predefined intervals. The verifi- cation of the state is performed by comparing the software measurements from the IaaS server and VM against the reference software integrity values stored in the RIMM datastore.
The RIMM datastore is updated with valid integrity values of safe software either from the RIMM SaaS cloud or by the client. The domain controller of the IaaS server is verified only using the values provided by the RIMM SaaS cloud. In other words, the IaaS is only allowed to execute software that is approved by the community managed RIMM SaaS cloud.
4.4. Architecture 77
The verification of the VM can either be done by the values provided by the RIMM SaaS cloud or by the client. This allows the clients to deploy their own custom trusted applications on the VM.
The software stack of a TTP can be limited to known software as the TTP has a well-defined API. For example, if the TTP is exposing its services using XML web-services, the TTP can be restricted to run a minimal GNU\Linux OS with Java Runtime Environment and Tomcat Apache web server. Therefore the state of the TTP can be in turn verified by any external entity. However, to avoid complexity at the TTP level, we will assume that the the TTP does not need verification and is trusted by the client and IaaS.
RIMM
Datastore
TRUST
Verifier
Figure 4.14: Trusted Third Party
Trust Verifier
The trust verifier is responsible for attesting the state of the IaaS server’s domain controller and VM. It offers the following services:
• register_vm(vm, controller, vm_policy): This service is invoked by the client to register a new vm and controller with a policy with the TTP. This service registers the domain controller referred by the variable controllerand the virtual machine hosted by the IaaS server (domain controller), referred by the variablevmfor verification with a policy specified in the variable vm_policy. In an IaaS scenario, a controller can be shared with multiple clients (multi-tenancy support). Hence a controller could be already
registered for verification by a different client. If the variablecontrolleris not already registered by a different client, this service invokes the service request_ml from the IaaS trust component to verify the server’s state and then it adds the variablecontroller
andvmin its local controller verification list. The variablevm_policyspecifies a set of software versions allowed to be executed in the VM and the predefined interval for the polling of the IaaS server. Section 4.4.5 discusses the policy in detail and Section 4.5.1 details the registration scenario.
• verify_controller_ml(ml): This service is invoked by the VM to verify its con- troller. The service verifies the measurement list, ml against the valid values of the controller and returnstrue, if the verification was successful.
• init_vm_ml(ml): This service is invoked by the serviceinit_mlof the VM trust com- ponent during registration of the VM with the TTP (Section 4.4.1). The measurement list,mlis verified against the policy specified by the client while registration.
• verify(target): Invokes the servicerequst_mlof the target machine. It can be either IaaS server’s domain controller or a VM. The trust verifier verifies if the ml has valid values by comparing it with the reference values from RIMM datastore. The verification scenario is detailed in Section 4.5.2.
RIMM Datastore
The RIMM datastore is the repository of all the valid integrity measurement values of the soft- ware binaries. The RIMM datastore updates its database from two different sources: RIMM SaaS and client. RIMM SaaS is a community maintained database of all safe software values. The client provides the integrity values if they want to host their own custom developed appli- cations that are not approved by the RIMM SaaS5. The measurement values from RIMM SaaS cloud are used as the reference values for comparison with the values from the controller and VM. The client provided measurement values are used as reference values for the comparison with the values only from the client owned VM. The RIMM datastore stores the software hash values in the following format:
4.4. Architecture 79
{id,version,hash value,origin,client id}
The variableidis the unique identifier representing the software binary, the variableversion denotes the version of the software, the variable hash value indicates the hash of the binary and the variableorigintakes two values: globalorclient. When the variablehash valueis
global, the hash value is managed by the RIMM SaaS cloud and when it is client, the client specifies the hash values for this software binary. The variable client id stores the client’s unique identifier and the variableclient idis relevant only if the hash value isclient.
The integrity values are updated using the following service:
publish_client(software_info): The RIMM SaaS cloud or the client notifies the TTP’s RIMM datastore of software updates that were subscribed by the TTP. This service appends the new software update hash values in the datastore and alerts the clients when the IaaS servers and VM do not update their software as recommended by the vendors or clients. The variablesoftware_infocontains the following information:
{so f tware id,prev version,version,update type}
Theso f tware idis the unique identifier representing the software binary. The variableversion represents the current version number of the update. The variable update type denotes the severity of the update. The variable takes one of the two values:criticalandnon_critical. The IaaS server or the VM is expected to install the critical updates as these updates carry se- curity bug fixes. The non-critical updates need not be installed by the IaaS server or the VM. With critical updates, the client is notified immediately if the IaaS server or the VM has not updated the prev version of the software binary with the new version. However, failure to install the non critical updates, leads to passive logging by the trust verifier, that can be in the future observed by the client.