New Solution Implementation to Protect Encryption Keys Inside the Database Management System

A R T I C L E I N F O A B S T R A C T Article history: Received: 31 December, 2019 Accepted: 13 February, 2020 Online: 09 March, 2020 Due to the attacks' growth on sensitive databases by deploying advanced tools, beyond access control and authentication mechanisms, the database encryption remains a useful and effective way to ensure robust security of data stored within it. Any database encryption solution is based on a specific encryption model that determines how data is encrypted inside it. A relevant database encryption model must necessarily adopt a strong security policy of data encryption keys. It determines how these keys are generated, stored, and protected. In this work, we will implement an original solution that protects the encryption keys when encrypting data occurred at the Database Management System level. Our solution suggests protecting the keys by their encryption with other ones named Master Keys, which are generated according to the encryption granularity defined by the database encryption model. The proposed solution protects the keys of two database encryption models: at the level of the columns and the level of tables.


Introduction
Database (DB) level encryption is a way to encrypt and decrypt data within the Database Management System (DBMS) using keys held by the DB server [1]. In fact, this encryption model offers major advantages, in particular, those related to the security of the encryption keys against external attacks performed outside the information system [2,3]. Though the probability of the administrator attack is not negligible, he owns large privileges on DB. Hence, he can attack the DB directly, via a collaboration with a malicious external attacker (disclosure of the administrator account for example), or with an internal attacker such as a legitimate user [4,5,6]. Obviously, the DB administrator has the ability to perform all these attacks without leaving any traces [7,8]. Data encryption at the DBMS level is based fundamentally on its specific encryption model. The management of encryption keys within this model is a crucial point, it defines the ways how keys are generated, stored, and protected [9,10]. Actually, keys values, how users access them, and where they are stored are the ultimate goal of any attacker. Therefore, it should be necessary to establish a protection policy for encryption keys to minimizing their exposure face of malicious attackers. Indeed, many solutions have been developed in order to resolve this problem. For instance, the keys protection solutions implemented at DBMSs such as Oracle, Ms SQL Server and My SQL are mainly based on the use of "Wallets", Hardware Security Module (HSM) and "Security server" [11][12][13][14]. In fact, each one of these solutions has advantages and major limits, as have already explained in more detail in our previous work [8,15].
Several studies proposed several solutions to protect DB encryption keys either in DB encryption models or separate solutions of keys protection [16,17]. The authors of [16] proposed a model to protect encryption keys based on a concept of distributed keys representation. The first key part stored in the DB, and the other part is obtained by converting the user password. Elovici et al. presented a special DB encryption model that permits to protect keys using "Wallet" mechanism [17], although Itimar et al. used asymmetric key encryption [18]. The authors of [19] suggested a solution called "Server-HSM" which merges an HSM and a security server into a module called "HW Security Module" that might be integrated into a DB server. This module manages user privileges and protects keys with their encryption. El bouchti et al. presented a full package of encryption keys protection models inside the DBMS. Their method allows encrypting keys with master keys generated according to encryption granularity adopted by the DBMS encryption model [15]. Sesay et al. in their proposed DB encryption model suggested protecting keys by the use of a particular way. In fact, they generate the encryption keys from a unique master key (Km) generated and stored in a tamper-proof controller [20].
Notwithstanding several DB security studies for improving the concept of encryption keys protection within DBMS, more investigations are required to develop, improve, and provide more security and flexibility to keys protection. Then, as discussed in our previous work presented in [7,10,15], most of the proposed solutions have their advantages and disadvantages. However, to our knowledge, a trusted and simple solution concretized by a real implementation, and adapted to more than one DB encryption model has not yet been proposed.
In this context, the present work aims to implement two solutions proposed in our previous work [15] to protect DB encryption keys. Our solutions protect encryption keys when encryption granularity adopted by the DBMS is fixed at the column level or the entire table level. They consist of encrypting the DB encryption keys of tables and columns using Km, generated by deploying two models. We consider that the main original features of our solution are its reliability and its principle. It does not require any control or management of key protection by a DB or security administrator as well as it resists strongly against attacks performed by administrators.
The present work will be structured as follows: section two presents the proposed models of Km and the common objects of the implementation of each model. It also explains how our Km models work with DB encryption models that we will implement. Section three explains the implementation and discusses the provided results. Finally, our article ends with a conclusion.

