An Architecture for a Secure Service Discovery Service

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 The SDS Service Description Where is a color printer? XML Query “443Phaser” 443 Phaser czerwin@cs <service> <name> 443 Phaser </name> <type> io.printer </type> <location> Soda/443 </location> <color> yes </color> <postscript> yes </color> <contact> <url> rmi://batman.cs </url> </contact> </service> <query> <type> io.printer </type> <color> yes </color> </query>

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 Services Capability Manager SDS Servers Converter UC Berkeley SDS Server Printer Certificate Authority Jukebox Soda Hall Cory Hall Printer Client Room 466 Room 464 “czerwin@cs”

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

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

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

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

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

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

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. <soda-admin@cs> • Server Announcements: • Have to sign information • No privacy needed • Signed broadcasts • Clients: • Encryption for 2-way communication • Have to prove rights • Authenticated RMI <soda-admin@cs> <czerwin@cs> • Service Announcements: • Only intended server can decrypt • Signed descriptions to validate • Secure One-Way Broadcasts <ninja@cs> <ravenben@cs> Security Hazards SDS Server Backup SDS Server Client • All components: • Use certificates for authentication Music Server Printer

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

21. KSession {Signed Description} EKPublic {Session Key} Secure One-Way Broadcasts Asymmetric Encryption (RSA) Symmetric Encryption (Blowfish) Server EKPrivate KSession Signed Service Description (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 Root UC Berkeley Kinko’s Stanford U UCB Physics UCB CS CS Kinko’s #123 Physics ISRG IRAM Mobile People Room 443 • 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 Root UC Berkeley Kinko’s Stanford U UCB Physics UCB CS CS Kinko’s #123 Physics ISRG IRAM Mobile People Room 443 Administrative Hierarchy

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

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

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

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

30. Query Routing in Action Berkeley, US UC Berkeley Hearst St Kinko’s #123 UCB Physics Soda Hall <type>fax </type> <color>yes</color>? Color Fax ISRG IRAM SDS servers Services Room 443 Clients czerwin@cs 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