secure outsourcing of xml data n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Secure outsourcing of XML data PowerPoint Presentation
Download Presentation
Secure outsourcing of XML data

Loading in 2 Seconds...

play fullscreen
1 / 70

Secure outsourcing of XML data - PowerPoint PPT Presentation


  • 129 Views
  • Updated on

Secure outsourcing of XML data. Barbara Carminati University of Insubria at Varese barbara.carminati@uninsubria.it http://www.dicom.uninsubria.it/~barbara.carminati. Software as a Service. Get What you need When you need it Pay for What you use Don’t worry about

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Secure outsourcing of XML data


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    1. Secure outsourcing of XML data Barbara Carminati University of Insubria at Varese barbara.carminati@uninsubria.it http://www.dicom.uninsubria.it/~barbara.carminati

    2. Software as a Service • Get • What you need • When you need it • Pay for • What you use • Don’t worry about • Deployment, installation, maintenance, upgrades • Hire/train/retain people

    3. Emerging trend: data outsourcing • Database as a Service (DBaaS), why? • Most organizations need efficient data management • DBMSs are extremely complex to deploy, setup, and maintain • Require skilled DBAs (at very high cost!) • Driven by faster, cheaper, and more accessible networks

    4. DBMS Server Traditional architecture Client

    5. Client Third-party architecture Outsourced db Data Internet Data Provider Data owner Results Queries

    6. Research issues • Distributed query management • Consistency • Security & Privacy: • Main requirements: confidentiality, integrity, authenticity, completeness, etc…

    7. Security & Privacy • NaÏve solution: • Data providers are trusted -- they always operate according to owners security and privacy policies

    8. Security & Privacy • To be satisfied evenin the presence of an untrusted provider that: • Can modify/delete the data • Can access sensitive/private information • Can send data to non authorized users • Can send a user not all the information he/she is authorized to access • Can be attacked from outside • To be satisfied by incurring minimal computation and bandwidth overhead

    9. Main requirements • Confidentiality • Authenticity/integrity • Completeness

    10. Confidentiality • Confidentiality: • Data are disclosed only to authorized users • Usually, confidentiality requirements are expressed through a set of access control policies

    11. Access control policies SAs Access granted (partially or totally) Access denied Users Access control Authorizations Reference Monitor Access request

    12. Confidentiality • When data are outsourced, confidentiality has a twofold meaning: • Confidentiality wrt users: • protect data against unauthorized user’s read accesses • Confidentiality wrt providers: • protect the Owner’s data from read accesses by untrusted providers

    13. Integrity • It refers to information protection from modifications; • it involves several goals: • Assuring the integrity of information with respect to the original information– often referred to as authenticity • Protecting information from unauthorized modifications

    14. Integrity/authenticity • Usually enforced through signature techniques • When data are outsourced: • Traditional signature techniques are not enough • A user can be returned only selected portions of the data signed by the owner

    15. Completeness • It refers to ensure that users receive all information they are entitled to access, according to the owner policies

    16. Secure outsourcing of XML data our proposal

    17. Scenario • We focus on XML • The Owner is the producer of information. It specifies access control policies • The Provideris responsible for managing (a portion of) the Owner information and answering user queries according to the access control policies specified by the Owner Provider XML Source Credential base Policy Base XML docs Owner

    18. Scenario • We focus on XML data • The Owner specifies access control policies according to an access control model supporting: • Fine-grained and credential-based access control • XML-based language to express access control policies and credentials (X-Sec)‏

    19. Cred expression target Path M P secretary[@level>='4'] organization.xml department[@dept='Marketing']/employee[@level<10] R F secretary[@level>='9'] organization.xml department[@dept='Internet']/employee R F Example • X-Sec Alice Credential • Access Control Policy (encoded by X-Sec language) <x_profile> <secretary level='7’> <name>Alice Rossi</name> <department>marketing</type> <type> administrative</type> <email>arossi@myorganization.com</email> </secretary> </x_profile>

    20. Example Alice submits this Xpath: //organization/department/employee[@level>4] <?xml version="1.0" encoding="UTF-8"?> <Organization> <department dept=‘Marketing’> <employee> <name> Alice Rossi</name> <salary> 80K </salary> <level> 7</level> </employee> <employee> <name> Bob Red</name> <salary> 50K </salary> <level> 5 </level> </employee> <employee> <name> Tom Black</name> <salary> 170K </salary> <level> 12</level> </employee> </department> <department dept=‘HR’> <employee> <name> Kim </name> <salary> 150K </salary> <level> 11 </level> </employee> <employee> <name> Ann</name> <salary> 80K </salary> <level> 7</level> </employee> </department> </Organization> denied Access control policy authorizes Alice to see department[@dept=‘Marketing’]/employee[@level<10] denied denied

    21. Problem Provider 2 XML docs Provider 1 XML Source Policy Base Credential base XML docs Strategies for ensuringconfidentiality, authenticity and completeness even if the provider is not trusted XML docs Owner XML docs Provider 3 Untrusted Provider 4

    22. Proposed solution: overall idea • The owner outsources to providers a Security Enhanced Encryption of the original XML docs, where: • Authenticity and integrity are enforced by an alternative digital signature devised for XML docs, i.e., Merkle Signature; • Confidentiality is ensured by the properties of Well formed encryption; • It contains security information, that makes the providers able to evaluate queries. • Moreover, the owner provides users with auxiliary data structures (i.e., Query templates), that make them able to submit queries directly to providers and verify the obtained query results

    23. Owner-side processing Merkle Signature XML document Well-formed encryption Partioning information Authenticity information Security Information K1 Kj Km Kp SE-ENC document Removal of encrypted content Query Template

    24. OWNER Query Answer CLIENT PROVIDER System architecture Decryption keys SE-ENC document credentials User

    25. OWNER Query Answer CLIENT PROVIDER System architecture Query Template SE-ENC document XML query Reply Document User

    26. Confidentiality enforcement

    27. Confidentiality issues • Secure data outsourcing implies two different confidentiality issues: • Confidentiality with respect to users • Confidentiality with respect to providers

    28. Confidentiality • Problem: Providers must be able to evaluate queries and enforce access control policies on XML documents, by respecting at the same time confidentiality requirements • Solution based on encryption techniques

    29. Well Formed Encryption • The idea is that before sending a document to a provider, the owner encrypts it: Well formed encryption • The approach is based on encrypting all document portions to which the same set of access control policies apply with the same key

    30. Well-Formed Encryption P2 &1 P1,P3 &5 P1,P3 &2 &8 &3 &4 &6 &7 P3 &9 &13 P1,P3 P1,P3 P1,P3 P1,P3 &14 &10 P3 &11 &12 &15 &16

    31. Well-Formed Encryption P2 &1 Node encrypted with key K1 P1,P3 &5 P1,P3 &2 &8 &3 &4 &6 &7 P3 &9 &13 P1,P3 P1,P3 P1,P3 P1,P3 &14 &10 P3 &11 &12 &15 &16

    32. Well-Formed Encryption P2 &1 P1,P3 &5 P1,P3 &2 &8 &3 &4 &6 &7 P3 &9 &13 P1,P3 P1,P3 P1,P3 P1,P3 &14 &10 P3 Nodes encrypted with key K2 &11 &12 &15 &16

    33. Well-Formed Encryption P2 &1 P1,P3 &5 P1,P3 &2 &8 &3 &4 &6 &7 P3 &9 &13 P1,P3 P1,P3 P1,P3 P1,P3 &14 &10 P3 Nodes encrypted with key K3 &11 &12 &15 &16

    34. Well-Formed Encryption P2 &1 P1,P3 &5 P1,P3 &2 &8 &3 &4 &6 &7 P3 &9 &13 P1,P3 P1,P3 P1,P3 P1,P3 &14 &10 P3 Nodes encrypted with key Kd &11 &12 &15 &16

    35. Well-Formed Encryption P2 &1 P1,P3 &5 P1,P3 &2 &8 &3 &4 &6 &7 P3 &9 &13 P1,P3 P1,P3 P1,P3 P1,P3 &14 &10 P3 P1 K2 P2 K1 &11 &12 &15 &16 P3 K2, K3

    36. Well Formed Encryption:Key management • The owner does not supply any key to providers • Keys are properly stored by the owner into the user entries in the directory server. • Each user entry contains the key(s) corresponding to access control policies satisfied by the user: • Hierarchical key management scheme that minimizes the number of keys to be permanently stored

    37. Well Formed Encryption pro • Each node of the resulting encrypted document is accessible only by authorized users • It prevents provider accesses to the managed data Well-formed encryption ensures confidentiality both wrt users and Providers

    38. Well Formed Encryption cons • Issue: • How can the Provider evaluate queries on XML encrypted data?

    39. Quering XML encrypted data - Querying encrypted documents is a difficult issue and greatly depends on the kinds of queries that are submitted to providers. - In our scenario, we assume users submit XPath expressions

    40. Quering XML encrypted data - Xpath expressions: • Queries that impose conditions only on the structure of the XML document (structure queries)‏ • Queries that impose conditions also on data content (content-dependent queries)

    41. Quering XML encrypted data - Xpath expressions: • Queries that impose conditions only on the structure of the XML document (structure queries)‏ • Queries that impose conditions also on data content (content-dependent queries)

    42. Well Formed Encryption Well formend encryption is encoded by an XML document preserving the structure of the original XML document Enc(tg1,K1)‏ tg1 Enc(tg2,K2)‏ tg2 Enc(tg2,K2)‏ tg2 Enc(tg3,K1)‏ tg3 tg3 Enc(tg3,K3)‏ Att Att Enc(Att,K3)‏ Enc(Att,K1)‏

    43. Well Formed Encryption • Preserving the original doc structure greatly facilitates the evaluation of structure queries over the encrypted document • But it implies some security threats: • Data dictionary attacks by providers and users: • At schema level (tag/attribute names)‏ • On element data contents/attribute values

    44. Well Formed Encryption • To prevent data dictionary attacks we adopt the encryption scheme proposed by Song, Wagner and Perrig for textual data (IEEE Symposium on Security and Privacy,2000): • Different occurrences of the same word, encrypted with the same key, result in different encryptions • It is possible to perform keyword-based searches on the encrypted textual data without knowing decryption keys

    45. Quering XML encrypted data structure queries • XPath expressions specify only the location path: • Ex: //tag1/tag2/tag3// • Since we preserve the structure, client simply generates the corresponding encrypted query • Ex: //Enc(tag1,K1)/Enc(tag2,K2)/Enc(tag3,K1)// • Providers are able to evaluate the encrypted query directly on the encrypted document

    46. Quering XML encrypted data - Xpath expressions: • Queries that impose conditions only on the structure of the XML document (structure queries)‏ • Queries that impose conditions also on data content (content-dependent queries)

    47. Quering XML encrypted data content-dep. queries • In order to make a provider able to evaluate conditions on encrypted data, we provide it with additional information • In particular, on the basis of the data domain, we use two different strategies: • non-textual data: Hacigums et al. (SIGMOD 2002)‏ • textual data: Song et al. (IEEE Symposium on Security and Privacy,2000)‏

    48. Quering XML encrypted data content-dep. queries • Proposed solution for non-textual data: • Previous research on querying encrypted relational db (H.Hacigumus et al.)‏ • Given a relation R, the data owner divides the domain of each attribute into distinguished partitions, to which it assigns a different id • For each encrypted tuple, the provider receives also the partition ids of each of its attributes • The provider is able to perform queries directly on the encrypted tuples, by exploiting the partitioning ids

    49. Eid Name Dip Salary etuple ID Eid ID Name ID Dip ID Salary 0945 Alice 98 275 #%& … ... ... 46 7903 Bob 93 436 8239 John 93 380 @#% ... … … 41 @#% … … … 30 Partition salary ID 251-300 46 301-350 29 351-400 30 401-450 41 Quering XML encrypted data content-dep. queries Employee relation Provider SELECT * FROM Employee WHERE Salary=275 SELECT * FROM Employee WHERE ID_salary=46

    50. tg1 Enc(tg1,K1)‏ Well formed encryption & Node Partion IDs tg2 tg2 Enc(tg2,K2)‏ Enc(tg2,K2)‏ tg3 tg3 Enc(tg3,K3)‏ Enc(tg3,K1)‏ Salary Salary Enc(380,K1); 30 Enc(275,K3); 46 //Enc(tg1,K1)/Enc(tg2,K2)/Enc(tg3,K1)[@Enc(Salary,K1)=46]// Partition salary ID 251-300 46 301-350 29 351-400 30 401-450 41 //tg1/tg2/tg3[@Salary=275]// Quering XML encrypted data content-dep. queries Provider Owner