CryptDB - Đảm bảo an toàn cho cơ sở dữ liệu trong điện toán đám mây

I.Giới thiệu
Điện toán đám mây được định nghĩa chi tiết tại website của NIST [1]. Trong công việc của chúng tôi, chúng
tôi đơn giản định nghĩa điện toán đám mâ như là một phân phối của các nguồn tài nguyên điện toán theo nhu
cầu được đặt tại các máy chủ từ xa. Thông qua việc đánh giá các công cụ và kết nối băng thông rộng, điện toán
đám mây đang nhận được sự chấp nhận nhiều hơn từ người dùng [2], vì nó giảm thiểu chi phí và nâng cao tính
di động [5].
Với sự phổ biến ngày càng tăng của điện toán đám mây vấn đề về an ninh cũng tăng lên [3][4]. Các tổ chức
xem xét chuyển đổi sang các dịch vụ dựa trên đám mây cũng phải xem xét và hiểu các vấn đề về an ninh, riêng
tư, độ tin cậy và pháp lý. Các cơ quan nghiên cứu quan trọng nhận thức những rủi ro này và đã đưa ra các báo
cáo [6], [7], [8], [9]. Theo Gartner, các nguy cơ bảo mật điện toán đám mây có thể tóm tắt thành bảy loại sau:
“Đặc quyền truy cập người dùng, Tuân thủ quy định, Vị trí dữ liệu, Phân tách dữ liệu, Phục hồi, Hỗ trợ điều tra,
Khả năng tồn tại dài hạn” [6]. Các vấn đề an ninh được điều tra sâu hơn dưới hai đối tượng chính cụ thể, “mất
kiểm soát dữ liệu” và “sự phụ thuộc vào nhà cung cấp điện toán đám mây” [15].
Các cơ sở dữ liệu từ bên ngoài (outsourcing) vào đám mây có thể nâng cao mức độ sẵn sàng, mạnh mẽ, đàn
hồi và hiệu quả cũng như hạn chế tối đa các lý do thuộc hành chính. Tuy nhiên dữ liệu trong đám mây có thể bị
nhà cung cấp đám mây truy cập. Vì thế, nhà cung cấp đám mây, nhân viên của mình hoặc thậm chí các nhà thầu
phụ có thể cố tình hoặc vô tình truy cập vào dữ liệu của khách hàng. Để đảm bảo tính bảo mật của dữ liệu về
mặt kỹ thuật, dữ liệu có thể được mã hóa trước khi được đưa vào cơ sở dữ liệu thuê bên ngoài. Tuy nhiên, việc
thực thi các truy vấn như một bí mật tính toán hoàn hảo trên một dữ liệu mã hóa không thể được tạo ra một cách
hiệu quả. Việc thực hiện các tính toán không bình thường với dữ liệu trên đám mây như tìm kiếm, chuyển đổi,
lựa chọn, và quyết định kiểm soát truy cập là có ích. Mã hóa thông thường ngăn chặn xử lý dữ liệu này trên đám
mây. Genrty đã giải quyết một vấn đề ba mươi năm chờ đợi trong mật mã [14]. Ông ta đã giải thích một lược đồ
mã hóa mới có thể cho phép xử lý trên dữ liệu mã hóa. Tuy nhiên lược đồ mã hóa này là xa với thực tế. DARPA
tách 20 triệu đô để tìm kiếm vấn đề này của mật mã như là một giải pháp thiết thực [16]. Popa và bạn bè của
mình từ MIT đã mang đến một giả pháp thiết thực để xử lỹ cơ sở dữ liệu mã hóa [10]. Bài viết này tập trung vào
công việc của họ chi tiết hơn và những điểm yếu trong công việc của họ.

A.Công việc liên quan
Các nhà nghiên cứu đang cố gắng tìm ra các giải pháp để giữ dữ liệu trên đám mây được bí mật. Việc xử lý
dữ liệu an toàn trên đám mây là phức tạp. Trong phần này, chúng tôi sẽ đưa ra một số cách tiếp cận nổi tiếng để
giải quyết tính toán an toàn trên đám mây.

Mã hóa đồng cấu đầy đủ - Fully homomorphic encryption. Như đã đề cập trong phần trước, dữ liệu có thể
được mã hóa trước khi tải lên đám mây. Tuy nhiên, việc sử dụng lược đồ mã hóa thông thường, dữ liệu không
thể đươc truy cập trên đám mây. Trong trường hợp này, đám mây chỉ có thể được sử dụng với mục đích lưu trữ.
Mã hóa đồng cấu có thể khắc phục hạn chế này tới một mức nhất định, cho phép các phép toán logic trên bản
mã mà không cần giải mã. Mã hóa đồng cấu như Paillier hoặc ElGamal cho phép chỉ một phép toán, cụ thể là
cộng hoặc nhân [25][26]. Các lược đồ mã hóa đồng cấu đầy đủ cho phép cộng và nhân trên bản mã, cho phép
một máy chủ không đang tin cậy thực hiện tính toán tùy ý trên dữ liệu mã hóa thay mặ cho một client mà không
cần giải mã. Cụ thể, sử dụng các lược đồ mã hóa đồng cấu đầy đủ nhà cung cấp đám mây có thể chay bất cứ
chương trình nào client mong muốn mà không đạt được bất kỳ thông tin nào về các bản rõ. Lược đồ má hóa
đồng cấu đầy đủ được phát minh lần đầu tiên bởi Gentry vào năm 2009 [14]. Không may, ngày nay không có
lược đồ thực tế nào sử udngj mã hóa đồng cấu đầy đủ nhưng rất nhiều công việc đang được thực hiện trong lĩnh
vực này, một vài trong số chính hứa hẹn dành cho điện toán đám mây [20].


