# Technique for Searching Data in a Cryptographically Protected SQL Database
## 4 The Proposed Technique for Searching the Required Data
However, if certain efforts are not made to prevent access to this key (by taking possession of the value of this key) by illegitimate users, and first of all, in this case, this applies to privileged users (such as a DBA or an external attacker with DBA rights), then this would allow the attacker to gain access to all data. Therefore, taking into account all of the above, a compromise solution was adopted in the proposed approach. Namely, to use an effective cryptosystem to encrypt sensitive data, but to provide access to these data only to a legitimate user and only one that will provide the database server (indirectly through the database proxy) during an active session with an encrypted file with steganocontainers \(\text{file}_{i,\_zip}^{encr}\) containing the corresponding secret keys \(K_{\textit{sec}}\), \(K_{\textit{ss}}\) of the user. The encrypted file \(\text{file}_{i,\_zip}^{encr}\) is decrypted and decompressed by the DB proxy server, and the corresponding container files \(\text{file}_{i}^{1}(K_{\textit{sec}})\), \(\text{file}_{i}^{2}(K_{\textit{ss}})\) are transmitted over a secure channel to the DBMS server. On the DBMS server, the corresponding keys are extracted automatically by special software, the main modules of which are also encrypted. These modules are decrypted only if the \(K_{pd}\) and \(K_{\textit{ss}}\) keys are available, which are associated with a legitimate user. The activity of the \(K_{\textit{sec}}\), \(K_{\textit{ss}}\) keys is limited by the duration of the session. Their values are assigned to the corresponding attribute of the so-called application context (application context--a set of pairs: \"attribute name--value\"), more precisely, the database session-based application context, which is initialized locally [38]. As is known [39], such values are valid within the active session, and they are not visible to another session. Thus, in our solution, the encryption keys are associated with the user's keys/passwords, which allows decryption of the corresponding data elements only by legitimate users who present the corresponding keys in an active session. Therefore, a curious DBA and an attacker with DBA rights, not knowing \(K_{\textit{sec}}\), \(K_{\textit{ss}}\), \(K_{pd}\) and not being able to disclose their values, and, therefore, not being able to extract the corresponding keys (\(K_{1}^{R}\), \(K_{2}^{j}\)) from the table \(R^{\textit{sec}}\), will not be able to decrypt the main modules of special software and encrypted data, which is what we were striving for in this case. In general, our solution allows the DBMS server to execute SQL queries over encrypted data in much the same way as if it were executing the same queries over open data. At the same time, existing applications do not need to be modified. The query itself is modified on the proxy server. The database server within the active session of a legitimate user executes a modified query, automatically extracting the required encrypted data. For automatic extraction of encrypted data, encrypted stored modules of special software are used. The latter are automatically decrypted by some open modules stored on the database server using file\({}_{i}^{2}(K_{ss})\) and \(K_{pd}\) received from the proxy server. We will consider the features of query processing on the DBMS server using the example of the implementation of the proposed solution for the Oracle DBMS. In our solution, we use the potential of the RLS (Row Level Security) technology [40], supplementing it with the capabilities of the application context [39; 41; 42]. We also use the capabilities of fine-grained audit (FGA) technology [39; 41; 42], and first of all, the ability to mimic a SELECT trigger (by automatically executing a stored procedure when a user issues SELECT). The main stages of the proposed solution are:  
1. Execution of the \(P_{DS}\) procedure stored in clear text on the DBMS server.