Nghiên cứu và phát triển một số giải pháp bảo mật và bảo vệ tính riêng tư trong cơ sở dữ liệu thuê ngoài (ODBS)

Căn cứ vào tính chất quan trọng của từng bài toán, chúng tôi chọn thứ tự trình bày trong luận án như sau: trước tiên là bài toán bảo vệ tính riêng tư người dùng vì xử lý truy vấn là dịc

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN

PHẠM THỊ BẠCH HUỆ

NGHIÊN CỨU VÀ PHÁT TRIỂN MỘT SỐ GIẢI PHÁP BẢO MẬT VÀ BẢO VỆ TÍNH RIÊNG TƯ

TRONG CƠ SỞ DỮ LIỆU THUÊ NGOÀI (ODBS)

LU Ậ N ÁN TI Ế N S Ĩ CÔNG NGH Ệ THÔNG TIN

THÀNH PH Ố H Ồ CHÍ MINH - 2013

NGHIÊN CỨU VÀ PHÁT TRIỂN MỘT SỐ GIẢI PHÁP BẢO MẬT VÀ BẢO VỆ TÍNH RIÊNG TƯ

TRONG CƠ SỞ DỮ LIỆU THUÊ NGOÀI (ODBS)

LỜI CAM ĐOAN

Tôi xin cam đoan rằng luận án này là công trình nghiên cứu khoa học của tôi Các kết quả của luận án là trung thực và chưa từng được ai công bố trong bất kỳ công trình nào khác

Tp Hồ Chí Minh, ngày 20 tháng 10 năm 2013

Người thực hiện

Phạm Thị Bạch Huệ

LỜI CẢM ƠN

Tôi chân thành bày tỏ lòng biết ơn sâu sắc đến PGS TS Đồng Thị Bích Thủy và

PGS TS Nguyễn Đình Thúc Quý Thầy Cô đã tận tình hướng dẫn tôi trong suốt quá

trình làm luận án Tôi xin cảm ơn PGS TS Đặng Trần Khánh đã mở ra cho tôi bối

cảnh nghiên cứu và các bài toán khoa học lý thú Tôi đã được Quý Thầy Cô cung cấp tài liệu, chỉ bảo tận tình về phong cách làm việc, phương pháp nghiên cứu khoa học

và tạo điều kiện thuận lợi cho tôi học tập và nghiên cứu

Tôi cũng xin gửi lời cảm ơn đến Giáo sư Echizen, giáo sư Sven Wohlgemuth,

Viện Thông tin Nhật Bản (NII), đã tạo điều kiện cho tôi học tập nghiên cứu trong khoảng thời gian thực tập tại Nhật Bản phục vụ cho luận án

Xin bày tỏ lòng biết ơn đến Quý Thầy Cô trong Khoa Công nghệ thông tin, Đại

học Khoa học Tự nhiên Tp Hồ Chí Minh Quý Thầy Cô đã trang bị cho tôi kiến thức

quý báu để tôi phục vụ cho luận án này

Cảm ơn các bạn bè đồng nghiệp đã quan tâm và giúp đỡ tôi trong quá trình học tập, nghiên cứu

Tp Hồ Chí Minh, tháng 10 năm 2012

DANH MỤC CÁC TỪ VIẾT TẮT

ODBS Outsourced Database Service

SMS Single data owner-Multiple clients-Service provider

MMS Multiple data owner-Multiple clients-Service provider

OPES Order Preserving Encryption Scheme

FGAC Fine-grained Access Control

EFGAC Enhanced Fine-grained Access Control

PEKS Public Key Encryption with Keyword Search

DANH MỤC CÁC HÌNH VẼ

Hình 1 Mô hình chung của ODBS 7

Hình 2 Các mô hình ODBS : (a) Mô hình SS (b) Mô hình SMS (c) Mô hình MMS 8

Hình 3 Hình minh họa sự kết hợp vận dụng giải pháp của các bài toán bảo mật 161

Hình 1.1 Cấu trúc phân cấp người dùng [13] 24

Hình 2.1 Quá trình xử lý truy vấn tổng quát trong ODBS 32

Hình 2.2 Hình minh họa cách thức mã hóa dữ liệu [26] 36

Hình 2.3 Các bước xử lý truy vấn trong ODBS [26] 39

Hình 2.4 Ba thành phần của phương pháp thực thi truy vấn trên CSDL mã hóa 42

Hình 2.5 Quá trình thực thi một phép toán ĐSQH 44

Hình 2.6 Quá trình thực thi của thuật toán Select_NTimes 50

Hình 2.7 Quá trình thực hiện phép chọn 54

Hình 2.8 Quá trình thực hiện phép kết 57

Hình 2.9 Quá trình thực hiện phép chiếu 58

Hình 2.10 Quá trình thực hiện phép tính tổng hợp và gom nhóm 60

Hình 2.11 Quá trình thực hiện phép toán sắp xếp 61

Hình 2.12 Quá trình thực hiện phép loại bỏ trùng lắp 63

Hình 2.13 Quá trình thực hiện phép hiệu 65

Hình 2.14 So sánh chi phí của ba cách thực thi truy vấn, gồm thực thi trên dữ liệu rõ, giải pháp của Hacigümüs và cộng sự và UPP, khi kích thước phân hoạch thay đổi: (a) Phép chọn (b) Phép chiếu 95

Hình 2.15 Chi phí thực thi phép chọn của ba cách thực thi truy vấn, gồm thực thi trên dữ liệu rõ, giải pháp của Hacigümüs và cộng sự và UPP 96

Hình 2.16 Chi phí thực thi phép chiếu của ba cách thực thi truy vấn, gồm thực thi trên dữ liệu rõ, giải pháp của Hacigümüs và cộng sự và UPP 97

Hình 2.17 Chi phí thực thi phép kết của ba cách thực thi truy vấn, gồm thực thi trên dữ liệu rõ, giải pháp của Hacigümüs và cộng sự và UPP 97

Hình 3.1 Bối cảnh bài toán quản lý truy cập trong ODBS 102

Hình 3.2 Binary trie ứng với ma trận quyền truy xuất Bảng 1.1 105

Hình 3.3 Gán khóa và suy dẫn khóa bởi FGAC 107

Hình 3.4 Cấu trúc binary trie ứng với ma trận ở Bảng 3.4 116

Hình 3.5 Hình minh họa việc gán khóa và suy dẫn khóa dùng token 119

Hình 3.6 Dùng thêm token để giảm số lượng khóa người dùng phải giữ còn 1 khóa 121

Hình 3.7 So sánh thời gian mã dữ liệu bởi CRT so với RSA, DES và AES 126

Hình 3.8 Biểu đồ so sánh thời gian hồi đáp truy vấn cho Q1 127

Hình 3.9 Biểu đồ thể hiện thời gian hồi đáp truy vấn cho Q2 128

Hình 3.10 Số lượng khóa trung bình mỗi nhóm người dùng phải giữ khi dữ liệu thay đổi trên: (a) Số nhóm người dùng (b) Số nhóm tài nguyên (c) Số cột của CSDL 129 Hình 3.11 Thời gian suy dẫn khóa trung bình để người dùng truy cập một dòng dữ liệu khi dữ liệu thay đổi trên: (a) Số nhóm người dùng (b) Số nhóm tài nguyên (c) Số cột của CSDL 131

Hình 4.1 Bối cảnh bài toán xác thực trong ODBS 139

Hình 4.2 Quá trình DO cấp tài khoản cho người dùng 142

Hình 4.3 Quá trình DO gửi thông tin tài khoản cho máy chủ 143

Hình 4.4 Quá trình người dùng gửi thông tin tài khoản cho máy chủ 143

Hình 4.5 Dữ liệu dùng cho cơ chế xác thực 144

Hình 4.6 Quá trình xác thực lẫn nhau 146

Hình 4.7 Thời gian mã hóa dùng PEKS-PM (mili giây) 148

Hình 4.8 Thời gian tìm kiếm của PEKS-PM (mili giây) 149

Hình 4.9 Bối cảnh bài toán ghi nhật ký hệ thống trong ODBS 152

Hình 4.10 Quá trình ghi nhật ký trong ODBS 153

Hình 4.11 Hình minh họa cho giai đoạn ghi nhật ký trong ODBS 154

Hình 4.12 Quá trình tìm kiếm trên dữ liệu nhật ký 155

DANH MỤC CÁC BẢNG BIỂU

Bảng 1.1 Ma trận quyền truy xuất 22

Bảng 2.1 Mô tả thuật toán Select_NTimes 45

Bảng 2.2 Bảng mô tả dữ liệu thử nghiệm 92

Bảng 2.3 Bảng so sánh đặc điểm của các phương pháp thực thi truy vấn 98

Bảng 3.1 Ma trận quyền truy xuất 22

Bảng 3.2 Khóa phân phối cho từng người dùng và khóa có thể suy dẫn theo quyền truy cập ở Bảng 1.1 108

Bảng 3.3 Chi phí mã và giải mã dữ liệu thực hiện bởi giải thuật dựa trên CRT 111

Bảng 3.4 Ma trận quyền truy xuất theo cột 115

Bảng 3.5 Ma trận sau khi áp dụng bước 2 của EFGAC trên Bảng 3.3 116

Bảng 3.6 Khóa từng nhóm người dùng phải giữ để suy dẫn các khóa cần thiết 116

Bảng 3.7 Thời gian hồi đáp truy vấn cho Q1 127

Bảng 3.8 Thời gian hồi đáp truy vấn cho Q2 128

Bảng 3.9 Bảng so sánh đặc điểm của FGAC và các công trình liên quan 132

Bảng 4.1 So sánh đặc tính của nghi thức xác thực đề xuất với các giao thức hiện có 147

DANH MỤC CÁC THUẬT TOÁN

Thuật toán 2.1 Select_NTimes - Truy xuất dữ liệu từ máy chủ 47

Thuật toán 2.2 Select_NTimes_Grouped - Truy xuất dữ liệu từ máy chủ, kết quả trả về được gom nhóm theo tập thuộc tính chỉ định 52

Thuật toán 2.3 Selection - Thuật toán thực thi phép chọn 54

