Trusted Computing Integration for Policy-Driven Remote Attestation

A policy evaluation that returns a positive authorisation for a usage request does not guarantee by itself that the policies will actually be enforced once decryption keys have been released to the requesting recipients. Correct enforcement depends on the integrity of the virtual machine’s components and processes running on recipients’

devices. As we described in Section 2.6, verifying the trustworthiness of the accessing applications, as well as of the entire software and hardware environment where data is received, is pivotal for data protection. To this end we integrated our data protection architecture with trusted computing technologies in general and remote attestation mechanisms in particular.

As described in Chapter 2 remote attestation requires that a trusted verifier is able to verify the integrity of a software environment based on a digitally signed list of hash values. The process of verifying this evidence requires the verifier to maintain a large up-to-date database of acceptable software components. However, a simple Boolean decision regarding the presence of untrusted software running on a machine may not be enough to verify its integrity. For example, “acceptable” behaviours may depend on specific compositions of system components and their versions. Or, a data originator might not require a trusted platform verification, preferring easy and fast data dissemination over protection (as it may be the case in emergency scenarios) or deeming simple policy evaluation sufficient. Considering these requirements, usage control policies should

DSA

Figure 3.8: High level architecture for policy-driven remote attestation

be able to specify whether remote attestation is required or not and, if required, which conditions should be satisfied by system components.

Figure 3.8 depicts the high-level data protection architecture with the actual components introduced for re-mote attestation. The PIP adapter is a daemon running on the client machine and acting as a “listener” service that waits for requests on a particular port. It interacts with system-level libraries that measure the system’s state using the TrouSerS (trusted computing software stack) API for accessing the various functionalities of the TPM. In particular, the trusted platform module takes measurements according to the trusted boot process and integrity measurement architecture (IMA) described in Chapter 2. When a policy explicitly requires a mea-surement from the TPM, the PIP fetches it from the PIP adapter and forwards it to the evaluation authority as a credential. It consists of:

• TPM quote (i.e. a signed composite hash of the selected platform configuration registers, PCRs);

• TPM credentials;

• values of selected TPM PCRs (chosen depending on what the policy wants to check - this includes PCR-10);

• the IMA measurement list (i.e. the list of all the executable and application-related files loaded).

We entrust evaluation authorities to act as attestation authorities as connecting to specialised verifiers could be difficult when connectivity is not guaranteed. As we will see in Chapter 5, this also means that every

client machine must be able to act as an attestation authority for other clients and thus store an up-to-date list of the acceptable and expected hash values of various programs. When the evaluation authority receives such a credential, it passes it to its local PIP for further evaluation. The integrity verifier verifies the TPM quote using the credentials provided for the TPM and the received PCR values. In other words, it verifies the signature on the PCRs and uses the IMA measurement to re-compute the value of PCR-10 by aggregating all PCR values. The re-computed value is then compared with the received value to verify the IMA measurement list was correct. Finally, the hash values of the applications (and their versions) in the verified IMA list are checked against the available database to verify that they can all be trusted. Depending on the outcome of the verification process, the integrity verifier returns to the PDP an attestation certificate with the required credentials (e.g. specifying the version of certain libraries, the running applications etc.), as specified by the evaluated policy. The certificate can then be used like any subject or context certificate received by the secure token and certification architecture or directly by the recipient’s client. The same approach could also be used in combination with more complex forms of remote attestation such as property-based attestation [SS04] and dynamic property-based attestation [NV10]. We here propose the basic policy-based attestation mechanism that allows a policy to specify constraints on the specific components in the attested platform. Extending this mechanism to allow policies to specify constraints on a platform’s high-level properties [SS04] would be straightforward.

Using this approach, trusted platform verification is treated as an optional requirement to be included into usage policies and that depends on the discretion of data originators or, in our case, of the authors of the DSA. If policies do not require trusted platform verifications, the PIP adapter and integrity verifier could be removed from the proposed architecture with no effect on the rest of the components, as if they were external certification authorities. In other words, the main advantage of this approach is that it completely separates the policy enforcement components and architecture from the trusted platform components, allowing greater flexibility in the policy specification and enforcement.

3.6 Summary and Conclusions

This chapter mainly served the purpose of “setting the scene” for what is described in the rest of this thesis.

First, we described the high-level threat model and basic assumptions we considered when developing our architecture. We believe the assumptions we considered are realistic and do not hinder the validity of our work.

We then introduced the concept of data sharing agreement (DSA). Despite not being the focus of our work, the existence of a DSA architecture is at the basis of our proposal. It allows us to specify how policies are created

in the first place and distributed amongst data originators. The solutions we present in the next chapters all start from the specification of a set of policies in a DSA, either to define the set of usage control policies (in the set U P) or the set of trusted evaluation authorities (in the set EA). In the rest of this thesis we expand upon the presented architecture introducing the new components that constitute the major contributions of our work.

These components modify the data publication, policy evaluation and enforcement procedures thus enabling derived data control in partially disconnected networks. The content of the DSA is also described in more detail to include the information needed by the new components to work properly.

Finally, we described how we integrated trusted platform technologies into the presented architecture. The system relies on trusted hardware and uses the integrity measurement architecture to verify whether the envi-ronment where policies must be enforced can be trusted. In other words, policy evaluation authorities can verify remotely the set of components installed in recipients’ machines and decide to not issue decryption keys on the base of the configurations found. For example, a machine may be considered untrustworthy if it has installed an anti-DRM software such as QTFairUse, or if it has an old version of the PEP component known for a security vulnerability. Our policy-driven approach allows us to prove the integrity of a system while decoupling autho-risation logic from remote attestation. This grants organisations more flexibility when specifying authoautho-risation policies that can now contain conditions on the hardware and software configuration of the data recipients’

machines. For example, this solution allows the specification of policies where access to data on machines with untrusted components is constrained by more or different obligations, for example higher payments, to balance the risk of data leakage.