Understanding Access Control and Digital Rights Management

1. Access Control & Digital Rights Management KAIST KSE Uichin Lee

2. Objectives Access control: what, how? Digital rights management

3. Access Control Control user access to system resources May implement specific security policy Organization policy Government policy Requirements include Restrict read access (confidentiality) Restrict write access (integrity) Restrict execute access (for applications)

4. Why Access Control? Limit authorized users access to resources they need, allowed to use Limit damage caused by unauthorized users malicious software, viruses Prevent interference between applications

5. General Model User requests access to resource read, write or execute e.g. Alice tries to open example.txt for editing Reference monitor check validity of a request grant or deny access accordingly

6. General Model Authorization Database Authentication Access Control Objects Security Administrator Security Administrator User User Reference Monitor Reference Monitor Auditing Auditing

7. Reference Monitor System process, module that controls access to system resources Required characteristics completeness: always invoked, impossible to bypass isolation: must be tamper proof verifiability: must be shown to be properly implemented

8. Access Control Policy vs. Mechanism Policies: high level guidelines that determine how accesses are controlled and access decisions are determined Mechanisms: low-level software and hardware functions that can be configured to implement a policy

9. Access Matrix Subject, object, activity Authorization is expressed in terms of access rights or access modes (e.g., read, write, execute, own) File 1 File 2 File 3 File 4 Account 1 Account 2 John Own R, W Own R, W Inquiry Credit Alice R Own R, W W R Inquiry Debit Inquiry Credit Bob R, W R Own R, W Inquiry Debit

10. Implementation of Access Matrix Access matrix in reality: very large and sparse Two popular approaches: (1) access control list (ACL) for files and (2) capability lists of users File1 File2 File3 File4 John Alice Bob Capability lists of users Access control list for files

11. Access Control Policies DAC Restricting access to objects based on the identity and need-to-know of the user, process, and/or groups to which they belong Discretionary , in the sense that a subject is capable of passing certain access permission on to another subject [NCSC-TG-004] Widely used in systems (Unix, Windows) MAC Restricting access to objects based on fixed security attributes or clearance labels assigned to users and to files or other objects. Mandatory , in the sense that controls cannot be modified by users or their programs [Bell & Lapadula] Depends on system-enforced mechanisms that override the intentions of the resource owner Widely used in government and DoD systems MAC and DAC are not mutually exclusive, and may be used in conjunction

12. DAC Policies Users identity and authorizations (or rules) that specify the access modes (e.g., read, write, execute) on each object Each request of a user is checked against the specified authorizations Flow of information is possible: a user who is able to read data can pass it to other users not authorized to read it without the cognizance of the owner Example: Unix systems

13. MAC Policies Based on the classification of subjects and objects in the system Each user and each object in the system is assigned a security level Objects security level represents sensitivity of the information contained in the object (i.e., potential damage could result from unauthorized disclosure of the information) Users security level (or clearance) represents trustworthiness not to disclose sensitive information to users not cleared to see it

14. MAC Policies Example: military/government arenas: Top Secret (TS), Secret (S), Confidential (C), and Unclassified (U) Policy: TS > S > C > U Access to an object by a subject: Read down: a subjects clearance must dominate the security level of the object being read Write up: a subjects clearance must be dominated by the security level of the object being written

15. MAC Policies S subject writes a TS object (yet cannot read it) can overwrite TS data! (still can send email to TS subjects) Many systems do not allow write-up, but limit writing to the same level as the subject S subject cannot write C or U data S cannot send an email to C or U users

16. Conventional Access Control Models Identity Based Access Control (IBAC) Access permissions are directly associated with a subject (e.g. ACLs) Difficult to scale Role Based Access Control (RBAC) [Sandhu 1993, NIST 2004] Access permissions are based on the role(s) a subject is performing Better scalability and ease of use, but also has drawbacks (more later) Lattice Based Access Control (LBAC) [Sandhu 1993] Implemented in the US defense sector to address MAC requirements Subjects Subjects Roles Roles Permissions Permissions Actions Actions Resources Resources Session Contexts Session Contexts User Assignment Permission Assignment Session Roles User Sessions

