Vault: A Secure Binding Service Guor-Huar Lu, Changho Choi, Zhi-Li Zhang University of Minnesota

What are binding services?  A binding service: Stores bindings (a pair) Translates (binding) key into (binding) values.  DNS is a good example maps hostnames into IP addresses Reverse lookup maps IP addresses into hostnames  Other example: SIP registrars, location service in MANET, etc.

Outline  Binding Services  Motivation, Challenges and Approach  Vault  Evaluation  Conclusion

Generic Binding Services  What is generic binding services? Internet-scale infrastructure service Allows arbitrary key-value pairs Many applications can use the same infrastructure  Why is it different from typical lookup service? Ownership is essential E.g., in reverse DNS lookup the key (IP address) gives no indication of the owner.  Security is important!

Secure Binding Services  Two minimum requirements: Only the owner can update or delete its bindings The binding returned must be the correct one deposited by the owner  Must be robust against “ man-in-the- middle ” attacks An attacker between users and the service can intercept and modify messages

Objective  A generic binding service that is Scalable Robust Secure  Distributed Hash Table (DHT) Takes care of scalability and robustness Semantic free, flat id space allows generality  What about security? RSA/PKI enough? Not really.. Other crypto-mechanisms?

Example: Binding service using DHT  Similar to DHT ’ s put/get operations.  B=(k,v), id k =H(k) root(id k )  Question: how to make it secure? put(id k, B) get(id k ) Return OK or B User

RSA/PKI approach  Not robust against “ man-in-the-middle ” attacks  Users can sign their requests Signatures can be easily replaced  Using Certificates? only if the binding key is part of the owner id.  Key problem: need to verify the association between user id and public key Need another secure binding service!

Our approach: using IBE  In identity-based encryption (IBE) identity is the public key! Private key can be generated on-demand  Key idea: use IBE to establish secure channels between users and the system.  Robust against MITM attacks

DHT+IBE: an example DHT System User root(id k ) Encrypt data and s k using id k Send encrypted data to the service Return response encrypted with s k Retrieves the private key for id k

Outline  Introduction  Motivation, Challenges and Approach  Vault  Evaluation  Conclusion

Vault: Architecture overview  Two-level architecture Better control over the service Efficient key management  Pillars: issue keys  Columns: handle users and store bindings.

Vault: Design principles  Secures user to service communication Use IBE to establish secure channels  Focus on the basic mechanism But provide hooks for namespace management  Secures internal system operations Only active columns should serve user requests

Vault: basic operations  User Operations: Registration for owners  Provides necessary hooks for namespace management  Establish owner credential with its user id. Insertion Update and delete Query  Internal Operations: Key retrieval between column and pillars

User operation example: insertion  Binding is sent to home column first.  Home column verifies ownership and forwards to root(id k )  root(id k ) returns encrypted response.

Internal operations  Secure Key retrieval process  Two way hash- chains allows the pillar to: Verify a node is currently active Verify a node ’ s id space range

Outline  Introduction  Motivation, Challenges and Approach  Vault  Evaluation  Conclusion

Local Testbed: System response time The more nodes the better the performance. IBE operations are expensive, the price we pay for added security.

Planetlab System response time does not change much. Some other factors?

Planetlab  Wide area network latency has large impact.  Local proxy should help

Conclusion  New approach in constructing generic secure binding services. DHT+IBE  Cornerstone for future networks and applications.  Currently building more applications using Vault.

Thank You Questions?

Extras  Extra slides follows

Example: Binding Service using DHT  Basic operation  To insert a binding B=(k,v) Compute id k =H(k) The owner “ puts ” B at a node responsible for id k  To query B Again, compute id k =H(k) The Querier “ gets ” B from the node responsible for id k  Question: how to make it secure?

DHT+IBE: an example

DHT+IBE  Encrypts data and a symmetric key s k with id k  Sends encrypted data to the service  The root node of id k (root(id k )) requests a key for id k  root(id k ) decrypts the data, returns a reply encrypted using s k

User Operation: Update and Delete  Two modes: direct if symmetric key is still valid, indirect if it expires.  No IBE in direct mode: efficient!  Indirect mode is similar to the insert operation.

User Operations: Query  Queriers: No need to register  Queries: Delivered to root(id k ) directly.  Symmetric key: Prevents MITM attacks  Nonce: Prevents reply attacks.

Evaluations  Evaluate computational overhead and system response time  Computation overhead for local testbed Computational overhead for crypto-primitives Computational overhead for binding operations

Additional Enhancement  Local Vault Proxy Reduce latency  Binding Delegation Reduce Flash crowd effect  Timed permit Defend against DoS attacks