JOIN
Get Time
features   

Peer 2 Fear: Solutions for developers for designing secure P2P applications
Monday, October 4, 2004

By AryanI
TopCoder Member

Introduction
Securing P2P data sharing applications is challenging due to their open and autonomous nature. Compared to a client-server system in which servers can be relied upon or trusted to always follow protocols, peers in a P2P system may provide no such guarantee. The environment in which a peer must function is a hostile one in which any peer is welcome to join the network; these peers cannot necessarily be trusted to route queries or respond correctly, store documents when asked to, or serve documents when requested.

Peer to peer networking is not specifically a new technology but rather a different model for deploying existing technologies. In terms of implementation, it is still basically client/server, except that every machine runs as both a client and a server. Although Napster, Gnutella and Freenet are often mentioned together, each actually functions quite differently from the others. Napster serves as a broker to a centralized address server; Gnutella makes its connections directly while relying on static IP addresses and Freenet is completely dynamic. All of them turn the Net into a giant, distributed hard drive.

Some of the biggest dangers from peer-to-peer networks stem from their 'always connected' status (read 'always vulnerable') and the fact that one is now running servers on machines that are managed by end users -- and the fact that these end users don't know how to securely manage a server.

Napster's reliance on a centralized directory may make it especially vulnerable. Because of the directory server, Napster is closer than most other peer-to-peer models to a hybrid of client/server and P2P. The server(s) that host the directory could become a particular target for intruders -- and copyright lawyers.

Other problems lie not with the technical structure of peer-to-peer networks but in what's being sent across them.

Our trust in a source may be based on digital signatures, but if the key is stored on a disk and not a smart card, that key is vulnerable, regardless of anyone's claim of non-reputability. Worse, even if the key is stored on a smart card, a virus can change the message so that what is being signed is not what the digital signature thought it was signing.

Spyware programs are also a huge problem in the P2P community. A Spyware is a program that is usually distributed along with the P2P client and which sends out personal user information.

Viruses of course are another potential threat for the P2P community. P2P systems are just another medium over which viruses can spread efficiently, although it is estimated that they are not as dangerous as viruses that are spread over the email.

Finally, poorly written P2P Clients are another problem in these networks, since they expose their users to all the security flaws of the particular P2P client. For example, the actual transfer of files in Gnutella is done with the HTTP protocol. This means that each Gnutella Client instantiates a "mini" web-server that is capable of serving other Gnutella Clients after their query was performed over the Gnutella network. These "mini" web-servers are sometimes poorly written making them vulnerable to attacks.

P2P has been applied on the landscape of Internet and has to face millions of anonymous users. On the other hand, P2P software is getting more powerful and sophisticated. For instance, some applications grant users the power to limit other user's bandwidth amount while uploading files. But still there are a lot of security risks that are required to be addressed. The common security flaws that I found in

P2P networks in general are related to Denial of Service, Traceability, Leakage, User Interface, Security holes, Privacy, Worms and Viruses, and Architecture.

The main aim of writing this article is to suggest some possible solutions and security guidelines, which are the outcome of my research analysis regarding designing and implementing secure P2P applications, to the developer community.

I am not describing the possible attacks in P2P networks, but just to mention them the most common are Denial of Service, malicious node, self-replication, pseudospoofing, shilling, ping flooding, SYN flooding, attacks on P2P nodes, attacks on routing like incorrect lookup routing attack, incorrect routing updates attack, partitioning attack, semantic attacks like storage and retrieval and face-off and attacks related to file availability, authenticity and integrity.

In the table given below I have listed some of the various possible solutions for different inherent problems in P2P networks.

Solutions Node failure File integrity File authenticity Man in middle
Can Y      
Chord Y      
Pastry Y      
Viceroy Y      
Cyclic redundancy checks   Y    
Hashing   Y    
MACs   Y    
Digital signatures   Y Y  
Trutella       Y

Can, Chord, Pastry and Viceroy provide significant levels of fault tolerance in the face of node failure. Digital signature schemes are limited by the lifetime and security of public/private keys.

Intel® proposes Trutella, a solution to Man in the Middle attack. Here, a malicious node answers all incoming requests for information with "Yes, I've got that" and then floods the poor requester with garbage, in essence creating a denial-of-service attack.