CryptDB: một mô hình kẻ tấn công yếu hơn – a weaker attacker model. CryptDB [10] là một triển khai cho
phép xử lý truy vấn trên các cơ sở dữ liệu mã hóa. Cơ sở dữ liệu được quản lý bởi nhà cung cấp đám mây,
nhưng các mục cơ sở dữ liệu được mã hóa với khóa mà chỉ người sở hữ dữ liệu biết. Các truy vấn SQL chạy
trên cơ sở dữ liệu mã hóa sử dụng một tập các phép toán như equality check và order comparison. CryptDB sử
dụng các lươc đồ mã hóa cho phép các so sánh như vậy được thực hiện trên bản mã. CryptDB đại diện một mô
hình tấn công yếu vì nó giả định sự tồn tài của một máy chủ và proxy ứng dụng tin cậy dựa trên đám mây.
Tuy nhiên, CryptDB đại diện một vị trí thú vị về sự đánh đổi (trade-off) giữa chức năng và bảo mật từ các
nhà cung cấp đám mây. Trong bài viết này, chúng ta sẽ đi vào chi tiết hơn về CryptDB.
Sự thu hồi thông tin riêng tư - Private Information Retrieval. Để cho phép tìm kiếm trên cơ sở dữ liệu từ xa
Secure Multi-party Computation cũng có thể được sử dụng [19], [21], [24]. Những lược đồ này đã được sử dụng
trong thực tế và do đó, có thể hứa hẹ giải quyết các vấn đề điện toán đám mây trong tương lai gần [22], [23].
Các cơ chế Private Information Retrieval giải quyết vấn đề với sự riêng tư tuyệt đối (ví dụ, [17]). Curtmola đề
xuất hai lược đồ chống lại đối thủ không thích ứng (non-adaptive) và thích ứng (adaptive) với một hiệu suất tốt
[18].

B.Sự đóng góp

Sự đóng góp chính của bài viết này là cung cấp phân tích chi tiết về CryptDB. Để dễ hiểu đầu tiên chúng tôi
mô tả CryptDB với giải thích chi tiết hơn. Tiếp theo, chúng tôi mô tả cấu chúc máy chủ của CryptDB và chúng
tôi phân tích Proxy Server. Không may, bài viết ban đầu không giải thích thuật toán tìm kiếm, do đó chúng tôi
mở rộng thuật toán tìm kiếm của CryptDB. Chúng tôi cho thấy rằng thuật toán tìm kiếm hiện tại là không đủ để
đám ứng tất cả các truy vấn tìm kiếm. Chúng tôi nhấn mạnh những điểm an toàn và hiệu quả của CryptDB.
Cuối cùng, chúng tôi trình bày một vài nhận xét và mở rộng khu vực nghiên cứu cho CryptDB.

II.Kiến trúc CryptDB
A.Mã hóa lớp - Layered Encryption
Mã hóa dữ liệu trên cơ sở dữ liệu được tính toán theo lớp. Có 4 mục tiêu chính khác nhau để đạt được, và với
mỗi mục tiêu tồn tại một “nhân” được bao bọc bởi các lớp khác nhau, được gọi là onion [11]: EQ, ORD,
SEARCH và ADD onion. EQ onion nhằm mục đích điều chỉnh các lớp cho các truy vấn equality, trong khi
ORD onion nhằm mục đích ddiefu chỉnh sự rò rỉ thứ tự cho các truy vấn so sánh (comparison), SEARCH onion
được sử dụng để tìm kiếm một đoạn van bản trong cơ sở dữ liệu mà không làm rò rỉ bất kỳ thông tin gì. Onion
này không cho phép thực thi các giá trị nguyên (integer values). Cuối cùng Add onion nhằm mục đích cộng
(add) các giá trị mã hóa mà chỉ hỗ trợ các giá trị nguyên. Các onion này có các lớp khác nhau và mỗi lớp được
mã hóa sử dụng các thuật toán khác nhau. Hơn nữa, những thuật toán này có các mức độ an toàn khác nhau với
các lớp bên ngoài của một onion sẽ bảo mật hơn các lớp bên trong. Hơn nữa, một giá trị chỉ có một lớp hiện tại
trong mỗi onion. Một khi cơ sở dữ liệu được tạo ra, tất cả các onion sẽ ở tại lớp an toàn nhất.
Các truy vấn được xử lý như các cột trong cơ sở dữ liệu, do đó, CryptDB cũng là hướng cột (columnoriented). Nếu một giá trị cần được giải mã tới lớp yếu hơn, thì toàn bộ cột sẽ được giải mã. Tuy nhiên, nó khiến
cho rò rỉ nhiều thông tin hơn yêu cầu. Nếu chúng ta cần một giá trị ở lớp yếu nhất, toàn bộ cột sẽ tại lớp đó và
rò rỉ thông tin. Và cũng lưu ý rằng lớp trong cùng là lớp yếu nhất, nhưng nó cũng không tiết lộ bất kỳ bản rõ
nào cho máy chủ DBMS. Lớp bên trong của các onion là Equi-JOIN, OPE-JOIN, SEARCH và HOM không
bao giờ được gỡ bỏ.


Hình 1. EQ Onion
Tai lớp an toàn nhất của EQ onion là lớp RND. Lớp RND này mã hóa mỗi giá trị với AES (thuật toán
Rjindaels) trong chế độ CBC. Với số nguyên, Blowfish trong chế độ CBC thích hợp hơn vì kích thước khối 64
bit của nó thay vì kích thước khối 128 bit sẽ giảm độ dài của bản mã. Giá trị khởi tạo cho cả hai loại mã hóa là

các giá trị được chọn ngẫu nhiên. Mỗi giá trị được mã hóa thành các bản mã khác nhau kể khi bản rõ là như
nhau. Vì lý do này, lớp RND không thể bị tấn công lựa chọn bản rõ thích ứng. Tuy nhiên, lược đồ này không
cung cấp chức năng hiệu quả.
Khi cần thiết thực hiện equality check, Lớp RND cần được loại bỏ. Lớp bên trong tiếp theo của EQ onion là
lớp DET. Lớp này là lớp bất định (derministic layer). Sau khi mã hóa được thực hiện, nếu hai giá trị giống nhau,
thì bản mã tương ứng của chúng cũng giống nhau.
Với các giá trị trong cùng một cột, hai lớp RND và DET đủ để xử lý các truy vấn. Tuy nhiên, một vài truy
vấn cần kiểm tra sự bằng nhau (equality) của hai cột khác nhau hoặc hai cột khác nhau của các bảng khác nhau.
Đối với những trường hợp này, lớp hiện tại cần được cập nhật lớp Equi-JOIN. Trong lớp này, JOIN-ADJ được
nối với mã hóa của lớp DET.
JOIN = JOIN-ADJ||DET

