Một phần quan trọng trong thiết kế của CryptDB là tự động điều chỉnh lớp mã hóa trên máy chủ DBMS. Mục đích là để sử dụng các lược đồ mã hóa an toàn nhất mà có thể chạy các truy vấn được yêu cầu. Ví dụ, nếu ứng dụng không sinh ra truy vấn nào so sánh các mục dữ liệu trong một cột, hoặc sắp
39
xếp cột, cột phải được mã hóa với RND. Đối với những cột yêu cầu các equality check nhưng không yêu cầu inequality check, DET cũng đủ. Tuy nhiên, tập truy vấn không phải lúc nào cũng được biết trước. Do đó, chúng ta cần một lược đồ có khả năng thích ứng mà tự động điều chỉnh các mã hóa.
“Onions of encryption” – có thể hiểu là mã hóa nhiều lớp. Ý tưởng là mã hóa từng mục dữ liệu trong một hoặc nhiều onion: tức là, mỗi giá trị sẽ được bọc trong các lớp mã hóa ngày càng mạnh hơn. Mỗi lớp của mỗi onion cho phép mỗi loại chức năng như được chú thích. Ví dụ, các lớp ngoài cùng như RND và HOM cung cấp bảo mật tối đa, trong khi các lớp bên trong như OPE cung cấp nhiều chức năng hơn.
Hình 2.8 Các lớp mã hóa Onion và các lớp tính toán được phép.
Tên của Onion cho biết các phép toán chúng cho phép tại một vài lớp của chúng (Equality, Order, Search, và Addition). Trong thực tế cần nhiều onion, vì các phép toán được hỗ trợ bởi các lược đồ mã hóa khác nhau không luôn luôn theo thứ tự một cách hoàn toàn, và vì cần phải cân nhắc hiệu suất thực hiện (kích thước của bản mã và thời gian mã hóa cho các lớp onion lồng vào nhau). Phụ thuộc vào loại dữ liệu (và các chú thích (annotations) được cung cấp bởi nhà phát triển ứng dụng trên lược đồ cơ sở dữ liệu), CryptDB có thể không duy trì tất cả các onion cho mỗi cột. Ví dụ, Search onion không có ý nghĩa đối với các số nguyên (integers), và Add onion không có ý nghĩa cho
các chuỗi (strings).
Với mỗi lớp của mỗi onion, proxy sử sử dụng cùng một key cho các giá trị đang mã hóa trong cùng một cột, và các key khác nhau trên các bảng, các cột, các onion, và các lớp onion khác nhau. Việc sử dụng cùng một key cho tất cả các giá trị trên một cột cho phép proxy thực hiện các phép toán trên một cột mà không phải tính toán các key riêng biệt cho từng hàng. Việc sử dụng các
40
key khác nhau trên các cột ngăn chặn máy chủ tìm ra bất kỳ mối liên hệ bổ sung nào. Tất cả những key này được bắt nguồn từ masterk key MK. Ví dụ,
với bảng t, cột c, onion o, và lớp mã hóa l, proxy sử dụng key
Kt,c,o,l = PRPMK(bảng t, cột c, onion o, lớp l), (1)
với PRP là một hoán vị giả ngẫu nhiên – pseudo random permutation (ví dụ, AES)
Mỗi onion bắt đầu được mã hóa với lược đồ mã hóa an toàn nhất (RND cho onion Eq và Ord, HOM cho onion Add, và SEARCH cho onion Search).
Khi proxy nhận các truy vấn SQL từ ứng dụng, nó xác định xem các lớp mã hóa nào cần được gỡ bỏ. Để cho phép P trên cột c thực thi một truy vấn trên
máy chủ, proxy đầu tiên thiết lập lớp onion cần thiết để tính toán P trên c. nếu mã hóa của c không phải là đã ở một lớp onion mà cho phép P, proxy bóc
tách các lớp onion để cho phép P trên c, bằng cách gửi key onion tương ứng
tới máy chủ. Proxy không bao giờ giải mã dữ liệu qua các lớp onion mã hóa kém an toàn.
CryptDB thực hiện việc giải mã lớp onion sử dụng các UDF chạy trên máy chủ DBMS. Ví dụ, để giải mã onion Ord của cột 2 trong bảng 1 tới lớp
OPE, proxy sinh ra truy vấn sau tới server sử dụng DECRYPT_RND UDF: UPDATE Table1 SET
C2-Ord = DECRYPT_RND(K, C2-Ord, C2-IV)
với K là key phù hợp được tính toán từ phương trình (1). Tại cùng thời điểm, proxy cập nhật trạng thái bên trong của chính nó để ghi nhớ rằng cột
C2-Ord trong Table1 bây giờ đang ở lớp OPE trong DBMS.
Chú ý rằng việc giải mã onion được thực hiện toàn bộ bởi máy chủ DBMS. Trong trạng thái ổn định, việc giải mã ở phía máy chủ là không cần thiết bởi vì việc giải mã onion xảy ra chỉ khi một lớp tính toán mới được yêu cầu trên một cột. Ví dụ, sau một equality check được yêu cầu trên một cột và máy chủ đưa cột đó vào lớp DET, cột vẫn tồn tại trong trạng thái đó, và các truy vấn sau đó với các equality check không yêu cầu giải mã.
41