An Architecture for a Secure
Service Discovery Service
Steven Czerwinski, Todd Hodes, Ben Zhao,
Anthony Joseph, Randy Katz
UC Berkeley
Internet Scale Research Group
Outline
•
•
•
•
•
Intro
Architecture
Security
Wide Area
Conclusion
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, selfconfiguring, secure, and support wide-area
• Existing solutions don’t adequately address needs
A Secure Service Discovery Service
The Idea:
A secure directory tool which tracks services in
the network and allows authenticated users to
locate them through expressive queries
• 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
Berkeley Service Discovery Service
The SDS
Where is a
color printer?
czerwin@cs
<query>
<type> io.printer </type>
<color> yes </color>
</query>
443 Phaser
<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>
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
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
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
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
The Berkeley SDS Architecture
Capability
Manager
Services
SDS Servers
Converter
UC
Berkeley
Printer
Certificate
Authority
SDS Server
Jukebox
Soda
Hall
Printer
Cory
Hall
Client
“czerwin@cs”
Room
464
Room
466
The Berkeley SDS Architecture
Capability
Manager
Services
SDS Servers
Converter
Printer
Certificate
Authority
SDS Server
UC
Berkeley
Jukebox
Soda
Hall
Printer
Cory
Hall
Client
“czerwin@cs”
SDS Servers
Room
464
Room
466
• Create hierarchy for query routing
• Store service information and process requests
• Advertise existence for bootstrapping
The Berkeley SDS Architecture
Capability
Manager
Services
SDS Servers
Converter
UC
Berkeley
Printer
Certificate
Authority
SDS Server
Jukebox
Soda
Hall
Printer
Cory
Hall
Client
“czerwin@cs”
Services
Room
464
Room
466
• Responsible for creating and
propagating XML service description
The Berkeley SDS Architecture
Capability
Manager
Services
SDS Servers
Converter
UC
Berkeley
Printer
Certificate
Authority
SDS Server
Jukebox
Soda
Hall
Printer
Cory
Hall
Client
“czerwin@cs”
Clients
Room
464
Room
466
• The users of the system
• Perform look up requests via SDS server
The Berkeley SDS Architecture
Capability
Manager
Services
SDS Servers
Converter
Printer
Certificate
Authority
SDS Server
UC
Berkeley
Jukebox
Soda
Hall
Printer
Cory
Hall
Client
“czerwin@cs”
Certificate Authority
Room
464
Room
466
• Provides a tool for authentication
• Distributes certificates to other components
The Berkeley SDS Architecture
Capability
Manager
Services
SDS Servers
Converter
Printer
Certificate
Authority
SDS Server
UC
Berkeley
Jukebox
Soda
Hall
Printer
Cory
Hall
Client
“czerwin@cs”
Capability Manager
Room
464
Room
466
• Maintains access control rights for users
• Distributes capabilities to other components
How the Pieces Interact...
Client Queries:
• SDS address from server
• Sends service specification
• Gets service description
and URL
SDS
Server
Server Announcements:
• Global multicast address
• Periodic for fault detection
• Provides all parameters
Backup
SDS
Server
Client
Service Announcements:
• Multicast address from server
• Periodic for soft state
• Contains description
Printer
Music
Server
Security Goals
• Access control
• Authentication of all components
• Encrypted communication
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
Security Hazards
<soda-admin@cs>
Clients:
• Encryption for 2-way
communication
• Have to prove rights
• Authenticated RMI
SDS
Server
Server Announcements:
• Have to sign information
• No privacy needed
• Signed broadcasts
Backup
SDS
Server
<soda-admin@cs>
Client
<czerwin@cs>
Service Announcements:
Printer
• Only intended server can decrypt
<ninja@cs>
• Signed descriptions to validate
• Secure One-Way Broadcasts
Music
Server
All components:
• Use certificates for
authentication
<ravenben@cs>
Secure One-Way Broadcasts
Service Description
Service
KPrivate
Signing
(DSA)
KSession
Symmetric
Encryption
(Blowfish)
KSession {Signed Description}
Asymmetric
Encryption
(RSA)
Server
EKPublic
EKPublic {Session Key}
Key idea: Use asymmetric algorithm to encrypt symmetric key
Secure One-Way Broadcasts
KSession {Signed Description}
Symmetric
Encryption
(Blowfish)
Signed Service Description
EKPublic {Session Key}
Asymmetric
Encryption
(RSA)
Server
EKPrivate
KSession (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
Wide Area
Root
UC Berkeley
UCB Physics
UCB CS
ISRG
Kinko’s
Kinko’s #123
IRAM
Stanford U
CS
Physics
Mobile People
Room 443
Hierarchy motivation:
• Divide responsibility among servers for scalability
The big question:
• How are queries routed between servers?
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)
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
Multiple Hierarchies
Root
UC Berkeley
UCB Physics
UCB CS
ISRG
Kinko’s
Kinko’s #123
IRAM
Room 443
Administrative Hierarchy
Stanford U
CS
Physics
Mobile People
Multiple Hierarchies
Northern California
Root
UC Berkeley
UCB Physics
Soda Hall
ISRG
IRAM
Berkeley, US
Hearst St
Stanford, US
Kinko’s
Stanford U
CS
Kinko’s #123
Physics
Mobile People
Room 443
Physical Location Hierarchy
Query Routing in Action
Berkeley, US
UC Berkeley
UCB Physics
<type>fax
</type>
<color>yes
</color>?
Soda Hall
ISRG
IRAM
Hearst St
Kinko’s #123
Color Fax
SDS servers
Room 443
Services
Clients
czerwin@cs
Query Routing in Action
Berkeley, US
UC Berkeley
UCB Physics
<type>fax
</type>
<color>yes
</color>?
Soda Hall
ISRG
IRAM
Hearst St
Kinko’s #123
Color Fax
SDS servers
Room 443
Services
Clients
czerwin@cs
Room 443 server examines its data and tables, routes to parent
Query Routing in Action
Berkeley, US
UC Berkeley
UCB Physics
<type>fax
</type>
<color>yes
</color>?
Soda Hall
ISRG
IRAM
Hearst St
Kinko’s #123
Color Fax
SDS servers
Room 443
Services
Clients
czerwin@cs
Each server checks aggregation tables, Hearst sees possible hit
Query Routing in Action
Berkeley, US
UC Berkeley
UCB Physics
<type>fax
</type>
<color>yes
</color>?
Soda Hall
ISRG
IRAM
Hearst St
Kinko’s #123
Color Fax
SDS servers
Room 443
Services
Clients
czerwin@cs
Kinko’s #123 finds match, returns service description
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