# Rentable CDN Using Blockchain and Proof of Provenance
## 4 Analysis
### Security Analysis for the Proposed Method  
In rentable CDN, Uploader should not be able to reuse a proof of piece that has been claimed already, and Downloader should not be allowed to redirect payment for a legitimate Uploader to themselves or Uploaders that they are colluding with. The former is called \"replay attack\" and the latter is called \"collusion attack\". The proposed method is secure against replay attacks using proof of pieces, and various collusion attacks.  
Suppose a malicious Uploader wants to replay a previously used proof of piece to get paid again. Consider the following possible replay attack scenarios:  
1. _Proof of piece to be replayed was already used by another Uploader_: it cannot be replayed because the proof of piece contains \"Uploader's address\" and \"Downloader's signature\". The malicious Uploader cannot replace existing Uploader's address with their own address since the signature will not match with the signed data.
2. _Proof of piece to be replayed was already used by themselves_: it cannot be replayed because the proof of piece contains \"Content delivery contract ID\", \"Downloader's signature\". \"Content delivery contract ID\" ensures that the proof of piece is only valid for this current contract and cannot be replayed for a different contract. Also, replaying the piece again does not increase the payment unless \"Total # of new pieces\", and \"Total # of duplicate pieces\" are modified, but this is not possible since Downloader's signature will not match the modified data.  
Suppose a malicious user want to collude to get paid for the service they did not provide. Consider the following collusion attack scenarios:  
1. _Malicious Downloader colludes with fake Uploaders_: Suppose a malicious Downloader creates fake Uploaders and claim that content is downloaded from them. Under the proposed scheme, fake Uploaders are not paid without the correct proof of provenance, and malicious Downloader will not be able to become an Uploader for the content if they send a proof of piece with false proof of provenance. Furthermore, Downloader must send correct proof of piece to the honest Uploaders, otherwise, Uploaders will not send additional pieces beyond the first piece.
2. _Malicious Downloader colludes with other Uploaders_: Suppose a malicious Downloader claim that content has been downloaded from the colluders. Under the proposed fee structure, Downloader does not gain from this because honest Uploaders still need to be paid. If anything, their loss will grow as additional verification and network maintenance fees have to be paid for the proof of pieces submitted by the colluders.  
Figure 9: Download speed comparison between the proposed and Theta network when malicious peers (300 and 600) overtake the network. (**a**) 50 honest Uploaders and 300 malicious Uploaders; (**b**) 50 honest Uploaders and 600 malicious Uploaders.  
_Malicious Uploader:_ In this scenario, a malicious Uploader tries to gain a legitimate proof of piece from Downloader without sending a piece of the content. Unlike the Theta network where the payment is given before Uploader sends a piece of the content, the proposed method only sends the proof of piece if a piece is delivered. In other words, malicious Uploaders cannot gain from colluding.  
The combination of proof of piece, proof of provenance, and fee structure which penalizes malicious activities, offers protections against replay attacks using proof of piece and collusion attacks.