17. Attribute Based Access Control (ABAC) Subject Attributes Associated with a subject (user, application, process) that defines the identity and characteristics of the subject E.g. identifier, name, job title, role Resource Attributes Associated with a resource (web service, system function, or data) E.g. Dublin Core metadata elements Environment Attributes Describes the operational, technical, or situational environment or context in which the information access occurs E.g. current date time, current threat level, network security classification

18. ABAC Policy Formulation 1. S , R , and E are subjects, resources, and environments, respectively; 2. SA k (1 k K), RA m (1 m M), and EA n (1 n N) are the pre-defined attributes for subjects, resources, and environments, respectively; 3. ATTR(s) , ATTR(r) , and ATTR(e) are attribute assignment relations for subject s , resource r , and environment e , respectively:

19. ABAC Policy Formulation (Contd) 4. We also use the function notation for the value assignment of individual attributes. For example: 5. In the most general form, a Policy Rule that decides on whether a subject s can access a resource r in a particular environment e , is a Boolean function of s , r , and e s attributes: Role(s) = Service Consumer ServiceOwner(r) = XYZ, Inc. CurrentDate(e) = 01-23-2005 The access control decision process in essence amounts to the evaluation of applicable policy rules in the policy store.

20. ABAC Policy Rule Examples Modeling conventional RBAC rules: User with role Manager may access the ApprovePurchase web service Modeling richer access control semantics A resource may only be accessed by its owners Modeling mandatory access control Classified files can be accessed by users with equal or higher clearance

21. CP-ABE: Ciphertext-Policy Attribute-Based Encryption Brent Waters SRI International John Bethencourt CMU Amit Sahai UCLA IEEE Symposium on Security and Privacy (SP), 2007

22. 22 What is Ciphertext-Policy Attribute-Based Encryption (CP-ABE)? Type of identity-based encryption One public key Master private key used to make more restricted private keys But very expressive rules for which private keys can decrypt which ciphertexts Private keys have attributes or labels Ciphertexts have decryption policies

23. 23 Remote File Storage: Interesting Challenges Scalability Reliability But we also want security

24. 24 Good: Flexible access policies Bad: Data vulnerable to compromise Must trust security of server Remote File Storage: Server Mediated Access Control Access control list: Kevin, Dave, and anyone in IT department Sarah: IT department, backup manager ?

25. 25 More secure, but loss of flexibility New key for each file: Must be online to distribute keys Many files with same key: Fine grained access control not possible Remote File Storage: Encrypting the Files

26. 26 Remote File Storage: We Want It All Wishlist: Encrypted files for untrusted storage Setting up keys is offline No online, trusted party mediating access to files or keys Highly expressive, fine grained access policies Ciphertext-policy attribute-based encryption does this! User private keys given list of attributes Files can encrypted under policy over those attributes Can only decrypt if attributes satisfy policy

27. 27 Remove File Storage: Access Control via CP-ABE Public Key MSK SecretKey Sarah : manager IT dept. SecretKey Kevin : manager sales OR IT dept. AND manager marketing

28. 28 Collusion Attacks: The Key Threat Important potential attack Users should not be able to combine keys Essential, almost defining property of ABE Main technical trick of our scheme: preventing collusion SK Sarah : A, C SK Kevin : B, D AND A B ?

29. $ cpabe-setup $ cpabe-keygen -o sarah_priv_key pub_key master_key \ sysadmin it_dept 'office = 1431' 'hire_date = 2002' $ cpabe-enc pub_key security_report.pdf (sysadmin and (hire_date < 2005 or security_team)) or 2 of (executive_level >= 5, audit_group, strategy_team)) 29 Implementation: The cp-abe Toolkit

30. Digital Rights Management S.R. Subramanya and Byung K. Yi IEEE Potential 2006

31. DRM Broadly refers to a set of policies, techniques and tools that guide the proper use of digital content

32. DRM Facilitate packaging of raw content into an appropriate form for easy distribution Offline (CD/DVD), online (CDN, P2P) Track and protect the content for temper- proof transmission Protect content from unauthorized use Enable specifications of suitable rights

33. DRM Architecture Potable, networked devices (sometimes with local DRM agent) Superdistribution: P2P distribution (yet, authorization is needed via a license server) Content Protection: Encryption or Digital watermarking

34. DRM Operation Example