1. An Architecture for a Secure Service Discovery Service Steven Czerwinski, Todd Hodes, Ben Zhao, Anthony Joseph, Randy Katz UC Berkeley Internet Scale Research Group

2. Outline Intro Architecture Security Wide Area Conclusion

3. Supporting Ubiquitous Computing Ubiquitous Computing envisions… –Billions of computers and devices available to users –Devices seamlessly interact with all others –Networks and computers as an unobtrusive utility One problem: Locating servers and devices –How can you locate a light bulb among billions? –Solution must be scalable, fault-tolerant, self- configuring, secure, and support wide-area Existing solutions don’t adequately address needs

4. A Secure Service Discovery Service Services are applications/devices running in the network One piece of the puzzle –Helps manage explosive growth of services –Aids in configuration by providing indirection –Aids in protecting user and services by providing security The Idea: A secure directory tool which tracks services in the network and allows authenticated users to locate them through expressive queries

5. Berkeley Service Discovery Service 443 Phaser io.printer Soda/443 yes rmi://batman.cs czerwin@cs Where is a color printer? The SDS 443 Phaser “443 Phaser” io.printer yes XML Query Service Description

6. Discovery Services Discovery/Directory services are not new –Provide a mapping of attribute values to domain specific addresses –Examples: Telephone book, card catalogs, etc.. Computer network discovery services –DNS –NIS –SAP –Globe –LDAP –Jini LookUp service

7. Differentiating Discovery Services Query Routing –Implicitly specified by the query (DNS, globe) Queries –Query grammar complexity (LDAP vs. DNS) Push (advertisements) versus pull (queries) –Pull only (DNS) vs. Push Only (SAP modulo caching) Update rate –Short for mobility vs. long for efficient caching

8. Discovery Services Cont. Bootstrapping –“Well-known” local name (“www.”) –List of unicast addresses (DNS) –Well-known global/local multicast address (SAP, SLP) Soft state vs. hard state –Implicit recovery vs. guaranteed persistence Service data –Reference (globe) vs. content (SAP+SDP) Security –Privacy and authentication

9. Features of the Berkeley SDS Hierarchical network of servers –Multiple hierarchies based on query types Queries –Use XML for service descriptions and queries Bootstrapping via Multicast announcements –Listen on well-known global channel for all parameters Soft-state approach –State rebuilt by listening to periodic announcements Secure –Use certificates/capabilities to authenticate

10. The Berkeley SDS Architecture Printer Converter Jukebox Printer Services Certificate Authority Capability Manager UC Berkeley Soda Hall Room 466 Room 464 Cory Hall SDS Servers SDS Server Client “czerwin@cs”

11. The Berkeley SDS Architecture Printer Converter Jukebox Printer Services Certificate Authority Capability Manager UC Berkeley Soda Hall Room 466 Room 464 Cory Hall “czerwin@cs” SDS Server SDS Servers Create hierarchy for query routing Store service information and process requests Advertise existence for bootstrapping Client SDS Servers

12. The Berkeley SDS Architecture Printer Converter Jukebox Printer Certificate Authority Capability Manager UC Berkeley Soda Hall Room 466 Room 464 Cory Hall SDS Server “czerwin@cs” Services Responsible for creating and propagating XML service description Client SDS Servers

13. The Berkeley SDS Architecture Printer Converter Jukebox Printer Services Certificate Authority Capability Manager UC Berkeley Soda Hall Room 466 Room 464 Cory Hall SDS Server “czerwin@cs” Clients The users of the system Perform look up requests via SDS server Client SDS Servers

14. The Berkeley SDS Architecture Printer Converter Jukebox Printer Services Capability Manager UC Berkeley Soda Hall Room 466 Room 464 Cory Hall SDS Server “czerwin@cs” Certificate Authority Certificate Authority Provides a tool for authentication Distributes certificates to other components Client SDS Servers

15. The Berkeley SDS Architecture Printer Converter Jukebox Printer Services Certificate Authority UC Berkeley Soda Hall Room 466 Room 464 Cory Hall SDS Server “czerwin@cs” Capability Manager Capability Manager Maintains access control rights for users Distributes capabilities to other components Client SDS Servers

