Building Blocks for Trusted Coordination (a status report from the TAPAS project)

1. Building Blocks for Trusted Coordination(a status report from the TAPAS project) Santosh Shrivastava University of Newcastle ADAPT Workshop, 11-12 December 03

2. Need for Trust • Organisations increasingly use the Internet both to offer services and to use the services of others • This extends to formation of virtual enterprises (VE) for delivery of goods or services • Organisations forming a VE are expected to trust each other to some extent to enable business • However, we assume that organisations forming a VE cannot simply rely on the trust they have in one another • To be of practical use, trust relationships must be managed and observed • How? ADAPT Workshop, 11-12 December 03

3. Need for Trust • Trust is achieved through regulation: • Interacting parties are given mechanisms that guarantee the rights and obligations that each interacting entity promises to honour. • In the worst case, violations of agreed interactions are detected and notified to all interested parties • an audit trail of all interactions needs to be maintained • We refer to this form of regulated interaction as “trusted coordination” ADAPT Workshop, 11-12 December 03

4. Trusted Coordination • Two aspects: • Higher level mechanisms for VE policy specification and enforcement • Contract representation and monitoring • Role based access control • Middleware mechanisms for non- repudiable interaction - the scope of this presentation ADAPT Workshop, 11-12 December 03

5. Building blocks for trusted coordination • Regulation implies an audit trail to monitor interaction and for dispute resolution • Evidence generated is of little value unless irrefutably attributable to its source (non-repudiable) • Implies two building blocks for trusted coordination: • Non-repudiable service invocation • Non-repudiable information sharing ADAPT Workshop, 11-12 December 03

6. request Client Server response Service invocation • 2-party, client-server interaction • Server needs evidence that: • The request originated at the client: non-repudiation of origin (NRO) of the request • The response was received by the client: non-repudiation of receipt (NRR) of the response • Client needs evidence that: • The request was received by the server (NRR req.) • The response originated at the server (NRO resp.) ADAPT Workshop, 11-12 December 03

7. req req, NROreq req Client Interceptor Interceptor Server resp, NRRreq, NROresp resp resp NRRresp Non-repudiable service invocation ADAPT Workshop, 11-12 December 03

8. req req, NROreq req Client Interceptor Interceptor Server resp, NRRreq, NROresp resp resp NRRresp Observations • To guarantee protocol compliance, interceptors must be trusted • Degenerate case is that the interceptors are a trusted third party (or parties) • protocol resembles fair exchange as discussed in the literature • Interceptors can be configured to execute any non-repudiation protocol • For example: to meet different evidentiary requirements ADAPT Workshop, 11-12 December 03

9. Evidence for non-repudiable service invocation • Request evidence includes the service invoked and any parameters to the invocation • Response evidence is the result of the invocation • 3 different types to consider: • Values: require the state of the value at invocation time (or at response time for result). Before evidence generation, must resolve references to local values to an agreed representation of their state. • Service references: require a globally resolvable name for the service, e.g. URL (not the state of the service) • Shared information references: require the state of the information at invocation time (or at response time for result) and a reference to the shared information that is resolvable by the remote party ADAPT Workshop, 11-12 December 03

10. Access and update to shared information • Multi-party, peer-peer interaction • For an update proposed by A: • B and C need evidence that update originated at A (NRO update) • A needs evidence that B and C received the update (NRR update) • A, B and C need evidence that, after update, the information will be in a consistent, agreed state (NRO agreement, NRR agreement) B update i update A update C ADAPT Workshop, 11-12 December 03

11. Non-repudiable information sharing B Evidence required: • State transition proposed by A (propose: step 2) • Decisions on validity of transition from B and C (respond: step 3) • Collective decision (resolve: step 4) Shared information is onlyupdated if the collective decision is that A’s proposal is valid Incentives to good behaviour stronger than for one-off service invocation prop (2) resp (3) reslv (4) i upd (1) upd (5) A reslv (4) resp (3) prop (2) C ADAPT Workshop, 11-12 December 03

12. Infrastructure Requirements • Cryptographic primitives • Digital signatures, secure message digest (hash), secure random number generation • Credential (certificate) management • Access control services • Intra-organisation: map user to role • Inter-organisation: map credential to role • Non-repudiation log • protocol-specific • include signed hash of state in evidence • State store • map hash of state to persistent representation of state ADAPT Workshop, 11-12 December 03

13. Infrastructure contd. • Coordination service to execute NR protocols (configurable to specific protocol) • Membership service (for information sharing only) • Maintain group membership information (mapping members to credentials) • Membership is coordinated using NR protocols executed by coordination service • Communication subsystem • Trusted time-stamping service • To verify a signing key was not compromised at time of use (evidence generation) ADAPT Workshop, 11-12 December 03

14. Implementations • NR service invocation • J2EE prototype implementation (JBoss) nearing completion • NR information sharing • B2BObjects • Realise shared information as object replicas at each member of coordinating group • Regulate access to and update of object state • Group membership and object state only change if all parties agree • Implemented in Java using RMI • J2EE prototype implementation (JBoss) nearing completion ADAPT Workshop, 11-12 December 03

15. References • M. Wichert, D. Ingham, S. Caughey. Non-repudiation Evidence Generation for CORBA using XML, In Proc. IEEE Annual Comp. Security Applications Conf., Phoenix, US, 1999. • N. Cook, S. Shrivastava, S. Wheater. Distributed Object Middleware to Support Dependable Information Sharing between Organisations, In Proc. IEEE DSN02, Washington, US, Jun 2002. • N. Cook, S. Shrivastava, S. Wheater. Middleware Support for Non-repudiable Transactional Information Sharing between Enterprises, To appear as Work in Progress in: Proc. 4th IFIP DAIS, Paris, France, Nov 2003. • C. Molina-Jimenez, S.K. Shrivastava, E. Solaiman and J. Warne. Contract Representation for Run-time Monitoring and Enforcement, IEEE Conference on Electronic Commerce (CEC’03), Newport Beach, CA, June 2003, pp. 103-110. • Paul D Ezhilchelvan and Santosh K Shrivastava. Systematic Development of a Family of Fair Exchange Protocols, Seventeenth Annual IFIP WG 11.3 Working Conference on Data and Applications Security, Estes Park, Colorado, August 2003. • Ellis Solaiman, Carlos Molina-Jimenez, and Santosh Shrivastava. Model Checking Correctness Properties of Electronic Contracts, International Conference on Service Oriented Computing, Trento, November 2003 • Recent work using component middleware is being written up…. ADAPT Workshop, 11-12 December 03