CHƯƠNG 2. MÔ HÌNH XỬ LÝ DỮ LIỆU MÃ HÓA VÀ BẢO MẬT DỮ LIỆU TRONG ĐIỆN TOÁN ĐÁM MÂY
2.2. CryptDB và mô hình xử lý dữ liệu mã hóa
2.2.3. Truy vấn trên dữ liệu mã hóa
2.2.3.6. Thực thi truy vấn trên dữ liệu mã hóa
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 bảng 2.4, 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 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 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 TABLEStudents (IDint, 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”);
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc.tnu.edu.vn
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 2.5.
Students
ID Name
1 Alice
2 Bob
3 Eve
Bảng 2.5. Students sau khi đƣợc tạo C1-IV C1-Eq C1-Ord C1-
Hom C2-IV C2-Eq C2-Ord C2- Search
q39f ge88 hwip dwna lpw9 dkfm fdkw 98wu
c8x3 8n4o s09s 28bd suc0 d82w 8mx0 x9ak
sk7x x7wk x6sh s7w9 3mnu snge xuwn u8sb
Bảng 2.6. 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ú ý Proxy phải thay đổi các truy vấn để bảo vệ nội dung bảng gốc. Nếu tiếp tục với truy vấn “SELECT Name FROM Students;”, truy vấn nhƣ sau:
SELECTC2-IV, C2-EqFROMDBMS_Table1;
DBMS Server sẽ xử lý truy vấn này và trả về kết quả trong bảng 2.7.
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc.tnu.edu.vn
C2-IV C2-Eq
lpw9 dkfm
suc0 d82w
3mnu snge
Bảng 2.7. 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ƣ bảng 2.8.
Name Alice
Bob Eve
Bảng 2.8. Kết quả đƣợc trả về từ phía Proxy Server
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.
Bảng 2.9. 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.
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc.tnu.edu.vn
Hình 2.7. 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, truy vấn nhƣ sau:
SELECT ID FROM Employees WHERE Name = „Alice‟
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.
Bảng 2.10. Lược đồ cơ sở dữ liệu sau bước 1
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc.tnu.edu.vn
Hình 2.8. 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:
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ú ý 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.
Bảng 2.11. 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
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc.tnu.edu.vn
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 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, 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 [6].
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 [9]. 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 * FROMStudentsWHERENameLIKE“% 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 %”;
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc.tnu.edu.vn
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 là 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 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 [8].
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 đƣợc minh họa trong bảng 2.12.
StudentsWithGrades
ID Name Grade
1 Alice 86
2 Bob 77
3 Eve 95
Bảng 2.12. Đƣợc cập nhật với các giá trị Grade đƣợc thêm
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc.tnu.edu.vn
Bảng 2.12 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 2.13.
DBMS_Table2 C1-
IV
C1- Eq
C1- Ord
C1- Hom
C2- IV
C2- Eq
C2- Ord
C2- Search
C3- IV
C3- Eq
C3- Ord
C3- Hom smsk skwl 9dsi 32k0 cos8 qsaw udb7 6sq8 wj9s wus8 2ldo qmd1 aksi w8f9 v7sj 3ld0 sk0w kd8s lvmh s99s kcsk dfsi xnsk ahc0 wipd msuw 9s9k 389r kduc 8sjf k9sk cnbs bosm x19s jwmd h9dj
Bảng 2.13. Đƣợ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:
SELECTSUM(grade) ASaverageFROMStudents;
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) ASaverageFROMDBMS_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 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)
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc.tnu.edu.vn
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 cách 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 DBMS khác: Hầu hết các cơ chế DBMS 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, 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.