1 / 14

Building Blocks for Trusted Coordination

Building Blocks for Trusted Coordination. Nick Cook University of Newcastle. Trusted Coordination. Two aspects: Higher level mechanisms for policy specification and enforcement Contract representation and monitoring

travis
Download Presentation

Building Blocks for Trusted Coordination

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Building Blocks for Trusted Coordination Nick Cook University of Newcastle TAPAS Workshop, 25-26/09/03

  2. Trusted Coordination • Two aspects: • Higher level mechanisms for policy specification and enforcement • Contract representation and monitoring • Lower level mechanisms for non- repudiable interaction - the scope of this presentation TAPAS Workshop, 25-26/09/03

  3. Outline • Building blocks for trusted coordination • Non-repudiable service invocation • Non-repudiable information sharing • Infrastructure requirements • Implementations • References TAPAS Workshop, 25-26/09/03

  4. Building blocks for trusted coordination • Trusted coordination addresses VE requirement to regulate interactions (service access, update to shared information, etc.) • 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 TAPAS Workshop, 25-26/09/03

  5. 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.) TAPAS Workshop, 25-26/09/03

  6. req req, NROreq req Client Interceptor Interceptor Server resp, NRRreq, NROresp resp resp NRRresp Non-repudiable service invocation TAPAS Workshop, 25-26/09/03

  7. 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 TAPAS Workshop, 25-26/09/03

  8. 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 TAPAS Workshop, 25-26/09/03

  9. 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 TAPAS Workshop, 25-26/09/03

  10. 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 TAPAS Workshop, 25-26/09/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 TAPAS Workshop, 25-26/09/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) • Recent results from Zhou et al may make this unnecessary • Trusted Third Parties for strong fairness guarantees TAPAS Workshop, 25-26/09/03

  13. Implementations • NR service invocation • Wichert et al’s CORBA service • Lacks protocol detail, (naturally) only addresses value types • Paul Robinson is working on J2EE implementation • 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 (also have initial version running on JBOSS) TAPAS Workshop, 25-26/09/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 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. • J. Zhou, F. Bao, R. Deng. Validating Digital Signatures without TTPs Time-stamping and Certificate Revocation, To appear in Proc. 2003 Inf. Security Conf., Bristol, UK, Oct 2003. • Jianying Zhou’s non-repudiation bibliography:http://www.geocities.com/zhou_jianying/non-repudiation.html TAPAS Workshop, 25-26/09/03

More Related