Khi các lớp onion trên DBMS đang ở lớp cần thiết để thực thi một truy vấn, proxy biến đổi truy vấn để hoạt động trên các onion này. Đặc biệt, proxy thay thế các tên cột trong một truy vấn với các tên onion tương ứng, dựa trên lớp tính toán được thực hiện trên cột đó. Ví dụ, với lược đồ được thể hiện trong Hình 2.10, một tham chiếu đến cột Name cho một so sánh bằng (ví dụ
WHERE Name = „Alice‟) sẽ được thay thế với một tham chiếu tới cột Name-
EqOn.
Proxy cũng thay thế mỗi hằng số trong truy vấn với mã hóa onion tương ứng của hằng số đó, dựa trên các tính toán trong đó nó được sử dụng. Ví dụ, nếu một truy vấn chứa WHERE Name = „Alice‟, proxy mã hóa „Alice‟ bằng
43
cách áp dụng lần lượt tất cả các lớp mã hóa tương ứng với onion Eq mà vẫn
chưa được loại bỏ khỏi C2-Eq.
Cuối cùng, server thay thế các toán tử nhất định với các UDF tương ứng. Ví dụ, toán tử tập hợp SUM và toán tử cộng cột „+‟ phải được thay thế với một lời gọi của một UDF mà thực hiện phép tính cộng HOM của các bản mã. Các toán tử Equality và Order (như „=‟ và „<‟ chẳng hạn) không cần thiết thay thế như vậy và có thể được áp dụng trực tiếp vào các bản mã DET và OPE.
Khi proxy chuyển đổi truy vấn, nó gửi truy vấn tới DBMS server, nhận các kết quả truy vấn (bao gồm dữ liệu mã hóa), giải mã các kết quả sử dụng các onion key tương ứng, và gửi kết quả giải mã cho ứng dụng.
Thực thi các truy vấn không có chức năng. Giả sử bảng 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 bảng Students. 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 vì 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ư bảng trong Hình 2.12.
44
Hình 2.12 Bảng mã hóa được tạo trên Proxy Server.
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 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, 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ử dụng lớp an toàn nhất, chúng ta có thể chạy các truy vấn như SELECT * FROM Students;”, “SELECT Name FROM Students;”
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 thay đổ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 Hình 2.13
Hình 2.13 Kết quả của truy vấn.
Bảng tương ứng khi Proxy Server giải mã và gửi cho Application Server sẽ giống như Hình 2.14.
45
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.
Thực thi truy vấn với chức năng equality check. Để hiểu sự thực thi
truy vấn trên các bản mã, xem xét lược đồ cơ sở dữ liệu ví dụ sau.
Hình 2.15 Lược đồ cơ sở dữ liệu ví dụ.
Ban đầu, mỗi cột trong bảng được bọc trong tất cả các onion mã hóa, với RND, HOM, và SEARCH là các lớp ngoài cùng. Tại thời điểm này, máy chủ không thể biết gì về dữ liệu ngoại trừ số cột, số hàng, và kích thước dữ liệu.
Hình 2.16 Các lớp mã hóa của các cột.
Giả sử Eq Onion đang ở lớp mã hóa mặc định RND, thực hiện truy vấn sau:
46
Lúc này mã hóa của Name sẽ được yêu cầu giảm xuống tới lớp DET. Sau đây là các bước để thực hiện được truy vấn trên dữ liệu mã hóa:
Bước 1: proxy gửi tới DBMS: UPDATE Table1 SET
C2-Eq = DECRYPT_RND(KT1,C2,Eq,RND, C2-Eq, C2-IV),
với cột C2-Eq tương ứng với Name. Tại DBMS, cột C2-Eq được giải mã tới lớp DET:
DKeyT1,C2,Eq,RND(xd1e3, x8a13) = x7b3d
DKeyT1,C2,Eq,RND(x3f2a, x73fd) = xbb4a
proxy sau đó cập nhật vào log rằng Table1 cột C2-Eq hiện tại đang ở lớp DET trong DMBS.
Hình 2.17 Lược đồ cơ sở dữ liệu sau bước 1.
Hình 2.18 Lớp mã hóa của các cột sau bước 1.
Bước 2: Proxy mã hóa „Alice‟ lên lớp DET của Eq Onion thu được giá trị x7b3d bằng cách thực hiện mã hóa
47 EKeyT1,C2,Eq,DET(EKeyT1,C2,Eq,JOIN(Alice))
proxy sau đó sinh ra một truy vấn và gửi nó cho DBMS:
SELECT C1-Eq, C1-IV FROM Table1 WHERE C2-Eq = x7b3d
với cột C1-Eq tương ứng với ID, và x7b3d là mã hóa Eq onion của
“Alice” với các key KT1,C2,Eq,JOIN và KT1,C2,Eq,DET. Chú ý rằng proxy phải yêu càu IV ngẫu nhiên từ cột C1-IV để giải mã bản mã RND từ C1-Eq. Các lớp Eq Onion và các giá trị mã hóa vẫn không thay đổi sau bước UPDATE.
Hình 2.19 Lược đồ cơ sở dữ liệu sau bước 2.
Bước 3: Cuối cùng, proxy nhận được kết quả x2b82 tại lớp RND, tiến hành giải mã nó sử dụng các key KT1;C1;Eq;RND, KT1;C1;Eq;DET, và KT1;C1;Eq;JOIN, thu được kết quả 23, và trả nó về cho ứng dụng.
DKeyT1,C1,Eq,JOIN(DKeyT1,C1,Eq,DET(DKeyT1,C1,Eq,RND (x2b82, x27c3))) = 23
Nếu truy vấn tiếp theo là SELECT COUNT(*) FROM Employees
WHERE Name = „Bob‟, cột C2-Eq lúc này đã ở lớp DET, không cần thiết
phải giải mã ở phía máy chủ, và proxy trực tiếp sinh ra truy vấn SELECT COUNT(*) FROM Table2 WHERE C2-Eq = xbb4a, với xbb4a là mã hóa Eq
onion của “Bob” sử dụng KT1;C2;Eq;JOIN và KT1;C2;Eq;DET.
Thực thi truy vấn với các chức năng order check. 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 cả trong CryptDB. 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ó
48
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 [8].
Các truy vấn với chức năng tìm kiếm. CryptDb sử dụng triển khai thuât
toán tìm kiếm của Song [11]. Thuật toán này thực hiện các tìm kiếm từ đầy đủ (full-word) 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 hoán 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à x29b0 trong ví dụ.
SELECT * FROM DBMS_Table1 WHERE C2-Search LIKE “% x29b0 %”; 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 không đủ đáp ứng nhu cầu của chúng ta cho các truy vấn tìm kiếm.
Các truy vấn với chức năng tính tổng các giá trị. Từ quan điểm của các
truy vấn SQL, tổng của số nguyên được sử dụng không chỉ cho các truy vấn SUM mà còn được sử dụng để tính toán giá trị trung bình. Việc thực hiện chức năng cộng cho bản mã có thể đạt được bằng cách sử dụng mã hóa đồng cấu. Trong mã hóa đồng cấu, phép nhân của hai bản mã là mã hóa của phép cộng của bản rõ của hai bản mã đó. Ta có thể mô tả như sau:
m1 và m2 là bản rõ của hai giá trị c1 la mã hóa của m1.
49 c2 là mã hóa của m2.
c1 × c2 = Enc(m1 + m2) với Enc là hàm mã hóa có đặc tính đồng cấu.
Thuật toán đồng cấu được sử dụng trong CryptDB là thuật toán của Paillier [10]. 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ụ sau, ta sẽ tính toán tổng số điểm (Grade) của các học sinh trong bảng ví dụ sau được minh họa trong Hình 2.20.
Hình 2.20 Bảng được cập nhật với các giá trị Grade được thêm.
Bảng trong Hình 2.20 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ư bảng trong Hình 2.21.
Hình 2.21 Bảng được cập nhật được mã hóa bên Proxy Server. 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ử
50
dụng đặc tính đồng cấu. Có nghĩa là, các giá trị mã hóa của cột C3-HOM 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ì ta sẽ có: 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ã.
Thực thi các truy vấn viết. Để hỗ trợ các truy vấn INSERT, DELETE, và
UPDATE, proxy áp dụng cùng một xử lý cho các vị từ (ví dụ, mệnh đề WHERE) như cho các truy vấn đọc. Các truy vấn DELETE không yêu cầu thêm xử lý nào khác. Với tất cả các truy vấn INSERT và UPDATE mà thiết lập giá trị của một cột thành một hằng số, proxy mã hóa từng giá trị của cột được chèn vào với từng lớp onion mà vẫn chưa được gỡ bỏ trong cột đó.
Các đặc điểm DMBS khác. Hầu hết các cơ chế DMBS khác, như giao
dịch (transaction) và lập chỉ mục (indexing) hoạt động tương tự với CryptDB trên dữ liệu mã hóa như chúng làm trên bản rõ mà không có sự thay đổi nào. CryptDB hiện tại không hỗ trợ các thủ tục lưu trữ, mặc dù các thủ tục lưu trữ nhất định có thể được hỗ trợ bằng cách viết lại mã của chúng theo cùng cách mà proxy của CryptDB viết lại các câu lệnh SQL.
DBMS xây dựng các chỉ mục cho dữ liệu mã hóa theo cùng một cách như cho bản rõ. Hiện tại, nếu ứng dụng yêu cầu một chỉ mục (index) trên một cột,
51
proxy yêu cầu máy chủ DBMS xây dựng các chỉ mục trên các lớp DET, Equi- JOIN, OPE, hoặc OPE-JOIN onion của cột đó (nếu chúng bị lộ), nhưng không phải cho RND, HOM, hoặc SEARCH. Các thuật toán lựa chọn chỉ mục hiệu quả hơn có thể được nghiên cứu.