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
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:
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
The WRB’s digital 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 )
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

45. Thank you for listening
Any questions?