Building Blocks for Trusted Coordination a status report

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

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, 11 -12 December 03 2

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, 11 -12 December 03 3

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

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 (nonrepudiable) ¨ Implies two building blocks for trusted coordination: • Non-repudiable service invocation • Non-repudiable information sharing ¨ Trusted Coordination ADAPT Workshop, 11 -12 December 03 5

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

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

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

Evidence for non-repudiable service invocation ¨ ¨ ¨ Request evidence includes the service invoked 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, 11 -12 December 03 9

Access and update to shared information B update A update i update C Trusted Coordination 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) ¨ ADAPT Workshop, 11 -12 December 03 10

Non-repudiable information sharing B Evidence required: ) ¨ (3 (4 ) sp ¨ re sl v re pr op (2 ) ¨ A upd (1) upd (5) i re re pr op (2 slv sp ) (4 (3 ) ) 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 C Trusted Coordination ADAPT Workshop, 11 -12 December 03 11

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, 11 -12 December 03 12

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, 11 -12 December 03 13

Implementations ¨ NR service invocation • J 2 EE prototype implementation (JBoss) nearing completion ¨ NR information sharing • B 2 BObjects – 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 • J 2 EE prototype implementation (JBoss) nearing completion Trusted Coordination ADAPT Workshop, 11 -12 December 03 14

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 DSN 02, Washington, US, Jun 2002. N. Cook, S. Shrivastava, S. Wheater. Middleware Support for Nonrepudiable Transactional Information Sharing between Enterprises, To appear as Work in Progress in: Proc. 4 th 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…. Trusted Coordination ADAPT Workshop, 11 -12 December 03 15