DBMask: Fine-Grained Access Control on Encrypted Relational Databases

DBMask: Fine-GrainedAccess Control on

Encrypted Relational Databases

Mohamed Nabeel, Muhammad I. Sarfraz,Jianneng Cao, Elisa Bertino

5th ACM Conference on Data and Application Security and PrivacySan Antonio, Texas, USA, March 2015

SWIM SeminarJuly 29th, 2015Mateus Cruz

Introduction Access Control Model Cryptographic Constructs Secure Query Evaluation Experiments Conclusion

OUTLINE

1 Introduction

2 Access Control Model

3 Cryptographic Constructs

4 Secure Query Evaluation

5 Experiments

6 Conclusion


OUTLINE

1 Introduction




5 Experiments

6 Conclusion


OVERVIEW

SQL queries over encrypted dataI Inspired by CryptDB1

Fine-grained access controlI Attribute-based group key management

1Popa et al., CryptDB: Protecting Confidentiality with EncryptedQuery Processing, SOSP 2011

1 / 28


REVIEW: CRYPTDBSQL queries over encrypted dataProxy controls accessLimitations

I Column-level as minimum granularityI Onions of encryption

– Decreasing security– Storage overhead

2 / 28


ARCHITECTURE

Adversary modelI Trusted and invulnerable data ownerI Trusted and vulnerable proxyI Passive vulnerable server

3 / 28


OUTLINE

1 Introduction




5 Experiments

6 Conclusion


ATTRIBUTE-BASED ACCESS CONTROL (ABAC)

Users have a set of identity attributesI Job, age, location

Data is associated with policiesI “Only managers older than 30 years old living

in Tokyo can access the data item X”

Users’ attributes have to satisfy the policies

4 / 28


DEFINITIONS

Attribute Condition: nameA op lI Attribute AI Comparison operator opI Value l

Policy: tuple (s, o)I Boolean expression sI Set of rows o

GroupI Users that satisfy the conditions in a policy

5 / 28


DEFINITIONS

Attribute Condition: nameA op l

role = doctor

I Attribute AI Comparison operator opI Value l

Policy: tuple (s, o)I Boolean expression sI Set of rows o

GroupI Users that satisfy the conditions in a policy

5 / 28


DEFINITIONS

Attribute Condition: nameA op lI Attribute AI Comparison operator opI Value l

Policy: tuple (s, o)I Boolean expression s

role = doctorOR

role = nurse

I Set of rows oGroup

I Users that satisfy the conditions in a policy

5 / 28


IDENTIFYING GROUPSExampleTwo access control policies (ACP) with attributeconditions:ACP1 = C1 ∧( C2 ∨ C3)ACP2 = C2Using the disjunctive normal form (DNF):ACP1 = (C1 ∧ C2) ∨ (C1 ∧ C3)ACP2 = C2Groups given by disjunctive clauses:G1 : C1 ∧ C2G2 : C1 ∧ C3G3 : C2

6 / 28


IDENTIFYING GROUPSExampleTwo access control policies (ACP) with attributeconditions:ACP1 = C1

level > 3

∧( C2 ∨ C3)ACP2 = C2Using the disjunctive normal form (DNF):ACP1 = (C1 ∧ C2) ∨ (C1 ∧ C3)ACP2 = C2Groups given by disjunctive clauses:G1 : C1 ∧ C2G2 : C1 ∧ C3G3 : C2

6 / 28


IDENTIFYING GROUPSExampleTwo access control policies (ACP) with attributeconditions:ACP1 = C1 ∧( C2

role = doctor

∨ C3)ACP2 = C2Using the disjunctive normal form (DNF):ACP1 = (C1 ∧ C2) ∨ (C1 ∧ C3)ACP2 = C2Groups given by disjunctive clauses:G1 : C1 ∧ C2G2 : C1 ∧ C3G3 : C2

6 / 28


IDENTIFYING GROUPSExampleTwo access control policies (ACP) with attributeconditions:ACP1 = C1 ∧( C2 ∨ C3

role = nurse

)ACP2 = C2Using the disjunctive normal form (DNF):ACP1 = (C1 ∧ C2) ∨ (C1 ∧ C3)ACP2 = C2Groups given by disjunctive clauses:G1 : C1 ∧ C2G2 : C1 ∧ C3G3 : C2

6 / 28


IDENTIFYING GROUPSExampleTwo access control policies (ACP) with attributeconditions:ACP1 = C1 ∧( C2 ∨ C3)ACP2 = C2Using the disjunctive normal form (DNF):ACP1 = (C1 ∧ C2) ∨ (C1 ∧ C3)ACP2 = C2Groups given by disjunctive clauses:G1 : C1 ∧ C2G2 : C1 ∧ C3G3 : C2

6 / 28


GROUP POSET

Partially ordered set (⊆)Hierarchical key management

I Parents can access children’s keys

Example

Conditions:G1: Doctors AND level > 3G2: Nurses AND level > 3G3: Doctors

7 / 28


KEY MANAGEMENT APPROACH

