# Behavioural Verification: Preventing Report Fraud in Decentralized Advert Distribution Systems
## 5 Detailed System Analysis
### Protocol Description
#### 5.3.3 Ad Report Submission Sub-Protocol  
The Advert Collection sub-protocol that is depicted in Figure 12 is used for the delivery of Advert Reports by the user to the Broker.  
1. The user gradually composes his or her reports into an \(ARC\) as he or she is interacting with adverts. The contents of the \(ARC\) are encrypted with the Broker's public key \(B_{PuK}\) except for the first block that contains the \(ARC\)-\(ID\) and the sequence number \(N\) and hash digest \(h(N-1)\) in all remaining blocks. When the \(ARC\) is ready for submission, the user produces an Integrity Hash \(IH\) by computing \(h(ARC)\) and signing the result with the signing key \(sk\) which were delivered to him with the sub-protocol described in Section 5.3.1.
2. The \(ARC\) and \(IH\) are sent to one of the Ad-Dealers either directly or via a Commissioner.
3. The Ad-Dealer keeps a local copy of the \(ARC\) and \(IH\).
4. The Ad-Dealer submits the \(ARC\) and \(IH\) to the Broker.
5. The Broker first decrypts the \(ARC\) with his private key \(B_{PrK}\) and verifies the authenticity of the \(IH\) with the matching verification key \(vk\). The Broker then verifies the integrity of the \(ARC\) by replicating the results of the hashes \(h(N-1)\) in the individual blocks as well as the digest of \(h(ARC)\) that is found in the \(IH\). When verification has been completed successfully the Broker uploads the \(ARC\) and \(IH\) onto the \(SC\)-_Board_ in plaintext form. Finally, the Broker verifies the validity of the Checkpoint Blocks \(CBs\) and Affiliation Blocks \(ABs\) and Marks them on the \(SC\)-_Board_. The \(CBs\) are validated by checking the authenticity of the Ad-Dealers signature with a public key which is used only for this application. The \(ABs\) are validated by checking the signature (which exploits the \(sk^{\prime}\) of the second user who participated in the meeting) and by cross referencing the dates in both the \(ARCs\) (if the other \(ARC\) has already been submitted).
6. When the \(ARC\) and \(IH\) have been uploaded to the \(SC\)-_Board_, the Broker notifies the **submitting** Ad-Dealer with a Check Message.
7. The submitting Ad-Dealer verifies the hashes in the uploaded \(ARC\) and \(IH\) by comparing them to his own copy (recall that the hashes were not originally encrypted). The submitting Ad-Dealer then confirm the correctness of the \(ARC\) by placing his name and signature in the third field of the \(SC\)-_Board_.
8. The Broken notifies the Advertisers for the new entry in the \(SC\)-_Board_.
9. The Advertisers begin to reward the Publishers and Ad-Dealers and each reward report of the \(ARC\) is marked on the \(SC\)-_Board_ by the appropriate Advertiser. Each Advertiser is responsible for individually determining the honesty of the user who submitted the \(ARC\) by assessing the embedded authentication credentials which have been marked (\(CBs\), \(ABs\), \(RoCs\) and \(RoAs\)). The \(RoCs\) and \(RoAs\) are validated and marked on the \(SC\)-_Board_ by the respective Advertisers after conforming the contained \(C\)-_Tokens_ and \(A\)-_Tokens_. Depending on the number and significance of credentials in the \(ARC\), the Advertisers may choose to award a report or wait for more credentials to be marked on the \(SC\)-_Board_ (more awarded \(RoCs\) and \(RoAs\) by other Advertisers and more confirmed \(ABs\)).
10. After a certain time has passed from the submission of the \(ARC\), the user's mobile client checks the \(SC\)-_Board_ in order to determine that his or her report has been registered. If the matching \(ARC\)-\(ID\) is present within the \(SC\)-_Board_, the user may discard his or her original copy of the \(ARC\) and \(IH\) or else resubmits them. Recall that the only part of the \(SC\)-_Board_ which is visible to the user is the \(ARC\)-\(ID\) while the rest is kept private among the remaining stakeholders.