Applying Trusted Computing to a Workflow System Po-Wah Yau, Allan Tomlinson, Shane Balfe and Eimear Gallery Information Security Group Royal Holloway, University of London www.isg.rhul.ac.uk Third e-Science Workshop Trusted Services: Requirements and Prospects, 8-9 July 2008, Edinburgh

Contents Introduction Grid workflow security Overview of Trusted Computing Securing workflows Summary

Introduction Grid middleware used to achieve synergy from otherwise disparate resources: Hardware (CPU, storage, computationally steerable equipment), Applications, Data, and People. Security issues when running a Grid job at a resource provider: See Andy’s talk!

Introduction Grid workflows used to achieve automated synergy from multiple tasks: Logical ordering of tasks, Each task can either process results of another task or new set of data, Sequential, parallel, choice branching and loops. Variety of workflow systems: Low level, physical workflows, as opposed to High level (e.g. Pegasus, P-Grade, Taverna).

Introduction Workflow Resource Broker (WRB): Typically maps abstract workflow of tasks to physical workflow of jobs (in a high level system), Selects resource providers to run jobs (according to static requirements), and Schedules jobs (taking into account dynamic requirements).

Contents Introduction Grid workflow security Overview of Trusted Computing Securing Grid workflows Summary

Grid Workflow Security Confidentiality, to protect: An individual job, A workflow of jobs, The workflow/sub-workflow, and The locations of where jobs are submitted. Integrity, to prevent: Error propagation, Wasted resources, and Loss of reputation.

Grid Workflow Security WRB vulnerabilities: Delegated control of user credentials Resource provider selection Scheduling and location of workflow jobs Resource provider vulnerabilities: Complex Grid middleware Local user access Network vulnerabilities

Contents Introduction Grid workflow security Overview of Trusted Computing Securing Grid workflows Summary

Overview of Trusted Computing Defined by the Trusted Computing Group: www.trustedcomputinggroup.org A ‘Trusted Platform’ consists of: Trusted Platform Module (TPM) embedded into the host platform, Protected capabilities, commands, that can access shielded locations (memory, registers), and Creating proxy ‘roots of trust’ in hardware.

Overview of Trusted Computing Three types of key: Non-migratable keys never leave protection of the TPM in which they are created, and are certified by the TPM. Migratable keys can be released by a TPM, encrypted using the public key of the destination, but are not certified. Certifiable migratable keys are keys that are migrated under specific conditions, possibly under the control of a Migration Selection Authority (MSA).

Overview of Trusted Computing Each TPM is shipped with a non-migratable Endorsement Key. A non-migratable Storage root key (SRK) is created when a TPM is initialised/reset: The SRK is used to encrypt other keys, which can then be stored outside of the TPM, If a non-migratable key is used to encrypt data, then that data is ‘bound’ to the TPM, and If use of that non-migratable key is only possible when the platform is in a specific state, then that data is ‘sealed’ to that platform state.

Overview of Trusted Computing Integrity measurement: The ability to record events that modify platform state, which are Stored in Platform Configuration Registers (PCRs) via an ‘extend’ operation. Sealed storage: Binding data objects, including cryptographic keys, to a specific platform state. Attestation: The ability to prove platform state to an external entity, where The PCR values are signed using an Attestation Identity Key (AIK).

Contents Introduction Grid workflow security Overview of Trusted Computing Securing Grid workflows: Assumptions Workflow preparation Workflow execution Summary

Securing Grid Workflows The following proposal uses Trusted Computing to provide: Trusted resource provider selection Confidentiality of job information Integrity of job information Secondary properties: Confidentiality and integrity of workflow Information to possibly assist process provenance

Assumptions Trusted Computing prevalence: WRB platform Subset of resource providers Means of verifying that WRB can be trusted User has a means of specifying high level security requirements: Translated by WRB into low-level platform state requirements

Assumptions All resource providers have a certified copy of the WRB’s public signature verification key. The WRB has a copy of all resource providers’ public signature verification key.

Workflow preparation (1) Consider a workflow of jobs a0, a1, … , an Each job ai is associated with a symmetric key Ki, which will be used to ‘protect’ the job. A private key SKi is also associated with each job ai: This will be stored in a TPM.

Workflow preparation (1) The resource provider RPi can obtain SKi using one of two methods: The WRB creates a certifiable migratable key pair Specifying the state i to which the private key is sealed The key is then migrated to TPM of RPi RPi creates a non-migratable key pair sealed to a specific platform state i: The public key and platform state are advertised as part of an attestation token [Lohr et al. 06]

Workflow preparation (2) WRB  RPi :

Workflow preparation (2) WRB  RPi : IDW Identifiers of WRB and workflow

Workflow preparation (2) WRB  RPi : IDW || ri Random nonce

Workflow preparation (2) WRB  RPi : IDW || ri || gKi (ai || r i) Output of g is the ciphertext and message authentication code for the job and nonce

Workflow preparation (2) WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) Ki encrypted using PKi corresponding to SKi which is sealed to platform state i

Workflow preparation (2) WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 Identifier of resource provider RPi+1 to send job results to, and Public encryption key of RPi+1 corresponding to Ski+1

Workflow preparation (2) WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 || IDRPi-1 ||VKRPi-1 || i-1 Identifier of preceding resource provider, Public verification key of RPi-1 (non-TPM key), The platform state of RPi-1 required by WRB

Workflow preparation (2) WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 || IDRPi-1 ||VKRPi-1 || i-1 ||W The WRB’s digital signature on the whole message