JOIN-ADJ cho phép máy chủ DBMS điều chỉnh key của từng cột tại thời gian chạy. Bằng cách nào đó một
băm có khóa (keyed hash) với thuộc tính bổ sung mà băm có thể được điều chỉnh để thay đổi key của chúng mà
không truy cạp tới bản rõ. JOIN-ADJ là một hàm bất định đồng thời cũng chống đụng độ (192-bit), không khả
nghịch (non-invertible), và bắc cầu. Hàm JOIN-ADJ được định nghĩa dưới đây:

Đường cong Elliptic (ECC) được sử dụng như một thuật toán. K là khóa khởi tạo ban đầu cho bảng, cột,
onion, và lớp đó. P là một điểm trên đường cong elliptic, là một tham số public. PRF là một hàm giả ngẫu nhiên
(pseudorandom function) ánh xạ các giá trị tới một số giả ngẫu nhiên (pseudoramdom number). Như
AESK0(SHA(value)). K0 là khóa như nhau cho tất cả các cột và được sinh ra từ Master Key.
Lũy thừa thực tế là phép cộng hình học được lặp đi lặp lại của các điểm đường cong elliptic, và nó nhanh
hơn so với lũy thừa RSA. Proxy tính toán ΔK=K/K’ và gửi nó cho máy chủ DBMS. Máy chủ DBMS sử dụng


một UDF để giúp chúng chia sẻ cùng một JOIN-ADJ bằng cách tính toán dưới đây với các giả định là cột c có
K và cột c’ có K’ là khóa tại lớp JOIN-ADJ.

Bằng cách sử dụng UDF thích hợp, JOIN-ADJ của hai cột khác nhau sẽ trở nên giống nhau. Do đó nó có thể
so sánh bình đẳng bằng cách nhìn vào JOIN-ADJ. Vì lớp DET sử udngj các khóa khác nhau cho từng cột cho

tương quan giữa các cột. An toàn của lược đồ này dựa vào Elliptic-Curve Decisional Diffie Hellman.

Hình 2 ORD Onion
ORD onion. Lớp an toàn nhất của ORD onion giống như EQ onion, là lớp RND. Lớp bên trong của RND
cho ORD onion là lớp OPE. Các thuật toán mã hóa duy trì thứ tự không có đủ an toàn và hiệu quả cho đến bây
giờ. Trong bài viết gốc của CryptDB [10], các tác giả không xem xét mã hóa duy trì thứ tự nhưng sau đó họ đưa
ra vấn đề này trong bài viết “An Ideal Security Protocol for Order-Preserving Encoding” [11].
Thông tin hạn chế được đưa ra về onion này trong bài viết của CryptDB [10]. Nếu mã hóa của x nhỏ hơn mã
hóa của y, thì giá trị x cũng nhỏ hơn giá trị y. Nếu chúng ta tìm ra bất kỳ giá trị được mã hóa nào gữa hai mã hóa
này, thì bản rõ cũng sẽ nằm giữa x và y. Cụ thể, lược đồ này rò rỉ thứ tự, do đó, nó là một lược đồ yếu hơn khi
được so sánh với sự rò rỉ của equality.
Đối với các giá trị tại cùng một cột, lớp này là đủ để xử lý các truy vấn, nhưng nếu hai cột khác nhau được so
sánh để kiểm tra thứ tự, thì chúng ta cần tháo bỏ lớp OPE, và đạt tới lớp OPE-JOIN. Lớp này thiếu tính chức
năng hơn lớp EQUI-JOIN của EQ onion. Để điều chỉnh hai cột là không thể vì sự thiếu hiệu quả của các thuật
toán duy trì thứ tự. Có hai giải pháp. Giải pháp đầu tiên là, ứng dụng sẽ khai báo các cột có thể được kết nối, và
trong khi sắp xếp các khóa, cùng một khóa sẽ được sử dụng cho những cột này. Nó không hợp lý trong hầu hết
tình huống khai báo trước. Giải pháp thứ hai là cùng một khóa sẽ được sử dụng cho tất cả các cột tại lớp này.
Giải pháp này cũng không phải là giải pháp tốt. May thay, các range join không được sử dụng quả nhiều.


Hình 3 SEARCH & ADD Onions
SEARCH & ADD onions. SEARCH onion chỉ có một lớp, vì thế không có quá trình giải mã nào cho onion
này. SEARCH onion có một giá trị, và lớp SEARCH trong đó bao gồm giá trị này. Thuật toán tìm kiếm được sử
dụng trong CryptDB là thuật toán tìm kiếm của Song được mô tả trong phần III-D. Mục đích của SEARCH
onion là tìm kiếm các giá trị mã hóa bên trong một bảng mã hóa.
ADD onion cũng tương tự như vậy. Lớp HOM là lớp duy nhất của ADD onion. Mục đích của onion này là
cung cấp một số chức năng với các giái trị mã hóa mà không truy cập bản rõ. Điều này có thể đạt được với mã
hóa đồng cấu (homomorphic encryption). Thuật toán được sử dụng cho mã hóa đồng cấu của CryptDB là thuật
toán của Paillier.

B.Mã hóa có thể điều chỉnh - Adjustable Encryption
Nếu chúng ta giữu tất cả các lớp cho từng onion, đó không phải là cách tốt. Vì nếu lớp yêu snhaats được đưa
ra, các lớp khác không cần thiết tạo ra. Tuy nhiên, nếu chúng ta sử dụng một lớp cho từng onion, khó đẻ biết
trước được lớp an toàn nhất đáp ứng nhu cầu của chúng ta. Vì lý do này, yêu cầu phải điều chỉnh lớp hiện tại
một cách tự động mà không rò rỉ dữ liệu. Vấn đề này được giải quyết với chức năng điều chỉnh. Có các onion
khác nhau cho các mục đích khác nhau. Tất cả các onion này được đưa vào bảng. Tùy theo mục đích của chúng
ta, chúng ta chọn onion, và sử dụng nó. Và mỗi giá trị được mã hóa với tất cả các lớp ngoài, bắt đầu từ yếu nhất
tới an toàn nhất. Với cách tiếp cận này, nếu không truy vấn nào yêu cầu các lớp yếu hơn, thì các lớp này sẽ
không được sử dụng.
Với mỗi cột trong một bảng, cùng môi khóa được sử dụng để mã hóa các giá trị bên trong, nhưng với các
bảng, cột, onion và lớp khác nhau, các khóa khác nhau được sử dụng. Khóa được thực hiện với một hoán vị giả
ngẫu nhiên (pseudorandom permutation) như sau:
Key = PRPMK(bảng t, cột c, onion o, lớp l)

