## 4 Privacy Preserving in Cloud Computing
### Data Privacy  
It is well-known that storage data encryption is not fully efficient in preserving the privacy of outsourced storage applications [79]. The frequency of accessed storage locations from the server by users can leak a substantial volume of sensitive user information through statistical interpretation for unencrypted data [43]. Since only cryptographic techniques cannot ensure privacy, [PERSON] and [PERSON] [80] first proposed the concept of Oblivious RAM using Definition 6.  
**Definition 6**.: _A data access is said to be oblivious if accessing the cells of \(A\) according to a random hash function, \(h(i)\), as \(A[h(1)],A[h(2)],\)\(\cdots,A[h(n)]\), or random permutation, \(\pi(i)\) as \(A[\pi(1)],A[\pi(2)],\)\(\cdots,A[\pi(n)]\), and not oblivious if \(T[h(A[1])],T[h(A[2])],\)\(\cdots,T[h(A[n])]\), where \(T\) is a hash table_  
The method employed by Oblivious RAM allows a client to conceal its access pattern to the remote storage by continuous shuffle and data re-encryption as they are accessed. Even if a malicious attacker observes or intercepts storage locations, the Oblivious RAM algorithm ensures that the adversary has a negligible probability of learning anything about the true logical access pattern. To further enhance user access patterns when using ORAMs, [PERSON] et al. [81] proposed privacy-preserving data access using a combination of probabilistic encryption, which directly hides data values, and stateless oblivious RAM simulation, which hides the pattern of data accesses. The limitation to this was the worst-case efficiency of the algorithm, which achieved \(O(\log n)\) amortised access overhead. Further works by [PERSON] et al. [82] achieved \(O(\log^{2}N/\log\chi)\), for large block size \(B=\chi logN\) with a reduction rate of \(\chi\geq 2\) for every \(N^{\prime}=N/\chi\), where \(N\) represents the number of blocks. The integrity check of the Path ORAM was based on the concept of the Markle Tree, where data storage is placed at every node of the tree and not only the leaf nodes. Tagging every node bucket of the Path ORAM with a hash of the form \(H(b_{1}||b_{2}::||b_{Z}||h_{1}||h_{2})\), where \(b_{i}\) for \(i\in\{1,2,3,4,5,\ldots,Z\}\) represents bucket blocks, and \(h_{1}\) and \(h_{2}\) represent the left and right leaf hashes, respectively. Therefore, for leaf nodes, \(h_{1}=h_{2}=0\), only two nodes for each ReadBucket or WriteBucket operation will need to be read or written. However, [PERSON] et al. [83] have shown that information can still be leaked even if only Write Access Patterns are visible to a malicious intruder. Instead, the authors [83] proposed the Flat ORAM. The algorithm comprises two zero-initialised OccMAP and PosMap corresponding to the occupancy and the position map of \(N\) and \(P\) entries, respectively, allocated. Then, each block is mapped to a random block, assuming that PosMap and OccMap both reside where the adversary has no access (on-chip). Any collision is being avoided with OccMap. The OccMap is then updated as 'occupied' for all assigned logical blocks. For an integrity check for Flat ORAM, let us assume a logical block with counter \(c\), upon any writes, the controller computes MAC \(h=MAC_{K}(a||c||data)\) using \(K\) as a secrete key, then writes the tuple \((h,data)\) to Dynamic RAM (DRAM). The hypothetically altered data tuple \((h*,data*)\) is read upon every read. Then the ORAM controller recomputes hash MAC \(h=MAC_{K}(a||c||data*)\) to check if \(h=h*\). If they are both equal, then data integrity has been verified. The mechanisms of the Flat ORAM shuffles only Write Access Patterns to conserve user privacy. Interestingly, it is preferred to a fully functional ORAM because it offers better performance and higher energy efficiency.