# Private and Secure Distribution of Targeted Advertisements to Mobile Phones
## 6 Evaluation
### Protection from Impersonation Attacks  
A malicious user can launch an attack against the system by impersonating the identity of a legitimate system stakeholder, either a user or an Ad-Dealer. The four possible scenarios that may accrue from such an attack are the following.  
* Victim is a user and the Attacker impersonates one of his/her Contacts (that is not an Agent or a Requester).
* Victim is a Requester and the Attacker impersonates his/her Agent
* Victim is an Agent and the Attacker impersonates his/her Requester
* Victim is an Agent and the Attacker impersonates the Ad-Dealer  
In the first scenario, the attacker tricks a user U1 into registering a fake encounter with one of his/her Contacts U2. This would alter the Encounter Average \(EA_{(UI1,UI2)}\) of the two users and in turn interfere with the correct operation of the opportunistic routing algorithm.  
In the scenario where the attacker impersonates an Agent there are two cases. In the first case, the victim is a potential Requester, i.e., a user who has not yet made a request, who is manipulated into sending ARMs to the attacker. The attacker would still be unable to read the encrypted ARMs, but this would also result in the requests being lost. In the second case, the victim is already a Requester, i.e., the victim has placed a request and is waiting for ads. If this happens, the Requester may be tricked into downloading data, such as fake ADMs and Bundles, that have not been sent by a legitimate Ad-Dealer.  
In the third scenario, the attacker impersonates the Requester, after the request has been made, to an Agent who is tricked into sending to the attacker the adverts (ADMs and Bundles) that are meant for the real Requester. After completing the delivery, the Agent (victim) will have no reason to keep the ADMs, which will be discarded. This will result in a denial of service for the real Requester, who will not be able to obtain his/her adverts when the actual meeting between him and the Agent takes place.  
These first three scenarios are prevented with the use of password-based mutual authentication. The authentication protocol uses a standard challenge-response handshake that is assumed to be secure as long as the passwords are not leaked. The original exchange of passwords happens through an out-of-band channel (e.g., manual input, QR code, text) which is very difficult for an attacker to eavesdrop on. Although the passwords are generated automatically by a random function within the client, we assume that they cannot be guessed by an attacker, as the function may include several sources of randomness from the user's device, such as memory usage, time or signal strength.  
For our final scenario, the attacker impersonates the identity of an Ad-Dealer. Nearby Agents would be deceived into sending to the attacker their ARMs. The ARMs are encrypted and the attacker would not be able to use them, nor would he/she be able to send back any malicious content. However, the ARMs could potentially be lost, which would result in failure to deliver on behalf of the Agent. Agents avoid this attack by authenticating the Ad-Dealer with the use of digital signatures. The Agent sends a random nonce that the Ad-Dealer is asked to encrypt with the \(K_{sign}\) and can be verified with the \(K_{auth}\). We need to note that this creates a threat for the Ad-Dealer being tricked into signing something else other than a user's nonce. However, this would serve no purpose since the Ad-Dealer's signature is used only for this operation.