Definition of the proposed solution
In this section, we will define two models (1 and 2) of the Km generation that protects, respectively, the columns and tables keys. We will also describe the role of the common objects that have used between the two models' implementation and how those models work in an encryption/decryption process.

Proposed models of Km
The generation of the Km follows the two different models below: • The Km (C) key used to protect the encryption keys of the DB columns. It is generated by the DBMS according to the model defined below:  (2) In order to concretize the functioning and the response of the models (1) and (2), we have designed and implemented two models of DB encryption (A) and (B) having, respectively, two encryption levels: column and table. The functioning of each Km generation model is associated with the execution of a DB encryption model, as shown in Table 1.

The common objects of each model implementation
The creation of elements below is common for the implementation of the models (1) and (2).
MYTABLE_ENCRYPT_OBJET: This DB table contains records of : i) the names of the objects on which encryption has defined, ii) the used encrypt algorithms, and iii) the encryption of the encryption keys using Km. It has the following structure: MYTABLE_ENCRYPT_OBJET (K_OBJECT_NAME, K_ENCRYPT_ALGO, K_KEY) TEST_MANAGEMENT: This DB table contains the records of : i) the names of the objects on which encryption has defined, ii) the used encrypt algorithms, iii) the object encryption keys, and iv) the Km of each object name. In fact, TEST_MANAGEMENT table is not implemented in the real working case of our solution. Nevertheless, its main role is to illustrate the results of the creation of both encryption keys and the Km. The table has the following structure: where: C1_OBJECT, K_OBJECT_NAME: the object on which we have defined encryption; C2_ALGO, K_ENCRYPT_ALGO: the algorithm used for encryption; C3_KEY: the encryption key; C4_MASTERKEY: the generated Km; K_KEY: the encrypting result of encryption keys using Km.
The Md5 hash function: it is used to create the encryption keys and the Km while implementing all models. The AES256 algorithm: it is the algorithm used to encrypt / decrypt the data.

Note:
The term "Objet" signifies the column and table names.

Principle of the encryption/decryption process
An encryption/decryption process in the model (A) follows the defined steps below: When a user sends a query to be executed, the DBMS generates the Km for each column on which encryption is defined. The DBMS decrypts, using the generated Km, a value from the K_KEY column belonging to MYTABLE_ENCRYPT_OBJET table and which corresponds to the column desired to be encrypted or decrypted. This process generates the real encryption key of column that will encrypt (in the case of an inserting or updating query) or decrypt (in the case of a consulting query) the data.
The encryption/decryption process in the model (B) follows similar operations. In this case, the DBMS generates a single Km in response to the user's query since the encryption is defined on the entire table.

Case study: the dosimetric monitoring of agents
A real case study has chosen to illustrate the models' implementation results.
Let have a database named "ORCL10G" of a nuclear power plant intended to manage the dosimetric monitoring of agents working under ionizing radiation. The "agent" table stores the accumulation of the different types of doses received by each agent during the period of his work within the plant. We assume that all the data in the "agent" table are sensitive since the dose values are considered in the nuclear field as medical secret. The table "agent" has the following structure: agent (idf_agent, name_agt, Dose_interne_agt, Dose_superficielle_agt, Dose_profonde_agt, Catégorie_agt)

Implementation of the proposed models
In this section, we will present the implementation of the models (1) and (2) generating Km as well as the corresponding DB encryption models (A) and (B).

Implementation of the model (1)
In order to create the "agent" table and defining encryption on all its sensitive columns, we have used the following SQL syntax: Create table agent (idf_agent varchar2(100) encrypt using AES256, name_agt varchar2(100) encrypt using AES256, Dose_interne_agt varchar2(100) encrypt using AES256, Dose_superficielle_agt varchar2(100) encrypt using AES256, Dose_profonde_agt varchar2(100) encrypt using AES256, Catégorie_agt varchar2(100) encrypt using AES256); The "Algo1" algorithm supports the execution task of this statement; it creates the "agent" table and defines encryption on its columns using the AES256 algorithm. In fact, the data column will be encrypted/decrypted with six keys KC which will be protected by six masters key Km (C). In addition, the "Algo1" generates and stores the encryption keys of the columns (Kc) and the master keys The execution of the "Algo1"algorithm generates the following records:    In order to test model (1), the "Algo2" algorithm represents the functioning of Model (A). It supports the data encryption inserted by a user. Tables 4 and 5 show the result of inserting four lines in the "agent" table before and after the encryption.

