An Architecture for a Secure Service Discovery Service

transcript

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,

• 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”

Printer

Converter

Jukebox

Printer

Services

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

Printer

Converter

Jukebox

Printer

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

Printer

Converter

Jukebox

Printer

Services

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

Printer

Converter

Jukebox

Printer

ServicesCapabilityManager

UC Berkeley

Soda Hall

Room466

Room 464

Cory Hall

SDS Server

“czerwin@cs”

Certificate Authority•Provides a tool for authentication•Distributes certificates to other components

Client

SDS Servers

Printer

Converter

Jukebox

Printer

Services

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>

<ravenben@cs>

<czerwin@cs>

Secure One-Way Broadcasts

Service KPrivate

Signing(DSA)

AsymmetricEncryption

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

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

Kinko’s

UCB Physics

UC Berkeley

UCB CS

Stanford U

Kinko’s #123 CS Physics

Mobile People

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

Kinko’s

UCB Physics

UC Berkeley

UCB CS

Stanford U

Mobile People

Administrative Hierarchy

Multiple Hierarchies

Room 443

Kinko’s

UCB Physics

UC Berkeley

Soda Hall

Stanford U

Mobile People

Physical Location Hierarchy

Stanford, USBerkeley, US

Hearst St

Northern California

Query Routing in Action

Room 443

UCB Physics

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

UCB Physics

UC Berkeley

Berkeley, US

Hearst St

SDS servers

Services

Clientsczerwin@cs

Room 443

Room 443 server examines its data and tables, routes to parent

Room 443

UCB Physics

UC Berkeley

Berkeley, US

Hearst St

SDS servers

Services

Clientsczerwin@cs

Each server checks aggregation tables, Hearst sees possible hit

Room 443

UCB Physics

UC Berkeley

Berkeley, US

Hearst St

SDS servers

Services

Clientsczerwin@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

• Ongoing work– Experimenting with wide area strategy and caching

• For more information– sds@iceberg.cs.berkeley.edu

An Architecture for a Secure Service Discovery Service

Documents