Authentication and Integrity in Outsourced Databases

1. Authentication and Integrity in Outsourced Databases Kanaka Rajanala

2. What is Outsourced Database • Organizations outsource their data management needs to an external provider. • The service provider hosts client database and offers mechanisms. • Create databases • Updating • Storing • Accessing (querying)

3. Advantages of ODB • The organizations can concentrate on their core tasks and operate their business applications via Internet. • Don’t worry about • Deployment, instillation, maintenance ,upgrades. • Hire, train/retain people.

4. Challenges • Overall performance • Scalability • Usability

5. Challenges • Privacy/Security • Protection of outsourced data from intruders and attacks. • Protecting clients from misuse of data by service providers. • Ensuring integrity+privacy+completeness of query replies.

6. Goal • This paper investigate techniques to help ODB client authenticate the origin and verify the integrity of data returned by the service provider in response to a posed query.

7. System Model • ODB is an example of Client –Server model. • Types of ODB • Unified Client Model • Multi Querier Model • Multi Owner Model

8. Owner/Querier 1. Unified Owner Scenario Server Site Server Data Deposit + Queries Encrypted User Database A single entity creates, queries, manipulates the database.

9. Querier 1 Owner/Querier Querier 3 Querier 2 2. Multi-Querier Scenario Server Site Data Deposit & queries Server Encrypted User Database Data Queries

10. Owner 1 Owner 2 Querier 2 Owner 3 Querier 1 3. Multi-Owner Scenario Server Site Server Encrypted User Database Data Deposit & queries Data Queries

11. Why do we need Integrity • In some occasions where we may not want secrecy but want integrity • Every one is allowed to read a message • But no one is allowed to modify it.

12. Why do we need Authentication • To authenticate the source of data. • The main goal is to assure ODB clients that the data they receive from the server has not be tampered from an external adversary or the server itself.

13. Granularity of Integrity • Table level-impractical for large tables. • Column level-very expensive for the owner in terms of computation. • Optimal is to provide integrity at row level.

14. Overhead Factors and Desired Features • Querier computation • Querier bandwidth • Server computation • Owner computation • Server storage

15. MAC’s or Signatures • With MAC client can ask server to store record along with MAC. • Works for Unified Client model where owner and querier are same. • Cannot be worked with other models • MAC key to be shared between all owners and queriers. • Non repudiation of queries cannot be achieved.

16. Standard RSA

17. Condensed RSA • Server: • Selects records matching posed query • Multiplies corresponding RSA signatures • Returns single signature to querier Server Querier Given t record signatures: {σ1, σ2 …σt} , compute combined signature σ1,t =Πσi mod n Send σ1,t to the querier Given t messages: {m1,m2 … mt} and σ1,t verify combined signature: (σ1,t)e = ? =Π h(mi) (mod n) σ1,t

18. Condensed RSA • Reduced querier computation costs • Querier performs (t-1) mult-s and a one exponentiation • Constant bandwidth overhead • Querier receives a single RSA signature • As secure as batch RSA (with FDH) • Not efficient for Multi-Owner model

19. Batch Verification of RSA Signatures • Batching: useful when many signature verifications need to be performed simultaneously • Reduces computational overhead • By reducing the total number of modular exponentiations • Fast screening of RSA signatures : • Given a batch instance of signatures {σ1, σ2 …σt} on distinct messages {m1, m2 … mt} where h() is a full domain hash function

20. Fast Screening • Reduces (somewhat) querier computation but not bandwidth overhead • Individual signatures are sent to the querier for verification • Bandwidth overhead can be overwhelming • Consider weak (anemic) queriers • Query reply can have thousands of records • Each RSA signature is at least 1024 bits!

21. Cost Comparisons 1. Querier computation: Parameters: For RSA: |n| = 1024 For DSA: |p| = 1024 and |q| = 160