Thuật toán 2.4 Join - Thuật toán thực thi phép kết 56

Thuật toán 2.5 Projection - Thuật toán thực thi phép chiếu 58

Thuật toán 2.6 Group_Aggregation - Thuật toán thực thi phép tính tổng hợp và gom nhóm 59

Thuật toán 2.7 Sort - Thuật toán thực hiện phép sắp xếp 61

Thuật toán 2.8 Duplicate_Elimination - Thuật toán thực thi phép loại bỏ trùng lắp 62

Thuật toán 2.9 Difference - Thuật toán thực thi phép hiệu hai quan hệ 64

Thuật toán 2.10 Union - Thuật toán thực thi phép hội hai quan hệ 65

Thuật toán 2.11 Intersect - Thuật toán thực thi phép giao hai quan hệ 66

Thuật toán 2.12 Select_Disjunction - Thuật toán thực thi phép chọn với điều kiện C1 ∨ C2 66

Thuật toán 2.13 Select_Conjunction - Thuật toán thực thi phép chọn với điều kiện C1 ∧ C2 67

GIỚI THIỆU

Tóm tắt

Dịch vụ quản lý cơ sở dữ liệu thuê ngoài, bên cạnh việc mang lại những lợi ích

về kinh tế và tính chuyên nghiệp trong quản lý dữ liệu, thì thách thức đặt ra liên quan đến vấn đề bảo mật và bảo vệ tính riêng tư Nguyên nhân chính là do máy chủ thuộc về một tổ chức bên ngoài, được xem là không đáng tin cậy đối với nội dung cơ sở dữ liệu Hơn nữa, quá trình thao tác dữ liệu của các thực thể (là chủ

sở hữu dữ liệu hay người dùng) đều thông qua mạng diện rộng Chương này giới thiệu mục tiêu của luận án liên quan đến vấn đề bảo mật và bảo vệ tính riêng tư đặt ra trong dịch vụ quản lý cơ sở dữ liệu thuê ngoài Mục tiêu sẽ được

cụ thể hóa qua động cơ nghiên cứu, các vấn đề khoa học đặt ra đối với dịch vụ này và nội dung nghiên cứu của luận án Kết quả luận án và bố cục chi tiết của luận án sẽ được giới thiệu ở cuối chương

Những năm gần đây xuất hiện một dịch vụ mới, đó là dịch vụ quản lý CSDL thuê ngoài (Outsourced Database Service – ODBS) Khi sử dụng ODBS, DO không phải đầu tư tài nguyên cho việc lưu trữ và quản lý dữ liệu mà thuê nhà cung cấp (Service Provider – SP) thực hiện điều này Chi phí hoạt động của tổ chức

giảm đi đáng kể trong khi họ có thể tập trung vào các hoạt động chính yếu hơn [26] Hơn thế nữa, dữ liệu thường được quản lý một cách chuyên nghiệp hơn bởi đội ngũ giàu kinh nghiệm

Có bốn loại thực thể chính tham gia vào một hệ thống ODBS [13] (Hình 1):

• Chủ sở hữu dữ liệu (Data Owner - DO): người tạo ra hoặc làm chủ dữ liệu

• Máy chủ (Server): máy tính đặt tại SP có nhiệm vụ lưu trữ và quản lý dữ

liệu của DO

• Người dùng (User): cá nhân hay ứng dụng truy cập CSDL lưu ở máy chủ

theo quyền DO đã cấp

• Máy khách (Client): thiết bị đầu cuối có nhiệm vụ tiếp nhận yêu cầu (từ DO

hoặc người dùng) và giao tiếp với máy chủ để đáp ứng cho yêu cầu nhận được

Hình 1 Mô hình chung của ODBS

Thông qua máy khách, DO có thể gửi CSDL đến SP, yêu cầu máy chủ tại SP

cập nhật CSDL hoặc gửi siêu dữ liệu đến người dùng Siêu dữ liệu (metadata) là dữ

liệu cần thiết để các thực thể có thể giao tiếp với hệ thống theo vai trò tương ứng, chẳng hạn như siêu dữ liệu thể hiện cách thức lưu trữ dữ liệu để người dùng biết cách truy vấn dữ liệu, siêu dữ liệu về quyền truy cập của những người dùng trong hệ thống, siêu dữ liệu về cách thức truy cập dữ liệu của từng người dùng,… Máy khách

Người dùng

Ở máy khách Ở máy chủ của SP

Gửi/ thao tác trên dữ liệu

Tìm kiếm Gửi/ nhận siêu dữ liệu

còn có chức năng tiếp nhận câu truy vấn từ người dùng, yêu cầu máy chủ thực hiện truy vấn và xử lý kết quả trả về từ máy chủ để có kết quả cuối cùng cho người dùng Trong luận án, chúng tôi quan tâm trường hợp SP là một thực thể duy nhất Trong thực tế, ODBS được triển khai theo nhiều mô hình khác nhau tùy thuộc vào

số lượng DO và số lượng người dùng trong hệ thống [16] Mô hình đơn giản nhất,

gọi là mô hình SS (Single user-Service provider), trong đó DO thuê SP lưu trữ và quản lý CSDL, DO cũng là người dùng truy cập CSDL Phức tạp nhất, gọi là mô hình MMS (Multiple data owner-Multiple clients-Service provider), có nhiều DO

cùng sở hữu CSDL lưu lại SP, mỗi DO chỉ có quyền trên một phần của CSDL này,

có nhiều người dùng truy cập đến CSDL Trong bối cảnh luận án, chúng tôi chọn

mô hình SMS (Single data owner-Multiple clients-Service provider), là trường hợp

đơn giản hơn của mô hình MMS, trong đó một DO thuê SP lưu trữ và quản lý CSDL, ngoài DO còn có nhiều người dùng truy cập CSDL này Kết quả nghiên cứu của luận án trên mô hình SMS sẽ được xem xét để vận dụng giải quyết các vấn đề

về bảo mật và bảo vệ tính riêng tư cho mô hình MMS trong tương lai

Hình 2 Các mô hình ODBS: (a) Mô hình SS (b) Mô hình SMS (c) Mô hình MMS

Với cách quản lý dữ liệu truyền thống, người quản trị CSDL (và máy chủ) được xem là tin cậy (trusted) đối với nội dung dữ liệu và có toàn quyền trên dữ liệu Trong ODBS, dữ liệu của DO được lưu trữ tại SP và do SP quản lý DO chỉ sử dụng dịch vụ lưu trữ và xử lý dữ liệu của SP nhưng DO thường không tin tưởng để giao quyền quản lý nội dung CSDL cho SP Vì lý do bảo mật, DO cần phải giấu nội dung CSDL trước khi lưu trữ CSDL trên máy chủ của SP DO quản lý quyền truy cập dữ liệu cho những người dùng có nhu cầu truy cập dữ liệu từ hệ thống dựa vào vai trò của người dùng Tùy vào vai trò của thực thể đang dùng máy khách để tương

tác với hệ thống mà máy khách có thể truy cập phần dữ liệu tương ứng Tương tự, trong trường hợp máy khách phục vụ cho người dùng, nội dung siêu dữ liệu mà DO phân phối cho máy khách cũng tùy thuộc vai trò của người dùng đang sử dụng máy khách đó để tương tác với hệ thống

Do máy chủ được xem là không đáng tin cậy đối với nội dung CSDL, và quá trình tương tác giữa các thực thể trong ODBS đều thông qua mạng diện rộng, nên bên cạnh những thuận lợi do ODBS mang lại, ODBS cũng đối diện với nhiều vấn

đề về bảo mật và bảo vệ tính riêng tư Các vấn đề quan trọng có thể kể:

• Xác thực (Authentication) [22]: giúp cho máy chủ xác minh người dùng đang đăng nhập vào hệ thống là một người dùng hợp lệ và người dùng cũng

có thể xác minh rằng họ đang kết nối với một máy chủ hợp lệ chứ không phải là một chủ thể nào đó mạo danh Thông tin đăng nhập của người dùng mang tính riêng tư cần phải được bảo vệ đối với máy chủ

• Bảo vệ tính bí mật dữ liệu (Data confidentiality) ([15], [26]): nội dung dữ liệu mà DO thuê SP quản lý cần phải được bảo vệ khỏi những truy cập bất hợp pháp, ngay cả từ phía máy chủ

• Bảo vệ tính riêng tư dữ liệu (Data privacy) [13]: vì tính bí mật của nội dung

dữ liệu, và mỗi người dùng có vai trò khác nhau trên CSDL nên mỗi đơn vị

dữ liệu phải có thể và chỉ được truy cập bởi những người dùng mà DO đã cấp phép truy cập

• Bảo vệ tính riêng tư người dùng (User privacy) [33]: những nhu cầu truy vấn

mà một người dùng gửi đến máy chủ và kết quả truy vấn tạo nên những đặc điểm riêng tư của người dùng Hệ thống cần đảm bảo, ngoài bản thân người dùng, không có một chủ thể nào khác biết được câu truy vấn và kết quả truy vấn do người dùng thực hiện trên CSDL, ngay cả DO và máy chủ của SP

• Xác thực kết quả truy vấn (Query assurance) ([35], [36], [48]): dựa trên giả

sử rằng DO và người dùng không tin vào sự trung thực của máy chủ tại SP

trong việc quản lý và thao tác dữ liệu nên khi nhận kết quả truy vấn trả về từ máy chủ, người dùng phải có thể xác thực rằng kết quả này là đúng (correctness), là đủ (completeness) và mới (freshness) Kết quả trả về là đúng khi nó bao gồm các dòng dữ liệu do chính DO tạo ra ban đầu mà không bị chỉnh sửa bởi chủ thể không có quyền (người quản trị CSDL tại SP chẳng hạn) Kết quả trả về là đủ khi nó bao gồm tất cả các dòng dữ liệu lẽ ra phải được trả về (các dòng dữ liệu thỏa mãn điều kiện truy vấn) Kết quả trả về là mới khi nó được kết xuất dựa trên tình trạng mới nhất của CSDL trên đó người dùng đang thực hiện truy vấn

