Tính toán liên kết giữa các cột

Một phần của tài liệu Xử lý và mã hóa bảo mật dữ liệu trên điện toán đám mây (Trang 60)

Có hai loại liên kết được hỗ trợ bởi CryptDB: equality joins, trong đó vị từ liên kết được dựa trên equality, và range joins, trong đó liên quan đến các

order check. Để thực hiện một equi-join của hai cột mã hóa, các cột phải được mã hóa với cùng một khóa để máy chủ có thể thấy các giá trị khớp giữa hai cột. Tại cùng thời điểm, để cung cấp bảo mật tốt hơn, máy chủ DBMS không được liên kết các cột mà ứng dụng không yêu cầu liên kết, vì vậy các cột mà không bao giờ được liên kết không nên được mã hóa với cùng các khóa.

Nếu các truy vấn mà có thể được sinh ra hoặc các cặp cột mà có thể được liên kết được biết từ trước đó,việc hỗ trợ equi-join rất dễ dàng: CryptDB có thể sử dụng mã hóa DET với cùng key cho mỗi nhóm của các cột mà được liên kết với nhau. Tuy nhiên, trường hợp khó khăn là khi proxy không biết tập các cột được liên kết từ trước đó, và do đó không biết các cột nào phải được mã hóa với các khóa phù hợp.

Để giải quyết vấn đề này, một cơ sở mật mã mới được giới thiệu, JOIN- ADJ (adjustable join), cho phép DMBS server điều chỉnh khóa của từng cột tại thời điểm chạy. JOIN-ADJ có thể được coi như là một băm mật mã được bảo vệ bằng khóa (keyed cryptographic hash) với các đặc điểm bổ sung mà các băm có thể được điều chỉnh để thay đổi khóa của chúng mà không cần truy cập tới bản rõ. JOIN-ADJ là một hàm tất định của các đầu vào của nó, có

nghĩa là nếu hai bản rõ giống nhau, các giá trị JOIN-ADJ tương ứng cũng bằng nhau. JOIN-ADJ chống được đụng độ (collision-resistant), và có chiều dài đầu ra đủ dài (192 bit) để cho phép chúng ta thừa nhận rằng các đụng độ không bao giờ xảy ra trong thực tế.

Lược đồ mã hóa Equi-JOIN là một chuỗi kết nối Equi-JOIN(v) = JOIN- ADJ(v)||DET(v). cấu trúc này cho phép proxy giải mã một cột JOIN(v) để thu được v bằng cách giải mã thành phần DET, và cho phép máy chủ DBMS

52

kiểm tra hai giá trị Equi-JOIN có bằng nhau không bằng cách so sánh các thành phần JOIN-ADJ.

Mỗi cột ban đầu được mã hóa tại lớp Equi-JOIN sử dụng khóa khác nhau, do đó ngăn chặn bất kỳ các liên kết nào giữa các cột. Khi một truy vấn yêu cầu một liên kết, proxy đưa cho máy chủ DBMS một khóa onion để điều chỉnh các giá trị JOIN-ADJ trong một hoặc hai cột, để nó phù hợp với khóa JOIN-ADJ của cột khác (được ký hiệu là cột join-base). Sau khi điều chỉnh,

các cột chia sẻ cùng một khóa JOIN-ADJ, cho phép máy chủ DBMS liên kết chúng lại với nhau. Các thành phần DET của Equi-JOIN vẫn được mã hóa với các khóa khác nhau.

Chú ý rằng liên kết điều chỉnh được ở đây có tính bắc cầu: nếu người dùng liên kết các cột A và B và rồi liên kết cột B và C, máy chủ có thể liên kết A và C. Tuy nhiên, máy chủ không thể liên kết các cột trong “các nhóm bắc cầu” khác nhau. Ví dụ, nếu cột D và E được liên kết với nhau, DBMS server không thể liên kết cột A và D.

Sau một truy vấn liên kết ban đầu, các giá trị JOIN-ADJ vẫn được chuyển đổi với cùng khóa, vì vậy không cần thiết điều chỉnh lại cho các truy vấn liên kết đến sau giữa cùng hai cột. Một ngoại lệ là nếu ứng dụng sinh ra truy vấn khác, liên kết một trong các cột đã được điều chỉnh với một cột thứ ba, sẽ khiến cho proxy điều chỉnh lại cột sang một join-base khác. Để tránh những dao động (oscillations) và để hội tụ (converge) tại một trạng thái mà tất cả các cột trong một nhóm bắc cầu chia sẻ cùng join-base, CryptDB chọn cột đầu tiên có tên theo thứ tự từ điển trong bảng là join-base. Với n cột, số lượng tổng thế tối đa của các chuyển đổi join là n(n-1)/2.

Đối với các range join, một lược đồ tái điều chỉnh động tương tự là khó khăn để xây dựng do thiếu sót cấu trúc trong các lược đồ OPE. Thay vào đó, CryptDB yêu cầu cặp cột đó mà sẽ được liên hệ với nhau bằng các liên kết được ứng dụng khai báo trước, do đó các key phù hợp được sử dụng cho lớp OPE-JOIN của các cột đó; nếu không, cùng một key sẽ được sử dụng cho tất cả các cột tại lớp OPE-JOIN. May mắn thay, các range join hiếm khi xuất hiện.

53

Cấu trúc JOIN-ADJ. Thuật toán được sử dụng để mã hóa là đường cong

elliptic (elliptic-curve cryptography - ECC). JOIN-ADJK(v) được tính toán như sau:

Với K là khóa khởi tạo cho bảng, cột, onion và lớp đó, P là một điểm trên một đường cong elliptic (là một tham số public), và PRFK0 là một hàm giả ngấu nhiên (pseudo-random function) ánh xạ các giá trị tới các số giả ngẫu nhiên, như AESK0(SHA(v)) chẳng hạn, với K0 là một khóa, khóa này như

nhau cho tất cả các cột và có nguồn gốc từ MK. Các “lũy thừa” (“exponentiation”) thực tế là sự bổ sung các hình lặp đi lặp lại của các điểm đường cong elliptic; nó nhanh hơn đáng kể so với lũy thừ RSA.

Khi một truy vấn join cột c và c’, mỗi khóa K và K’ tại lớp join, proxy tính toán ΔK = K/K’ (trong một nhóm thích hợp) và gửi nó cho máy chủ. Sau đó với JOIN-ADJK’(v) đã cho (các giá trị JOIN-ADJ từ cột c‟) và ΔK, máy chủ DBMS sử dụng một UDF để điều chỉnh key trong c’ bằng cách tính :

Bây giờ các cột c và c‟ chia sẻ cùng JOIN-ADJ key, và DBMS có thể thực hiện một equi-join trên c và c‟ bằng cách lấy bộ phận JOIN-ADJ của JOIN onion cipertext.

Tại một mức cao hơn, độ an toàn của lược đồ này là máy chủ không thể suy ra các mối quan hệ liên kết giữa các nhóm của các cột mà không được yêu cầu bởi các truy vấn liên kết hợp pháp, và lược đồ không để lộ bản rõ.

Một phần của tài liệu Xử lý và mã hóa bảo mật dữ liệu trên điện toán đám mây (Trang 60)

Tải bản đầy đủ (PDF)

(90 trang)