Intel® solution "Trutella," is a combination of Gnutella and hardware that conforms to the Trusted Computing Platform Alliance (TCPA) for encryption. TCPA -- originally formed by Compaq, HP, IBM, Intel® and Microsoft -- now has over 145 companies as participating members, including Broadcom and Philips Semiconductors. The group has dedicated itself to developing a specification for a trusted computing platform.

One approach is to use a Peer-to-Peer Trusted Library that allows software developers to add the element of 'trust' to their peer-to-peer applications. It provides support for digital certificates, peer authentication, secure storage, public key encryption, digital signatures, digital envelopes, and symmetric key encryption. The library also provides simple support for networking and some operating system primitives, such as threads and locks. Applications built with the library are portable to both Win32 and Linux.

After analyzing various P2P security models, I have come up with some of the security guidelines that could form the basis for designing robust P2P networks in future.

  1. In the future, P2P protocols need to be designed to make it hard for adversaries to construct DoS attacks by taking advantage of loosely constrained protocol features.
  2. It is important to design future P2P protocols such that they do not open up new opportunities for attackers to use as amplifiers and back-door communication channels.
  3. One approach to deal, with the attack that effect the availability of any of the particular resources at a node, is to allocate storage to nodes in a manner proportional to the resources that a node contributes to the network.
  4. Techniques such as hash trees could to be used by the client to incrementally ensure that the server is sending the correct data, and that data is sent at a reasonable rate.
  5. To protect against Man in the Middle attack, one way to defeat attacker is for nodes to authenticate other nodes. This can be achieved by obtaining a node's public key through a secure channel (e.g., a trusted party such as certificate vendor, or through a web of trust like PGP) and validating their fingerprints.
  6. Make firewalls smarter so that peer-to-peer applications can cooperate with the firewall to allow traffic the administrator wants. Firewalls must become more sophisticated, allowing systems behind the firewall to ask permission to run a particular peer-to-peer application.
  7. One problem is the lack of accountability in the Internet architecture. Because any host can connect to any other host, and because connections are nearly anonymous, people can insert Spam into the network at any point. The lesson for peer-to-peer designers is that without accountability in a network, it is difficult to enforce rules of social responsibility.
  8. Use security toolbox like JXTA. Project JXTA has security API's and a library that has implements RSA, RC4, MD5, SHA-1, a psuedo-random number generator, MAC, and digital signatures. There are plans to add more ciphers, and Diffey-Hellman. The default key strength is 512 bits for RSA, and 128 bits for RC4. These are there to fulfill U. S. export requirements for open source. The above toolkit is sufficient to begin the P2P implementation.
Finally the above security guidelines and proposed solutions are followed by some research issues that developer community in future have to address:
  1. Some research has been done in particular to address DoS attacks based on query-floods in the Gnutella network. However, more research is necessary to understand the effects of other types of DoS attacks in various P2P networks.
  2. Research is required to develop techniques to deal with fail-stop and byzantine failures that are acceptable from a performance and security standpoint in a P2P context.
  3. Research is required to explore a broad range of fundamental P2P issues such as: peer-node identity, naming, configuration and capabilities; P2P network organization and scope; resource discovery, content lookup, search and distribution; request routing and operation in the presence of mobility; adaptation to expected peer-node instability; monitoring of P2P operations; security of P2P systems involving reputation-based trust for ad-hoc systems or more centralized, CA-like approaches; etc.
  4. In current P2P models the users are unaware of the information about the end users or consumers who has the file to share. On some systems, like Gnutella, this is discoverable; on others, like Freenet, anonymity is designed in. But in order to identify trusted sources one has to have the knowledge about the sources. One solution can be based on ratings of different sources based on trust parameters. Even that solution brings problems. The information must be stored somewhere. In a P2P system built on the Napster model that would be in a central directory -- once again creating a prime target for a malicious hack. Another answer might be a "source arbitrator," which would inform the peer's computer about both the identity of the source and its trustworthiness but not reveal it to the user -- at least not easily.
Since the data does exist somewhere within the peer's computer, odds are whatever programs the programmers use to test the viability of the trust model would be able to screen for this data.

So the problem of identifying the trust of nodes in P2P networks is still an open research problem.

I have developed four different P2P applications using RMI, JXTA, JMS and Web Services. And I found as the technology is maturing, the security features are increasing but still the increasing complexity and dynamism brings more security issues on the platform. I think it is like a loop in which you must be ahead of the security threats following you from behind.

The further information about security issues in P2P networks can be found at below online resources:


Would you like to write a feature?