• Ghi nhật ký (Auditing) [16]: là việc ghi nhận lại thông tin liên quan đến các thao tác diễn ra trên CSDL nhằm phục vụ việc theo dõi quá trình làm việc của hệ thống khi cần thiết Dữ liệu nhật ký thường chứa đựng thông tin liên quan đến tính bí mật dữ liệu (thể hiện qua câu truy vấn, kết quả truy vấn) và tính riêng tư người dùng (người dùng nào đã thực hiện câu truy vấn gì) Việc lưu trữ và tìm kiếm trên dữ liệu nhật ký cần được thực hiện sao cho tính bí mật dữ liệu và tính riêng tư người dùng được đảm bảo

• Quản lý siêu dữ liệu (Metadata management) [14]: siêu dữ liệu ta quan tâm

là dữ liệu cần thiết để các thực thể trong hệ thống hoạt động bình thường Siêu dữ liệu thường chứa thông tin nhạy cảm Quản lý siêu dữ liệu xem xét vấn đề về tổ chức và lưu trữ siêu dữ liệu sao cho các thực thể trong hệ thống vẫn hoạt động bình thường trong khi các yêu cầu về bảo mật trong ODBS được thỏa mãn

Các bài toán bảo mật nêu trên có vai trò quan trọng quyết định sự thành công của ODBS Theo thống kê năm 2011, có ít nhất 8 triệu hồ sơ y tế bị đánh cắp trong khoảng từ năm 2009 – 2011 [29]; có hơn 77 triệu hồ sơ cá nhân, gồm cả thông tin thẻ tín dụng, bị truy cập trên hệ thống cung cấp trò chơi trực tuyến của Sony (Sony Playstation Network) [41] Nguyên nhân chủ yếu của việc mất cắp này xuất phát từ vấn đề quản lý quyền truy cập, máy chủ bị tấn công hay do cả từ phía người quản trị

CSDL không đáng tin cậy ([10], [27], [37]) Ngoài ra, hiện tại, tính riêng tư của người sử dụng các dịch vụ trực tuyến (ví dụ dịch vụ của Google, Microsoft Corp., Facebook, Twitter) gần như bị phơi bày hoàn toàn đối với nhà cung cấp dịch vụ và người sử dụng dịch vụ không thể kiểm soát thông tin riêng tư của họ có được bảo vệ hay không [10]

Vì những lý do trên, chúng tôi quan tâm đến vấn đề bảo mật và bảo vệ tính riêng

tư trong ODBS Cụ thể, chúng tôi nghiên cứu và phát triển giải pháp cho bốn bài toán sau: xác thực, bảo vệ tính riêng tư dữ liệu, bảo vệ tính riêng tư người dùng và ghi nhật ký Các bài toán bảo mật còn lại là hướng nghiên cứu tiếp theo

của luận án

Như vậy, chúng tôi chọn bối cảnh nghiên cứu của luận án là mô hình SMS của

ODBS, với mục tiêu là nghiên cứu và phát triển giải pháp cho bốn bài toán bảo mật

đã chọn, trên CSDL được tổ chức theo mô hình dữ liệu quan hệ

Căn cứ vào tính chất quan trọng của từng bài toán, chúng tôi chọn thứ tự trình

bày trong luận án như sau: trước tiên là bài toán bảo vệ tính riêng tư người dùng vì

xử lý truy vấn là dịch vụ quan trọng của ODBS; khi tính riêng tư người dùng được

đảm bảo sẽ tạo được niềm tin để người dùng sử dụng dịch vụ; kế đến là bài toán bảo

vệ tính riêng tư dữ liệu, bài toán này không kém phần quan trọng giúp DO kiểm

soát việc chia sẻ dữ liệu; sau đó là phần trình bày bài toán xác thực và bài toán ghi

nhật ký hệ thống trong ODBS, giải pháp cho hai bài toán này góp phần không nhỏ cho giải pháp bảo mật trong toàn hệ thống

Tình hình nghiên cứu trong và ngoài nước

Với bài toán bảo vệ tính riêng tư người dùng, như đã đề cập, ta cần bảo vệ câu

truy vấn mà người dùng thực hiện trên CSDL và kết quả truy vấn Giải pháp cho bài toán bảo vệ tính riêng tư người dùng thể hiện qua phương pháp thực thi truy vấn Ta biết rằng DO cần phải giấu nội dung dữ liệu trước khi lưu trữ tại SP để bảo vệ tính

bí mật dữ liệu Mã hóa là giải pháp phổ biến để phục vụ bảo vệ tính bí mật dữ liệu

([1], [6], [13], [14], [26], [33], [50]) Máy chủ khi đó sẽ thực thi câu truy vấn trên CSDL ở dạng mã hóa mà không cần giải mã dữ liệu

Hiện tại có nhiều giải pháp thực thi truy vấn trên CSDL mã hóa có thể áp dụng cho CSDL quan hệ ([1], [6], [26], [33], [50]) Tuy nhiên, tất cả các giải pháp này chỉ

có thể được sử dụng cho mục tiêu bảo vệ tính bí mật dữ liệu mà không thể dùng cho mục đích bảo vệ tính riêng tư người dùng Nguyên nhân là do phương pháp chuyển đổi điều kiện truy vấn (từ dạng rõ sang dạng tương ứng để có thể thực thi truy vấn trên CSDL dạng mã) trong các giải pháp kể trên đều được thực hiện theo một nguyên tắc cố định làm cho máy chủ có thể nhận biết loại câu truy vấn (ví dụ câu truy vấn thực hiện phép chọn hay phép kết) và thực hiện tấn công thống kê tần suất thực hiện một câu truy vấn nào đó Bằng cách kết hợp thông tin đã biết với những câu truy vấn được thực hiện với tần suất cao, máy chủ có thể biết được ngữ nghĩa của câu truy vấn mà người dùng thực hiện, hoặc nhận ra xu hướng truy cập thông tin và khai thác tri thức trên dữ liệu đang lưu trữ Điều này làm vi phạm tính bí mật

dữ liệu và tính riêng tư người dùng

Tính riêng tư dữ liệu được bảo vệ bằng một cơ chế quản lý truy cập Đã có nhiều

công trình nghiên cứu về việc mã hóa dữ liệu kết hợp với quản lý truy cập ([2], [4], [13], [18], [19]) Sử dụng những giải pháp quản lý truy cập hiện có, DO gặp phải những khó khăn sau: (1) Không thể giới hạn quyền truy cập của người dùng trên một số thuộc tính nhạy cảm của CSDL (2) DO thường xuyên phải xây dựng lại cấu trúc quản lý khóa, phát sinh lại khóa, mã hóa lại dữ liệu khi có sự thay đổi về người dùng, tài nguyên và quyền truy cập trong hệ thống (3) DO thường xuyên giải quyết

bài toán thay khóa (rekey) ngay cả trong những trường hợp không cần thiết Khi

thay khóa, DO phải tải lại dữ liệu từ máy chủ (nếu DO không lưu lại bản sao dữ liệu), phát sinh lại khóa, mã hóa lại dữ liệu, phân phối lại khóa cho những người dùng có liên quan Việc thay khóa gây tốn kém nhiều chi phí

Nghi thức xác thực rất cần thiết trong dịch vụ ODBS Không có nghi thức xác

thực, máy chủ sẽ phải xử lý mọi nhu cầu truy vấn gửi đến vì máy chủ không thể nhận ra một nhu cầu truy vấn gửi từ một người dùng đã đăng ký sử dụng dịch vụ

trước đó hay chưa Trong nhiều ứng dụng thực tế, thông tin đăng nhập của người dùng tiết lộ danh tính của người dùng Trong ODBS, tính riêng tư người dùng phải được đảm bảo, ngay cả đối với máy chủ Các nghi thức xác thực hiện có không đặt

ra mục tiêu bảo vệ tính riêng tư người dùng chứa đựng trong thông tin đăng nhập; tất cả đều hoạt động trên cơ sở máy chủ biết chính xác định danh của người dùng đang đăng nhập hệ thống nên không thể áp dụng trong ODBS ([8], [12], [22], [38], [39])

Bài toán ghi nhật ký và tìm kiếm trên dữ liệu nhật ký (để phục vụ giải trình khi

cần thiết) trong ODBS được Mike Burmester và cộng sự nêu ra với các yêu cầu gần như trái ngược nhau, đó là vừa đạt được mục tiêu có thể giải trình về các hoạt động diễn ra trong hệ thống, vừa đảm bảo tính bí mật dữ liệu và tính riêng tư người dùng [7] Hiện tại có nhiều công trình phục vụ cho việc lưu dữ liệu (tài liệu dạng tập tin, thư điện tử) ở máy chủ không tin cậy và cho phép máy chủ tìm kiếm trên dữ liệu này nhưng không làm vi phạm tính bí mật dữ liệu và tính riêng tư người dùng Tuy nhiên các công trình này có sự khác biệt về vai trò các loại thực thể tham gia vào hệ thống so với ODBS, nên không thể áp dụng cho ODBS Bài toán ghi nhật ký hệ thống trong ODBS chưa được cộng đồng nghiên cứu quan tâm

Lý do thực hiện và mục tiêu đề tài

Những hạn chế đã trình bày ở trên cho thấy kết quả nghiên cứu hiện tại không đáp ứng được cho yêu cầu đặt ra đối với từng bài toán mà luận án quan tâm Đó là

lý do mà chúng tôi thực hiện đề tài này Mục tiêu cụ thể của luận án là như sau:

Bảo vệ tính riêng tư người dùng (User privacy): đề xuất phương pháp thực thi truy vấn không làm lộ thông tin về câu truy vấn hoặc kết quả truy vấn,

ngăn chặn máy chủ thực hiện tấn công thống kê tần suất thực hiện truy vấn gây vi phạm tính riêng tư người dùng

Bảo vệ tính riêng tư dữ liệu (Data privacy): tính riêng tư dữ liệu được DO

đảm bảo bằng cách sử dụng một cơ chế quản lý truy cập (access control

mechanism) Luận án đề xuất cơ chế quản lý truy cập trên đơn vị dữ liệu

là cột (column-level access control/ fine-grained access control) giúp DO

