Decentralized authorization and data security in web content delivery *

1. 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

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

3. Motivations in CDN • Contents are delivered by a third-party, not directly by content owners • e.g., Akamai.com’s servers deliver contents for CNN.com • Delivered contents are usually modified or transformed by proxies • 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

4. Transcode Medium Low High Customize banner An example of 2-step data transformations

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 • Role authority is trusted and assigns roles to proxies • Role authority can be the content owner or others • A trustworthy proxy is authorized to perform allowed operations • 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

7. Original content Modified Content 3. Data is delivered by proxies with specified roles 2. Required role sequence specified by content owner Illustration of role-based proxy management Content Owner Web Surfer 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 • 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

9. Major operations in our model • Role certificate generation and distribution by role authority • Control information generation by content owner specifying the sequence of roles required for data transformation • E.g., control information • Routing of contents to required proxies • Performed among proxies in a decentralized fashion • Protocols for the verification of integrity by each proxy and client Content owner Web surfer 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. 2310 230* 20** 0*** 2311 231* 21** 1*** 2312 232* 22** 2*** 2313 233* 23** 3*** 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 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. 1020 100* 10** 0*** 1021 101* 11** 1*** 1022 102* 12** 2*** 1023 103* 13** 3*** Another example: lookup table for 1021 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) Proxies only need to keep the local routing information in lookup tables, not the global CDN map 1*** 1021 2310 10** 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

14. Security protocol for performing transformation and verification • A proxy with the required role is requested to perform a transformation on a requested content • The proxy verifies the previous transformation is valid • The proxy performs transformation and signs the hash of the transformed segment • The proxy appends its role certificate to the segment • 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 iDeliver Protocol

15. 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)

16. Complexity of iDelivery 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 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 iDeliveryprotocolin details • We also support caching (see paper for details)