Implementation of the model (2)
To implement model (2), we define encryption on the "agent" table level using the following SQL syntax: Create table agent encrypt using AES256 (idf_agent varchar2(100), name_agt varchar2(100), Dose_interne_agt varchar2(100), Dose_superficielle_agt varchar2(100), Dose_profonde_agt varchar2(100), Catégorie_agt varchar2(100)); The "Algo3" algorithm supports the execution of this instruction. It creates the "agent" table and defines encryption on all its data using the algorithm AES256. In this case, the data are encrypted /decrypted with a single key KT, which will be protected by a single master key Km (T). The The execution of the "Algo3" algorithm generates the following records: The "Algo4" algorithm represents the functioning of the model (B). It supports the data encryption inserted by a user. The tables 8 and 9 show the result of inserting four rows in the "agent" table before and after the encryption.

Results and discussion
This section introduces data discussion and analysis based on the findings obtained by implementing the two Km models. They are summarized as follow: • The proposed solutions are more practical than the conventional ones, primarily the Wallet, HSM, and the security server, where their disadvantages have explained and revealed in [15]. Our solutions optimize perfectly additional costs to protect the keys either in terms of hardware acquisition (case of HSM and security server) or in human resources (the administrator of the security server). • The Wallet solution used in Oracle TDE generates Km, which protects encryption keys, and stores it within the Wallet. Here, it is necessary to create the Wallet and its password as well as a secured location (such as backup systems) to store the password whenever the Km is newly created. This operation is mandatory before starting the process of data encryption/decryption inside DBMS [11]. It is worthy to mention that the backup system is a critic component of the Wallet concept. In this vein, the protection concept of encryption keys based on the proposed models (1) and (2) is similar to the Wallet solution in terms of Km generation within the DBMS. However, with our concept, the Km creation does not require any Wallet creation to store Km or secured location to store the password. • The proposed solution does not require any protection management of the encryption keys by a security administrator, DB administrator or another trusted collaborator, as discussed in [15]. Hence, none of them knew about the generation of Km or its location.  (1) implementation, we focused on to protect 6 encryption keys of the following columns (idf_agent, name_agt,Dose_interne_agt,Dose_superficielle_agt,Dose_ profonde_agt, Catégorie_agt). Each column key is protected by encrypting it with its own Km generated by the model (1). This protection was tested by the implementation of the model (A). Table 4 shows the encryption test results of the 6 columns of the "agent" table deploying the model (1). Likewise, in the model (2) implementation, one encryption key of the table "agent" has protected with a single Km generated using this model. Then, this protection was tested using the model (B). Table  8 represents the result obtained of encrypting  (1) or (2), respectively. Each value of generated Km is used to extract, from K_KEY column, the real encryption /decryption key. The process of data decryption follows the same operations. • Finally, both proposed model works inside DBMS are summarized according to the algorithm flowchart described below: Let's consider a sensitive table A Figure 1: Algorithm flowchart specifying the both proposed models.

Conclusion:
Besides the conventional mechanisms deployed to secure sensitive DB (network protection, authentification, and access control), data encryption at DBMS level is a strong way that reinforces the defense in depth of the sensitive data. This process is strongly linked to the protection of the encryption keys on which they depend on two main factors: the location where the keys are stored and users who have access to them.
Our contribution in this article is to implement two solutions that secure encryption keys within the DBMS. These solutions are original and well adapted to any encryption model inside a DBMS. The solution's purpose is to protect DB keys by their encryption using a master key generated when defining encryption on a table or column. In forthcoming works, we aim to develop a solution that covers the protection of encryption keys when encryption is done on Tablespaces.

Conflict of Interest
This manuscript has not been published and is not under consideration for publication elsewhere. We have no conflicts of interest to disclose.