CryptDB - Bảo vệ tính bí mật cơ sở dữ liệu với truy vấn đã được mã hóa

Các ứng dụng trực tuyến rất dễ bị đánh cắp thông tin nhạy cảm vì kẻ xấu có thể khai thác các lỗi phần mềm để truy cập tới dữ liệu cá nhân, và vì các quản trị viên tò mò hoặc có ý đồ xấu có thể thu thập và làm rò rỉ dữ liệu. CryptDB là một hệ thống cung cấp tính bảo mật đã được chứng minh chống lại được các tấn công vào các ứng dụng cơ sở dữ liệu SQL. Nó hoạt động dựa trên việc thực hiện các truy vấn SQL trên dữ liệu được mã hóa sử dụng một tập hợp các lược đồ mã hóa SQL hiệu quả. CryptDB cũng có thể kết hợp các key mã hóa với các mật khẩu của người dung, vì vậy một mục dữ liệu chỉ có thể được giải mã bằng cách sử dụng mật khẩu của một trong những người sử dụng truy cập vào dữ liệu đó. Kết quả là, một quản trị viên cơ sở dữ liệu không bao giờ truy cập được để giải mã dữ liệu, và kể cả khi tất cả server bị thỏa hiệp, đối phương không thể giải mã dữ liệu của bất kỳ người dùng không đăng nhập nào

Tóm tắt

Các ứng dụng trực tuyến rất dễ bị đánh cắp thông tin nhạy cảm vì kẻ xấu có thể khai thác các lỗi phần mềm để truy cập tới dữ liệu cá nhân, và vì các quản trị viên tò mò hoặc có ý đồ xấu có thể thu thập và làm rò rỉ dữ liệu CryptDB là một hệ thống cung cấp tính bảo mật đã được chứng minh chống lại được các tấn công vào các ứng

dụng cơ sở dữ liệu SQL Nó hoạt động dựa trên việc thực hiện các truy vấn SQL trên dữ liệu được mã hóa sử

dụng một tập hợp các lược đồ mã hóa SQL hiệu quả (It works by executing SQL queries over encrypted data using a collection of efficient SQL-aware encryption schemes) CryptDB cũng có thể kết hợp các key mã hóa với các mật khẩu của người dung, vì vậy một mục dữ liệu (a data item) chỉ có thể được giải mã bằng cách sử dụng mật khẩu của một trong những người sử dụng truy cập vào dữ liệu đó Kết quả là, một quản trị viên cơ sở

dữ liệu không bao giờ truy cập được để giải mã dữ liệu, và kể cả khi tất cả server bị thỏa hiệp, đối phương không thể giải mã dữ liệu của bất kỳ người dùng không đăng nhập nào Một phân tích theo dõi 126 triệu truy vấn SQL từ một server MySQL cho thấy rằng CryptDB có thể hộ trợ 95.5% các phép toán trên cơ sở dữ liệu được mã hóa của 128,840 cột được thấy Đánh giá của chúng tôi chỉ ra rằng CryptDB có chi phí thấp, giảm 14.5% thông lượng (throughput) cho phpBB, một ứng dụng web forum, và 26% cho các truy vấn từ TPCC, so với unmodified MySQL Chaining encryption keys to user passwords requires 11–13 unique schema

annotations to secure more than 20 sensitive fields and 2–7 lines of source code changes for three multi-user web applications

1.Giới thiệu

Trộm cắp thông tin cá nhân là một vấn đề quan trọng, đặc biệt là đối với các ứng dụng trực tuyến [40] Đối phương có thể khải thác các lỗ hổng bảo mật phần mềm để truy cập trái phép vào các server [32]; những quản trị viên tò mò hay có ý đồ xấu tại các nhà cung cấp hosting hoặc ứng dụng có thể ăn cắp dữ liệu cá nhân [6]; và những kẻ tấn công truy cập vật lý vào các server có thể truy cập tất cả dữ liệu trên đĩa và trong bộ nhớ [23].Một trong các hướng để giảm thiểu những tổn hại gây ra bởi server bị thỏa hiệp là mã hóa dữ liệu nhạy cảm, như trong SUNDR [28], SPORC[16], và Depot [30], và chạy tất cả các tính toán (logic ứng dụng) trên các client Không may là nhiều ứng dụng quan trọng không tiếp cận theo cách này, bao gồm các database-backed web site mà xử lý các truy vấn để sinh ra dữ liệu cho người dùng, và các ứng dụng mà tính toán trên một lượng lớn dữ liệu Ngay cả khi phương pháp này được đảm bảo, việc chuyển đổi một ứng dụng phía server (server-side) hiện có sang dạng này có thể gặp khó khăn Một cách tiếp cận khác sẽ là xem xét các giải pháp theo lý thuyết như là mã hóa đồng cấu (homomorphic encryption) hoàn toàn [19], cho phép các server tính toán các hàm (functions) tùy ý trên dữ liệu được mã hóa, trong khi chỉ các client xem dữ liệu được mã hóa Tuy nhiên

mã hóa đồng cấu hoàn toàn vẫn rất tốn kém theo orders of magnitude [10, 21]

Bài viết này trình bày về CryptDB, một hệ thống nghiên cứu (explores) một điểm thiết kế trung gian

(intermediate design point) để cung cấp bảo mật cho các ứng dụng sử dụng các hệ quản trị cơ sở dữ liệu

(DBMSes) CryptDB tận dụng cấu trúc điển hình của các database-backen application, bao gồm một server DBMS và một server ứng dụng riêng biệt, được thể hiện trong Hình 1; server ứng dụng riêng biệt này chạy code ứng dụng và đưa ra các truy vấn DBMS thay cho một hoặc nhiều người dùng Cách tiếp cận của CryptDB là để thực thi các truy vấn trên dữ liệu được mã hóa, và điều làm nó thực tế là SQL sử dụng một tập xác định các toán

tử (operators), mỗi toán tử chúng ta có khả năng hỗ trợ hiệu quả trên dữ liệu mã hóa

Hình 1: Kiến trúc của CryptDB bao gồm 2 phần: một database proxy và một unmodified DBMS CryptDB sử

dụng các hàm người dùng định nghĩa (user-defined functions – UDFs) để thực hiện các tính toán mật mã trong DBMS Các hộp chữ nhật vuông và bo tròn đại diện các tiến trình và dữ liệu tương ứng Các hình có màu đậm chỉ ra các thành phần được thêm vào bởi CryptDB Các đường nét đứt cho thấy sự tách biệt giữa các máy tính của người dùng, server ứng dụng, một server đang chạy proxy cơ sở dữ liệu của CryptDB (nó thường giống một server ứng dụng), và DBMS server CryptDB giải quyết hai loại đe dọa, hiển thị dưới các đường chấm Trong mối đe dọa thứ nhất, một quản trị viên cơ sở dữ liệu tò mò với truy cập hoàn toàn tới DBMS server dòm ngó dữ liệu cá nhân, trong trường hợp này CryptDB ngăn chặn DBA truy cập vào bất kỳ thông tin cá nhân nào Trong mối đe dọa thứ hai, kẻ xấu đạt đượt kiểm soát hoàn toàn cả phần mềm và phần cứng của ứng dụng, proxy, và các DBMS server, trong trường hợp này CryptDB đảm bảo kẻ xấu không thẻ có được dữ liệu thuộc về người đung chưa đăng nhập (ví dụ: user 2)