giới hạn quyền truy cập trên một số trường nhạy cảm của CSDL, giảm chi phí quản lý truy cập (qua việc xác định số lượng khóa tối thiểu cần thiết để

mã hóa dữ liệu, giảm chi phí phát sinh khóa, loại trừ một số trường hợp thay khóa không cần thiết), và tạo thuận lợi cho người dùng khi tương tác với hệ thống (giảm thiểu thông tin bí mật mà mỗi người dùng phải giữ, rút ngắn thời gian suy dẫn khóa để người dùng có được các khóa cần thiết cho việc giải mã các tài nguyên họ được cấp quyền truy cập)

Xác thực (Authentication): đề xuất nghi thức xác thực lẫn nhau giữa người dùng và máy chủ nhằm ngăn chặn tình trạng người dùng không hợp lệ truy

cập hệ thống bất hợp pháp hoặc tình trạng mạo danh máy chủ giành quyền điều khiển hệ thống (hijacking attacks) Đặc biệt, nghi thức xác thực mà luận

án đề xuất có thể giấu thông tin đăng nhập của người dùng (thường cho biết danh tính người dùng) đối với máy chủ và chống lại tấn công đánh cắp dữ liệu trên đường truyền từ người dùng trung gian (man-in-the-middle attacks), hoặc tấn công kiểu lặp lại (replay attacks)

Ghi nhật ký hệ thống (Auditing): đề xuất nghi thức ghi nhật ký hệ thống phục vụ giải trình trong ODBS mà không làm vi phạm tính bí mật dữ liệu

và tính riêng tư người dùng chứa đựng trong dữ liệu nhật ký

Nội dung nghiên cứu của luận án

Nội dung nghiên cứu của luận án đối với từng bài toán bảo mật đã chọn là:

• Bảo vệ tính riêng tư người dùng:

- Tìm hiểu các giải pháp thực thi truy vấn trong ODBS và các nguy cơ tấn công làm lộ tính riêng tư người dùng

- Đề ra giải pháp thực thi truy vấn khắc phục các nguy cơ tấn công trên

• Bảo vệ tính riêng tư dữ liệu – Cơ chế quản lý truy cập mức cột:

- Tìm hiểu và đánh giá các cơ chế quản lý truy cập đã được đề xuất cho ODBS; nhận xét về khả năng vận dụng các cơ chế này để quản lý truy cập mức cột

- Đề ra các tiêu chí đánh giá một cơ chế quản lý truy cập trong ODBS

- Trên cơ sở đó, đề xuất cơ chế quản lý truy cập có thể giới hạn truy cập đối với một số trường nhạy cảm trong CSDL, tạo thuận lợi cho DO trong việc quản lý quyền truy cập và cho người dùng khi truy cập dữ liệu từ hệ thống

• Bài toán xác thực và ghi nhật ký hệ thống trong ODBS:

Với bài toán xác thực:

- Tìm hiểu yêu cầu và đặc điểm của bài toán xác thực trong ODBS

- Các khả năng tấn công đối với một cơ chế xác thực

- Đề ra cơ chế xác thực đáp ứng yêu cầu đặt ra và ngăn ngừa được các khả năng tấn công

Với bài toán ghi nhật ký hệ thống:

- Máy chủ được xem là không đáng tin cậy đối với nội dung dữ liệu nhật

ký (vì dữ liệu này có liên quan đến nội dung CSDL, thể hiện tính bí mật

dữ liệu), cùng với yêu cầu về việc không để lộ thông tin về câu truy vấn

và kết quả truy vấn của người dùng (thể hiện tính riêng tư người dùng) tạo nên độ khó của bài toán ghi nhật ký hệ thống trong ODBS

- Đề ra nghi thức ghi nhật ký hệ thống để phục vụ giải trình khi cần thiết

và thỏa mãn các yêu cầu về tính bí dữ liệu và tính riêng tư người dùng

Những đóng góp chính của luận án

Các đóng góp chính của luận án gồm:

• Bảo vệ tính riêng tư người dùng:

- Đề xuất phương pháp thực thi truy vấn bảo vệ tính riêng tư người dùng, thể hiện qua: nguyên lý thực thi truy vấn, phương pháp truy cập dữ liệu

từ máy chủ, thuật toán thực thi từng phép toán đại số quan hệ, phân tích

độ an toàn và đánh giá bằng thực nghiệm Giải pháp đề xuất có thể ngăn chặn máy chủ thực hiện tấn công dạng thống kê tần suất thực hiện truy vấn (statistical attacks) làm vi phạm tính riêng tư người dùng ([CT1], [CT2])

• Bảo vệ tính riêng tư dữ liệu – Cơ chế quản lý truy cập mức cột:

- Đề xuất cơ chế quản lý truy cập mức cột trên cơ sở kết hợp ba thành phần: thuật toán mã hóa dữ liệu dựa trên lý thuyết Số dư Trung Hoa (CRT - Chinese Remainder Theorem), cấu trúc nhị phân binary trie được dùng làm cấu trúc quản lý khóa và hàm một chiều để suy dẫn khóa Kết quả này được trình bày trong công trình ([CT7], [CT4])

- Cải tiến cơ chế quản lý truy cập mức cột đã đề xuất nhằm nâng cao hiệu quả quản lý truy cập, kết quả được trình bày trong công trình [CT3]

• Đối với bài toán xác thực và ghi nhật ký hệ thống:

- Đề xuất cơ chế xác thực lẫn nhau giữa người dùng và máy chủ Dùng

cơ chế này, máy chủ có thể nhận biết người dùng đang đăng nhập vào

hệ thống là một người dùng hợp lệ hay không nhưng máy chủ không biết người dùng đó là ai Điều này giúp đảm bảo tính riêng tư người dùng (user privacy) Ngoài ra, cơ chế xác thực này có thể chống nghe lén, ngăn chặn các tấn công theo kiểu lặp lại (replay attacks), và tấn công kiểu cướp quyền điều khiển (hijacking attacks) Kết quả này được

trình bày trong công trình [CT5]

- Đề nghị nghi thức ghi nhật ký và tìm kiếm trên dữ liệu nhật lý (để phục

vụ giải trình khi cần thiết) dùng cho ODBS đảm bảo tính bí mật dữ liệu

và tính riêng tư người dùng [CT6]

Bố cục luận án

Luận án được trình bày theo thứ tự như sau:

• Phần Giới thiệu trình bày tổng quan về dịch vụ ODBS, các mô hình của dịch

vụ ODBS, định nghĩa các thực thể tham gia vào dịch vụ, các bài toán bảo mật liên quan, mục tiêu nghiên cứu của luận án, những đóng góp của luận án

và cấu trúc trình bày của luận án

• Chương 1 Hiện trạng vấn đề bảo mật và bảo vệ tính riêng tư trong ODBS trình bày hiện trạng bốn bài toán bảo mật mà luận án quan tâm về

phương diện nghiên cứu lẫn ứng dụng thực tế, và nhận xét chung về hiện

trạng

• Chương 2 Bảo vệ tính riêng tư người dùng trình bày phương pháp thực thi

truy vấn bảo vệ tính riêng tư người dùng, gồm có nguyên lý chung và thuật toán thực thi các phép toán đại số quan hệ trên CSDL lưu ở máy chủ; phần cài đặt thực nghiệm nhằm đánh giá khả năng ứng dụng thực tế của phương pháp đề xuất

• Chương 3 Bảo vệ tính riêng tư dữ liệu - Cơ chế quản lý truy cập mức cột

trình bày tổng quan về bài toán quản lý truy cập trong ODBS, các tiêu chí đánh giá một giải pháp quản lý truy cập (các tiêu chí này được tổng hợp được từ các công trình liên quan); trình bày chi tiết cơ chế quản lý truy cập mức cột đề xuất và các cải tiến nhằm tạo thuận lợi cho DO và người dùng trong hệ thống ODBS

• Chương 4 Xác thực và ghi nhật ký hệ thống trong ODBS trình bày tổng

quan về bài toán xác thực và bài toán ghi nhật ký hệ thống trong ODBS, các

yêu cầu của từng bài toán, các dạng tấn công có thể xảy ra Với bài toán xác

thực, luận án trình bày chi tiết phương pháp xác thực lẫn nhau giữa máy chủ

và người dùng mà không để lộ thông tin đăng nhập của người dùng; phương pháp xác thực này có thể loại trừ những tấn công thường gặp đối với một cơ

chế xác thực Với bài toán ghi nhật ký hệ thống trong ODBS, luận án trình

bày nghi thức ghi nhật ký hệ thống và tìm kiếm trên dữ liệu nhật ký (phục vụ giải trình khi cần thiết) không vi phạm tính bí mật dữ liệu và tính riêng tư người dùng

• Phần Kết luận và hướng phát triển trình bày các kết quả mà luận án đạt

được, sự kết hợp vận dụng các kết quả này trong một hệ thống ODBS và các hướng nghiên cứu tiếp theo của luận án

CHƯƠNG 1 HIỆN TRẠNG VẤN ĐỀ BẢO MẬT VÀ BẢO VỆ

TÍNH RIÊNG TƯ TRONG ODBS

Tóm tắt chương

Nội dung chương 1 trình bày hiện trạng các vấn đề bảo mật và bảo vệ tính riêng

tư trong ODBS mà luận án quan tâm xét về phương diện nghiên cứu lẫn ứng dụng thực tế Cuối chương 1 là nhận xét chung về hiện trạng

1.1 Hiện trạng nghiên cứu

Chúng tôi lần lượt xem xét kết quả nghiên cứu liên quan từng bài toán bảo mật

đã chọn

1.1.1 Bảo vệ tính riêng tư người dùng

Như đã đề cập, câu truy vấn mà một người dùng gửi đến máy chủ và kết quả trả

về tạo nên những đặc điểm riêng tư của người dùng đó Để bảo vệ tính riêng tư cho người dùng, cần đảm bảo không có một chủ thể nào khác (ngoài người dùng) có thể biết câu truy vấn và kết quả truy vấn liên quan đến người dùng, ngay cả máy chủ thực thi truy vấn

Trong CSDL truyền thống, vấn đề bảo vệ tính riêng tư người dùng không được

