Formal Model and Analysis of Usage Control

1. Formal Model and Analysis of Usage Control Dissertation defense Student: Xinwen Zhang Director: Ravi S. Sandhu Co-director: Francesco Parisi-Presicce Department of Information and Software Engineering School of Information Technology and Engineering George Mason University, Fall 2005

2. Outline • Introduction • Motivations & Problem Statement • Background • Usage control and TLA • A Formalization of UCON • A logical model to formalize state transitions in a single usage • Policy specification flexibility of the logical model • Expressive Power of UCON • A model to formalize the global effects of a usage and accumulative results of a sequence of usages • Relative expressive power between UCONA and traditional access control models • Relative expressive power between UCONA and UCONB • Safety Analysis of UCON • Safety undecidability of the general UCONA model • Safety decidable UCONA models • Expressive power of safety decidable models • Contribution Summary and Future Work

3. Motivations & Problem Statement • Motivations of UCON • A comprehensive unified model that • fundamentally extends traditional access control models • captures DRM and trust management systems • A conceptual model has been presented by Park and Sandhu. • Formalization of UCON Model is required • for the precise semantics of the conceptual model • for policy definition • for the analysis of UCON properties. • Two fundamental problems in access control: • Expressive Power • Safety Analysis

4. Three phases of a usage process • Decision in first two phases • pre-decision: • preA, preB, preC • ongoing-decisions: repeatedly decision check during ongoing usage phase • onA, onB, onC • Decision Continuity UCON Model (Park and Sandhu 2004) • Attributes can be updated as side-effects of a usage: • pre, ongoing, post and updates • Attribute Mutability • Core models: • preA0, preA1, preA2, preA3, onAx, preBx, onBx preCx onCx • A real model may be a combination of core models.

5. An Example • Resource-constrained access control • Limited number (10) of ongoing accesses to a single object • When 11th subject requesting new access, one ongoing accessing will be revoked. • Different revocation policies: • By start time: the longest ongoing usage is revoked • By idle time: the usage with the longest total idle time is revoked • By total usage time: the usage with the longest accumulating usage time is revoked. • Need decision continuity, attribute mutability, and ongoing access revocations

6. Temporal Logic of Actions (Lamport 1994) • Basic terms of TLA: • Variables and values • State: assignment of values to variables • Predicates: boolean expressions using variables in a single state • Actions: boolean expressions using variables in two states. • Future temporal operators: • Past Temporal operators

7. Logical Model of UCON: Variables, States, Predicates • Variables: • Subject attributes: role, group, clearance, credit, etc. • Object attributes: type, owner, access control list, etc. • System attributes: location, time, load, etc. • A state of a UCON system is an assignment of values to attributes. • Predicates: boolean expressions built from subject attributes, object attributes, and system attributes in a single state. Alice.credit > $1000, file1.classification = “secure” Dominate(Alice.clearance, file1.classification) (Bob, read)  file2.ACL)

8. Logical Model of UCON: Actions • Control actions: • Actions changing the usage state of a single usage process (s,o,r) • 6 values of state(s,o,r) • 5 actions • Update actions: • s.credit’=s.credit - $50.0 • Obligation actions: • Actions that have to be performed before or during a usage • May or may not be performed by the requesting subject and on the target object.

9. Logical Model of UCON • The logical model of a UCON system is a 5-tuple: (S, PA, PC, AA, AB) , where • S is a set of sequences of states of the system, • PA is a finite set of authorization predicates built from the attributes of subjects and objects, • PC is a finite set of condition predicates built from the system attributes, • AA is a finite set of control actions, • AB is a finite set of obligation actions. • A logic formula consisting of predicates, actions, and logical and temporal operators:

10. Specification of Core Models • Ongoing authorizations: onA123 • Resource-constrained access control, revocation by idle time • Object attribute: • Subject attributes: status (with value of busy or idle), idleTime

11. Specify General Policies • Control Rules: • Update Rules:

12. Specifying General Policies • Completeness: • Any UCON policy can be specified by a non-empty set of control rules and a set of update rules. • Soundness: • A non-empty set of control rules and a set of update rules can be satisfied by at least one UCON model.

13. Policy Specification Flexibility • RBAC models (RBAC0, RBAC1, RBAC2) • Chinese Wall policies • Dynamic separation of duty • MAC policy with high watermark property • Healthcare information systems with authorizations and obligations

14. Expressive Power & Safety Analysis • Expressive Power: • The flexibility to express policies for variant requirements. • Comparing expressive power between access control models • Safety problem: • By giving a system, specified by an initial state and a scheme, is there a reachable state in which a subject has a particular right on an object? • Expressive power and safety analysis are two conflict problems for an access control model: • In general, the more expressive power it has, the harder it is to computationally carry out safety analysis. • Examples: HRU, SPM, and TAM

15. Formal Model of preA & preB • To formalize the global effect of a single usage process • Instead of the detailed state transitions in single usage process by the logical model • A system state is (O, ), where • O is a set of objects • : O  ATT  dom(ATT)  {null} • S  O • Three primitive actions: • createObject, destroyObject, updateAttribute • preA policy: • preB policy:

16. Formal Model of preA & preB • A UCON preA scheme is a 4-tuple (ATT, R, P, C), where • ATT is a finite set of attribute names • R is a finite set of rights, • P is a finite set of predicates • C is a finite set of policies • A UCON preA system is specified by a preA scheme and an initial state (O0, 0). • A UCON preB scheme is a 5-tuple (ATT, R, P, B, C), where • B is a finite set of obligation actions • A UCON preB system is specified by a preB scheme and an initial state (O0, 0).

17. user_register (s, u): true  permit(s,u, register) createObject u; updateAttribute:s.regUsers' = s.regUsers  {u}; updateAttribute: u.registered' = true; updateAttribute: u.platformList'=o; updateAttribute: u.orderList'=o; updateAttribute: u.credit' = 0.00; order (u, m):(u.registered=true)  (u.credit  m.price)  (mu.orderList) permit(u,m,order)updateAttribute:u.orderList' = u.orderList  {m};updateAttribute: m.owner' = u;updateAttribute:u.credit' = u.credit - m.price; register order authorize play deauthorize play (p,m): (p.authorizedby  null)  (m.owner  null)  (p.authorizedby=m.owner)  permit(p,m,play) authorize_platform (u, p):(u.registered=true)  (|u.platformList|<5)  (p u.platformList)permit(u,p,authorize)updateAttribute: u.platformList' = u.platformList  {p};updateAttribute: p.authorizedBy' = u; deauthorize_platform (u, p):(u.registered=true)  (p u.platformList)  permit(u,p,deauthorize)updateAttribute: u.platformList' = u.platformList - {p};updateAttribute: p.authorizedBy' = null; Expressive Power of preA: iTunes-like Systems iTunes music store User Music file Device

18. Expressive Power of UCON preA • The expressive power of UCON preA model has been formally studied by comparing it with traditional access control models: • simulating the general SO-TAM model • Simulating the general SO-ATAM model Theorem UCON preA is more expressive than TAM. UCON preA is at least as expressive as ATAM.

19. Relative Expressive Power ofpreA & preB Theorem UCON preA and preB have the same expressive power. • A preA policy can be simulated by a preB policy. • A preB policy can be simulated by a finite number of preA policies.

20. Safety Analysis of UCON preA Theorem The general preA model has undecidable safety. • By reducing a general SO-TAM system to a preA system • By simulating the operations of a general Turing machine with a preA model.

21. Safety Analysis of UCON preA Theorem The safety problem of a preA system is decidable if: • the value domain of each attribute is finite, and • there is no creating policy in the scheme. The complexity of the safety problem is: • polynomial in the number of possible states of the system. • NP-hard in number of policies in the scheme. Theorem The safety problem of a preA system is decidable if: • the attribute creation graph is acyclic, and • the attribute update graph has no cycle containing a create-parent attribute tuple, and • in each creating policy, both the parent's and the child's attribute tuples are updated.