CryptDB giải quyết hai mối đe dọa Mối đe dọa đầu tiên là một người quản trị cơ sở dữ liệu tò mò (curious database administrator – DBA) người cố gắng tìm hiểu dữ liệu cá nhân (ví dụ các bản ghi sức khỏe,các báo cáo tài chính, thông tin các nhân) bằng cách đánh cắp trên server DBMS;tại đây, CryptDB ngăn chặn DBA tìm ra dữ liệu cá nhân Mối đe dọa thứ hai là một kẻ tấn công đạt được quyền điều khiển hoàn toàn ứng dụng và các server DBMS Trong trường hợp này, CryptDB không thể cung cấp bất cứ đảm bảo nào cho những người dùng

đã đăng nhập vào ứng dụng trong khi tấn công đang xảy ra, nhưng vẫn có thể đảm bảo bí mật dữ liệu cho những người dùng đã đăng xuất

Có hai thách thức trong cuộc chiến chống lại những mối đe dọa này Thách thức đầu tiên là sức ép giữa việc tối giản hóa thông tin bí mật được tiết lộ cho server DBMS và khả năng thực thi có hiệu quả một loạt các truy vấn Các phương pháp tiếp cận hiện tại để tính toán trên dữ liệu mã hóa hoặc là quá chậm hoặc là không cung cấp đủ tính bí mật, như chúng ta thảo luận trong phần 9 Mặt khác, việc mã hoa dữ liệu với một hệ thống mã hóa mạnh, như AES, sẽ ngăn chặn server DBMS thực hiện nhiều truy vấn SQL, như những truy vấn số lượng nhân viên trong bộ phận “sales” hoặc tên của các nhân viên có số lương lớn hơn $60,000 Trong trường hợp này, giải pháp thực tế duy nhất sẽ là để cho server DBMS truy cập tới key mã hóa, nhưng điều đó cũng sẽ cho phép kẻ xấu đạt được truy cập tới toàn bộ dữ liệu

Thách thức thứ hai là tối thiểu dữ liệu bị rò rỉ khi kẻ xấu thỏa hiệp được server ứng dụng cùng với server

DBMS Vì việc tính toán tùy ý trên dữ liệu mã hóa là không thực tế, ứng dụng phải có khả năng truy cập dữ liệu

đã được giải mã Do đó khó khăn là đảm bảo rằng một ứng dụng đã bị thỏa hiệp có thể thu được chỉ một lượng giới hạn dữ liệu đã được giải mã Giải pháp gán cho mỗi người dùng một key mã hóa cơ sở dữ liệu khác nhau cho dữ liệu của họ không thực hiện được cho những ứng dụng với dữ liệu chia sẻ, như các trang web bảng tin

và hội nghị

CryptDB giải quyết những thách thức này bằng ba ý tưởng chính:

• Đầu tiên là thực thi các truy vấn SQL trên dữ liệu mã hóa CryptDB thực hiện ý tưởng này bằng cách sử dụng một chiến lược mã hóa nhận biết SQL (SQL-aware encryption strategy) tận dụng thực tế rằng tất

cả truy vấn SQL được tạo thành từ một tập xác định các toán tử nguyên thủy, như là kiểm tra đẳng equality check, so sánh thứ tự-oder comparison, tính tổng- aggregates (sums) , và kết hợp-join Bằng cách sửa lại cho phù hợp các lược đồ mã hóa đã biết (cho equality, additions, và odder checks) và sử dụng một phương pháp mã hóa bảo quản riêng tư (privacy-pereserving) cho joins, CryptDB mã hóa mỗi mục dữ liệu theo cách mà cho phép DBMS thực thi trên dữ liệu chuyển đổi CryptDB hiệu quả bởi nó chủ yếu sử dụng mã hóa đối xứng, tránh mã hóa đồng cấu đầy đủ (fully homomorphic encryption), và chạy trên phần mềm DBMS không chỉnh sửa (bằng cách sử dụng các hàm chức năng người dùng định nghĩa)

thức-• Kỹ thuật thứ hai là điều chỉnh mã hóa dựa trên truy vấn (adjustable query-based encryption) Một vài

lược đồ mã hóa làm rò rỉ thông tin về dữ liệu cho server DBMS nhiều hơn một số khác, nhưng được

yêu cầu xử lý các truy vấn nhất định Để tránh tiết lộ tất cả mã hóa có thể của dữ liệu cho DBMS từ trước đó (a priori), CryptDB cẩn thận điều chỉnh lược đồ má hóa nhận biết SQL (SQL-aware

encryption scheme) cho bất kỳ mục dữ liệu đã cho nào, tùy thuộc vào các truy vấn quan sát được trong

lúc chạy Để thực hiện những điều chỉnh này một cách hiệu quả, CryptDB sử dụng onions of encryption

Onions là một cách mới để lưu trữ một cách chặt chẽ nhiều bản mã trong mỗi onion khác trong cơ sở dữ liệu để tránh chi phí trong việc mã hóa lại (re-encryptions)

• Ý tưởng thứ ba là xâu chuỗi các key mã hóa với các mật khẩu người dùng, để mỗi mục dữ liệu trong cơ

sở dữ liệu chỉ có thể được giải mã thông qua một chuỗi của các key bắt nguồn từ mật khẩu của một trong số những người dùng truy cập vào dữ liệu đó Kết quả là nếu người dùng không đăng nhập vào ứng dụng, và nếu kẻ xấu không biết mật khẩu của người dùng, kẻ xấu không thể giải mã dữ liệu của người dùng, kể cả khi server DBMS và server ứng dụng bị thỏa hiệp hoàn toàn Để xây dựng một chuỗi của các key mà bắt (captures) dữ liệu riêng tư của ứng dụng và chính sách chia sẻ, CryptDB cho phép nhà phát triển cung cáp các ghi chú chính sách trên giản đồ SQL của ứng dụng, chỉ rõ người dùng nào (hoặc những principal khác, như các group chẳng hạn) có quyền truy cập tới từng mục dữ liệu