Ban đầu, tất cả các onion đều ở lớp an toàn nhất là lớp RND, HOM hoặc SEARCH. Nếu cần đến equality
hoặc order, lớp ngoài sẽ được giải mã. Giải mã này không cung cấp bản rõ do mã hóa nhiều lớp. Các lớp còn lại
vẫn không được giải mã để giữ dữ liệu an toàn. Hơn nữa, các lớp yếu nhất là OPE-JOIN, Equi-JOIN, SEARCH,
và ADD không bao giờ được gỡ bỏ.

C.Hàm người dùng định nghĩa - UDF: User-Defined Function
Một chức năng chứa các hướng dẫn để thực hiện một tác vụ cụ thể, và cung cấp để lặp lại tác vụ này dễ dàng.
Hàm người dùng định nghĩa cũng là một chức năng, và nó được tạo bởi người dùng. Người dùng này cần có
quyền để thực hiện các tiến trình trong cơ sở dữ liệu, hoặc người sở hữu cơ sở dữ liệu (database owner – dbo)
có thể được sử dụng. dbo là một người dùng có thể thực hiện tất cả các hoạt động trên cơ sở dữ liệu.
Nếu chúng ta có một bảng được gọi là Square có hai cột là EdgeLength và Number, thì chúng ta có thể tạo
một UDF để tính toán diện tích của các hình vuông bên trong cơ sở dữ liệu. Ví dụ bảng Square trong Table I.


Không cần thiết phải giữ các giá trị diện tích thêm vào cơ sở dữ liệu. Chúng ta có thể tạo một UDF, và gọi nó
khi cần tính toán diện tích. Đây là một ví dụ tạo một UDF.

CREATE FUNCTION dbo.area (edge FLOAT) RETURNS FLOAT RETURN(edge * edge);

Một truy vấn ví dụ để sử dụng UDF này có thể giống như sau:
SELECT Number, area (Edge Length) AS Area FROM Square;

Kết quả trả về sẽ giống Table II

Thay vì giữ dữ liệu cho từng thông tin có thể được yêu cầu, sẽ tốt hơn khi tạo một UDF, và gọi nó bất cứ khi
nào tác vụ cần. Trong CryptDB, UDF cũng là một yêu cầu. Việc giải mã của kiến trúc lớp để điều chỉnh lớp
hiện tại được thực hiện bằng cách sử dụng các UDF. Và cập nhật trạng thái hiện tại của các lớp onion cũng được
thực hiện bằng cách sử dụng các UDF. Việc thay đổi tất cả cơ chế cơ sở dữ liệu hiện tại là khó đạt được. Do đó,
các UDF rất quan trọng đối với các chức năng bổ sung trong hệ thống cơ sở dữ liệu.

D.Cấu trúc máy chủ trong CryptDB - Server Structure in CryptDB
Trong các hệ thống cơ sở dữ liệu, người dùng yêu cầu một vài thông tin hoặc chức năng từ các ứng dụng.
Các truy vấn SQL được sử dụng để đám ứng chu cầu của người dùng. Các máy chủ ứng dụng gửi các truy vấn
tới máy chủ DBMS. Máy chủ DBMS xử lý và phản hồi tập kết quả. Hệ thống này có thể bị kẻ xấu tấn công
hoặc nghe trộm. Các máy chủ DBMS cũng tò mò về các truy vấn và theo dõi các truy vấn với kết quả của
chúng. Khả năng khác là truy cập vật lý và đĩa có thể gây mất trộm dữ liệu. Trong CryptDb, cơ chế của các truy
vấn là tương tự, nhưng kiến trúc máy chủ một cách nào đó thay đổi , và một máy chủ bổ sung được gọi là Proxy
Server được thêm vào hệ thống cơ sở dữ liệu.
Nó giả định rằng tất cả truy vấn từ máy chủ ứng dụng được thực hiện bởi Proxy Server, và gửi tới DBMS
Server sau khi sửa đôi. Mục đích là giữ thông tin vô nghĩa tại phía DBMS Server để ngăn chặn những người


quản trị cơ sở dữ liệu tò mò dòm ngó tới nội dung của các bảng trong cơ sở dữ liệu của nó [27]. Vì lý do này,
chúng ta cần làm cho toàn bộ dữ liệu trở nên vô nghĩa.
Điều đầu tiên là tạo một bảng để giữ một vài dữ liệu bên trong cơ sở dữ liệu của DBMS Server. Trong
CryptDB, bảng của DBMS Server hoàn toàn khác với bảng thực. Proxy Server thay đổi tên bảng. Sau đó, tùy
theo loại của cột (ví dụ int, varchar), sẽ được đưa vào các onion có thể. Proxy Server giữ tất cả các dữ liệu của

onion có thể trong các cột khác nhau một cách riêng biệt trong bảng này. Table III là một ví dụ đơn giản.
Bảng được tạo mới từ Table III bởi Proxy Server được thể hiện trong Table IV.

