# Behavioural Verification: Preventing Report Fraud in Decentralized Advert Distribution Systems
## 6 Evaluation
### Report Integrity  
After an \(ARC\) leaves the user's device, it has to go through a Commissioner, an Ad-Dealer and the Broker before finally being posted on the _SC-Board_ (Service Confirmation Board). This makes it possible for any of the intermediaries to commit fraud by altering the content of an \(ARC\). This type of fraud would be particularly difficult to detect due to the fact that a legitimate \(ARC\) (one created by a real user) is likely to have valid _Tokens_. Our system prevents this attack through the employment of hash functions and verification checks. To demonstrate the operation of the integrity mechanism, we will consider two attack scenarios.  
Attack scenario 1:  
The Commissioner and the submitting Ad-Dealer attempt to alter the content of a legitimate \(ARC\) in order to trick the Broker and Advertisers into rewarding a malicious Publisher for a publication that did not take place. Recall that the \(ARC\) follows the architecture of a blockchain where the first block holds a unique \(ARC\)-\(ID\) and each following block includes the hash digest of the previous. Additionally, the user also sends an \(IH\) (Integrity Hash) that contains the hash digest of the entire \(ARC\) which has been signed with a verification key \(vk\).  
Since the content of the Ad-Reports is encrypted with the Broker's public key \(B_{PuK}\), it would be possible for a malicious Commissioner or Ad-Dealer to create a fictitious Ad-Report of his own. However, if the fictitious Ad-Report were to be inserted into the \(ARC\) (either as a new block or by replacing an existing one), this would result in a mismatch of both the hash digests within \(ARC\)'s blocks as well as the hash digest that is included in the \(IH\). The attacker would be able to change the hashes in the \(ARC\) but cannot change the hash in the \(IH\) without knowing the user's verification key \(vk\) which was delivered to the user within the \(RF\) (Report Form). The \(RF\) was encrypted with a key that the user selected himself and only shared with the Broker via his public key \(B_{PuK}\). This makes it impossible for an attacker to alter the content of \(IH\) without being exposed.  
Attack scenario 2:  
The Broker attempts to alter the content of a legitimate \(ARC\) in order to cheat a Publisher out of a reward. Although the Broker can be considered trustworthy as the representative of Advertisers, our system allows the Ad-Dealers and Publishers to verify that there has been no tampering of the Ad-Reports.  
Recall that Ad-Reports are encrypted with the Broker's public key \(B_{PuK}\) and are shared on the _SC-Board_ (Service Confirmation Board) after they have been decrypted. The Broker could therefore attempt to cheat the Ad-Dealers and Publishers by altering the Ad-Reports of a submitted \(ARC\) before uploading it to the _SC-Board_. To prevent this attack, the submitting Ad-Dealer holds a copy of the \(ARC\) before forwarding it to the Broker. Although certain parts of the \(ARC\) are encrypted with Broker's public key \(B_{PuK}\), the hash digests are transferred in plaintext. This allows the submitting Ad-Dealer to replicate the hash functions on the posted \(ARC\) in order to verify that decryption has been completed correctly. The submitting Ad-Dealer then marks the verification check \(VC\)-\(S\) in the _SC-Board_ which informs the Publishers and remaining Ad-Dealers that the submitted \(ARC\) is valid.