# Technique for Searching Data in a Cryptographically Protected SQL Database
## 3 Main Security Aspects  
In the proposed solution, as in most active research in the field of secure search technology, we consider a curious database administrator (DBA) or other external attacker with full access to the data stored on the DBMS server as the main threat to database security while recognizing that such attackers can be either semi-honest or malicious. In our solution, we use a searchable encryption scheme that allows the owner of the secret key (more precisely, keys) to read and write data, creating searchable encrypted data, and trapdoors (providing the so-called architecture (S/S)--single writer/single reader [6]). In doing so, we extend this scheme to the so-called multiwriter/multireader (M/M) architecture layer by distributing a secret key to allow multiple users to perform write and search over an encrypted database. Moreover, we are taking certain measures to simplify the process of user revocation if necessary (not to cause big overhead). The architecture of the proposed solution is shown in Figure 1. This is a typical of three-tier client-server architecture. This architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a specific level of abstraction [32]. This allows developers to create flexible and reusable applications. In addition, the three-tier architecture allows applications in any of the three tiers to be independently upgraded or replaced in response to changing requirements and technologies, thereby simplifying the implementation and maintaining such a system up to date, taking into account the development of security standards. In the solution under consideration, users and the application server are trusted, and the DBMS server is untrusted. Each user \(i=1,\ldots,n\) has some security token, in which container files (stegocontainers)--file\({}_{i}^{1}(K_{sec})\), file\({}_{i}^{2}(K_{ss})\) are stored in a compressed and encrypted form (file\({}_{i,zip}^{enc}=\mathrm{Enc}_{D}(\mathrm{file}_{i}^{1}(K_{sec}),\mathrm{file}_{i }^{2}(K_{ss}))\)) using the secret key \(P_{i}\). These container files contain decryption keys: \(K_{sec}\) for the special database table \(R^{sec}\) and \(K_{ss}\) for special software modules. \(R^{sec}\) and modules of special software are stored on the DBMS server. The container files are different for each legitimate user; moreover, where and how the corresponding keys \(K_{sec}\) and \(K_{ss}\) are contained in them, the users themselves do not know. These stegocontainers usually have different names. The database proxy leads them to names known to special software stored in encrypted form on the DBMS server. This is intentional in order to simplify the process of user revocation. Namely, do not distribute once again a new secret key (in this context, a file with stegocontainers that store the keys \(K_{sec}\) and \(K_{ss}\)) among the remaining users. Figure 1: Architecture of the proposed solution. The transmitted compressed encrypted file (file\({}_{i,zip}^{enc}\)\(=\) Enc\({}_{P_{i}}\)(file\({}_{i}^{1}(K_{sec})\), file\({}_{i}^{2}(K_{ss})\))) from the corresponding legitimate user \(i=1,\ldots,n\) arrives at the application server (database proxy). The database proxy (it is essentially a reverse proxy between the application and an untrusted DBMS server), knowing the secret key \(P_{i}\), decrypts and decompresses the file file\({}_{i,zip}^{enc}\) (Dec\({}_{P_{i}}\)(file\({}_{i,zip}^{enc}\)) = Dec\({}_{P_{i}}\)(Enc\({}_{P_{i}}\)(file\({}_{i}^{1}(K_{sec})\), file\({}_{i}^{2}(K_{ss})\)))) when processing the first user request related to the search for the required encrypted data in the active session. The decrypted container files file\({}_{i}^{1}(K_{sec})\), file\({}_{i}^{2}(K_{ss})\) are subsequently transferred over a secure channel to the DBMS server. Table \(R^{sec}\) stores in encrypted form the keys for decrypting the encrypted sensitive data of certain attributes of the corresponding database tables.