Chúng tôi đã thực hiện CryptDB trên cả MySQL và Postgres; thiết kế của chúng tôi và hầu hết những thực hiện của chúng tôi có thể áp dụng được với hầu hết các hệ quản trị cơ sơ dữ liệu SQL tiêu chuẩn Phân tích một cuộc theo dõi 10 ngày của 126 triệu truy vấn SQL từ nhiều ứng dụng tại MIT cho thấy rằng CryptDB có thể hỗ trợ 99.5% các phép toán (operations) trên dữ liệu mã hóa của 128,840 cột (colums) được thấy trong cuộc theo dõi Đánh giá của chúng tôi cho thấy rằng CryptDB có chi phí thấp, giảm 14.5% thông lượng (throughput) cho ứng dụng phpBB web forum, và giảm 26% cho các truy vấn từ TPC-C, so với unmodified MySQL Chúng tôi đã đánh giá độ an toàn của CryptDB trên sáu ứng dụng thực( bao gồm phpBB, phần mềm quản lý hội nghị

HotCRP [27], và ứng dụng hồ sơ y tế OpenEMR); kết quả cho thấy rằng CryptDB bảo vệ hầu hết các trường nhạy cảm với các lược đồ mã hóa bảo mật cao Việc xâu chuỗi các key mã hóa với các mật khẩu người dùng yêu cầu 11-13 chú thích giản lược độc nhất (unique schema anntotations) để thực thi các chính sách bảo mật trên hơn 20 trường nhạy cảm (bao gồm một chính sách mới trong HotCRP for handling papers in conflict with a

PC chair) và 2-7 dòng mã nguồn thay đổi cho ba ứng dụng web nhiều người dùng

Phần còn lại của tài liệu này được xây dựng như sau Trong phần 2, chúng ta sẽ thảo luận chi tiết hơn các nguy

cơ mà CryptDB chống lại Sau đó, chúng tôi sẽ mô tả thiết kế của CryptDB cho việc xử lý truy vấn mã hóa trong phần 3 và cho quá trình xâu chuỗi key với mật khẩu người dùng trong phần 4 Trong phần 5, chúng tôi trình bày một số case studies về cách các ứng dụng có thể sử dụng CryptDB, và trong phần 6, chúng tôi thảo luận về những hạn chế của thiết kế của chúng tôi, và cách mà nó có thể mở rộng Tiếp theo, chúng tôi miêu tả những thực hiện nguyên mẫu của chúng tôi trong phần 7, và đánh giá hiệu quả và độ an toàn của CryptDB,

cũng như các nỗ lực cần thiết cho các nhà phát triển ứng dụng để sử dụng CryptDB, trong phần 8 Chúng tôi so sánh CryptDB với công việc liên quan trong phần 9 và kết luận trong phần 10.

2.Security Overview

Hình 1 cho thấy kiến trúc của CryptDB và các mô hình de dọa CryptDB làm việc bằng cách chặn lại tất cả truy

vấn SQL tại một database proxy, ở đó các truy vấn được viết lại để thực thi trên dữ liệu mã hóa (CryptDB coi

như tất cả các truy vấn đi qua proxy) Proxy mã hóa và giải mã tất cả dữ liệu, và thay đổi một vài toán tử truy vấn, nhưng vấn đảm bảo ngữ nghĩa của truy vấn DBMS server không bao giờ nhận được các key giải mã ở dạng plaintext vì thế nó ko bao giờ thấy được dữ liệu nhạy cảm, đảm bảo rằng những DBA tò mò không thể truy cập tới thông tin cá nhân (mối de dọa thứ nhất)

Để bảo vệ chống lại ứng dụng, proxy, và DBMS server thỏa hiệp (mối đe dọa thứ hai), các nhà phát triển chú

thích giản đồ SQL của họ (annotate their SQL schema) để xác định những người ủy quyền (principals) khác,

các key của những người đó sẽ cho phép giải mã các phần khác nhau của cơ sở dữ liệu chúng cũng tạo một sự thay đổi nhỏ tới các ứng dụng của chúng để cung cấp các key mã hóa cho proxy, điều này được mô tả trong phần 4 Proxy xác định những phần nào của cơ sở dữ liệu nên được mã hóa bằng key nào Kết quả là CryptDB đảm bảo tính bí mật của dữ liệu thuộc về những người dùng không đăng nhập trong khi bị thỏa hiệp (ví dụ: user

2 trong Hình 1), và những ai không đăng nhập cho tới khi sự thỏa hiệp bị phát hiện và sửa chữa bởi người quản trị

Mặc dù CryptDB bảo vệ tính bí mật của dữ liệu, nó không đảm bảo tính toàn vẹn, tính mới, hay đầy đủ của kết quả được trả về cho ứng dụng Một kẻ xấu mà thỏa hiệp ứng dụng, proxy, hay DBMS server, hoặc một DBA xấu, có thể xóa bất kỳ hoặc tất cả dữ liệu được lưu trữ trên cơ sở dữ liệu Tương tự, tấn công vào máy của người dùng, như cross-site scripting chẳng hạn, là nằm bên ngoài phạm vi của CryptDB

Bây giờ chúng tôi sẽ miêu tả hai mô hình mối đe dọa được giải quyết bởi CryptDB và những đảm bảo an ninh được cung cấp dưới những mô hình mối đe dọa đó

2.1.Mối đe dọa thứ nhất: Thỏa hiệp DBMS Server - DBMS Server

Compromise

Trong mối đe dọa này, CryptDB bảo vệ chống lại một DBA tò mò hoặc kẻ tấn công bên ngoài khác với truy cập hoàn toàn tới dữ liệu được lưu trên DBMS server Mục tiêu của chúng ta là tính bí mật, không phải tính toàn

vẹn hay sẵn sàng Giả sử kẻ tấn công là bị động (passive): hắn muốn tìm hiều dữ liệu bí mật, nhưng không thay

đổi các truy vấn được sinh ra bởi ứng dụng, các kết quả truy vấn, hay dữ liệu trong DBMS Mối đe dọa này bao gồm các thỏa hiệp phần mềm DBMS, truy cập root tới các máy DBMS, và kể cả truy cập tới RAM của máy vật

lý Với sự gia tăng trong việc thống nhất cơ sở dữ liệu bên trong các trung tậm dữ liệu doanh nghiệp, lưu trữ các

cơ sở dữ liệu trên cơ sở hạ tầng điện toán đám mây công cộng, và sử dụng các DBA của bên thứ ba, mối đe dọa này đang ngày càng trở nên quan trọng

Tiếp cận CryptDB nhằm mục đích bảo vệ tính bí mật của dữ liệu chống lại mối đe dọa này bằng cách thực thi

các truy vấn SQL trên dữ liệu mã hóa trên DBMS server Proxy sử dụng các key bí mật để mã hóa toàn bộ dữ liệu được thêm vào hoặc được bao gồm trong các truy vấn được sinh ra cho DBMS Hướng tiếp cận của chúng tôi là cho phép DBMS server thực hiện việc xử lý truy vấn trên dữ liệu mã hóa như là nó thực hiện trên một cơ

sở dữ liệu không mã hóa, bằng cách cho phép nó tính toán các hàm nhất định trên các mục dữ liệu dựa trên dữ liệu mã hóa Ví dụ, nếu DBMS cần thực hiện một GROUP BY trên cột c, DBMS server sẽ có thể xác định các

