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 dont adequately address needs

4
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

5
Berkeley Service Discovery Service
The SDS
Service Description
Where is a color printer?
XML Query
443 Phaser
443 Phaser
czerwin_at_cs
ltservicegt ltnamegt 443 Phaser lt/namegt lttypegt
io.printer lt/typegt ltlocationgt Soda/443
lt/locationgt ltcolorgt yes lt/colorgt
ltpostscriptgt yes lt/colorgt ltcontactgt
lturlgt rmi//batman.cs lt/urlgt
lt/contactgt lt/servicegt
ltquerygt lttypegt io.printer lt/typegt ltcolorgt yes
lt/colorgt lt/querygt
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 (SAPSDP)
• 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_at_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_at_cs

• SDS Servers
• Create hierarchy for query routing
• Store service information and process requests
• Advertise existence for bootstrapping

12
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_at_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_at_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_at_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_at_cs

• Capability Manager
• Maintains access control rights for users
• Distributes capabilities to other components

16
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
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
Asymmetric Encryption (RSA)
Symmetric Encryption (Blowfish)
Server EKPublic
KSession Signed Description
EKPublic Session Key
Key idea Use asymmetric algorithm to encrypt
symmetric key
21
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
Kinkos
UC Berkeley
Stanford U
UCB Physics
UCB CS
Kinkos 123
CS
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
Kinkos
UC Berkeley
Stanford U
UCB Physics
UCB CS
Kinkos 123
CS
Physics
ISRG
IRAM
Mobile People
Room 443
Administrative Hierarchy
26
Multiple Hierarchies
Northern California
Root
Stanford, US
Berkeley, US
Kinkos
UC Berkeley
Stanford U
Hearst St
UCB Physics
Soda Hall
Kinkos 123
CS
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
Kinkos 123
lttypegtfax lt/typegt ltcolorgtyeslt/colorgt?
ISRG
IRAM
Color Fax
SDS servers
Services
Room 443
Clients
czerwin_at_cs
28
Query Routing in Action
Berkeley, US
UC Berkeley
Hearst St
UCB Physics
Soda Hall
Kinkos 123
lttypegtfax lt/typegt ltcolorgtyeslt/colorgt?
ISRG
IRAM
Color Fax
SDS servers
Services
Room 443
Room 443
Clients
czerwin_at_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
Kinkos 123
lttypegtfax lt/typegt ltcolorgtyeslt/colorgt?
ISRG
IRAM
Color Fax
SDS servers
Services
Room 443
Clients
czerwin_at_cs
Each server checks aggregation tables, Hearst
sees possible hit
30
Query Routing in Action
Berkeley, US
UC Berkeley
Hearst St
Kinkos 123
UCB Physics
Soda Hall
lttypegtfax lt/typegt ltcolorgtyeslt/colorgt?
ISRG
IRAM
Color Fax
SDS servers
Services
Room 443
Clients
czerwin_at_cs
Kinkos 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_at_iceberg.cs.berkeley.edu