Platform-based control of device identity keys

Identifying the device interacting with cloud services can significantly enhance the overall level of trust we can achieve. The work that follows is part of a wider project whose goal is precisely this, looking at device authentication and attestation by leveraging Trusted Computing Group (TCG) standards for issuing OEM certified lifetime device identities (IDevIDs) and enabling a range of application specific device based identities (LDevIDs). One area of particular interest is in being able to demonstrate the authenticity and integrity of telemetry and control data, which means assuring that it comes from the correct device and that it has not been tampered with. With this project I am trying to go a step further and give additional confidence in the way the telemetry data is generated and hence that it is trustworthy. For example, ensuring that the only correct codebase can collect and report on the data; rather than a substitute telemetry agent than may not correctly report the underlying data. To address the problem, an entire architecture will be explained throughout the thesis, in- volving different components at different levels. The core module is a Policy Enforcement Point (PEP) ideated and implemented emphasizing flexibility, such that it could be a component below the OS (whether in the BIOS or in a service VM). Its purpose is gating the access to TPM keys and, since keys are associated with policies defining how they are used, enforce the indicated constraints. Other key component is what will be referred as the Proxy, which is a Kernel Driver responsible for collecting information between the PEP and any application, recovering all the context related information, also assuring the integrity of the requestor application itself. The development of the PEP has been conducted keeping in mind that it could be moved between the different layers of the system, ideally running in the BIOS or in a protected Virtual Machine. The reason for that is guaranteeing the already mentioned security properties without trusting the OS, therefore forcing every application to contact the PEP before using the related key. For the Proxy Kernel Driver, we must remember that Windows controls the TPM when running through TPM Base Service (TBS), the Windows TPM Resource Manager, so we need to proxy commands from our PEP back through Windows to the TPM. We do this whilst maintaining the security of the key leveraging TPM Sessions between the PEP and the TPM. The additional information are recovered through Kernel APIs, while the assurance of the integrity of the agent is certified by a mix of different security techniques, to avoid the most common attacks.