mục nào trong cột đó đều bình đẳng với nhau, nhưng không phải nội dung thực tế của mỗi mục Do đó, proxy cần phải kích hoạt DBMS server để xác định các mỗi quan hệ giữa dữ liệu cần thiết để xử lý một truy vấn Bằng cách sử dụng mã hóa nhận biết SQL (SQL-aware encryption) điều chỉnh tự động các truy vấn được đưa ra, CryptDB cẩn thận xem xét những quan hệ nào nó tiết lộ giữa các bộ dữ liệu tới server Ví dụ, nếu DBMS cần thực hiện chỉ một GROUP BY trên một cột c, DBMS server không nên biết thứ tự của các mục trong cột c, cũng như không nên biết bất kỳ thông tin nào khác về các cột khác Nếu DBMS được yêu cầu thực hiện một ORDER BY, hoặc tìm MAX hoặc MIN, CryptDB tiết lộ thứ tự của các mục trong cột đó, chứ không phải cột nào khác.

Sự bảo đảm CryptDB cung cấp tính bí mật cho nội dung dữ liệu và cho các tên của các cột và các bảng;

CryptDB không che giấu cấu trúc bảng tổng thể, số hàng, các loại của các cột, hay kích thước của dữ liệu theo

byte Sự an toàn của CryptDB là không hoàn hảo: CryptDB tiết lộ cho DBMS server các mỗi quan hệ giữa các mục dữ liệu tương ứng với các lớp tính toán (classes of computation) mà các truy vấn thực hiện trên cơ sở dữ

liệu, chẳng hạn như so sánh các mục có ngang bằng nhau không (comparing item for equality), sắp xếp, hoặc thực hiện tìm kiếm từ Granularity (Granularity là mức độ mà một bộ dữ liệu hay thông tin lớn, phức tạp được chia ra thành các đơn vị nhỏ hơn) tại CryptDB nào cho phép DBMS thực hiện một lớp các tính toán là toàn bộ một cột (hoặc một nhóm của các cột được join với nhau), có nghĩa là ngay cả khi một truy vấn yêu càu các kiểm tra bằng (equality checks) cho một vài hàng, việc thực thi truy vấn đó trên server sẽ yêu cầu việc tiết lộ lớp tính toán đó (that class of computation) cho cả một cột Phần 3.1 miêu tả cách mà các lớp tính toán map với các lược

đồ mã hóa của CryptDB, và những thông tin chúng tiết lộ

CryptDB cung cấp các tính chất sau:

• Dữ liệu nhạy cảm không bao giờ tồn tại dưới dạng rõ trên DBMS server

• Thông tin bị lộ cho DBMS server phụ thuộc và các lớp tính toán được yêu cầu bởi các truy vấn của ứng dụng, tùy theo những ràng buộc mà nhà phát triển ứng dụng chỉ ra trong lược đồ (phần 3.5.1):

o Nếu ứng dụng không yêu cầu bộ lọc vị từ quan hệ (relational predicate filtering) trên một cột, không gì về nội dung dữ liệu nào bị rò rỉ (trừ kích thước của nó tính theo byte)

o Nếu ứng dụng yêu cầu equality checks trên một cột, proxy của CryptDB tiết lộ những mục lặp lại trong cột đó (biểu đồ tần suất – the histogram), nhưng không phải là các giá trị thực tế

o Nếu ưng dụng yêu cầu order checks trên một cột, proxy tiết lộ thư tự của các phần tử trong cột

• DBMS server không thể tính toán kết quả (được mã hóa) cho các truy vấn liên đến các lớp tính toán mà không được ứng dụng yêu cầu

CryptDB “tối ưu” an ninh như thế nào? Về cơ bản, tối ưu an ninh đạt được bằng các công việc gần đây trong lý thuyết mật mã cho phép bất kì tính toán toàn trên dữ liệu mã hóa [18]; tuy nhiên, những đề xuất như vậy không thực tế Ngược lại, CryptDB là thực tế, và trong phần 8.3, chúng tôi sẽ chứng minh rằng nó cũng cung cấp những bảo mật quan trọng trong thực tế Cụ thể, chúng tôi sẽ cho chỉ ra rằng tất cả hoặc hầu như tất cả các trường nhạy cảm nhất trong các ứng dụng thử nghiệm vẫn được mã hóa với các lược đồ mã hóa bảo mật cao Đối với các trường như vậy, CryptDB cung cấp tối ưu an ninh, giả sử giá trị của chúng độc lập với mô hình mà trong đó chúng được truy cập (trường hợp với các thông tin y tế, số an sinh xã hội, vv…) CryptDB không tối

ưu cho các trường đòi hỏi tiết lộ nhiều hơn các lược đồ mã hóa (encryption shemes), nhưng chúng tôi tìm ra rằng hầu hết các trường như vậy là bán nhạy cảm (semi-sensitive) (như nhãn thời gian-timestamp chẳng hạn).Cuối cùng, chúng tôi tin rằng một mô hình tấn công bị động là thực tế vì các DBAs xấu có nhiều khả năng đọc

dữ liệu, có thể khó phát hiện, hơn là thay đổi dữ liệu hoặc các kết quả truy vấn, mà có nhiều khả năng được khám phá Trong phần 9, chúng tôi trích dẫn công việc liên quan đến toàn vẹn dữ liệu mà có thể được sử dụng

trong việc bổ sung với công việc của chúng tôi Một kẻ xấu có thể chèn hoặc cập nhật dữ liệu có thể gián tiếp thỏa hiệp bảo mật Ví dụ, một kẻ xấu thay đổi một trường email trong cơ sở dữ liệu có thể có khả năng lừa ứng dụng gửi một dữ liệu của người dùng tới một địa chỉ email sai, khi người dùng yêu cầu ứng dụng gửi email cho

cố ấy một bản sao dữ liệu của chính mình Các cuộc tấn công chủ động như vậy trên DBMS thuộc mô hình đe dọa thứ hai, và chúng ta sẽ thảo luận bây giờ

2.2.Mối đe dọa thứ hai: Các mối đe dọa tùy ý - Arbitrary Threats

Bây giờ chúng tôi sẽ miêu tả mỗi đe dọa thứ hai khi các cơ sở hạ tầng server ứng dụng, proxy, và DBMS server

có thể bị thỏa hiệp tùy ý Cách tiếp cận trong mối đe dọa thứ nhất là không đủ vì kẻ xấu bây giờ có thể đạt được truy cập tới các key được sử dụng để mã hóa toàn bộ cơ sở dữ liệu

Giải pháp là mã hóa các mục dữ liệu khác nhau (ví dụ, dữ liệu thuộc về các user khác nhau) với các key khác nhau Để xác định key nào được sử dụng cho mỗi mục dữ liệu, các nhà phát triển chú thích giản đồ cơ sử dữ liệu của ứng dụng để thể hiện các chính sách bảo mật tốt hơn Một DBA tò mò vẫn không thể có được dữ liệu

cá nhân bằng cách đánh cắp trên DBMS serve (mối đe dọa thứ nhất), và thêm vào đó, kẻ xấu thỏa hiệp server ứng dụng hoặc proxy bây giờ có thể giải mã chỉ dữ liệu của những user đang đăng nhập (những dữ liệu đó được lưu trữ trong proxy) Dữ liệu của những người hiện tại không hoạt động sẽ được mã hóa với các key mà

kẻ xấu không biết, và sẽ được giữ bí mật