Điều thứ hai là thêm các trường hợp (instances) vào các bảng hiện tại. Tên của các cột được thay đổi, và mỗi
giá trị trong bảng được mã hóa tùy theo thuật toán của lớp onion của nó. Ví dụ, nếu lớp hiện tại của EQ onion là
RND, và truy vấn thực hiện equality, thì từng giá trị trong cột tương ứng sẽ được mã hóa với AES trong chế độ
CBC. Hoặc thuật toán của Paillier sẽ được sử dụng để mã hóa các giá trị thuộc về lớp HOM của ADD onion.
Tất cả những tiến trình mã hóa này được thực hiện bởi Proxy Server.
Khi một truy vấn đến Proxy Server, nó thay đổi truy vấn, Trước hết, Proxy Server quyết định onion nào được
sử dụng cho truy vấn này. Proxy Server có các bảng thêm, một trong số chúng là để giữ trạng thái hiện tại của
từng onion của từng cột. Sau khi quyết định onion của truy vấn, Proxy Server nhìn vào bảng này, và kiểm tra
xem bảng hiện tại của onion có đang ở lớp cần thiết cho truy vấn này không. Nếu không, Proxy Server gọi UDF
chịu trách nhiệm gỡ bỏ lớp hiện tại đến lớp cần thiết. Sau quá trình này, Proxy Server thay đổi truy vấn, và gửi
nó nó DBMS Server. Toàn bộ dữ liệu được lưu trữ trong cơ sở dữ liệu của DBMS Server đã được mã hóa, và
các truy vấn không có ý nghĩa đối với người quản trị cơ sở dữ liệu.
DBMS Server xử truy vấn đã được sửa đổi, và trả về một kết quả đã mã hóa cho Proxy Server. Proxy Server
lấy các giá trị mã hóa, và giải mã chúng, và gửi cho Application Server. Application Server không quan tâm đến
bất kỳ quá trình mã hóa nào, nó chỉ gửi bản rõ gốc, và lấy kết quả, và cung cáp dịch vụ cho các client với những
kết quả này. Cấu trúc máy chủ cơ bản của CryptDB là như vậy.

III.Một ví dụ đơn giản
Trong phần này chúng tôi mô tả một ví dụ để giải thích cấu trúc cơ bản của CryptDB. Có một nguyên tắc
trong ví dụ của chúng tôi, không có sửa đổi hoặc hạn chế nào được thực hiện theo nguyên tắc. Từng bảng chỉ có
một Master Key viết tắt là MK trong suốt bài viết. Chúng tôi có một bảng ví dụ gọi là Students. Bảng này có
một Master Key. Như đã đề cập trong phần II-B, từng lớp của từng onion của từng cột của từng bảng có các
khóa khác nhau theo công thức sau:
Key=PRPMK(table t, column c, onion o, layer l)


A.Các truy vấn an toàn nhưng không có chức năng

Sau khi đọc bài viết về CryptDB [10], thậm chí nếu dễ dàng hiểu cấu trúc, nó vẫn khó có thể kết hợp cơ chế
CryptDB với các truy vấn SQL. Vì lý do này, chúng tôi minh họa một ví dụ để làm rõ các bước chi tiết hơn.
Bảng Studens có hai cột là ID và Name. Cột ID có giá trị nguyên trong khi cột Name có giá trị là chuỗi.
Bảng Students được tạo ra bằng câu lệnh sau:
CREATE TABLE Students (ID int, Name varchar(255));

Sau khi tạo bảng, chúng ta chèn một vài giá trị như sau:
INSERT INTO Students VALUES(1, “Alice”);
INSERT INTO Students VALUES(2, “Bob”);
INSERT INTO Students VALUES(3, “Eve”);

Khi chúng ta chạy tất cả các truy vấn này, Application Server tạo Table V. bảng này có dữ liệu thô, vì vậy nó
không phải là cách tốt để lưu trữ bảng này trong cơ sở dữ liệu của DBMS Server cho lý do an ninh. Cụ thể,
Proxy Server tạo một bảng đã mã hóa mới cho DBMS Server. Bảng mã hóa được tạo mới sẽ như Table VI.

Vì loại dữ liệu của cột ID là nguyên, SEARCH onion không dùng cho cột này. Hơn nữa, vì loại dữ liệu của
cột Name là chuỗi, HOM onion cũng không dùng cho cột này. Như đã mô tả từ trước trong phần II, tất cả các
lớp sẽ ở lớp mã hóa an toàn nhất lúc đầu. Có bảy lớp. Các lớp an toàn nhất của các onion là ba lớp RND,
SEARCH và HOM. Tuy nhiên, chúng cũng có ít chức năng nhất. Ví dụ, lớp RND không rò rỉ bất kỳ dữ liệu
nào, nhưng nó không có chức năng hiệu quả. Nếu chúng ta quay trở lại ví dụ, bằng cách sư rdungj lớp an toàn
nhất, chúng ta có thể chạy các truy vấn như SELECT * FROMStudents;”, “SELECTNameFROMStudents;”
Chú ý rằng Proxy phải thay đổi các truy vấn để bảo vệ nội dung bảng gốc. Nếu chúng ta tiếp tục với truy vấn
“SELECT Name FROM Students;”, truy vấn được thây đổi sẽ như sau:
SELECT C2-IV, C2-Eq FROM DBMS_Table1;

DBMS Server sẽ xử lý truy vấn này, và trả về kết quả trong Table VII


Bảng tương ứng khi Proxy Server giải mã và gửi cho Application Server sẽ giống như Table VIII

Truy vấn này trả về kết quả mà không có chức năng nào. Tuy nhiên, không có sự thay đổi nào tại bản rõ
trong bảng của DBMS Server. Bạn chỉ có thể đọc dữ liệu trả về, nhưng nói chung các truy vấn đến Application
Server yêu cầu một số chức năng như cập nhật dữ liệu, lựa chọn và hiển thị một vài hàng cụ thể của bảng, tính
trung bình của một cột.

B.Các truy vấn với equality leakage
Lưu ý rằng equality trong cơ sở dữ liệu là một tính năng quan trọng và thường xuyên được sử dụng nhất. Ví
dụ các ID của những sinh viên đạt điểm AA từ một bài giảng tại một trường đại học, tên của các khách hàng
mua một sản phẩm cụ thể trong một trung tâm mua sắm và só điện thoại của người gửi hàng với địa chỉ nhận bị
sai có thể được giải quyết bằng tính năng equality. Nếu chúng ta quay lại với ví dụ, chúng ta có thể tạo các truy
vấn SQL như sau:
SELECT name FROM Students WHERE id = 1;

Proxy Server sẽ lấy truy vấn này, và sửa đổi nó theo chức năng mong muốn. Lớp mã hoa của cột được tính
toán được kiểm tra xem lớp hiện tại có phải là lớp có thể đám ứng truy vấn được yêu cầu không. Nếu không,
Proxy Server gửi một truy vấn UPDATE. Truy vấn UPDATE này cung cấp để điều chỉnh lớp hiện tại của cột
này với các khóa đã cho từ Proxy Server. Trong ví dụ của chúng ta, chúng ta cần sử dụng một UDF để bóc lớp
RND thành lớp DET. Lý do là, nếu chúng ta muốn biết bằng nhau của hai dữ liệu tại cùng cột, chúng ta cần sử
dụng mã hóa tất định (deeterministic encryption). Nếu chúng ta giả sử STRIP_RND là một UDF lấy lớp RND
và giải mã nó thành lớp DET, sau đó Proxy Server sẽ gửi truy ván UPDATE dưới đây đầu tiên. Truy vấn này sẽ
gửi khóa mã hóa tới DBMS Server, và DBMS Server có thể gỡ bỏ lớp RND.
UPDATE DBMS_Table1 SET C1-Eq

= STRIP_RND (Key, C1-IV,C1-Eq);

Nhớ lại rằng khóa thu được từ phương trình sau:


Key = PRPMK(table t, column c, onion o, layer l)

Sau khi thực thi UDF, cột C1-Eq đang tại lớp DET, và Proxy Server sẽ cập nhật trạng thái onion hiện tại của
cột này là lớp DET.
DecryptKey(C1-IV, C1-Eq) là cấu trúc của hàm giải mã. Key là khóa giải mã của lớp RND cho cột đầu tiên
của bảng Students. Giả sử rằng giải mã cột này được cho như sau:
DecryptKey(q39f, ge88) = djes
DecryptKey(c8x3, 8n4o) = ektd
DecryptKey(sk7x, x7wk) = 3kw7

Sau khi sửa đổi cơ sở dữ liệu của DBMS Server, Application Server sẽ thay đổi truy vấn cho DBMS như sau:
SELECT C1-IV, C1-Eq FROM DBMS_Table1 WHERE C1-Eq = djes;

Key1 là khóa mã hóa của lớp JOIN cho cột C1 của DBMS_Table1. Và Key2 cũng là khóa mã hóa của lớp
DET cho cột C1 của DBMS_Table1. Sau đó mã hóa của một giá trị sẽ được tạo ra bằng cách mã hóa tất cả các
lớp cho tới lớp hiện tại. Ví dụ, mã hóa giá trị nguyên 1 sẽ được tạo ra như sau:
EncKey2 (EncKey1 (1)) = djes

Trong phần này, chúng ta bị rò rỉ thông tin của các cột được yêu cầu equality check. Nếu dữ liệu trong cùng
một cột có cùng giá trị, bản mã của cơ sở dữ liệu của DBMS Server sẽ giống nhau.

C.Các truy vấn với order leakage
Mã hóa duy trì thứ tự (Order preserving encryption) là một vấn đề khó khăn trong các cơ chế tìm kiếm riêng
tư bao gồm CryptDB. Trong bài viết gốc về CryptDB [10], các tác giả không xem xét mã hóa duy trì thứ tự một
cách chi tiết, nhưng sau đó nhấn mạnh vấn đề này trong một bài viết khác [11]. Phần này có thể được tóm tắt
như sau, nếu giá trị mã hóa của x nhỏ hơn giá trị mã hóa của y, thì ta biết được rằng giá trị x nhỏ hơn y. Nếu
chúng ta tìm ra bất kỳ giá trị mã hóa nào nằm giữa hai giá trị mã hóa này, thì dạng giải mã sẽ nằm giữa x và y.
Lược đồ này để lộ thứ tự, nó là lược đồ yếu nhất. các truy vấn “lớn hơn”, “nhỏ hơn”, ORDER BY, SORT,
MAX, MIN có thể được thực hiện với lược đồ mã hóa. Việc thực hiện mã hóa duy trì thứ tự không được thực
hiện cho đến khi có CryptDB, và thậm chí cũng không có ước lượng nào cho tính thực tế của lược đồ. Có nghĩa
là, CryptDB là triển khai đầu tiên của mã hóa duy trì thứ tự sử dụng thuât toán của Boldyreva [12].

D.Các truy vấn với chức năng tìm kiếm
Các triển khai trong bài viết của Song được sử dụng cho CryptDB. Các truy vấn với LIKE được thực hiện sử
dụng lược đồ này, nhưng thuật toán tìm kiếm chỉ cho phép thực hiện các tìm kiếm đầy đủ từ (full-word). Trong
phần này, chúng tôi sẽ giải thích thuật toán tìm kiếm của Song[13]. Giả sử rằng chúng ta có nhiều tài liệu riêng
tư và chúng ta có lưu trữ giới hạn. Dó đó, chúng ta có thể giữ chúng trên một máy chủ không tin cậy. Điều này
cũng được áp dụng cho máy chủ thư, và chúng ta cần giữ các e-mail các nhân ở đó. Vì lý do riêng tư và bảo
mật, dữ liệu được lưu trữ trên một bên không đáng tin cậy phải được mã hóa.
Không mất tính tổng quát, chúng ta sẽ coi các từ như là các chuỗi N bit. Đây chỉ là giả sử rằng tất cả các từ
có cùng độ dài, từ nhỏ hơn sẽ được đệm (padded), và từ dài hơn có thể được chia thành các khối N bit. Trong
khi tìm kiếm trong các tài liệu, chúng tôi quan tâm tới các tài liệu cụ thể chứa các từ đặc biệt. một từ khóa đặc
biệt. Nếu chúng ta có băng thông thấp chúng ta chỉ cần tải các file yêu cầu chứa các từ của chúng ta thay vì tải
toàn bộ file. Thuật toán tìm kiếm của Song là một lựa chọn tốt để giải quyết vấn đề này.
Lưu ý rằng có hai thuật toán tìm kiếm: thuật toán dựa trên chỉ mục (index-based algorith) và thuật toán quét
tuần tự (sequential scan algorith) Thuật toán của Song dựa trên thuật toán quét tuần tự. Sử dụng một chỉ mục


cho tìm kiếm các tài liệu lớn thường nhanh hơn quét tuần tự. Trong khi việc đọc dữ liệu từ một nguồn, nó tốt
hơn để sử dụng dựa theo chỉ mục, nhưng lưu trữ và thay đổi các từ ở đây là một vấn đề khó để xem xét. Chỉ
mục đưa thêm thông tin, và điều này có thể dẫn tới các tấn công thống kê. Vì những lý do đó, thuật toán của
Song thích hợp hơn thuật toán quét tuần tự.
1)Thuật toán tìm kiếm của Song trên dữ liệu mã hóa: có bốn lược đồ tồn tại trong thuật toán của Song. Đầu
tiên là lược đồ cơ bản là có thể chứng minh an toàn. Tuy nhiên, không có tìm kiếm được kiểm soát và các tìm
kiếm không ẩn. Để làm cho hệ thống chức năng hơn, Song giới thiệu ba lược đồ khác.
Lược đồ cơ bản co thể được mô tả gần như sau: Giả sử rằng chúng ta tìm kiếm một từ trên tài liệu mã hóa
trên một bên không đáng tin cậy, nhưng cùng thời điểm đó chúng ta không muốn lộ bất kỳ thông tin nào về bản
rõ. Cơ chế mã hóa của lược đồ cơ bản cung cấp tính bí mật có thể chứng minh được. Nếu bạn có một tài liệu
chưa l từ dài N bit, sau đó bạn tạo một chuỗi l các giái trị giả ngẫu nhiên (pserudorandom values) dài N bit. Để
mã hóa một từ N bit tại vị trí thứ i, giá trị tương ứng Si và F(Si) được nối với nhau với F là một hàm giải ngẫu
nhiên an toàn (secure pseudorandom function), ví dụ Si||F(Si). Hàm F này là một hàm giả ngẫu nhiên an toàn và
nó sử dụng một khóa để mã hóa. Khóa này có thể giống nhau cho tất cả các từ trong tài liệu, hoặc nó có thể

khác cho từng vị trí độc lập. Lược đồ này là có thể chứng minh an toàn có nghĩa là máy chủ không đáng tin cậy
không thể biết được bất cứ thứ gì từ bản rõ.

Hình 4 lược đồ cơ bản
Từ quan điểm của lược đồ cơ bản, nếu chúng ta muốn tìm một từ, chúng ta cung cấp chính từ đó và các khóa
của các vị trí mà từ này có thể xuất hiện Nếu chúng ta không biết gì về các vị trí, chúng ta sẽ cung cấp tất cả các
khóa. Bên không tin cậy sẽ lấy chúng, và XOR bản mã với từ. Nếu kết quả có Si||F(Si) cho một vài S, sự tương
xứng xảy ra và chúng ta sẽ biết vị trí của từ. Nếu bên không tin cậy không biết khóa của một vị trí, không gì sẽ
rỏ rỉ về bản rõ. Tuy nhiên, biết bất cứ gì về các vị trí khiến cho tất cả khóa bị rò rỉ, và điều này có nghĩa tất cả tài
liệu được giải mã cho bên không tin cậy.
Lược đồ thứ hai mở rộng lược đồ cơ bản bằng cách hỗ trợ tìm kiếm được kiếm soát. Trong lược đồ này, khóa
được gắn với một hàm giả ngẫu nhiên khác G trong đó láy các từ dưới một khóa bí mật ngẫu nhiên k’. Với mỗi
từ, nó tạo ra các khóa cho hàm F, ki =fk’(Wi)) với W là một từ trong tài liệu. Sau khi mã hóa tài liệu, nếu chúng ta
muốn tìm một từ, chúng ta sẽ đưa từ và khóa được sinh ra bằng các sử dụng chính từ đó và khóa bí mật k của
chúng ta. Lược đồ này không tiết lộ bất kỳ thông tin gì về vị trí không được bao gồm trong từ tìm kiếm của
chúng ta. Điều này cung cấp tìm kiếm được kiểm soát.


Hình 5 lược đồ thứ hai
Cho đến nay, từ được trao cho các máy chủ không tin cậy như bản rõ, nói chung đây không phải là tình
huống được chấp nhận. Lược đồ thứ ba mở rộng lược đồ thứ hai, và hỗ trợ các tìm kiếm ẩn. Trước khi chúng ta
tìm kiếm một từ, chúng ta mã hóa mỗi từ với một thuật toán bất định như mã hóa chế độ ECB. Từ chúng ta tìm
kiếm được mã hóa và cũng là khóa của chúng ta được sinh ra bằng cách sử dụng hàm G trong lược đồ thứ hai.
Tuy nhiên, khóa phụ thuộc vào từ mã hóa, không phụ thuộc vào từ gốc nữa. Cơ chế còn lại là giống như lược đồ
thứ hai.

Hình 6 Lược đồ thứ ba
Vấn đề với lược đồ thứ hai và ba là việc giải mã không khả thi. Sau khi có gắng nối S và F(S), và XOR
chúng với một từ, chúng ta mã hóa từ. Tuy nhiên, tại phần giải mã, để sinh ra F(S) từ S, chúng ta cần biết khóa
của từ cụ thể này. Và khóa này phụ thuộc vào từ mã hóa. Đó là một mâu thuẫn cho giải mã của một từ mã hóa

yêu cầu chính từ mã hóa đó. Vì lý do này, một vài sửa đổi được thực hiện với hàm sinh khóa. Khóa được sinh ra
với N-M bit của từ mã hóa như độ dài của các giá trị S. Trong khi giải mã từ, chúng ta sử dụng S và N-M bit
đầu tiên của bản mã để sinh ra N-M bit của bản rõ. Với thông tin này, chúng ta có thể sinh ra khóa, và sử dụng
khóa này chúng ta tìm F(S). Và cuối cùng chúng ta tìm ra M bit cuối cùng của bản rõ bằng cách XOR M bit
cuối của bản mã và các giá trị F(S). Lược đồ cuối cùng này cũng có an toàn có thể chứng minh được như lược
đồ đầu tiên. Ngoài ra chúng tôi thêm tính năng cách ly truy vấn, đó là bên không tin cậy chỉ biết kết quả tìm
kiếm, không thông tin bổ sung nào về vị trí của dạng rõ của các từ.


