Applying Trusted Computing to a Workflow System

Po-Wah Yau, Allan Tomlinson, Shane Balfe and Eimear Gallery

Information Security GroupRoyal Holloway, University of London

www.isg.rhul.ac.uk

Applying Trusted Computing to a Workflow System

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

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

Overview of Trusted Computing

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:

1. Each job is ‘protected’ using a symmetric key,

2. This key is sealed to the required platform state,

3. The platform states to which the keys are sealed are decided/known before workflow execution, and

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

1. Job are ‘protected’ using a symmetric key,

2. This key is sealed to the required platform state of the next resource provider in the workflow,

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