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ả.. EQ onion nhằm mục đích điều chỉnh các lớp cho cá
Trang 1I.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]
Trang 2CryptDB: 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
(column-oriented) 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ỏ
Trang 3Hì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 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
Trang 4Bằ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
Trang 5Hì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 = PRP MK (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
Trang 6Khô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
Trang 7Đ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=PRP MK (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
Trang 8Bả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
Trang 9Bả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 = PRP (table t, column c, onion o, layer l)
Trang 10Sau 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:
Decrypt Key (q39f, ge88) = djes
Decrypt Key (c8x3, 8n4o) = ektd
Decrypt Key (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:
Enc Key2 (Enc Key1 (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