Workflow preparation (2) In summary: Each job is ‘protected’ using a symmetric key, This key is sealed to the required platform state, The platform states to which the keys are sealed are decided/known before workflow execution, and Each resource provider knows the state that the previous resource provider should have been in, in order to execute their designated job.

Workflow execution WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 || IDRPi-1 ||VKRPi-1 || i-1 ||W RPi-1  RPi : IDW || “ready” || RPi-1

Workflow execution WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 || IDRPi-1 ||VKRPi-1 || i-1 ||W RPi-1  RPi : IDW || “ready” || RPi-1 RPi : Verify W and RPi-1 RPi : Retrieve Ki using SKi (sealed to TPM) RPi : Decrypt and retrieve ai , and verify integrity

Workflow execution WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 || IDRPi-1 ||VKRPi-1 || i-1 ||W RPi-1  RPi : IDW || “ready” || RPi-1 RPi-1  RPi :

Workflow execution WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 || IDRPi-1 ||VKRPi-1 || i-1 ||W RPi-1  RPi : IDW || “ready” || RPi-1 RPi-1  RPi : IDW || C(rRPi) RPi : Generate random nonce RPi : Send attestation challenge

Workflow execution WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 || IDRPi-1 ||VKRPi-1 || i-1 ||W RPi-1  RPi : IDW || “ready” || RPi-1 RPi-1  RPi : IDW || C(rRPi) RPi-1  RPi :

Workflow execution WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 || IDRPi-1 ||VKRPi-1 || i-1 ||W RPi-1  RPi : IDW || “ready” || RPi-1 RPi-1  RPi : IDW || C(rRPi) RPi-1  RPi : IDW || F(i-1, rRPi) RPi-1 : Generates response to attestation challenge

Workflow execution WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 || IDRPi-1 ||VKRPi-1 || i-1 ||W RPi-1  RPi : IDW || “ready” || RPi-1 RPi-1  RPi : IDW || C(rRPi) RPi-1  RPi : IDW || F(i-1, rRPi) RPi-1 : Generates symmetric key Ki’ and…

Workflow execution WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 || IDRPi-1 ||VKRPi-1 || i-1 ||W RPi-1  RPi : IDW || “ready” || RPi-1 RPi-1  RPi : IDW || C(rRPi) RPi-1  RPi : IDW || F(i-1, rRPi) || gKi’ (R(ai-1, rRPi) || rRPi) RPi-1 : Protects job results using Ki’

Workflow execution WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 || IDRPi-1 ||VKRPi-1 || i-1 ||W RPi-1  RPi : IDW || “ready” || RPi-1 RPi-1  RPi : IDW || C(rRPi) RPi-1  RPi : IDW || F(i-1, rRPi) || gKi’ (R(ai-1, rRPi) || rRPi) || ePKi (Ki’) RPi-1 : Encrypts Ki’ using public key PKi

Workflow execution WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 || IDRPi-1 ||VKRPi-1 || i-1 ||W RPi-1  RPi : IDW || “ready” || RPi-1 RPi-1  RPi : IDW || C(rRPi) RPi-1  RPi : IDW || F(i-1, rRPi) || gKi’ (R(ai-1, rRPi) || rRPi) || ePKi (Ki’) RPi : Verifies F(i-1, rRPi)

Workflow execution WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 || IDRPi-1 ||VKRPi-1 || i-1 ||W RPi-1  RPi : IDW || “ready” || RPi-1 RPi-1  RPi : IDW || C(rRPi) RPi-1  RPi : IDW || F(i-1, rRPi) || gKi’ (R(ai-1, rRPi) || rRPi) || ePKi (Ki’) RPi : Retrieves Ki’

Workflow execution WRB  RPi : IDW || ri || gKi (ai || r i) || ePKi (Ki) || IDi+1 || PKi+1 || IDRPi-1 ||VKRPi-1 || i-1 ||W RPi-1  RPi : IDW || “ready” || RPi-1 RPi-1  RPi : IDW || C(rRPi) RPi-1  RPi : IDW || F(i-1, rRPi) || gKi’ (R(ai-1, rRPi) || rRPi) || ePKi (Ki’) RPi : Recovers ai-1, and processes ai

Workflow execution In summary: Job are ‘protected’ using a symmetric key, This key is sealed to the required platform state of the next resource provider in the workflow, A resource provider should challenge the previous one to attest to its platform state.

Properties of the scheme Security is provided in both directions of a workflow: Forward – trusted resource provider selection, Backward – detection of compromised jobs. Efficient symmetric key cryptography to protect job data: Symmetric key bound to trusted platform state, via sealed private key. Each platform stores a “secure measurement log”: Potentially useful (verifiable) information for process provenance.

Summary Securing Grid workflows is paramount because a user’s entire dataset is being exposed. Trusted computing can be used to improve trust establishment in Grids. Trust in the Workflow Resource Broker is critical. Proposed a scheme to ensure trusted workflow execution.

Acknowledgements The first and second authors are being funded by the Engineering and Physical Sciences Research Council (EPSRC) UK e-Science programme of research (EP/D053269). The third author is sponsored by the U.S. Army Research Laboratory and the UK Ministry of Defence (Agreement no. W911NF-06-3-0001) The fourth author is sponsored by the Open Trusted Computing project of the European Commission Framework 6 Programme. Thanks to Professor Chris J. Mitchell. For more details of this project please refer to www.distributedtrust.org.

Thank you for listening Any questions?