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
2
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!
3
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).
4
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).
5
Contents
• Introduction
• Grid workflow security
• Overview of Trusted Computing
• Securing Grid workflows
• Summary
6
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.
7
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
8
Contents
• Introduction
• Grid workflow security
• Overview of Trusted Computing
• Securing Grid workflows
• Summary
9
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.
1
0
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).
1
1
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.
1
2
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).
1
3
Contents
• Introduction
• Grid workflow security
• Overview of Trusted Computing
• Securing Grid workflows:
– Assumptions
– Workflow preparation
– Workflow execution
• Summary
1
4
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
1
5
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
1
6
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.
1
7
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.
1
8
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]
1
9
Workflow preparation (2)
WRB
RPi :
2
0
Workflow preparation (2)
WRB
RPi : IDW
Identifiers of WRB and workflow
2
1
Workflow preparation (2)
WRB
RPi : IDW || ri
Random nonce
2
2
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
2
3
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
2
4
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
2
5
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
2
6
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
2
7
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.
2
8
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
2
9
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
3
0
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-1
RPi : IDW || “ready” || RPi-1
RPi :
3
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-1
RPi : IDW || “ready” || RPi-1
RPi : IDW || C(rRPi)
RPi : Generate random nonce
RPi : Send attestation challenge
3
2
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-1
RPi-1
RPi : IDW || “ready” || RPi-1
RPi : IDW || C(rRPi)
RPi :
3
3
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-1
RPi-1
RPi : IDW || “ready” || RPi-1
RPi : IDW || C(rRPi)
RPi : IDW || F(i-1, rRPi)
RPi-1 : Generates response to attestation
challenge
3
4
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-1
RPi-1
RPi : IDW || “ready” || RPi-1
RPi : IDW || C(rRPi)
RPi : IDW || F(i-1, rRPi)
3
5
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-1
RPi-1
RPi : IDW || “ready” || RPi-1
RPi : IDW || C(rRPi)
RPi : IDW || F(i-1, rRPi)
|| gKi’ (R(ai-1, rRPi) || rRPi)
3
6
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-1
RPi-1
RPi : IDW || “ready” || RPi-1
RPi : IDW || C(rRPi)
RPi : IDW || F(i-1, rRPi)
|| gKi’ (R(ai-1, rRPi) || rRPi)
|| ePKi (Ki’)
3
7
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-1
RPi-1
RPi : IDW || “ready” || RPi-1
RPi : IDW || C(rRPi)
RPi : IDW || F(i-1, rRPi)
|| gKi’ (R(ai-1, rRPi) || rRPi)
|| ePKi (Ki’)
RPi : Verifies F(i-1, rRPi)
3
8
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-1
RPi-1
RPi : IDW || “ready” || RPi-1
RPi : IDW || C(rRPi)
RPi : IDW || F(i-1, rRPi)
|| gKi’ (R(ai-1, rRPi) || rRPi)
|| ePKi (Ki’)
3
9
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-1
RPi-1
RPi : IDW || “ready” || RPi-1
RPi : IDW || C(rRPi)
RPi : IDW || F(i-1, rRPi)
|| gKi’ (R(ai-1, rRPi) || rRPi)
|| ePKi (Ki’)
4
0
RPi : Recovers ai-1, and processes ai
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.
4
1
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.
4
2
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.
4
3
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.
4
4
Thank you for listening
• Any questions?
4
5