22. order (s, o):(s.credit  o.price)  (o.owner = null)  permit(s,o,order)updateAttribute: s.credit'=s.credit - o.price;updateAttribute: o.owner=s;updateAttribute:o.copylicense=10; order copy (o1, o2):(o1.allowcopy=true)  permit(o1,o2,copy)createObject o2;updateAttribute: o2.sn' = o1.copylicense;updateAttribute: o1.copylicense' = o1.copylicense-1;updateAttribute: o1.allowcopy' = false; copy allowcopy allow_copy (s, o):(o.owner=s)  (o.copylicense > 0)  permit(s,o,allowcopy)updateAttribute: o.allowcopy = true; Expressive Power of Decidable preA • The decidable model can express an RBAC96 model with URA97 scheme. • The decidable model can express DRM applications with consumable rights.

23. Contribution Summary • A logical model of UCON is developed: • Precisely defining the semantics of the conceptual model • Specifying policies for general UCON models with completeness and soundness • Policy specification flexibility by defining policies for various applications • Formal study of the expressive power of UCON preA and preB: • preA is at least as expressive as ATAM. • preA and preB have the same expressive power. • Safety analysis of UCON preA: • Safety undecidability of the general model • Two safety decidable models with restrictions on the general model • Expressive power of the decidable models by simulating RBAC and DRM applications

24. Future Work • An administrative model of UCON • Efficiently decidable UCON models • Expressive power and safety analysis of UCON ongoing models. • UCON architectures and mechanisms

25. Related Publications • Xinwen Zhang, Sejong Oh, and Ravi Sandhu, PBDM: A Flexible Delegation Model in RBAC, 8th ACM Symposium on Access Control Models and Technologies (SACMAT), 2003. • Xinwen Zhang, Jaehong Park, Francesco Parisi-Presicce, and Ravi Sandhu, A Logical Specification for Usage Control, ACM SACMAT, 2004. • Jaehong Park, Xinwen Zhang, and Ravi Sandhu, Attribute Mutabiligy in Usage Control, Annual IFIP WG 11.3 Working Conference on Data and Applications Security, 2004. • Xinwen Zhang, Jaehong Park, Francesco Parisi-Presicce, and Ravi Sandhu, Formal Model and Policy Specification of Usage Control, ACM Transactions on Information and System Security (TISSEC), to appear. • Xinwen Zhang, Ravi Sandhu, and Francesco Parisi-Presicce, Safety Analysis of Usage Control Authorization Model, to appear in ACM Symposium on Information, Computer, and Communication Security, 2006. • Xinwen Zhang, Masayuki Nakae, Ravi Sandhu, Michael J. Covington, A Usage-based Authorization Framework for Collaborative Computing Systems, in submission.

26. Thank you! Q & A

27. Backup

28. OM-AM Framework (Sandhu 2000)

29. Specifying Core Models • PreA0 • PreA1 • An example: Dynamic Separation of Duty (DSOD) • A subject who prepares a check cannot issue it:

30. Expressive Power of preA • A model for iTunes-like systems • A UCON preA sheme (ATT, R, P, C), where • R={register, order, authorize, deauthorize, play} • ATT: a set of attribute names

31. policy_B(s,o,ob):(s.role=ITE_faculty)  (o.statement = ob) sign(s,ob)  permit(s,o,r) access policy_A1(s,ob):true  permit(s,ob,sign)updateAttribute:s.signed’ = ob; Policy_A2 (s,o):(s.role=ITE_faculty)  (o.statement=s.signed)  permit(s,o,r)updateAttribute: s.signed’=null; sign access Relative Expressive Power ofpreA & preB • A preB system can be simulated with a preA system:

32. policy_A(s,o):(s.role=ITE_faculty)  permit(s,o,r) access policy_B(s,o):(s.role=ITE_faculty)  try_access(s,o) permit(s,o,r) access Relative Expressive Power ofpreA & preB • A preA system can be simulated with a preB system: