Escrow Services and Incentives in Peer-to-Peer Networks
   Summary by Cristina Abad
   =========================================================
   
   This paper proposes a system architecture that uses economic incentives 
instead of tamper resistance to motivate users of a peer-to-peer content 
distribution network to keep the content within the subscription community. The 
solution they suggest involves a trusted third party called escrow server.
   
   Motivation: Subscription-based services are currently being considered by the 
industry as a viable business model for P2P content distribution. But, such 
services may suffer from users that choose to redistribute content outside the 
community of subscribers and from illegal or low quality content. Digital Rights 
Management (DRM) systems have been proposed to control piracy. Until that 
alternative is viable, the authors suggest using economic incentives to motivate 
the users to "play by the rules". Another issue they consider is breakdown of 
trust.
   
   Problems with P2P file sharing systems: Spam (sharing files that do not match 
their description), free riding (downloading without serving content), black 
markets (illegitimate P2P networks), content certification (policies of 
providing file sharing for only a restricted class of files). The proposed 
method provides a solution for the first three issues.
   
   Characteristics of the Escrow Server: The operation of the trusted party is 
very simple:
   ·	The escrow server does not require direct online interaction with the 
party serving the content
   ·	The escrow server is not required to receive the entire content from the 
recipient
   ·	If desired, the content can be kept secret from the escrow server
   ·	The escrow server does not need to keep a database of content files that 
it supports (its operation can be completely stateless)
   
   Cryptographic primitives: The parties agree on the following: a symmetric 
encryption scheme, a collision resistant hash function, and availability of 
secure and authenticated channels between any two parties. Note: for non-
interactive secure communication between parties, the encryption can be done 
using public key cryptography or symmetric keys (shared between ES and each of 
the parties).
   
   The Basic Scheme: S: serves content C; R: recipient of content C; ES: escrow 
server. S encrypts C with a key K and sends the encryption Ek(C) to R. R obtains 
the decryption key K from the escrow server ES. ES requires the correct hash of 
the encrypted content, H(Ek(C)), and the key K that decrypts the content (they 
could have been sent to ES by S in a preprocessing stage). ES might have also 
asked to receive the content C itself and verify that C agrees with its 
description and that H(Ek(C)) is the required value. The steps required are:
   1)	S encrypts C using a randomly chosen key K
   2)	S sends Ek(C) to R
   3)	R computes H(Ek(C)) and sends it to ES together with a description of the 
content C it desires to obtain, and the identity of S. It also sends a payment 
for C.
   4)	ES compares the hash received from R with the hash it stores. It also 
checks if C is what R wants. If both tests are passed, R's payment is processed 
and if the payment is valid, ES sends K to R.
   If the two hash values and the hash values are not equal, the operation is 
cancelled. It may be desired to enable the system to decide who is to blame. In 
that case, it is required that the message from S to R is signed.
   
   An example scenario: The basic scheme can be adapted to many different 
scenarios in which files are shared, such as:
   Large content providers (e.g. music labels): providers distribute their 
content through a network of small peers (the peers serve the content for a 
fee). Providers may have a continuing relationship with ES, or even each content 
provider can operate an ES to handle distribution of its own content. Sharing 
parties need not know the plaintext version of the content.
   
   Indirect communication from S to ES: Method that frees ES from keeping a 
database of the hash values of the content being served by S and from the 
preprocessing communication with S.
   1)	S know the public key PK of ES
   2)	S sends to R Ek(C) and EPK(H(Ek(C)),K)
   3)	R forwards to ES H(Ek(C)) and EPK(H(Ek(C)),K)
   4)	ES decrypts the second part and proceeds as in the basic protocol
   
   Another scheme in which ES is able to ensure the quality of Ek(C) before R's 
payment is processed is also described in the paper.
   
   Problem: The fact that there is a single encrypted copy of the content can 
lead to:
   ·	Leaking of the decryption key
   ·	Fooling ES into paying a different S
   Solution:  Encrypt C with a different key each time it is sent to a different 
recipient and use error correcting codes to enable ES to check the hash values 
of different encryptions by checking a fixed set of values and without having to 
decrypt each encryption.
   
   Orthogonality to search method: The escrow systems proposed are not linked to 
a particular method of file sharing among the peers (centralized directory 
service, distributed directory service or distributed file storage).
   
   
   PROS & CONS by Kevin Cernekee & Suvda Myagma
   =========================================================
   
   PROS
   ----------------
    - presents a good solution to the spam/certification problem PTP
    - gives users a profit motive not to freeload
    - gives content owners a cheaper way to buy bandwidth
    - may be necessary to start paying users to serve when transfer caps or 
surcharges become commonplace
    - server doesn't need the entire content for verification
    - server doesn't need to keep a large database of hash values of encrypted 
contents
    - sender is able to keep the content secret to the ES
   
   CONS
   ----------------
    - centralized control makes it unsuitable for deployment in kazaa, other 
illegal PTP networks
    - a lack of a trusted source of original rips also makes it unsuitable for 
pirate PTP networks
    - online distribution doesn't appeal to content holders because popular 
songs subsidize crappy songs on most current music
    - default settings, not economics, are the current incentives to be a server 
in pirate PTP networks
    - doesn't guarantee that licensed content won't be distributed illegally, 
although the authors claim otherwise
    - this doesn't seem to be a better solution than Digital Rights Management
    - authors claim that ES can ensure that the receiver is getting a good 
quality content. But this is not possible to enforce since ES doesn't know much 
about the content
    - since ES doesn't require the entire content to verify, it seems impossible 
to check whether the content matches its description
    - in the basic sceme, the decryption key K is sent in plain from the sender 
to the ES, introducing a point of malicious attack
   
   
   VOTES
   =========================================================
   Strong Reject: 4
   Weak Reject: 8
   Weak Accept: 5
   Strong Accept: 0