Trong dạng này, CryptDB cung cấp những đảm bảo mạnh khi đối mặt với các thỏa hiệp tùy ý phía server, bao gồm cả những người đạt được truy cập root tới ứng dụng hay proxy CryptDB rò rỉ các dữ liệu của người dùng đang hoạt động trong suốt thời gian bị thỏa hiệp “trong suốt thời gian bị thỏa hiệp” nghĩa là khoảng thời gian từ khi bắt đầu của thỏa hiệp cho đến khi bất kỳ dấu viết của thỏa hiệp nào được xóa khỏi hệ thống Với một tấn công SQL injection thực tế, khoảng thời gian thỏa hiệp là thời gian kẻ tấn công thực hiện các truy vấn SQL Trong ví dụ trên, khi kẻ xấu thay đổi địa chỉ email của một user trong cơ sở dữ liệu, chúng ta xem xét hệ thống

bị xâm nhập cho đến khi địa chỉ email của kẻ tấn công vẫn tồn tại trong cơ sở dữ liệu

3.Các truy vấn trên dữ liệu mã hóa

Phần này miêu tả cách mà CryptDB thực thi các truy vấn SQL trên dữ liệu mã hóa Mô hình mối đe dọa trong phàn là là mối đe dọa thứ nhất từ phần 2.1 Các máy DMBS và những người quản trị không đáng tin cậy,

nhưng ứng dụng và proxy được tin cậy

CryptDB cho phép DBMS server thực thi các truy vấn SQL trên dữ liệu mã hóa gần như giống với nó được thực thi cùng các truy vấn trên dữ liệu rõ Các ứng dụng có sẵn không cần thiết thay đổi Kế hoạch truy vấn của DMBS cho truy vấn mã hóa thường giống như đối với các truy vấn nguyên gốc, ngoại trừ các toán tử

(operators) bao gồm truy vấn, chẳng hạn như lựa chọn (selections), phép chiếu (projections), kết hợp (joins), tập hợp (aggregates), và xếp thứ tự (ordering), được thực hiện trên bản mã, và sử dụng các toán tử sửa đổi trong một số trường hợp

Proxy của CryptDB lưu trữ một secret master key MK, lược đồ cơ sở dữ liệu, và các lớp(layers) mã hóa hiện tại

của tất cả các cột DBMS server thấy một lược đồ ẩn danh (trong tên bảng và tên cột nào được thay thế bởi các định danh mờ - in which table and column names are replaced by opaque identifiers), dữ liệu người dùng mã hóa, và một vài bảng phụ được CryptDB sử dụng CryptDB cũng trang bị cho server với các chức năng người dùng định nghĩa cụ thể (CryptDB-specific user-defined functions - UDFs) cho phép server tính toán trên các bản mã cho các phép toán nhất định

Việc xử lý một truy vấn trong CryptDB gồm 4 bước:

• Ứng dụng sinh ra một truy vấn, proxy chặn lại và viết lại: để bảo vệ danh tính của các bảng và cột, nó tổ chức lại mỗi tên bảng, tên cột, và , sử dụng master key MK, mã hóa mỗi hằng số (constant) trong truy vấn với một lược đồ mã hóa phù hợp nhất cho phép toán (operation) mong muốn (phần 3.1)

• Proxy kiểm tra xem liệu DBMS server có được đưa các key để điều chỉnh các lớp mã hóa trước khi thực thi truy vấn, và nếu có, sinh ra một truy vấn UPDATE tại DBMS server để gọi một UDF để điều chỉnh lớp mã hóa của các cột thích thợp (phần 3.2)

• Proxy chuyển tiếp truy vấn được mã hóa đến DBMS server, nơi thực hiện nó sử dụng SQL tiêu chuẩn (đôi khi gọi UDFs cho các hàm tập hợp (aggregation) hoặc tìm kiếm từ khóa)

• DBMS server trả về kết quả truy vấn (được mã hóa), proxy sẽ giải mã và trả về cho ứng dụng

3.1.SQL-aware Encryption

Bây giờ chúng ta sẽ mô tả các loại mã hóa mà CryptDB sử dụng, bao gồm một số các hệ mật hiện có, một tối ưu hóa của một lược đồ gần đây, và một cơ sở mật mã (hoặc mật mã cơ sở - cryptographic primitive) mới cho các kết hợp (joins) Với mỗi loại mã hóa, chúng tôi giải thích đặc điểm an toàn mà CryptDB yêu cầu từ nó, chức năng của nó, và làm thế nào để nó được thực hiện

Random (RND) RND cung cấp bảo mật tối đa trong CryptDB: an toàn ngữ nghĩa dưới một tấn công lựa chọn

bản rõ thích ứng (indistinguishability under an adaptive chosen-plaintext attack - IND-CPA)(tham khảo IND, tham khảo CPA, tham khảo 2); lược đồ (scheme) là xác suất, có nghĩa là hai giá trị bằng nhau được ánh xạ tới hai bản mã khác nhau với xác suất trội hơn (overwhelming probability) Mặt khác, RND không cho phép bất cứ

sự tính toán nào được thực hiện hiệu quả trên bản mã Một cấu trúc hiệu quả của RND là sử dụng mã hóa khối như AES hoặc Blowfish trong chế độ CBC với một vector khởi tạo ngẫu nhiên (IV) (chúng tôi hầu như sử dụng AES, ngoại trừ các giá trị nguyên chúng tôi sử dụng Blowfish với kích thước khối là 64 bit vì khối 128 bit của AES sẽ gây ra bản mã dài hơn đáng kể)

Kể từ đó, trong mô hình mối đe dọa này, CryptDB giả định server không thay đổi kết quả, CryptDB không yêu cầu một cấu trúc IND-CCA2 (tham khảo CCA, tham khảo IND-CCA) mạnh mẽ hơn (ngăn chặn tấn công lựa chọn bản mã) Tuy nhiên, nó sẽ được đơn giản hóa để sử dụng một thực hiện IND-CCA2 an toàn của RND thay vào đó, như một mã hóa khối ở chế độ UFE [13], nếu cần thiết

Tất định – Deterministic (DET) (“thuật toán” chia làm hai loại : thuật toán đơn định – Deterministic – là thuật toán mà kết quả của mọi phép toán đều được xác định duy nhất; thuật toán không đơn định – NoDeterministic –

là thuật toán có ít nhất một phép toán mà kết quả của nó là không duy nhất) DET có một đảm bảo hơn yếu hơn, nhưng nó vẫn cung cấp bảo mật mạnh mẽ: nó chỉ rò rỉ các giá trị mã hóa tương ứng với giá trị cùng một dữ liệu, bằng cách sinh ra cùng bản mã cho cùng bản rõ Lớp mã hóa này cho phép server thực hiện các kiểm tra bình đẳng (equality checks), có nghĩa là nó có thể thực hiện các lựa chọn (selects) với equality predicates, equality joins, GROUP BY,COUNT, DISTINCT,…