Combines broadcast and hierarchical keymanagementEfficiently handles user dynamics

I Granting or revoking access

8 / 28


KEY MANAGEMENT

Attribute-based Group Key ManagementI Easier re-keying

Users do not receive private keysI Secret sharing used to derive keys

9 / 28


AB-GKMAttribute-based Group Key ManagementPolicies are embedded in access trees

I Internal nodes represent threshold gates– “d-out-of-m” policies (threshold d)

I Leaves represent attributes

ExamplePolicy:(′′type = premium′′ ∨

(′′type = regular′′ ∧′′region = indiana′′),{new movie})

10 / 28


OUTLINE

1 Introduction




5 Experiments

6 Conclusion


NUMERICAL MATCHING

Compares encrypted numeric valuesAllows different approaches

I DeterministicI Order-preservingI Semantically secure

– Use trapdoors to make comparisons

11 / 28


KEYWORD SEARCH

Looks for words in an encrypted stringCan check for more than one wordCan check if two words are close

12 / 28


JOINS

Cannot match semantically secure valuesJOIN-SEM

I New column for blinded trapdoor valuesJOIN-DET

I Encrypts with deterministic encryption

13 / 28


OUTLINE

1 Introduction




5 Experiments

6 Conclusion


DBMASK EXECUTION FLOW

1 System initialization2 User registration3 Data encryption4 Query execution

14 / 28


SYSTEM INITIALIZATION

1 Data owner sets up the systemI Makes available public parametersI Allows proxy to generate trapdoorsI Identify and create groups of users

15 / 28


USER REGISTRATION

1 Users get their identity certifiedI Done by a trusted identity provider

2 Data owner distributes secretsI Only for valid and identified usersI Maintains a database of user-secret values

– Shared with proxy to allow decryption– Secrets are encrypted with users’ passwords

16 / 28


HANDLING USER DYNAMICS

Users can be added or deletedI Update the user-secret database

No need for re-keyingI The encrypted data remains the same

Example1 New user having the attribute role = doctor2 Data owner generates new secrets and

public information related to G2I Updates proxy and cloud serverI No effect on other groups

17 / 28


DATA ENCRYPTION

1 Encrypts each cell twiceI Fine-grained access controlI Privacy-preserving matching

2 Each column is expanded to twoI data-colI match-col

18 / 28


TABLE ENCRYPTION

19 / 28


QUERY EXECUTION1 User sends query to proxy2 Proxy parses query

I Removes certain clauses– ORDER BY, GROUP BY, HAVING, SUM

I Replaces columns’ namesI Computes trapdoors for secure

3 Cloud server executes queryI Sends encrypted results to proxy

4 Proxy process resultsI Generate keys for decryptionI Filters and aggregates resultsI Decrypts resultsI Send plaintext results to user

20 / 28


QUERY EXECUTION - EXAMPLE 1

ExampleInitial query made by a doctor (G3):SELECT ID, Age, DiagFROM Patient

Processed query:SELECT ID-enc, Age-enc, Diag-encFROM PatientWHERE Groups LIKE ’%G3%’

21 / 28



ExampleInitial query made by a doctor level 4 (G1,G3):

SELECT ID, Age, DiagFROM Patient

WHERE Age > 35ORDER BY Age ASC

22 / 28



ExampleProcessed query:SELECT ID-enc, Age-enc, Diag-encFROM PatientWHERE UDF Compare Num(Age-com,

PPNC.GenTrapdoor(35), ’>’)AND (Groups LIKE ’%G1%’ ORGroups LIKE ’%G3%’)

22 / 28


OUTLINE

1 Introduction




5 Experiments

6 Conclusion


ENVIRONMENT

C++, NTL and OpenSSLPostgres 9.1 extended with UDFsMachine

I 3.40GHz Intel i7-3770I 8GB RAMI Ubuntu 12.04

DatasetI TCP-C

23 / 28


IMPLEMENTATIONS

DBMask-SECI Maximum securityI Semantically secure encryption

– AES with blinding factor– Adds one more column for joins

DBMask-PERI Best performanceI Deterministic encryptionI OPE scheme for numerical comparison

– Order-preserving encryption

24 / 28


THROUGHPUT

30% overheadTrade-off: performance and security

25 / 28


LATENCY

44% increase on server sideProxy adds 4.3ms

I 24% for encryption and decryptionI 67% for query rewriting, parsing, processing

26 / 28


STORAGE

Increases space requirements by 3.2x

27 / 28


OUTLINE

1 Introduction




5 Experiments

6 Conclusion


CONCLUSION

Evaluates SQL queries on encrypted dataFine-grained access controlSecurity level does not change

I Unlike CryptDBFuture work

I Support more relational operationsI Optimization

28 / 28

Detailed Execution Flow ACV-BGKM Extra Examples

EXTRA SLIDES


QUERY EVALUATION FLOW

System initializationUser registrationData encryption and uploadData querying and retrieval


SYSTEM INITIALIZATION

1 The data owner (DO) runs the setupI Generation of security parameters

2 The DO send the parameters to the proxyI The proxy can generate trapdoors

