Apr 26, 2003 - centralized index of all files on nodes subscribing to the Napster network ... Starting with Napster that popularized P2P file-sharing, we examine.
Securing Content in Peer-to-Peer File Systems
By Dushyant Bansal Student ID 97128880 For Professor Gordon Agnew April 26, 2003 E&CE 628
2
Table of Contents Table of Contents ...................................................................................................................... 3 List of Figures ........................................................................................................................... 4 List of Tables............................................................................................................................. 5 Abstract ..................................................................................................................................... 6 1. What is Peer-to-Peer Computing?..................................................................................... 7 2. Applications of P2P Computing........................................................................................ 8 2.1. Collaboration............................................................................................................. 8 2.2. Edge services............................................................................................................. 8 2.3. Distributed computing and resources........................................................................ 8 2.4. Intelligent agents ....................................................................................................... 8 3. P2P File-Sharing ............................................................................................................... 9 3.1. Orthogonal Factors.................................................................................................... 9 4. P2P File-Systems ............................................................................................................ 12 5. Overview of some Architectures..................................................................................... 13 5.1. Napster .................................................................................................................... 13 5.2. Gnutella ................................................................................................................... 13 5.3. FastTrack................................................................................................................. 13 5.4. PAST ....................................................................................................................... 14 5.4.1. Security............................................................................................................ 15 5.4.2. SmartCards ...................................................................................................... 15 5.4.3. System Integrity .............................................................................................. 15 5.4.4. Persistence....................................................................................................... 15 5.5. Oceanstore............................................................................................................... 16 5.5.1. Routing ............................................................................................................ 16 5.6. FARSITE................................................................................................................. 16 5.6.1. Machines in FARSITE .................................................................................... 17 5.6.2. Files and Directories........................................................................................ 17 5.6.3. Security............................................................................................................ 17 5.7. Publius..................................................................................................................... 18 5.7.1. Publish............................................................................................................. 19 5.7.2. Retrieve ........................................................................................................... 19 5.8. Dagster .................................................................................................................... 20 5.8.1. Publishing........................................................................................................ 21 5.8.2. Retrieving ........................................................................................................ 22 6. Security Requirements .................................................................................................... 23 7. Identifying and Dealing with Attacks ............................................................................. 24 7.1. Content attacks ........................................................................................................ 24 7.2. Routing attacks........................................................................................................ 41 7.3. Identity attacks ........................................................................................................ 45 7.3.1. Other comments .............................................................................................. 48 7.4. General DoS attacks ................................................................................................ 49 8. Conclusions and Future Directions ................................................................................. 50 9. References ....................................................................................................................... 52
3
List of Figures FIGURE 1: THE GENERAL FILE-SHARING MODEL ................................................................................................. 11
4
List of Tables TABLE 1: CLASSIFYING SOME FILE-SHARING ARCHITECTURES ........................................................................... 10
5
Abstract This paper examines various possible security attacks in a peer-to-peer (P2P) file-system and what some P2P file-system architectures are doing to counter-act them. First, the general idea of peer-to-peer computing is introduced. Then an overview is given of P2P file-sharing. Building on that, the idea of a P2P file-system is described. Given this, a number of P2P filesystems are examined, each of which differs from the other in terms of its abilities. For example, FastTrack is a read-only P2P file-system that makes files available by sharing them while FARSITE is a full-featured P2P file-system, except that it does not scale to more than 10,000 nodes. Finally, a number of attacks are examined that could undermine the integrity of the data content stored in a P2P file-system and how the architectures under consideration deal with them. These attacks are analyzed along the dimensions of direct content attacks and indirect content attacks that exploit weaknesses in routing and identity management to corrupt content.
6
1. What is Peer-to-Peer Computing? A form of distributed computing, peer-to-peer (P2P) computing allows computers to communicate directly with each other and to share various resources and services without going through an intermediate server. These resources include processing cycles, cache and disk storage space. The popularization of peer-to-peer computing in current times stems from the availability of larger amounts of storage, processing power and network bandwidth on computers on the edge of the network. This network could be a Local Area Network, a Wide Area Network or the Internet itself. P2P allows edge resources to be collectively used to provide a superutility that cannot be provided by a single machine alone. In the peer-to-peer architecture, each node performs the role of both client and server. It acts as a client when requesting a service or as a server when providing a service or acting as an intermediary to providing the service. The result is a reduced load on traditional servers that can now perform a more specialized role, such as network monitoring and administration, mail-list generation, billing, etc., in a more effective manner [1]. Another perhaps more important result is that the central servers no longer form a bottleneck in performance and bandwidth.
This gives P2P networks the ability to scale much more than traditional
centralized distributed systems.
7
2. Applications of P2P Computing As described above, P2P computing can be used to share various computing resources. This gives rise to applications that fall in the broad categories of collaboration, edge services, distributed computing and resources, and intelligent agents [1].
2.1.
Collaboration
By collaborating in a peer-to-peer manner, users are able to communicate in all sorts of network topologies, whether administered or un-administered, on an enterprise network or on the Internet, or partitioned by a firewall. P2P collaboration provides access to the latest data.
2.2.
Edge services
Edge services move data closer to the point of consumption, mimicking a network caching mechanism. Thus, a node on a network can access the same data accessed by another node from that node itself, rather than communicating with the original remote site. This also utilizes existing storage space, eliminating the need for additional servers and saving money.
2.3.
Distributed computing and resources
P2P technology can exploit a network of computers and use their idle computing cycles and disk storage for computational jobs that would take much longer or need more storage to complete on any machine alone. A machine of the total combined power may either be too expensive or not within the reach of current technology. The participating peers may be able to exchange results with each other and perform required synchronizations with each other.
2.4.
Intelligent agents
Peer to peer computing also allows computing networks to dynamically work together using intelligent agents [1]. These agents reside on peer computers and communicate various kinds of information with each other necessary to maintain the smooth functioning of the network. This information may range from the current network traffic conditions to alerting other agents of viruses detected anywhere on any network. 8
3. P2P File-Sharing Before describing P2P file-systems, it is worth looking at P2P file-sharing first. P2P filesharing has emerged as one of the most popular applications today. Starting with Napster, new architectures have subsequently emerged, such as Gnutella, FastTrack and Gnutella2. Various file-sharing architectures that exploit the desirable properties of P2P networking are also under development at various academic institutions. In terms of classes of applications described in the previous section, file-sharing is a hybrid application that falls in the categories of Distributed Resources and Edge Services. It falls under Distributed Resources as it allows the sharing of terabytes of multimedia files, as in the FastTrack network. It falls under the Edge Services category as by virtue of the various filesharing protocols, the files are cached and replicated on nodes throughout the P2P network.
3.1.
Orthogonal Factors
File-sharing can be broken down into three orthogonal factors. These are: 1. Routing queries, which requires the nodes to have specific identifiers for deterministic routing 2. Indexing the content, which requires the files to be assigned specific identifiers for deterministic routing 3. Distributing the index, which takes advantage of file identifiers and node identifiers for deterministic routing Table 1 below describes the architectures relevant to this report in terms of the above factors. More details on these architectures are described later. However, in brief, Napster kept a centralized index of all files on nodes subscribing to the Napster network. Gnutella requires nodes to index their own content and store their indices locally. Routing is performed by broadcasting requests to all nodes in the vicinity of the requesting node. FastTrack provides a semi-centralized indexing mechanism of peers and superpeers. Each peer subscribes to a superpeer to get answers to its queries and the superpeers talk to each other. A peer is promoted to the position of superpeer if it has the required computing power to handle
9
queries this way. Finally, the Pastry/PAST file-sharing protocol is an architecture produced by academia. It provides a structured way of indexing files and routing queries in the P2P network. Each document and node are assigned an identifier. Pointers to documents are kept on nodes with the closest identifiers. Routing a request for a document takes place by forwarding the request to the node with a closer and closer identifier, till the desired file is reached. Other research architectures that provide structured indexing and searching for filesharing P2P networks are Content Addressable Network [20], Cooperative File Storage [21] and JXTA [22].
Table 1: Classifying Some File-Sharing Architectures
Index
Index distribution
Routing
Examples
Central
Centralized
Directed-queries (no
Napster
routing required) Local
Decentralized,
Broadcast to
Unstructured
neighbours based on
Gnutella
a network metric Superpeer holds
Semi-centralized,
Peers send their
index of nodes
semi-structured
requests to their
under it.
FastTrack
superpeers, who broadcast requests to neighbouring superpeers based on a network metric.
Content-based
Decentralized,
Nearest neighbours
hashing, Distributed
Structured
based on numerical
Pastry/PAST
identifier Based on the orthogonal factors identified above, Figure 1 below gives a general model of P2P file-sharing. As shown, queries enter the P2P network, pick up a routing algorithm (abstractly speaking), are routed through the index nodes using that algorithm, and finally
10
reach
the
computer
that
holds
the
file
that
Queries
Routing
Index Nodes
Data Stores
Figure 1: The General File-Sharing Model
11
satisfies
the
query.
4. P2P File-Systems The concept of a P2P file-system is broader than that of P2P file-sharing. P2P file-sharing only provides a read-only mode of file availability. A P2P file-system must provide the following as well: 1. The owner of a data item should be able to set the rules about who can access that data item and with what privileges. 2. Only authorized users must be able to create, read, update or delete files. 3. Once a file is uploaded to the system, the P2P file-system must provide guarantees of persistence of the file as long as some sort of participation metric is maintained, such as a monthly fee or a certain amount of contributed storage space. 4. Once a file is uploaded to the P2P file-system, it must be retrievable. 5. When a data item is updated, all copies of that data item must reflect the changes consistently. 6. The file-system must provide the ability to create namespaces or directories. 7. The owner of a namespace should be able to define access control to his directory. 8. Only authorized users must be able to create, rename and delete new directories. 9. Only authorized users must be able to view and update directory contents. By this definition, P2P file-sharing can be viewed as a read-only file-system with a flat directory structure. In deed, the architectures for file-sharing that are emerging from research centres are also being imbibed with characteristics of file-systems [7].
12
5. Overview of some Architectures A number of architectures are analyzed in this report for their protection and resilience against security attacks. Starting with Napster that popularized P2P file-sharing, we examine Gnutella, FastTrack, PAST, Oceanstore, FARSITE, Publius and Dagster. Each system has its own strengths and weaknesses in terms of the service that it can provide and the types of attacks that it can withstand while providing the service.
5.1.
Napster
As explained by Brain [13], every time a user logged into the Napster network, the desktop software updated a central indexing server with the files being shared on the user’s machine. Users directed their queries to this central server, which would return the identity of the machines containing matching files. The user directly connected to one of these machines and downloaded the desired file.
5.2.
Gnutella
As explained earlier, Gnutella nodes broadcast their queries to all their neighbours. These queries in turn do the same until an instance of the file is found. By virtue of a hop-limit, a request propagates only for a limited number of steps, thus limiting the message explosion. Once the file is found, a direct connection is established between the requester and the destination to download the file [13].
5.3.
FastTrack
The FastTrack P2P network is organized as a network of peers and super-peers. Super-peers are typically nodes with higher computational power and bandwidth. Normal peers connect to a super-peer and direct all their queries to the super-peer. The super-peer is part of a P2P
13
overlay of only super-peers, so it is able to broadcast the queries to other super-peers in that overlay [15].
5.4.
PAST
PAST is a persistent file storage system built on top of the Pastry routing substrate. Pastry is a scalable, distributed, object-location and routing substrate for wide-area P2P applications running over a potentially very large overlay network of nodes connected via the Internet [15]. When a node wishes to join the Pastry network, it runs an expanding ring multicast to locate the closest Pastry node. The new node is assigned a uniformly distributed random 128bit identifier. Given the large space that 128 bits imply, those few nodes that have identifiers close together are likely to be diverse in geography, ownership, and other parameters. No mechanism to maintain uniqueness is specified [15], and thus, based on the birthday paradox, it is a fair assumption that, as the Pastry network grows, there will be some duplication of identifiers [19]. However, because of the size of the address space, the probability of discovering a target node’s address would be computationally difficult. Each message in Pastry carries an application-dependent key. A message is routed to the node with an identifier closest to that key. This is achieved by comparing prefixes of increasing length, leading to a decentralized and structured organization overall. The key is a hash of the file name and author in PAST [15]. PAST [17], as noted above, builds a file system on top of Pastry’s routing substrate. An algorithm that assigns the key value uniformly is used. Files are then statistically assigned to storage nodes to maintain a balanced load. PAST stores replicas on r nodes whose node ID is numerically closest to the file identifier. The number r is chosen in proportion to the demand for the file. When a node becomes overloaded with files and replicas, some files or replicas can be offloaded to other nodes. PAST nodes can also use unused portions of their disk space to cache files.
14
5.4.1. Security
The security measures in PAST are built upon a number of assumptions [18]. PAST does not specify what public-key cryptosystem and cryptographic hash function are to be used but does assume that it would be computationally infeasible to break them. The underlying infrastructure comprised of clients, node operators and node software are not trusted and it is possible that malicious nodes may gain control of individual PAST nodes. However, most nodes in the overlay are assumed to be well-behaved. 5.4.2. SmartCards
To use the system, a smartcard is needed by each PAST node and user [18]. Each card has its own private/public key pair. The public key is signed with the smartcard issuer’s private key for certification purposes. The smartcards generate and verify various certificates used during insert and reclaim operations and also maintain storage quotas. It is assumed that an attacker cannot control the behaviour of the smartcards used in this system. 5.4.3. System Integrity
This section describes a few basic measures taken by PAST to maintain system integrity [18]. To maintain some degree of anonymity, identifiers for nodes and files are uniformly distributed. To provide a basic level of protection against malicious nodes, the Pastry routing algorithm allows a node to route around a malicious node after repeatedly not receiving service from it. To prevent a system overload in terms of data storage, the sum of all client quotas and the total available storage in the system are expected to be balanced through a third party or broker, who sells the smartcards and maintains the balance between supply and demand through the monetary price of storage [18]. 5.4.4. Persistence
PAST provides some degree of assurance with regards to persistence of user data in the PAST system [18]. Reclaim certificates ensure that unauthorized users are not able to reclaim a file’s storage. Storage receipts ensure that the specified number of replicas of the file continue to be stored. The quasi-random distribution of the node identifiers ensures that there is sufficient diversity in the storage nodes storing a particular file.
15
5.5.
Oceanstore
The goal of Oceanstore is to provide a persistent storage infrastructure spanning the entire globe [7]. Oceanstore envisions being used in a ubiquitous environment to provide a place to store persistent information about self-maintained devices, such as configurations, so that this information is not lost when a device is rebooted or replaced, and persistent data so that devices can synchronize amongst themselves transparently with minimal human intervention. Oceanstore also aims to make information available to users at all times regardless of their location and rate of connectivity. This information is to be made available securely and with minimal latency, moving the data closer to the requesting node through the overlay if required. Oceanstore assumes a fundamentally untrusted infrastructure. There is no guarantee about the availability and behaviour of nodes.
Objects are replicated and stored on multiple
servers, in an attempt to make data available even in the presence of failure and attacks. To keep data consistent, storage nodes take part in distributed consistency management amongst themselves. 5.5.1. Routing
Each request header consists of the required GUID, a random number and a small predicate. The destination IP address is not included in the message header.
Routing takes place by
consulting a distributed data structure from node to node until a destination with the matching predicate and with the desired GUID is found.
5.6.
FARSITE
FARSITE is designed to be a reliable file storage infrastructure built using untrusted machines [8]. However, it is not fully autonomic and requires some degree of human intervention in terms of the system administrator assigning certificates to new users and machines. Furthermore, FARSITE does not scale beyond about 10,000 nodes, which makes it suitable for an enterprise wide network but not for the Internet.
16
5.6.1. Machines in FARSITE
The machines that form part of the FARSITE system are not dedicated servers but they are all assumed to be interconnected by a high bandwidth low latency network whose topology can be ignored. Furthermore, it is assumed that machines are accessible for majority of the time. Each machine in the FARSITE system plays one of three roles: client, member of a directory group, or file host. A client machine is one that interacts with a user directly. A directory group is a group of machines that collectively manage file metadata using a Byzantine fault tolerant protocol. Every member stores a replica of the information and each member processes each update received from a client. Data consistency is guaranteed as long as fewer than a third of the machines misbehave. File hosts are picked by the directory group to store the replicas of a file. 5.6.2. Files and Directories
Farsite tolerates large-scale read-only sharing and small-scale read/write sharing, assuming that no files are both read by many users and also frequently updated by at least one user. It is assumed that malicious users do exist in the system, and that they attempt to read file data or metadata to which they have not been granted access, or they attempt to destroy or corrupt file data or metadata. A directory system is a key attribute of a file system. Typically, it is organized as a tree, which has a single root. In FARSITE, however, there is no single root. Each machine can have its own root. The administrator generates a unique name for the root and assigns a set of machines to manage the root in a Byzantine-fault-tolerant manner. 5.6.3. Security
Encryption, one-way hashing and replication are used to ensure the privacy, integrity and durability of file data.
Directory metadata is maintained by Byzantine replicated state
machines and specialized cryptographic techniques that permit metadata syntax enforcement without compromising privacy.
17
Trust is managed using public key cryptography certificates. There are machine certificates, user certificates, and namespace certificates. Machine certificates bind machines to their public keys, user certificates bind users to their public keys, and namespace certificates bind namespace roots to their managing machines.
Administration is an issue of signing
certificates issued to new users and machines. All certificates have an expiration date.
5.7.
Publius
The goal of Publius is to prevent any third party from being able to change or delete material published by someone else. Unauthorized changes to published materials should be detected. The publisher of any material should remain anonymous so that a malicious party cannot target a particular person’s data. Publishers should be able to make changes to their own material or delete it if required. The nodes storing the content should not be able to tell what is contained in the data items they are storing. The system should work even if some of the storing nodes are malicious. Material should be publishable without any expiry date, i.e. it should be possible for material to have indefinite persistence. Finally, it should be possible to add new features and users. In Publius, publishers publish content, servers store the content and retrievers browse the content. Publius assumes a static system-wide list of available servers that is known to all nodes in the system. However, as future work, the authors propose including the server IP address in the URL itself, thereby eliminating the need for a fixed table of servers. A publisher encrypts a file before publishing it. The content is spread over some of the servers. The key, K used to encrypt the file is split into n shares, using Shamir’s secretsharing [11] mechanism, such that any k of the shares can reproduce the original K but k-1 shares give no hints about the key. Each server receives the encrypted content and one of the key shares. To browse content, a retriever must get the encrypted content from one server and k of the key shares. Data is accessed by using a special URL that is created in the publishing process. The published content is cryptographically tied to the URL, such that
18
any modification to the stored Publius content or the URL results in a failed tamper check. A mechanism exists to allow only publishers to update or delete their content. 5.7.1. Publish
Before publishing any content, the publisher first generates a random symmetric key K. Using this key, he encrypts message his M to get {M}K. The key K is split into n shares using Shamir secret-sharing such that exactly k of them are required to reproduce the key K but any less than k give no hints about the key. For each of the n shares, a name is produced by concatenating each share with the message and hashing the total bit string as shown here: namei = wrap(H(M sharei)) H is the hashing function. Wrapping refers to XORing the first half of the hash output with the second half. The name produced in such a manner is dependent on every bit of the file as well as the share contents. The names are used to form the URL to access the data. The publisher has a static list of m available servers in the system. For each of the n shares, the location to store the share on is calculated by calculating an index to the list of servers as shown: locationi = (namei MOD m) + 1 A minimum number of unique servers, d, are required to store the content and must be at least as large as k, the number of shares required to reconstruct the key K. If at least d unique values are not obtained this way for location, another K is picked and the process is repeated. Once the d values are finalized, it is these d names that are concatenated together to form the URL for that data item. 5.7.2.
Retrieve
To view the content, a user parses out the namei’s from the URL and calculates the location index to retrieve the location from the static list of servers. The location index for each share is calculated simply as: locationi = (namei MOD m) + 1 The encrypted content is retrieved from one of these d servers. Of these d servers, k servers are chosen arbitrarily to get the key shares. The shares are combined to get the key K and the
19
content is decrypted as M. To verify the k namei’s, the user calculates the name for each share using the M that was just decrypted, as shown below: namei = wrap(H(M sharei)) If any of the names don’t match, it could mean that either the URL or the content is corrupt So the user can try another set of k shares or an encrypted file on another server or both.
5.8.
Dagster
Dagster has been designed to protect censorable material from being deleted but the principles can be applied to securing content from malicious users as well. Dagster tries to protect content by intertwining documents from different sources together so that a malicious user who has a stake in the system (i.e., has contributed data to the system or knows someone taking part in the system whom he does not want to harm) cannot delete any files without risking losing his own [10]. Of course, if the malicious user does not have a stake in the system, he will not run a risk of losing anything. Although defined for the single server case, data can be replicated on different servers in the same way as clients originally add data [10], although how data replicated a number of times this way would be treated is not clear. Dagster does not aim to anonymize the participants in the system itself. Hence, it requires an anonymous connection to the servers and an out of band channel to announce when a document has been published. Dagster has a number of design goals. A malicious node should not be able to identify the contents of a piece of data stored on a server. It should not be possible for a malicious node to damage specific pieces of data without damaging others. Publishers and retrievers of information should remain anonymous so that a malicious node is not able to correlate the identity of the publisher or retriever of a block of data with the data itself. The server should not be able to tell the difference between stored data and random data. Users should be able to tell if anyone has tampered with the published data.
20
5.8.1.
Publishing
Before publishing can begin, the publication server sorts all blocks it is currently hosting by block identity. Then it constructs a Merkle tree out of them. A Merkle tree is computed by first breaking a file into blocks. Each block is hashed and forms the leaves of the Merkle tree. These block hashes are taken, say r at a time, with every hash being picked only once, and combined and hashed again. This forms the next level up in the tree. These hashes are combined and hashed in the same way again until only one hash, the root hash, is reached in the end. The advantage of this approach is that given only one block from a file, it can be validated without the rest of the file and in logarithmic time. This is done by hashing the block and combining it with the hash values from the Merkle tree to see if we get same the root hash in the end. If we don’t, Dagster concludes that the block is not authentic. Of course, the tree could be inauthentic too but no check is done for that. Block Selection When ready to publish, the publisher first splits the document into b-bit blocks. Then he randomly queries the Dagster system and obtains a number of pre-existing blocks. To do this, the publisher traverses down the server’s Merkle tree and checks if it contains the blocks it says it contains. Then it randomly chooses a number of pre-existing blocks, checks if their contents are random through some statistical tests and if they are, proceeds to the next stage. However, if even one block is found to be not random, the server is deemed malicious and abandoned. Block Committal Then the publisher computes as many random keys as blocks of data to be published. It encrypts each data block and XOR’s it with the XOR of all the random pre-existing blocks as shown below: Xi = Eki(Mi) XOR (XOR Bj,i for j = 1 to c) for i=1 to n It sends Xi, each new block so obtained, to the server. The server checks the received blocks for randomness through some statistical tests and accepts the ones that pass. Theoretically, they should all pass as they were computed using pre-existing blocks which were all random.
21
Then the server calculates a cryptographically secure hash of each block, which forms the identifier (ID) for that block, and adds it to the system. Document Announcement The publisher periodically and anonymously queries the Merkle tree of the server to make sure that his committed blocks are still being stored and reported by the server. When it determines that other blocks have linked to his own blocks, he releases the blocks from his own memory, resting assured that deleting his blocks would put other blocks at risk so the server would refrain from deleting his blocks. 5.8.2.
Retrieving
Each block in a document is named in terms of the key used to encrypt it and a permutation of the block ID’s of the pre-existing blocks B that it linked to as well as the resulting block X, as shown below: [(k1,
[h(B1,1), …., h(Bc,1), h(X1)]),.., (kn,
[h(B1,n), …., h(Bc,n), h(Xn)])]
To retrieve a document, the publisher asks the server for the block ID’s in the name of the document. On receiving the blocks, the publisher checks the cryptographic hashes to make sure that the blocks are authentic. On being satisfied with the authenticity of the blocks, the publisher calculates the message block as a decryption of the XOR of all the blocks, as shown below: Mi = Dki (Xi XOR [XOR Bj,i for j=1 to c ] ) for i = 1 to n
22
6. Security Requirements A P2P file system must provide anonymity to its users [3]. The different types of anonymity required are author anonymity so that it is not possible to know who authored a certain document, server anonymity so that it is not possible to know which nodes host a document, reader anonymity so that it is not possible to know who is accessing a document, and finally document anonymity so that it is not possible to know what documents a certain server holds. Every node should only have one identity [12]. No node should be able to masquerade as another node. There should be some binding between a user and his identity and between a machine and its identity. No document should be able to masquerade as another, i.e. there must be a mechanism in place to check the authenticity of a file. There should be a binding between a document and its identity which can be verified by any node and which cannot be tampered with by any node. File authenticity is a way of attesting to the originality of a file and is a way of checking for any tampering [3]. No node should be able to deny a file when it is requested or serve the wrong file in response to a request or corrupt a document and serve that. All files should remain available in a P2P network [3]. Only legitimate users must be able to add new documents to the system and read and modify documents that already exist in the system [3]. Given that a file-system also has a directory tree, the access control should also extend to particular directories. All queries must be routed correctly. The communication channels must be secure [2]. 23
7. Identifying and Dealing with Attacks Various types of attacks are possible in a peer-to-peer file system. These can be classified as content attacks, routing attacks and identity attacks. The following analysis describes how each architecture deals with each attack. If an architecture is not mentioned for an attack, it means that the architecture does not have any information on protecting itself from that attack. We will not talk about viruses and Trojans in this analysis as that falls under the realm of “intelligent” agents, which is beyond the scope of this report.
7.1. •
Content attacks
A node may store a part of a search index but not perform search operations over them or lie in its responses about them [2].
A means of binding a search index to the node is required. If the user refuses to perform a search, the node should be deemed malicious. In this light, the index can be viewed in the same way as content, attacks on which continue below. •
A node may agree to store a copy of a document but delete it instead, giving the wrong impression that there exists a copy of the document on that node when there really does not [2].
•
A node may store a copy of a document but not perform search operations over them or lie in its responses about them [2].
•
A node may serve corrupted versions of the document it stores, or equivalently a totally different document, or may refuse to serve the document altogether [2].
It must be possible to check the authenticity of a file. This can be done in a number of ways. A timestamp could be associated with each file so that only the oldest file by a certain name is considered authentic.
However, this solution is obviously flawed and may wrongly
blacklist genuine resources published later by the same name. Another approach is of having a single certifying node that can attest to the authenticity of the file using public and private 24
keys. But this system has the drawback of being a central point of failure. To divide up the task, a voting-based approach can be taken where multiple nodes attest to the authenticity of a file and if the file can win a sufficient number of votes, it is allowed to pass. Lastly, reputation-based systems follow a completely decentralized approach and associate weights with each node based on past performance [3]. However, voting and reputation based approaches are beyond the scope of this report. It is possible to bind the document identity to the document itself in such a way that the binding can be verified by any node and it cannot be tampered with by any node. One way to do this is to calculate a secure hash using SHA-1 or MD5 over the document’s contents to produce an identity for the document that would be very difficult to forge [2]. To avoid single points of responsibility, any document must be replicated on k number of nodes. The number k can be determined by mathematically, for example, by estimating the probability of failure of each node. Further, when accessing documents, multiple replicas must be consulted to check that the document each of them has is the same, which means that there is a good chance that the document has not gotten corrupted. Napster In Napster, implicit replication took place across the user-base, whenever one user downloaded a file from another. Gnutella Gnutella makes no caching or replication optimizations on the downloaded files and even the downloaded file may not be added to the pool of shared files based on the user’s request. This makes it easier for a malicious user to corrupt all copies of a document, as there are fewer of them. Furthermore, to weed out such nodes from the system from time to time, nodes should be randomly asked to provide a document that they are supposed to store or random parts of it. If they refuse to serve up the document or if the returned data does not match the expected
25
content, the node should be deemed malicious and avoided [2]. How to actually blacklist nodes identified this way falls under the realm of reputation management and is beyond the scope of this document. PAST PAST has a mechanism of offering store receipts [18]. Once a file is successfully stored on a node, the storing node issues a store receipt to the client node. It gives the client proof that the storage node is supposed to store that file and also allows the client to check if the right number of replicas has been created When a file is retrieved, the file certificate is returned along with it to allow the client to verify that the contents are authentic. Nodes are randomly audited to see if they can produce the files they are supposed to store. However, PAST does have a problem. It stores whole files, not blocks, which makes it easier to censor or corrupt the data once access to the single file is obtained. In a block-oriented approach, corrupting a block doesn’t mean that the whole file is corrupted. Oceanstore It is unclear what precautions are taken by Oceanstore to prevent this attack. It seems that they do not perform any sort of hash comparison to make sure that the data retrieved is in fact valid. FARSITE The directory group in FARSITE keeps a cryptographically secure hash of the content of the file replicas managed by the directory group so that when file content needs to be fetched from a file host, it can be validated. When a client is looking for a file, the directory group replies with its namespace certificate, a lease on the file, a one-way hash of the file contents, and a list of file hosts that store
26
encrypted replicas of the file. The client picks one host randomly, obtains the encrypted file and then verifies its contents by generating a one-way hash on those contents. If the user has read access to the file, he will be able to decrypt the file. Integrity of metadata is ensured by the directory group members using the Byzantine faulttolerant protocol. Integrity of file data is ensured by computing a Merkle hash tree over the file data blocks. Thus in Farsite, a copy of the tree is stored with the file and a copy of the root hash is kept in the directory group responsible for that file’s metadata. Publius A user accesses a data item using its URL. If the data item or the URL itself have been tampered with, the tamper check will fail. Dagster Both the publisher and the client use statistical tests to test the blocks received from each other for randomness. If even one block is not random, the sender of that block is deemed malicious and the transaction is aborted. During block committal, the server calculates a cryptographically secure hash of each block received from the publisher. This hash becomes the identifier of the block and is what is stored in a Merkle tree. This way, each entry in the Merkle tree becomes dependent on the contents of the blocks that it depends on, providing a fast means to check for data integrity of the blocks. At block selection time, the publisher randomly queries Dagster system and obtains a number of pre-existing blocks. To do this, the publisher traverses down the server’s Merkle tree and checks if it contains the blocks it says it contains. Additionally, the publisher doesn’t release the blocks from his own storage until he is sure that other blocks have linked to his, providing his blocks a blanket of protection against deletion. To this end, the publisher periodically and anonymously queries the Merkle tree of the server to make sure that the committed blocks are still being stored and reported by the server.
27
Multiple malicious nodes may all corrupt their copies of the same document, thus giving other users the impression that is the only copy available [2]. When malicious nodes coordinate amongst themselves and corrupt all copies of a document in the same way, it makes it harder to verify if the document is authentic. To circumvent this problem, the replicas of the document should be placed on random nodes and it should not be easy to determine for a malicious node where the replicas are. In other words, the data stored on nodes should remain anonymous. Furthermore, replicas should be checked to ensure that they have not been tampered with. PAST Each replica has a file certificate, which ensures that the file has not been altered. Oceanstore No checks are provided. FARSITE Each replica is managed by the directory group that keeps a secure hash of each replica to ensure that the replica returned from a file host has not been altered. Publius The URL of a file depends on the file contents so any change in a replica would cause the URL check to fail. Both the index as well as the data should be distributed to prevent the loss of any information. Napster Indeed, in Napster the centralized index formed a single point of failure and shutting down the central indexing server in Napster brought down the entire network [13].
28
FARSITE When a directory group member is inaccessible even for a short period of time, the other members of the group pick another member randomly from the set of machines they know about and replicate their state to that machine. Provided that the random machine picked as replacement is not malicious, this mechanism provides some protection against an attack on the directory group. If data cannot be found in the P2P overlay, the data is as good as lost. More details on this type of attack are provided in the routing attacks section. Gnutella Gnutella’s hop-limit on each query is an attempt to limit message explosion. However, it also limits how far the query propagates, which means that search may not result in success even if the file does exist on some node, which means that once a file is “uploaded” to the Gnutella network, it may not even be found. Studies find that only half of the peers are reached by Gnutella’s flooding mechanism [13]. FastTrack: It is unclear how far the broadcast travels amongst the superpeers in FastTrack. PAST: PAST uses deterministic routing to ensure that data can be found. Oceanstore: It is unclear how Oceanstore provides this assurance that data can be found. FARSITE: FARSITE uses a directory group that keeps track of replicas to ensure that data can be found. Publius: Publius uses a URL and a static list of servers to ensure that data can be found.
29
If a malicious user can breach the access control system, he will be able to illegitimately traverse directory subtrees [3]. Oceanstore In Oceanstore, directories are represented as objects, mapping human readable names to GUID’s. Thus it is not possible to tell by looking at a GUID, what directory it represents. Furthermore, arbitrary directory hierarchies and soft links to other directories are allowed. Any of these directories can be made root with respect to a user, and it is secured through public key encryption. FARSITE In FARSITE, a namespace certificate associates the root of a file-system namespace with a set of machines that manages the root metadata. This ensures that no unauthorized user tries to access that namespace. With time, the file-system metadata managed by any directory group is expected to grow. When this happens, it is possible for a directory group to delegate a portion of its namespace to another directory group. The machines to form this new group are picked randomly by the first group. The first group first collectively signs a new namespace certificate delegating authority to the newly formed group. The second group can similarly delegate authority again and so on. When it comes time for a directory group to prove a client that it has authority over its directory space, it can present the namespace certificate signed by its parent, another certificate signed by its parent’s parent and so on until it reached the original root namespace certificate signed by the directory group that the client recognizes as authoritative. If a malicious user can breach the access control system, he will be able to illegitimately add new documents [3]. Napster, Gnutella, FastTrack Anyone with the software can make files visible to others on the overlay network.
30
PAST Anyone with a smartcard can insert files into PAST. Oceanstore Any entity that can be assigned an Oceanstore-compliant GUID and knows of other nodes will be able to add documents to the system. FARSITE A system administrator adds users to the system by issuing them a certificate.
Thus,
unauthorized users will not be given a certificate, because of which they will not be able to add documents to the system. Publius Anyone with knowledge of the Publius servers can add files to the system. Dagster Again, anyone with knowledge of the hashing and randomness-testing algorithms will be able to add files to the Dagster system. If a malicious user can breach the access control system, he will be able to illegitimately read existing documents [3]. PAST PAST provides no protection against unauthorized reads [18]. The read-only permission needs no smart card so anyone can read any files. Oceanstore Oceanstore does have reader restriction. Data that is not completely public is encrypted and the encryption key is distributed to users with read permission. This prevents unauthorized users from reading that data. If the owner of the data wishes to revoke read permission on
31
his data, it means that the replicas must be deleted. Alternatively, they can be re-encrypted with the new key that the owner presumably provides. However, old readers will still be able to read cached copies or copies that have not been deleted or re-keyed by malicious servers. FARSITE In FARSITE, both file content and user-sensitive file and directory names are encrypted for privacy. The client encrypts the data and metadata before sending it to the directory group. To encrypt a file, the file is broken down into blocks. A one-way hash of each block is calculated and this hash is used to encrypt the block. Then the hashes are encrypted using a randomly generated symmetric file-key. The file-key is then encrypted separately by the public keys of all authorized reader of the files. The file-key encryptions are stored with the encrypted file so that a user with a valid private key can decrypt the file key and then the file itself. The block approach enables a client to read and write individual blocks rather than the whole file every time. The file and directory names are encrypted using a symmetric key that is encrypted with the public keys of authorized directory readers and stored in the directory metadata. Publius: Publius does not provide any sort of connection based anonymity. Publius allows anyone to read any file. If a malicious user can breach the access control system, he will be able to illegitimately modify existing documents [3]. PAST Data privacy can be ensured through a cryptosystem. The cryptosystem to be used is not specified by PAST, as it does not involve the smartcard. Data integrity is ensured by means of the file certificates issued by smartcards. Oceanstore The owner of a data item in Oceanstore can restrict write access to only certain users by using an Access Control List (ACL). This ACL is provided by the owner himself and
32
contains an entry for each user in terms of his signing key and the privilege granted to him, but not his explicit identity. Every write request is signed by the user and would be verified by the server using the signature key present in the ACL. Oceanstore only makes the ciphertext of the data available to the storing node. As a result, arbitrary computations and manipulations on stored data are not possible. Furthermore, Oceanstore defines updates as lists of predicates associated with certain actions. It is assumed that no one server can be trusted to perform commits. Hence, every server that receives an update request evaluates each predicate, and if true, applies it atomically to its replica. If all servers are able to do this successfully, the update is said to commit. Otherwise the update is said to abort. In Oceanstore, the metadata is not encrypted so it allows the version and size to be compared. Moreover, the data is encrypted using a position-dependent block cipher, which allows the blocks to be compared even in an encrypted form, which also enables search operations on the encrypted data. Blocks can also be replaced, inserted, deleted and appended. To maintain consistency in updates, the storing nodes are organized into two tiers. The primary tier nodes receive the updates first and agree on a final commit order for updates amongst themselves. The secondary tier nodes are organized into one or more application level multicast trees. Once the primary tier nodes agree on a commit order, they timestamp the updates and send them out to the nodes on the secondary tier. FARSITE In FARSITE, directory groups keep their shared directory metadata consistent using a Byzantine fault tolerant protocol. This metadata includes access control lists of public keys of all users authorized to write to that directory and to contained files. When trying to access a directory, a user is authenticated using his private key
33
Updates are first made to the client’s local disk and added to a log. Periodically, the update log is transmitted to the directory group, where it is verified before being applied. This is done as follows. When a client first contacts a directory group, it generates a random authenticator key and splits it into secret shares, which are distributed among members of the directory group. Each update is signed with the key and the MAC of this signature is sent to the directory group along with the update log. The group members jointly reconstruct the key, validate the updates, and then discard the key. The key is not stored on the client’s local disk so that it does not fall into the hands of a hacker if the client crashes. Modifying a file should keep the metadata consistent with the file. Publius Before publishing a document in Publius, a password PW is generated, concatenated with the domain name of the server to store the document and the following hash is calculated: H(server_domain_name PW) This hash value is sent along with the document and key share to each server. To update the content, the following are first specified: the new file name with the updated content, the original URL, the original password PW and a new password. The new file is published first in the same way as the original file was published, which produces a new URL because the URL is tied to the content. Then the original URL is used to find the n servers containing the old file and each of these files is sent the old password (for authentication), the old namei and the new URL. Each of those servers deletes the old content and creates a redirection link to the new URL. Since only the publisher has the original password and because the password is stored in a hashed form on the server, it would be difficult for a malicious user to modify existing files without authorization. A redirection is used while preserving the old URL because others may have links to the old URL. However, to get redirected, the same new URL must be received from all k servers tried. If they don’t match, another set of k servers is tried, until a matching condition is found, otherwise the URL is deemed invalid.
34
However, A malicious user may try to launch a redirection attack by linking at least k servers to new URLs. This way, if the bad servers are picked to get the content and shares, innocent users trying to access that data item would be redirected to the malicious users’ content. Changing the URL on at least n-k+1 servers would guarantee that the innocent users will get redirected to the new URL, since a maximum of k-1 users only would remain unaffected. To protect against these attacks, a URL may be configured as non-updateable (specified within the URL itself) because of which a redirection would not take place. A malicious user may even delete the update URL on each server. In this case, retrievers would either get no content, if the old content has been deleted, or the old content, if it has not been deleted. Malicious users may publish a document under the same identity as an existing document to make it difficult to find the authentic document [2]. Napster, Gnutella, Kazaa No checks are performed in Napster, Gnutella and Kazaa on the contents of the shared files and a user could easily share bogus files under the same name as the authentic files. PAST PAST uses the file name and author to form the identifier for the document and the content is not used at all. However, because the smart card signs a file certificate for the document, the user can be assured that someone looking for a file authored by him, he will not be duped into accepting a fake document. If the author decides to publish another document with the same name but bogus content, this document would actually replace the previous correct one, so there is no chance for the same author introducing fake versions of his own documents into the system. Oceanstore It is unclear what precautions are taken by Oceanstore.
35
FARSITE As described earlier, all file updates are verified by the directory group. Publius Only the contents of the file are considered to form the URL to access the data. The URL has nothing to do with the original name of the file. Hence, any retrieve operation would only fetch the correct file. Dagster Again, only the contents are intertwined with the contents of other files. The Dagster name of the file is a function of the contents of the file, not the original name of the file. Hence, any retrieve operation would only fetch the correct file. Copies of a data item may be in an inconsistent form after an update. Data inconsistency that stays on for a long time without being resolved will give wrong views of the data to a user. FARSITE To provide consistency, FARSITE uses a leasing mechanism. There are content leases, name leases, mode leases, and access leases. Leases have an expiration time so that a disconnected client does not render a file inaccessible. Content leases are used to maintain data consistency. A content lease may cover a single file or an entire directory. The content lease is requested from the directory group managing that file or directory. A read/write content lease entitles a client to perform write operations to its local copy of the file. A read-only lease assures client that the file data it sees is not stale. FARSITE essentially has single-write, multi-reader semantics. When returning the lease, all logged updates are also pushed to the directory group, which applies updates before issuing a new content lease. To maintain namespace consistency, name leases are used. Some directory regions are private to certain users so it is better to issue a namespace lease on that directory region
36
rather than have the client frequently contact the directory group for a content lease. The name lease allows a client to create a directory or file by that name if it doesn’t exist or to create files or subdirectories under that directory. Access mode is specified in terms of read access, write access and delete access. Mode leases enforce these semantics through read, write, delete, exclude-read, exclude-write, and exclude-write mode leases. For example, to open a file with an exclusive access, a client would request read, write and delete access. However, if it wants a read-sharing access, then it would request read, exclude-write and exclude-delete access. To enable consistent deletion, FARSITE provides three types of access leases: public, protected and private. A public access means that other clients can also open the file. A protected lease means that any other client would have to ask the first client before opening the file. A private lease means that no other client can access the lease other than the first one. To mark a file for delete requires a client to obtain a private or protected access lease on the file first. If a malicious user can breach the access control system, he will be able to illegitimately delete existing documents [3]. PAST Before issuing a reclaim operation, the equivalent of a delete, the smartcard of the user generates a reclaim certificate that is sent along with the reclaim request to the nodes storing the file.
The reclaim certificate contains the file ID and is signed by the smartcard. The
storing node compares the signature with that in the file certificate stored with the file. This acts as a way of authenticating the user to make sure that no one else reclaims the file’s storage. If the signatures match, the storage node generates a reclaim receipt containing the reclaim certificate and the amount of storage reclaimed and is signed by the smartcard of the storage node.
37
Publius In Publius, the publisher of some content can delete the content from all servers. To do this, before publishing the document, a password PW is generated, concatenated with the domain name of the server to store the document and the following hash is calculated: H(server_domain_name PW) This hash value is sent along with the document and key share to each server. To delete the content, the publisher sends this value to each hosting server along with the namei corresponding to that server. If the hash values match, the server deletes the content. Since only the publisher has the password and because the password is stored in a hashed form on the server, it would be difficult for a malicious user to delete files without authorization. However, if all n copies of a document are deleted by a malicious user, then the document cannot be recovered. Since up to k-1 shares are insufficient to recover K, if n-k+1 shares are deleted, the key K cannot be recovered. Dagster Dagster provides delete protection in an indirect way. During block committal time, the publisher combines his blocks with the pre-existing blocks on the server in the way defined in an earlier section. Because of this inter-twining, a server wanting to delete a block belonging to the publisher cannot do so without deleting some data belonging to another party that the server does not want to target. If a malicious user can breach the access control system, he will be able to illegitimately modify the access controls so that only he can access the data in the future. PAST The security bottleneck in PAST is the smartcards. If an attacker can break the security of the smartcards, he can cheat the system.
38
Oceanstore The security bottleneck in Oceanstore are the ACL’s, which are not protected. FARSITE The security bottleneck in FARSITE are the access control lists and there is no protection provided for them. However, using a fresh key every time the directory group is contacted ensures that the ACLs remain secure. Furthermore, each update is validated using the private key of the owner. Publius The security bottleneck in Publius is password hashing mechanism that permits a user to update or delete a file. If a hacker can break the hashing algorithm, he may be able to recover the password.
However, this is very difficult to achieve, as the only given
information is a hash value, not even ciphertext. Dagster Dagster allows users to write and retrieve data. However, there is no mechanism to delete or update data. The only way to remove any information from the system would be to delete the published blocks, which runs the risk of deleting information that is not supposed to be targeted. Hence, knowing where the data is stored is only a matter of knowing what the URL is and this URL cannot be changed but can be made inaccessible by deleting some blocks, which however may not be what the hacker wishes to do. A malicious user may try to exhaust a node’s storage space by storing too many files on it [6]. This would prevent the node from storing files for anyone else, which is effectively a DoS attack. PAST A storage quota is associated with each smartcard. When storing a file, the file certificate contains the size of the file multiplied by the replication factor and this amount is debited from the storage quota of the smart card. When reclaiming a file, the reclaim receipt is used
39
as proof by the smartcard to credit back the corresponding amount. The smartcard also specifies the amount of storage contributed by the node. Before a user inserts a file into the PAST system, his smartcard issues a file certificate = {hash of file’s contents, file ID, replication factor, randomizing salt} and is signed by the smartcard. Each storing node can use the certificate to check if the user is authorized to insert the file into the system, preventing clients from exceeding their storage quotas; if the contents of the file have been corrupted by a faulty or malicious node en route to the destination storage node; and if the file ID is authentic, so that malicious nodes do not generate files with nearby file ID’s in an effort to exhaust the storage capacity of the storing node. However, the use of smartcards requires clients to periodically replace their smartcards to ensure key freshness (about persistent). Knowledgeable attackers can compromise a storage card and cheat against the storage quota, thus being able to mount denial of service attacks by overloading a node with excessive files. Publius A malicious user in Publius can try to consume the entire disk space on a particular server, thereby making that server unable to store anyone else’s content. To prevent this, storage space could be charged for. Alternatively, each client trying to publish content could be asked to execute a complex computation or do some useful work for the Publius system first. This would act as a deterrent to malicious users. Another scheme suggested by the authors is to limit storage by IP address but this would be a problem if the user’s IP address changes the next time he connects to Publius and would also defeat the goal of user anonymity.
40
7.2.
Routing attacks
A node may intercept messages between other nodes and modify them en route [2]. This would make the communication channels insecure, which is undesirable. FastTrack The hierarchical structure of peers and super-peers in FastTrack reduces the number of messages exchanged, which limits the amount of data available to a malicious peer to manipulate. Other than this, the other protocols provide multiple paths to be able to get around malicious nodes after repeated failures to transmit a message. A malicious node might route messages incorrectly without following the correct protocol or it may simply declare a random node to be the node responsible for a key [6]. In this case, if the source node is far away from the declared destination node, it may not be able to verify if that node is in fact the correct node. If the operation was a write operation, the wrong node may end up becoming responsible for a certain file. If it’s a lookup operation, the result will be wasted bandwidth. In structured protocols where the request should be getting closer to the key, as in PAST, this attack can be detected by observing whether the request is getting closer to the key or not [6]. However, this would require the querying node to be able to observe the lookup progress, which can be an expensive operation. A malicious node can route all queries to a single random node, which would overload its CPU and crash it or consume all its network bandwidth. Either way, files on that computer will be effectively lost and there will be one less node to aid in routing and to maintain replicas on [3].
41
Gnutella allows anyone to create queries for anyone else [13]. This means that a number of malicious nodes can all broadcast queries spoofed with the IP address of the victim node, resulting in query results all being sent to the victim node instead of back to the malicious nodes, leading to a “traffic amplification” for that node, consuming much of its bandwidth and CPU cycles and resulting in a denial of service attack it. A recent update to the Gnutella protocol is the Gnutella2 protocol for file-sharing. This protocol actually does provide security mechanisms to prevent denial of service attacks on innocent nodes [14]. To verify that the return address of a query is indeed of the original sender, a system of “query keys” is used. Before transmitting a query to a peer, a node must obtain a “query key” for that peer and include it in the transmission. The query keys are unique for each pair of query and search peers and have a long life. A malicious node might refuse to route messages at all. The last three attacks can take place easily in the FastTrack network. If a malicious peer is able to act as a super-peer, it could exploit its position and launch attacks from there. For example, the malicious node could return false results to the peers under it. A more benign attack would be to stop processing queries from the peers under it. In deed, it is this ability that is modeled in Daswani and Garcia-Molina’s study [4], described below. This would result in a denial of service attack on those peers. However, it would only last for a short period of time as the peers will seek out new superpeers when they do not hear back from the malicious one. Daswani and Garcia-Molina define a model to limit the effect of a DoS attack where a malicious node stops processing queries from other nodes and starts broadcasting a large number of bogus requests of its own [4].
They build their model upon a super-peer
architecture like that of FastTrack that uses broadcasts to route queries. The basic idea is to balance the load of queries by limiting the number of queries processed from each neighbour and to drop any queries over the limit. They experiment with various Incoming Allocation Strategies (IAS), which determine how many queries from each neighbour a node would process, and with Drop Strategies (DS), which determine how nodes drop queries arriving
42
from their neighbouring peers. The paper describes the performance obtained with each combination of strategies for a number of different network topologies. The presence of malicious peers is simulated by setting the number of queries they send out to the system maximum, and by setting the number of queries they process from each neighbour to zero. The IAS’s used include weighted, where a different fraction of traffic from each neighbour is processed, and fractional, where a constant fraction of the traffic from each neighbour is processed. Other IAS’s proposed are least queries first, where the query with the smallest hop count is queried first, and preferred neighbours first, where a certain amount of preference is given to certain neighbours, perhaps based on a reputation metric. The DS’s used are proportional, where queries processed from each neighbour is in proportion to the number of queries received from that neighbour, and equal, where the same fraction of queries from each neighbour are processed. The network topologies experimented with are complete, cycle, wheel, line, star, grid and power-law. The metrics used to evaluate the effect of each policy are the amount of service generated for each node, which is how many of its queries are processed, and in terms of how much damage is inflicted by a malicious node at various hops away from it. Using these metrics, Daswani and Garcia-Molina conclude that broadcast style P2P networks are highly susceptible to application-layer, flooding-based DoS attacks if good load-balancing policies are not employed by the peers. Oceanstore By having multiple routing paths to the destination, Oceanstore minimizes the ability of malicious nodes from denying service. There should be a mechanism for verifying routing updates [6]. Otherwise, malicious nodes may be able to update routing tables incorrectly, leading to wrong routing in the P2P network and possibly also a Denial of Service attack if a large number of queries get routed to one node.
43
No architecture seems to deal with this problem. To join a P2P network, a node must bootstrap from a trusted node [6]. Bootstrapping refers to the process of contacting a node at start-up time to acquire some routing information and a list of other nodes so that the joining node can find its place in the network and start using the service. If the new node accidentally contacts a malicious node, the malicious node may only give the new node a list of other malicious nodes, making the new node a part of the malicious P2P network. The result of this would be that any documents that the new node publishes, would not be available on the real P2P network. Furthermore, the malicious nodes may be able to observe the usage behaviour of the new node and which files it accesses. Since all malicious nodes are working in concert, they may even be able to access all the documents published by the new node. A simple approach to dealing with this problem would be to discover new nodes at random times with the expectation that if the node has moved to the wrong overlay network, it would be able to rejoin the correct one now.
44
7.3.
Identity attacks
If the identifier space is not large enough or if the distribution of identities is not uniform, then it gives some hints to the malicious users about what identity for a node or file they should target. PAST PAST places the responsibility of providing a node ID on the smartcard. The smartcard calculates the node ID as a cryptographic hash of the smartcard’s public key. This ensures that the assignment of node ID’s is uniform in the address space, which in turn ensures that nodes with adjacent node ID’s are diverse in terms of geographic location, network attachment, ownership, rule of law, etc.
Because of the public nature of the hashing
algorithm and the public key, nodes can verify the authenticity of each other’s node ID’s. FARSITE Public key cryptography provides a certification authority to vouch for the identity of a node in FARSITE. If it is possible to determine what documents are stored on a particular server, then either the server can be attacked to make the documents unavailable or the documents can be deleted by an adversary. These documents could be confidential reports, for example. Dagster Since the name of every Dagster block contains the encryption keys and the blocks it depends on, it becomes impossible to know the nature of the data by just looking at the block name. Security components that rely on redundancy need to trust that a set of seemingly distinct machines is truly distinct and not one node masquerading as multiple nodes, an attack known as the Sybil attack [8]. Using the Sybil attack [12], a single node may take on multiple identities, all of which store a copy of the same document. This would defeat the original
45
purpose of replication, which is to place multiple copies of a document on different machines [2]. To protect against such an attack, the authors propose using either a central certifying authority as in Public Key systems, or an indirect way such as a hash of the IP address, or a challenge-oriented approach [12]. The challenge-oriented approach could exploit the limited communication, storage or computation resources that any node would have but issuing a challenge along those dimensions concurrently to all false identities. The reason for doing them concurrently is that if done serially, the single node would be able to use the resources to solve one challenge and then free them up for the next challenge. Users need to trust the authority of machines that offer to present data and metadata [8]. FARSITE FARSITE uses machine certificates to maintain the identity of a machine. A machine certificate associates a machine with its own public key which is used for establishing the validity of the machine as a physically unique resource. In addition, machines are instructed to accept the authorization of any certificate that can be validated with one or more particular public keys, which belong to the certification authorities in the system. These CA’s are really users whose certificates designate them as authorized to certify machines.
A
machine’s private key is stored on the machine itself Machines need to trust the validity of requests from remote users to modify file contents or regions of the namespace [8]. If a node’s identity is not kept anonymous, a malicious node may masquerade as that node and perform unauthorized operations [2] or it may be
possible to attack the author, reader or host of the document. Nodes should be assigned identifiers in a verifiable way [6]. This would make it possible to tell if the node claiming a certain identity does in fact have that identity. This would help in enforcing access control. As mentioned before, a binding must be created between a user and his identity and between a machine and its identity.
46
Napster In Napster, the user directly connected to one of the machines containing a desired file and downloaded it. The messages were sent in the clear so a user could spoof his IP address easily as someone else’s and either conduct searches in their name or direct query results to their machine. Gnutella In Gnutella, once the file is found, a direct connection is established between the requester and the destination to download the file [13]. Thus, although queries are tunneled through peers, which effectively hides the IP address of the original requester, once the file is found, the direct connection between source and destination reveals the IP addresses of both nodes. PAST A PAST user’s smartcard signature binds a request to a user. The association between a smartcard and the user’s identity is only known by the user and anyone he chooses to share this information with, thereby protecting his identity. The storage nodes also use their smartcards to sign certificates, which again protects the identity of the operator of that node. By using node ID’s instead of IP addresses, the Pastry routing scheme avoids the widespread dissemination of the binding between node ID’s and IP addresses. Oceanstore Oceanstore objects are named by globally unique identifiers or GUID’s. These are pseudorandom, fixed-length bit strings and are a secure hash of the owner’s key and some humanreadable name. GUID’s allow servers to verify an object’s owner efficiently and facilitate access checks and resource accounting. When it comes to directories, GUID’s act as selfcertifying path names that give users a more accessible naming facility but don’t let adversaries take over those names that belong to other users. A GUID for a server is a secure hash of its public key. And a GUID for an archival fragment is a secure hash over its data contents
47
FARSITE FARSITE uses user certificates to maintain the identity of a user.
A user
certificate associates a user with his personal public key so that the user identity can be validated for access control. Each user’s private key is encrypted with a symmetric key derived from the user’s password and then stored in a globally readable directory to be accessed upon login. It must be possible to change access controls if a user turns out to be a malicious user. Otherwise, the user may behave well in the beginning, gain access to many resources, and then launch a series of attacks based on his position. FARSITE User or machine keys in FARSITE are revoked by the issuing CA and stored in revocation lists that are periodically posted to a prominent and highly replicated location
7.3.1. Other comments
Some of the goals of anonymity conflict with the general ideology of a P2P file-system. For example, server and document anonymity would interfere with the goal of being able to search and retrieve documents in a P2P file-system. But techniques do exist to solve these problems, such as tunnelling requests and files through other peers, thereby not revealing directly where the file was stored and who requested it, and cryptographic secret-sharing techniques so that files can be read only if enough shares are available.
48
7.4.
General DoS attacks
Keyani, Larson and Senthil describe a proactive approach to detecting and dealing with a DoS attack, where nodes are forced off the network in an undefined way [5]. experimented with the Gnutella network.
They
They propose creating and maintaining an
exponential overlay network in additional to the active Gnutella network. This network, because of its exponential nature, is balanced in terms of per-node connectivity than Gnutella, where a small percentage of the nodes maintain most of the connections to the other peers. When a DoS attack is detected, each node starts switching its connections to members of the exponential network. Keyani, Larson and Senthil detect DoS attacks by determining the rate at which a node’s 1st and 2nd degree neighbours leave. Since a node’s 2nd degree neighbours are determined by the 1st degree neighbours, if the 1st degree neighbours leave, the node will get disconnected from the respective 2nd degree neighbours as well. It has been shown that the Gnutella overlay fragments severely when only the small percentage of highly connected nodes are removed. Thus, an attack on one of these nodes would result in a greater loss of 2nd degree nodes than 1st degree nodes and this is the premise of a DoS attack detection in this study. A random failure on the other hand would result in an equal average number of 1st and 2nd degree neighbours lost. The authors suggest using a threshold value for the percentage of lost 2nd degree neighbours as a means of detecting real attacks and filtering out false positives. Their experiment shows that this method improves the robustness of the Gnutella overlay to attacks and has minimal overhead.
49
8. Conclusions and Future Directions It was found that certain attacks have not been addressed well by any of the architectures. These attacks are described in this section of the report. In a PAST-like decentralized scheme, a node can receive routing updates from any node in its P2P routing table or from a node that claims to be new to the P2P system. No mechanism is provided to make sure that the routing update information received is correct. One mechanism that could help is to query each node in the received update and to tally routing tables with it to build a bigger picture of the network. This bigger picture could then be evaluated by each node to see how likely it is. An alternative is to study how trust can be established between peers on a mutual basis and use this trust as a reason to accept the routing update. A few checks could still prove to be useful, especially when the chain of trust becomes too long between peers. Similarly, a P2P node in a PAST-like decentralized scheme can bootstrap from any other node. No checks are currently performed to check if the bootstrapping node is trustworthy. Other than bootstrapping from a few globally trusted sources, trust management could prove useful in tackling this problem too. As part of the routing process, a message is sent from one node to another. However, there is no way of knowing that a node in the chain of P2P links will not misbehave and send the message to the wrong node. This problem needs to be solved in a better than observing lookup progress, which could involve sending back a message to the query originator at every hop. This mechanism can be expensive and the progress messages can be faked by a group of coordinating malicious nodes if the identity of a node can be spoofed.
An
alternative solution would be to get each node to return the address of the next hop in the overlay to the querying node, who would then contact the next hop himself. In this case, if the hop address was fake, it would be detected right away.
However, an additional
mechanism would still be required to check if the hop address was generated as part of the
50
protocol. Perhaps a probability analysis would help determine how likely the returned address is to be the next hop. A distributed way of certifying identities is also required so that we can protect documents without relying on a centralized entity as in FARSITE. Such reliance prohibits the scalability of the system, as it does in FARSITE. PAST uses a smartcard device to get around this problem.
However, reliance on a single breakable device does not provide sufficient
security. Research into reputation and trust management may help in this direction. If all copies of a document in the overlay are corrupted, then that document is essentially irretrievable. Some degree of integration with the Operating System (OS) may help in this regard. The OS should mark all files managed by the P2P protocol as being not writeable or delete-able by the user and as not belonging to that user so that he cannot modify the permissions on that file either. This would ensure that a file will not be modified even if it is encrypted and that the file will not be deleted unless the P2P protocol deems it necessary to do so. It is concluded that many security issues have been addressed by the P2P file-system architectures analyzed in this report. However, there are still some issues that need to be examined. As more research is conducted and more architectures are put into practice, more security problems will undoubtedly emerge.
51
9. References [1] The Peer-to-Peer Working Group. What is peer-to-peer? April 2003. Available at http://www.peer-to-peerwg. org/whatis/index.html. [2] Brian Cooper, Mayank Bawa, Neil Daswani and Hector Garcia-Molina. Protecting the PIPE from Malicious Peers.
Technical report, Distributed Systems Group,
Stanford University, May 2002. Available at http://dbpubs.stanford.edu:8090/pub/ showDoc.Fulltext?lang=en&doc=2002-27&format=pdf&compression=. [3] Neil Daswani, Hector Garcia-Molina and Beverly Yang. Open problems in DataSharing Peer-to-Peer Systems. In Proceedings of the 9th International Conference on Database Theory (ICDT 2003). January 2003. [4] Neil Daswani and Hector Garcia-Molina. Query-Flood DoS Attacks in Gnutella. Technical report, Distributed Systems Group, Stanford University, May 2002. Available at http://dbpubs.stanford.edu/pub/showDoc.Fulltext?lang=en&doc=200226&format=pdf&compression=. [5] Pedram Keyani, Brian Larson and Muthukumar Senthil. Peer Pressure: Distributed Recovery from Attacks in Peer-to-Peer Systems. IFIP Workshop on Peer-to-Peer Computing, in conjunction with Networking 2002. [6] Emil Sit and Robert Morris. Security Considerations for Peer-to-Peer Distributed Hash Tables. In the Proceedings of the 1st International Workshop on Peer-to-Peer Systems (IPTPS 2002), pages 261-269. March 2002. [7] John Kubiatowicz, David Bindel, Yan Chen, Steven E. Czerwinski, Patrick R. Eaton, Dennis Geels, Ramakrishna Gummadi, Sean Rhea, Hakim Weatherspoon, Westley Weimer, Chris Wells, Ben Y. Zhao. Oceanstore: An Architecture for Global-Scale Persistent Storage.
In Proceedings of the Ninth international Conference on
Architectural Support for Programming Languages and Operating Systems (ASPLOS 2000), pages 190-201. ACM Press, Nov 2000. [8] Atul Adya, William J. Bolosky, Miguel Castro, Gerald Cermak, Ronnie Chaiken, John R. Douceur, Jon Howell, Jacob R. Lorch, Marvin Theimer, Roger P. Wattenhofer.
FARSITE: Federated, Available, and Reliable Storage for an
52
Incompletely Trusted Environment.
In Proceedings of the 5th Symposium on
Operating Systems Design and Implementation (OSD12002), December 2002. [9] Marc Waldman, Aviel D. Rubin and Lorrie Faith Cranor. Publius: A robust, tamperevident, censorship-resistant web publishing system.
In Proceedings of the 9th
USENIX Security Symposium, pages 59-72. August 2000. [10] Adam Stubblefield and Dan S. Wallach. Dagster: Censorship-Resistant Publishing Without Replication.
Technical Report TR01-380, Computer Science, Rice
University, Texas, July 2001. [11] Adi Shamir. How to Share a Secret. Communication of the ACM, volume 22, pages 612-613. November 1979. [12] John R. Douceur.
The Sybil attack.
In Proceedings of the 1st International
Workshop on Peer-to-Peer Systems (IPTPS 02), pages 251-260. March 2002. [13] Marshall
Brain.
How
file
sharing
works,
April
2003.
Available
at
http://www.howstuffworks.com/file-sharing.htm. [14] Michael Stokes. Gnutella2 Specification Document, First Draft, 2003-03-26, April 2003. Available at http://www.kiwiuk.net/gnutella2_draft.htm. [15] Kazaa. Supernodes, April 2003. Available at http://www.kazaa.com/us/help/ faq/supernodes.htm. [16] Antony Rowstron and Peter Druschel. Pastry: Scalable, decentralized object location and routing for large-scale peer-to-peer systems. In Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms, pages 329–350. ACM Press, November 2001. [17] Antony Rowstron and Peter Druschel. Storage management and caching in PAST, A large-scale persistent peer-to-peer storage utility. In Proceedings of the 18th ACM Symposium on Operating Systems Principles, pages 188–201. ACM Press, October 2001. [18] Antony Rowstron and Peter Druschel. PAST: A large-scale, persistent peer-to-peer storage utility. In Proceedings of the 8th Workshop on Hot Topics in Operating Systems (HotOS-VIII), pages 75-80, Schloss Elmau, Germany, May 2001. [19] Dushyant Bansal and Paul A.S. Ward. Reducing Bandwidth Utilization in Peer-toPeer Networks.
Technical report 2002-17, Shoshin Distributed Systems Group,
53
Department of Electrical and Computer Engineering, University of Waterloo, December 2002. [20] Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard M. Karp, and Scott Schenker. A scalable content-addressable network. In Proceedings of the ACM SIGCOMM Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication (SIGCOMM 2001), pages 161–172, New York, August 2001. ACM Press. [21] Frank Dabek, M. Frans Kaashoek, David Karger and Robert Morris and Ion Stoica. Wide-area cooperative storage with CFS.
In the Proceedings of the 18th ACM
Symposium on Operating Systems Principles (SOSP ' 01), pages 202-215. October 2001. [22] Bernard Traversat, Mohamed Abdelaziz, Mike Duigou, Jean-Christophe Hugly, Eric Pouyoul, and Bill Yeager. Project jxta virtual network, February 2002. Available at http://www.jxta.org/docs/JXTAprotocols.pdf.
54
