Access Control & Digital Rights Management KAIST KSE Uichin Lee

Objectives Access control: what, how? Digital rights management

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)

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

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

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

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

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

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

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 usersAccess control list for files

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

DAC Policies User’s 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

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 – Object’s security level represents sensitivity of the information contained in the object (i.e., potential damage could result from unauthorized disclosure of the information) – User’s security level (or clearance) represents trustworthiness not to disclose sensitive information to users not cleared to see it

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 subject’s clearance must dominate the security level of the object being read – Write up: a subject’s clearance must be dominated by the security level of the object being written

MAC Policies S subject writes a TS object (yet cannot read it)  can overwrite TS data! (still can send 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 to C or U users

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 Roles Permissions Actions Resources Session Contexts Session Contexts User Assignment Permission Assignment Session Roles User Sessions

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

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:

ABAC Policy Formulation (Cont’d) 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) = “ ” The access control decision process in essence amounts to the evaluation of applicable policy rules in the policy store.

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”

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 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 Remote File Storage: Interesting Challenges Scalability Reliability … But we also want security

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 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 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 Remove File Storage: Access Control via CP-ABE Public Key MSK SecretKey Sarah : “manager” “IT dept.” SecretKey Kevin : “manager” “sales” OR IT dept. AND managermarketing    

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 AB ?

$ 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

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

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

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

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

DRM Operation Example