Department of Electronic & Computer Engineering 
Intelligent Systems Laboratory                           Pdi2etP TECHNICAL UNIVERSITY OF CRETE 

 

border graphic Main Menu border graphic
border graphic border graphic border graphic border graphic border graphic
 
- Description
- People
- Courses
- Research
- Publications
- Dissertation Topics
- Events
- Funding
- Contact
 
border graphic   border graphic

 
 
border graphic P2P-DIET Menu border graphic
border graphic border graphic border graphic border graphic border graphic
 
- General
- Architecture                 - Routing                        - Security                      - Alert Features              - Super-peer Environment - Client-peer Environment
- Screenshots
- Setup instructions
- Download
- Related Work
 
 
 

 Security

P2P-DIET clients may use dynamic IP addresses. This is expected in today's Internet given the limitations of address space in IPv4. Thus, we need another way to identify clients since we cannot use their IP address for this purpose. Any method used to identify nodes in open environments such as the current P2P systems should also take into account the possibility that some peers might be malicious. A malicious peer will try to identify itself as another peer, or eavesdrop on communications and take advantage of them in various ways. Secure identification in P2P-DIET is done using unique identifiers in the spirit of [Hauswirth et. al.]. Additionally, P2P-DIET provides message authentication and message encryption using PGP technology based on algorithms presented in [Rivest et. al.]. For details on the protocols see [Idreos and Koubarakis, 2003].

When a new client wants to register to the P2P-DIET network, it creates a unique identifier by applying a cryptographically secure hash function, SHA-1 to the concatenated values of current date and time, the IP address of the access point, the current IP address of the client and a very large random number. The properties of the cryptographically secure hash function now guarantee that it is highly unlikely that a peer with exactly the same identifier will enter the network. In addition to generating an identifier, each peer x generates a pair of keys (Ex,Dx) where Ex is the public key of x (or the encryption key) and Dx is the private key of x (or the decryption key). We assume that the client will already have an IP and public key for one of the super-peers so it securely identifies the super-peer (Secure identification is described in the following paragraphs} and sends an encrypted (Encryption is described in the following paragraphs) message to the access point. The message contains the public key, the identifier and the IP address of the client. The only security ``gap" in these scenarios is the case someone that attacks and changes the web page. In this way the new clients will get false IP addresses and public keys for super-peers and will not be able to connect to the real super-peers of the system. We assume that this problem will be solved by the administration of the system that will monitor the web page.

After registration, each message that a client sends, either to a super-peer or to another client, contains the identifier of the client. In this way, the receiver always knows who ``is supposed" to have sent the message and it can proceed to authenticate the message using a PGP like cryptographic feature in the following way [Rivest et. al.]. Let us assume that client A wants to send a message M to a super-peer SP. It creates the signature S=DA(M) of M using its private key and sends S to SP. Then, SP uses its knowledge of the public key of the sender and obtains M from M=EA(S).

In P2P-DIET, authentication is used in all messages from super-peer to client, client to super-peer and super-peer to super-peer. In case that a signed message has not been properly signed (the public key that matches the identifier of the sender cannot decrypt the signature) then the message is ignored by the receiver (in this case, we might have a malicious sender ``masquaraded" as some other peer).


When a client disconnects, its access point does not erase the public key or identifier of the client; it only erases the client identifier from the active client list. Later on, when the client reconnects, it will identify itself using its identifier and it will send to its access point its new IP address. In case that the client migrates to a different access point, it will notify the previous one so that this access point erases all information about the client. Then, it securely identifies the super-peer and sends an encrypted message to the access point. The message contains the public key, the identifier and the IP address of the client.


In P2P-DIET, there is only one case that a super-peer starts a communication session with a client-peer and does not wait for a reply, so it cannot be sure that the client-peer is on this IP address. This is when a super-peer wants to deliver a notification to a client. In all other cases, a client peer starts the communication session and identifies itself with a signed message or the client replies to a message of a super-peer with a signed message. As presented in [hauswirth-handling], a peer A can securely identify another peer B by generating a random number r and send EB(r) to B. Peer B sends a reply message that contains the number DB(EB(r)). Then, peer A checks if DB(EB(r)) = r in which case peer B is correctly identified. In P2P-DIET, a super-peer uses the above procedure to securely identify a client before sending a notification.

Until now, we have discussed how we can sign messages and how we can securely identify another peer. In this paragraph we show how using the ideas in [RiShAd78] we can use encryption for added security. A peer A can encrypt a message M and send it to peer B in the following way. Peer A creates the signature S=DB(M). Then, A encrypts S using the public key of the receiver Se=EB(S) and sends Se to B. Peer B decrypts the signed message using its private key S=DB(Se) and finally obtains M from M=EA(S).

Encryption is not a default feature in P2P-DIET; by default all messages are signed but not encrypted. This is a design decision that allows a user to avoid the time required to encrypt/decrypt a message, which slows down communication. If a client-peer x wants its messages to be encrypted then x requests secure communication from its access point, and from there on all the messages from x or to x will be encrypted.
 

References:

  1. Hauswirth et. al. M. Hauswirth and A. Datta and K. Aberer. Handling Identity in Peer-to-Peer Systems  "Technical report, Laboratoire de Systemes d'Information Repartis (LSIR), Ecole Polytechnique Federale de Lausanne (EPFL)

  2. Rivest et. al. Ron L. Rivest and Adi Shamir and Leonard M. Adleman A Method for Obtaining Digital Signatures and Public-Key Cryptosystems http://theory.lcs.mit.edu/~rivest/rsapaper.ps

  3. Idreos and Koubarakis, 2003  Idreos and M. Koubarakis. P2P-DIET: A Query and Notification Service Based on Mobile Agents for Rapid Implementation of P2P Applications. Technical Report, Intelligent Systems Laboratory, Dept. of Electronic and Computer Engineering, Technical University of Crete, June, 2003.

border graphic Services border graphic
border graphic border graphic border graphic border graphic border graphic
 
- Recent News
- Search
- Downloads
- Useful Links
- Web Mail (restricted)
- Users (restricted)
 
border graphic   border graphic
border graphic About border graphic
border graphic border graphic border graphic border graphic border graphic
 

- Technical Univ. of Crete
- ECE Department
 
border graphic   border graphic

2003 Intelligent Systems Laboratory, TUC