Trong giới hạn mật mã, DET phải là một phép hoán vị giả ngẫu nhiên (pseudo-random permutation – PRP –

tham khảo 1, tham khảo 2 hay còn gọi là Block ciphers) [20] Với các giá trị 64 bit và 128 bit, chúng tôi sử dụng một mã hóa khối với một kích thước khối phù hợp (Blowfish và AES tương ứng); chúng tôi tạo ra giả định thông thường rằng thuật toán má hóa khối AES và Blowfish là PRPs Chúng tôi đệm các giá trị nhỏ hơn 64 bít, nhứng với dữ liệu dài hơn một khối AES 128 bit, chế độ CBC tiêu chuẩn của phép toán rò rỉ tiền tố bằng nhau (ví dụ, nếu hai mục dữ liệu có một tiền tố giống hệt nhau dài ít nhất 128 bit) Để tránh ván đề này, chúng tôi sử dụng AES với biến thể của chế độ CMC [24], có thể gần như coi là một vòng (round) của CBC, theo sau các

vòng khác của CBC với các khối theo thứ tự ngược lại Vì mục tiêu của DET là để reveal equality, chúng tôi sử dụng một zero IV (hoặc “tinh chỉnh – tweak” [24]) cho sự thực hiện AES-CMC của DET.

Mã hóa duy trì thứ tự - Order-preserving encryption (OPE) (tham khảo1, tham khảo 2) OPE cho phép

quan hệ thứ tự giữa các mục dữ liệu được thiết lập dựa theo các giá trị mã hóa của chúng, mà không tiết lộ dữ liệu của chính nó Nếu x < y, thì OPEK(x) < OPEK(y), cho bất cứ key bí mật K nào Vì thế, nếu một cột được mã

hóa với OPE, server có thể thực hiện nhiều truy vấn khi các hằng số được mã hóa đã cho OPEK(c1) và OPEK(c2) tương ứng với khoảng [c1, c2] Server cũng có thể thực hiện ORDER BY, MIN, MAX, SORT, vv…

OPE là một mô hình mã hóa yếu hơn DET vì nó hiển thị thứ tự Do đó, CryptDB proxy sẽ chỉ hiển thị các cột được mã hóa OPE cho server nếu những người dùng yêu cầu thứ tự các truy vấn trên các cột đó OPE có các đảm bảo an toàn chứng minh được [4]: mã hóa tương đương với một ánh xạ ngẫu nhiên mà giữ theo thứ tự

Mô hình chúng tôi sử dụng [4] là một mô hình an toàn có thể chứng minh được đầu tiên Cho đến khi CryptDB xuất hiện, không có thực hiện cũng như biện pháp thực tiến nào của mô hình Việc thực hiện trực tiếp của mô hình này mất 25 ms trên mỗi mã hóa của một số nguyên 32 bít trên một bộ xử lý Intel 2.8 GHz Q9550 Chúng tôi cải tiến thuật toán bằng cách sử dụng cây tìm kiếm nhị phân AVL để mã hóa hàng loạt (ví dụ, các tải cơ sở

dữ liệu – database loads), giảm thiểu chi phí của má hóa OPE đến 7 ms trên mỗi mã hóa mà không làm ảnh hưởng tới an toàn của nó Chúng tôi cũng thực hiện một hypergeometric sampler mà nằm trong lõi của OPE, porting a Fortran implementation from 1988 [25]

Mã hóa đồng cấu - Homomorphic encryption (HOM) (tham khảo 1, tham khảo 2, tham khảo 3) HOM là

một lược đồ mã hóa xác suất an toàn (IND-CPA-secure), cho phép server thực hiện các tính toán trên dữ liệu mã hóa với kết quả cuối dùng được giải mã tại proxy Trong khi mã hóa đồng cấu đầy đủ phục vụ chậm [10], mã hóa đồng cấu cho các phép toán cụ thể là hiệu quả Để hỗ trợ tổng kết, chúng tôi đã thực hiện hệ mật Paillier [35] Với Paillier,việc nhân các mã hóa của hai giá trị dẫn tới kết quả trong một mã hóa của tổng các giá trị, ví

dụ, HOMK(x) * HOMK(y) = HOMK(x + y), phép nhân được thực hiện theo modulo một vài giá trị khóa công khai Để tính tổng SUM (SUM aggregates), proxy thay thế SUM với các lời gọi tớ một UDF mà thực hiện phép nhân Paillier trên một cột được mã hóa với HOM HOM cũng có thể được sử dụng để tính toán giá trị trung bình bằng cách DBMS server trả về giá trị tổng (sum) và đếm (count) riêng biệt, và cho việc tăng các giá trị (ví

dụ, SET id=id+1) , mà chúng tôi xây dựng ngay (on wich we elaborate shortly).

Với HOM, bản mã là 2048 bít Theo lý thuyết, nó có thể đóng gói nhiều giá trị từ một hàng đơn lẻ vào một bản

mã HOM cho hàng đó, sử dụng lược đồ của Ge và Zdonik [17], dấn tới kết quả là một khoảng trống khấu hao gấp đôi (ví dụ một giá trị 32 bit chiếm 64 bit) cho một bảng với nhiều cột được mã hóa HOM Tuy nhiên, chúng tôi đã không thực hiện tối ưu hóa này trong mẫu thử nghiệm của chúng tôi Sự tối ưu hóa này cũng sẽ làm phức tạp các phép toán UPDATE hàng cục bộ (This optimization would also complicate partial-row UPDATE

operations) mà thiết lập lại một số - nhưng không phải là tất cả - các giá trị được đóng gói vào một bản mã HOM

Join (JOIN and OPE-JOIN) Một lược đồ mã hóa riêng là cần thiết để cho phép các equality join giữa hai cột,

vì chúng tôi sử dụng các key khác nhau cho DET để ngăn chặn các mối tương quan giữa các cột JOIN cũng hỗ trợ tất cả các phép toán được DET cho phép, và cũng cho phép server xác định những giá trị nhắc lại giữa hai cột OPE-JOIN cho phép tham gia theo các mối liên hệ thứ tự (OPE-JOIN enables joins by order relations) Chúng tôi cung cấp một lược đồ mã hóa mới cho JOIN và chúng ta sẽ thảo luận về nó ở phần 3.4

Hình 2: Các lớp mã hóa Onion và các lớp tính toán chúng cho phép (Onion encryption layers and the classes of

computation they allow) Các tên Onion viết tắt cho các phép toán chúng cho phép tại một vài lớp của chúng (Equality, Order, Search, và Addition) Trong thực tế, một vài onion hoặc các lớp onion có thể bỏ qua, phụ thuộc vào loại cột hoặc những chú giải lược đồ(schema annotations) được cung cấp bởi các nhà phát triển ứng dụng (phần 3.5.2) DET và JOIN thường kết hợp trong một lớp onion đơn lẻ, vì JOIN là một sự nối tiếp cua

DET và JOIN-ADJ (phần 3.4) Một IV ngẫu nhiên cho RND (3.1), được chia sẻ bởi các lớp RND là Eq và Ord,

cũng được lưu trữ cho từng mục dữ liệu

Word search (SEARCH) SEARCH được sử dụng để thực hiện các tìm kiếm trên văn bản được mã hóa để hỗ

