We propose storage efficient SQL-aware encrypted databases that preserve the format of the fields. We give experimental results of storage improvements in CryptDB using FNR encryption scheme

Prakruti C

Sashank Dara

V. N.  Muralidhara

Cryptology ePrint Archive

Efficient Format Preserving Encrypted DatabasesPrakruti CIIIT- BangaloreEmail: prakruti@iiitb.orgSashank DaraCisco Systems India Pvt. LtdEmail: sadara@cisco.comV. N. MuralidharaIIIT- BangaloreEmail: murali@iiitb.ac.inAbstract—We propose storage efficient SQL-aware encrypteddatabases that preserve the format of the fields. We give exper-imental results of storage improvements in CryptDB using FNRencryption scheme.Keywords Format preserving Encryption, CryptDB, computa-tional privacy, block ciphers, FNRI. INTRODUCTIONCloudification of application stacks, legacy systems,databases etc. has many benefits but ensuring privacy ofsensitive fields while retaining their computability is quitechallenging. Such privacy preserving efforts involve identi-fication of sensitive fields in the system and re-engineeringsuch data fields in order to encrypt them. Many companies areskeptical from moving their critical applications to the clouddue to privacy issues associated with outsourcing sensitive datato third party cloud providers.For example, a data field might be well-defined for ac-commodating IPv4 address of size 32 bits with number ofvalidations throughout the application stack (and/or database)to ensure the input data is in fact IPv4 address. In order topreserve the privacy of this field using traditional AES-128scheme it has to be re-engineered to accommodate 128 bits ofmemory instead of 32 bits. Also any validations that identifiesthe type of the data (dotted notation of IPv4 address) needs tobe removed in order to accommodate a random cipher stringof encrypted IPv4 address.While the length expansion of the field needs more storage(and/or bandwidth) the removal of validations might openup serious security vulnerabilities in the form of injectionattacks. The same issue is applicable while ensuring privacyof any sensitive fields like MAC addresses, Email addresses,Usernames, Account numbers, Serial Numbers, SSN, CreditCard numbers etc.Recent advances in SQL-aware encrypted database systemslike CryptDB[1] attempts to solve this problem. CryptDB is asystem that provides practical and provable confidentiality forapplications that are backed by SQL databases. It allows run-ning most standard SQL queries over encrypted data withoutever decrypting it.CryptDB uses conventional Symmetric Encryption schemeslike AES and BlowFish to encrypt the data that is to bestored in the database. Cryptographic Schemes like AES andBlowFish do not preserve the format of the plaintext afterencryption. As a result of which there is a change in databasefield length and field types. For example, encrypting a 16 digitcredit card number(of data type Integer) using AES producesa 128 bit ciphertext. The major drawback involved in usingconventional encryption schemes like AES and BlowFish isthat it adds up to the storage space required to store theencrypted data.A. Key ContributionsIn this paper we propose usage of a Format PreservingEncryption(FPE) to encrypt data fields in CryptDB. This pre-serves the length and formats of the plaintext upon encryption.Hence we name our implementation as FP-CryptDB. Weprovide experimental results on improvements in storage gainswith minor impact on performance.II. PRELIMINARIESA. Format Preserving EncryptionFormat Preserving Encryption(FPE) retains the formats ofthe input domains upon encryption. Encryption of an IPv4address (represented in dotted notation format) using con-ventional encryption techniques like AES would result in arandom string but not an IPv4 address format again. Whereasencrypting using FPE encryption schemes would ensure thatresultant cipher text is again an IPv4 address.We use simplified definitions of FPE scheme without loss ofgenerality. More rigorous definitions and proofs are availablein [2]. FPE algorithms have additional parameters tweak t anddomain d. Tweak t is similar to cryptographic salt to provideadditional randomness. Domain d defines the domain in whichthe plain text belongs to. For example input domains could beIPv4 address or Credit card number etc.The basic algorithms of an FPE encryption scheme aredefined as below1) KeyGen(σ) Generates a key k, tweak t based on asecurity parameter σ.2) Encryption(p, k, t, d) Given a plaintext p, key k and atweak t the algorithm produces cipher text c such thatboth the plaintext p and ciphertext c are in the same do-main d. As shown in the Fig.4, it internally uses rank andde-rank methods along with a length preserving blockcipher enc‘. Detailed examples of ranking functions arediscussed later.3) Decryption(c, k, t, d) Given a ciphertext c, key k anda tweak t the algorithm returns the corresponding plaintext p. Here both c, p are in same domain.FNR is a arbitrary length small domain block cipher pro-posed in [3]. FNR scheme could be used to preserve theformat and length of arbitrary length small domain sensitivedata like MAC addresses, IPV4(32), IPV6(32) etc. FNR usesPair wise Independent Permutations along with classic FeistelNetworks which is proven to provide additional security to itsalternatives.B. SQL Aware EncryptionSQL Aware Encryption is a technique that defines anencryption scheme for each of the pre-defined set of SQLoperations like equality checks, joins, aggregates, inequalitychecks etc. As a result of this every data item is encrypted ina way such that it is possible to perform computations on theresultant ciphertext[1].III. TECHNICAL ARCHITECTUREA. FP-CryptDBThe fundamental architecture of our modified version issame as CryptDB. We differentiate in the encryption tech-niques used internally as discussed in below sections.CryptDB comprises of three major components, namely theApplication Server, Proxy Server and DBMS Sever. Applica-tion Server is the main server that runs CryptDB’s databaseproxy and also the DBMS Server. The Proxy Server storesa secret Master Key, the database Schema and the onionlayers of all the columns in the database. The DBMS serverhas access to the anonymized database schema, encrypteddatabase data and also some cryptographic user-defined-functions(UDF’s). The DBMS server uses these cryptographicUDF’s to carry out certain operations on the encrypteddata(ciphertext).Fig.1 describes the architecture of CryptDB.Fig. 1: CryptDB ArchitectureBelow we describe the steps involved in processing a queryinside CryptDB.1) In the first step a query is issued by the applicationserver. The proxy server receives this query and itanonymizes the table name and each of the columnnames. The proxy server also encrypts all the constantsin the query using the stored secret master key. Theencryption layers or the onion layers are also adjustedbased on the type of operation required by the is-sued query. For example if the query has to performsome equality checks then the deterministic encryptionscheme(DET)is applied to encrypt all the values in thatparticular column (on which equality check is to beperformed).2) The encrypted user query is then passed on to theDBMS server. The DBMS server executes these queriesusing standard SQL and also invokes UDF’s to performcertain operations like token search and aggregation. Thequeries are executed on the encrypted database data.3) The DBMS server performs computations on the en-crypted data and forwards the encrypted results back tothe proxy server.4) The proxy server decrypts the encrypted query resultobtained and returns it to the application server.B. Encryption TechniquesCryptDB uses different Encryption techniques based on theoperations desired by the issued query. For example if thequery does not involve any equality or inequality checks thenthe query is encrypted using random encryption scheme(RNDlayer). If the query involves any SUM aggregate calculationthen CryptDB uses homomorphic encryption scheme[4](HOMlayer). For performing equality checks deterministic encryp-tion scheme(DET layer) is used. CryptDB uses separate en-cryption schemes for performing inequality checks and joins.In this paper we have focused on two encryption layersRandom and deterministic(DET).1) Random (RND)It is a probabilistic encryption scheme which meansthat two equal plaintexts map to two different cipher-texts. Due to this probabilistic property it provides themaximum security and is IND-CPA secure. The randomencryption layer in CryptDB is implemented using AES-CBC-128 for strings and Blowfish (CBC mode) forintegers. Both these schemes use a random initializationvector(IV).2) Deterministic (DET)It is a deterministic encryption scheme which means thattwo equal plaintexts map to the same ciphertext. Dueto deterministic property this layer is less secure thanrandom (RND) layer. The deterministic encryption layerin CryptDB is implemented using AES-CMC-128 andBlowfish, using a zero initialization vector. This layeris used by the server to compute select queries withequality checks, equality joins, COUNT and DISTINCT.Fig.2 describes the various encryption layers of CryptDB fora simple INSERT query. As shown in the Fig.2, the columnsin the query are encrypted twice using DET layer followed byencryption using RND layer. The output of RND_int(for acolumn with Integer Input type) and RND_str(for a columnwith varchar input type) is the final ciphertext that is storedin the database.FP-CryptDB achieves both the above described propertiesof Format Preserving Encryption (FPE) schemes. The follow-ing Fig.3 describes the various onion layers of FP-CryptDB.In addition to the above two described layers CryptDB [5]has many other onion layers like OPE(order-preserving en-cryption layer) to support range queries, HOM(homomorphicencryption layer)[6] [4] to support aggregation and counts,SEARCH layer performs full word keyword searches onencrypted data[7].These additional layers aide to perform different SQLoperations on the encrypted data without decrypting the data.These layers are left as is in our modified implementation FP-CryptDB.Fig. 2: Onion Layers of CryptDB for an SQL INSERT queryFig. 3: Onion Layers of FP-CryptDB for an SQL INSERT queryIV. IMPLEMENTATIONA. Toy ApplicationWe take network monitoring application as reference. Thedata used in our implementation is used by security analysts tomonitor and analyze network traffic. Attributes of the data areSource IP address, Destination IP address,Protocol, Numberof packets, Number of Records, No of Bytes, Start date, Enddate, Sensor. These fields are useful for network monitoringapplications to perform traffic analysis, intrusion detection andpacket filtering. For our analysis, we have taken five fieldsfrom this dataset, which are described in Fig.5.B. Encryption of Data TypesIn our modified FP-CryptDB we preserve the formats andlengths of the input strings. We chose Flexible Naor andReingold (FNR) is length preserving block cipher for inputs32 to 128 bits [3], [8]. We preserve the lengths and formatswhile encrypting IPv4 (Table I) , Time Stamps (Table II) asdiscussed below.1) IPv4 Addresses: An IPv4 address is ranked as a 32 bitsinteger. The ranked integer is then encrypted using a blockcipher like FNR to result in another 32 bits integer. Theresultant cipher text is converted back (de-ranked) to dottednotation of IPv4 address in order to preserve the format. Theoutline of the algorithm is show in Fig.4.Fig. 4: Format-preserving encryptionPlain Text Cipher TextRaw(Dotted) Ranked(Integer) Raw(Integer) De-ranked(Dotted)64.243.129.86 941079480 1226870871 73.32.144.8756.23.187.184 2213763856 1067498731 63.160.188.235131.243.91.16 4026531837 2739475379 163.73.19.179239.255.255.253 905584639 2223369266 132.133.236.5053.250.31.255 3222780570 2000079960 119.54.204.88TABLE I: Samples for IPv4 Addresses2) Time Stamps: To preserve the format of the input timestamp, first the date field is ranked to epoch value 1. Theobtained epoch value is then encrypted using FNR encryptionscheme. The encrypted epoch value is then again is de-rankedback to date. The obtained date is the ciphertext and is in thesame format as that of the plaintext.3) Integers: Few fields in the application like Port Number,Packets transfered are plain integers. On encrypting integerswith FNR scheme we get back an integer as the ciphertext.These fields do not need any special ranking functions. In ourimplementation we have used unsigned 64-bit integer data typeto store the ciphertexts.V. EXPERIMENTSA. SetupWe used Ubuntu 12.04 setup with 4GB RAM, 2.60 GHzProcessor, Intel(R) Core(TM) i5-320M. We have taken refer-ence data derived from anonymized enterprise packet headertraces obtained from Lawrence Berkeley National Laboratoryand ICSI [9][10]. This data covers the network traffic in1Epoch is the date and time with reference to which a computer’s clockand time-stamp values are determined. Most versions of Unix, use January 1,1970 as the Unix Epoch. Unix Time-stamp is basically the number of secondsbetween a particular date and the Unix Epoch.Plain Text Cipher TextRaw(String) Ranked(Integer) Raw(Integer) De-Ranked(String)Date String Unix Timestamp Unix timestamp Date String2004/11/16T21:04:05 1100639045 1531152620 2018/07/09T16:10:202004/11/15T15:44:38 1100533478 627185476 1989/11/16T02:11:161988/01/14T09:27:05 569150825 3645016902 2085/07/03T16:41:422005/01/7T41:33:07 1105205587 2685279782 2055/02/03T15:03:022005/01/6T22:07:06 1105049226 3275728681 2073/10/20T12:38:01TABLE II: Samples for Time stampsparticular hours on dates in late 2004 and early 2005. Thedata sets are in SILK flow record format. We have encryptedup to 1 million SILK flow records[11], using FNR encryptionscheme and analyzed the performance.B. Results1) Storage: Our experimental results show approximately50% 2 storage efficiency in FP-CryptDB for our applicationchosen. The storage gain is due to length preserving nature ofFNR scheme used in FP-CryptDB. The database schema ofour application is shown in Fig.5. Fig.6 is a graph that showsthe estimated storage space for data encrypted in CryptDB(using AES) and FP-CryptDB (using FNR).The X-axis represents the Number of records inserted intothe database and the Y-axis represents the Database Size inMB.Fig. 5: Database Schema of FP-CryptDBIn our implementation, we have five VARCHAR fields inour database as shown in Fig.5 and the encrypted databasealso stores the salt values which is used to encrypt queriesand onion layers in CryptDB. Therefore the estimated averagerow length is the sum of variable data length(size of ciphertextstored) and the total size required to store the salt value foreach field.Fig. 6: Storage in MB for CryptDB and FP-CryptDB2) Performance: The following graph shows the perfor-mance of FNR when compared to AES-128. The X-axisrepresents the No of records inserted and Y-axis represents thetime (in milliseconds) to execute n number of SQL INSERTqueries.2Note that this varies based on the data fields of the application chosen.The performance degrades in the case of FP-CryptDB ascompared to CryptDB. It could be noticed that the perfor-mance degrades y ≈ 7x times. This is in lines with theory,FNR scheme internally uses 7 rounds of AES by design [3].Fig. 7: Performance of CRYPTDB versus FP-CRYPTDBVI. CONCLUSIONSIn this paper we have proposed Format Preserving En-crypted Databases FP-CryptDB. We took network monitoringas reference application. We provided experimental results onstorage gains that could be achieved using FPE schemes withminor degrade in performance.REFERENCES[1] R. A. Popa, C. Redfield, N. Zeldovich, and H. Balakrishnan, “Cryptdb:protecting confidentiality with encrypted query processing,” in Pro-ceedings of the Twenty-Third ACM Symposium on Operating SystemsPrinciples. ACM, 2011, pp. 85–100.[2] M. Bellare, T. Ristenpart, P. Rogaway, and T. Stegers, “Format-preserving encryption,” in Selected Areas in Cryptography. Springer,2009, pp. 295–312.[3] S. Dara and S. Fluhrer, “Fnr : Arbitrary length small domain block cipherproposal,” in Security, Privacy, and Applied Cryptography Engineering.Springer, 2014.[4] P. Paillier, in Proceedings of the 18th Annual International Conferenceon the Theory and Applications of Cryptographic Techniques, 1999.[5] Y. A. Boldyreva, N. Chenette and A. O’Neill, “Order-preserving sym-metric encryption,” in Proceedings of the 28th Annual International Con-ference on the Theory and Applications of Cryptographic Techniques.(EUROCRYPT), 2009.[6] C. Gentry, “Fully homomorphic encryption using ideal lattices.” inSTOC, vol. 9, 2009, pp. 169–178.[7] D. X. Song, D. Wagner, and A. Perrig, “Practical techniques forsearches on encrypted data,” in Security and Privacy, 2000. S&P 2000.Proceedings. 2000 IEEE Symposium on. IEEE, 2000, pp. 44–55.[8] https://github.com/cisco/libfnr.[9] https://tools.netsa.cert.org/silk/referencedata.html.[10] http://www.icir.org/enterprise-tracing/Overview.html.[11] T. Shimeall, S. Faber, M. DeShon, and A. Kompanek, “Using silkfor network traffic analysis,” tech. rep., CERT Network SituationalAwareness Group, Tech. Rep., 2010.

Efficient Format Preserving Encrypted Databases

Abstract

Similar works

Full text

Available Versions

Cryptology ePrint Archive