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 dễ bị đánh cắp thông tin nhạy cảm kẻ xấu khai thác lỗi phần mềm để truy cập tới liệu cá nhân, quản trị viên tò mò có ý đồ xấu thu thập làm rò rỉ liệu CryptDB hệ thống cung cấp tính bảo mật chứng minh chống lại công vào ứng dụng sở liệu SQL Nó hoạt động dựa việc thực truy vấn SQL liệu mã hóa sử dụng tập hợp lược đồ mã hóa SQL hiệu (It works by executing SQL queries over encrypted data using a collection of efficient SQL-aware encryption schemes) CryptDB kết hợp key mã hóa với mật người dung, mục liệu (a data item) giải mã cách sử dụng mật người sử dụng truy cập vào liệu Kết là, quản trị viên sở liệu không truy cập để giải mã liệu, kể tất server bị thỏa hiệp, đối phương giải mã liệu người dùng không đăng nhập Một phân tích theo dõi 126 triệu truy vấn SQL từ server MySQL cho thấy CryptDB hộ trợ 95.5% phép toán sở liệu mã hóa 128,840 cột thấy Đánh giá CryptDB có chi phí thấp, giảm 14.5% thông lượng (throughput) cho phpBB, ứng dụng web forum, 26% cho 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 vấn đề quan trọng, đặc biệt ứng dụng trực tuyến [40] Đối phương khải thác lỗ hổng bảo mật phần mềm để truy cập trái phép vào server [32]; quản trị viên tò mò hay có ý đồ xấu nhà cung cấp hosting ứng dụng ăn cắp liệu cá nhân [6]; kẻ công truy cập vật lý vào server truy cập tất liệu đĩa nhớ [23] Một hướng để giảm thiểu tổn hại gây server bị thỏa hiệp mã hóa liệu nhạy cảm, SUNDR [28], SPORC[16], Depot [30], chạy tất tính toán (logic ứng dụng) client Không may nhiều ứng dụng quan trọng không tiếp cận theo cách này, bao gồm database-backed web site mà xử lý truy vấn để sinh liệu cho người dùng, ứng dụng mà tính toán lượng lớn liệu Ngay phương pháp đảm bảo, việc chuyển đổi ứng dụng phía server (serverside) có sang dạng gặp khó khăn Một cách tiếp cận khác xem xét giải pháp theo lý thuyết mã hóa đồng cấu (homomorphic encryption) hoàn toàn [19], cho phép server tính toán hàm (functions) tùy ý liệu mã hóa, client xem liệu mã hóa Tuy nhiên mã hóa đồng cấu hoàn toàn tốn theo orders of magnitude [10, 21] Bài viết trình bày CryptDB, hệ thống nghiên cứu (explores) điểm thiết kế trung gian (intermediate design point) để cung cấp bảo mật cho ứng dụng sử dụng hệ quản trị sở liệu (DBMSes) CryptDB tận dụng cấu trúc điển hình database-backen application, bao gồm server DBMS server ứng dụng riêng biệt, thể Hình 1; server ứng dụng riêng biệt chạy code ứng dụng đưa truy vấn DBMS thay cho nhiều người dùng Cách tiếp cận CryptDB để thực thi truy vấn liệu mã hóa, điều làm thực tế SQL sử dụng tập xác định toán tử (operators), toán tử có khả hỗ trợ hiệu liệu mã hóa Hình 1: Kiến trúc CryptDB bao gồm phần: database proxy unmodified DBMS CryptDB sử dụng hàm người dùng định nghĩa (user-defined functions – UDFs) để thực tính toán mật mã DBMS Các hộp chữ nhật vuông bo tròn đại diện tiến trình liệu tương ứng Các hình có màu đậm thành phần thêm vào CryptDB Các đường nét đứt cho thấy tách biệt máy tính người dùng, server ứng dụng, server chạy proxy sở liệu CryptDB (nó thường giống server ứng dụng), DBMS server CryptDB giải hai loại đe dọa, hiển thị đường chấm Trong mối đe dọa thứ nhất, quản trị viên sở liệu tò mò với truy cập hoàn toàn tới DBMS server dòm ngó liệu cá nhân, trường hợp CryptDB ngăn chặn DBA truy cập vào thông tin cá nhân Trong mối đe dọa thứ hai, kẻ xấu đạt đượt kiểm soát hoàn toàn phần mềm phần cứng ứng dụng, proxy, DBMS server, trường hợp CryptDB đảm bảo kẻ xấu không thẻ có liệu thuộc người đung chưa đăng nhập (ví dụ: user 2) CryptDB giải hai mối đe dọa Mối đe dọa người quản trị sở liệu tò mò (curious database administrator – DBA) người cố gắng tìm hiểu liệu cá nhân (ví dụ ghi sức khỏe,các báo cáo tài chính, thông tin nhân) cách đánh cắp server DBMS;tại đây, CryptDB ngăn chặn DBA tìm liệu cá nhân Mối đe dọa thứ hai kẻ công đạt quyền điều khiển hoàn toàn ứng dụng server DBMS Trong trường hợp này, CryptDB cung cấp đảm bảo cho người dùng đăng nhập vào ứng dụng công xảy ra, đảm bảo bí mật liệu cho người dùng đăng xuất Có hai thách thức chiến chống lại mối đe dọa Thách thức sức ép việc tối giản hóa thông tin bí mật tiết lộ cho server DBMS khả thực thi có hiệu loạt truy vấn Các phương pháp tiếp cận để tính toán liệu mã hóa chậm không cung cấp đủ tính bí mật, thảo luận phần Mặt khác, việc mã hoa liệu với hệ thống mã hóa mạnh, AES, ngăn chặn server DBMS thực nhiều truy vấn SQL, truy vấn số lượng nhân viên phận “sales” tên nhân viên có số lương lớn $60,000 Trong trường hợp này, giải pháp thực tế server DBMS truy cập tới key mã hóa, điều cho phép kẻ xấu đạt truy cập tới toàn liệu Thách thức thứ hai tối thiểu liệu bị rò rỉ kẻ xấu thỏa hiệp server ứng dụng với server DBMS Vì việc tính toán tùy ý liệu mã hóa không thực tế, ứng dụng phải có khả truy cập liệu giải mã Do khó khăn đảm bảo ứng dụng bị thỏa hiệp thu lượng giới hạn liệu giải mã Giải pháp gán cho người dùng key mã hóa sở liệu khác cho liệu họ không thực cho ứng dụng với liệu chia sẻ, trang web bảng tin hội nghị CryptDB giải thách thức ba ý tưởng chính: • • • Đầu tiên thực thi truy vấn SQL liệu mã hóa CryptDB thực ý tưởng cách sử dụng chiến lược mã hóa nhận biết SQL (SQL-aware encryption strategy) tận dụng thực tế tất truy vấn SQL tạo thành từ tập xác định toán tử nguyên thủy, kiểm tra đẳng thứcequality check, so sánh thứ tự-oder comparison, tính tổng- aggregates (sums) , kết hợp-join Bằng cách sửa lại cho phù hợp lược đồ mã hóa biết (cho equality, additions, odder checks) sử dụng phương pháp mã hóa bảo quản riêng tư (privacy-pereserving) cho joins, CryptDB mã hóa mục liệu theo cách mà cho phép DBMS thực thi liệu chuyển đổi CryptDB hiệu chủ yếu sử dụng mã hóa đối xứng, tránh mã hóa đồng cấu đầy đủ (fully homomorphic encryption), chạy phần mềm DBMS không chỉnh sửa (bằng cách sử dụng hàm chức người dùng định nghĩa) Kỹ thuật thứ hai điều chỉnh mã hóa dựa truy vấn (adjustable query-based encryption) Một vài lược đồ mã hóa làm rò rỉ thông tin liệu cho server DBMS nhiều số khác, yêu cầu xử lý truy vấn định Để tránh tiết lộ tất mã hóa 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 mục liệu cho nào, tùy thuộc vào truy vấn quan sát lúc chạy Để thực điều chỉnh cách hiệu quả, CryptDB sử dụng onions of encryption Onions cách để lưu trữ cách chặt chẽ nhiều mã onion khác sở liệu để tránh chi phí việc mã hóa lại (re-encryptions) Ý tưởng thứ ba xâu chuỗi key mã hóa với mật người dùng, để mục liệu sở liệu giải mã thông qua chuỗi key bắt nguồn từ mật số người dùng truy cập vào liệu Kết người dùng không đăng nhập vào ứng dụng, kẻ xấu mật người dùng, kẻ xấu giải mã liệu người dùng, kể server DBMS server ứng dụng bị thỏa hiệp hoàn toàn Để xây dựng chuỗi key mà bắt (captures) liệu riêng tư ứng dụng sách chia sẻ, CryptDB cho phép nhà phát triển cung cáp ghi sách giản đồ SQL ứng dụng, rõ người dùng (hoặc principal khác, group chẳng hạn) có quyền truy cập tới mục liệu Chúng thực CryptDB MySQL Postgres; thiết kế hầu hết thực áp dụng với hầu hết hệ quản trị sơ liệu SQL tiêu chuẩn Phân tích theo dõi 10 ngày 126 triệu truy vấn SQL từ nhiều ứng dụng MIT cho thấy CryptDB hỗ trợ 99.5% phép toán (operations) liệu mã hóa 128,840 cột (colums) thấy theo dõi Đánh giá cho thấy CryptDB có chi phí thấp, giảm 14.5% thông lượng (throughput) cho ứng dụng phpBB web forum, giảm 26% cho truy vấn từ TPC-C, so với unmodified MySQL Chúng đánh giá độ an toàn CryptDB sáu ứng dụng thực( bao gồm phpBB, phần mềm quản lý hội nghị HotCRP [27], ứng dụng hồ sơ y tế OpenEMR); kết cho thấy CryptDB bảo vệ hầu hết trường nhạy cảm với lược đồ mã hóa bảo mật cao Việc xâu chuỗi key mã hóa với mật người dùng yêu cầu 11-13 thích giản lược độc (unique schema anntotations) để thực thi sách bảo mật 20 trường nhạy cảm (bao gồm sách HotCRP for handling papers in conflict with a PC chair) 2-7 dòng mã nguồn thay đổi cho ba ứng dụng web nhiều người dùng Phần lại tài liệu xây dựng sau Trong phần 2, thảo luận chi tiết nguy mà CryptDB chống lại Sau đó, mô tả thiết kế CryptDB cho việc xử lý truy vấn mã hóa phần cho trình xâu chuỗi key với mật người dùng phần Trong phần 5, trình bày số case studies cách ứng dụng sử dụng CryptDB, phần 6, thảo luận hạn chế thiết kế chúng tôi, cách mà mở rộng Tiếp theo, miêu tả thực nguyên mẫu phần 7, đánh giá hiệu độ an toàn CryptDB, nỗ lực cần thiết cho nhà phát triển ứng dụng để sử dụng CryptDB, phần Chúng so sánh CryptDB với công việc liên quan phần kết luận phần 10 2.Security Overview Hình cho thấy kiến trúc CryptDB mô hình de dọa CryptDB làm việc cách chặn lại tất truy vấn SQL database proxy, truy vấn viết lại để thực thi liệu mã hóa (CryptDB coi tất truy vấn qua proxy) Proxy mã hóa giải mã tất liệu, thay đổi vài toán tử truy vấn, vấn đảm bảo ngữ nghĩa truy vấn DBMS server không nhận key giải mã dạng plaintext ko thấy liệu nhạy cảm, đảm bảo DBA tò mò 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, DBMS server thỏa hiệp (mối đe dọa thứ hai), nhà phát triển thích giản đồ SQL họ (annotate their SQL schema) để xác định người ủy quyền (principals) khác, key người cho phép giải mã phần khác sở liệu chúng tạo thay đổi nhỏ tới ứng dụng chúng để cung cấp key mã hóa cho proxy, điều mô tả phần Proxy xác định phần sở liệu nên mã hóa key Kết CryptDB đảm bảo tính bí mật liệu thuộc người dùng không đăng nhập bị thỏa hiệp (ví dụ: user Hình 1), không đăng nhập thỏa hiệp bị phát sửa chữa người quản trị Mặc dù CryptDB bảo vệ tính bí mật liệu, không đảm bảo tính toàn vẹn, tính mới, hay đầy đủ kết trả cho ứng dụng Một kẻ xấu mà thỏa hiệp ứng dụng, proxy, hay DBMS server, DBA xấu, xóa tất liệu lưu trữ sở liệu Tương tự, công vào máy người dùng, cross-site scripting chẳng hạn, nằm bên phạm vi CryptDB Bây miêu tả hai mô hình mối đe dọa giải CryptDB đảm bảo an ninh cung cấp 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 DBA tò mò kẻ công bên khác với truy cập hoàn toàn tới liệu lưu DBMS server Mục tiêu tính bí mật, tính toàn vẹn hay sẵn sàng Giả sử kẻ công bị động (passive): muốn tìm hiều liệu bí mật, không thay đổi truy vấn sinh ứng dụng, kết truy vấn, hay liệu DBMS Mối đe dọa bao gồm thỏa hiệp phần mềm DBMS, truy cập root tới máy DBMS, kể truy cập tới RAM máy vật lý Với gia tăng việc thống sở liệu bên trung tậm liệu doanh nghiệp, lưu trữ sở liệu sở hạ tầng điện toán đám mây công cộng, sử dụng DBA bên thứ ba, mối đe dọa ngày trở nên quan trọng Tiếp cận CryptDB nhằm mục đích bảo vệ tính bí mật liệu chống lại mối đe dọa cách thực thi truy vấn SQL liệu mã hóa DBMS server Proxy sử dụng key bí mật để mã hóa toàn liệu thêm vào bao gồm truy vấn sinh cho DBMS Hướng tiếp cận cho phép DBMS server thực việc xử lý truy vấn liệu mã hóa thực sở liệu không mã hóa, cách cho phép tính toán hàm định mục liệu dựa liệu mã hóa Ví dụ, DBMS cần thực GROUP BY cột c, DBMS server xác định mục cột bình đẳng với nhau, nội dung thực tế mục Do đó, proxy cần phải kích hoạt DBMS server để xác định quan hệ liệu cần thiết để xử lý 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 truy vấn đưa ra, CryptDB cẩn thận xem xét quan hệ tiết lộ liệu tới server Ví dụ, DBMS cần thực GROUP BY cột c, DBMS server không nên biết thứ tự mục cột c, không nên biết thông tin khác cột khác Nếu DBMS yêu cầu thực ORDER BY, tìm MAX MIN, CryptDB tiết lộ thứ tự mục cột đó, cột khác Sự bảo đảm CryptDB cung cấp tính bí mật cho nội dung liệu cho tên cột bảng; CryptDB không che giấu cấu trúc bảng tổng thể, số hàng, loại cột, hay kích thước liệu theo byte Sự an toàn CryptDB không hoàn hảo: CryptDB tiết lộ cho DBMS server quan hệ mục liệu tương ứng với lớp tính toán (classes of computation) mà truy vấn thực sở liệu, chẳng hạn so sánh mục có ngang không (comparing item for equality), xếp, thực tìm kiếm từ Granularity (Granularity mức độ mà liệu hay thông tin lớn, phức tạp chia thành đơn vị nhỏ hơn) CryptDB cho phép DBMS thực lớp tính toán toàn cột (hoặc nhóm cột join với nhau), có nghĩa truy vấn yêu càu kiểm tra (equality checks) cho vài hàng, việc thực thi truy vấn server yêu cầu việc tiết lộ lớp tính toán (that class of computation) cho cột Phần 3.1 miêu tả cách mà lớp tính toán map với lược đồ mã hóa CryptDB, thông tin chúng tiết lộ CryptDB cung cấp tính chất sau: • • • Dữ liệu nhạy cảm không tồn dạng rõ DBMS server Thông tin bị lộ cho DBMS server phụ thuộc lớp tính toán yêu cầu truy vấn ứng dụng, tùy theo ràng buộc mà nhà phát triển ứng dụng lược đồ (phần 3.5.1): o Nếu ứng dụng không yêu cầu lọc vị từ quan hệ (relational predicate filtering) cột, không nội dung liệu bị rò rỉ (trừ kích thước tính theo byte) o Nếu ứng dụng yêu cầu equality checks cột, proxy CryptDB tiết lộ mục lặp lại cột (biểu đồ tần suất – the histogram), giá trị thực tế o Nếu ưng dụng yêu cầu order checks cột, proxy tiết lộ thư tự phần tử cột DBMS server tính toán kết (được mã hóa) cho truy vấn liên đến lớp tính toán mà không ứng dụng yêu cầu CryptDB “tối ưu” an ninh nào? Về bản, tối ưu an ninh đạt công việc gần lý thuyết mật mã cho phép tính toán toàn liệu mã hóa [18]; nhiên, đề xuất không thực tế Ngược lại, CryptDB thực tế, phần 8.3, chứng minh cung cấp bảo mật quan trọng thực tế Cụ thể, cho tất tất trường nhạy cảm ứng dụng thử nghiệm mã hóa với lược đồ mã hóa bảo mật cao Đối với trường vậy, CryptDB cung cấp tối ưu an ninh, giả sử giá trị chúng độc lập với mô hình mà chúng truy cập (trường hợp với thông tin y tế, số an sinh xã hội, vv…) CryptDB không tối ưu cho trường đòi hỏi tiết lộ nhiều lược đồ mã hóa (encryption shemes), tìm hầu hết trường bán nhạy cảm (semi-sensitive) (như nhãn thời gian-timestamp chẳng hạn) Cuối cùng, tin mô hình công bị động thực tế DBAs xấu có nhiều khả đọc liệu, khó phát hiện, thay đổi liệu kết truy vấn, mà có nhiều khả khám phá Trong phần 9, trích dẫn công việc liên quan đến toàn vẹn liệu mà sử dụng việc bổ sung với công việc Một kẻ xấu chèn cập nhật liệu gián tiếp thỏa hiệp bảo mật Ví dụ, kẻ xấu thay đổi trường email sở liệu có khả lừa ứng dụng gửi liệu người dùng tới địa email sai, người dùng yêu cầu ứng dụng gửi email cho cố liệu Các công chủ động DBMS thuộc mô hình đe dọa thứ hai, thảo luận 2.2.Mối đe dọa thứ hai: Các mối đe dọa tùy ý - Arbitrary Threats Bây miêu tả đe dọa thứ hai sở hạ tầng server ứng dụng, proxy, DBMS server bị thỏa hiệp tùy ý Cách tiếp cận mối đe dọa thứ không đủ kẻ xấu đạt truy cập tới key sử dụng để mã hóa toàn sở liệu Giải pháp mã hóa mục liệu khác (ví dụ, liệu thuộc user khác nhau) với key khác Để xác định key sử dụng cho mục liệu, nhà phát triển thích giản đồ sử liệu ứng dụng để thể sách bảo mật tốt Một DBA tò mò có liệu cá nhân cách đánh cắp DBMS serve (mối đe dọa thứ nhất), thêm vào đó, kẻ xấu thỏa hiệp server ứng dụng proxy giải mã liệu user đăng nhập (những liệu lưu trữ proxy) Dữ liệu người không hoạt động mã hóa với key mà kẻ xấu không biết, giữ bí mật Trong dạng này, CryptDB cung cấp đảm bảo mạnh đối mặt với thỏa hiệp tùy ý phía server, bao gồm người đạt truy cập root tới ứng dụng hay proxy CryptDB rò rỉ liệu người dùng hoạt động suốt thời gian bị thỏa hiệp “trong suốt thời gian bị thỏa hiệp” nghĩa khoảng thời gian từ bắt đầu thỏa hiệp dấu viết thỏa hiệp xóa khỏi hệ thống Với công SQL injection thực tế, khoảng thời gian thỏa hiệp thời gian kẻ công thực truy vấn SQL Trong ví dụ trên, kẻ xấu thay đổi địa email user sở liệu, xem xét hệ thống bị xâm nhập địa email kẻ công tồn sở liệu 3.Các truy vấn liệu mã hóa Phần miêu tả cách mà CryptDB thực thi truy vấn SQL liệu mã hóa Mô hình mối đe dọa phàn là mối đe dọa thứ từ phần 2.1 Các máy DMBS người quản trị không đáng tin cậy, ứng dụng proxy tin cậy CryptDB cho phép DBMS server thực thi truy vấn SQL liệu mã hóa gần giống với thực thi truy vấn 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 DMBS cho truy vấn mã hóa thường giống truy vấn nguyên gốc, ngoại trừ toán tử (operators) bao gồm truy vấn, chẳng hạn lựa chọn (selections), phép chiếu (projections), kết hợp (joins), tập hợp (aggregates), xếp thứ tự (ordering), thực mã, sử dụng toán tử sửa đổi số trường hợp Proxy CryptDB lưu trữ secret master key MK, lược đồ sở liệu, lớp(layers) mã hóa tất cột DBMS server thấy lược đồ ẩn danh (trong tên bảng tên cột thay định danh mờ - in which table and column names are replaced by opaque identifiers), liệu người dùng mã hóa, vài bảng phụ CryptDB sử dụng CryptDB trang bị cho server với chức người dùng định nghĩa cụ thể (CryptDB-specific user-defined functions - UDFs) cho phép server tính toán mã cho phép toán định Việc xử lý truy vấn CryptDB gồm bước: • • • • Ứng dụng sinh truy vấn, proxy chặn lại viết lại: để bảo vệ danh tính bảng cột, tổ chức lại tên bảng, tên cột, , sử dụng master key MK, mã hóa số (constant) truy vấn với lược đồ mã hóa phù hợp cho phép toán (operation) mong muốn (phần 3.1) Proxy kiểm tra xem liệu DBMS server có đưa key để điều chỉnh lớp mã hóa trước thực thi truy vấn, có, sinh truy vấn UPDATE DBMS server để gọi UDF để điều chỉnh lớp mã hóa cột thích thợp (phần 3.2) Proxy chuyển tiếp truy vấn mã hóa đến DBMS server, nơi thực sử dụng SQL tiêu chuẩn (đôi gọi UDFs cho hàm tập hợp (aggregation) tìm kiếm từ khóa) DBMS server trả kết truy vấn (được mã hóa), proxy giải mã trả cho ứng dụng 3.1.SQL-aware Encryption Bây mô tả loại mã hóa mà CryptDB sử dụng, bao gồm số hệ mật có, tối ưu hóa lược đồ gần đây, sở mật mã (hoặc mật mã sở - cryptographic primitive) cho kết hợp (joins) Với loại mã hóa, giải thích đặc điểm an toàn mà CryptDB yêu cầu từ nó, chức nó, làm để thực Random (RND) RND cung cấp bảo mật tối đa CryptDB: an toàn ngữ nghĩa công lựa chọ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) xác suất, có nghĩa hai giá trị ánh xạ tới hai mã khác với xác suất trội (overwhelming probability) Mặt khác, RND không cho phép tính toán thực hiệu mã Một cấu trúc hiệu RND sử dụng mã hóa khối AES Blowfish chế độ CBC với vector khởi tạo ngẫu nhiên (IV) (chúng sử dụng AES, ngoại trừ giá trị nguyên sử dụng Blowfish với kích thước khối 64 bit khối 128 bit AES gây mã dài đáng kể) Kể từ đó, 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 cấu trúc IND-CCA2 (tham khảo CCA, tham khảo IND-CCA) mạnh mẽ (ngăn chặn công lựa chọn mã) Tuy nhiên, đơn giản hóa để sử dụng thực IND-CCA2 an toàn RND thay vào đó, mã hóa khối chế độ UFE [13], 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 – thuật toán mà kết phép toán xác định nhất; thuật toán không đơn định – NoDeterministic – thuật toán có phép toán mà kết không nhất) DET có đảm bảo yếu hơn, cung cấp bảo mật mạnh mẽ: rò rỉ giá trị mã hóa tương ứng với giá trị liệu, cách sinh mã cho rõ Lớp mã hóa cho phép server thực kiểm tra bình đẳng (equality checks), có nghĩa thự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 phép hoán vị giả ngẫu nhiên (pseudo-random permutation – PRP – tham khảo 1, tham khảo hay gọi Block ciphers) [20] Với giá trị 64 bit 128 bit, sử dụng mã hóa khối với kích thước khối phù hợp (Blowfish AES tương ứng); tạo giả định thông thường thuật toán má hóa khối AES Blowfish PRPs Chúng đệm giá trị nhỏ 64 bít, nhứng với liệu dài khối AES 128 bit, chế độ CBC tiêu chuẩn phép toán rò rỉ tiền tố (ví dụ, hai mục liệu có tiền tố giống hệt dài 128 bit) Để tránh ván đề này, sử dụng AES với biến thể chế độ CMC [24], gần coi vòng (round) CBC, theo sau vòng khác CBC với khối theo thứ tự ngược lại Vì mục tiêu DET để reveal equality, sử dụng zero IV (hoặc “tinh chỉnh – tweak” [24]) cho thực AES-CMC DET Mã hóa trì thứ tự - Order-preserving encryption (OPE) (tham khảo1, tham khảo 2) OPE cho phép quan hệ thứ tự mục liệu thiết lập dựa theo giá trị mã hóa chúng, mà không tiết lộ liệu Nếu x < y, OPEK(x) < OPEK(y), cho key bí mật K Vì thế, cột mã hóa với OPE, server thực nhiều truy vấn số mã hóa cho OPEK(c1) OPEK(c2) tương ứng với khoảng [c1, c2] Server thực ORDER BY, MIN, MAX, SORT, vv… OPE mô hình mã hóa yếu DET hiển thị thứ tự Do đó, CryptDB proxy hiển thị cột mã hóa OPE cho server người dùng yêu cầu thứ tự truy vấn cột OPE có đảm bảo an toàn chứng minh [4]: mã hóa tương đương với ánh xạ ngẫu nhiên mà giữ theo thứ tự Mô hình sử dụng [4] mô hình an toàn chứng minh Cho đến CryptDB xuất hiện, thực biện pháp thực tiến mô hình Việc thực trực tiếp mô hình 25 ms mã hóa số nguyên 32 bít xử lý Intel 2.8 GHz Q9550 Chúng cải tiến thuật toán cách sử dụng tìm kiếm nhị phân AVL để mã hóa hàng loạt (ví dụ, tải sở liệu – database loads), giảm thiểu chi phí má hóa OPE đến ms mã hóa mà không làm ảnh hưởng tới an toàn Chúng thực hypergeometric sampler mà nằm lõi 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ược đồ mã hóa xác suất an toàn (IND-CPA-secure), cho phép server thực tính toán liệu mã hóa với kết cuối dùng giải mã proxy Trong mã hóa đồng cấu đầy đủ phục vụ chậm [10], mã hóa đồng cấu cho phép toán cụ thể hiệu Để hỗ trợ tổng kết, thực hệ mật Paillier [35] Với Paillier,việc nhân mã hóa hai giá trị dẫn tới kết mã hóa tổng giá trị, ví dụ, HOMK(x) * HOMK(y) = HOMK(x + y), phép nhân thực theo modulo vài giá trị khóa công khai Để tính tổng SUM (SUM aggregates), proxy thay SUM với lời gọi tớ UDF mà thực phép nhân Paillier cột mã hóa với HOM HOM sử dụng để tính toán giá trị trung bình cách DBMS server trả giá trị tổng (sum) đếm (count) riêng biệt, cho việc tăng giá trị (ví dụ, SET id=id+1) , mà xây dựng (on wich we elaborate shortly) Với HOM, mã 2048 bít Theo lý thuyết, đóng gói nhiều giá trị từ hàng đơn lẻ vào mã HOM cho hàng đó, sử dụng lược đồ Ge Zdonik [17], dấn tới kết khoảng trống khấu hao gấp đôi (ví dụ giá trị 32 bit chiếm 64 bit) cho bảng với nhiều cột mã hóa HOM Tuy nhiên, không thực tối ưu hóa mẫu thử nghiệm Sự tối ưu hóa làm phức tạp phép toán UPDATE hàng cục (This optimization would also complicate partial-row UPDATE operations) mà thiết lập lại số - tất - giá trị đóng gói vào mã HOM Join (JOIN and OPE-JOIN) Một lược đồ mã hóa riêng cần thiết phép equality join hai cột, sử dụng key khác cho DET để ngăn chặn mối tương quan cột JOIN hỗ trợ tất phép toán DET cho phép, cho phép server xác định giá trị nhắc lại hai cột OPE-JOIN cho phép tham gia theo mối liên hệ thứ tự (OPE-JOIN enables joins by order relations) Chúng cung cấp lược đồ mã hóa cho JOIN thảo luận phần 3.4 Hình 2: Các lớp mã hóa Onion 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 phép toán chúng cho phép vài lớp chúng (Equality, Order, Search, Addition) Trong thực tế, vài onion lớp onion bỏ qua, phụ thuộc vào loại cột giải lược đồ(schema annotations) cung cấp nhà phát triển ứng dụng (phần 3.5.2) DET JOIN thường kết hợp lớp onion đơn lẻ, JOIN nối tiếp cua DET JOIN-ADJ (phần 3.4) Một IV ngẫu nhiên cho RND (3.1), chia sẻ lớp RND Eq Ord, lưu trữ cho mục liệu Word search (SEARCH) SEARCH sử dụng để thực tìm kiếm văn mã hóa để hỗ trợ phép toán LIKE MySQL chẳng hạn Chúng thực giao thức mã hóa Song đồng nghiệp ông [46], mà trc họ không thực hiện; sử dụng giao thức họ theo cách khác, dẫn tới kết đảm bảo an toàn tốt Cho cột cần SEARCH, chia văn thành từ khóa sử dụng ký tự phân cách tiêu chuẩn (hoặc sử dụng chức khai thác từ khóa đặc biệt quy định người phát triển lược đồ) Sau loại bỏ lặp lại từ này, hoán vị ngẫu nhiên vị trí từ, mã hóa từ sử dụng lược đồ Song, đệm (padding) từ cho kích thước SEARCH an toàn gần RND: má hóa ko để lộ cho DBMS server có từ lặp lặp lại nhiều hàng, rò rỉ số lượng từ khóa mã hóa với SEARCH; kẻ xấu ước lượng số lượng từ riêng biệt trùng lặp (ví dụ, cách so sánh kích thước mã SEARCH RND với liệu) Khi người dùng thực truy vấn SELECT * FROM messages WHERE msg LIKE "% alice %" chẳng hạn, proxy đưa cho DBMS server token, mã hóa alice Server giải mã token để tìm từ (underlying word) Sử dụng hàm người dùng định nghĩa, DBMS server kiểm tra xem mã hóa từ thông điệp có phù hợp với token hay không Trong cách tiếp cận chúng tôi, tất server tìm hiểu từ việc tìm kiếm xem liệu token có phù hợp (matched) với thông điệp hay không, điều xảy token người dùng yêu cầu Server không tìm hiểu thông tin tương tự trả tập kết thiếp người dùng, lược đồ tìm kiếm tổng thể để lộ thông tin cần thiết để trả kết Chú ý SEARCH cho phép CryptDB thực tìm kiếm từ khóa đầy đủ từ (full-word keyword searches); hỗ trợ biểu thức quy tùy ý Cho ứ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 xếp lại cách giải lược đồ(annotating the schema), mặc định 3.2.Adjustable Query-based Encryption Một phần quan trọng thiết kế CryptDB adjustable query-based encryption, tự động điều chỉnh lớp mã hóa DBMS server Mục đích sử dụng lược đồ mã hóa an toàn mà chạy truy vấn yêu cầu Ví dụ, ứng dụng không sinh truy vấn so sánh mục liệu cột, xếp cột, cột phải mã hóa với RND Đối với cột yêu cầu equality check không yêu cầu inequality check, DET đủ Tuy nhiên, tập truy vấn lúc biết trước Do đó, cần lược đồ có khả thích ứng mà tự động điều chỉnh chiến lược mã hóa Ý tưởng mã hóa mục liệu nhiều onion: tức là, giá trị bọc lớp mã hóa ngày mạnh hơn, minh họa hình Mỗi lớp onion cho phép loại chức giải thích tiểu mục trước Ví dụ, lớp RND HOM cung cấp bảo mật tối đa, lớp bên OPE cung cấp nhiều chức Trong thực tế cần nhiều onion, phép toán hỗ trợ lược đồ mã hóa khác không luôn theo thứ tự cách hoàn toàn, cần phải cân nhắc hiệu suất thực (kích thước mã thời gian mã hóa cho lớp onion lồng vào nhau) Phụ thuộc vào loại liệu (và thích (annotations) cung cấp nhà phát triển ứng dụng lược đồ sở liệu, thảo luận phần 3.5.2), CryptDB không trì tất onion cho cột Ví dụ, Search onion ý nghĩa cho số nguyên (integers), Add onion ý nghĩa cho chuỗi (strings) Với lớp onion, proxy sử sử dụng key cho giá trị mã hóa cột, key khác bảng, cột, onion, lớp onion khác Việc sử dụng key cho tất giá trị cột cho phép proxy thực phép toán cột mà tính toán key riêng biệt cho hàng mà thao tác (chúng sử dụng key mã hóa finer-grained phần để giảm khả tiềm ẩn liệu bị tiết lộ trường hợp ứng dụng haowcj proxy server bị thỏa hiệp) Việc sử dụng key khác cột ngăn chặn server tìm mối quan hệ thêm Tất key bắt nguồn từ masterk key MK Ví dụ, với bảng t, cột c, onion o, lớp mã hóa l, proxy sử dụng key Kt,c,o,l = PRPMK(bảng t, cột c, onion o, lớp l), (1) với PRP hoán vị giả ngẫu nhiên – pseudo random permutation (ví dụ, AES) Mỗi onion bắt đầu mã hóa với lược đồ mã hóa an toàn (RND cho onion Eq Ord, HOM cho onion Add, SEARCH cho onion Search) Khi proxy nhận truy vấn SQL từ ứng dụng, xác định xem lớp mã hóa cần gỡ bỏ Gán vị từ (predicate) P cột c cần thiết để thực thi truy vấn server, proxy thiết lập lớp onion cần thiết để tính toán P c mã hóa c lớp onion mà cho phép P, proxy bóc tách lớp onion phép P c, cách gửi key onion tương ứng tới server Proxy không giải mã liệu qua lớp onion mã hóa an toàn (hoặc qua vài lớp mức khác, định nhà phát triển ứng dụng lược đồ, 3.5.1) CryptDB thực việc giải mã lớp onion sử dụng UDFs chạy DBMS server Ví dụ, hình 3, để giải mã onion Ord cột bảng tới lớp OPE, proxy sinh 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 key phù hợp tính toán từ phương trình (1) Tại thời điểm, proxy cập nhật trạng thái bên để ghi nhớ cột C2-Ord Table1 lớp OPE DBMS Mỗi giải mã cột phải bao gồm giao dịch để tránh vấn đề tính quán với client truy cập cột điều chỉnh Hình 3:Bố trí liệu máy chủ (Data layout at the server) Khi ứng dụng tạo bảng hiển thị bên trái, bảng tạo DBMS server bảng hiển thị bên phải Bản mã hiển thị không đủ độ dài Chú ý việc giải mã onion thực toàn DBMS server Trong trạng thái ổn định, không giải mã phía server cần thiết, việc giải mã onion xảy lớp tính toán yêu cầu cột Ví dụ, sau equality check yêu cầu cột server đưa cột vào lớp DET, cột tồn trạng thái đó, truy vấn tương lai với 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 liệu mã hóa - Executing over Encrypted Data Khi lớp onion DBMS lớp cần thiết để thực thi truy vấn, proxy biến đổi truy vấn để hoạt động onion Đặc biệt, proxy thay tên cột truy vấn với tên onion tương ứng, dựa lớp tính toán thực cột Ví dụ, với lược đồ thể Hình 3, tham chiếu đến cột Name cho equalyti comparison thay với tham chiếu tới cột C2-Eq Proxy thay số truy vấn với mã hóa onion tương ứng số đó, dựa tính toán sử dụng Ví dụ, truy vấn chứa WHERE Name = ‘Alice’, proxy mã hóa ‘Alice’ cách áp dụng tất lớp mã hóa tương ứng với onion Eq mà chưa loại bỏ khỏi C2Eq Cuối cùng, server thay toán tử định với dựa hàm người dùng định nghĩa (UDFbased counterparts) Ví dụ, toán tử tính tổng SUM toán tử cộng cột + phải thay với lời gọi UDF mà thực việc thêm HOM mã Các toán tử đẳng thức thứ tự (như = < chẳng hạn) không cần thiết thay áp dụng trực tiếp vào mã DET OPE Khi proxy chuyển đổi truy vấn, gửi truy vấn tới DBMS server, nhận kết truy vấn (bao gồm liệu mã hóa), giải mã kết sử dụng onion key tương ứng, gửi kết giải mã cho ứng dụng Sự thực thi truy vấn đọc – Read query execution Để hiểu thực thi truy vấn mã, xem xét lược đồ ví dụ Hình Ban đầu, cột bảng bọc tất onion mã hóa, với RND, HOM, SEARCH lớp cùng, Hình Tại thời điểm này, server có biết liệu khác số cột, số hàng, kích thước liệu Để minh họa lớp onion 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 Name tới lớp DET Để thực thi truy vấn này, proxy sinh truy vấn UPDATE Table1 SET C2-Eq = DECRYPT_RND(KT1,C2,Eq,RND, C2-Eq, C2-IV), với cột C2 tương ứng với Name Proxy sau sinh SELECT C1-Eq, C1-IV FROM Table1 WHERE C2-Eq = x7 d, Với cột C1 tương ứng với ID, x7 d mã hóa Eq onion “Alice” với key KT1,C2,Eq,JOIN KT1,C2,Eq,DET (xem Hình 2) Chú ý proxy phải yêu càu IV ngẫu nhiên từ cột C1-IV để giải mã mã RND từ C1-Eq Cuối cùng, proxy giải mã kết từ server sử dụng key K T1;C1;Eq;RND, K T1;C1;Eq;DET, K T1;C1;Eq;JOIN, thu kết 23, trả cho ứng dụng Nếu truy vấn SELECT COUNT(*) FROM Employees WHERE Name = ‘Bob’, không cần thiết phải giải mã phía server, proxy trực tiếp sinh truy vấn SELECT COUNT(*) FROM Table2 WHERE C2-Eq = xbb 4a, với xbb 4a mã hóa Eq onion “Bob” sử dụng K T1;C2;Eq;JOIN K T1;C2;Eq;DET Sự thực thi truy vấn viết – Write query exexution Để hỗ trợ truy vấn INSERT, DELETE, UPDATE, proxy áp dụng xử lý cho vị từ (vị ngữ - predicates) (ví dụ, mệnh đề WHERE) cho truy vấn đọc Các truy vấn DELETE không yêu cầu thêm tiến xử lý Cho tất truy vấn INSERT UPDATE mà thiết lập giá trị cột thành số (constant), proxy mã hóa giá trị cột chèn vào với lớp onion mà chưa gỡ bỏ cột Trường hợp lại UPDATE mà thiết lập giá trị cột dựa vào giá trị cột tồn tại, salary=salary+1 chẳng hạn Một cập nhật phải thực sử dụng HOM, để xử lý bổ sung Tuy nhiên, làm vậy, giá trị onion OPE DET trở nên cũ Thực tế, lược đồ mã hóa giả định (hypothetical encryption scheme) mà đồng thời cho phép bổ sung so sánh trực tiếp mã không an toàn: server độc hại tính toán thứ tự mục, tăng giá trị lên một, server liên tục thêm vào trường (add one to each field homomorphically – homomorphically chuyển đổi sang khác mà giữ nguyên thứ hai phép toán thành viên đầu tiên) trở nên với vài giá trị khác cột Điều cho phép server tính toán khác hai giá trị sở liệu, mà gần tương đương với giá trị chúng biết Có hai cách tiếp cân phép cập nhật dựa giá trị cột tồn Nếu cột tăng lên sau chiếu (projected) (không so sánh thực nó), giải pháp đơn giản: truy vấn yêu cầu giá trị trường này, proxy phải yêu cầu mã HOM từ Add onion, thay mã từ onion khác, giá trị HOM Ví dụ, cách tiếp cận áp dụng với truy vấn tăng (increment queries) TPC-C Nếu cột sử dụng so sánh sau tăng lên, giải pháp thay truy vấn cập nhật với hai truy vấn: SELECT giá trị cũ để cập nhật, mà proxy tăng mà mã hóa cách phù hợp, UPDATE thiết lập giá trị Chiến lược hoạt động tốt cho cập nhật mà ảnh hưởng đến số lượng nhỏ hàng Các đặc điểm DMBS khác – Other DBMS features Hầu hết chế DMBS khác, giao dịch (transaction) lập mục (indexing), hoạt động tương tự với CryptDB liệu mã hóa chúng làm rõ, với thay đổi Đối với giao dịch (transactions), proxy gửi truy vấn BEGIN, COMMIT, ABORT tới DBMS Vì toán tử SQL xử lý giá trị NULL khác với giá trị NULL, CryptDB để lộ giá trị NULL cho DBMS mà không mã hóa CryptDB không hỗ trợ thủ tục lưu trữ, thủ tục lưu trữ định hỗ trợ cách viết lại code chúng theo cách mà proxy CryptDB viết lại câu lệnh SQL DBMS xây dựng mục cho liệu mã hóa theo cách cho rõ Hiện tại, ứng dụng yêu cầu mục (index) cột, proxy yêu cầu DBMS server xây dựng mục lớp DET, JOIN, OPE, OPE-JOIN onion cột (nếu chúng bị lộ), không cho RND, HOM, SEARCH Các thuật toán lựa chọn mục hiệu điều tra 3.4.Computing Joins Có hai loại join hỗ trợ CryptDB: equi-joins, join predicate dựa equality, range joins, liên quan đến order check Để thực equi-join hai cột mã hóa, cột phải mã hóa với key để server tháy giá trị khớp hai cột Tại thời điểm, để cung cấp bảo mật tốt hơn, DBMS server không join cac cột mà ứng dụng không yêu cầu join, cột mà không join không nên mã hóa với key Nếu truy vấn mà sinh ra, cặp cột mà join, biết từ trước (are known a priori), equi-join dễ dàng để hỗ trợ: CryptDB sử dụng mã hóa DET với key cho nhóm cột mà join với Phần 3.5 mô tả cách mà proxy biết cột join trường hợp Tuy nhiên, trường hợp khó khăn proxy tập cột join từ trước (a priori), cột phải mã hóa với key phù hợp Để giải vấn đề này, giới thiệu sở mật mã mới, JOIN-ADJ (adjustable join), cho phép DMBS server điều chỉnh key cột thời điểm chạy Bằng trực giác, JOIN-ADJ coi băm mật mã bảo vệ khóa (keyed cryptographic hash) (băm mật mã có khóa)với đặc điểm bổ sung mà băm điều chỉnh để thay đổi key chúng mà không cần truy cập tới rõ JOINADJ chức xác định đầu vào nó, có nghĩa hai rõ giống nhau, giá trị JOINADJ tương ứng JOIN-ADJ chống đụng độ (collision-resistant), có chiều dài đầu đủ dài (192 bít) phép thừa nhận đụng độ không xảy thực tế JOIN-ADJ không khả nghich (non-invertible), định nghĩa lược đồ mã hóa JOIN chuỗi kết nối JOIN(v) = JOIN-ADJ(v)||DET(v) cấu trúc cho phép proxy giải mã cột JOIN(v) để thu v cách giải mã thành phần DET, cho phép DBMS server kiểm tra hai giá trị JOIN có không cách so sánh thành phần JOIN-ADJ Mỗi cột ban đầu mã hóa lớp JOIN sử dụng key khác nhau, ngăn chặn join cột Khi truy vấn yêu cầu join, proxy đưa cho DBMS server key onion để điều chỉnh giá trị JOIN-ADJ hai cột, để phù hợp với JOIN-ADJ key cột khác (được ký hiệu cột joinbase) Sau điều chỉnh, cột chia sẻ key JOIN-ADJ, cho phép DBMS server join chúng lại với Các thành phần DET JOIN mã hóa với key khác Chú ý join điều chỉnh bắc cầu:nếu người dùng join cột A B join cột B C, server join A C Tuy nhiên, server join cột “các nhóm bắc cầu” khác Ví dụ, cột D E join với nhau, DBMS server join cột A D Sau truy vấn join ban đầu, giá trị JOIN-ADJ chuyển đổi với key, không tái điều chỉnh cần thiết cho truy vấn join đến sau hai cột Một ngoại lệ ứng dụng sinh truy vấn khác, join cột điều chỉnh với cột thứ ba, khiến cho proxy điều chỉnh lại cột sang join-base khác Để tránh dao động (oscillations) để hội tụ (converge) trạng thái mà tất cột nhóm bắc cầu chia sẻ join-base, CryptDB chọn cột có tên theo thứ tự từ điển bảng join-base Với n cột, số lượng tổng tối đa chuyển đổi join n(n-1)/2 Đối với range join, lược đồ tái điều chỉnh động tương tự khó khăn để xây dựng thiếu sót cấu truc lược đồ OPE Thay vào đó, CryptDB yêu cầu cặp cột mà liên hệ với join ứng dụng khai báo trước, key phù hợp sử dụng cho lớp OPE-JOIN cột đó; không, key sử dụng cho tất cột lớp OPE-JOIN May mắn thay, range join xuất hiện; chúng không sử dụng ứng dụng ví dụ chúng tôi, sử dụng 50 128,840 cột theo dõi truy vấn SQL mà mô tả phần 8, tương ứng với ứng dụng riêng biệt JOIN-ADJ construction Thuật toán cúng sử dụng mã hóa đường cong elliptic (elliptic-curve cryptography - ECC) JOIN-ADJK(v) tính toán sau: Với K khóa khởi tạo cho bảng, cột, onion lớp đó, P điểm đường cong elliptic (là tham số public), PRFK0 hàm giả ngấu nhiên (pseudo-random function) [20] ánh xạ giá trị tới số giả ngẫu nhiên, AESK0(SHA(v)) chẳng hạn, với K0 key mà cho tất cột có nguồn gốc từ MK Các “lũy thừa” (“exponentiation”) thực tế bổ sung hình lặp lặp lại điểm đường cong elliptic; nhanh đáng kể so với lũy thừ RSA Khi truy vấn join cột c c’, khóa K K’ lớp join, proxy tính toán ΔK = K/K’ (trong nhóm thích hợp) gửi cho server Sau JOIN-ADJK’(v) cho (các giá trị JOIN-ADJ từ cột c’) ΔK, DBMS server sử dụng UDF để điều chỉnh key c’ cách tính : Bây cột c c’ chia sẻ JOIN-ADJ key, DBMS thực equi-join c c’ cách lấy phận JOIN-ADJ JOIN onion cipertext Tại mức cao hơn, an toàn lược đồ server suy mối liên hệ join nhóm cột mà không yêu cầu truy vấn join hợp pháp, lược đồ không để lộ rõ Chúng chứng minh an toàn lược đồ dựa giả thiết chắn Elliptic-Curve Decisional Diffie-Hellman tiêu chuẩn, thực sử dụng NIST-approved elliptic curve Chúng dự định công bó mô tả chi tiết thuật toán chứng website [37] 3.5.Cải thiện độ an toàn hiệu suất - Improving Security and Performance Mặc dù CryptDB hoạt động với lược đồ không bị thay đổi không đánh dấu (an unmodified and unannotated schema), mô tả trên, an toàn hiệu nâng lên thông qua nhiều tùy chọn tối ưu, mô tả 3.5.1.Security Improvements Các lớp onion tối thiểu - Minimum onion layers Các nhà phát triển ứng dụng rõ lớp mã hóa onion thấp mà bị lộ cho server cột cụ thể Bằng cách này, nhà phát triển đảm bảo proxy không thực thi truy vấn lộ liên hệ nhạy cảm với server Ví dụ, nhà phát triển rõ số thẻ tín dụng phải luôn trì RND DET Xử lý proxy – In-proxy processing Mặc dù CryptDB ước lượng số vị từ (predicates) server, việc ước lượng chúng proxy nâng cao an toàn cách không để lộ thông tin bổ sung cho server Một trường hợp phổ biến truy vấn SELECT mà xếp cột chọn, mà LIMIT số cột trả Vì proxy nhận tập toàn kết từ server, việc xếp kết proxy không yêu cầu số lượng đáng kể tính toán, không tăng yêu cầu băng thông Làm tránh việc lộ mã hóa OPE cột tới server Training mode CryptDB cung cấp training mode, cho phép nhà phát triển cung cấp theo dõi truy vấn thu lớp mã hóa onion kết cho trường (field), với cảnh báo trường hợp vài truy vấn không hõ trợ Nhà phát triển sau nghiên cứu lớp mã hóa kết để biết lược đồ mã hóa rò rỉ, miêu tả phần 2.1 Nếu vài mức onion thấp cho trường nhạy cảm, cô nên xếp để có truy vấn xử lý proxy (như mô tả trên), để xử lý liệu vài kiểu khác, chẳng hạn cách sử dụng local instance SQLite Onion re-encryption Trong trường hợp ứng dụng thực truy vấn xảy yêu cầu lớp onion thấp (ví dụ, OPE), CryptDB mở rộng tới onion mã hóa lại quay trở lớp cao sau truy vấn xảy kết thúc thực thi Cách tiếp cận giảm thiểu sử rò rỉ cho công xảy cửa sổ thời gian (time window) liệu lớp onion cao 3.5.2 Các tối ưu hóa hiệu suất - Performance Optimizations Developer annotations Theo mặc định CryptDB mã hóa tất trường tạo tất onion áp dụng cho mục liệu dựa loại Nếu nheiefu cuột không nhạy cảm, nhà phát triển cung cấp thích rõ ràng thay để trường nhạy cảm (được mô tả phần 4), để trường lại dạng rõ Tập truy vấn biết - Know query set Nếu nhà phát triển biết vài truy vấn trước đó, trường hợp cho nhiều ứng dụng web, nhà phát triển sử dụng training mode mô tả đê điều chỉnh onion sang lớp a priori xác, tránh chi phí điều chỉnh onion chạy (runtime onion adjustments) Nếu nhà phát triển cung cấp tập truy vấn xác, thích mà chức định không cần thiết số cột, CryptDB loại bỏ onion mà ko cần thiết (ví dụ loại bỏ Ord onion cho cột mà không sử dụng truy vấn range, loại bỏ Search onion cho cột tìm kiếm từ khóa không thự hiện), loại bỏ lớp onion không cần thiết (ví dụ adjustable JOIN layer, join a priori), loại bỏ IV ngẫu nhiên cần cho RND cho vài cột Ciphertext pre-computing and caching Proxy dành lượng kể thời gian mã hóa giác trị sử dụng truy vấn với OPE HOM Để giảm thiểu chi phí, proxy tính toán trước (pre-computes) (cho HOM) lưu trữ đệm (caches) (cho OPE) mã hóa số thường sử dụng key khác Vì HOM theo xác suất (probabilistic), mã sử dụng lại Vì vậy, ra, Proxy tính toán lại giá trị ngẫu nhiên Paillier rn HOM cho mã hóa sau liệu Sự tối ưu hóa giảm thời gian CPU mà proxy dùng mã hóa OPE, giải định proxy nhàn rỗi để thực tính toán trước HOM, loại bỏ mã hóa HOM từ path quan trọng 4.Multiple Principals Bây mở rộng mô hình đe dọa tới trường hợp sở hạ tầng ứng dụng proxy không tin tưởng (mối đe dọa thứ 2) Mô hình đặc biệt liên quan cho website đa người dùng chạy web server ứng dụng Để hiểu vấn đề ứng dụng web đa người dùng phải đối mặt giải pháp CryptDB cho vấn đề này, xem xet phpBB, forum web trực tuyến phổ biến Trong phpBB, người dùng có tài khoản mật khẩu, thuộc nhóm định, gửi tin nhắn cá nhân cho người dùng khác Phụ thuộc vào cho phép nhóm họ, người dùng đọc toàn forum, vài forum, khẳ đọc frum Có số đảm bảo bí mật có ích phpBB Ví dụ, muốn đảm bảo tin nhắn cá nhân gửi từ người dùng tới người dùng khác không nhìn thấy khác; viết forum truy cạp tới người dùng nhóm truy cập forum đó; tên forum hiển thị với người dùng thuộc nhóm mà cho phép xem CryptDB cung cấp đảm bảo đối mặt với thỏa hiệp tùy ý, hạn chế thiệt hại gây bị thỏa hiệp Để đạt đảm bảo yêu cầu giải hai thách thức Đầu tiên, CryptDB phải nắm bắt (capture) sách kiểm soát truy cập ứng dụng cho liệu chia sẻ mức truy vấn SQL Để làm điều này, CryptDB yêu cầu nhà phát triển thích (annotate) lược đồ sở liệu họ để rõ principal liệu mà principal có quyền truy cập, mô tả phần 4.1 Thách thức thứ hai để giảm lượng thông tin mà kẻ xấu đạt cách thỏa hiệp hệ thống Giải pháp hạn chế rò rỉ từ ứng dụng hay proxy server bị thỏa hiệp để liệu người dùng đăng nhập bị ảnh hưởng bị thỏa hiệp Đặc biệt, kẻ công truy cập liệu người dùng mà không đăng nhập bị thỏa hiệp Việc lộ liệu người dùng hoạt động trường hợp thỏa hiệp tránh được: để tính toán liệu mã hóa, vài liệu người dùng hoạt động phải ứng dụng giải mã Trong CryptDB, user có key( ví dụ mật mức ứng dụng ) mà cho phép user truy cập tới liệu CryptDB mã hóa mục liệu khác với key khác nhau, tăng cường sách kiểm soát truy cập sử dụng chuỗi bắt đầu key từ mật người dùng kết thúc key mã hóa mục liệu SQL, mô tả phần 4.2 Khi user đăng nhập, cung cấp mật cho proxy (thông qua ứng dụng) Proxy sử dụng mật để lấy key onion để xử lý truy vấn liệu mã hóa, trình bày phần trước, để giải mã kết Proxy giải mã liệu mà user truy cập, dựa vào sách kiểm soát truy cập, Proxy đưa liệu mã hóa cho ứng dụng, tính toán Khi user đăng xuất, proxy xóa key user 4.1.Các thích sách – Policy Annotations Để thể sách bảo mật liệu ứng dụng database-backed mức truy vấn SQL, nhà phát triển ứng dụng thích (annotate) lược đồ sở liệu CryptDB cách rõ, cho tập mục liệu, mà principal truy cập vào Một principal thực thể, user group chẳng hạn, mà tự nhiên để xác định sách truy cập Từng truy vấn SQL kéo theo mục liệu thích đòi hỏi đặc quyền principal tương ứng CryptDB định nghĩa khái niệm principal thân thay sử dụng DBMS principal có sẵn hai lý sau: đầu tiên, nhiều ứng dụng không ánh xạ (map) user mức ứng dụng tới DBMS principal cách đầy đru, thứ hai, CryptDB yêu cầu ủy quyền rõ ràng đặc quyền principal mà khó để trích xuất cách tự động từ danh sách kiểm soát truy cập chi tiết Một nhà phát triển ứng dụng thích lược đồ cách sử dụng ba bước miêu tả minh họa Hình Trong tất ví dụ đưa ra, nghiêng tên bảng cột, chữ in đậm thích thêm vào cho CryptDB Hình 4: phần lược đồ phpBB với thích để đảm bảo riêng tư tin nhắn Chỉ người gửi người nhận thấy tin nhắn riêng tư Một kẻ công mà đạt truy cập hoàn toàn vào phpBB DBMS truy cập tin nhắn riêng tư user hoạt động Bước Nhà phát triển phải định nghĩa principal types (sử dung PRINCTYPE) sử dụng ứng dụng anh ta, user, group, message Một principal trường hợp principal type, ví dụ principal type user Có hai lớp principal: external internal Các external principal tương ứng với end user người xác thực xác họ với ứng dụng sử dụng mật Khi user đăng nhập vào ứng dụng, ứng dụng phải cung cấp mật user cho proxy để user có đặc quyền external principal anh Các đặc quyền (internal) principal khác đạt thông qua ủy quyền, mô tả Bước Khi user đăng xuất, ứng dụng phải báo cho proxy biết, để proxy quên mật user key có nguồn gốc từ mật user Bước Nhà phát triển phải rõ cột lược đồ SQL có chứa liệu nhạy cảm, với principal mà cần phải có quyền truy cập vào liệu đó, sử dụng thích ENC_FOR CryptDB yêu cầu điều cho mục liệu riêng hàng, tên principal mà cần phải có quyền truy cập tới liệu lưu trữ cột khác hạng Ví dụ, Hình 4, việc giải mã msgtext x37a21f có cho principal type msg Bước Các lập trình viên rõ luật (rules) cho việc làm để ủy quyền đặc quyền principal cho principal khác, sử dụng mốt quan hệ speak-for [49] Ví dụ, phpBB, user phải có đặc quyền nhóm mà thuộc Vì nhiều ứng dụng lưu trữ thông tin bảng, lập trình viên cho CryptDB cách để suy luật ủy thác từ hàng bảng tồn Đặc biệt, lập trình viên thích bảng T với (a x) SPEAKS_FOR (b y) Chú thích hàng bảng quy định principal a type x đại diện (speaks for) cho principal b type y, có nghĩa a có truy cập tới tất key mà b truy cập Ở đây, x y phải luôn prinxipal type cố định Principal b luôn rõ tên cột bảng T Mặt khác, a tên cột khác bàng, số, T2.col, nghĩa tất principal từ cột col bảng T2 Ví dụ, Trong Hình 4, principal “Bob” type physical_user đại diện cho principal type user, Hình 6, tất principal cột contactId từ bảng PCMember (type contact) đại diện cho paperId principal type review Tùy chọn, lập trình viên vị từ (predicate), mà đầu vào giá trị hàng, để điều kiện mà theo ủy thác xảy ra, loại trừ xung đột Hình chẳng hạn Phần cung cấp nhiều ví dụ việc sử dụng thích để đảm bảo an toàn ứng dụng 4.2.Key Chaining Mỗi principal (ví dụ, trường hợp mối principal type) liên kết với key bí mật, lựa chọn ngẫu nhiên Nếu principal B đại diện principal A (như kết số thích SPEAKS_FOR), key principal A mã hóa sử dụng key principal B, lưu trữ hàng bảng đặc biệt access_key sở liệu Ví dụ, Hình 4, để trao cho user1 user2 truy cập tới message 5, key msg mã hóa với key user 1, mã hóa riêng với key user Mỗi trường nhạy cảm mã hóa với key principal thích ENC_FOR (ENC_FOR annotation) CryptDB mã hóa trường nhạy cảm với onion theo cách principal CryptDB đơn lẻ, ngoại trừ key onion suy từ key principal trái ngược với global master key Key principal kết hợp symmetric key cặp public-private key Trong trường hợp phổ biến, CryptDB sử dụng symmetric key principal để mã hóa liệu key principal khác truy cập vào principal này, với chi phí CPU Tuy nhiên, điều thường không khả thi, vài principal không trực tuyến Ví dụ, Hình 4, giả sử Bob gửi message cho Alice, Alice (user 1) không online Điều có nghĩa CryptDB truy cập vào key user 1, mã hóa key message với symmetric key user Trong trường hợp này, CryptDB tìm public key principal (ví dụ user 1) bảng thứ hai, public_keys, mã hóa key message sử udngj public key user Khi user đăng nhập, cô ta sử dụng phần secret key key cô để giải mã key cho message (và mã hóa lại symmetric key cô để sử dụng sau này) Đối với external principal (ví dụ, physicla user), CryptDB gán key ngẫu nhiên với principal khác Để cho extenal user truy cập tới key tương ứng đăng nhập, CryptDB lưu trữ key external principal bảng thứ ba, external_keys, mã hóa với mật principal Điều cho phép CryptDB có key user đưa mật user, cho phép user thay đổi mật cô mà không thay đổi key principal Khi bảng với mối quan hệ SPEAKS_FOR cập nhật, CryptDB phải cập nhật bảng access_keys phù hợp Để chèn hàng vào access_keys cho mối quan hệ SPEAKS_FOR mới, proxy phải có truy cập tới key principal mà đặc quyền ủy thác Điều có nghĩa kẻ xấu mà xâm nhập vào ứng dụng proxy server tạo mối quan hệ SPEAKS_FOR cho principal mà không đăng nhập, proxy kẻ xấu không truy cập key họ Nếu quan hệ SPEAKS_FOR bị gỡ bỏ, CryptDB thu hồi truy cập cách gỡ bỏ cột tương tứng khỏi access_keys Khi mã hóa liệu truy vấn giải mã liệu từ kết quả, CryptDB theo key chain mật user đăng nhập có key mong muốn Như tối ưu, user đăng nhập, proxy CryptDB tải key vào principal mà người dùng có quyền truy cập (đặc biệt, principal type nhiều trường hợp principal – ví dụ, cho cac group mà user đó,nhưng không cho message mà user nhận) Các ứng dụng thông báo cho CryptDB user đăng nhập hay đăng xuất cách sinh truy vấn SQL INSERT DELETE cho bảng đặc biệt cryptdb_active có hai cột, username password Proxy chặn tất truy vấn cho cryptdb_active, lưu trữ mật user đăng nhập nhớ, không để lộ chúng cho DBMS server CryptDB bảo vệ liệu user không hoạt động thời gian công Nếu thỏa hiệp xảy ra, CryptDB cung cập một ràng buộc liệu bị rò rỉ, cho phép quản trị viên không sinh cảnh báo trống tới tất user hệ thống Trong ý này, CryptDB khác với cách tiếp cận khác tới an toàn sở liệu (xem phần 9) Tuy nhiên, vài user dặc biệt quản trị viên chẳng hạn có quyền truy cập vào lượng lớn liệu cho phép thỏa hiệp lớn công diễn Để tránh công xảy quản trị viên đăng nhập, quản trị viên phải tạo tài khoản user riêng với quyền hạn chế truy cập ứng dụng user bình thường Ngoài ra, thực tế, ứng dụng tốt nên tự động đăng xuất user không hoạt động khoảng thời gian 5.Application Case Studies Trong phần này, giải thích cách mà CryptDB sử dụng để đảm bảo an toàn cho ứng dụng web đa người dùng hành Cho ngắn gọn, cho thấy lược đồ đơn giản, loại bỏ trường không liên quan Nhìn chung, tìm lập trình viên princial lược đồ ứng dụng, cá quy tắc ủy quyền cho họ sử dụng SPEAKS_FOR, bảo vệ trường nhạy cảm khác cần yêu cầu thêm thích ENC_FOR Hình 5: lược đồ thích cho việc đảm bảo an toàn truy cập tới viết (posts) phpBB Một user truy cập để tháy nội dung viết forum group mà user thuộc có quền vậy, optionid 20 bảng aclgroups cho tương tứng forumid groupid Tương tự, optionid 14 cho phép user tháy tên forum phpBB làm forum mã nguồn mở sử dụng rộng rãi với tập phong phú thiết lập điều khiển truy cập Các user tổ chức group; user group có loạt quyền truy cập mà quản trị viên ứng dụng chọn Chúng cho thấy cách đảm bảo an toàn tin nhắn riêng tư user phpBB Hình Một trường hợp chi tiết đảm bảo an toàn truy cập viết, Hình Ví dụ cho cách sử dụng vị từ (ví dụ IF optionid=…) để thực quan hệ điều kiện speaks-for principal, cách cột (forumid) sử dụng để đại điện nhiều principal (của loại khác nhau) với đặc quyền khác Có nhiều cách để truy cập vào viết, bỏ qua chúng cho ngắn gọn Hình 6: lược đồ thích cho đảm bảo an toàn review HotCRP Các review danh tính reviewer cung cấp review hiển thị cho PC thành viên (bảng PCMember bao gồm PC chủ tọa) người mà không mâu thuẫn, PC chủ tọa ghi đè lên giới hạn HotCRP ứng dụng phê bình hội nghị (conference review application) phổ biến [27] Một sách quan trọng cho HotCRP PC thành viên thấy phê bình (reviewed) viết họ Hình cho thấy thích CryptDB cho lược đồ HotCRP để thực thi sách Ngày nay, HotCRP ngăn PC chủ tọa họp tò mò bất cẩn đăng nhập vào database server thấy viết review cho báo mà cô mâu thuẫn với Kết là, hội nghị (conferences) thường thieetps lập server thứ hai để review viết chủ tọa sử dụng email out-of –band bất tiện Với CryptDB, PC chủ tọa biết viết review cho viết cô ấy, kể cô chiếm ứng dụng hay sở liệu, cô key giải mã (việc thực đày đủ sách yêu cầu thiết lập PC chủ tọa (PC chairs): chủ tọa chính, chủ tọa backup chịu tránh nhiệm review viết chủ tọa HotCRP cho phép PC chủ tọa đóng vai PC thành viên, thích CryptDB sử dụng để ngăn chủ tọa đạt truy cập tới key người review gắn với viết cô ấy.) Lý vị từ SQL “NoConflict” kiểm tra xem liệu PC thành viên có mâu thuẫn với viết ngăn chặn proxy cung cấp truy cập tới PC chủ tọa key chain (chúng ta giải sử PC chủ tọa không thay đổi ứng dụng để log lại mật PC thành viên khác để lật đổ hệ thống) grad-apply tuyển sinh sau đại học sử dụng MIT EECS Chúng thích lược đồ phép thư mục ứng dụng truy cập người ứng tuyển riêng giảng viên sử dụng (reviewers.reviewer_id reviewer) bảng canddidatess, … SPEAKS_FOR (letter_id letter) bảng letter Người nộp đơn thấy tất thư mục liệu ngoại trừ thư giới thiệu nhìn chung, grad-apply có điều khiển truy cập đơn giản thích đơn giản 6.Thảo luận – Discussion Thiết kế CryptDB hỗ trợ hầu hết truy vấn quan hệ kết hợp loại liệu tiêu chuẩn, integer text/varchar Các tính toán bổ sung thêm vào CryptDB cách mở rộng onion có, thêm onion cho loại liệu cụ thể (ví dụ truy vấn đa chiều – spatial and multidimensional range queries [43]) Ngoài ra, vài trường hợp, ảnh xạ phép toán không hỗ trợ phức tạp sang phép toán đơn giản (ví dụ, trích tháng ngày mã hóa đơn giản trường ngày, tháng, năm ngày mã hóa riêng lẻ) Có phép toán định CryptDB khong thể hỗ trợ liệu mã hóa Ví dụ, không hỗ trợ tính toán so sánh cột, WHERE salary > age*2+10 CryptDB xử lý phần truy vấn này, yêu cầu vài xử lý proxy Trong CryptDB, truy ván phải (1) viết lại thành truy vấn select cột, SELECT age*2+10 FROM…, mà CryptDB tính toán sử dụng HOM, (2) mã hóa lại proxy, tạo cột (gọi aux) DBMS server bao gồm giá trị mã hóa Cuối cùng, truy vấn ban đầu với vị từ WHERE salary > aux chạy Chúng không bị ảnh hưởng giới hạn nà ứng dụng kiểm tra (TCP-C, phpBB, HotCRP, grad-apply) Trong chế độ đa principal, CryptDB thực tính toán phía server giá trị mã hóa cho principal khác nhau, kể ứng dụng có quyền tất principal mà ta thảo luận, mã mã hóa với key khác Đối với vài tính toán, thực tế proxy thực tính toán sau giải mã liệu, với tính toán khác (ví dụ, tính toán phạm vi rộng lớn – large-scale aggregates) cách tiếp cận tốn Một khả mở rộng để CryptDB hỗ trợ truy vấn để trì nhiều mã cho giá trị vậy, mã hóa key khác 7.Triển khai - Implementation CryptDB proxy bao gồm thư viện C++ modun Lua Thư viện C++ bao gồm phân tích cú pháp truy vấn (query parser); mã hóa/ viết lại truy vấn (query encryptor/rewriter), để mã hóa trường bao gồm UDF truy vấn; modun giải mã kết Để cho phép ứng dụng suốt sử dụng CryptDB, sử dụng MySQL proxy [47] thực modun Lua để chuyển truy vấn kết tới từ modun C++ Chúng thực giao thức mật mã sử dụng NTL [44] Việc thực CryptDB bao gồm ~18,000 dòng code C++ ~150 dòng code Lua, với ~10,000 dòng code kiểm tra khác CryptDB có tính di động (portable) thực phiên cho Postgres 9.0 MySQL 5.1 Việc thực ban đầu dựa Postgress mô tả báo cáo kỹ thuật gần [39] Việc để CryptDB hoạt động với MySQL yêu cầu thay đổi 86 dòng code, chủ yếu code để kết nối MySQL server khai báo UDF Như đề cập trước đó, CryptDB không thay đổi DBMS; thuwcjhieenj tất chức phía server với UDF bảng phí server Thiết kế CryptDB làm việc SQL DBMS phổ biến mà hỗ trợ UDF 8.Đánh giá thí nghiệm – Experimental Evaluation Trong phần này, đánh giá khía cạnh CryptDB: khó khăn việc điều chỉnh ứng dụng để chạy chương trình điều khiển tới CryptDB, loại truy vấn loại ứng dụng CryptDB hỗ trợ, lức độ an toàn CryptDB cung cấp, hiệu tác động việc sử dụng CryptDB Với phân tích này, sử dụng bảy ứng dụng, lượng lớn truy vấn SQL để đánh giá Chúng đánh gái hiệu thích (annotations) thay đổi ứng dụng cần thiết ứng dụng mô tả phần (phpBB, HotCRP, grad-apply), kết hợp truy vấn TPC-C (a standard workload in the database industruy) Sau phân tích chức an toàn CryptDB ứng dụng nữa, TPC-C, lượng lớn truy vấn SQL Ba ứng dụng bổ sung OpenEMR, ứng dụng hồ sơ ý tế điện tử lưu trữ liệu ý tế riêng tư bệnh nhân; ứng dụng web lớp MIT (6.02), lưu trữ lớp học sinh; PHP-calendar, lưu trữ lịch làm việc người Lượng lớn truy vấn SQL để theo dõi đến từ server MySQL MIT, sql.mit.edu Server sử dụng chủ yếu ứng dụng web chạy scripts.mit.edu, dịch vụ hosting ứng dụng web chia sẻ điều hành Ban xử lsy thông tin sinh viên MIT (Student Information Processing Board – SIPB) Thêm vào đó, server SQL sử dụng mởi số ứng udngj chạy máy khác sử dụng sql.mit.edu để lưu trữ liệu chúng Chúng theo dõi khoảng 10 ngày, có khoảng 126 triệu truy vấn Hình tóm tắt số liệu thống kê sơ đồ cho sql.mit.edu; sở liệu gần trường hợp riêng biệt vài ứng dung Cuối cùng, đánh giá hiệu suất tổng thể CryptDB ứng dụng phpBB truy vấn kết hợp từ TPC-C, thực phân tích chi tiết thông qua microbenchmarks Trong sáu ứng dụng (không tính TPC-C), mã hóa cột nhạy cảm, theo kiểm tra thủ công Một vài trường rõ ràng nhạy cảm (ví dụ, grades, private message, medical information), số khác không (ví dụ, thời gian tin nhắn post) Không có ngưỡng rõ ràng nhạy cảm hay không, hoàn toàn rõ ràng cho xác định trường chắn nhạy cảm Trong trường hợp TPC-C, mã hóa tất cột sở liệu chế độ single-principal nghiên cứu hiệu suất chức DBMS mã hóa hoàn toàn 8.1 Các thay đổi ứng dụng Hình tóm tắt số lượng kết lập trình cần thiết để sử dụng CryptDB ba ứng dụng web đa người dùng truy vấn single-principal TPC-C Kết cho thấy rằng, chế độ multi-principal, CryptDB yêu cầu từ 11 đến 12 thích lược đồ (29 tới 111 tổng số), đến dòng code thay đổi để cung cấp mật người dùng cho proxy, để đảm bảo an toàn thông tin nhạy cảm lưu trữ sở liệu Một phần đơn giản việc đảm bảo an toàn cột bổ sung yêu cầu thích hầu hết trường hợp Đối với truy vấn single-principal TPC-C, việc sử dụng CryptDB không yêu cầu thích ứng dụng 8.2 Đánh giá chức Để đánh giá cột nào, phép toán nào, truy vấn CryptDB hỗ trợ, phân tích truy vấn sinh sáu ứng dụng web (bao gồm ba ứng dụng phân tích phần 8.1), truy vấn TPC-C, truy vấn SQL từ sql.mit.edu Kết thể nửa bên trái Hình CryptDB hỗ trợ hầu hết truy vấn; số lượng cột cột “cần rõ – needs plaintext”, mà việc đếm cột xử lý dạng mã hóa CryptDb, tương đối nhỏ so với tổng số cột Với PHP-calendar OpenEMR, CryptDB không hỗ trợ truy vấn trường nhạy cảm định mà thực thao tác chuỗi (ví dụ chuyển đổi chuỗi chữ thường) thao tác ngày (ví dụ, lấy ngày, tháng, năm ngày mã hóa) Tuy nhiên, chức tính toán trước với kết thêm vào cột độc lập (ví dụ, ba phần ngày mã hóa tách riêng), CryptDB hỗ trợ truy vấn Hai cột tiếp theo, “needs HOM” “needs SEARCH”, ánh xạ số lượng cột cho lược đồ mã hóa cần thiết để xử lý vài truy vấn Các số gợi ý lược đồ mã hóa quan trọng; lược đồ này, CryptDB khả hỗ trợ truy vấn Dựa phân tích theo dõi sql.mit.edu, thấy CryptDB có khả hỗ trợ tính toán tất trừ 1,094 cột 128,840 cột quan sát theo dõi “in-proxy processing” cho thấy kết phân tích với giả định proxy tực vài tính toán nhẹ (lightweight) kết trả từ DBMS server Đặc biệt, điều bao gồm phép toán mà không cần thiết để tính toán tập hàng kết để tập hợp hàng (nghĩa là, biểu thức mà không xuất mệnh đề WHERE, HAVING, hay GROYP BY, mệnh đề ORDER BY với LIMIT, toán tử tập hợp (aggregate operators)) Với xử lý proxy, CryptDB có khả xử lý truy vấn liệu mã hóa tất trừ 571 cột tổng số 128,940 cột, hỗ trợ 99.5% cột Trong 571 cột, 222 sử dụng toán tử bitwise mệnh đè WHERE thực bitwise aggregation, ứng dụng Gallery2 chẳng hạn, sử dụng bitmask trường cho phép tham vấn chúng mệnh đề WHERE Việc viết lại ứng dụng để lưu trữ cho phép cách khác cho phép CryptDB hỗ trợ phép toán 205 cột khác thực xử lý chuỗi mệnh đề WHERE, so sánh phiên chữ thường hai chuỗi có tương xứng không Việc lưu trữ keyed hash phiên chữ thường chuỗi cho cột, tương tự lượt đồ JOIN-ADJ, hỗ trợ equality check trường hợp nhạy cảm cho mã 76 cột liên quan tới chuyển đổi toán học mệnh đề WHERE, tháo tác ngày, thời gian, điểm, tọa độ hình học 41 cột gọi toán tử LIKE với tham chiếu cột cho mô hình (pattern); thường sử dụng để kiểm tra giá trị đặc biệt với bảng lưu trữ motojdanh sách địa IP bị cấm, tên người dùng, URL,… Một truy vấn viết lại mục liệu nhạy cảm 8.3 Đánh giá an toàn Để hiểu số lượng thông tin mà bị lộ cho kẻ xấu thực tế, nghiên cứu mức onion trạng thái ổn định cột khác cho loạt ứng dụng truy vấn Để định lượng mức độ an toàn, xác định MinEnc môt cột lược đồ mã hóa onion yếu bị lộ onion cột onion đạt tới trạng thái ổn định (ví dụ, sau ứng dụng phát sinh tất loại truy vấn, sau chạy toàn theo dõi) Chúng xem xét RND HOM lược đồ mạnh nhất, theo sau SEARCH, DET JOIN, kết thúc với lược đồ yếu OPE Ví dụ, cột có onion Eq RND, onion Ord OPE onion Add HOM, MinEnc cột OPE Phía bên phải hình cho thấy mức độ onion MinEnc cho loạt úng dụng truy vấn theo dõi Chúng thấy hầu hết trường RND, lược đồ an toàn Ví dụ OpenEMR có hàng trăm trường nhạy cảm mô tả điều kiện y tế lịch sử bệnh nhân, trường hầu hết chèn lấy, không sử dụng tính toán Một số cột DET, thường để thực tra cứu key joins OPE, với việc để lộ thứ tự (order), sử dụng thường xuyên nhất, hầu hết cho trường không nhạy cảm (ví dụ nhãn thời gian, số lượng tin nhắn) Vì thế, bảo mật điều chỉnh CryptDB cung cấp cải thiện đáng kể tính bảo mật việc tiết lộ tất lược đồ mã hóa đến server Để phân tích an toàn CryptDB cho cột cụ thể mà đặc biệt nhạy cảm, xcas định mức an toàn mới, HIGH, bao gồm lược độ RND HOM, DET cho cột lặp lại (trong trường hợp DET tương đương cách hợp lý với RND) Đây lược đồ mã hóa an toàn cao gần không rò rỉ liệu DET cho cột lặp lặp lại OPE khoogn phải phần HIGH chúng để lộ mối quan hệ tới DBMS server Cột bên phải Hình cho thấy hầu hết cột đặc biệt nhạy cảm (một lần nữa, theo kiểm tra thủ công) HIGH 10 Kết luận Chúng trình bày CryptDB, hệ thống cung cấp mức bảo mật mạnh mẽ đảm bảo tính bí mật phải đối mặt với mối đe dọa đáng kể cho ứng dụng database-backed: DBAs xấu thỏa hiệp tùy ý server ứng dụng DBMS CryptDB đạt mực đích sử dụng ba ý tưởng: chạy truy vấn liệu mã hóa sử dụng chiến lược mã hóa SQL mới, tự động điều chỉnh mức mã hóa sử dụng onion mã hóa để tối thiểu thông tin bị lộ cho DBMS không tin cậy, kết hợp key mã hóa với mật người dùng để người dùng hợp pháp truy cập tới liệu mã hóa Đánh giá khảo sát lớn 126 triệu truy vấn SQL từ server MySQL cho thấy CryptDB hỗ trợ tính toán liệu mã hóa cho 99.5% số 128,840 cột theo dõi Phân tích an toàn cho thấy CryptDB bảo vệ hầu hết trường nhạy cảm với lược đồ mã hóa an toàn cao với sáu ứng dụng Mã nguồn có sẵn để tải http://css.csail.mit.edu/cryptdb/ [...]... khi bị thỏa hiệp Việc lộ dữ liệu của những người dùng đang hoạt động trong trường hợp thỏa hiệp là không thể tránh được: để tính toán trên dữ liệu mã hóa, một vài dữ liệu của người dùng hoạt động phải được ứng dụng giải mã Trong CryptDB, mỗi user có một key( ví dụ mật khẩu mức ứng dụng ) mà cho phép user đó truy cập tới dữ liệu của mình CryptDB mã hóa các mục dữ liệu khác nhau với các key khác nhau,... Chúng tôi đã trình bày CryptDB, một hệ thống cung cấp các mức bảo mật mạnh mẽ đảm bảo tính bí mật khi phải đối mặt với các mối đe dọa đáng kể cho các ứng dụng database-backed: DBAs xấu và các thỏa hiệp tùy ý của server ứng dụng và DBMS CryptDB đạt được mực đích của nó sử dụng ba ý tưởng: chạy các truy vấn trên dữ liệu mã hóa sử dụng một chiến lược mã hóa SQL mới, tự động điều chỉnh mức mã hóa sử dụng... user2 truy cập tới message 5, key của msg 5 được mã hóa với key của user 1, và cũng được mã hóa riêng với key của user 2 Mỗi trường nhạy cảm được mã hóa với key của principal trong chú thích ENC_FOR (ENC_FOR annotation) CryptDB mã hóa trường nhạy cảm với các onion theo cùng cách như đối với principal CryptDB đơn lẻ, ngoại trừ các key onion được suy ra từ key của một principal như trái ngược với một... onion mã hóa để tối thiểu các thông tin bị lộ cho DBMS không tin cậy, và kết hợp các key mã hóa với các mật khẩu của người dùng để chỉ những người dùng hợp pháp mới có thể truy cập được tới dữ liệu mã hóa Đánh giá của chúng tôi trong một cuộc khảo sát lớn 126 triệu truy vấn SQL từ một server MySQL cho thấy rằng CryptDB có thể hỗ trợ các tính toán trên dữ liệu mã hóa cho 99.5% trong số 128,840 cột được. .. độ đa principal, CryptDB không thể thực hiện các tính toán phía server trên các giá trị được mã hóa cho các principal khác nhau, kể cả nếu ứng dụng có quyền của tất cả các principal mà ta đã thảo luận, bởi vì các bản mã được mã hóa với các key khác nhau Đối với một vài tính toán, thực tế có thể proxy thực hiện tính toán sau khi giải mã dữ liệu, nhưng với những tính toán khác (ví dụ, tính toán trên phạm... 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 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... sinh ra truy vấn UPDATE Table1 SET C2-Eq = DECRYPT_RND(KT1,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ấp bảo mật tốt hơn, DBMS server không được join cac cột mà ứng dụng không yêu cầu join, vì vậy các cột mà không bao giờ được join không nên được mã hóa với cùng các key 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 join, được biết từ trước đó (are known a priori), equi-join rất dễ dàng để hỗ trợ: 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. .. 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. .. các kết quả Proxy chỉ có thể giải mã dữ liệu mà user đã truy cập, dựa vào chính sách kiểm soát truy cập, Proxy đưa dữ liệu mã hóa cho ứng dụng, và bây giờ có thể tính toán trên nó Khi user đăng xuất, proxy xóa key của user 4.1.Các chú thích chính sách – Policy Annotations Để thể hiện chính sách bảo mật dữ liệu của một ứng dụng database-backed tại mức của các truy vấn SQL, nhà phát triển ứng dụng có