đặt ra vì môi trường người dùng truy cập dữ liệu được xem là tin cậy - máy chủ tin cậy và việc truy xuất dữ liệu thông qua hệ thống mạng cục bộ cũng được xem là tin cậy

Bài toán bảo vệ tính riêng tư người dùng có cùng mục tiêu với bài toàn tìm kiếm thông tin đảm bảo tính riêng tư (PIR – Private Information Retrieval) [11] Các giải pháp cho PIR đòi hỏi chi phí đường truyền cao hoặc phải nhân bản CSDL trên những máy chủ không thông đồng Hơn nữa, các giải pháp này được xây dựng cho

dữ liệu nhị phân nên rất khó áp dụng cho CSDL quan hệ

Trong ODBS, Lin và Candan đề nghị phương pháp thực thi truy vấn bảo vệ tính

bí mật dữ liệu và tính riêng tư người dùng trên CSDL có cấu trúc cây, như dữ liệu XML hay cây chỉ mục [33] Dữ liệu được mã hóa theo từng nút của cây trước khi gửi đến máy chủ Bên cạnh nội dung dữ liệu, cấu trúc dữ liệu cũng được bảo vệ Câu truy vấn trên dữ liệu cấu trúc cây cho biết cấu trúc của dữ liệu Một câu truy vấn (thể hiện bởi một ngôn ngữ truy vấn, ví dụ như XQuery) được xử lý bằng cách phân rã thành nhiều lần truy vấn, lần lượt mỗi lần truy vấn một nút trên cây Tuy nhiên, do chỉ truy vấn mỗi lần một nút nên để tránh khả năng để lộ thông tin về nút cần tìm và cấu trúc cây, tác giả dùng kỹ thuật truy cập thừa (access redundancy) kết hợp với kỹ thuật hoán đổi vị trí nút (node swapping) Với kỹ thuật truy cập thừa, mỗi lần truy cập dữ liệu trên cây, phải luôn truy cập m nút, m nguyên dương và m >

1 Để loại trừ khả năng kẻ tấn công tìm tập giao của những tập thừa m nút làm lộ thông tin về nút đích được kiếm nhiều lần, kỹ thuật hoán đổi vị trí nút sẽ chuyển vị trí nút cần tìm với một nút rỗng hiện diện trong (m - 1) nút còn lại Giải pháp này mang những đặc trưng của dữ liệu cấu trúc cây nên không thể dùng cho bài toán đặt

đề xuất cho mục tiêu bảo vệ tính bí mật dữ liệu, có chung đặc điểm là máy chủ trả

về kết quả truy vấn là đầy đủ, tức là không cần phải xử lý thêm để loại bỏ những dòng thừa Tuy nhiên, OPES chỉ có thể áp dụng trên các trường kiểu số, cho câu truy vấn loại truy vấn chính xác (exact match queries) hoặc truy vấn miền (range queries) PH cho phép thực thi trực tiếp các phép toán số học (+, -, ×, /) trên dữ liệu

ở dạng mã hóa, nhưng lại không quan tâm đến các toán tử so sánh Hai mô hình này đều gặp phải hạn chế về loại câu truy vấn mà mô hình có thể đáp ứng, nên không

thể áp dụng cho ODBS vốn cần một phương pháp xử lý truy vấn có thể đáp ứng cho truy vấn liên quan đến mọi vị từ

Trên CSDL quan hệ, Hacigümüs và cộng sự đề nghị phương pháp mã hóa dữ liệu và xử lý truy vấn trên CSDL ở dạng mã hóa [26] Tác giả đề nghị cách thức mã hóa dữ liệu và cách tạo chỉ mục phục vụ xử lý truy vấn liên quan các trường kiểu số (numeric field) Trên cùng loại mô hình dữ liệu, sử dụng cùng cách chuyển đổi lược

đồ và phương thức lưu trữ dữ liệu, Zheng-Fei và cộng sự đề xuất phương pháp tạo chỉ mục cho trường dữ liệu kiểu chuỗi và phương pháp thực thi truy vấn liên quan đến trường dữ liệu kiểu chuỗi với các toán tử như LIKE, NOT LIKE [50] Với mục đích giấu câu truy vấn và kết quả truy vấn, câu truy vấn của người dùng sẽ được chuyển đổi sang một dạng thức tương ứng để thực thi trên CSDL dạng mã hóa; máy chủ thực thi truy vấn và trả về kết quả cho máy khách (mà người dùng đang sử dụng) ở dạng mã hóa Tuy nhiên, do quá trình chuyển đổi câu truy vấn dựa trên một

số nguyên tắc không đổi, máy chủ có thể nhận biết loại câu truy vấn (ví dụ Q thực hiện phép chọn hay phép kết) và thực hiện tấn công kiểu thống kê tần suất thực hiện truy vấn Bằng cách kết hợp thông tin đã biết với những câu truy vấn được thực hiện với tần suất cao, máy chủ có thể biết được ngữ nghĩa câu truy vấn mà người dùng thực hiện, hoặc nhận ra xu hướng truy cập thông tin và khai thác tri thức trên

dữ liệu đang lưu trữ Điều này làm vi phạm tính bí mật dữ liệu và tính riêng tư người dùng [43]

Năm 2012, Popa và cộng sự đề xuất mô hình mã hóa và phương pháp thực thi truy vấn trên CSDL dạng mã, với sự tham gia của một máy chủ trung gian tin cậy (trusted proxy) làm nhiệm vụ mã hóa dữ liệu, chuyển đổi điều kiện truy vấn và giải

mã kết quả truy vấn [40] Tác giả đã cố gắng tăng hiệu quả thực thi truy vấn trên CSDL dạng mã nhưng đã để lộ thông tin về kiểu dữ liệu của từng trường, mối quan

hệ giữa các giá trị dữ liệu thuộc một trường của CSDL (bằng nhau, lớn hơn, nhỏ hơn) Điều này có thể dẫn đến việc vi phạm tính bí mật dữ liệu Ngoài ra, cũng như các giải pháp đã đề cập ở trên, giải pháp của Popa và cộng sự cũng sử dụng cách chuyển đổi điều kiện truy vấn cố định tạo điều kiện cho máy chủ tấn công thống kê

tần suất thực hiện truy vấn để đoán biết ngữ nghĩa câu truy vấn làm vi phạm tính riêng tư người dùng

1.1.2 Bảo vệ tính riêng tư dữ liệu – Cơ chế quản lý truy cập

DO bảo vệ tính riêng tư dữ liệu bằng cách sử dụng một cơ chế quản lý truy cập, đảm bảo mỗi đơn vị dữ liệu có thể và chỉ được truy cập bởi những người dùng mà

DO cho phép truy cập Để gán quyền truy cập CSDL, DO sử dụng một ma trận quyền truy xuất A A là ma trận nhị phân có số dòng là số người dùng trong hệ thống và số cột là số tài nguyên trên đó DO cần quản lý quyền truy cập Tùy vào đơn vị dữ liệu trên đó DO muốn quản lý truy cập (dòng, cột) mà các cột của ma trận quyền truy xuất sẽ được thể hiện tương ứng A[u, r] = 1 nếu người dùng u được quyền truy cập trên r; ngược lại A[u, r] = 0 Cột thứ i, ký hiệu là ACLi (Access Control List), là vector cột cho biết những chủ thể nào được phép đọc tài nguyên ri Đôi khi ACLi được dùng để chỉ tập hợp những người dùng có quyền truy cập tài nguyên ri Cũng vậy, dòng thứ j, ký hiệu là CAPj (Capability) là vector dòng biểu diễn tập hợp các tài nguyên mà người dùng uj được phép truy cập [13]

Bảng 1.1 Ma trận quyền truy xuất

Ví dụ, xét ma trận quyền truy xuất ở Bảng 1.1, ACL1 có giá trị là [0111] hay ACL1 = {u2, u3, u4}, nghĩa là chỉ những người dùng u2, u3, u4 được phép truy cập r1; CAP2 có giá trị là [11011] hay CAP2 = {r1, r2, r4, r5}, nghĩa là người dùng u2 được phép truy xuất các tài nguyên r1, r2, r4, r5

Giải pháp tầm thường cho bài toán quản lý truy cập đặt ra là DO can thiệp vào từng phiên truy cập dữ liệu, nhằm loại bỏ phần dữ liệu mà người dùng hiện tại không được phép truy cập, chỉ giữ lại phần dữ liệu mà họ được phép truy cập Giải

pháp này không phù hợp với ODBS vì DO phải xử lý quá nhiều việc, đó là chưa kể đến tính khả thi của giải pháp vì tình trạng cổ chai tại DO

Mã hóa là giải pháp phổ biến nhất cho bài toán bảo vệ tính bí mật dữ liệu nhằm giấu nội dung dữ liệu khỏi những truy cập bất hợp pháp, chẳng hạn như từ người quản trị CSDL tại SP, máy chủ, hay những chủ thể không có quyền khác Nếu trong CSDL truyền thống, mã hóa và quản lý truy cập là hai kỹ thuật nên vận dụng độc lập thì trong ODBS, quản lý truy cập được thực hiện trong khi mã hóa CSDL [13] Khi đó, tính bí mật và tính riêng tư của dữ liệu cùng được đảm bảo

Như vậy, trong ODBS, bài toán đảm bảo tính riêng tư dữ liệu được giải quyết cùng với bài toán bảo vệ tính bí mật dữ liệu Để làm điều đó, cần một giải pháp giúp

DO xác định số khóa phù hợp cho việc mã hóa CSDL sao cho sau khi phân phối khóa, mỗi người dùng trong hệ thống chỉ được truy cập phần dữ liệu mà họ được

Để làm rõ vấn đề, trước tiên, ta xem xét giải pháp đơn giản nhất, gọi là giải pháp ngây thơ, cho bài toán này Đó là DO mã mỗi dòng dữ liệu (như vậy đơn vị dữ liệu đang cần quản lý truy cập là dòng) với một khóa khác nhau và phân phối cho từng người dùng tập hợp các khóa ứng với quyền truy cập của người dùng đó Giải pháp này rõ ràng không hiệu quả vì DO phải sử dụng quá nhiều khóa và số lượng khóa mỗi người dùng phải giữ cũng rất nhiều

Bài toán quản lý truy cập trong ODBS lần đầu tiên được đặt ra bởi Damiani và cộng sự [13] Vấn đề này thu hút sự quan tâm của cộng đồng nghiên cứu ngay sau

đó ([2], [3], [18], [19], [51]) Theo đó, một phương pháp quản lý truy cập trong

ODBS được xem như là sự kết hợp của 3 thành phần: một phương pháp tổ chức dữ liệu, một cấu trúc quản lý khóa và một phương pháp suy dẫn khóa Phương pháp tổ

chức dữ liệu cho biết cách thức mã và giải mã dữ liệu Cấu trúc quản lý khóa giúp xây dựng mối quan hệ giữa các khóa dùng để mã (và giải mã dữ liệu) trong hệ thống nhằm làm giảm số lượng khóa cần sử dụng và phải quản lý Phương pháp suy dẫn khóa giúp người dùng có thể tính toán ra các khóa cần thiết từ một số ít (một hoặc vài khóa) các khóa mà người dùng phải giữ

Phần lớn các phương pháp quản lý truy cập thường chọn đơn vị dữ liệu để mã là dòng, dựa vào mối quan hệ bán phần (partial order) giữa các tập hợp người dùng có quyền truy cập khác nhau, hình thành nên cấu trúc phân cấp người dùng, gọi là UH (user hierarchy) [13]

Cho tập hợp người dùng U, cấu trúc UH tương ứng được định nghĩa bởi (P(U),

p ) trong đó P(U) chứa tất cả những tập hợp con của U và p là một quan hệ bán

phần trên P(U) sao cho ∀X, Y ∈P(U), X p Y nếu và chỉ nếu Y ⊆ X

Với ma trận quyền truy cập ở Bảng 1.1 thì cấu trúc UH như Hình 1.1

Hình 1.1 Cấu trúc phân cấp người dùng [13]

DO căn cứ vào cấu trúc phân cấp này để xác định số lượng khóa cần dùng cho việc mã hóa dữ liệu và tập khóa mà mỗi nhóm người dùng cần giữ để truy cập dữ liệu theo quyền được cấp Khóa ki ứng với nút ni, có nhãn là name(n i ), trên cấu trúc

phân cấp được suy dẫn từ khóa kj ứng với nút cha duy nhất của nút ni dùng hàm một chiều f [42]: ki = fname(ni ) (kj) Khóa của nút gốc được chọn ngẫu nhiên

Trong Hình 1.1, DO cần dùng 5 khóa để mã dữ liệu: k2 để mã r5, k24 để mã r4,

k234 để mã r1, k134 để mã r3, k1234 để mã r2 Người dùng u2 có thể truy cập các tài nguyên r1, r2, r4, r5 cần có các khóa tương ứng là k234, k1234, k24 và k2 Nhưng u2 chỉ cần giữ khóa k2 là có thể suy dẫn ra các khóa còn lại theo đường dẫn thể hiện mối quan hệ phân cấp trên cây

Cấu trúc UH được sử dụng làm cấu trúc quản lý khóa trong các công trình ([2], [13], [18]) Nhờ cấu trúc phân cấp này mà số lượng khóa DO phải dùng (và vì thế,

số lượng khóa cần thiết mà mỗi người dùng phải giữ) ít hơn so với giải pháp ngây thơ Khi dùng giải pháp của Damiani và cộng sự [13], nếu gọi số lượng khóa mỗi người dùng ui phải giữ là Ki, thì Ki ≥ 1, ∀i Quá trình suy dẫn được thực hiện bởi hàm một chiều để người dùng sở hữu khóa ở nút cấp dưới của cây không thể suy ngược khóa ứng với nút cấp trên

Zych và cộng sự cũng dựa vào cấu trúc UH để quản lý khóa, cấu trúc này được xây dựng từ dưới lên (bottom-up); Diffie-Hellman là thuật toán được dùng để sinh khóa [51] Khi sử dụng giải pháp đề nghị, mỗi người dùng chỉ cần giữ một khóa duy nhất là có thể suy dẫn các khóa cần thiết (Ki = 1) Tuy nhiên, thuật toán xây dựng cấu trúc quản lý khóa và thuật toán sinh khóa phức tạp và đòi hỏi chi phí cao Các cách tiếp cận dựa trên cấu trúc UH có chi phí xây dựng cấu trúc cao (2G,

|G| là số nhóm người dùng) và hiệu quả quản lý khóa thấp vì các nút của cấu trúc này phụ thuộc hoàn toàn vào các tập người dùng có quyền khác nhau trong hệ thống (là danh sách các ACL khác nhau) Trong trường hợp CSDL động, với sự thay đổi thường xuyên về tài nguyên, người dùng hoặc quyền truy cập, thì danh sách các ACL lập tức thay đổi theo làm cho cấu trúc quản lý khóa cũng thay đổi Khi đó, DO phải thường xuyên xây dựng lại cấu trúc

El-khoury và cộng sự dùng cấu trúc quản lý khóa là binary trie [19] Cấu trúc này chặt chẽ và dễ xây dựng hơn so với cấu trúc quản lý khóa UH đã đề cập Hơn nữa, trong trường hợp CSDL động, những thay đổi xảy ra không làm ảnh hưởng đến toàn bộ cấu trúc mà chỉ cần một số thao tác cập nhật tương ứng trên binary trie

là phản ánh được sự thay đổi

Tất cả các phương pháp quản lý truy cập đã đề cập ở trên, do mã dữ liệu theo đơn vị là dòng nên chỉ cho phép quản lý truy cập ở mức dòng Sử dụng các phương pháp này, DO không thể giới hạn quyền truy cập trên một số trường nhạy cảm trong một quan hệ, hoặc nếu muốn, DO phải phân rã các quan hệ thành những quan hệ con nhằm tách biệt phần dữ liệu có thể chia sẻ toàn bộ và phần dữ liệu không thể chia sẻ Việc phân rã quan hệ để phục vụ cho mục đích quản lý truy cập là không hợp lý vì gây tốn kém cho việc quản lý CSDL và xử lý truy vấn Nếu vận dụng các phương pháp đã đề cập nhưng chọn đơn vị dữ liệu mã hóa là cột thì sau khi mã, mỗi dòng dữ liệu gồm có nhiều từ mã ứng với mỗi trường của CSDL Khi đó hệ thống

tử thì mỗi giá trị của dòng cần một chữ ký điện tử tương ứng

Vì những hạn chế trên, chúng tôi quan tâm đến việc đề xuất cơ chế quản lý truy cập mức cột dùng cho ODBS

1.1.3 Xác thực trong ODBS

Xác thực giữ vai trò quan trọng trong hệ thống quản lý dữ liệu theo kiểu truyền thống lẫn trong ODBS Đây là bước kiểm tra tính hợp lệ của các đối tượng tham gia thực hiện giao dịch Không có nghi thức xác thực, máy chủ sẽ phải xử lý mọi nhu cầu truy vấn gửi đến vì máy chủ không thể nhận ra một nhu cầu truy vấn gửi từ một người dùng đã đăng ký sử dụng dịch vụ trước đó hay chưa

Như đã đề cập ở phần giới thiệu, trong nhiều ứng dụng thực tế, thông tin đăng nhập của người dùng tiết lộ danh tính của người dùng đó Để đảm bảo tính riêng tư

của người dùng, cơ chế xác thực dùng cho ODBS cần phải bảo vệ thông tin đăng nhập của người dùng đối với máy chủ

Để ngăn chặn những truy cập dữ liệu bất hợp pháp, các giải pháp hiện có phục

vụ cho ODBS chủ yếu tập trung vào bài toán mã hóa dữ liệu kết hợp với quản lý truy cập trên dữ liệu ([2], [3], [13], [18], [19], [26], [51]) Hiện tại đã có nhiều cơ chế xác thực nhưng do không được xây dựng đặc thù cho ODBS nên yêu cầu về tính riêng tư người dùng không được thỏa mãn ([8], [12], [22], [38], [39]) Giao thức SSL (Secure Socket Layer), được phát triển bởi Netscape [22], được sử dụng rộng rãi trên World Wide Web nhằm xác thực và mã hóa dữ liệu trên đường truyền giữa máy khách và máy chủ phục vụ cho các giao dịch điện tử liên quan đến thông tin bí mật như: dữ liệu thẻ tín dụng, mật khẩu, số bí mật cá nhân, … Giao thức SSL

là một quá trình xác thực lẫn nhau giữa ứng dụng khách và ứng dụng chủ; trong đó quá trình xác thực ứng dụng chủ được thực hiện nhờ vào chứng chỉ điện tử (digital certificate) do một cơ quan thẩm quyền (certificate authority) xác nhận Giao thức SSL hoạt động trên cơ sở các bên đều biết chính xác định danh của chủ thể mà họ đang tạo kết nối đến Chính vì điều này, giao thức SSL không thể dùng để xác thực trong ODBS

Kerberos là một giao thức xác thực được phát triển bởi MIT (Học viện Kỹ thuật Massachusetts) cho phép các bên tham gia giao dịch xác thực lẫn nhau nhờ sự tham gia của một máy chủ xác thực [12] PKI (Public Key Infrastructure) cũng là một giao thức xác thực lẫn nhau với sự tham gia của bên thứ ba (thường là cơ quan cung cấp chứng chỉ điện tử) làm nhiệm vụ cung cấp và xác thực định danh của các bên tham gia vào quá trình trao đổi thông tin, giúp cho các giao dịch điện tử diễn ra đảm bảo tính bí mật, toàn vẹn [8] Cũng vậy, giao thức Kerberos và PKI đều không đặt

ra mục tiêu giấu thông tin riêng tư của người dùng trong quá trình xác thực Các giao thức chứng thực khác như chứng thực dựa trên mật khẩu (password-based authentication), chứng thực dựa trên máy chủ (host based authentication) thường là những chọn lựa trong các hệ thống nhỏ triển khai trên nền mạng cục bộ; đó là những nghi thức xác thực một chiều, tên đăng nhập của người dùng được gửi đến

máy chủ ở dạng tường minh Bảo vệ thông tin riêng tư của người dùng là một yêu cầu quan trọng trong ODBS; các giao thức xác thực hiện có không đáp ứng được yêu cầu này nên không thể áp dụng cho ODBS Bài toán xác thực đặc thù cho ODBS hiện tại chưa được cộng đồng nghiên cứu quan tâm giải quyết

1.1.4 Ghi nhật ký hệ thống

Mike Burmester và cộng sự nêu ra bài toán ghi nhật ký trong ODBS với các yêu cầu gần như trái ngược nhau, đó là vừa đạt được mục đích có thể giải trình về các hoạt động diễn ra trong hệ thống, vừa đảm bảo tính bí mật dữ liệu và tính riêng tư người dùng [7] Hiện tại có nhiều công trình phục vụ cho việc lưu dữ liệu (tài liệu dạng tập tin, thư điện tử) ở máy chủ không tin cậy và cho phép máy chủ tìm kiếm thông tin theo từ khóa (keyword) nhưng không làm vi phạm tính bí mật dữ liệu và tính riêng tư người dùng ([5], [9], [23], [44], [46]) Các công trình này thuộc hai nhóm chính: (1) Đề xuất mô hình mã hóa để A lưu dữ liệu trên máy chủ S, A có thể yêu cầu S tìm kiếm trên dữ liệu mà tính bí mật của dữ liệu luôn được đảm bảo (S không biết A lưu dữ liệu gì và tìm kiếm điều gì) ([9], [23], [44]) (2) A gửi dữ liệu (ví dụ email) cho B thông qua S, A muốn nội dung dữ liệu phải được giữ bí mật đối với S trong khi B thì có thể truy cập trên dữ liệu [5] Đặc biệt, Golle và cộng sự đề nghị mô hình mã hóa phục vụ tìm kiếm cho phép tìm tài liệu chứa đồng thời nhiều

từ khóa (conjunctive keyword search) [23] Waters và cộng sự đề nghị giải pháp để nhiều máy chủ gửi các dòng nhật ký đến cùng một máy chủ của SP và cho phép tìm kiếm trên dữ liệu nhật ký chung [46] Tác giả dựa trên mô hình mã hóa phục vụ tìm kiếm dùng khóa đối xứng hoặc khóa bất đối xứng Các công trình hiện có không phục vụ được cho bài toán ghi nhật ký trong ODBS vì sự khác nhau về vai trò các loại thực thể trong hệ thống Bài toán ghi nhật ký hệ thống trong ODBS chưa được cộng đồng nghiên cứu quan tâm

1.2 Vấn đề bảo mật và bảo vệ tính riêng tư qua các ứng dụng thực tế của ODBS

Để xem xét hiện trạng các vấn đề bảo mật và riêng tư trong ODBS, chúng tôi xem xét các vấn đề bảo mật mà luận án quan tâm trong hai hệ thống quản lý dữ liệu

y tế được nhiều người biết đến là Google Health (của nhà cung cấp Google) và Health Vault (của nhà cung cấp Microsoft Corp.):

Theo Westin [47], tính riêng tư được định nghĩa là “… quyền của cá nhân hoặc

tổ chức tự quyết định khi nào, bằng cách nào và gồm những gì khi chia sẻ thông tin

về họ” Định nghĩa trên về tính riêng tư, thể hiện thông qua quyền tự quyết định về

việc chia sẻ thông cá nhân liên quan đến chủ thể, là nền tảng cho những luật bảo vệ

dữ liệu riêng tư như: luật bảo vệ dữ liệu y tế của Mỹ - HIPAA (U.S Health Insurance Portability and Accountability) [28], luật bảo vệ dữ liệu của châu Âu (European Data Protection Direction 95/46/EC) [21] và của Nhật (Data Protection Act of Japan) [30] Dựa trên định nghĩa về tính riêng tư và những luật bảo vệ riêng

tư đã đề cập, cùng với việc tham khảo nguyên tắc hoạt động của một hệ thống ODBS phục vụ y tế [25], các yêu cầu về bảo mật cần phải có đối với một hệ thống ODBS gồm:

• Yêu cầu thứ nhất: DO phải có thể kiểm soát được dòng thông tin (flow of information) liên quan đến họ Yêu cầu này rất quan trọng trong những hệ

thống ODBS nhằm bảo vệ tính bí mật và riêng tư, như đã định nghĩa ở trên, cho dữ liệu của DO Trong các hệ thống như Google Health và Microsoft Health Vault, bệnh nhân giữ vai trò là DO Do DO không đủ cơ sở để tin tưởng SP, điều này dẫn đến sự cần thiết của yêu cầu thứ hai

• Yêu cầu thứ hai: SP không thể yêu cầu DO phải tin tưởng họ trong cách thức quản lý dữ liệu của SP SP không thể yêu cầu DO tin vào họ nếu DO sử dụng

dịch vụ do SP cung cấp, cho dù có thông qua một số luật do SP phổ biến Tuy nhiên DO phải tin tưởng những người làm việc trực tiếp với dữ liệu; ví

dụ, trong một hệ thống quản lý dữ liệu y tế, bác sĩ là người làm việc trực tiếp

với dữ liệu y tế liên quan đến bệnh mà bác sĩ đang điều trị cho bệnh nhân (giữ vai trò DO) Việc truy cập đến toàn bộ dữ liệu của DO không phải luôn luôn cần thiết Những mục đích sử dụng, tiết lộ, hay yêu cầu về dữ liệu riêng

tư chỉ nên ở mức độ tối thiểu Điều này dẫn đến yêu cầu thứ ba

• Yêu cầu thứ ba: DO phải có thể kiểm soát việc truy cập dữ liệu của họ đến mức tinh nhất có thể Ngoài ra, việc kết hợp thông tin từ những nhu cầu truy

vấn dữ liệu người dùng (gồm cả DO) có thể hình thành nên đặc điểm riêng tư của họ Chính vì vậy, ta cần có yêu cầu thứ tư

• Yêu cầu thứ tư: Không thể dựa vào quá trình khai thác dữ liệu của người dùng để thiết lập nên hồ sơ người dùng (user profile) Cho dù những cơ chế

bảo mật được sử dụng, nếu người dùng không thể xác minh những cơ chế này đã hoạt động đúng đắn thì việc sử dụng các cơ chế này là vô nghĩa Cho nên, ta cần có yêu cầu thứ năm

• Yêu cầu thứ năm: Người dùng phải có thể xác minh rằng kết quả truy vấn do máy chủ thực hiện là đáng tin cậy

Năm yêu cầu trên là những yêu cầu tối thiểu về bảo mật đối với một hệ thống ODBS Hai nhà cung cấp là Google và Microsoft Corp yêu cầu người sử dụng tin tưởng họ khi sử dụng các dịch vụ như Google Health hay Microsoft Health Vault ([24], [34]) Người sử dụng dịch vụ không thể kiểm soát rằng SP có thật sự tuân thủ các điều luật về việc bảo vệ tính riêng tư và chia sẻ thông tin riêng tư hay không

Qua đó, ta thấy rằng Google và Microsoft Corp không tuân thủ yêu cầu thứ nhất và

thứ hai, nên cũng không tuân thủ ba yêu cầu còn lại trong năm yêu cầu đã trình bày

ở trên

Giải pháp cho các bài toán bảo mật áp dụng trong một hệ thống ODBS phải đáp ứng được ít nhất là năm yêu cầu về bảo mật kể trên Yêu cầu thứ năm, do giải pháp của bài toán xác thực kết quả truy vấn đảm nhiệm, không thuộc phạm vi nghiên cứu của luận án Các yêu cầu thứ nhất, thứ hai, và thứ ba phải được đáp ứng bởi giải pháp của hai bài toán gồm: bảo vệ tính bí mật dữ liệu và bảo vệ tính riêng tư dữ

liệu Bảo vệ tính riêng tư dữ liệu được thực hiện trên cơ sở tính bí mật dữ liệu cũng được đảm bảo; luận án quan tâm giải pháp cho bài toán bảo vệ tính riêng tư dữ liệu

nhưng cũng đáp ứng yêu cầu về tính bí mật dữ liệu Vì vậy, giải pháp cho bài toán

bảo vệ tính riêng tư dữ liệu mà luận án đề nghị sẽ đáp ứng yêu cầu thứ nhất, thứ hai và thứ ba Yêu cầu thứ tư được luận án đáp ứng bởi giải pháp của bài toán bảo

vệ tính riêng tư người dùng Hai bài toán còn lại mà luận án quan tâm, gồm xác thực và ghi nhật ký hệ thống trong ODBS, góp phần làm cho hệ thống an toàn hơn

1.3 Kết luận

Chương 1 khảo sát hiện trạng bốn bài toán bảo mật mà luận án quan tâm về phương diện nghiên cứu lẫn ứng dụng thực tế Kết quả nghiên cứu cho thấy, tất cả các phương pháp thực thi truy vấn trên CSDL mã hóa hiện có chỉ có thể đảm bảo

tính bí mật dữ liệu mà không thể bảo vệ tính riêng tư người dùng Sử dụng các giải

pháp này, máy chủ có thể tấn công dạng thống kê tần suất thực hiện truy vấn để biết ngữ nghĩa câu truy vấn mà người dùng thực hiện làm vi phạm tính riêng tư người

dùng Với bài toán bảo vệ tính riêng tư dữ liệu, các cơ chế quản lý truy cập hiện có

hoạt động với chi phí cao, không thuận lợi cho mục đích giới hạn truy cập mức cột, không phù hợp trong trường hợp CSDL động, gây khó khăn cho DO và người dùng

trong hệ thống Với bài toán xác thực trong ODBS, các cơ chế xác thực hiện có

không thể đáp ứng cho yêu cầu bảo vệ thông tin riêng tư của người dùng chứa đựng

trong thông tin đăng nhập Bài toán ghi nhật ký hệ thống trong ODBS chưa được

cộng đồng nghiên cứu quan tâm Qua khảo sát ứng dụng quản lý dữ liệu y tế của hai nhà cung cấp được nhiều người biết đến là Google và Microsoft Corp., ta thấy rằng vấn đề về bảo mật và bảo vệ riêng tư chưa được quan tâm

CHƯƠNG 2 BẢO VỆ TÍNH RIÊNG TƯ NGƯỜI DÙNG

Tóm tắt chương

Hầu hết các phương pháp xử lý truy vấn hiện có trong ODBS đều chỉ quan tâm đến việc mã hóa và thực thi truy vấn trên CSDL mã hóa nhằm đảm bảo tính bí mật dữ liệu Vấn đề bảo vệ tính riêng tư người dùng giữ vai trò quan trọng trong ODBS nhưng chưa được quan tâm Nội dung chương này bổ sung thêm yêu cầu đảm bảo tính riêng tư người dùng vào giải pháp thực thi truy vấn đảm bảo tính

bí mật dữ liệu trong ODBS Luận án đề xuất ba nguyên lý làm cơ sở để xây dựng giải pháp thực thi truy vấn trên CSDL (dạng mã) ở máy chủ thỏa mãn tính riêng

tư người dùng, và trình bày thuật toán thực thi các phép toán ĐSQH dựa trên các nguyên lý đã đề xuất Luận án phân tích độ an toàn của giải pháp đề nghị cùng với một số khuyến cáo về cách chọn giá trị cho các tham số dùng trong hệ thống để tính riêng tư người dùng được đảm bảo mà không ảnh hưởng nhiều đến hiệu năng làm việc của hệ thống Phần thực nghiệm khảo sát thời gian thực thi truy vấn nhằm đánh giá tính khả thi của giải pháp đề nghị

2.1 Giới thiệu bài toán bảo vệ tính riêng tư người dùng

Trong ODBS, máy chủ của SP ngoài việc lưu trữ và xử lý dữ liệu cho DO còn đảm nhiệm chức năng xử lý truy vấn cho người dùng Thông qua máy khách, người dùng gửi câu truy vấn đến máy chủ; máy chủ xử lý truy vấn trả kết quả về cho máy khách, người dùng nhận kết quả truy vấn từ máy khách (Hình 2.1)

Hình 2.1 Quá trình xử lý truy vấn tổng quát trong ODBS

Câu truy vấn và kết quả truy vấn chứa thông tin riêng tư của người dùng Ví dụ,

khi ta biết một người dùng u thường xuyên truy cập một loại thuốc nào đó, ta có thể đoán được bệnh của u Để bảo vệ tính riêng tư cho người dùng u, cần đảm bảo không có bất kỳ chủ thể nào khác ngoài u, kể cả máy chủ và DO, có thể biết câu truy vấn và kết quả truy vấn do u thực hiện trên CSDL Đây chính là nội dung chính

của bài toán đảm bảo tính riêng tư người dùng mà luận án sẽ xem xét trong chương này

Để xác định cụ thể bối cảnh bài toán, chúng tôi giả sử rằng kết quả truy vấn mà máy chủ trả về cho máy khách là đúng, đầy đủ dựa trên tình trạng mới nhất của CSDL Việc xác thực kết quả truy vấn (một trong các bài toán bảo mật mà chúng tôi

đã đề cập ở phần Giới thiệu) nằm ngoài phạm vi nghiên cứu của luận án Ngoài ra,

phương pháp thực thi truy vấn mà chúng tôi đề xuất sẽ sử dụng, và không cần bổ sung hay thay đổi, các tính năng của hệ quản trị CSDL quan hệ thương mại đang dùng tại máy khách lẫn máy chủ

2.2 Giải pháp thực thi truy vấn của Hacigümüs và cộng sự [26]

DO cần phải giấu nội dung dữ liệu trước khi gửi đến SP để bảo vệ tính bí mật dữ liệu Như đã đề cập ở phần 1.1.1, mã hóa là giải pháp được sử dụng phổ biến nhằm phục vụ mục đích bảo vệ tính bí mật dữ liệu ([1], [6], [26]) Máy chủ phải có thể thực thi câu truy vấn trên CSDL ở dạng mã hóa mà không cần giải mã dữ liệu Trên CSDL quan hệ, Hacigümüs và cộng sự đề nghị phương pháp thực thi truy vấn trên CSDL đã mã hóa dựa vào chỉ mục được lưu cùng với dữ liệu mã [26] Trong phần này, chúng ta sẽ tìm hiểu cách thức tổ chức dữ liệu và phương pháp thực thi truy vấn của giải pháp này

2.2.1 Tổ chức dữ liệu

Một quan hệ r với lược đồ quan hệ R(A1, A2, …, An), ký hiệu r(R) Ký hiệu R+

để chỉ tập tất cả các thuộc tính của quan hệ r(R): R+ = {A1, A2, …, An}

Ứng với mỗi quan hệ r, DO tạo một quan hệ rS có lược đồ quan hệ là:

RS(tS, A S, A S, …, A S)

Việc xây dựng quan hệ rS từ quan hệ r dựa trên các hàm sau đây:

Hàm phân hoạch (partition function)

Với mỗi thuộc tính kiểu số r.Ai, ta xác định miền giá trị dom(A i ) Hàm phân hoạch chia dom(A i ) thành các phân vùng không giao nhau:

partition(r.Ai) = {p1, p2, , pk}

Với một phân hoạch p, ký hiệu p.low và p.high để chỉ biên dưới và biên trên của

một phân hoạch Chẳng hạn, miền giá trị của thuộc tính MAKH là giá trị nguyên, thuộc [0, 1000]; ta chia miền giá trị này thành 5 phân hoạch có kích thước bằng nhau, khi đó:

partition(KH.MAKH) = {[0, 200], (200, 400], (400, 600], (600, 800], (800, 1000]}

1 Trong cài đặt thực tế, chỉ trên những thuộc tính nhạy cảm mới cần giấu nội dung dữ liệu Nếu dữ liệu trên thuộc tính A không nhạy cảm thì chỉ mục AS của A chính là A

Hàm định danh (identification function)

Hàm định danh được dùng để gán nhãn phân biệt cho các phân hoạch của một

thuộc tính Định danh của phân hoạch pj của thuộc tính Ai, ký hiệu là ident r.Ai (p j ) Ví

dụ, identKH.MAKH([0, 200]) = 2, identKH.MAKH((600, 800]) = 1

Khi hàm định danh áp dụng trên một thuộc tính (không có tham số phân hoạch),

ký hiệu là ident(r.A i ), thì kết quả trả về là định danh của tất cả các phân hoạch của

thuộc tính đó Ví dụ, ident.(KH.MAKH)= {2, 7, 5, 1, 4}

Hàm ánh xạ (mapping function)

Hàm ánh xạ chuyển một giá trị v của một thuộc tính Ai sang giá trị định danh của phân hoạch chứa v Hàm ánh xạ được dùng để tạo chỉ mục cho các thuộc tính

Mapr.Ai(v) = ident(pj) vớipj là phân hoạch có chứa giá trị v

Ví dụ, MapKH.MAKH(50) = 2, MapKH.MAKH(500) = 5

Hàm ánh xạ được gọi là bảo toàn thứ tự nếu với hai giá trị vk và vl trong miền giá trị của thuộc tính Ai, khi vk < vl thì Mapr.Ai(vk) ≤ Mapr.Ai(vl) Hàm ánh xạ được gọi là ngẫu nhiên nếu nó không bảo toàn thứ tự

Gọi S là tập hợp các giá trị thuộc miền giá trị của thuộc tính Ai, S ⊂ dom(Ai); v

là một giá trị cũng thuộc miền giá trị này Các hàm ánh xạ sau đây cũng được dùng

để chuyển đổi câu truy vấn sang dạng tương ứng để có thể thực thi trên CSDL (dạng mã) tại máy chủ:

(1) Mapr.Ai(S) = {identr.Ai(pj) | pj ∩ S ≠ ∅}: là tập hợp các định danh của các phân hoạch có ít nhất một giá trị chung với tập S

(2) Map>r.Ai(v) = {identr.Ai(pj) | pj.low ≥ v}: là tập hợp các định danh của các phân hoạch có chứa ít nhất một giá trị không nhỏ hơn v

(3) Map<r.Ai(v) = {identr.Ai(pj) | pj.high ≤ v}: là tập hợp các định danh của các phân hoạch có chứa ít nhất một giá trị không lớn hơn v

KH.MAKH

Bằng cách sử dụng những hàm được định nghĩa và những ký hiệu được quy ước

ở trên, tác giả đề nghị cách thức lưu trữ quan hệ dạng mã hóa rS (ứng với quan hệ r) trên máy chủ Với mỗi dòng dữ liệu t = (a1, a2, …, an) thuộc quan hệ r, có một dòng tương ứng trong rS, có dạng:

(encrypt(a1, a2, …, an), Mapr.A1(a1), Mapr.A2(a2), …, Mapr.An(an))

với encrypt là thuận toán mã hóa dữ liệu2, Mapr.Ai(ai) là giá trị chỉ mục ứng với mỗi giá trị ai, với giả sử rằng mỗi thuộc tính đều có tạo chỉ mục

Như vậy ký hiệu rS chỉ quan hệ dạng mã hóa của quan hệ r Hàm D dùng để giải

mã một quan hệ, D(rS) = r Hàm D có thể áp dụng trên một biểu thức đại số quan

hệ, sau này sẽ được viết tắt là ĐSQH, để giải mã những dòng dữ liệu trả về bởi biểu

thức ĐSQH đó Khi áp dụng hàm D lên một quan hệ có chứa thuộc tính là chỉ mục, thì những thuộc tính chỉ mục bị loại bỏ, D chỉ giải mã trường tS

Hình 2.2 Hình minh họa cách thức mã hóa dữ liệu [26]

2.2.2 Cách thức chuyển đổi điều kiện truy vấn

Phần này trình bày cách thức chuyển đổi một điều kiện truy vấn từ dạng rõ sang dạng tương ứng để có thể áp dụng trên CSDL dạng mã ở máy chủ Điều kiện truy

vấn C được chuyển đổi bởi hàm chuyển đổi điều kiện truy vấn, ký hiệu là

Mapcond(C), với tham số điều kiện C thuộc về một trong các trường hợp sau: