Applying Trusted Computing to a Workflow System

1. 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

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

3. 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!

4. 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).

5. 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).

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

7. 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.

8. 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

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

10. 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.

11. 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).

12. 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.

13. 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).

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

15. 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

16. 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

17. 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.

18. 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.

19. 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]

20. Workflow preparation (2) WRB  RPi:

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

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

23. 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

24. 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

25. 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

26. 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

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

28. 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.

29. 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

30. 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

31. 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:

32. 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

33. 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:

34. 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

35. 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…

36. 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’

37. 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

38. 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)

39. 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’

40. 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

41. 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.

42. 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.

43. 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.

44. 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.

45. Thank you for listening • Any questions?