trợ các phép toán như LIKE của MySQL chẳng hạn Chúng tôi đã thực hiện giao thức mã hóa của Song và các đồng nghiệp của ông [46], mà trc đây họ không thực hiện; chúng tôi cũng sử dụng giao thức của họ theo một cách khác, dẫn tới kết quả là một đảm bảo an toàn tốt hơn Cho mỗi cột cần SEARCH, chúng tôi chia văn bản thành các từ khóa sử dụng các ký tự phân cách tiêu chuẩn (hoặc sử dụng một chức năng khai thác từ khóa đặc biệt được quy định bởi người phát triển lược đồ) Sau đó chúng tôi loại bỏ những gì lặp lại trong những từ này, hoán vị ngẫu nhiên vị trí của các từ, và rồi mã hóa mỗi từ sử dụng lược đồ của Song, đệm (padding) mỗi từ cho cùng kích thước SEARCH an toàn gần như RND: má hóa ko để lộ cho DBMS server có một từ nào đó lặp đi lặp lại trong nhiều hàng, nhưng nó rò rỉ số lượng từ khóa được mã hóa với SEARCH; kẻ xấu có thể ước lượng

số lượng các từ riêng biệt hoặc trùng lặp (ví dụ, bằng cách so sánh kích thước của bản mã SEARCH và RND với cùng dữ liệu)

Khi người dùng thực hiện một truy vấn như SELECT * FROM messages WHERE msg LIKE "% alice %" chẳng hạn, proxy đưa cho DBMS server một token, là một mã hóa của alice Server không thể giải mã token

để tìm ra từ cơ bản (underlying word) Sử dụng một hàm người dùng định nghĩa, DBMS server kiểm tra xem bất cứ các mã hóa từ trong bất cứ thông điệp nào có phù hợp với token hay không Trong cách tiếp cận của chúng tôi, tất cả server sẽ tìm hiểu từ việc tìm kiếm xem liệu một token có phù hợp (matched) với một thông điệp hay không, và điều này chỉ xảy ra đối với các token được người dùng yêu cầu Server không tìm hiểu những thông tin tương tự khi trả về tập kết quả thiếp những người dùng, do đó các lược đồ tìm kiếm tổng thể để

lộ ra ít thông tin cần thiết nhất để trả về kết quả

Chú ý răng SEARCH cho phép CryptDB chỉ thực hiện các tìm kiếm từ khóa đầy đủ từ (full-word keyword searches); nó không thể hỗ trợ các biểu thức chính quy tùy ý Cho các ứng dụng yêu cầu tìm kiếm nhiều từ liền

kề, CryptDB cho phép nhà phát triển ứng dụng vô hiệu hóa loại bỏ trùng lặp và sắp xếp lại bằng cách chú giải lược đồ(annotating the schema), mặc dù đây không phải là mặc định

3.2.Adjustable Query-based Encryption

Một phần quan trọng của thiết kế của CryptDB là adjustable query-based encryption, tự động điều chỉnh lớp mã

hóa trên DBMS server Mục đích của chúng tôi là sử dụng các lược đồ mã hóa an toàn nhất mà có thể chạy các truy vấn được yêu cầu Ví dụ, nếu ứng dụng không sinh ra truy vấn nào so sánh các mục dữ liệu trong một cột, hoặc sắp xếp cột, cột phải được mã hóa với RND Đối với những cột yêu cầu các equality check nhưng không yêu cầu inequality check, DET cũng đủ Tuy nhiên, tập truy vấn không phải lúc nào cũng được biết trước Do

đó, chúng ta cần một lược đồ có khả năng thích ứng mà tự động điều chỉnh các chiến lược mã hóa

Ý tưởng của chúng tôi là mã hóa từng mục dữ liệu trong một hoặc nhiều onion: tức là, mỗi giá trị sẽ được bọc

trong các lớp mã hóa ngày càng mạnh hơn, như minh họa trong hình 2 và 3 Mỗi lớp của mỗi onion cho phép mỗi loại chức năng như được giải thích trong tiểu mục trước Ví dụ, các lớp ngoài cùng như RND và HOM cung cấp bảo mật tối đa, trong khi các lớp bên trong như OPE cung cấp nhiều chức năng hơn

Trong thực tế cần nhiều onion, vì các phép toán được hỗ trợ bởi các lược đồ mã hóa khác nhau không luôn luôn theo thứ tự một cách hoàn toàn, và vì cần phải cân nhắc hiệu suất thực hiện (kích thước của bản mã và thời gian

mã hóa cho các lớp onion lồng vào nhau) Phụ thuộc vào loại dữ liệu (và bất cứ chú thích (annotations) được cung cấp bởi nhà phát triển ứng dụng trên lược đồ cơ sở dữ liệu, như được thảo luận trong phần 3.5.2),

CryptDB có thể không duy trì tất cả các onion cho mỗi cột Ví dụ, Search onion không có ý nghĩa cho các số nguyên (integers), và Add onion không có ý nghĩa cho các chuỗi (strings).

Với mỗi lớp của mỗi onion, proxy sử sử dụng cùng một key cho các giá trị đang mã hóa trong cùng một cột, và các key khác nhau trên các bảng, các cột, các onion, và các lớp onion khác nhau Việc sử dụng cùng một key cho tất cả các giá trị trên một cột cho phép proxy thực hiện các phép toán trên một cột mà không phải tính toán các key riêng biệt cho từng hàng mà sẽ được thao tác (chúng tôi sử dụng các key mã hóa finer-grained trong phần 4 để giảm khả năng tiềm ẩn dữ liệu bị tiết lộ trong trường hợp một ứng dụng haowcj proxy server bị thỏa hiệp) Việc sử dụng các key khác nhau trên các cột ngăn chặn server tìm ra bất kỳ mối quan hệ thêm nào Tất cả

những key này được bắt nguồn từ masterk key MK Ví dụ, với bảng t, cột c, onion o, và lớp mã hóa l, proxy sử

dụng key

Kt,c,o,l = PRP MK (bảng t, cột c, onion o, lớp l), (1)

với PRP là một hoán vị giả ngẫu nhiên – pseudo random permutation (ví dụ, AES)

Mỗi onion bắt đầu được mã hóa với lược đồ mã hóa an toàn nhất (RND cho onion Eq và Ord, HOM cho onion Add, và SEARCH cho onion Search) Khi proxy nhận các truy vấn SQL từ ứng dụng, nó xác định xem các lớp

mã hóa nào cần được gỡ bỏ Gán một vị từ (predicate) P trên cột c cần thiết để thực thi một truy vấn trên server, proxy đầu tiên thiết lập lớp onion nào là cần thiết để tính toán P trên c nếu mã hóa của c không phải là đã ở một lớp onion mà cho phép P, proxy bóc tách các lớp onion để cho phép P trên c, bằng cách gửi key onion tương

ứng tới server Proxy không bao giờ giải mã dữ liệu qua các lớp onion mã hóa kém an toàn (hoặc qua một vài lớp mức khác, nếu được chỉ định bởi nhà phát triển ứng dụng trong lược đồ, 3.5.1)