3 The DO converts ACP into DNFI Create groups of users


USER REGISTRATION

1 Users get certified by an identity providerI Certified identity attributes are cryptographic

commitments

2 Users register with DO using OCBE3 The DO generates and distributes secretes

I Users only decrypt secrets with valid identities4 The DO has a database of user-secret values

I Shared with the proxyI Needs synchronization when changed


DATA ENCRYPTION

Each cell is expanded into threeI Fine-grained access control (data-col)I Privacy-preserving matching (match-col)I Assigned group labels (label-col)


label-col

Each cell is assigned group labelsGroups connected in the poset

I Assign the label of the less privileged group


data-col

Encrypt data with masterkey KI Generated from the keys of groups and public

informationI Prevents multiple encryptions


match-col

Encryption depends on the data typeI String (for keyword search)I Numerical


CELL-LEVEL ACCESS CONTROL


QUERYING

1 The user sends a query to the proxyI Plaintext query

2 The proxy parses and filters the queryI Remove certain clauses and aggregations

– E.g.: ORDER BY, SUM

3 Replace columns’ namesI Use data-col encrypted names

4 Add predicate to the WHERE clause thatdetermines the groups of the user

5 Send query to server for execution


RETRIEVAL

1 The server returns the results to the proxyI The results are encryptedI The public information is also transferred

2 The proxy applies the removed clausesI Performs aggregation using an in-memory

database of decrypted results

3 The final plaintext result is sent to the user


BGKM

Broadcast Group Key ManagementI Users have secrets to derive keys

Rekeying uses broadcastI Public information (PI) changesI Secrets of existing users remain the same

No need for private comm. channelsI Except during the first phase

Combination of secrets and PI gives keys


ACV-BGKM

Access Control Vector BGKMExecuted by a trusted key serverGroup of n users

I Usri, i = 1, 2, ...,nAlgorithms

1 Setup(`)2 SecGen()3 KeyGen(S)4 KeyDer(si,PI)5 Update(S)


SETUP(`)

Initialization of parametersI `-bit prime number qI Keyspace KS = Fq

– Fq is a finite field with q elementsI Maximum group size N (N ≥ n)I Cryptographic hash function

– H(·) : {0, 1}∗ → Fq

I Secret space SS = {0, 1}`I Set of issued secrets S = ∅


SECGEN()

1 Choose a secret si ∈ SSI si /∈ S

2 Add si to S3 Output si


KEYGEN(S)

Pick a random k ∈ KSChoose N random bit strings

I z1, z2, ..., zN ∈ {0, 1}`

Create an n× (N + 1) Fq-matrix

A =

1 a1,1 a1,2 · · · a1,N1 a2,1 a2,2 · · · a2,N... ... ... . . . ...1 an,1 an,2 · · · an,N

ai,j = H(si||zj), 1 ≤ i ≤ n, 1 ≤ j ≤ N, si ∈ S


KEYGEN(S)

Solve AY = 0I Y is a nonzero (N + 1)-dimensional Fq-vectorI Y is chosen from the nullspace of A

Construct the access control vector (ACV)I ACV = k · eT

1 + Y– k is the group key– e1 = (1, 0, ..., 0)

Defines the public informationI PI = 〈ACV, (z1, z2, ..., zn)〉

Outputs PI and k


KEYDER(si,PI)

Usri computes a key extraction vectorI vi = (1, ai,1, ai,2, ..., ai,N)I Unique row in the access matrix A

Usri derives key kI k = vi · ACV


UPDATE(S)

Run the KeyGen(S) algorithmOutput the new PI′ and the new key k′


EXAMPLE: ACCESS CONTROL MATRIX

ExampleUsers: U1,U2,U3

Access control matrix:

A =

1 1 1 1 11 1 2 3 41 4 3 2 1

Nullspace of A:N(A) = span{(1,−2, 1, 0), (2,−3, 0, 1)}


EXAMPLE: GENERATING PI

ExampleACV = k · eT

1 + Y, where AY = 0, e1 = (1, 0, ..., 0)and k is the group key

Using Y = (0, 1,−2, 1, 0) and k = 2:ACV = 2 · (1, 0, 0, 0, 0) + (0, 1,−2, 1, 0)ACV = (2, 1,−2, 1, 0)

Output the public information PI:PI = 〈ACV, (z1, z2, ..., zn)〉


EXAMPLE: DERIVING THE KEY

Examplek = vi · ACV

For user U1: k = (1, 1, 1, 1, 1) · (2, 1,−2, 1, 0) = 2For user U2: k = (1, 1, 2, 3, 4) · (2, 1,−2, 1, 0) = 2For user U3: k = (1, 4, 3, 2, 1) · (2, 1,−2, 1, 0) = 2


QUERY EXECUTION - EXAMPLE 3Original query made by a level 4 doctor (G1 and G3):

Maximum Security:

Best Performance:



Original query made by a doctor (G3):

Maximum Security:

Best Performance:

Internet

DBMask: Fine-Grained Access Control on Encrypted Relational Databases