# Private and Secure Distribution of Targeted Advertisements to Mobile Phones
## 5 Detailed System Description
### User Meets Ad-Dealer
#### 5.4.2 Construction of Bundles and ADMs  
After authentication has been successful, the users may log their encounter with the Ad-Dealer and proceed to forward to him/her both the ARMs they constructed themselves, as well as those they received from their Requesters. The AD-Dealer then decrypts the ARMs with \(DK_{System}\) and fetches adverts for the requested interests. Depending on availability, each particular interests may be matched to one or multiple ads.  
Since the Requester's ARMs are selected after a profile comparison with the Agent, it is to be expected that both users may have multiple requests for the same ads. A significant amount of memory  
Figure 5: AD-Dealer authentication protocol.  
and bandwidth can therefore be conserved by distributing these adverts as a single copy that is addressed to both users. However, this would expose each other's interests and essentially defeat the purpose of performing a private profile comparison in the first place.  
Our system bypasses this problem by deploying a novel protocol that enables multiple users to share access to the same ads while preventing them from knowing which ads are being shared. Specifically, the Agent and the Requester are able to view the same encrypted ads, but neither of them can learn what ads are being viewed by the other.  
The Ad-Dealer initially encrypts each of the requested adverts with a different asymmetric encryption key \(EK_{i}^{AD}\) (Encryption Key of advert \(i\)) of his/her own choosing. The encrypted ads are then stamped with a unique AD-ID number, and they are organized into a sequence of groups that are called Bundles.  
The Bundles are composed in such a way that shared ads, i.e., ads that are addressed to multiple users, are mixed with ads that are addressed to the respective users individually. In our particular case, where we only have two users, the Agent and the Requester, a Bundle, which contains a shared ad \(AD_{(Agent,Requester)}\) (\(AD_{(A,R)}\) for short), also contains some ads that are addressed only to the Agent \((AD_{(A)}^{1},AD_{(A)}^{2})\), as well as some ads that are addressed only to the Requester \((AD_{(R)}^{1},AD_{(R)}^{2})\). Under no circumstances should we have a Bundle that contains only shared ads or a mix of shared ads and ads that are addressed to one of the users, but no ads that are addressed to the other user. The reasons for this become evident later on when we evaluate the privacy of the system.  
Once the Bundles have been composed, the Ad-Dealer creates Advert Delivery Messages (ADMs) for every one of the ARMs that he/she received. The ADMs are intended as responses to the ARMs and contain three pieces of information: (1) the AD-IDs of the adverts that relate to interest of a particular ARM, (2) the cryptographic keys \(DK_{i}^{AD}\) (Decryption Key of advert \(i\)) that can be used to decrypt them (the ads have been encrypted with the corresponding \(EK_{i}^{AD}\)) and (3) the sequence number of the Bundles in which the adverts are enclosed (note that multiple ads for a single interest may not necessarily be sent in the same Bundle).  
Recall that every ARM is labelled with a unique ARM-ID, and it contains a user-generated encryption key \(K_{i}^{user}\). Each respective ADM is therefore encrypted with the corresponding \(K_{i}^{user}\), and the resulting ciphertext is labelled with the matching ARM-ID before being sent to the Agent along with all the Bundles of encrypted adverts.  
\[ADM_{ARM-ID}=E_{K_{i}^{user}}\Big{[}AD-ID,DK_{i}^{AD},BUNDLE_{(n)}\Big{]} \tag{3}\]