1 / 23

Enhancing Delegation Protocols in Grid Computing: A Study of DToken Vulnerabilities and Solutions

This presentation by Dr. Benjamin Aziz at the 8th International Conference on Trust, Privacy & Security in Digital Business discusses the delegation protocol DToken, used in large-scale distributed operating systems. It aims to uncover vulnerabilities within the existing DToken framework and propose solutions for a more secure version, DToken II. Key topics include the overview of the current protocol, identified vulnerabilities, and essential properties of effective delegation protocols, emphasizing correctness, traceability, accountability, and scalability for improved security in grid computing.

awen
Download Presentation

Enhancing Delegation Protocols in Grid Computing: A Study of DToken Vulnerabilities and Solutions

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. Correcting a Delegation Protocol for Grids Dr Benjamin Aziz School of Computing University of Portsmouth Presentation in the 8th International Conference on Trust, Privacy & Security in Digital Business (TrustBus'11), Toulouse, France, 02 September 2011

  2. Objectives • Study the delegation properties within the context of a recent delegation protocol, DToken, designed for a large-scale distributed operating system • Gain some appreciation of the subtlety of vulnerabilities that can be hidden in even the simplest protocols and propose fixes for those vulnerabilities

  3. Content • Overview of the current DToken protocol • Round-up of vulnerabilities in the current protocol • DToken II: A more secure version • Conclusion and future work

  4. Delegation Protocols • Generally, delegation means some degree of trust that a user (delegator) holds on some entity (delegatee) in carrying out some task on behalf of the user • In computing systems, delegation is often established by means of some delegation protocol, which involves exchanges of; • digital certificates • cryptographic tokens carrying various delegation information

  5. Desirable Properties of Delegation Protocols • Correctness of delegation mechanism • Delegated permissions are handed in the intended manner • Traceability • Unique identity • Accountability • Verifiable traceability by means of cryptography • Non-repudiation • Two-way accountability • Deterministic delegation chains • A chain must be possible to construct unambiguously • Performance • Scalability w.r.t. long of chains of delegation

  6. Grid Systems Sharing of large-scale computational resources among organisations in a virtual collaboration Org1 Org3 Grid Infrastructure ... Org n Org2 Ian Foster’s Anatomy of the Grid: http://www.globus.org/alliance/publications/papers/anatomy.pdf

  7. Grid Computing – User Perspective Resource 1 (Org1) Delegation Step = Protocol Delegation Step = Protocol Resource 2 (Org2) User Trusted Machine Gateway Delegation Enforcement Point

  8. Essentials of the DToken Protocol • Appeared in 2009, designed in the framework of the XtreemOS Operating System (www.xtreemos.eu) • Based on the idea that each delegation step introduces a token (DToken), which: • is signed by both sides of the delegation step • contains information on the delegated permissions • can be used to form a chain of trust from the delegator to the delegatee • Contains other relevant information (e.g. token validity, delegation session identification)

  9. The DToken Protocol Message 1. Message 2. = DToken Gateway (Delegatee) User (Delegator) User’s Signature Delegated Permissions Session Identifier Gateway’s Signature

  10. DToken Integrity • The integrity of a DToken implies that the following two facts can be correctly validated • The consent of the delegator to the delegation step • The consent of the delegatee to the delegation step

  11. Traceability and Accountability • Traceability and accountability are achieved in the DToken protocol by means of the verifiablenon-repudiation property • No delegated permission is used unless it is signed by both sides of the delegation

  12. Deterministic Delegation Chains • Given a set of DTokens, this property states that we should be able to infer the exact delegation chain behind these token 2 4 1 2 3 4 1 3

  13. Design-time Mistakes • A few vulnerabilities where introduced at design time • Non-matching Hash Validation • Delegation Repudiation • Non-deterministic Delegation Chains • Highlighted in a formal analysis by Aziz and Hamilton • B. Aziz and G. Hamilton, Verifying a Delegation Protocol for Grid Systems. In Future Generation Computing, vol. 27(5), pp. 476-485, 2011.

  14. Non-matching Hash Validation • Mismatching of hash values due to different values of the session identifier DS in the two messages of the protocol From Property 1 first hash validation, we arrive at the inequality: hash(CDor,CDee,Vfr,Vto,TS,PDor→Dee,DSDor→Dee)  hash(CDor,CDee,Vfr,Vto,TS,PDor→Dee,DSDor→Dee0) Novice design error

  15. Delegation Repudiation • Delegatee receives permission prematurely, thus is able to repudiate the delegation • The delegatee can use a received permission without signing the permission 1st message of a protocol session U to G 2nd, 3rd messages, different protocol G to itself

  16. Delegation Repudiation • One argument for this style of delegation (i.e. premature permissions passing) is that: Delegation enforcement points will ensure authorization policies are maintained at the point of access to a resource • But, this implies that the robustness of the protocol is dependant on external entities (policies)

  17. Non-deterministic Delegation Chains • The current protocol assumes that it is possible to construct chains from DTokens: • If A delegates to B, and B delegates to C, then C gets two tokens: one for “A->B” and one for “B->C” • Hence, it is possible for C to infer the chain “A->B->C” • Now, consider the following case: A delegates to B (A->B), B delegates to C (B->C), C delegates to A (C->A), A delegates to C (A->C) and C delegates to D (C->D)

  18. Non-deterministic Delegation Chains • D will obtain the following set of tokens: {A->B, B->C, C->A, A->C, C->D} • But from these tokens, D can construct the following “different” chain: A delegates to C (A->C) C delegates back to A (C->A) A delegates to B (A->B) B delegates to C (B->C) C delegates to D (C->D) Original chain A delegates to B (A->B) B delegates to C (B->C) C delegates to A (C->A) A delegates to C (A->C) C delegates to D (C->D)

  19. Non-deterministic Delegation Chains • The essence of the vulnerability is that it breaks chains of trust • Crucial in some areas such as digital forensics and handling of delegated evidence • The vulnerability appears as a result of: • Lack of relationship across the different tokens • richer structure underlying the sets (sets convey little information regarding ordering or multiplicity) • Designers assumed that two-step delegations will correctly scale up to any n-step delegations • Not the case, due to loops!

  20. DToken II: An Improved Version Request for delegation Delegatee signs (session id + request) before receiving the permissions Session identifier is the same in both messages Tokens are passed as lists rather than sets = Multiplicity and ordering preserved

  21. Future Work • Carry out a formal verification of DToken II • Test a model of DToken II within a Grid simulation environment • Implementation DToken II into a real Grid system

  22. Conclusion • Designing of even the simplest protocols can be tricky • Some verification is always necessary when feasible • Vulnerabilities presented in this paperreflected • Novice design mistakes • Invalid assumptions regarding external context and policies • Invalid assumption on the scalability of certain properties, e.g. determinism of delegation chains from 2 to n participants

  23. Correcting a Delegation Protocol for Grids Dr Benjamin Aziz School of Computing University of Portsmouth Presentation in the 8th International Conference on Trust, Privacy & Security in Digital Business (TrustBus'11)

More Related