2017 2nd International Conference on Advances in Management Engineering and Information Technology (AMEIT 2017) ISBN: 978-1-60595-457-8
Performance Enhanced for CryptDB Based on AES-NI Acceleration
Yi-feng ZHUANG
1, Chang-zheng WEI
2, Jian LI
1and Wei-gang LI
21
School of Software, Shanghai Jiao Tong University, China
2
Intel Asia-Pacific Research & Development Ltd, Shanghai, China
Keywords: Database, Security, CryptDB, Encryption, AES-NI.
Abstract. CryptDB is a database management system that provides the capability of executing SQL queries over encrypted data with a series of encryption algorithms to support SQL operations. However, these encryption algorithms incur a high system overhead, in which the AES algorithm is the most frequently used one. In this paper, we accelerate the CryptDB by substituting the ASE to a new encryption instruction set AES-NI. Evaluations prove that our acceleration can improve the performance for typical OLTP workloads YCSB under the conditions of caching the query by 3~10% in comparison with original CryptDB.
Introduction
Recently, more and more users intend to migrate their applications and data onto cloud infrastructure due to the cloud’s advantages in flexibility and low cost of maintenance. It is indicated by Alibaba Cloud 2016 Q1 Report that there are 2.3 million users have choose Alibaba Cloud products. On a third-party platform, it must provide the confidentiality to the users for their data security, preventing the leak of private data from the adversaries as well as the curious or malicious administrators. Existing systems naturally try to prevent adversaries from compromising these servers. However, experience has shown that adversaries still find a way to break in and steal the data. So Building a practical system that can compute on encrypted data and without access to the decryption key will be a effective way. In such a system, even the DBA can’t steal the original data. CryptDB provided by MIT provides such a solution with a low overhead of degrading throughput performance by 26% for queries from TPC-C, compared to unmodified MySQL. This effectiveness of CryptDB makes it be applied to many companies or organizations, including SAP, Google, Microsoft and so on.
However, it is recognized that the performance CryptDB should be improved to promote their wider acceptance.
Background and Motivation
CryptDB is a DBMS that provides provable and practical privacy even in the presence of a compromised database server or curious database administrators. Its key approach is to execute queries over encrypted data using a collection of efficient SQL-aware encryption schemes.
Data Encryption of CryptDB
Figure 1. Implementation of CryptDB is based on the OpenSSL.
For example, CryptDB uses Onion ‘Eq’, Onion ‘Ord’, Onion ‘Add’ to a string field. In the Onion Eq, the string will be encrypted by JOIN, DET, RND encryption algorithms one by one. So the data will be extended at the MySQL Server (refer with: Fig. 2).
[image:2.612.150.459.338.435.2]Because of the onions of encryption, when we want to retrieve some string fields like ‘Field1’ in Fig. 2, CryptDB will strips off the onion layers for 1~3 times. Obviously, it is a very frequent operation.
Figure 2. Data layout at the MySQL Server. Cipher Texts shown are not full-length.
Encrypted Query of CryptDB and its Performance Bottleneck
To find the performance bottleneck in CryptDB, we should figure out the encrypted query of CryptDB first.
[image:2.612.98.509.541.684.2]CryptDB is implemented on both MySQL and Postgres. The system architecture of CryptDB on
Figure 3. Encrypted Query Process in CryptDB system.
To understand query execution over cipher texts, consider the example about ReadRecord procedure in YCSB Benchmark shown in Figure 3.
An encrypted query on CryptDB involves eight steps:
1) First, The Application server will issue a query like ‘Select * from USERTABLE where YCSB_KEY=1’ to the Proxy.
2) Then, the Proxy will use CryptDB to check whether the ‘YCSB_KEY’ field at the DBMS support the equivalence checking like ‘YCSB_KEY=1’.
3) If the Onion Eq of ‘YCSB_KEY’ field, which is the C1-Eq filed in the Figure 2, isn’t at the DET layer that can support the equivalence checking, the Proxy will issue a update query to the DBMS.
4) When the DBMS received the update query, it will use UDF to strips off the RND layers. 5) After that, the Proxy will issue a query to require the related initialization vector and cipher texts.
6) The DBMS will return the encrypted data to the Proxy.
7) When the Proxy receive the response, it will do the decryption to the cipher texts.
8) At last, the Proxy will return the original data to the Application Server after the decryption. In Step 7), for the YCSB_KEY field, CryptDB will only decrypt the DET layer and JOIN layer because of Step 4). But for the other 10 string fields like FIELD1, CryptDB will decrypt the RND, DET, JOIN layers one by one.
Decrypting RND, DET, JOIN layers of string field are all based on AES algorithm. The Advanced Encryption Standard (AES) is a specification for the encryption of electronic data established in 2001 [2]. In CryptDB, the AES algorithm is used in two different modes AEC_CBC, AEC_CMC for RND_STRING, DET_STRING layers respectively.
When decrypting the RND layer, the CryptDB will use the AEC_CBC mode to do the decryption, which will call the function like ‘AES_cbc_encrypt’ in OpenSSL. When decryption the DET layer, the CryptDB will use the AES_CMC mode to avoid leaking prefix equality [4], which can be approximately thought of as one round of CBC, followed by another round of CBC with the blocks in the reverse order [1].
So we found that each string filed will be decrypted by using AES algorithm for 5 times (1 for RND, 2 for DET and 2 for JOIN), which means issuing a query like that to achieve a record will consuming 50 times AES function call (10 string fields).
Obviously, the number of times that AES decryption function was called is 5x to number of fields. Using AES is a very frequent operation in such process. So the speed of AES is directly related to the overall performance of the system, which means there is a performance bottleneck can be optimized.
Solution and Implementation
We have localized that one the performance bottleneck in CrytDB is the speed of AES. To solve this problem, we propose an acceleration using more efficient instructions to substitute AES library encapsulated in CryptDB system. To this end, we choose Advanced Encryption Standard New Instructions (AES-NI) as the candidate which is proposed by Intel in 2008 as an extension to the x86 instruction set architecture for microprocessors from Intel and AMD [5]. It’s purpose is to improve the speed of applications performing encryption and decryption using AES.
In AES-NI, it consists seven new instructions. So using the AES-NI, the system can directly use the CPU instructions to complete the AES encryption/decryption process. It will be extremely fast. According to a performance analysis, there is an increase in throughput from approximately 28.0 cycles per byte to 3.5 cycles per byte with AES/GCM versus a Pentium 4 with no acceleration. [5]
In OpenSSL v1.0.2k, there is a very convenient API called EVP cipher routines, which are a high level interface to certain symmetric ciphers. In EVP, when we set to use AES, openssl will check whether current CPU support AES-NI automatically to choose corresponding interface. Besides this, as shown in Figure 4, EVP will maintain a cipher_context and do some maintenance works, such as initialize work, padding work and so on.
Figure 4. Bypass the high level interface to use the lower interfaces.
But after our analysis, we found that CryptDB has already done the padding work. And there is no need to maintain a cipher_context and do the maintenance works. So we choose to bypass the high level interface to use some lower interfaces like ‘aesni_cbc_encrypt’, which is implemented by x86 assemble AES-NI instructions (refer with: Fig. 4).
To implement this substitution, it involves 3 steps:
1) Modify the makefile of CryptDB to replace OpenSSL v1.0.0 with OpenSSL v1.0.2k.
2) Because the lower interfaces haven’t be exported to standard openssl extern header files. So when we integrate these into CryptDB, we should add some declaration like ‘extern C’ in the related header file to use the lower interfaces.
3) Replace the related AES interfaces used in related Onions with the AES-NI interfaces
In our evaluations, this method has achieved a better improvement than using the EVP cipher routines.
Evaluation
In our evaluation, we choose oltpbench [6] to be our benchmark framework. To evaluate the performance of our acceleration, we used a machine with 2.8GHz Intel Xeon E5-2680 processors to run the application server, the MySQL-Proxy which will run a LUA script to use CryptDB, and the unmodified MySQL Server. All workloads fit in the server’s RAM.
We choose the YCSB benchmark to evaluate the system’s performance. YCSB benchmark consists one int field ‘YCSB_KEY’ which is the primary key and ten other string fields in its table.
In order to compare the performance in different circumstances, we modified the benchmark a little. YCSB-512-10 represents the benchmark consists ten string fields and each field is 512 byte size.
Besides these, we cached the rewritten queries which sent to the MySQL Server, because this rewriting part has no relation with our acceleration.
Figure 5. YCSB Benchmark with different field size and different field number.
To understand our performance improvement, we measure the decryption speed of AES and AES-NI. In AES, it will spend 0.007~0.012 ms to decrypt a 512 bytes string. As a comparison, in AES-NI, it only spend 0.0008~0.0012 ms which outperforms the AES at least 583%. And in CryptDB, only 23% time is spent in encryption and decryption [1]. So this improvement is reasonable.
Summary
In this paper, we accelerate the CryptDB by substituting the ASE to AES-NI, and achieve a good improvement. Besides this acceleration, we think maybe we can accelerate the CryptDB based on some hardware or accelerate other encryption algorithm in the future.
Acknowledgement
We thank WeiGang Li (intel), Raluca Ada Popa (UC Berkeley) to give us useful advice and relative machines. We also thank Andy Pavlo (Carnegie Mellon University) and the rest of the oltpbench
maintainers for maintaining an excellent Benchmark Framework.
References
[1] Popa R A, Redfield C, Zeldovich N, et al. CryptDB: protecting confidentiality with encrypted query processing. Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles. ACM, 2011: 85-100.
[2] Information on https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
[3] Information on https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
[4] Halevi S, Rogaway P. A tweakable enciphering mode. Annual International Cryptology Conference. Springer Berlin Heidelberg, 2003: 482-499.
[5] Information on https://en.wikipedia.org/wiki/AES_instruction_set
