[cryptdb]2017/07/12--Guidelines for Using the CryptDB System Securely

## Guidelines for Using the CryptDB System Securely
### 1 Introduction
two goals:
- review guidelines for using the CryptDB system
- an unsafe usage of CryptDB(Inference attacks on property-preserving encrypted
databases)
### 2 Encryption schemes in CryptDB
![encryption schemes,security levels,and operations supported](https://leanote.com/api/file/getImage?fileId=5965eb99ab6441546100147e)

>strong encryption scheme  provide semantic security and protect against inference attacks even when an attacker has side information.
>HOM/DET/SEARCH encryption schemes are non-standard schemes,RND is standard.
> DET unique constraint(唯一性约束，不能有相同的值)
>
- client-side: an application + CryptDB proxy
- server-side:encrypted database

### 3 Guarantees
CryptDB provides guarantees only for columns marked 'sensitive',CryptDB will keep them encrypted with strong encryption schemes.
access-pattern leakage--> Oblivious RAM(ORAM) hiding such access patterns

### 4 Guidelines
- step 1: Mark as "sensitive" any column whose content you want to protect.
- step 2: Provide the query set to CryptDB
>确定应用种有多少种query types,Applications often have a relatively small set of query types;
TPC-C基准有30种查询
>CryptDB 并能满足所有的query type

- step 3: Address each unsupported query/operation with one or both of these options((如果不能满足的话，有两种方案)):
>第一种:不修改application，Run a part of the query in the proxy,using Monomi(出处：processing analytical queries over encrypted data)
第二种:修改application,removed the unsupported operation or handle in the application
不支持的query分为两种：一种是任何加密方案都不支持这种query，另外一种是某些column被标识为“sensitive”，所以这种query不被支持(这种情况比较少)

### 5 Functionality for "sensitive" fields
被标记为sensitive的fields，会采取strong encryption schemes，various operations(2中图片shows) that the server can compute directly on such fields in the databse.
有些操作直接在server做(select [...] where [...] )
有些操作在proxy(order by sensitive field)

### 6 Fields not marked "sensitive"
a field not marked as sensitive,CryptDB employs a "best-effort" approach using the most secure encryption scheme,weak encryption schemes such as OPE and DET for non-unique values

### 7 Unsafe usage in Naveed et al.
Naveed etc.al(Inference attacks on property-preserving encrypted databases) use OPE and DET(and no strong encryption) on medical application OpenEMR
the reasons of the unfound conclusions:
- do not mark any fields "sensitive"
- the authors do not actually evaluate CryptDB on OpenEMR(有些字段没破解出来)
OPE and DET leak is in fact not novel

信息安全从业人员^_^

导航

最近发表

友情链接