G. Danezis
[email protected] Queens’ College, Cambridge
The Implementation of an Auction Protocol over Anonymous Networks Computer Science Tripos, Part II, 2000
G.Danezis – Queens’ College
The Implementation of an Auction Protocol over Anonymous Networks Computer Science Tripos, Part II, 2000 Word Count: Project Originator: Project Supervisor:
11 400 F.Stajano and G.Danezis F.Stajano
Aims of the project The aim of the project was to implement two anonymous communication protocols, MIXing networks and Dining Cryptographers networks, as described by D. Chaum. A simple auction protocol was also to be implemented to illustrate the use of such anonymous communication channels. Work completed A working, but experimental implementation of a MIXing network and a Dining Cryptographers network was produced. Superposed receiving was implemented to perform collision detection and retransmission on the D.C. network. A simple transport protocol was implemented to reconstruct fragmented packets. A simple auction protocol based on the “Cocaine Auction Protocol” described by F.Stajano and R.Anderson was implemented. A new mechanism, called “money escrow”, was invented to prevent frauds, while providing financial compensation and preserving the anonymity of all participants. Special difficulties The lack of any previous implementation of a Dining Cryptographers network and the very abstract description of its mechanisms made its implementation challenging. Much background research had to be done for the proposed “money escrow” mechanisms to be designed. Declaration of originality I George Danezis of Queens’ College, being a candidate for Part II of the Computer Science Tripos, hereby declare that this dissertation and the work described in it are my own work, unaided except as may be specified below, and that the dissertation does not contain material that has already been used to any substantial extent for any comparable purpose. Signed _________________
Date _____________
3
Table of contents TABLE OF CONTENTS ............................................................................................................................. 5 1. INTRODUCTION .................................................................................................................................... 7 2. PREPARATION....................................................................................................................................... 9 REQUIREMENTS AND OBJECTIVES ................................................................................................................ 9 ASSUMPTIONS ............................................................................................................................................. 9 Assumed threat model............................................................................................................................. 9 Assumed network model ......................................................................................................................... 9 Assumed key distribution mechanisms.................................................................................................... 9 STRUCTURE OF THE PROJECT ..................................................................................................................... 10 DESIGN PRINCIPLES ................................................................................................................................... 10 Abstractions used.................................................................................................................................. 10 Abstract networks and concrete implementations ..........................................................................................10 Abstract keys and cryptographic environments..............................................................................................10 Utilities ..........................................................................................................................................................11
Layered implementation ....................................................................................................................... 11 MODULES .................................................................................................................................................. 11 TOOLS USED .............................................................................................................................................. 13 The Java programming language ......................................................................................................... 13 Cryptographic libraries ........................................................................................................................ 13 BACKUP PROCEDURES ............................................................................................................................... 13 BACKGROUND READING ............................................................................................................................ 14 Anonymous networks ............................................................................................................................ 14 Auction protocols.................................................................................................................................. 14 Other..................................................................................................................................................... 14 RELATED WORK......................................................................................................................................... 14 Onion routing networks: mixes with connection state .......................................................................... 14 Freedom network: pseudonymity on the Internet ................................................................................. 14 Anonymous remailers ........................................................................................................................... 15 Dinning Cryptographers Networks....................................................................................................... 15 3. IMPLEMENTATION ............................................................................................................................ 17 IMPLEMENTING MIXING NETWORKS ......................................................................................................... 17 Structure of the mix packets.................................................................................................................. 18 Structure of the mix server.................................................................................................................... 19 Extending the server ............................................................................................................................. 19 Attacks on the current implementation ................................................................................................. 20 Message replay...............................................................................................................................................20 Participating server attacks.............................................................................................................................20 Statistical attacks............................................................................................................................................20
Novel ideas and further research.......................................................................................................... 20 Adding integrity to the mix packets ...............................................................................................................20 Routing packets using alternative routing ......................................................................................................21
IMPLEMENTATION OF THE D.C. NETWORK ................................................................................................ 22 Setup protocols ..................................................................................................................................... 22 Server structure .................................................................................................................................... 23 The problem of state: protocol and retransmission rounds .................................................................. 24 Implementing the superposed receiving collision resolution................................................................ 24 Implementing the combine and broadcast operation............................................................................ 25 Novel ideas ........................................................................................................................................... 25 Efficient broadcast and combine operation ....................................................................................................25
5
Using raw D.C. s: public key cryptography without number theory ..............................................................25
IMPLEMENTING A TRANSPORT LAYER PROTOCOL ...................................................................................... 27 Transport packet format ....................................................................................................................... 27 Packet Reconstruction .......................................................................................................................... 28 Limitations of the transport layer ......................................................................................................... 28 Denial of Service attacks on the transport layer .............................................................................................28 Statistical attacks and traffic shaping .............................................................................................................28
IMPLEMENTING A SIMPLE AUCTION PROTOCOL .......................................................................................... 29 The Auction state machine.................................................................................................................... 29 Remarks on the implemented auction ................................................................................................... 30 “MONEY ESCROW” MECHANISMS TO PROTECT ANONYMOUS PROTOCOLS ................................................. 31 Denial of service attacks against communications and protocols ........................................................ 31 Money escrow mechanisms................................................................................................................... 31 An auction protocol that uses “money escrow” mechanisms............................................................... 31 Objectives ......................................................................................................................................................31 The auction protocol framework ....................................................................................................................32 Some remarks on “money escrow” mechanisms............................................................................................33
4. EVALUATION ....................................................................................................................................... 35 COMPARISONS BETWEEN THE TWO IMPLEMENTED ANONYMOUS NETWORKS............................................. 35 Differences between possible attacks.................................................................................................... 35 Anonymity of actions versus anonymity of participants........................................................................ 35 Bandwidth and scalability .................................................................................................................... 36 Stateless versus stateful protocols ........................................................................................................ 36 Management of addresses, keys and servers ........................................................................................ 36 Interactive versus static protocols ........................................................................................................ 37 CODE REVIEW ............................................................................................................................................ 37 TESTING .................................................................................................................................................... 38 The virtual network............................................................................................................................... 38 The ROTn cryptographic environment ................................................................................................. 38 The test chat clients .............................................................................................................................. 38 5. CONCLUSIONS..................................................................................................................................... 39 OUTSTANDING ISSUES ............................................................................................................................... 39 THREAT MODEL FOR E-COMMERCE............................................................................................................ 39 WHAT KIND OF ANONYMITY PROTECTION? AGAINST GUNS OR JUDGES..................................................... 39 ACKNOWLEDGEMENTS .............................................................................................................................. 40 BIBLIOGRAPHY....................................................................................................................................... 41 APPENDIX A.............................................................................................................................................. 43 CHAUM’S MIXES ........................................................................................................................................ 43 ATTACKS ON THE ORIGINAL PROPOSAL ..................................................................................................... 44 The direct RSA implementation attack.................................................................................................. 44 The flooding attack ............................................................................................................................... 44 The “double block” attack.................................................................................................................... 45 APPENDIX B.............................................................................................................................................. 47 THE DINING CRYPTOGRAPHERS’ PROBLEM: PROPOSAL AND CONCEPTS ..................................................... 47 SUPERPOSED RECEIVING COLLISION RESOLUTION AND SERVICEABILITY GUARANTEES ............................. 48 APPENDIX C.............................................................................................................................................. 51 APPENDIX D.............................................................................................................................................. 55
6
1. Introduction
The original ideas about the implementation of anonymous communication channels and protocols date from the early eighties. Today, twenty years later, the subject is more than ever topical, as more and more people connect to worldwide networks and spend a large amount of their time on them. Fears have been expressed that the traces of this on-line activity, in the wrong hands, could be a threat to the privacy of individuals. The objective of this project was to study two of the proposals for implementing anonymous communication channels. Both the Mixing and Dining Cryptographers networks were proposed by David Chaum, in the early eighties, and have been subject to improvements and the base for further research. Newer proposals were also studied in order to provide more insight into the engineering of such networks. A description of both MIXing and D.C. network is included in the Appendices. The Appendices also present the theory that has been used to produce the project implementation. Experience has also shown that careful thought has to be invested in design mechanisms to prevent the anonymity property of networks to be used to attack or abuse the protocols that are implemented over them. Most of the deployed anonymous remailers were closed down not because of protocol failures but because of misuse. For this reason a “money escrow” mechanism to prevent frauds in the context of e-commerce protocols has been designed. An auction protocol using this mechanism has been designed but not implemented. Instead a simpler auction protocol based upon the “Cocaine Auction Protocol” has been implemented. Insightful conclusions have been drawn from this project on the differences of the two different anonymity protocols and the possible contexts in which they could be used. Novel ways to use or improve these protocols are also presented. Given that an implementation had to be provided some research on the context and the protocols surrounding the original proposals had to be done. Finally areas where further research would be welcome were investigated, including the study of the threat models in the context of today’s networks and the costs of attacking these systems. A more comprehensive study of the protocols to set up and manage the anonymous communications is also needed. During the course of the project four talks were given about mechanisms implemented including a presentation at the Cambridge Security Protocols Workshop 2000, on the subject of “money escrow”.
7
2. Preparation
Requirements and objectives The main objective of the project was to implement a MIXing network and a Dining Cryptographers network. This implementation had to be experimental, given that no other implementation has been found of a D.C. network. A simple auction protocol had to be implemented to demonstrate the use of such networks. The efficiency of the implementation was not a prime objective and could often be sacrificed to the benefit of modularity and ease of extensibility. The implementation was required to be, as much as possible, independent of particular choices of cryptographic ciphers, as well as being independent from a particular underlying network. Assumptions
Assumed threat model We assume for this study that a potential attacker has complete control over the network. The attacker can see all messages travelling through the network and insert, delete or modify any message. However we assume that at least some nodes in the network are not collaborating with an attacker. As mentioned in [1] it is impossible to act anonymously in a network where everybody is collaborating against you. This threat model is typical of the cryptographic and computer security academic community. Attacks are considered “passive” if the attacker is only monitoring actions and is not, in any way, affecting the state of the communications. Attacks are considered “active” if the state of the network is affected by the attacker. Assumed network model We assume a basic network model supporting the operations of sending a message to an address, receiving a message from the network and broadcasting a message to the network. There is no multiplexing done, which means that all the messages addressed to a participant from various others will all be retrieved one by one. It can be assumed that the networks neither hide the identities of the participants, nor protect the integrity of the messages transmitted. However it is assumed that the network is reliable, and in the absence of active attacks, messages will be delivered without transmission errors. Assumed key distribution mechanisms A secure key distribution mechanism is assumed to exist and its construction ws not deemed to be in the scope of the project. This mechanism could be based on the existence
9
of a Public Key Infrastructure, such as “Verisign” or “Entrust”. It could also be implemented using a web of trust or a Global Trust Register [21]. In the implementation a very simple, and often insecure, key exchange mechanism is used where on line key exchange is needed. Structure of the project The overall structure of the project and the organization of the modules were designed before the implementation. A high level overview of the structure and the modules of the project is shown in the diagram below. Chat protocol
Auction protocol
Simple Transport Layer Collision detection MIXing networks D.C. networks Abstract network Structure of the project
Design principles
Abstractions used Abstract networks and concrete implementations The main aim of building the anonymous communication protocols was to be able to experiment on them while they were able to function over real life networks. For this reason an abstract notion of a network was defined on which the anonymous communication protocols would function. The “abstract network” should be able to send messages to an address and receive messages. An extension to the basic abstract network is the “abstract broadcast network”, which in addition the basic operations supports broadcast of messages to a particular group. The received messages have to be demultiplexed by the layers above the “abstract network”. A concrete version of an abstract network would be implemented using TCP/IP sockets. It would simulate the broadcast operation by sending messages to all the registered members of the broadcast network. A test bed network, that logs all the messages would be implemented for testing, debugging and experimentation purposes. Abstract keys and cryptographic environments In order not to tie the applications produced to a particular encryption library a layer of abstraction was designed to hide its details from the implementation of the anonymous
10
communication protocols. A “key centered” approach was chosen to design this layer where all the cryptographic operations are invoked on the keys. The more traditional approach would be to center the abstraction around particular cryptographic algorithms, a practice inherited from the non-object-oriented implementation of many libraries. The functions a key object should be able to perform are to encrypt and decrypt particular byte arrays and provide information on the length of the resulting data. This basic abstraction, further refined, was used to implement both symmetric and asymmetric cryptographic algorithms. An abstract cryptographic environment was defined to keep the node’s keys and provide new keys and random noise. It was planed to produce a concrete implementation using RC4 and padded RSA. A dummy encryption environment, using ROTn, has also been implemented for testing purposes. Utilities Given the low-level nature of many aspects of the project a more effective way to deal with arrays of bytes had to be designed than the native Java byte arrays. For this reason an “abstract byte array” was to be implemented which represents immutable arrays of bytes. Many additional operations have been defined such as “length”, “append”, “subarray”, “pad to length”, “add mod 2” and “convert to BigInteger”. These arrays have been used throughout the implementation saving a great deal of programming effort. Layered implementation A very common way to design network software is to divide the functionality into layers. Each layer can then be designed separately with well-defined interfaces between them. Although this is a common design methodology, it often an inefficient implementation strategy. It is quite usual to merge many protocol layers in order to make a more efficient implementation. Given the experimental nature of the implementation of anonymous communication protocols, and especially the D.C. networks, the choice was made to keep the implementation as close as possible with the theory, by implementing each logical layer separately. This layered implementation has been very useful for testing the different logical layers. It has been possible to design layers representing virtual networks that simply log all the activity or check for some conditions. Each layer could also be tested and evaluated separately. It has also enhanced the extensibility of the system as many layers can be used and combined in order to provide systems with different set of properties. Special care has been taken to evaluate the interoperability of the layers. All these made the implementation and testing easier at the expense of efficiency. Modules We present a short description of the modules of the project,
11
Quns.gd216.anon.dc
This package holds the implementation of the Dining Cryptographers’ networks. It contains classes that describe the state, the messages and perform the retransmissions necessary for the functioning of the D.C. network.
Quns.gd216.anon.mix
This package contains the implementation of the MIXing networks. All the protocol messages and the MIXing servers are contained in it.
Quns.gd216.anon
This package contains the interfaces to generic anonymous networks, and the concrete implementation of both the Mix and D.C. networks on top of a TCP/IP network.
Quns.gd216.comms
This package contains the interfaces defining the abstract communication infrastructure. All the components including the abstract server, address, broadcast server and abstract packets are defined in it. A transport protocol, in charge of reconstructing fragmented packets, is also defined in this package.
Quns.gd216.comms.ip
This package contains the concrete implementation of an abstract network on top of a TCP/IP network. It defines the interface to the TCP/IP network, IP addresses and TCP ports, and a concrete packet format.
Quns.gd216.crypto
All the cryptographic functions and keys used in the project are contained inside this packet. It defines abstract keys and cryptographic environments that provide keys. A concrete implementation of padded RSA, RC4 and a cryptographic environment that provides keys for them is defined.
Quns.gd216.util
The byte array interfaces are defined in this package and an implementation is provided.
Quns.gd216.auction
A “Cocaine Auction” like protocol is implemented in this package. It contains an engine that updates the state and all the messages necessary.
12
Quns.gd216.test
Most of the test classes are defined inside this package. A virtual network that logs all the packets inside a file is implemented. A dummy encryption environment is also defined where the cryptographic operation performed is ROTn. The driver classes for the mix and D.C. networks are implemented here along with simple test “chat” programs.
Tools used
The Java programming language The Java programming language version 1.2 was used in order to implement the anonymous networks and the auction protocol. This particular language was chosen for its platform independence and the high level, object oriented development facilities which it provides. Version 1.2 was preferred over version 1.1 because of the additional programming libraries, such as Collections, which are provided. These are libraries that provide lists, sorted sets and hash tables, which would be are extensively used throughout the implementation. Cryptographic libraries A third party cryptography library was used to implement the cryptographic functions required to implement the project. The “Entrust” [13], “Cryptix” [14] and “ABA” [15] cryptographic libraries were tested in order to find the most suitable one. The “Entrust” libraries, while providing general purpose cryptographic algorithms, were oriented towards building software around the proprietary Entrust public key infrastructure. This was too limiting for the aims of this project. The “Cryptix” library only implemented “Raw RSA” encryption algorithms without providing standard, cryptographically strong, padding such as the PKCS #1 [4] that has been used to implement MIXing networks. The “ABA” library provided all the necessary cryptographic functions while being free of commercial constraints and was therefore considered the most suitable. Backup procedures To be prepared for any possible disaster, backups were taken for every major change in the project code. These were stored on two separate disks on my personal computer and on the Pelican archiving server. Care has been taken to develop the project in a platform independent way. This was greatly helped by the use of the Java programming language. It has proved to be a wise precaution, as the operating system on my machine changed from Microsoft Windows to Debian Linux during the course of the project, without affecting the development.
13
Background reading Given the experimental and research-oriented nature of the project, a lot of time was spent before and during the in studying the wide areas of anonymous communication, protocols and possible attacks. Anonymous networks The implementation of the MIXing networks is based on the research by D.Chaum [2]. Some other proposals for MIXing networks have also been studied including Onion Routing [5], Stop-and-Go mixes [11], and the Freedom network [7]. Some attacks on the original proposal were also studied in [3] and [11]. The paper on which the implementation of the D.C. networks would be based was [1] by D.Chaum. The superposed receiving technique implemented is described in [8]. Further ideas about D.C. networks, including computationally secure serviceability, were studied in [16]. Auction protocols The proposal on which the implementation of the auction protocol is based is the “Cocaine Auction Protocol” described in [20]. Background information on on-line auctions was also studied from [25,26] and [27]. Given that on-line auction systems are available today, some time was spent understanding the way they function. The eBay online auction system has been a very good example [24]. Other Background information was studied about traffic analysis [23] and anonymous cash protocols [22,28]. Related work
Onion routing networks: mixes with connection state Onion routing [5] is very similar to MIXing networks. Its main difference is that it introduces state in the routers by creating anonymous connections. The sender and receivers are considered to be outside the anonymous network. A connection request is sent through the network and each node of the chain keeps record of the virtual circuit. After the connection is established, the two parties can communicate as if through a normal network. This technique minimizes the routing information needed in each packet. An implementation supporting common Internet protocols is available. Freedom network: pseudonymity on the Internet The Freedom network as described in [7] provides the users with pseudonymity. The users can create many alternative identities to protect more effectively different aspects of their activities. The Freedom network, run privately by Zero-Knowledge and its partners, tunnels the IP traffic, removing all identifying information such as IP and mail addresses. 14
Like in the onion routing proposal an anonymous route is set up across the network. Therefore Freedom should be more vulnerable to traffic analysis, than a mixer that chooses a different route for each packet it sends. In [6] attacks are described against the freedom network and fears are expressed concerning the security of the system against statistical attacks done using traffic data. More robust traffic shaping is to be implemented in the future, while only a light version is supported at the moment. It is worth noting that much of the design and the engineering decisions for constructing the network were taken to minimize the potential of abuses. It has been noted that most of the anonymous services have failed not because of technological or cryptographic attacks, but because they have been abused by sending defamatory or insulting messages. The Freedom network tries to address this problem by being able to cancel the “pseudonymous” accounts of potential abusers. Anonymous remailers Many anonymous remailers exist. They are divided in two categories: Level 1 remailers just forward the messages received removing all original sender information. These obviously fail to the most basic attacks. Level 2 remailers are actually receiving encrypted email, and forward the decrypted version. As noted in [12] the traffic volume is so low that an attacker in control of the network could easily find the identities of the original senders. Some attacks and the general structure of Mixmaster, the Cypherpunk Level 2 remailers can be found in [12]. Dinning Cryptographers Networks Although the original proposal dates from 1981, no implementation of Dining Cryptographers networks has yet been made public.
15
3. Implementation
The implementation of the two types of anonymous communication layers was an opportunity to gain a deeper understanding of this computer security research field touching anonymous communications and protocols. Some novel ideas were developed alongside with the implementation of the communication protocols. A more clear understanding of the structure of the MIXing and especially D.C.1 has also been developed and can be found in the Appendices. Anyone who is not familiar with the theory behind these networks is invited to read these appendices. The study of anonymous auction protocols, and the problem of deadbeat bidders that is not addressed in many of them, has led to the development of a new protection mechanism, “Money Escrow”, during the project. This mechanism, although designed in reasonable details, would be difficult to implement because it would require an implementation of electronic cash and complicated cryptographic mechanisms such as blind signatures. For this reason the “Cocaine Auction Protocol” that provided the inspiration for this project was used instead. Implementing MIXing networks The implementation of the MIXing network is a directly inspired by Chaum’s description in [2]. Given that the paper was written in 1981 and attacks were described against the RSA implementation in [3] the methods used in the implementation kept the spirit but not the letter of Chaum’s proposal. As Chaum suggests at the beginning of the original proposal, in an ideal world everyone would be a mixer. Following this paradigm, the implementation assumes that each participant, in the network, is a mixer.
1
D.C. stands for Dining Cryptographers.
17
Structure of the mix packets Encrypted under the key K1 Session Key (K1) Encrypted under the key Kn Encrypted using the Encrypted under the key Klast mix’s RSA key
K1
IPn
Kn
IPlast
IP Address of the next mix. Header for the next mix •
Klast
IPlast
Message 1
Header for the last mix
Message n
Message with possible “junk” at the end.
The session keys (K1, … , Kn, Klast) are encrypted under the public key of the mixers.
Structure of a mix message. In the current implementation of the mix server message, the public key of the server is used to encrypt a 128bit RC4 key. The encrypted RC4 key is used to encrypt the address and the rest of the packet. For doing the RSA encryption, the PKCS #1 [4] standard from RSA Laboratories is used. The padding provided by that standard protects the system against attacks based on the pure RSA implementation, such as the ones described in [3]. It also destroys the algebraic properties of pure RSA in such a way that blinding attacks cannot be used in order to repeat messages. Stream encryption is done using the RC4 key. It is worth noting that the stream encryption is done continuously on the address concatenated with the rest of the message, and not block by block. This prevents the “double block” attacks, which are possible against the original proposal. The stream cipher does not protect the integrity of the encrypted message. If an attacker knows the plain text he can substitute whatever he likes. In the case of the addresses it does not seem to matter, as they should be unknown. It is possible to detect random tampering by requiring the addresses and the messages to contain some redundancy that could be checked by every intermediate mix and by the final recipient. Such redundancy could be implemented at higher layers, including the application layer. As the mixer could also be the final recipient, a block encrypted with the recipient’s public key is always included. The address in this last “header” block should be the address of the mix, so that when the message is decrypted it is kept in the Node. The existence of this last block provides some confidentiality between the sender and the recipient and makes it easier for the recipient to detect that a particular message is addressed to him.
18
Structure of the mix server Mix Server
Network
Network
Insert own messages
Waits for a N messages
Sends the messages
Retrieve own messages
Decrypts the messages
Sorts the messages
Discard the messages that do not decrypt
Function of the implemented Mixing Node The general structure of the mix server is as described by Chaum in [2]. Provisions were made so that the server could send messages and receive the messages that were addressed to it. The messages of the mixer are inserted in the same buffer as the messages coming from the network. That ensures that they are properly mixed with the other messages relayed. The messages addressed to the mix server are removed from the batch as they are decrypted. Messages that contain a PKCS#1 block that cannot be decrypted are silently discarded, and replaced by fetching another message. Extending the server In the current version of the server a list of messages received is not kept, so message replay attacks are still possible. This feature would need to be implemented in the core of the server, where messages are received. It would not be appropriate to keep a hash of the whole message, as an attacker could replace the junk and repeat the messages. Keeping the first block (containing the encrypted RC4 key and the encrypted address) would be appropriate if the address’s integrity is protected. The safest option would be to only keep the first half-block containing the encrypted RC4 key. Given that a new session key has to be generated for each new message and collisions are improbable (with a key space of 2128) this should provide a good protection against repeated messages. With extensibility in mind, packets provide many functions of the mix. A packet should be able, given the key of the node, to return the address of the next mix, as well as the packet to be sent to the next mix. Many kinds of packets ware implemented. The first kind is used while constructing the packet and keeps all the information in clear until the packet is sent. The second kind of packet implemented represents a packet in transit, and is used in order to route the packets inside the network. In order to implement return addresses a new kind of packet could be implemented without any other modification to the server. The main difference is that the striping for a return message is different from the striping of a normal message, and therefore a way to detect the type of an incoming message would be needed. A return address can also only be used once.
19
Attacks on the current implementation In this section some attacks that particularly affect the implementation of the MIXing server are presented. A list of attacks against the original proposal, including the “double block” attack that has been discovered during the course of the project are presented in Appendix A. Message replay Replay attacks can still be done on the current implementation. The most general instance of them is including the same message twice in the same batch. The output batch is then going to include two identical messages making it possible to know the next hop of the original message. Participating server attacks As the messages destined for the server are removed from the batch only after the decryption, and are not replaced, it is possible for only one message to remain in the output batch. If the attacker is following a message, and he somehow knows that the message is not destined to this particular mixer, this would reveal its destination without any effort from the side of the attacker. The same is not true for messages that cannot be decrypted, as others are fetched to replace them. Statistical attacks In the current implementation it is possible for an attacker to tell when a message is being sent or is being received by a particular mix. This could help potential attackers to create statistical correlations between nodes that send and receive. Much more research has to be done on the statistical side of traffic analysis. Worrying reports were produced by the onion routing project [5] that without including traffic shaping it is possible to tell what connections are established. The same problem was reported by the Freedom network [6] project, which does not implement traffic shaping in its current implementation. Novel ideas and further research Adding integrity to the mix packets In order to avoid attacks such as the “double block”, it would be a nice feature to provide a mechanism that would let intermediate nodes check for the integrity of the packet in transit. This could not be done using hash functions: if they were transmitted in clear, they could be replaced by the hash of the tampered message. On the other hand including the hash of the message inside the message would reveal the length of the message to the intermediate mix and therefore through how many mixes it has been. A solution could be the following: In each header block two more keys are included. The first one is used to check the MAC included with the message; the second one is used to
20
compute the MAC to include with the message which is transmitted to the next destination. By including each key twice (one in the header block of the mix creating the MAC and one in the header of the mix that will check the MAC) the integrity of the packet can be checked at each mix. This technique fails if a mix in the mix chain of the message tampers with the packet, but protects against tampering done at any intermediate communication channel. Routing packets using alternative routing If more than one address is included in each encrypted header, followed by the encrypted header blocks for more than one participant, the mixer could choose between two alternative routes. It would then strip its header block and strip all the blocks but the one addressed to the appropriate next mixer. The message must then be padded with more than one block before it is output. This could be useful if some mixers in the network are not always available. It could also lead, in the case of a dishonest mix, to the cancellation of the MIXing effect of the next node. If both of the routes are used then the next two mixers will output the same message, giving away the address of the mix after them. This routing strategy can be very expensive, as it increases the meta-information that should be contained in the packet headers, making the data payload smaller. It could though be used in order to establish virtual paths that possibly are less vulnerable to traffic analysis. After the route has been established, the mix nodes could randomly route the packets between the alternative routes. This could also provide some resilience mechanism in case some mixers become unavailable.
21
Implementation of the D.C. network The implementation of the D.C. network was a challenging part of the project. Although the original proposal dates from 1985, no implementation is publicly available, and no report about experiences developing such networks has been found. Both the original research paper and the further work done in Karlsruhe, by the Pfitzmann group, treat the subject in a very abstract way, without referring in detail to specific implementation strategies. Although the functions of the network are described abstractly but in detail in the literature, no detailed study of the setup and key exchange protocols is presented. Additional problems of managing distributed state and maintaining consistency between the different D.C. nodes, often in the presence of attacks, is not discussed either. Therefore an important part of the project was exploring these areas and designing an implementation that addresses these problems. The aim of the D.C. implementation was to follow the original research proposal by Chaum, and to provide the “superposed receiving” collision detection and retransmission mechanism proposed by the Pfitzmann group. An additional aim was to let users connect to a D.C. network while it is running, which would be a prerequisite for any useable system. A simple topology discovery mechanism was implemented, but it was not robust enough to resist attacks that would aim to corrupt it. Efforts were made so that attacks that try to affect the state of the network would not affect the anonymity of the systems. Often the choice has been made that the network should stop functioning rather than opening itself to attacks that could potentially compromise the anonymity of the participants. This makes the network implementation more open to denial of service attacks in general. Setup protocols Each new member of the D.C. network has to follow a protocol before taking part in the communications. The initial connection can be established with any member of the D.C. group that is already completely in the network. Calling the node that wants to connect Node 1, and the one already in the network Node 2, the steps are the following: 1. Node 1 sends a topology request to Node 2. 2. Node 2 replies giving the topology of the network, i.e. all the nodes in the D.C. network with the key connections between them. 3. Some key exchange protocol runs between Node 1 and Node 2. Given that the exact nature of the key distribution mechanism is not known, and outside the scope of this work, an insecure exchange was implemented. This could very easily be replaced once the key exchange mechanisms are specified. 4. Node 1 sends a key connection request to Node 2. 5. Node 2 can accept or reject the key connection request and acknowledges to Node 1.
22
6. Node 1 broadcasts a message to all the members of the D.C. with information about the round into which it will start transmitting and its key connection. In this way all the participants in the network can update their topology tables. After the connection has been established: 7. When Node 1 receives a round result, it sends its personal result for the next round. Steps 2 - 6 can also be repeated when a node is already in the D.C. network to establish more key connections with other nodes. The setup protocol assumes that at least one of the participants is already in the network. For this reason, a bootstrap mechanism was implemented, that let the first participant simulate the fact that he already is in a network. Server structure Abstract network
D.C. specific methods: Connect, Request Topology, etc
Consult and update the D.C. state
Message fetcher
D.C. State Route incoming messages by type
No direct reply modules Abstract Network
Packets in
Packets out (Direct replies)
Direct packets out (Part of a protocol)
Structure of the D.C. server The server is structured around an internal thread that fetches the packets and processes them. The protocol layer above the D.C. server can call functions of the server in order to connect to a D.C., exchange a key, send or receive a message.
23
The multiplexing of the messages received is done according to their types. When the message fetching thread gets a message it executes the handler that has been registered for this particular type of message. Handlers for the standard types of messages are registered by default, but others can be added dynamically, extending or overriding the functionality of the server. This handling mechanism can by default only support one exchange of a particular type (key exchange, message exchange, connection request) taking place at a given time, but special handlers can be written to overcome this problem. The standard message handlers can be divided in two broad categories: the ones that reply immediately and the ones that just hold the message and can pass it to any method asking for it. The first type is used to reply to key exchange requests, topology requests and connection requests as well as sending the personal message as soon as the final result of the previous round has arrived. The second category of handlers is used to code the requests (topology requests, key requests and connection requests) that need to wait for a reply, and processes the reply in the same context as the request. The problem of state: protocol and retransmission rounds The state of the server is protected in a separate module that can only be accessed and modified using methods. This safeguards the consistency of the server state. The state includes: 1. The topology of the network, as communicated originally by the connecting node and subsequently updated by the different connection messages received. 2. The different keys shared with other nodes in the network. 3. The key connections shared with the other nodes in the network, along with the activation round. 4. Information about the current round. 5. Information about the final messages received, collision detection and resolution trees. 6. If the node is also the broadcaster for the D.C., the information about the personal messages received. It is very important for a node to know in which D.C. round it is and in case of collisions what retransmission round it is in. It is also quite dangerous to repeat the same encryption of a round with differing or blank plain text as this would give away the message sent by this server. Using a stream cipher helps to avoid this attack, as the encryption material is sequential and therefore independent of the round. Implementing the superposed receiving collision resolution In order to implement the superposed receiving a similar tree data structure was used as described in [8] (details are also included in Appendix B). Each message is added to this message tree and the other possible messages are calculated. If after this operation the tree is not complete the same retransmission round is continued and the appropriate nodes retransmit. 24
When a new node connects to a D.C. network it should not transmit any messages before a new retransmission round has started. In that way it is sure that it can reliably reconstruct the retransmission tree, and therefore knows when to transmit or retransmit if a collision occurs. The implementation of the superposed receiving tree is provided in Appendix C. Implementing the combine and broadcast operation The method chosen to implement the combine and broadcast operation was by sending all the personal messages to a node that combines them and broadcasts the final result to all the D.C. participants. The node that performs this operation must be trusted not to change or delete messages. The threat model, that includes active attacks, would let an external attacker perform all the possible attacks that the combining node could do anyway. To perform the combination the node does not rely on the topology maps, given that a node crashing would make them obsolete. The node uses the fact that each personal message includes the names of the keys used to encrypt it: it then expects to see each shared key exactly twice before performing the combination operation and broadcasting the final result of the round. This assumes that the graph of the D.C. network is connected. Novel ideas Efficient broadcast and combine operation A more efficient implementation of the combine and broadcast operation performed by the D.C. network could take into account the physical topology and physical connections of the network used. The nodes could be arranged in a tree structure where the children of each node transmit their personal messages to their parent node, which will combine them and forward them to its parent as its personal message. The root node will combine the messages of its children and will get the final message for the round. It will then push down the final message, which should flow down the tree. The tree should be created in such a way to minimize the overall traffic in the network. It is important to remember that the security of the D.C. network is not influenced by the way the combine and broadcast operation is performed, as it does not influence the keysharing graph. This kind of topology creates an imbalance in the sense that the root node, and the nodes that are closer to the root, will know the final result of the round before the others. This could lead to denial of service attacks where the root node acts as a “censor” and pushes down the tree only messages with which it agrees. Using raw D.C. s: public key cryptography without number theory In [9] J.H.Ellis describes how the predecessor of GCHQ discovered public key cryptography. The first system that inspired this invention was described in a BellTelephone report [10]. It proposed that the recipient could mask the sender’s speech in a telephone conversation by adding noise to the line. The sender would then be the only one to be able to remove the noise and recover the original speech. Problems prevented
25
this system from being practical but it provided a source of inspiration and a proof that asymmetric encryption techniques could exist. The trick described by Bell can be repeated on a D.C. network to provide the same functionality as public key cryptography. This system uses the fact that there could be collisions in a D.C. network in order to mask the content of messages sent. Therefore any kind of collision detection and resolution, such as superposed receiving, should be turned off. When a participant wants to send a secret message to someone else it broadcasts the name of the receiver and the length of the message in rounds. The receiver then floods the next rounds with random noise while the sender is sending his message. All the participants see the message superposed with the noise and are unable to retrieve it. The only one who is able to retrieve the message, because he knows the noise, is the receiver. This is a very primitive way to implement asymmetric cryptographic systems, as it does not require the sender to directly share a key with the receiver. The system is secure as long as the attackers are not able to “split” the key-sharing graph in such a way that the sender and the recipient are in different sub-graphs. In that case the attackers would be able to see both the noise and the message in clear.
26
Implementing a transport layer protocol Both MIXing and D.C. networks must be implemented on reliable communication channels. In the absence of attacks the messages fed into these anonymous protocols should reach their destinations free from transmission errors. In order to achieve that on a D.C. networks special collision detection and retransmission mechanisms, such as superposed transmission, must be used. Complications arise from the fact that the anonymous networks implemented have a fixed, usually small, packet size. This is necessary in MIXing networks in order to make all packets the same length, and in D.C. networks in order to maximize the interactiveness of the system by not requiring a huge amount of data to be transmitted for small messages. This forces larger messages to be split into many smaller packets in order to be retransmitted on the anonymous networks. In both networks the contents of each packet will arrive without transmission errors but the order in which the packets are going to arrive or the time intervals between them are random. For this reason a simple transport protocol is needed in order to split the messages into small packets and to reconstruct them at the recipients end. Transport packet format The maximum length of higher level messages is 216– 1 bytes. Each transport packet contains a header of 7 bytes and a variable data load with a maximum size of 255 bytes. Given that the networks cannot guarantee that any particular packet will arrive first to the destination, all the packets contain the necessary information in order to initialize the packet reconstruction data structures on the recipient side. For that reason all packets contain information on the total number of packets needed in order to reconstruct the higher level message.
Label
:2 bytes
A Label that uniquely identifies the higher level message.
PacketNum
:2 bytes
The serial number of the transport packet. It can range from zero to OfTotal-1.
OfTotal
:2 bytes
The total number of transport packets under the packet’s Label.
Length
:1 bytes
The length of the data in this particular packet.
Data
:Length bytes
The actual data contained in the packet.
The byte structure of a Transport Packet
27
Packet Reconstruction The sender can very easily split the packets and send them to the recipient. The recipient needs to reconstruct the packets that will most likely have arrived out of order. In order to do this a hash table indexed by the transport packet labels is created. A packet with a label never seen before creates an entry in the table containing an array of the same length as the number of packets contained in the particular higher level message. The data payloads of the packets with the same label number will then be put in the array. A counter is kept for each entry that indicates how many packets have been added to the array. Then there are as many packets in the array as packets in the message, the data is concatenated and the message sent to the higher network stack layer. Limitations of the transport layer Denial of Service attacks on the transport layer A new entry in the reconstruction hash table is generated for each transport packet with a previously unseen label. These entries are only deleted when the whole message has been generated. No timeout mechanism is implemented. This could lead to some entries never being deleted if a transport packet is lost in the network. An attacker could also use this weakness to fill all the available hash table entries with single transport packets, which would stop any other packets from being reconstructed. In order to avoid these problems a timeout should be associated for each entry. When it expires, the entry should be deleted. The same should be true for entries that receive packets which headers’ are inconsistent. A retransmission mechanism could help to reconstruct messages in case some transport packets are lost in the network. Implementing such an extensive transport layer was outside the scope of the project. Statistical attacks and traffic shaping The fact that long messages are divided into smaller ones could compromise the anonymity of the networks. In a MIXing network an attacker could observe the number of messages sent and received by the nodes and could deduce who is communicating with whom. The fact that the mix implementation is routing each transport packet using a different route reduces the danger of an attacker being able to follow the path of the packets from the sender to the recipient. Networks that establish anonymous circuits, where all the traffic follows the same route, are more susceptible to such an attack [5]. In order to be certain that the number and timing of messages does not provide the adversary with information that could be used to trace the communications, traffic shaping techniques could be used. The traffic could be distributed in time in order to provide a more effective mixing of the packets. Additional fake messages could be periodically sent in order to hide the real number of messages sent and received.
28
Implementing a simple auction protocol A simple auction protocol has been implemented in order to illustrate the potential use of anonymous communication networks. The auction protocol is inspired by “The cocaine auction protocol” proposed in [20] by F.Stajano and R.Anderson.
bid
init
msg
round sInit
win sRound round
sEnd X
Receive message X
X
Receive message X anonymously
The auction protocol state machine
The Auction state machine The state of the auction is held on each node participating in the auction protocol as a bidder and in a node representing the auction house. The protocol has been designed to be used over a network where all the messages are broadcasted, and therefore particularly suits the D.C. network. Each node receives all the messages and can therefore update the local state of the auction. The auction can be in three states. The first state is when the auction is being initialized. A message init is sent by the auction house describing the nature of the goods auctioned and the other parameters of the auction like the expiry time and the amount by which the price of the auctioned goods will be increased in each round. The auction house then sends the first round message, which puts the auction in the first round state. With each round the new value of the goods is communicated. As soon as a bid message is received the auction house sends the next round message. Each bid message contains the value of the bid in order to avoid confusions and race conditions. When a round times out without a bid, the winner of the previous round is considered to be the winner of the auction. A win message is then broadcast by the auction house, which puts the auction in the “end” state. The key contained in the winning bid is included in the win message. The winner can then send back a msg message to arrange a meeting where the goods will be exchanged.
29
Remarks on the implemented auction All the messages sent by bidders can be completely anonymous. That guarantees that the house will not know their identities, and the protocol is therefore anonymous. On the other hand, the messages sent by the auction house must be authenticated. A failure to do so would lead to a system which is very prone to denial of service attacks. The protocol as noted in the original proposal does not protect against cheaters. The protocol is vulnerable against deadbeat bidders, which could bring an auction house to its knees by making all its auctions fail. This problem was studied in detail and a “money escrow” mechanism was designed to impose a penalty on anyone using such practices. Other possible ways in which the auction house could cheat is by not giving the goods to the highest bidder or by participating in its own auctions. The first attack would be easy to detect in a network where all messages are broadcasted. The anonymous communication protocols as implemented do not offer a very good environment for interactive auctions to be performed. This is due to the fact that interactive auctions rely on an element of competition to place the bids, while the anonymous communication layers implemented do not guarantee that messages will arrive in the chronological order in which they were sent. The use of an anonymous timestamp service could help to resolve this problem.
30
“Money escrow” mechanisms to protect anonymous protocols
Denial of service attacks against communications and protocols A great challenge in designing anonymous communication protocols is to avoid denial of service attacks on the communication itself. M. Waider and B. Pfitzmann have discussed various methods of archiving this for D.C. networks in [16] and [8]. Once the problems of attacks against the anonymous communications infrastructure itself have been addressed, the problem of attacks against the protocols implemented over it becomes important. Traitor tracing schemes have been proposed to prevent fraud in anonymous elections and anonymous cash. These would disclose information about the identity of a user who is double spending or double voting. Many of them are based on blind signature schemes proposed by Chaum in [17]. A general technique named “identity escrow” was described by J.Lilian and E.Petrank in [18], where a trusted third party holds the identity of the participants in an anonymous protocol, and can disclose it in case of cheating or another extraordinary circumstance. Money escrow mechanisms Pushing further the idea of Identity Escrow, a new mechanism has been invented to protect anonymous protocols against fraud. In the case of electronic commerce protocols, where payments are made online, the identity of cheaters is not of great utility. The cheaters cannot easily be excluded from the service based on their identities, because it is anonymous, and a court case to sue them could be expensive. For this reason a merchant does not need to know the identity of the cheaters, but needs to be provided with a financial compensation in case of cheating. This compensation is also likely to stop potential abusers, as their acts would cost them money. This mechanism, named “money escrow”, can be implemented by having third parties escrowing electronic payment tokens instead of identities. Special care must be taken to design the protocols in such a way that neither the third party nor the merchant could use the compensation without reason. An auction protocol that used a “money escrow” mechanism to stop deadbeat bidders was designed and presented by the author in the Cambridge Security Protocols Workshop 2000 [19]. An auction protocol that uses “money escrow” mechanisms Objectives The aim of this auction protocol is to provide the auction house with a payment token corresponding to the highest bid and the winner with a proof of ownership of the goods. The identity of the participants should remain secret to both the auction house and the trusted third parties. The protocol should impose a financial penalty on deadbeat bidders and in such case provide a financial compensation to the auction house.
31
It is very important for an auction house to impose a penalty on deadbeat bidders. While this practice does not impose on the auction house any direct loss, it raises the costs of
Money Escrow Agency Give certificate of ownership, then… - Request private key in case of no message. - Request compensation coin in case of invalid money.
Compensation coin, Kv, Kd, Conditions Certificate: {Kv,Conditions} (Singed by the agency)
{Protocol Data, {Payment}ke}ks, Certificate
Bidder
Certificate of ownership {Kd}Ks
Auction House
Auction using a money escrow mechanism running the auctions and more importantly brings the auction house into disrepute. Continuous use of extremely high bids which are not honoured, can also completely stop the auction house from functioning, as all of its auction would fail. The auction protocol framework 1. Before initiating any contact with the auction house, the potential bidder sends anonymously a message to the trusted third party which acts as the Money Escrow Agency. The message contains a verification key, a decryption key from an asymmetric key pair, a compensation payment token and the conditions under which these should be disclosed. Bidder → Money Escrow: Compensation Token, Kv, Kd, Conditions 2. In response the Money Escrow Agency sends a certificate to the user, containing the verification key and the conditions of usage, stating that it accepts to act as a Money Escrow Agency for the holder of the particular signing key. The certificate should indicate to anyone who trusts the Agency that the compensation is valid and corresponds to the value stated in the conditions of usage. Money Escrow → Bidder: {Kv,Conditions}Kme 3. The bidder initiates the protocol with the auction house. He sends the certificate provided by the Money Escrow Agency along with a bid. The bid contains the protocol data and a payment token corresponding to the bid, encrypted under an
32
encryption key. The decryption key for the coin should be the one being escrowed. The bid must be signed and must be verifiable using the key in the certificate. Bidder → Auction House: {Protocol Data, {Payment Token}Ke}Ks, Conditions 4. When the winner of the auction is drawn, the auction house sends to him a certificate of ownership and expects to receive back a decryption key, which provides it with the payment token included in the bid. In case the bidder does not send this key, the auction house can request it from the Escrow Agency by providing the signed coin and the certificate of ownership. Auction House → Bidder: Certificate of Ownership Bidder → Auction House: Kd Auction House → Escrow Agency: Certificate of Ownership, Bid Escrow Agency → Auction House: Kd 5. The auction house can then decrypt the payment token. If it is valid and corresponds to the bid, the transaction is successful. If the payment token is not appropriate, the auction house can prove it to the escrow agency, and can request the compensation token. Auction House→ Escrow Agency: Certificate of Ownership, Bid Escrow Agency → Auction House: Compensation Token It is worth noticing that the framework provided above, is not heavily dependent on the details of the auction protocol. A restriction is that the bidder should know the amount that he will be invited to pay in case he is the winner, which excludes some kinds of auctions. The cocaine auction protocol [20] could be adapted to work inside such a framework. Some remarks on “money escrow” mechanisms The communications between the bidder and the Escrow Agency, and the auction protocol are anonymous. Therefore there is no way of acquiring the identity of any bidder. This is also true if someone is cheating, since the compensation token does not need to be linked to any identity. A major difference between disclosing the identity, like in the case of “Identity Escrow” protocols [18], and disclosing compensations is that the second can only be done once. As soon as the coin is used to claim the compensation the certificate must not be valid any more. In order to enforce this, the auction house could check the validity of certificates as soon as it receives them and “lock” them in such a way that two auctions could not happen concurrently. This is not however, a satisfactory solution because the Escrow Agency would need to be involved in each transaction. One would prefer a solution where the Escrow Agency is only used in the case of cheating taking place.
33
Another concern is the possibility that a bidder independently invalidates the compensation coin. That could happen at any stage of the protocol so the option of “locking” a particular compensation as described above would not work. A possible solution to both these problems is to create an anonymous electronic coin that can only be used by a particular principal up to an expiry date. After the expiry date anybody would be able to cash it. If such a payment token is used, the only principal able to cash it (up to the date of expiry of the escrow certificate) should be the auction house. The auction house has the ability to know if it has already used the coin and the bidder cannot use the coin independently. When the coin expires, which should coincide with the money escrow certificate expiring, the bidder can put the coin back into his personal account. Some properties that would be welcome for a “money escrow” system to have are: •
Provability of the need for compensation. A participant that requests compensation should be able to prove that cheating took place and that she has a right to claim compensation.
•
Guaranteed compensation. A participant that is able to prove her need for compensation must be guaranteed to receive it.
•
Resistance to impersonation. The escrow agency should not be able to use the escrowed information in order to impersonate participants or use their resources to participate in protocols.
•
Separability. The escrowed agency must only take part in the protocol in case of a participant cheating. It should not be directly involved in the normal running of the protocols.
The auction protocol described has properties 1 and 2. Unfortunately the Escrow Agency can use an escrowed compensation in order to participate as a bidder. So property 3 does not hold for the proposed protocol. Property 4 is holding in the sense that once the certificate is created the Escrow Agency does not need to be used. On the other hand, a different certificate must be created as soon as a user wins an auction, because the secret key used to protect his payment token is revealed. This could be overcome by including more than one key per certificate. In order to make the protocol more robust against malicious Escrow Agencies the information could be split between many Escrow Agencies in such a way that they all have to collude to get access to the payment key and compensation coin. For such a system to work the Escrow Agencies would need to be able to check the validity of their shares and the validity of the composition of their shares without actually composing them.
34
4. Evaluation
Comparisons between the two implemented anonymous networks Some insights into the differences between MIXing and D.C. networks are presented below. Differences between possible attacks In the case of both D.C. networks and MIXing networks it is assumed that passive and active attacks can be done on the network. Some nodes on the network can be trusted, to perform some operations: the mixes should reliably decrypt, sort and send a message, whilst a D.C. participant should reliably encrypt its message with the shared keys. In both cases the compromise of a single node does not compromise the anonymity of a participant. In the case of a MIXing network all the mixes could be compromised (but the more an attacker compromises the smaller the number of possible recipients). In the case of a D.C. network all the nodes with which a participant shares keys must be compromised to jeopardize its anonymity (unless all of these are compromised no personal information is revealed). Finding out which nodes to compromise could also be a potential problem for an attacker. In the case of a MIXing network where any mix of the network can randomly be chosen as a link in the mix chain, it is not rewarding to compromise a mix since it could have a very low probability of being used again by a particular participant. It could always be useful if the aim of the attacker is not to compromise the anonymity of a single participant but to monitor as much traffic as possible. Given that the topology of a D.C. network is public it can be much easier to detect which nodes to compromise. However this might not reveal a great deal of information if the D.C. networks have a short life, or if new key connections are established and others dropped after a certain amount of rounds. Anonymity of actions versus anonymity of participants In both the D.C. and MIXing networks an active attacker (with a huge amount of resources) is able to tell who is participating in the anonymous network. In the case of a D.C. network all the nodes in the network can legitimately know who is in the network. In that sense a mix network provides some anonymity of participants while the D.C. network provides only anonymity of actions. It could be possible to engineer D.C. networks to provide some partial anonymity of participants: Each participant would then know only a random subset of the others, and the broadcast-combine operation could be done hierarchically to protect against the disclosure of the participants’ addresses.
35
Illegitimate disclosures, using passive attacks, are difficult to avoid, and would require a more complicated combine and broadcast operation. Bandwidth and scalability The traffic overheads for the current implementations are the following: Install Connection startup Per key & connection setup
Per message
Mixing Network 1 (communication to recover a list of address of mixes) 0 NA
M (the number of intermediate mixes)
D.C. Network 1 (communication to recover a list of live D.C. networks) 2 (topology) 2+ (key exchange) 2 (connection request) N (connection broadcast) N+N (N messages sent by the participants and a broadcast of the result)
It is obvious from the above table that the MIXing network is much more economical than the D.C. network. In addition to this, the messages in a D.C. network tend to be larger than in the MIXing network because of the distributed state that must be maintained. The D.C. network has a very heavy setup overhead that is also proportional to the security needed and the number of participants in the network. The setup cost in a MIXing network is minimal. Finally the cost per message in a MIXing network is proportional to the security level required. In a D.C. network it is proportional to the number of participants. Stateless versus stateful protocols One of the main differences between MIXing and D.C. networks is that the first are stateless whilst the second have state. The only state that is needed in a mixer is a list of the hashes of the firsts half blocks of the messages, in order to avoid repeating them. The client node of a MIXing network only needs to know the addresses and the keys of the mixers. On the other hand a D.C. network node needs to keep information about the keys shared, the state of the network, the state of the collision resolution process and the topology of the network. This makes D.C. networks considerably harder to implement than MIXing networks. The original proposal as well as further research done on D.C. networks gives a description of the theory and techniques to solve theoretical problems such as collision detection and resolution but, unlike the documents presenting mixers, provide very little insight on how to implement them. They also provide little insight and analysis on how the failure of protocols that surround D.C. networks, such as the topology exchanges or the combine and broadcast operations, could affect the security of the system. Management of addresses, keys and servers The problem of key management and distribution is present in both MIXing and D.C. networks. In MIXing networks the addresses of the mixers must be bound to their public 36
keys in order to avoid man-in-the-middle attacks. In most of the proposed schemes the mixers should change their keys in order to minimize the volume of data needed to avoid “repeated message” attacks. To resolve this problem each mixer could have a master signing key and sign its new keys. However, the problem of key distribution still exists. The client must be very careful when it requests the new keys from servers because this could reveal the fact that some of his messages would take this path. A variant of this problem occurs if the client must resolve the network addresses of the servers. An example of that could be a database of server DNS names which must be converted to IP addresses in order to create the MIXing network packet. Because of the fact that DNS resolution involves querying the network, an outside observer could guess the path of the packets created. Similar difficulties exist in the key management needed for the D.C. networks where each node needs to share a key with other nodes. In the original proposal it is suggested that these keys can be shared off-line, but this is a hardly satisfactory solution. Another solution could be to know the public keys of some other nodes, and run a Diffie-Hellman key-exchange protocol in order to set up a session key. It is still not very clear how practical this would be in order to setup ad-hoc D.C. networks where no node has any previous experience of the others. Interactive versus static protocols Given that most of the people connecting to the Internet today do not have permanent connections, they usually are concerned about minimizing the time they stay on-line. MIXing networks can be used in such a way. A client of a MIXing network can be online just for the time required for sending a message. This practice is not in the spirit of the original proposal, where each user of a network was implicitly a mixer as well, but is the most common one in real life systems. On the other hand, D.C. networks require the participants to actively participate for a certain amount of time in the protocol before their anonymity can be guaranteed. In the case that a participant connects just to immediately send a message, and then immediately disconnects, his message can very easily be linked to him. The anonymity of the recipient is not jeopardized. The setup costs of entering a D.C. network would anyway make such a scenario very expensive in terms of bandwidth. Code review When both the MIXing networks and the D.C. network had been implemented, the code for both of them has been printed, and a code review was undertaken. The main objective of the code review was to tidy up the code and solidify the structure of both servers. As the result, the state in both servers was gathered in particular modules and was protected by access methods, which take care of its consistency. A clearer idea of the structure, which the servers should have, was established and some parts of the servers modified to better fit the new structure. In the case of the MIXing server the decision was taken to sacrifice some extensibility in order to simplify the design. In the case of D.C. networks, because of the complexity of
37
the state, a separate module holding the state of the server was designed and implemented. The review and resulting modifications took roughly three working days for each server. Testing The modular design of the project and the layered implementation made testing straightforward. Great importance was given to testing throughout the project, with 25% of the code being dedicated to it. Each module coded was tested as soon as possible, usually on top of virtual or “dummy” interfaces in order to be able to control its state and inputs. Once layers were working on their own, and had been tested on virtual networks or dummy interfaces they were plugged together and tested with other ones. Therefore the interoperability of the modules was continuously tested. The fact that sometimes testing and debugging had to be performed on top of other layers of the project increased the need for robust implementation of these layers and well defined interfaces. This practice has also led to more extensive debugging of the lower layers (as they have been used and relied upon for longer). The virtual network A virtual network behaving like an abstract network was implemented. It provides the illusion of a network whilst all the clients are running on the same machine and all of the messages are logged inside files. This makes possible a very detailed examination of all the information that is in transit in the network. The virtual network was used in order to debug the MIXing networks and D.C. networks, the transport protocol and the chat clients. The implementation of the virtual network is provided in Appendix D. The ROTn cryptographic environment A great difficulty in a project involving cryptography is the fact that it is difficult to debug the cryptographically protected transactions. In order to be able to see if the MIXing packets are of the required format, the RSA/RC4 cryptographic was substituted by an environment performing very simple ROTn encryption, which just adds the key to each byte modulo 256. This made it easier to debug the internals of the MIX servers and to correct bugs that would not be spotted if the cryptographic functions were completely turned off. The test chat clients In order to provide an interface to interactively assess and debug the network protocols a chat system was implemented. This simple system was used to test, debug and evaluate the effectiveness of the anonymous communications protocols.
38
5. Conclusions
During this project, both implementations of MIXing and D.C. networks were produced. A simple auction protocol engine was also implemented. Beyond the initial objectives, new mechanisms were developed to protect anonymous protocols and new insights into the implementation of these protocols have been presented. A comparison of the two implementations of anonymous communications was also done, together with an analysis of the attacks to which these implementations could be subject to. Outstanding issues It has been assumed that a key distribution mechanism exists; the fact that its nature is unknown has prevented its implementation in the D.C. key exchange phase. The key exchange has been implemented in an insecure manner, but care has been taken to make it easily replaceable in case one would like to implement a particular, secure, key exchange protocol. Overall the servers are still fragile and can be subject to overflows and denial of service attacks. An auction protocol engine has been implemented as an example application that could use anonymous communications but proper clients and servers have not been implemented to handle the auction operations automatically. Threat model for e-commerce. The threat model used during this project can be considered to be too strict for applications that only want to protect the anonymity of users in an e-commerce context. It assumes that all the communications can be intercepted which in practice is extremely difficult and expensive. A particularly interesting field for further research would be to study how the anonymity of the protocols and the cost of the interception infrastructure needed in order to defeat them is affected if the threat model is relaxed. By having a quantitative figure for the cost of the interception infrastructure, better threat models could be found and the anonymity channels that could be constructed on them might be cheaper to implement. What kind of anonymity protection? Against guns or judges. In order to effectively protect the anonymity of participants in a protocol it is essential to know what kind of anonymity is needed. Different anonymous channel protocols possess different anonymity properties. If the anonymity set is closed, as in the case of D.C. networks all the participants in the network are known to each other, if the set is open, as in the case of mixers, anyone could be a participant. In many cases, and countries, just the
39
fact that one has been seeking a right to anonymity can be more harmful than knowing what exactly one has said or to whom. Another distinction can be made between absolute anonymity - where at any cost the recipient and sender of messages must not be traced - and a statistical anonymity, which only provides the possibility to plausibly deny the communication. The first one could be required if the disclosure could result in one being prosecuted, while the second could be enough to defend one in a court. Therefore it is important to know if the anonymity property of the systems should protect the participants against guns or judges. Acknowledgements The author would like to thank Frank Stajano, the project supervisor, for the time, help and encouragement which he provided during the course of this project. Discussions with members of the Computer Security Group have also been helpful to develop the ideas and concepts presented in this dissertation.
40
Bibliography
[1]
D. Chaum, The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability, Journal of Cryptology vol. 1, no. 1, pp. 65-75.
[2]
D. Chaum, Untraceable Electronic Mail, Return Addresses, and digital Pseudonyms, CACM vol. 24, no. 2 (1881), p. 84-88.
[3]
Birgit Pfitzmann, Andreas Pfitzmann: How to Break the Direct RSAImplementation of Mixes. EUROCRYPT 1989: 373-381
[4]
PKCS #1 Specifications - http://www.rsasecurity.com/rsalabs/pkcs/index.html
[5]
Onion routing - http://www.onion-router.net/
[6]
The freedom network – Freedom 1.0 Security Issues and Analysis, http://www.freedom.net/info/freedompapers/Freedom-Security.pdf
[7]
The freedom network – Freedom Network 1.0 Architecture, http://www.freedom.net/info/freedompapers/Freedom-Architecture.pdf
[8]
M. Waidner and B. Pfitzmann, Unconditional Sender and Recipient Untraceability in spite of Active Attacks - Some Remarks; Fakultät für Informatik, Universität Karlsruhe, Interner Bericht 5/89, March 1989.
[9]
J.H.Ellis, The Story of Non-Secret Encryption.
[10]
“Final Report on Project C43”, Bell Telephone Laboratory, October 1944, p. 23.
[11]
Dogan Kesdogan, Jan Egner, Roland % VFKNHV Stop-And-Go-MIXes Providing Probabilistic Anonymity in an Open System, IHW'98 - Proc. of the International Information hiding Workshop, April. 1998.
[12]
Lance Cottell, Mixmaster & Remailer Attacks
[13]
Entrust/Toolkit Java Edition, http://developer.entrust.com/java/
[14] [15]
Cryptix 3, http://www.cryptix.org/products/cryptix31/index.html ABA's JCE v1.1, http://www-dse.doc.ic.ac.uk/Courses/netsec/aba/README.html The dining cryptographers in the disco, Unconditional sender and recipient Untraceability with Computationally Secure Serviceability.
[16] [17]
D.Chaum, Blind Signatures for Untraceable Payments, Proceedings of Crypto ’82, Plenum Press, pp.199-203.
[18]
Joe Kilian and Erez Petrank, Identity Escrow, Advances in Cryptology CRYPTO’98, LNCS 1462, p. 169 ff.
[19]
G.Danezis, An Auction Protocol using “Money Escrow”. To appear in the proceedings of the Cambridge Security Protocols Workshop 2000.
41
[20]
Frank Stajano and Ross Anderson, The cocaine Auction Protocol: On the power of Anonymous Broadcast, Preproceedings of Information Hiding Workshop 1999.
[21]
Ross J. Anderson, Bruno Crispo, Jong-Hyeon Lee, Charalampos Manifavas, Vaclav Matyas Jr., and Fabien A. P. Petitcolas ,The Global Trust Register, ISBN 0-262-51105-3
[22]
Daniel R. Simon. Anonymous Communication and Anonymous Cash, Microsoft Research.
[23]
Charles Rackoff and Daniel R. Simon, Cryptographic Defence Against Trafic Analysis, Microsoft Research.
[24]
eBay - Your Personal Trading Community, URL: http://www.ebay.com/
[25]
Tracy Mullen and Michael P. Wellman, The Auction Manager: Middleware for Large-Scale Electronic Commerce, 3rd USENIX Workshop on Electronic Commerce.
[26]
Manoj Kumar and Stuart I. Feldman, Internet Auctions, 3rd USENIX Workshop on Electronic Commerce.
[27]
M. Harkavy, J.D.Tygar and H.Kikuchi, Electronic Auctions with Private Bids, 3rd USENIX Workshop on Electronic Commerce.
[28]
Tomas Sander and Amnon Ta-Shma, Auditable, Anonymous Electronic Cash (Extended Abstract), Advances in Cryptology - CRYPTO’99, LNCS 1666, p. 555 ff.
42
Appendix A
This Appendix summarizes the mechanisms behind mixes. It also presents some attacks against the original proposal that were found after the publication of the original paper.
Chaum’s mixes
In the original proposal in [2] Chaum describes the MIXing network: A message is encapsulated in many layers of encryption each using the public keys of a mix. The message is sent to the series of mixes, where each of them strips a layer of encryption using its private key and sends the resulting packet to the next destination. Network
Network
Wait for N messages
Send the messages
Decrypt the messages
Sort the messages
The main aim of the intermediate mixes is to hide the correspondence between the input messages and the output messages. In order to do that a mix waits for a number of messages to arrive, decrypts them using its private key, sorts them by lexicographic order and sends them to their next destination. As the messages enter the mix encrypted and leave the mix decrypted there is no way for an outside observer, who does not have access to the private key of the mix, to tell which input message corresponds to a particular output message.
Basic function of a mixing Node
In order to avoid any correlation between the input and the output messages: 1.
It is required that each message should only be sent once: therefore a mix should discard any message it sees for the second time.
2.
The messages should all be the same size, and they should be padded after the decryption operation to remain of the same size. In this way the mix also has no way of knowing how many other mixes have processed the message before it.
The original proposed message format would be of the following form [2]: The message is divided in blocks of equal size (denoted by square brackets []). The first block of the message is the block encrypted with the public key of the first mix in the chain. It contains the key to decrypt the other blocks of the message and the address to which to send the message. In order to keep the length of the message constant the mix adds a block of Junk noted as J at the end of a decrypted message. A message prepared to be passed through mixes A1 through An has the Form: A1:
[KA1( RA1, A2 )], :Header for the mix A1 to decrypt [(RA1)-1 ( KA2( RA2, A3 ))], :Headers for the other mixes encrypted under A1 secret key ..., [(RA1)-1 ((RA2)-1 ... (RA)-1 ( KAn( RAn, A )) ... )], [(RA1)-1 ((RA2)-1 ... (RAn)-1 ( M1 )...)], ..., [(RA1)-1 ((RA2)-1 ... (RAn)-1 ( Ml-n )...)]
43
:Message encrypted under all the secret keys
The result leaving A1 is A2:
[KA2( RA2, A3 )], : Header for the mix A2 [RA2-1 ( KA3( RA3, A4 ))], : Headers for the other mixes encrypted under A2 secret key ..., [RA2-1 (RA3-1 ... RA-1 ( KAn( RAn, A )) ... )], [RA2-1 (RA3-1 ... RAn-1 ( M1 )...)], : Message encrypted under all the secret keys ..., [RA2-1 (RA3-1 ... RAn-1 ( Ml-n )...)], [RA1( JA1 )] : Junk added by A1 to hide the length of the message
and the final result leaving An is A:
[M1], [M2], ... , [M],
: The original message
[RAn( RA ... RA1( JA1 )...)], ..., [RAn( JAn )].
: Junk added by mixes
The original proposal also described schemes for providing signed receipts, to guarantee that messages were sent, as well as anonymous return addresses.
Attacks on the original proposal A mixed message leaving a mix is compromised when an attacker can deduce which input message it corresponds to. The main methods for doing this are: 1.
Finding a correspondence between the encrypted message and a decrypted message.
2.
Finding a correspondence between the message and another message in the same batch and by using some property of this correspondence to draw a conclusion about the output messages.
The attacks could span across many rounds of a mixer in order to compromise a message.
The direct RSA implementation attack In [3] attacks are described against the direct RSA implementation of the mixes. It uses the fact that the message format described does not destroy the multiplicative structure of RSA in order to find the connection between the input and output packets.
The flooding attack An active attacker intercepts every message that is being sent to the mix. It then sends the message along with N-1 other messages that he has himself created (where N is the size of the batch in which the mixer decrypts and sends the packets). The mix does the operation of decrypting, sorting and sending the messages. The attacker examines all the packets’ output and as he has created the N-1 packets the only one that is not his is the packet intercepted. Therefore he knows that the next destination of the original input packet is the destination of this packet. The attacker can repeat this attack on the next mix until he reaches the final receiver of the message.
44
This attack is described in [11] along with a proposed MIXing network that would avoid it. In the system described each packet is transmitted at a random time (chosen out from a Poisson distribution) with a specified mean. This prevents the system from being organized in a round that can be flooded.
The “double block” attack An active attacker substitutes the last block of a message by the one before it. Therefore a message is formed with the last two blocks being identical. This message is sent normally to the first mix. Given that in the original proposal each block is encrypted separately, without chaining, the output of the mixer is going to produce a message with the two last blocks being the same. The attacker then tracks the destination of this packet from mix to mix until it reaches the final recipient. As the message travels through the network, the attack automatically repeats itself on all the mixes, so the attacker need only to tamper with a message at the very beginning and then just trace its journey through the network. The problem with this attack is that if the last block replaced is not a junk block, the final recipient will notice that the message is malformed. In [3] the author warns that if a block cipher is used, the encryption must be done in CBC mode to disguise possibly identical blocks in the message. This would also prevent the “double block” attack.
45
Appendix B
The dining cryptographers’ problem: proposal and concepts Chaum in [1] presents a system that provides unconditional sender and receiver untraceability. It takes its name from the introduction of the proposal:
“Three cryptographers are sitting down to dinner at their favorite three-star restaurant. Their waiter informs them that arrangements have been made with the maitre d'hotel for the bill to be paid anonymously. One of the cryptographers might be paying for the dinner, or it might have been NSA (U.S. National Security Agency). The three cryptographers respect each other's right to make an anonymous payment, but they wonder if NSA is paying. They resolve their uncertainty fairly by carrying out the following protocol: Each cryptographer flips an unbiased coin behind his menu, between him and the cryptographer on his right, so that only the two of them can see the outcome. Each cryptographer then states aloud whether the two coins he can see - the one he flipped and the one his left-hand neighbor flipped - fell on the same side or on different sides. If one of the cryptographers is the payer, he states the opposite of what he sees. An odd number of differences uttered at the table indicates that a cryptographer is paying; an even number indicates that NSA is paying (assuming that the dinner was paid for only once). Yet if a cryptographer is paying, neither of the other two learns anything from the utterances about which cryptographer it is.”
The scheme can be generalized to any number of participants: we consider a connected graph G where every vertex is a participant and every edge is a secret coin flipping. This arrangement G is secure if the graph is bi-connected, so that no removal of a vertex or node will split the graph. If a group of participants choose to collaborate by sharing some or all of their keys the arrangement is still secure as long as the removal of the vertexes representing shared secret coins does not split the graph. Many additions and optimizations are also described. The most obvious one is that there are no coin flips but only an initial key exchange that is used to feed a stream cipher to produce the coin results. This minimizes the problem of the key management. Another optimization is to transmit more than one bit per round. It is quite important to realize that there are two networks, or graphs, in the implementation of a D.C. network. The first one is the key-sharing graph. To set it up standard key exchange techniques can be used. Knowing who is in a network and discovering the potential parties to which one would like to connect (and therefore trusts not to collude) is still a problem. The second network is the one that is going to be used to broadcast the individual participants’ results in order to combine them all and get the final result of a round. The operation of broadcasting and combining can happen in many ways: 1.
Centrally, when all participants send their results to one node, which combines them and broadcasts the result. The cost of each round if there are N participants will be N messages and 1 broadcast and thus 2N if the broadcast is simulated by sending a message to everybody.
2.
Hierarchically, when the participants are arranged in a tree and each node combines and sends the message to its parent. In this case 2N messages would be needed but it could be more efficient than the first case depending on the network topologies.
47
3.
In a completely distributed manner, where everybody broadcasts to everybody else and all participants calculate the final result for themselves. This scheme is the most inefficient with N broadcasts, which would result in N2 messages being sent if the broadcast operation is implemented in a naïve way.
Another problem is that the D.C. network creates a virtual shared medium, where many people broadcast messages. There is therefore the problem of collisions and sharing. A possible approach to solve the problem of sharing could be to divide each round of the shared medium in slots, and to have a system to reserve these slots. As in every shared medium there is still the problem of malicious jamming and related denial of service attacks.
Superposed receiving collision resolution and serviceability guarantees In [8] both the problems of sharing and malicious jamming are considered. The study notes that the D.C. networks should not be restricted to modulo two additions as the composition operation. Indeed any finite abelian group will preserve the properties of the system. Therefore given a finite abelian group G(A,*) with alphabet A and operation “*”: 1.
Each cryptographer j calculates his personal result given that he wants to send a message Mj chosen from the alphabet A and that he shares keys with the set I of cryptographers :
(Note that Kij should be inverted by one of the two cryptographers sharing the key) I
R j = M j * ∑ K ij i
2.
The total result is calculated by combining all the personal results: J
J
j
j
R = ∑ Rj = ∑ M j The final result R is the result of the round. The suggestion is then to use the group of the integers modulo the size of the alphabet times the number of participants. In that way the final result is going to be the sum of all the messages. Participants who want to send a message send the tuple (1,Mj) and the ones that do not want to send a message send the tuple (0,0). The final result is going to be the tuple (s,Σ) where s is the number of participants that have transmitted during the round. If a collision occurs, MA is calculated thus:
Σ MA = s This can be done because both the figures needed are in the final result. In the next round the participants with Mj ≤ MA retransmit. Each user then receives the pair (s1, Σ1) and calculates the pair:
(s2, Σ2) = (s*s1, Σ*Σ2). If s2 = 0 it means that everybody is broadcasting the same message (Mj = MA). Otherwise the method is applied recursively to (si, Σi) where i = 1,2.
48
An example where s = 5 could be:
P1 P2 P3 P4 P5
1 1 1 1 1
7 10 4 1 5
1 7 1 10 1 4 1 1 1 5
1 4
1 7 10 10
1 4
1 1 1 5
1 5
5 27 MA=5 3 10 MA=3
1 7 MA=8 1 7 MA=1
1 7 MA=4
1 7 MA=7 1 7 MA=4
1 7 MA=10
1 7 MA=5
In the above example the boxes framed in gray are calculated as soon as the left-hand side of the tree is transmitted. The resolution runs during five rounds, with 3 rounds being implicitly calculated.
49
Appendix C
The code performing the superposed receiving is presented below. More information on the algorithm can be found in Appendix B. package quns.gd216.anon.dc; import import import import import import
java.util.*; quns.gd216.comms.*; quns.gd216.crypto.*; quns.gd216.util.*; java.util.zip.CRC32; java.io.*;
import java.math.BigInteger; /* This is the class in charge of detecting and retransmiting after a collision It uses the method described by Pfitzman that solves a collision of n in at most n retransmitions. */ public class CollisionResolver { // This variable stores the number of the round that the collision happened. public long TotalRound = 0; // This is the orginal packet to be sent (in clear). byteArray myPacket = null; // Just some stuff that repeats itself in the methods BigInteger M = BigInteger.valueOf(2).pow(121*8); byteArray D = new DumpByteArray(new byte[1]); // The root of the message tree CollissionResult myTree = null;
// This class represent a node of the message collision tree. class CollissionResult { // Makes a collision result node public CollissionResult(DCResult r) { this.result = r; this.MA = r.Result.toBigNum().divide(r.Redudency.toBigNum()); } // Adds a collision result node to the tree. public boolean addResult(DCResult r) { if(result.Redudency.toBigNum().equals(BigInteger.ONE)) { return false; } if (smaller==null) { smaller = new CollissionResult(r); DCResult largerR = new DCResult(); largerR.round = r.round; largerR.Result = D.fromBigNum(result.Result.toBigNum().subtract(r.Result.toBigNum())); largerR.Redudency = D.fromBigNum(result.Redudency.toBigNum().subtract(r.Redudency.toBigNum())); larger = new CollissionResult(largerR); return true; } else { if(smaller.addResult(r)) { return true; }
51
else { return larger.addResult(r); } } } // Returns true if all the leafs of the tree are calculated. public boolean isItComplete() { if(result.Redudency.toBigNum().equals(BigInteger.ONE)) { return true; } if (smaller!=null) { return larger.isItComplete()&&smaller.isItComplete(); } else { return false; } } // Returns true if the node should retransmit given the last message received public boolean retransmit() { int i = this.retransmit(myPacket.toBigNum()); if (i>0) { return true; } else { return false; } } // Returns true if the node should retransmit given a messaga public boolean retransmit(DCResult r) { int i = this.retransmit(r.Result.toBigNum()); if (i>0) { return true; } else { return false; } } // Returns true if the packet stored has to be retransmited. public int retransmit(BigInteger r) { if(result.Redudency.toBigNum().equals(BigInteger.ONE)) { return 0; } BigInteger b = r; if (smaller!=null) { if (b.min(this.MA).equals(b)) //(!smaller.retransmit()) { int k = smaller.retransmit(r); return k; } else { int k = smaller.retransmit(r); if (k != -1) { return larger.retransmit(r); } else { return -1; }
52
} } else { if (b.min(this.MA).equals(b)) {return 1;} else {return -1;} } } // Returns a list of all the messages. public void returnAllMessages(LinkedList l) { if(result.Redudency.toBigNum().equals(BigInteger.ONE)) { // System.out.println("List value: "+l); l.addFirst(result); return; } if (smaller!=null) { smaller.returnAllMessages(l); larger.returnAllMessages(l); } } // The result stored in this node DCResult result = null; // The average of this node BigInteger MA = null; // The two leafs CollissionResult smaller = null; CollissionResult larger = null; // String output of the object public String toString() { String s = "Node
\n"; s += "Result: "+result.Result.toBigNum()+"
\n"; s += "Redund: "+result.Redudency.toBigNum()+"
\n"; s += " MA: "+MA+"
\n"; if (smaller!=null) { s += "
\n"; s += "Smaller
\n"; s += smaller.toString(); s += "
\n"; s += "
\n"; s += "Larger
\n"; s += larger.toString(); s += "
\n"; } return s; } } }
53
Appendix D
In this Appendix the implementation of the “vnet” test-bed on which the anonymous communication protocols were tested is presented. It is thread-safe and logs all the messages in transit in the network in the “outlogx.txt” file. The example uses advanced features of the Java language such as interface abstractions, monitors and inner classes. package quns.gd216.test; import import import import
quns.gd216.anon.*; quns.gd216.crypto.*; quns.gd216.comms.*; quns.gd216.util.byteArray;
import java.util.*; import java.io.*; // This class implements Vnet a testbed net for testing anonymous // network implementations. public class vnetServer { // Shares the Lists of messages // Each entry must be a Linked List of messages. HashMap packetsMap = new HashMap(); // Logs the messages that are put in the network // on a disk file. PrintWriter log = null; { try{ log = new PrintWriter(new FileOutputStream("outlogx.txt")); } catch(Exception e){System.out.println("log error: "+e);} }
// Returns a personal server for an address public GenericBroadcastServer getPersonalServer(GenericAddress ga) { return new vnetPersServer(ga); } public class AddrsLinkedList extends LinkedList { GenericAddress ga = null; public AddrsLinkedList(GenericAddress ga) { super(); this.ga = ga; } } // personal server to serve a node public class vnetPersServer implements GenericBroadcastServer { String NodeAddress = null; AddrsLinkedList privPacketsList = null; public vnetPersServer(GenericAddress ga) { privPacketsList = new AddrsLinkedList(ga); NodeAddress = ga.getStrAddress(); packetsMap.put(ga.getStrAddress(),privPacketsList); }
55
// Get the next packet that has been sent to it public GenericPacket popPacket() { try { GenericPacket gp = null; synchronized(privPacketsList) { while(privPacketsList.size() == 0) { //DEBUG -- System.out.println("No messages waiting for "+NodeAddress); privPacketsList.wait(); }
gp = (GenericPacket) privPacketsList.removeFirst(); //DEBUG -- System.out.println("Got packet "+gp); privPacketsList.notifyAll(); } return gp; } catch(Exception e) { throw new Error("The pop thread was interupted"); } } // Sends a packet to a destination. public void putPacket(GenericAddress A,GenericPacket p) { System.out.println("Put Packet: address: "+A+" Packet: "+p+"\n" ); LinkedList listToSend = (LinkedList)packetsMap.get((A.getRawAddress().unPad()).toString()); System.out.println("Got the list: "+listToSend); if (listToSend == null) throw new Error("Message Queue is NULL: "+(A.getRawAddress().unPad()).toString()+"\n"+p.getData()); // DEBUG -- System.out.println("Put packet from "+NodeAddress+"\nMessage:\n"+p); synchronized(listToSend) { listToSend.addLast(p); listToSend.notifyAll(); } // logs the packe in transit synchronized(log) { log.println("Node "+NodeAddress+ " to Node "+A.getStrAddress()); log.println("Data Length: "+p.getData().length()); log.println(p.getData()); log.flush(); } } // get a packet from a destination. public GenericPacket getPacket(GenericAddress A) { throw new Error("getPacket not implemented: multiplexing not supported"); } // Broadcasts a packet to a group. public void broadcastPacket(GenericPacket p) { Iterator Its = packetsMap.keySet().iterator(); while(Its.hasNext()) { putPacket(((AddrsLinkedList)packetsMap.get(Its.next())).ga,p); } } } }
56
George Danezis Queens’ College User ID: gd216
Computer Science Tripos Part II Project Proposal
Implementation of an Auction Protocol over Anonymous Networks
Project Originator: Special Resources: Overseers:
Supervisor: Director of Studies:
F.Stajano & G.Danezis Own Machine (see resource form) Dr A.M.Pitts Dr E.J.Briscoe
_________________ _________________
F.Stajano _________________ Dr R.D.H.Walker _________________
1
2
Introduction One of the main characteristics upon which many real-life transactions and protocols are based is the fact that the identity or the exact actions of the participants cannot be traced easily. These include elections, money in the form of cash, auctions and stock market exchange. As on line transactions are more and more common one would expect them to keep the properties that they have in the real world, such as anonymity, along with the added efficiency of being managed automatically and the speed of being transmitted over fast networks. Unfortunately for efficiency and security reasons the networks that are often used and the protocol that run over them (such as IP) require senders and receivers of messages to be identified. These protocols are neither implementing strong anonymity nor strong authentication. They just take care that messages are delivered reliably from a sender to a receiver. Given that we already have a wide infrastructure of such networks one must try to implement on top of them protocols that would permit anonymous transmission of messages. The proposed project can be divided in two parts. In the first part different proposals for anonymous communications are going to be implemented. These include mix-nets (for mixing networks as described in [1]) and dc-nets (for Dining Cryptographers networks as described in [2]). In the second phase an auction protocol is going to be designed and implemented on top of them (in the lines described in [3,7,8,9]). The auction protocol has been chosen as the paper that gave me the idea of the project [3], was talking about auctions and because it could be useful in real life e-commerce applications (such as eBay [6]).
Resources and back-up procedures The implementation of this project can be done in Java as the main aim is not the extreme efficiency but the study and experimental implementation of anonymous protocols. The main resource that is needed is a Java compiler and Virtual Machine that are provided by Sun. The latest stable version of this language, the Java2 platform, is going to be preferred for the extensive set of libraries it is offering. As the main aim of the project is not the implementation of cryptographic primitives a library is going to be used to provide them. A logical choice would be the Java Cryptographic Framework (JCF), but due to export restrictions it is not available outside USA and Canada. Therefore I will try to use the Cryptix library, which is meant to be compatible with the JCF. For the development of this project I am going to use my own computer. The specifications of my machine are: Intel Pentium 133MHz processor. 72MB RAM. 17GB of disc Space (of which 10GB are available). 4x/2x CRW-writer. 10Mbit Ethernet connection. Standard CD-ROM (24x), Disk drive, sound & Video card. 3
17" 32bit colour monitor. As my computer is equipped with a CD-writer and a 10MBit connection to the Internet, I can back up the work of each workday on a WR-CD, and each week on Pelican. If at some point my computer fails, I can always move my tools (all being platform independent) and work on Thor, without much delay. The project involves communication over networks so I may have to use Thor mainly for testing purposes. For this reason I assume that the Java2 platform is installed and that I could have an additional disk space of 15 MB mainly due to the size of the cryptographic libraries.
Starting point As a starting point I have a good knowledge of the Java programming language. I also have worked in the past, during my part IB, on implementing security abstractions using Java. I already have a copy of most of the relevant papers [1,2,3,7,8,9] that I have read but not studied in depth yet.
Description of the project The aim of the project is to produce the implementation of anonymous networks, and an auction protocol on top of them. This can be decomposed in many stages: (For milestones exact dates see the timetable of the next session) 1. The first stage is the study of the literature on anonymous network protocols. The literature should include all the referenced papers [1-5] and specially the ones written by Chaum [1,2] that are the base for the two anonymity layers I will implement (Milestone R). I should also have a close look at the documentation of the cryptographic library I am going to use. 2. The second stage is the implementation and testing of 2 anonymous communication layers (using mix-nets and dc-nets as described in [1,2]). This should be mainly a coding and testing phase done in Java. Careful design and interface specification should archive modularity: a protocol running on top of the anonymous layer should not care about its fine details (Milestone G1). When the groundwork has been done the two anonymity layers should be implemented and tested. These are the mixingnetwork [1] and the Dining Cryptographers-network [2] (milestones G2 and G3). At this stage I could, optionally, do a short talk at a Security group Friday meeting to present to other people the work that I will have done so far. 3. The next stage is the design of the auction protocol. Ideas could be used from [3] but also the proceeding of the USENIX conference on e-commerce [7,8,9]. Also ideas could be drawn by real on-line auction systems such as eBay [6]. The design is going to be done in two stages: The preliminary protocol, and the final protocol and ground coding implementation (with the progress report between them) (milestones AW and
4
A1). The coding does not include the coding of the protocol but of any needed utilities or stubs to simulate the auction environment (money, identities, etc.). 4. Finally the implementation and testing of the auction protocol can be done. This task is subdivided in the core implementation (milestone A2) and the interface implementation (milestone A3). The form of the user interface will depend on the time available. Optionally it could be an applet to be used for on-line auctions.
Timetable and milestones for the project The main idea behind the timetable is that unpredictable things will require more time at some point or another. For this reason the milestones are set on Fridays so that the weekend can be spend to put the project again on schedule. This is also the reason why no work is set in the holidays: as well as not being sure of having access to computers, this time could be used in a crisis situation to save my project. Roughly 4 milestones are set for each term, one every 2 weeks. Date Fri 22 Oct 1999 (12 noon) Fri 29 Oct 1999 Fri 5 Nov 1999 Fri 19 Nov 1999 Fri 3 Dec 1999 Fri 3 Dec 1999 Fri 3 Dec 1999 Holidays Tue 18 Jan 2000 Fri 28 Jan 2000 Fri 4 Feb 2000 (12 noon) Fri 18 Feb 2000 Fri 3 Mar 2000 Fri 17 Mar 2000 Fri 17 Mar 2000 Fri 17 Mar 2000 Holidays 25 Apr 2000 Fri 5 May 2000 Fri 19 May 2000 Fri 19 May 2000 (12 noon) Tue 6 Jun to Thu 8 Jun 2000
Mile Stone R G1 G2 G3
AW A1 A2 A3
W1 W2
Activity CST Proposal Deadline Finish the reading Finish the implementation ground work and education Finish one of the two anonymous layers Finish the other anonymous layer Short talk at the security group Friday meeting End of Michaelmas Full Term Buffer time in case something goes horribly wrong Start of Lent term Preliminary specifications for the Auction protocol CST Progress Report Deadline Full specification and ground work implementation Full implementation of the auction protocol Full user interface and testing completed Short talk at the security group meeting End of Lent Full Term Buffer time in case something goes horribly wrong Start of Easter term Draft dissertation completed (50%) Major part of dissertation written (90%) CST Dissertation Deadline CST Written papers
5
References: [1] [2] [3] [4] [5] [6] [7]
[8] [9]
D. Chaum, Untraceable Electronic Mail, Return Addresses, and digital Pseudonyms, CACM vol. 24, no. 2 (1881), p. 84-88. D. Chaum, The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability, Journal of Cryptology vol. 1, no. 1, pp. 65-75. Frank Stajano and Ross Anderson, The cocaine Auction Protocol: On the power of Anonymous Broadcast, Preproceedings of Information Hiding Workshop 1999. Daniel R. Simon. Anonymous Communication and Anonymous Cash, Microsoft Research. Charles Rackoff and Daniel R. Simon, Cryptographic Defence Against Trafic Analysis, Microsoft Research. eBay - Your Personal Trading Community, URL: http://www.ebay.com/ Tracy Mullen and Michael P. Wellman, The Auction Manager: Middleware for Large-Scale Electronic Commerce, 3rd USENIX Workshop on Electronic Commerce. Manoj Kumar and Stuart I. Feldman, Internet Auctions, 3rd USENIX Workshop on Electronic Commerce. M. Harkavy, J.D.Tygar and H.Kikuchi, Electronic Auctions with Private Bids, 3rd USENIX Workshop on Electronic Commerce.
6
