# A Security-Enhanced Query Result Verification Scheme for Outsourced Data in Location-Based Services
## 4 Proposed Scheme
### Data Outsourcing Process
#### 4.2.3 Design of the Lookup Table  
After the above settings, the encrypted retrieval index set (i.e., \(prf_{k}(W)\)), the encrypted query result set containing keywords (i.e., \(C(DS)_{w\in W}\)), the verification object set of fog nodes (i.e., \(VO_{G}\)), and the description file verification object set corresponding to the encrypted query result set (i.e., \(VO_{W}\)) are obtained. Based on the above-encrypted data, the LBSP can outsource these data to a third party (i.e., the fog side). However, how to use the user's encrypted query index to obtain the corresponding query result and the verification objects without leaking any useful information to the third party is an important problem that needs to be solved.  
Figure 5: The structure of the verification object in our scheme.  
**Problem statement**. To overcome the disclosure of query privacy, it is common to use the user's encrypted query index to support the secure query over the outsourced data. Although this way can prevent the third party from obtaining the plaintext information of the user's query index (e.g., the plaintext information about the query keyword \(w\) in our scheme), it still exposes important information, such as the frequency or rarity of requests for outsourced data corresponding to the user's encrypted query index, and accurate statistical information on the frequency of all encrypted outsourced data requested. Upon the above-exposed information, the third party may carry out some dishonest behaviors, such as deleting the outsourced data that are rarely requested or inferring the meaning of the encrypted query index (e.g., \(prf_{k}(w)\) in our scheme).  
**Improved storage structure of the outsourced data.** In brief, the reason that a third party can obtain the exposed information is that the relationship between the encrypted query index and the corresponding query objects is designed to be one-to-one in the storage structure. Therefore, to prevent the third party from implementing the inference attack based on the above one-to-one correspondence, our scheme designs the one-to-n lookup table as the storage structure of the outsourced data to disturb the corresponding relationship between the encrypted query index and the corresponding query objects. For example, Table 3 shows the improved storage structure with the one-to-two correspondence (i.e., the one-to-two lookup table). By using this storage structure, the relationship between the encrypted query index (i.e., \(prf_{k}(w)\)) and the corresponding query objects (e.g., \(VO_{w}\)) stored in the fog node can achieve the goal of one-to-two. Note that each fog node only owns the encrypted outsourced data within its Voronoi cell (i.e., the LBSP outsources the lookup table \(T(g)\) that contains the ciphertext data to the corresponding fog node). In the lookup Table 3, \(a\) and \(b\) are two random numbers, where \(1\leq a\leq\theta\) and \(1\leq b\leq s\). If \(i+a>\theta\), then \(i+a=(i+a)\ mod\ \theta\). If \(i+b>s\), then \(i+b=(i+b)\ mod\ s\). Moreover, \(ID\) is the identifier set of data items and each \(id\) indicates the identifier of a data item. \(c(\Lambda)\) is the encrypted set of the number of genuine description files and each \(c(\lambda_{w\in\text{W}})\) denotes the encrypted number of genuine description files corresponding to the set of encrypted description files (i.e.,\(c(ds)_{w\in\text{W}}\)), where \(\lambda_{w\in\text{W}}\) indicates the number of genuine description files and it is obtained by encrypting the genuine number with \(AES\). Based on the improved storage structure, the next subsection will show how to remedy the proposed problems with our scheme.  
\begin{table}
\begin{tabular}{c c c c c c c} \hline \(T(G)\) & \(ID\) & \(prf_{k}(W)\) & \(C