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

Trusted Coordination ADAPT Workshop, 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?

Trusted Coordination ADAPT Workshop, 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”

Trusted Coordination ADAPT Workshop, 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

Trusted Coordination ADAPT Workshop, 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

Trusted Coordination ADAPT Workshop, December 03 6 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.) Client request response Server

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

Trusted Coordination ADAPT Workshop, December 03 8 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 req Client Interceptor req, NROreq resp, NRRreq, NROresp NRRresp Interceptor Server resp req

Trusted Coordination ADAPT Workshop, 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: 1.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. 2.Service references: require a globally resolvable name for the service, e.g. URL (not the state of the service) 3.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

Trusted Coordination ADAPT Workshop, December 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) A update i B C

Trusted Coordination ADAPT Workshop, December upd (5) 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 only updated if the collective decision is that A’s proposal is valid Incentives to good behaviour stronger than for one-off service invocation Non-repudiable information sharing upd (1) C B prop (2) resp (3) reslv (4) prop (2) resp (3) A i reslv (4)

Trusted Coordination ADAPT Workshop, December 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

Trusted Coordination ADAPT Workshop, December 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)

Trusted Coordination ADAPT Workshop, December 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

Trusted Coordination ADAPT Workshop, December 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,  N. Cook, S. Shrivastava, S. Wheater. Distributed Object Middleware to Support Dependable Information Sharing between Organisations, In Proc. IEEE DSN02, Washington, US, Jun  N. Cook, S. Shrivastava, S. Wheater. Middleware Support for Non- repudiable Transactional Information Sharing between Enterprises, To appear as Work in Progress in: Proc. 4 th IFIP DAIS, Paris, France, Nov  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  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  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….