an architecture for a secure service discovery service
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
An Architecture for a Secure Service Discovery Service
Steven Czerwinski, Todd Hodes, Ben Zhao,Anthony Joseph, Randy Katz
UC BerkeleyInternet 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, self-
configuring, secure, and support wide-area
• Existing solutions don’t adequately address needs
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
Berkeley Service Discovery Service
<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>
czerwin@cs
Where is a color printer?
The SDS
443 Phaser“4
43 Phaser”
<query> <type> io.printer </type> <color> yes </color></query>
XML Query
Service
Description
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
Printer
Converter
Jukebox
Printer
Services
CertificateAuthority
CapabilityManager
UC Berkeley
Soda Hall
Room466
Room 464
Cory Hall
SDS Servers
SDS Server
Client
“czerwin@cs”
The Berkeley SDS Architecture
Printer
Converter
Jukebox
Printer
Services
CertificateAuthority
CapabilityManager
UC Berkeley
Soda Hall
Room466
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
The Berkeley SDS Architecture
Printer
Converter
Jukebox
Printer
CertificateAuthority
CapabilityManager
UC Berkeley
Soda Hall
Room466
Room 464
Cory Hall
SDS Server
“czerwin@cs”
Services
Services•Responsible for creating and
propagating XML service description
Client
SDS Servers
The Berkeley SDS Architecture
Printer
Converter
Jukebox
Printer
Services
CertificateAuthority
CapabilityManager
UC Berkeley
Soda Hall
Room466
Room 464
Cory Hall
SDS Server
“czerwin@cs”
Clients•The users of the system•Perform look up requests via SDS server
Client
SDS Servers
The Berkeley SDS Architecture
Printer
Converter
Jukebox
Printer
ServicesCapabilityManager
UC Berkeley
Soda Hall
Room466
Room 464
Cory Hall
SDS Server
“czerwin@cs”
CertificateAuthority
Certificate Authority•Provides a tool for authentication•Distributes certificates to other components
Client
SDS Servers
The Berkeley SDS Architecture
Printer
Converter
Jukebox
Printer
Services
CertificateAuthority
UC Berkeley
Soda Hall
Room466
Room 464
Cory Hall
SDS Server
“czerwin@cs”
CapabilityManager
Capability Manager•Maintains access control rights for users•Distributes capabilities to other components
Client
SDS Servers
How the Pieces Interact...
SDSServer
Client
Printer MusicServer
BackupSDS
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
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
SDSServer
Client
PrinterMusicServer
BackupSDS
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
<ninja@cs>
<soda-admin@cs>
<soda-admin@cs>
<ravenben@cs>
<czerwin@cs>
Secure One-Way Broadcasts
Service KPrivate
Signing(DSA)
AsymmetricEncryption
(RSA)
SymmetricEncryption(Blowfish)
Service Description
ServerEKPublic
KSession
KSession {Signed Description} EKPublic {Session Key}
Key idea: Use asymmetric algorithm to encrypt symmetric key
Secure One-Way Broadcasts
AsymmetricEncryption
(RSA)
SymmetricEncryption(Blowfish)
Signed Service Description
ServerEKPrivate
KSession
KSession {Signed Description} EKPublic {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
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 scalabilityThe 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
Room 443
ISRG
Kinko’s
UCB Physics
IRAM
UC Berkeley
UCB CS
Stanford U
Kinko’s #123 CS Physics
Mobile People
Root
Administrative Hierarchy
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
Query Routing in Action
Room 443
ISRG
UCB Physics
IRAM
UC Berkeley
Soda Hall Kinko’s #123
Berkeley, US
Hearst St
SDS servers
Services
Clientsczerwin@cs
Color Fax<type>fax</type><color>yes</color>?
Query Routing in Action
Room 443
ISRG
UCB Physics
IRAM
UC Berkeley
Soda Hall Kinko’s #123
Berkeley, US
Hearst St
SDS servers
Services
Clientsczerwin@cs
Color Fax<type>fax</type><color>yes</color>?
Room 443
Room 443 server examines its data and tables, routes to parent
Query Routing in Action
Room 443
ISRG
UCB Physics
IRAM
UC Berkeley
Soda Hall Kinko’s #123
Berkeley, US
Hearst St
SDS servers
Services
Clientsczerwin@cs
Color Fax<type>fax</type><color>yes</color>?
Each server checks aggregation tables, Hearst sees possible hit
Query Routing in Action
Room 443
ISRG
UCB Physics
IRAM
UC Berkeley
Soda Hall Kinko’s #123
Berkeley, US
Hearst St
SDS servers
Services
Clientsczerwin@cs
Color Fax<type>fax</type><color>yes</color>?
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– [email protected]