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) SAC, March, 2007, Seoul, Korea * Supported by U.S. NSF CCF– , IIS– , , CERIAS

2 Content Owner Web Surfer Web intermediaries (proxies) in content delivery network Original content Modified Content Content Delivery Network (CDN)

3 Motivations in CDN Contents are delivered by a third-party, not directly by content owners Contents are delivered by a third-party, not directly by content owners e.g., Akamai.com’s servers deliver contents for CNN.com e.g., Akamai.com’s servers deliver contents for CNN.com Delivered contents are usually modified or transformed by proxies Delivered contents are usually modified or transformed by proxies e.g., Modify sizes and resolutions of multimedia files e.g., Modify sizes and resolutions of multimedia files e.g., Customize dynamic web pages based on client preferences e.g., Customize dynamic web pages based on client preferences Data transformations may involve multiple proxies Data transformations may involve multiple proxies

4 An example of 2-step data transformations Transcode High MediumLow Customize banner

5 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]

6 Overview of our role-based authorization approach Entities: content owner, proxy, client, role authority Entities: content owner, proxy, client, role authority Role authority is trusted and assigns roles to proxies Role authority is trusted and assigns roles to proxies Role authority can be the content owner or others Role authority can be the content owner or others A trustworthy proxy is authorized to perform allowed operations A trustworthy proxy is authorized to perform allowed operations Transcoder proxy is authorized to transcode data only Transcoder proxy is authorized to transcode data only The proof of role assignment is the role certificate issued by role authority The proof of role assignment is the role certificate issued by role authority Only contents transformed by authorized proxies are accepted Only contents transformed by authorized proxies are accepted Role Cert

7 Illustration of role-based proxy management Content Owner Web Surfer Original content 2. Required role sequence specified by content owner Modified Content 3. Data is delivered by proxies with specified roles 1. Proxies are assigned roles by a role authority (Different color represents different proxy roles)

8 Advantages of role-based proxy management Easy to manage in a decentralized environment Easy to manage in a decentralized environment The role abstraction is scalable, useful when the number of proxies is high 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) Routing of contents is based on roles, rather than individual identities of proxies (will explain later) Improves flexibility and fault-tolerance Improves flexibility and fault-tolerance Multiple proxies are assigned to the same role and provide backups to each other Multiple proxies are assigned to the same role and provide backups to each other Proxies with required roles

9 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 Web surfer Content owner Proxies with required roles Control info.

10 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

11 Role number for proxies Each role is given a role number Each role is given a role number e.g., transcoding role is numbered 2310 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 The lookup table of a proxy is indexed by role numbers, and stores pointers to neighboring proxies with indexed role numbers 3*** 3*** 23** 23** 233* 233* *** 2*** 22** 22** 232* 232* *** 1*** 21** 21** 231* 231* *** 0*** 20** 20** 230* 230* 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]

12 Another example: lookup table for *** 3*** 13** 13** 103* 103* *** 2*** 12** 12** 102* 102* *** 1*** 11** 11** 101* 101* *** 0*** 10** 10** 100* 100*1020 Role number lookup table for 1021 (* representing any digit; an arrow represents the address of a proxy with the corresponding role number)

13 Role-number based routing (from role-number 2310 to role-number 1021) *** 102* ** 1. Prefix-based routing, correcting role-number digit-by-digit 2. Similar to overlay networks (Distributed Hash Table) 3. Suffix-based routing will work too 4. Further improvement is described in the paper Proxies only need to keep the local routing information in lookup tables, not the global CDN map

14 Security protocol for performing transformation and verification 1. 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 2. The client verifies the final transformed content against control information and proxies’ role credentials

15 Security of iDelivery Assumption: Certified proxies are trusted Assumption: Certified proxies are trusted Integrity: Delivered content that is modified by unauthorized entities should not be accepted Integrity: Delivered content that is modified by unauthorized entities should not be accepted Confidentiality: The delivered contents cannot be viewed by unauthorized entities Confidentiality: The delivered contents cannot be viewed by unauthorized entities Theorem The iDeliver protocol ensures data integrity and confidentiality 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) The proof of iDelivery’s security is based on standard digital signature and encryption schemes (public-key encryption and symmetric encryption)

16 Complexity of iDelivery OperationsHashEnc/DecSign/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.

17 Summary Developed a general framework for data integrity in content delivery networks Developed a general framework for data integrity in content delivery networks Developed a role-based proxy management approach for the decentralized authorization in CDN 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 Role-based proxy management improves the flexibility and fault-tolerance of content delivery Our paper describes our iDelivery protocol in details Our paper describes our iDelivery protocol in details We also support caching (see paper for details) We also support caching (see paper for details)