Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Design of a secure "Token Passing" protocol


Published on

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.

Published in: Technology
  • Be the first to comment

Design of a secure "Token Passing" protocol

  1. 1. Secure token passing at application level Augusto Ciuffoletti University of Pisa Pisa – ITALY
  2. 2. 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
  3. 3. 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)
  4. 4. 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...
  5. 5. 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
  6. 6. 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...
  7. 7. 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
  8. 8. Host architecture Token enters here Receiver Sender Port 9000 Process Unix pipe process Token exits here Local read/update Cache read
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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.
  13. 13. 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...
  14. 14. 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.
  15. 15. 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.
  16. 16. 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: