Luận văn Những vấn đề bảo mật khi truy vấn cơ sở dữ liệu XML động được OUTSOURCED

MỤC LỤC

 

ACKNOWLEDGEMENT. 4 

ABSTRACT. 5 

Chương 1 GIỚI THIỆU . 8 

1.1  Data Confidentiality . 12 

1.2  User Privacy và Data Privacy . 13 

1.3  Query Assurance . 17 

1.4  Nhận xét . 19 

Chương 2 CÁC NGHIÊN CỨU LIÊN QUAN . 22 

2.1  Khái niệm . 22 

2.2  Hướng tiếp cận dùng chữký điện tử. 23 

2.3  Hướng tiếp cận sửdụng cấu trúc dữliệu đặc biệt . 25 

2.4  Hướng tiếp cận Challenge – Response. . 28 

2.5  Hướng tiếp cận dựa vào đặc thù của bài toán . 30 

2.6  Bảo đảm truy vấn cho dữliệu dạng cây . 31 

2.7  Nhận xét . 33 

Chương 3 DỮLIỆU XML . 35 

3.1  Mô hình lưu trữ. 35 

3.2  Chỉmục cho tài liệu XML . 40 

Chương 4 ĐẢM BẢO TRUY VẤN . 42 

4.1  Phương pháp . 42 

4.2  Nested B+ Tree . 43 

4.3  Tác vụchọn . 45 

4.4  Các tác vụcập nhật dữliệu . 49 

Chương 5 PHÂN TÍCH . 51 

Chương 6 THỰC NGHIỆM . 58 

Chương 7 KẾT LUẬN . 63 

Chương 8 PHỤLỤC . 67 

8.1  Cấu trúc lưu trữXML . 67 

8.2  Giải thuật gán nhãn (labeling) . 67 

8.3  Chương trình thửnghiệm . 68 

8.4  Lược đồtài liệu mondial.xml . 71 

8.5  Kếhoạch thực thi truy vấn . 72 

8.6  Tóm lược các nghiên cứu liên quan . 73 

8.7  Bài báo liên quan . 83 

pdf93 trang | Chia sẻ: lethao | Lượt xem: 2048 | Lượt tải: 5download
Bạn đang xem trước 20 trang tài liệu Luận văn Những vấn đề bảo mật khi truy vấn cơ sở dữ liệu XML động được OUTSOURCED, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
, có thể sử dụng kết hợp các cấu trúc cây như sau. Xây dựng một cây B+-Tree với khóa so sánh là nameid, gọi là NameTree. Tại node lá của NameTree chứa gốc của hai cây B+Tree theo khóa lần lượt là (pnodeid, value) và (value). Hai cây này có tên là: ParentTree và ValueTree. Tập hợp ba loại cây này tạo thành một cấu trúc dữ liệu, gọi là Nested B+Tree, cho phép lập chỉ mục cho tài liệu XML trên hai bộ giá trị (nameid, pnodeid, value) và (nameid, value). N goài ra, việc phân bố của dữ liệu cũng ảnh hưởng một phần khá lớn đến cấu trúc cây. N ếu dữ liệu bị tập trung vào một vùng nhất định có thể làm quá trình tách node diễn ra thường xuyên, làm cho hiệu suất sử dụng của cây B+ không cao. Để hạn chế điều này, cây B+ đưa vào thao tác tái phân bố (redistribute) dữ liệu ở các node gốc. Trong cây N B+, ngoài đặc tính trên, các khóa (key) cũng được thực hiện tái phân bố trước khi thực hiện việc tách node hay hợp nhất (merge) node. Một hướng tiếp cận khác, là sử dụng một cấu trúc chỉ mục đa chiều (multi-dimension index) để tạo chỉ mục cho tài liệu XML dựa trên bộ bốn thuộc tính (nameid, prefixid, pnodeid, value) như họ cây R (R-Tree, R+Tree, R* Tree, X-Tree,…). Tuy nhiên, các Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 45/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh cấu trúc chỉ mục này không đảm bảo được thứ tự tăng dần của các record (hoặc chỉ đảm bảo cho một thuộc tính) vì vậy không phù hợp cho việc chứng minh completeness trong truy vấn. Nested Merkle B+ Tree Để N M+Tree có thể chứng minh kết quả truy vấn, cần nhúng kèm một số thông tin tương tự như cây Merkle Hash Tree (MHT) vào cây N B+Tree như sau: gọi H(node) là băm của một node bất kỳ thuộc N B+Tree, khi đó h(node) được tính như sau: - Node là node lá của ValueTree, ParentTree: H(node) = h(A(node)) - Node là node lá của NameTree: H(node)=h(H(R(ParentTree))||H(R(PrefixTree))) - Node là node nội : H(node)= h(∪I H(Childi(node))) , i = 1..số con của node. - Node là gốc của NameTree: H(node)= h(ε||∪I H(Childi(node))) , i = 1..số con của node. Trong đó: h là hàm băm bảo mật thỏa tính không đụng độ và không thể đảo trong thời gian tuyến tính (collusion-free and non-invertable) như SHA1, MD5. A(node) là t- node hoặc a-node liên kết với node lá này. R(tree) là node gốc của tree. Childi (node) là node con thứ i của node. ε là một giá trị duy nhất theo thời gian (timestamp), giá trị nào được cung cấp tới tất cả các client khi có sự thay đổi. Sau đó, thực hiện ký lên nội dung của R(PrefixTree) bằng giải thuật chữ ký số. N hư vậy, với việc áp dụng ý tưởng của MHT lên N B+Tree, ta được N MB+Tree (Nested Merkle B+ Tree), vừa dùng làm chỉ mục trong truy vấn vừa được dùng để chứng minh truy vấn trên toàn dữ liệu XML. Phần tiếp theo của tài liệu trình bày cách thức vận dụng N MB+Tree trong việc thực hiện truy vấn cũng như chứng minh kết quả trả về. 4.3 Tác vụ chọn Phép chọn (Selection) là câu truy vấn được xử dụng thường xuyên nhất. Đối với RDB, đó là phát biểu SELECT trong SQL. Trong XML, có nhiều ngôn ngữ được dùng truy Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 46/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh vấn như XPath, XQuery. Tài liệu này minh họa cho một vài dạng câu truy vấn XPath thông dụng. Xét một tài liệu XML có cấu trúc như sau: Hình 4.9. Cây cấu trúc của một tài liệu XML Các chỉ số đánh kế bên các node là nameid của node đó. Tài liệu sẽ khảo sát qua một số dạng truy vấn thường gặp. 4.3.1 Dạng truy vấn liên quan một node, điều kiện đơn Là dạng truy vấn đơn giản nhất, ví dụ /Customer/Order/Item[@name=”TV”]: tìm tất cả các hạng mục có tên là “TV”. Theo quy tắc gán tên, ta có định danh tên của thuộc tính name của node Item là 12. N hư vậy, để trả lời câu truy vấn này, thực hiện tìm trên N MB+Tree với khóa tìm kiếm (nameid=13, value=”TV”). Kết quả trả về các a-node Name_13 của Item_8. Từ các a-node, có thể dễ dàng xác định được các t-node Item_8 tương ứng. Sau đó, ta có thể lấy được các a-node khác (như price_14, qty_15). Tính đúng và Tính đầy đủ N goài các a-node Name thỏa điều kiện, server trả về thêm hai a-node biên của tập kết quả, và các băm của các node lân cận đủ để tính băm của node cha, đồng thời trả thêm giá trị băm của các node anh em của node cha. Các kết quả này giúp cho client có thể tính ngược lại được giá trị băm của nút gốc. Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 47/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh Tại nút gốc, từ giá trị băm tính được kết hợp với temp thời gian lưu trữ, client có thể kiểm tra với chữ ký của nút gốc. Do đặc tính một chiều, bất-khả-đảo của các hàm băm được áp dụng nên có thể chứng minh tính đúng (correctness). Do các record được sắp xếp theo thứ tự tăng dần theo bộ thuộc tính (nameid, value), kết hợp với hai record biên kèm theo, có thể chứng minh được tính đầy đủ (completeness) của dữ liệu. Tính mới Do trong băm của node gốc có chứa đựng giá trị temp thời gian ε (timestamp). N ếu data owner phổ biến giá trị ε này cho tất cả các client. Từ đó client có thể xác định được tính mới của dữ liệu. N hư vậy, chỉ sau một thao tác kiểm tra, client có thể kiểm tra đầy đủ cả ba vấn đề đặt ra của query assurance chi thông qua các phép băm với chi phí thấp hơn rất nhiều với các phép toán số nguyên lớn của các chữ ký số. Chứng minh không có record thỏa mãn (empty proof) Một phương diện khác cần được quan tâm là chứng minh kết quả trả về là trống, nghĩa là không có record nào thỏa điều kiện tìm kiếm. Để chứng minh, server trả về hai record nằm kế nhau trong dãy thứ tự có giá trị lớn và nhỏ hơn giá trị cần truy vấn. 4.3.2 Dạng liên quan nhiều node, điều kiện đơn Là dạng truy vấn tương đối phức tạp hơn liên quan đến nhiều node. Điều này tương đương với phép join query của RDB. Xét câu truy vấn : /Customer[@name=”Marry”]/Order/Item : trả về tất cả các hạng mục do khách hàng có tên là “Mary” đã mua. Tương tự như trên, xây dựng một VO để chứng minh cho truy vấn (nameid=4, prefixid=1, value=”Marry”). Tuy nhiên, VO này chỉ cần chứa các a-node Name_4 và các t-node Customer_1 tương ứng. Các a- node Name_4 được dùng để chứng minh t_node Customer_1 đầy đủ. Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 48/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh Ứng với mỗi t-node Customer_1 xây dựng một VO để đảm bảo query assurance của truy vấn (nameid=3, prefixid=1, pnodeid=) để lấy ra kết quả cho t-node Order_3. Tương tự, ta có thể đảm bảo cho kết quả truy vấn cho các node Item trả về. Tương tự cho câu truy vấn /Customer[@name=”Marry”]/Order/Item[@name= ”TV”] : lấy các hạng mục có tên là “TV” do khách hàng tên “Marry” đã mua. Phương pháp xử lý kết hợp giữa câu truy vấn trên và xử lý của trường hợp đầu tiên. 4.3.3 Các dạng khác Hai ví dụ trên là cách thức vận dụng cây N MB+ trong việc thực hiện truy vấn và chứng minh kết quả truy vấn. Để xử lý các câu truy vấn khác phức tạp hơn, ta có thể phân tách chúng thành những câu truy vấn đơn và từ đó xây dựng một kế hoạch thực thi (execution plan) với các bước thực hiện đơn. Ví dụ, ta có execution plan cho các câu truy vấn trên như sau. /Customer/Order/Item[@name=”TV”] STEP#1 IndexMethod : Vtree, nameID=13 Condition : equal to [TV] Result level : not included Retrieval : node only StepValue : PNODEID [For each matched items, perform] STEP#2 IndexMethod : DirectIDAccess, id=ParentStepValue Result level : 1 Retrieval : node and all its attributes /Customer[@name=”Marry”]/Order/Item STEP#1 IndexMethod : Vtree, nameID=4 Condition : equal to [Marry] Result level : not included Retrieval : node only StepValue : PNODEID [For each matched items, perform] STEP#2 IndexMethod : DirectIDAccess, value=ParentStepValue Result level : not included Retrieval : node only StepValue : ID [For each matched items, perform] STEP#3 IndexMethod : Ptree, nameID=3, pid=ParentStepValue Result level : not included Retrieval : node only StepValue : ID [For each matched items, perform] STEP#4 IndexMethod : Ptree, nameID=8, pid=ParentStepValue Result level : 1 Retrieval : node and all its attributes Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 49/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh 4.3.4 Hợp nhất các VO Trong việc thực thi một câu truy vấn, hầu hết các trường hợp, server cần trả về cho client nhiều hơn một VO. Ví dụ, trong trường hợp câu truy vấn mục 4.2.2, số lượng VO server cần trả về phục thuộc vào số lượng record Customer thỏa điều kiện @name=”Marry”. Điều này có thể dẫn đến sự quá tải ở phía Client trong việc kiểm tra các VO. Để hạn chế trường hợp trên, server cần phải thực hiện hợp nhất các VO này trở thành một VO duy nhất và gửi trả VO này về cho client. N hư vậy, client chỉ cần thực hiện kiểm tra một lần duy nhất để có thể xác định query assurance cho toàn bộ dữ liệu nhận được. Việc hợp nhất các VO có thể thực hiện được dễ dàng. Mỗi VO ban đầu được xác định bởi một đoạn các record liên tục nhau cùng với (tối đa) hai record biên. Với nhiều VO, ta sẽ có nhiều đoạn. Vì vậy, thay vì phát sinh co-path cho từng đoạn, ta có thể thực hiện phát sinh co-path cho toàn bộ các đoạn. 4.4 Các tác vụ cập nhật dữ liệu Các tác vụ cập nhật khi dữ liệu đã được outsourced đòi hỏi thêm một số chi phí nhất định. Trong trường hợp một bản sao của CSDL được lưu trữ ở data owner, số lượng các lần cập nhật xảy ra không thường xuyên (thời gian giữa hai lần cập nhật là đủ lớn) và số lượng cập nhật là nhiều, data owner có thể thực hiện cập nhật dữ liệu cục bộ. Sau đó thực hiện outsourced lại dữ liệu. Ở đây, tài liệu trình bày một phương thức để cập nhật dữ liệu trực tiếp được dùng trong trường hợp data owner không lưu trữ lại bản sao của dữ liệu outsourced hoặc chi phí cho mỗi lần outsource là khá lớn. 4.4.1 Tác vụ thêm mới (insertion) Data owner gửi các dữ liệu cần thêm mới (các xml element, attrbiute) đến server. Server thực hiện thêm các record mới vào CSDL, cập nhật lại cấu trúc index. Tính toán và cập nhật các giá trị băm của các node lá có liên quan và lan truyền lên đến node gốc của cây N MB+. Server gởi trả về cho data owner giá trị băm mới của node Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 50/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh gốc. Data owner phát sinh một giá trị timestamp mới, kết hợp với giá trị băm nhận được. Sau đó thực hiện ký lên các giá trị này. Data owner gửi lại cho server giá trị timestamp mới cùng với chữ ký mới. Server cập nhật giá trị timestamp và chữ ký vừa nhận được vào CSDL. Giao thức cập nhật nhiều giai đoạn như trên được minh họa như hình sau. Hình 4.10. Các bước thực hiện insert 4.4.2 Tác vụ xóa và cập nhật (deletion/updation) Tác vụ xóa/cập nhật dữ liệu cũng được thực hiện thông qua các bước tương tự như tác vụ thêm mới. Data owner gửi yêu cầu đến server. Server thực hiện việc cập nhật xuống CSDL đồng thời tính toán lại các giá trị băm của các node trong cây N MB+. Giá trị băm mới của node gốc được trả về cho data owner để thực hiện ký. Chữ ký cùng giá trị timestamp mới được gửi trả về cho server để cập nhật vào CSDL. Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 51/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh Chương 5 PHÂN TÍCH Chúng tôi đã trình bày giải pháp lưu trữ và sử dụng cây chỉ mục N MB+ để chứng minh truy vấn đối với dữ liệu XML được outsourced. Trong phần này, chúng tôi đề cập đến các khía cạnh bảo mật cũng như chi phí của giải pháp. Tất cả dữ liệu, kể cả các node của cây chỉ mục, trước khi lưu trữ đều được mã hóa bằng giải thuật mã hóa đối xứng (như Rijndael) nhằm đảm bảo tính bảo mật của dữ liệu cũng như hiệu suất khi thực hiện truy vấn. N hư vậy, phương pháp này thỏa mãn được yêu cầu data confidentiality. Giải pháp trên không đề cập đến tính riêng tư. Tuy nhiên, do đặc tính của dữ liệu dạng cây, nên hoàn toàn có thể áp dụng các kết quả của Lin và Candan [2] để có thể đạt được tính riêng tư. Đối với query assurance, tài liệu trình bày phương thức giải quyết đối với các câu truy vấn vùng và điểm của một điều kiện đơn. Đối với câu truy vấn vùng với nhiều điều kiện kết hợp, ta có thể giải quyết tương tự như cách thức xử lý các tác vụ tập hợp (set operations) bao gồm phép toán giao và hội như đã trình bày trong [10, 14, 21] - Phép Hội : được thực hiện đơn giản như hai câu truy vấn riêng biệt. Các VO phát sinh từ hai câu truy vấn sẽ được hợp nhất như đã trình bày. - Phép Giao : một giải pháp đơn giản, với các tập kết quả từ hai cây truy vấn con theo từng điều kiện, server chọn một tập kết quả nhỏ hơn, ứng với mỗi kết quả thuộc tập này không thỏa mãn tập kia, server trả về một empty proof. Tất cả các VO sau cùng sẽ được hợp nhất để thực hiện kiểm tra một lần ở phía client. Một điều cần quan tâm trong query assurance là chứng minh cho phép join. Trong dữ liệu dạng cây như XML, phép join được áp dụng chủ yếu cho quan hệ từ node cha Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 52/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh xuống node con. Đây là mối quan hệ phổ biến trong CSDL XML. Cây N MB+ sử dụng PTree để chứng minh truy vấn cho phép join này với chi phí thấp nhất trong việc xây dựng VO cũng như chi phí kiểm tra tại phía client. Giải pháp này không áp dụng trực tiếp cho các câu truy vấn có sử dụng các hàm tính toán bao gộp (aggregated function). Cho tới thời điểm hiện tại, theo hiểu biết của chúng tôi, chỉ có giải pháp của Radu Sion. [8] giải quyết cho trường hợp này, tuy nhiên giải pháp cũng tồn tại một số hạn chế như đã trình bày ở trên. Đối với các câu truy vấn này, ta có thể chứng minh các câu truy vấn này tương tự như câu truy vấn vùng, với điều kiện là điều kiện lọc của câu truy vấn ban đầu. Kết quả của hàm bao gộp có thể được tính toán tại server và được client kiểm tra lại ngẫu nhiên sau khi chứng thực được query assurance cho các record thỏa mãn điều kiện. Hoặc hoàn toàn được tính toán tại client. Tiếp theo, tài liệu tiến hành phân tích về mặt chi phí của giải pháp. Do hiện tại, chưa có một nghiên cứu trong lĩnh vực về query assurance cho CSDL XML, nên các phân tích chi phí được đánh giá dựa trên chi phí tối đa và tối thiểu theo tính toán lý thuyết. Đồng thời, ở đây, chúng tôi chỉ đề cập đến các chi phí phát sinh nhằm đảm bảo query assurance. Trước tiên, tài liệu trình bày một số ký hiệu quy ước được sử dụng bao gồm: n Tổng số phần tử (số element và số attribute). s Tổng số phần tử trả về của một truy vấn. f Tham số fanout của cây N MB+. h Chiều cao của cây. L Số node lá của cây. N Tổng số node của cây. |sign| Kích thước giá trị băm (20 byte cho SHA-1) Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 53/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh Chi phí lưu trữ tại server (storage cost): chi phí phát sinh cho việc lưu trữ tại server là chi phí dùng để lưu cây N MB+. Cây N MB+ là kết hợp bởi một cây NameTree và các cây ValueTree, ParentTree ở các lá của cây NameTree. Kích thước của cây NameTree phụ thuộc vào số lượng node trong cây cấu trúc (shema tree) của tài liệu XML. Số lượng node này thường là rất nhỏ so với số lượng node của cây dữ liệu (data tree) XML, đồng thời ít biến động trong thời gian sống của dữ liệu. Do đó, chi phí lưu trữ chủ yếu là chi phí để lưu các cây ParentTree và ValueTree. Do số lượng ValueTree và ParentTree biến đổi tùy theo số phần tử của schema tree, và chiều cao của các cây là biến đổi phụ thuộc và số phần tử dữ liệu tương ứng với mỗi phần tử cấu trúc. N hư vậy, để tiện cho việc đánh giá, ta giả sử schema tree của tài liệu XML chỉ có duy nhất một phần tử, và do đó chỉ có một cây ValueTree và một cây ParentTree. Dễ dàng nhận ra rằng, tổng số phần tử dữ liệu ở các lá của cây ValueTree và ParentTree là giống nhau. Giả sử rằng các phần tử dữ liệu là phân biệt nhau qua (nameid, value), nghĩa là, mỗi slot của một node lá bất kỳ chỉ chứa liên kết đến một phần tử dữ liệu duy nhất. Khi đó ta có: ⎥⎥ ⎤⎢⎢ ⎡=⎥⎥ ⎤⎢⎢ ⎡= f nL f nL VTreeVTree 2, maxmin (5.1) Ta có số node lá cần thiết tối thiểu trong trường hợp tất cả các node là đều đầy và số node là tối đa trong trường hợp tất các các node lá chỉ chứa ½ số phần tử. Từ số Lmin và Lmax, có thể xác định được số node tối thiểu và tối đa của cây như sau. ⎡ ⎤ 1log minmin += VTreefVTree Lh (5.2) 1log max 2 max +⎥⎥ ⎤⎢⎢ ⎡= VTreefVTree Lh (5.3) Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 54/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh 1 11 11 1 minmin min + ⎥⎥ ⎥⎥ ⎥ ⎤ ⎢⎢ ⎢⎢ ⎢ ⎡ ⎟⎟ ⎟⎟ ⎠ ⎞ ⎜⎜ ⎜⎜ ⎝ ⎛ − − = − f fLN h VTree (5.4) 1 21 21 1 maxmax max + ⎥⎥ ⎥⎥ ⎥ ⎥ ⎤ ⎢⎢ ⎢⎢ ⎢ ⎢ ⎡ ⎟⎟ ⎟⎟ ⎟ ⎠ ⎞ ⎜⎜ ⎜⎜ ⎜ ⎝ ⎛ − ⎟⎟⎠ ⎞ ⎜⎜⎝ ⎛− = − f f LN h VTree (5.5) Các công thức (5.2),(5.3),(5.4),(5.5) có thể được chứng minh như sau. Giả sử, cây B+ có L node lá, khi đó ta có: Số node tối thiểu tại độ sâu Số node tối đa tại độ sâu h Lmin Lmax h-1 ⎡Lmin/f⎤ ⎡2Lmax/f⎤ h-2 ⎡Lmin/f2⎤ ⎡22Lmax/f2⎤ … … … h-(h-1) ⎡Lmin/fh-1⎤ = 1 ⎡2h-1Lmax/fh-1⎤ = 1 ⇒ ⎡ ⎤ 1log minmin += VTreefVTree Lh 1log max 2 max +⎥⎥ ⎤⎢⎢ ⎡= VTreefVTree Lh ⇒ N min = Lmin + ⎡Lmin/f⎤ + ⎡Lmin/f2⎤ + … + 1 = ⎥⎥ ⎥⎥ ⎥ ⎤ ⎢⎢ ⎢⎢ ⎢ ⎡ ⎟⎟ ⎟⎟ ⎠ ⎞ ⎜⎜ ⎜⎜ ⎝ ⎛ − − − f fL h 11 11 1 min min + 1 N max = Lmax + ⎡2Lmax/f⎤ + ⎡22Lmax/f2⎤ + … + 1 = ⎥⎥ ⎥⎥ ⎥ ⎥ ⎤ ⎢⎢ ⎢⎢ ⎢ ⎢ ⎡ ⎟⎟ ⎟⎟ ⎟ ⎠ ⎞ ⎜⎜ ⎜⎜ ⎜ ⎝ ⎛ − ⎟⎟⎠ ⎞ ⎜⎜⎝ ⎛− − f f L h 21 21 1 max max + 1 Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 55/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh N hư vậy, chi phí lưu trữ phát sinh có thể tính như sau: ⎪⎩ ⎪⎨ ⎧ +=++= +=++= VTreeNTreePTreeVTreeNTreestorage VTreeNTreePTreeVTreeNTreestorage NNNNNC NNNNNC maxmaxmaxmax minminminmin 2 2 (5.6) Thực tế, tồn tại khá nhiều phần tử có khóa so sánh trùng nhau, tức là có bộ giá trị (nameid, value) đối với ValueTree hoặc (nameid, pnodeid, value) đối với ParentTree giống nhau. N hững phần tử này chiếm cùng một slot trong node lá của cây chỉ mục. Do đó, tổng số slot sử dụng trong các node lá luôn nhỏ hơn tổng số phần tử cần chỉ mục. N ếu gọi n’, n” lần lượt là số các phần tử phân biệt qua (nameid, value) và (nameid, pnodeid, value), dễ dàng nhận ra rằng: n’ < n’’ < n. N hư vậy, để tính được chi phí lưu trữ, cần xác định giá trị n’ và n’’. Sau đó thay vào công thức (5.4), (5.5) để xác định chi phí cho ValueTree và ParentTree. Kích thước VO: trong phân tích này, chúng tôi chỉ quan tâm đến phần dữ liệu phải thêm vào VO để có thể chứng minh truy vấn, do đó, khái niệm kích thước VO là kích thước thông tin thêm vào. N goài kết quả truy vấn, server trả về hai giá trị khóa biên (value cho ValueTree và pnodeid, value cho ParentTree) cùng băm của record tương ứng của hai khóa trên. Cộng với kích thước của co-path dùng để tính toán băm của node gốc. N hư đã trình bày ở phần trên, một câu truy vấn XPath có thể được phân tích thành nhiều đoạn truy vấn vùng, vì vậy có nhiều VO cho các vùng này. Kích thước VO trả về là tổng kích thước của các VO con. Xét kích thước VO cho một truy vấn, ta có: Số node ở độ sâu Số phần tử bổ sung vào co-path h ⎥⎥ ⎤⎢⎢ ⎡ += f sLh 2 CVOh = f.Lh - s + 2 h-1 Lh-1 = ⎡Lh/f⎤ CVOh-1 = f.Lh-1 – Lh Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 56/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh … … … h-i Lh-i = ⎡Lh-i+1/f⎤ CVOh-i = f.Lh-i – Lh-i+1 ⇒ Kích thước VO: CVO =|sign|∑ CVOi , i = 1,hNMBTree (5.7) Chi phí CPU: chi phí CPU (CPU time) là tổng thời gian xử lý kể từ lúc server nhận được yêu cầu truy vấn cho đến khi kết quả truy vấn được giải mã hoàn tất phía client sau khi đã loại bỏ thời gian cho việc truyền nhận dữ liệu trên đường truyền. Có thể chia các giai đoạn xử lý một câu truy vấn thành các giai đoạn sau: se rv er s id e cl ie nt s id e Hình 5.11. Các bước thực thi query. - Parse : phân tích các thành phần của câu truy vấn, loại bỏ các ký tự đại diện nếu cần thiết. Có thể từ một câu truy vấn ban đầu sẽ được phân tích thành nhiều câu truy vấn con. - Plan : xây dựng chiến lược thực thi các câu truy vấn vừa phân tích. - Fetch data : thực hiện truy vấn trên cây chỉ mục, đọc các record thỏa mãn điều kiện từ CSDL. Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 57/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh - Build VO : bổ sung các thông tin cần thiết để xây dựng các VO phục vụ cho việc chứng minh truy vấn, bao gồm cả thời gian tạo ra các co-path cho kết quả truy vấn. - Verify VO : kiểm tra kết quả truy vấn dựa vào thông tin VO nhận được. - Generate XML : phục hồi lại dữ liệu dạng XML. Do dữ liệu XML ban đầu lưu xuống CSDL đã chuyển thành các t-node và a-node, nên kết quả trả về phải được phục hồi sang dạng XML ban đầu. Hiện tại, do giới hạn về thời gian, chương trình đánh giá không thực hiện hai bước đầu là Parse và Plan. Các câu truy vấn được dùng để thực thi được cung cấp dưới dạng execution plan. Do đó, công việc còn lại chỉ bắt đầu từ bước fetch data. Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 58/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh Chương 6 THỰC NGHIỆM Để đánh giá thực nghiệm, chúng tôi hiện thực giải pháp trên nền tảng .N ET Framework 2.0, thư viện mã hóa sử dụng Rijndael và SHA1 cung cấp bởi .N ET 2.0. Sử dụng MS SQL Server 2005 Express Edition để lưu trữ CSDL. Chương trình thử nghiệm trên hệ thống PC P4 2.8GHz, 512MB. Tài liệu XML mẫu là Modial [19] với 69,846 hạng mục (gồm 22,423 element 47,423 attribute). Lược đồ của tài liệu này được trình bày ở phần phụ lục. Hệ số fanout của cây N MB+ là 10. Các tiêu chí được đo đạc bao gồm: - Chi phí lưu trữ (tổng số node của cây N MB+ theo thực tế, so sánh với số node tính trên lý thuyết trình bày ở mục 5). - Kích thước VO (số lượng các hạng mục trả kèm về để chứng minh truy vấn). - Thời gian thực thi truy vấn bao gồm các giai đoạn: fetch data, build VO, verify VO, generate XML và thời gian tổng cộng kể từ lúc câu truy vấn bắt đầu được thực thi cho đến khi dữ liệu XML kết quả được giải mã hoàn tất. Các thời gian này được so sánh trên tương quan số lượng record trả về trên tổng số record của CSDL để thấy được tính tương quan của thời gian thực thi với các thông số khác (yêu cầu là tương quan tuyến tính với kết quả trả về và tương quan logarit với kích thước CSDL). N goài ra, thời gian này còn được so sánh với thời gian thực thi câu truy vấn trong điều kiện không bảo mật để đo được chi phí phát sinh cho việc bảo mật của giải pháp. Đề tài: Security Issues in Querying Dynamic Outsourced XML Databases Trang 59/93 SV: Nguyễn Việt Hùng HD: TS Đặng Trần Khánh Các số liệu đo đạc dựa trên câu truy vấn /mondial/country/city[population > 500000]. Kế hoạch thực thi cho câu truy vấn này được trình bày ở phần phụ lục. Chi phí lưu trữ Ở đây, chúng tôi bỏ qua chi phí lưu trữ cho dữ liệu XML mà chỉ tập trung vào phần chi phí phát sinh cần thiết để lưu trữ cấu trúc cây chỉ mục. Chi phí này được đánh giá thông qua số lượng node cần thiết của cây để thực hiện chỉ mục cho số lượng các phần tử cần thiết. Đánh giá chi phí dựa trên chi phí tính toán từ công thức (5.4) và (5.5) cho kích thước tối thiểu và tối đa. Từ kích thước của CSDL (database size) (số lượng phần tử), xác định được số phần tử phân biệt nhau qua bộ thuộc tính (nameid, value) và (nameid, pnodeid, value) để xác định số lượng slot cần lưu trữ tại các node lá của cây chi mục theo (5.4), (5.5). Kết quả trình bày ở bảng dưới đây. Database Size 10K 20K 30K 40K 50K 60K 70K Va lu e Tr ee Distinct items 5,415 10,743 16,128 20,907 22,279 22,499 24,913 Min Leaves 542 1,075 1,613 2,091 2,228 2,250 2,492 Min Height 4 5 5 5 5 5 5 Min Nodes 603 1,196 1,794 2,325 2,477 2,501 2,770 Max Leaves 1,083 2,149 3,226 4,182 4,456 4,500 4,983 Max Height 5 6 6 6 6 6 6 Max Nodes 679 1,345 2,018 2,615 2,786 2,814 3,116 Pa re nt T re e Distinct items 9,126 18,108 27,181 36,376 43,612 50,379 57,497 Min Leaves 913 1,811 2,719 3,638 4,362 5,038 5,750 Min Height 4 5 5 5 5 5 5 Min Nodes 1,015 2,014 3,022 4,043 4,848 5,599 6,390 Max Leaves 1,826 3,622 5,437 7,276 8,723 10,076 11,500 Max Height 6 6 6 7 7 7 7 Max Nodes 1,143 2,265 3,400 4,549 5,454 6,299 7,189 Bảng 6.2. Kích thước cây ValueTree, ParentTree min, max Bảng 6.3. Chi phí lưu trữ Data size 10K 20K 30K 40K 50K 60K 70K Min nodes 1,618 3,210 4,816 6,368 7,325 8,100 9,160 Max nodes 1,822 3,610 5,418 7,164 8,240 9

Các file đính kèm theo tài liệu này:

  • pdfNhững vấn đề bảo mật khi truy vấn cơ sở dữ liệu XML động được OUTSOURCED.pdf