• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Design of a secure "Token Passing" protocol
 

Design of a secure "Token Passing" protocol

on

  • 3,004 views

Algorithms based on the circulation of a unique token are often indicated in the coordination of distributed systems. We introduce the design of the token passing operation at application level, that ...

Algorithms based on the circulation of a unique token are often indicated in the coordination of distributed systems. We introduce the design of the token passing operation at application level, that exhibits the requirements of security, since the token is a sensitive resource, and scalability, since the token passing protocol must not implement security at expense of scalability. These
characteristics make our solution suitable for large scale distributed infrastructures.

Statistics

Views

Total Views
3,004
Views on SlideShare
2,985
Embed Views
19

Actions

Likes
0
Downloads
17
Comments
0

2 Embeds 19

http://www.di.unipi.it 14
http://www.slideshare.net 5

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Design of a secure "Token Passing" protocol Design of a secure "Token Passing" protocol Presentation Transcript

    • Secure token passing at application level http://dx.doi.org/10.1016/j.future.2009.12.003 Augusto Ciuffoletti University of Pisa Pisa – ITALY augusto@di.unipi.it
    • What this paper is not about ● Many algorithms rely on a reliable token exchange (mutual exclusion, network overlay, etc) ● Few of them describe a protocol that effectively implements such operation ● None of them discusses an application level protocol ● Here we will not discuss an algorithm based on token exchange, but the token exchange itself ● Being implemented at the application level, it can be embedded in any sort of application
    • Basics of a token ● Token presence reflects in the state of the application ● Persistence of several tokens is to be avoided ● Long periods of absence of token are to be avoided ● The token circulates fairly in the system ● A token is never forged, or spoofed (by unauthorized entities)
    • A token passing protocol ● The presence of a token on a host must induce, after some time – the release of the token inside the host holding it, and – the presence of the token inside another host ● We consider that this operation (the token passing operation) is implemented with a protocol based on UDP datagrams ● In order to effectively implement the token passing operation, the protocol must fulfill some requirements...
    • Protocol requirements ● Token passing latency is concentrated around a value: this ensures fairness ● Token passing failure with token loss is an infrequent event: this event deteriorates the performance of the system ● Token duplication is deterministically excluded: it would be extremely difficult to detect and recover from this event ● The presence of several (distinct) tokens in the system is an infrequent event: it deteriorates the performance of the system
    • Protocol requirements ● The source of the token must be authenticated: this ensures that only trusted peers participate in token sharing The above requirement entails the maintenance of a trust relationship among participants. It is the kind of problem that may be solved using a token based scheme, and is related with the topology used to circulate the token. Here we propose a “vanilla” solution...
    • Token circulation topology ● We introduce a full mesh topology (all-to-all) and a randomized circulation of the token ● As a consequence, the membership consists of all hosts sharing the token ● Such membership relies on the existence of a Certification Authority ● All datagrams in the protocol are signed, and exceptionally contain the certificate ● Hosts maintain a cache of certificates, and public keys of the peers
    • Host architecture Token enters here Receiver Sender Port 9000 Process Unix pipe process Token exits here Local read/update Cache read
    • 4-way token exchange protocol ● Types of packets: – Move pkt: submits token exchange – Acknowledge pkt: accepts packet exchange – Commit pkt: confirms token exchange – EarlyStop pkt: stops resending Commit pkts ● All types except EarlyStop can be resent ● Non conformant packets are silently dropped ● All packets are signed ● Resent packets carry sender certificate
    • Sender process state diagram Transition notation: ● event (rcv or timeout) ● ------- ● action (send etc.) Transition arrow: ● blue: high probability ● yellow: low probability ● red: failure Transition label: ● green: send event
    • Receiver process state diagram Transition notation: ● event (rcv or timeout) ● ------- ● action (send etc.) Transition arrow: ● blue: high probability ● yellow: low probability ● red: failure Transition label: ● green: send event
    • Is it real? ● In order to assess the consistency of our specification, we implemented the specification using the Perl language ● It is about 700 lines of Perl code ● Exchanged packets are about 50 bytes long, 4 per token passing operation ● The security issues are partially implemented in the prototype: we use public keys instead of certificates issued by a cert. authority.
    • Does it work? ● In order to assess the conformace of the prototype with respect to the requirements we run two experiments ● The first experiment was run in the real Internet, using a testbed of three hosts located in Italy and Greece ● The purpose was to establish the robustness against Internet failures ● The token kept bouncing among the hosts for as long as 20 days (one bounce every 5 secs) before being lost ● More details reported in paper...
    • Does it work? ● Another experiment was run in a virtual network composed of 10 virtual hosts (using Netkit support) ● In that case, we injected token loss events and induced randomized delays ● Also in this case the results were satisfactory. They are not published in this issue.
    • Conclusions ● A communication protocol that ensures a reliable token passing operation is a basic building block ● An authentication mechanism is required in order to protect from disruptive intrusions These results have been published in the Future Generation Computer Systems journal. The Perl implementation of the protocol is available at the Wandering Token home page.
    • Useful links ● Augusto Ciuffoletti. Secure token passing at application level. Future Generation Computer Systems, 2010. doi:10.1016/j.future.2009.12.003. ● Wandering token home page: http://www.di.unipi.it/~augusto/WanderingToken/index.html