Hình 7 Lược đồ cuối cùng
2)Tìm kiếm mã hóa của CryptDB: CryptDb sử dụng triển khai của thuât toán tìm kiếm Song. Thuật toán này
thực hiện các tìm kiếm đầy đủ từ với các truy vấn LIKE. Trong CryptDB, việc lặp lại các từ được loại bỏ, và
các từ được hóa vị để cung cấp an toàn hơn trong tìm kiếm. Tuy nhiên bằng cách so sánh số lượng bản mã RND
với bản mã SEARCH, có thể biết được số lượng các từ lặp lại. Sau đó, các từ được đệm (padded) tới độ dài cố
định N bit để mã hóa theo thuật toán của Song. Các truy vấ n có thể được chạy như sau:
SELECT * FROM Students WHERE Name LIKE “% Alice %”;

Sau khi truy vấn này tới Proxy Server, nó sẽ sửa đổi truy vấn với việc mã hóa chuỗi “Alice”. Mã hóa được
giả sử là 98wu trong ví dụ.
SELECT

* FROM DBMS_Table1 WHERE C2-Search LIKE “% 98wu %”;

Một trong các UDF làm cho DBMS Server kiểm tra sự phù hợp của bản mã trong cột SEARCH với mã hóa
của chuỗi “Alice”. Sự rò rỉ duy nhất cho DBMS Server là liệu có sự phù hợp nào với từ đầy đủ này hay không.
Các biểu thức chính quy và nhiều từ không được hỗ trợ, chỉ các tìm kiếm từ đầy đủ (full-word) có thể được thực
hiện với thuật toán này, vì thế phần tìm kiếm này của CryptDB khong đủ đám ứng nhu cầu của chúng ta cho các
truy vấn tìm kiếm.

E.Các truy vấn với homomorphic addition functionality

Từ quan điểm của các truy vấn SQL, tổng của số nguyên được sư rudngj, không chỉ cho các truy vấn SUM,
mà còn là một phần của tính toán trung bình. Cách thêm chức năng cộng cho bản mã có thể đạt được bằng cách
sử dụng homomorphic. Nếu một chức năng là homomorphic, thì phép nhân của hai bản mã là mã hóa của phép
nhân hoặc phép cộng của bản rõ của hai bản mã. Với CryptDB, phép nhân của bản rõ không được sử udngj từ
quan điểm của các truy vấn SQL, vì vậy thuật toán đồng cấu có tính cộng (additively homomorphic algorithm)
là cần thiết cho cấu trúc này. Additively homomorphism có thể được mô tả như sau:
m1 và m2 là bản rxo của hai giá trị


c1 la mã hóa của m1.
c2 là mã hóa của m2.
c1 × c2 = Enc(m1 × m2) với Enc là hàm mã hóa có đặc điểm additively homomorphic.
Thuật toán đồng cấu được sử dụng trong CryptDB là thuật toán của Paillier. Ngoài ra còn có thuật toán của
Ge & Zdonik. Thuật tán này, nói chugn, nhằm mục đích ngăn chặn sự thỏa hiệp của cơ sở dữ liệu bằng cách xử
lý các truy vấn trên bản mã mà không giải mã chúng. Nó kết hợp tất cả các giá trị của một hàng vào một bản mã
HOM cho mỗi hàng. Tuy nhiên nó yêu cầu gấp hai lần không gian cho trước. Vì lý do này, trong CryptDB thuật
toán này không được thực hiện.
1)Đặc tính đồng cấu của CryptDB: trong CryptDB, chúng ta giữ các giá trị mã hóa trong cơ sở dữ liệu. Vì lý
do này, đặc tính đồng cấu là một giải pháp cho CryptDB. Các truy vấn với SUM và AVG được bao gồm trong
phần này. Chúng ta có thể tạo ra một truy vấn theo ví dụ của chúng ta. Chúng ta sẽ cập nhật bảng của chúng ta
để làm một truy vấn có nghĩa, và tính toán tổng số grade của Students. Bảng được cập nhật của chúng ta sẽ
được minh họa trong Table IX.

Table IX không được giữ bên trong cơ sở dữ liệu. Proxy Server mã hóa các giá trị cho việc tạo ra một bảng
khác cho DBMS Server. Cơ sở dữ liệu được tạo ra cho DBMS Server sẽ giống như Table X.

Truy vấn ví dụ của chúng ta có thể giống như sau:
SELECT

SUM (grade) AS average FROM Students;

Proxy Server sẽ chỉnh sửa truy vấn, và gửi tới DBMS Server. Theo bảng của DBMS Server, truy vấn sửa đổi
sẽ như sau:
SELECT SUM (c3-Hom) AS average FROM DBMS_Table2;

Sau khi lấy truy vấn SQL này, DBMS Server sẽ gọi UDF chịu trách nhiệm tính toán tổng của các giá trị. Tính
tổng này sẽ được thực hiện bằng cách sử dụng đặc tính đồng cấu. Có nghĩa là, các giá trị mã hóa của cột C3HOM sẽ được nhân, và kết quả sẽ là dạng mã hóa của các bản rõ.


Ở đây, các giá trị là qmdl, ahc0, và h9dj. Giả sử rằng giá trị của phép nhân là a83g.
(qmdl × ahc0 × h9dj) = a83g

Lưu ý rằng DBMS Server sẽ không thể biết được các giá trị và kết quả vì mã hóa. Các bản mã được nhân sẽ
dẫn đến kết quả một bản mã mới. Proxy Server sẽ lấy kết quả mã hóa này và sẽ giải mã nó. Giá trị giải mã này
sẽ là tổng của các giá trị bên trong cột Grade nhờ đặc tính đồng cấu.
a83g = Enc (86 + 77 + 95)

nếu Dec là hàm giải mã của Enc có đặc tính đồng cấu , thì điều này cũng sẽ xảy ra
Dec (a83g)

= 86 + 77 + 95

Cuối cùng, phép tính tổng được thực hiện chính xác trên phía DBMS Server mà không để lộ ra bất kỳ thông
tin nào trên dữ liệu. Cụ thể là, DBMS Server sẽ không thể nhìn thấy các bản rõ, những nó vẫn có thể tính tổng
chỉ bằng cash tính toán phép nhân trên các bản mã.

IV.An ninh và tính phức tạp của CryptDB và các ghi chú thêm.