CryptDB thực hiện việc giải mã lớp onion sử dụng UDFs chạy trên DBMS server Ví dụ, trong hình 3, để giải

mã onion Ord của cột 2 trong bảng 1 tới lớp OPE, proxy sinh ra truy vấn sau tới server sử dụng

DECRYPT_RND UDF:

UPDATE Table1 SET

C2-Ord = DECRYPT_RND(K, C2-Ord, C2-IV)

với K là key phù hợp được tính toán từ phương trình (1) Tại cùng thời điểm, proxy cập nhật trạng thái bên

trong của chính nó để ghi nhớ rằng cột C2-Ord trong Table1 bây giờ đang ở lớp OPE trong DBMS Mỗi giải mã

cột phải được bao gồm trong một giao dịch để tránh những vấn đề tính nhất quán với các client truy cập các cột đang được điều chỉnh

Hình 3:Bố trí dữ liệu tại máy chủ (Data layout at the server) Khi ứng dụng tạo bảng được hiển thị ở bên trái,

bảng được tạo tại DBMS server là một bảng được hiển thị ở bên phải Bản mã được hiển thị là không đủ độ dài.Chú ý rằng việc giải mã onion được thực hiện toàn bộ bởi DBMS server Trong trạng thái ổn định, không giải

mã ở phía server nào là cần thiết, bởi vì việc giải mã onion xảy ra chỉ khi một lớp mới của tính toán được yêu cầu trên một cột Ví dụ, sau một equality check được yêu cầu trên một cột và server đưa cột đó vào lớp DET, cột vẫn tồn tại trong trạng thái đó, và các truy vấn tương lai với các equality check không yêu cầu giải mã This property is the insight into why CryptDB’s overhead is modest in the steady state (see 8): the server mostly performs typical SQL processing

3.3 Thực thi trên dữ liệu mã hóa - Executing over Encrypted Data

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 3, một tham

chiếu đến cột Name cho một equalyti comparison sẽ được thay thế với một tham chiếu tới cột C2-Eq.

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 Eq.

C2-Cuối cùng, server thay thế các toán tử nhất định với các bản sao dựa trên hàm người dùng định nghĩa based counterparts) Ví dụ, toán tử tính tổng 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 việc thêm HOM của các bản mã Các toán tử đẳng thức và thứ tự (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

(UDF-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

Sự thực thi truy vấn đọc – Read query execution Để hiểu sự thực thi truy vấn trên các bản mã, xem xét lược

đồ ví dụ trong Hình 3 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, như trong Hình 2 Tại thời điểm này, server có không thể biết gì về dữ liệu khác ngoài số cột, số hàng, và kích thước dữ liệu

Để minh họa khi các lớp onion được gỡ bỏ, xem xét truy vấn:

SELECT ID FROM Employees WHERE Name = ‘Alice’,

mà yêu cầu giảm mã hóa của Name tới lớp DET Để thực thi truy vấn này, proxy đầu tiên sinh ra truy vấn

UPDATE Table1 SET

C2-Eq = DECRYPT_RND(K T1,C2,Eq,RND , C2-Eq, C2-IV),

với cột C2 tương ứng với Name Proxy sau đó sinh ra

SELECT C1-Eq, C1-IV FROM Table1 WHERE C2-Eq = x7 d,

Với cột C1 tương ứng với ID, và x7 d là mã hóa Eq onion của “Alice” với các key KT1,C2,Eq,JOIN và KT1,C2,Eq,DET

(xem Hình 2) 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 Cuối cùng, proxy giải mã các kết quả từ server sử dụng các key K T1;C1;Eq;RND, K T1;C1;Eq;DET, và K T1;C1;Eq;JOIN, thu được kết quả 23, và trả nó về cho ứng dụng

Nếu truy vấn tiếp theo là SELECT COUNT(*) FROM Employees WHERE Name = ‘Bob’, không cần thiết phải giải mã ở phía server, và proxy trực tiếp sinh ra truy vấn SELECT COUNT(*) FROM Table2 WHERE C2-Eq = xbb 4a, với xbb 4a là mã hóa Eq onion của “Bob” sử dụng K T1;C2;Eq;JOIN và K T1;C2;Eq;DET.

Sự thực thi truy vấn viết – Write query exexution Để 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ị ngữ - predicates) (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 tiến xử lý nào Cho 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ố (constant), 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 đó

Trường hợp còn lại là một UPDATE mà thiết lập một giá trị cột dựa vào một giá trị cột đang tồn tại, như

salary=salary+1 chẳng hạn Một cập nhật như vậy phải được thực hiện sử dụng HOM, để xử lý bổ sung Tuy

nhiên, làm như vậy, các giá trị trong các onion OPE và DET sẽ trở nên cũ Thực tế, bất cứ lược đồ mã hóa giả định nào (hypothetical encryption scheme) mà đồng thời cho phép bổ sung và so sánh trực tiếp trên bản mã là không an toàn: nếu một server độc hại có thể tính toán thứ tự của các mục, và có thể tăng giá trị lên một, server

có thể liên tục thêm một vào mỗi trường (add one to each field homomorphically – homomorphically là một sự chuyển đổi của một bộ sang một bộ khác mà vẫn giữ nguyên trong bộ thứ hai các phép toán giữa các thành viên của bộ đầu tiên) cho đến khi nó trở nên bằng với một vài giá trị khác trong cùng một cột Điều này sẽ cho phép server tính toán sự khác nhau giữa hai giá trị trong cơ sở dữ liệu, mà gần như tương đương với các giá trị của chúng đã biết

Có hai cách tiếp cân để cho phép các cập nhật dựa trên các giá trị cột đang tồn tại Nếu một cột được tăng lên và sau đó chỉ được chiếu ra (projected) (không so sánh nào được thực hiện trên nó), giải pháp đơn giản: khi một

truy vấn yêu cầu giá trị của trường này, proxy phải yêu cầu bản mã HOM từ Add onion, thay vì các bản mã từ

các onion khác, vì giá trị HOM là mới nhất Ví dụ, cách tiếp cận này áp dụng với các truy vấn tăng (increment queries) trong TPC-C Nếu một cột được sử dụng trong các so sánh sau khi nó được tăng lên, giải pháp là thay thế truy vấn cập nhật với hai truy vấn: một SELECT của các giá trị cũ để được cập nhật, mà proxy tăng mà mã hóa một cách phù hợp, tiếp theo là một UPDATE thiết lập các giá trị mới Chiến lược này sẽ hoạt động tốt cho các cập nhật mà ảnh hưởng đến một số lượng nhỏ các hàng

Các đặc điểm DMBS khác – Other DBMS features 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õ, với không có sự thay đổi nào Đối với các giao dịch (transactions), proxy gửi các bất kỳ truy vấn BEGIN, COMMIT, và ABORT nào tới DBMS Vì các toán tử SQL xử lý các giá trị NULL khác với các giá trị không phải là NULL, CryptDB để lộ ra các giá trị NULL cho DBMS mà không mã hóa CryptDB hiện tại