16. How the Pieces Interact... SDS Server Client Printer Music Server Backup SDS Server Server Announcements: Global multicast address Periodic for fault detection Provides all parameters Service Announcements: Multicast address from server Periodic for soft state Contains description Client Queries: SDS address from server Sends service specification Gets service description and URL

17. Security Goals Access control Authentication of all components Encrypted communication

18. Security Goals Access control –Services specify which users may “discover” them Authentication of all components –Protects against masquerading –Holds components accountable for false information Encrypted communication –Authentication meaningless without encryption –Hides sensitive information (service announcements) No protection against denial of service attacks

19. Security Hazards SDS Server Client Printer Music Server Backup SDS Server Clients: Encryption for 2-way communication Have to prove rights Authenticated RMI Server Announcements: Have to sign information No privacy needed Signed broadcasts Service Announcements: Only intended server can decrypt Signed descriptions to validate Secure One-Way Broadcasts All components: Use certificates for authentication

20. Secure One-Way Broadcasts Service K Private Signing (DSA) Asymmetric Encryption (RSA) Symmetric Encryption (Blowfish) Service Description Server EK Public K Session K Session {Signed Description}EK Public {Session Key} Key idea: Use asymmetric algorithm to encrypt symmetric key

21. Secure One-Way Broadcasts Asymmetric Encryption (RSA) Symmetric Encryption (Blowfish) Signed Service Description Server EK Private K Session K Session {Signed Description}EK Public {Session Key} (Cache it) To decode, only intended server can decrypt session key Use session to retrieve service description Cache session key to skip later asymmetric operations

22. Wide Area Room 443 ISRG Kinko’s UCB Physics IRAM UC Berkeley UCB CS Stanford U Kinko’s #123 CS Physics Mobile People Root Hierarchy motivation: Divide responsibility among servers for scalability The big question: How are queries routed between servers?

23. The Wide Area Strategy Build hierarchies based upon query criteria –Administrative domain –Network topology –Physical location Aggregate service descriptions (lossy) Route queries based on aggregation tables  Parent Based Forwarding (PBF)

24. Service Description Aggregation Hash values of tag subsets of service description used as description summary Hash list compressed with Bloom Filter [Bloom70] Fixed-size aggregation tables prevent explosion at roots Guarantees no false negatives Can have false positives, probability affected by table size Algorithm: –To add service, compute description tag subsets, insert into Bloom Filter table –To query, compute query tag subsets, examine corresponding entries in Bloom Filter table for possible matches

25. Multiple Hierarchies Room 443 ISRG Kinko’s UCB Physics IRAM UC Berkeley UCB CS Stanford U Kinko’s #123 CS Physics Mobile People Root Administrative Hierarchy

26. Multiple Hierarchies Room 443 ISRG Kinko’s UCB Physics IRAM UC Berkeley Soda Hall Stanford U Kinko’s #123 CS Physics Mobile People Root Physical Location Hierarchy Stanford, USBerkeley, US Hearst St Northern California

27. Query Routing in Action Room 443 ISRG UCB Physics IRAM UC Berkeley Soda Hall Kinko’s #123 Berkeley, US Hearst St SDS servers Services Clients czerwin@cs Color Fax fax yes ?

28. Query Routing in Action Room 443 ISRG UCB Physics IRAM UC Berkeley Soda Hall Kinko’s #123 Berkeley, US Hearst St SDS servers Services Clients czerwin@cs Color Fax fax yes ? Room 443 Room 443 server examines its data and tables, routes to parent

29. Query Routing in Action Room 443 ISRG UCB Physics IRAM UC Berkeley Soda Hall Kinko’s #123 Berkeley, US Hearst St SDS servers Services Clients czerwin@cs Color Fax fax yes ? Each server checks aggregation tables, Hearst sees possible hit

30. Query Routing in Action Room 443 ISRG UCB Physics IRAM UC Berkeley Soda Hall Kinko’s #123 Berkeley, US Hearst St SDS servers Services Clients czerwin@cs Color Fax fax yes ? Kinko’s #123 finds match, returns service description

31. Conclusion A tool for other applications –Provides a listing of services in the network –XML descriptions allow for flexibility –Well defined security model –Fault tolerant, scalable –Releasing local area implementation as part of Ninja Ongoing work –Experimenting with wide area strategy and caching For more information –sds@iceberg.cs.berkeley.edu