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.
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)
Rivest et. al. Ron L. Rivest and Adi Shamir and Leonard M.
Adleman A Method for Obtaining Digital Signatures and Public-Key
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.