Download ppt - People

SAC, March, 2007, Seoul, Korea
Decentralized authorization
and data security in web
content delivery *
Danfeng Yao (Brown University, USA)
Yunhua Koglin (Purdue University, USA)
Elisa Bertino (Purdue University, USA)
Roberto Tamassia (Brown University, USA)
* Supported by U.S. NSF CCF–0311510, IIS–0324846, 0430274, CERIAS
Content Delivery Network (CDN)
Modified
Content
Original
content
Content Owner
Web Surfer
Web intermediaries (proxies) in content delivery network
2
Motivations in CDN

Contents are delivered by a third-party, not
directly by content owners


Delivered contents are usually modified or
transformed by proxies



e.g., Akamai.com’s servers deliver contents for
CNN.com
e.g., Modify sizes and resolutions of multimedia files
e.g., Customize dynamic web pages based on client
preferences
Data transformations may involve multiple
proxies
3
An example of 2-step data
transformations
Transcode
High
Medium
Low
Customize
banner
4
Problem definition
Our goal: to ensure the integrity of data
transformations in content delivery networks
The key problem: How to ensure that data
transformations are properly authorized?
Our approach: role-based proxy management
Inspired by Role-based access control [Sandhu et al 1996]
5
Overview of our role-based
authorization approach

Entities: content owner, proxy, client, role authority



A trustworthy proxy is authorized to perform allowed
operations



Role authority is trusted and assigns roles to proxies
Role authority can be the content owner or others
Transcoder proxy is authorized to transcode data only
The proof of role assignment is the role certificate issued
by role authority
Only contents transformed by authorized proxies are
accepted
Role
Cert
6
Illustration of role-based proxy
management
Modified
Content
Original
content
Content Owner
Web Surfer
3. Data is delivered
by proxies with
specified roles
2. Required role sequence
specified by content owner
1. Proxies are assigned roles by a role authority
(Different color represents different proxy roles)
7
Advantages of role-based proxy
management

Easy to manage in a decentralized environment



The role abstraction is scalable, useful when the
number of proxies is high
Routing of contents is based on roles, rather than
individual identities of proxies (will explain later)
Improves flexibility and fault-tolerance

Multiple proxies are assigned to the same role and
provide backups to each other
Proxies with required roles
8
Major operations in our model
1. Role certificate generation and distribution by role authority
2. Control information generation by content owner specifying
the sequence of roles required for data transformation
1. E.g., control information
3. Routing of contents to required proxies
1. Performed among proxies in a decentralized fashion
4. Protocols for the verification of integrity by each proxy and
client
Content
owner
Web surfer
Proxies with required roles
Control info.
9
Main challenge in applying role
management to CDN
The key problem: How to route contents to
required proxies without a centralized map of
CDN?
The challenge: proxies do not have the global
knowledge of CDN (e.g., who has what roles)
Our approach: use a role-number based routing to
locate required proxies
10
Role number for proxies

Each role is given a role number


e.g., transcoding role is numbered 2310
The lookup table of a proxy is indexed by role numbers,
and stores pointers to neighboring proxies with indexed
role numbers
2310
230*
20**
0***
2311
231*
21**
1***
2312
232*
22**
2***
2313
233*
23**
3***
Role number lookup table for 2310 (* representing any digit; an arrow
represents the address of a proxy with the corresponding role number)
Inspired by distributed hash-tables [Zhao et al 2004]
11
Another example: lookup table for
1021
1020
100*
10**
0***
1021
101*
11**
1***
1022
102*
12**
2***
1023
103*
13**
3***
Role number lookup table for 1021 (* representing any digit;
an arrow represents the address of a proxy with the corresponding
role number)
12
Role-number based routing
(from role-number 2310 to role-number 1021)
Proxies only need to keep the local routing information in
lookup tables, not the global CDN map
1***
2310
10**
1.
2.
3.
4.
1021
102*
Prefix-based routing, correcting role-number digit-by-digit
Similar to overlay networks (Distributed Hash Table)
Suffix-based routing will work too
13
Further improvement is described in the paper
Security protocol for performing
transformation and verification
1.
2.
A proxy with the required role is requested to perform a
transformation on a requested content
1.
The proxy verifies the previous transformation is valid
2.
The proxy performs transformation and signs the hash of the
transformed segment
3.
The proxy appends its role certificate to the segment
4.
The proxy consults the lookup table and passes the segment to the
next proxy required by control information
The client verifies the final transformed content against
control information and proxies’ role credentials
14
Security of iDelivery

Assumption: Certified proxies are trusted

Integrity: Delivered content that is modified by


unauthorized entities should not be accepted
Confidentiality: The delivered contents cannot
be viewed by unauthorized entities
Theorem The iDeliver protocol ensures data
integrity and confidentiality

The proof of iDelivery’s security is based on standard digital
signature and encryption schemes (public-key encryption and
symmetric encryption)
15
Complexity of iDelivery
Operations
Hash
Enc/Dec
Sign/Verify
Role Authority
O(N)
O(N)
O(N)
Content server* O(m)
O(1)
O(1)
A proxy*
O(1)
O(1)
O(1)
client*
O(1)
O(1)
O(1)
N is the total number of proxies. m is the number of roles required
for processing the content. * This refers to the operations for one
content request.
16
Summary




Developed a general framework for data integrity in
content delivery networks
Developed a role-based proxy management approach for
the decentralized authorization in CDN
Role-based proxy management improves the flexibility
and fault-tolerance of content delivery
Our paper describes our iDelivery protocol in details

We also support caching (see paper for details)
17