1 / 45

Applying Trusted Computing to a Workflow System

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.

aure
Download Presentation

Applying Trusted Computing to a Workflow System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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?

More Related