PoWah Yau, Allan Tomlinson, Shane Balfe and Eimear Gallery

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 Andys 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 WRBs 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) IDi1 PKi1
• Identifier of resource provider RPi1 to send job
  results to, and
• Public encryption key of RPi1 corresponding to
  Ski1

26
Workflow preparation (2)

• WRB ?? RPi IDW ri gKi (ai r i)
• ePKi (Ki) IDi1 PKi1
• 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) IDi1 PKi1
• IDRPi-1 VKRPi-1 ?i-1 ?W
• The WRBs 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) IDi1 PKi1
• 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) IDi1 PKi1
• 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) IDi1 PKi1
• 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) IDi1 PKi1
• 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) IDi1 PKi1
• 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) IDi1 PKi1
• 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) IDi1 PKi1
• 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) IDi1 PKi1
• 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) IDi1 PKi1
• 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) IDi1 PKi1
• 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) IDi1 PKi1
• 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) IDi1 PKi1
• 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
  users 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?