## 4 ROLQ-TEE Scheme
### Detailed Construction
In the optimal location analysis phase, assuming that the TEE created by the \(\mathcal{DO}\) operates securely and correctly on the \(\mathcal{CSP}\), the location analysis process is executed within the TEE. The critical step involves comparing the customer identity of the mapping table \(MT\) with the customer list \(L\) to determine the corresponding encrypted location data. Subsequently, the TEE calculates the Euclidean distance between the intersected customer locations and the candidate facility locations to produce a ranking of the candidate facilities. Notably, the customer identity in the mapping table and the customer list are encrypted using a pseudo-random function \(F\). During the decryption phase, the \(\mathcal{DU}_{\mu}\) only obtains the ranking results \(\mathcal{C}_{res}\) of the candidate facility locations. Even if the \(\mathcal{DU}_{\mu}\) attempts to reverse-engineer the ranking results \(\mathcal{C}_{res}\) through extensive computation and combinatorial analysis, they can infer only the intersection data permitted by the scheme, but cannot deduce any additional location data stored by the \(\mathcal{DO}\) other than the intersection. Furthermore, due to the security of the pseudorandom function and the \(\mathcal{DU}_{\mu}\)'s inability to access the \(MT\), the \(\mathcal{DU}_{\mu}\) cannot obtain the identities of customers other than the intersection, nor can they access the corresponding location data. Additionally, the location data are encrypted using the AES-GCM algorithm. Without knowledge of the storage key \(sk_{\mathcal{DO}}\), the \(\mathcal{DU}_{\mu}\) is unable to infer any additional location data from the ciphertext. The security of the pseudorandom function and the AES-GCM encryption algorithm has been proven in [34,35], respectively, and will not be further elaborated on here. ## 6 Performance Evaluation

In this section, we analyze the computational complexity, communication overhead, query efficiency, and memory usage of the ROLQ-TEE scheme. ### Complexity Analysis

In this section, the performance and functions of these schemes are summarized in Table 2. Table 2 shows the computational cost of the optimal location query, the storage cost of all entities, and some functional characteristics. Yilmaz [9] implements a server-based query processing protocol and a client-based query processing protocol, respectively. Each protocol implements the following three most effective location analysis methods: cardinality query (RNNQ), average distance query (AVGQ), and maximum distance query (MAXQ). Similarly, our scheme also implements the above three query methods. However, the overall complexity of the three query methods of the ROLQ-TEE scheme on the server side is higher than that of the three query methods of the above scheme [9]. The reason is that the three query methods of the ROLQ-TEE scheme achieve stronger privacy protection than the above three query methods, so there are more encryption and decryption operations on the server side. Moreover, due to the introduction of TEE, the ROLQ-TEE scheme enables the cloud server provider \(\mathcal{CSP}\) to communicate less frequently with data owners \(\mathcal{DO}\) (or \(\mathcal{DU}_{\mu}\)), thereby reducing the communication complexity of clients such as \(\mathcal{DO}\) or \(\mathcal{DU}_{\mu}\). If the encryption and decryption operation are not considered, the computational efficiency of the three query methods of the ROLQ-TEE scheme is far better than the above three query methods. This is mainly because the ROLQ-TEE scheme only processes the plaintext data in the \(U_{I}\) in TEE, not all the ciphertext data. Therefore, the computational overhead is less than that of ciphertext processing in reference [9]. Meanwhile, the query computation complexity on the user side is reduced to a constant level, such as 6E+4P+4H+3 Mu+Div, and our scheme reduces the storage overhead to \(O(1)\) on the data owner side. However, the storage overhead of the \(\mathcal{CSP}\) is the same as in reference [9].