Safety Analysis of UCON Authorization Model

1. Safety Analysis of Usage Control (UCON) Authorization Model Xinwen Zhang, Ravi Sandhu, and Francesco Parisi-Presicce George Mason University AsiaCCS 2006

2. Context USAGE purpose • electronic commerce • information sharing • etcetera USAGE • multi-party security objectives • fuzzy objectives INTEGRITY modification AVAILABILITY access CONFIDENTIALITY disclosure

3. Context • Protection Objectives • Sensitive information protection • IPR protection • Privacy protection • Protection Architectures • Server-side reference monitor • Client-side reference monitor • SRM & CRM

4. Three phases of a usage process • Decision in first two phases • pre-decision: • preA, preB, preC • ongoing-decisions: repeatedly 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, and post 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. Motivations • Two fundamental properties in access control: • Expressive Power • Safety Analysis • Formalization of UCON Model is required • for the precise semantics of the conceptual model • for policy definition • for the analysis of UCON properties.

7. Expressive Power & Safety Analysis • Expressive Power: • The flexibility to express policies for different requirements. • Comparing expressive power among access control models • Safety problem: • Given 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 manageable safety analysis are two conflicting properties of access control models: • In general, the more expressive power a model has, the harder it is (if at all possible) to carry out safety analysis. • Examples: HRU, SPM, and TAM

8. Formalization of UCONA • We focus on UCON preA (UCONA) models in this paper • Attributes and values • Each object is specified by the same set of attributes: ATT • Each attribute has a value domain: dom(a) for a  ATT • A system state is (O, ), where • O is a set of objects (including subjects) • : O  ATT  dom(ATT)  {null} • S  O • Three primitive actions for state transitions: • createObject o: • create a new object o • a  ATT, ’(o.a) = null • destroyObject o: • O’ = O – {o} •  o O’, a  ATT, ’(o.a) = (o.a) • updateAttribute o.a=v’: • ’(o.a) = v’, v’ dom(a) • ’(ent.att) = (ent.att) if ent  o or att  a

9. UCONA Policy • p1, …pi are attribute predicates on s and o; • atc1, … actk are actions on s and o; • creating policy: • If act1 is “creatObject o”; • Only o can be created – single parent policy; • s is parent, o is child; • Assumptions: • Atomic policy enforcement • Serialized accesses

10. Formal Model of UCONA • A UCONA 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 UCONA system is specified by a UCONA scheme and an initial state t0=(O0, 0).

11. Policy Specification Flexibility • DRM policies • RBAC models (RBAC0, RBAC1, RBAC2) • Chinese Wall policies • Dynamic separation of duty • MAC policy with high watermark property

12. 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 UCONA: iTunes-like Systems iTunes music store User Music file Device

13. Expressive Power of UCONA • The expressive power of the UCONA 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 • UCONA is more expressive than TAM. • UCONA is at least as expressive as ATAM.

14. Safety Analysis of UCONA Theorem Safety is undecidable in the general UCONA model. • By reducing a general SO-TAM system to a UCONA system • By simulating the operations of a general Turing machine with a UCONA model.

15. Safety Analysis of UCONA Theorem • The safety problem of a UCONA system is decidable if: • the value domain of each attribute is finite, and • there is no creating policy in the scheme. • Proof idea: • Reduce a UCONA system with these restrictions to a FSM, where the safety problem is mapped to the empty language problem recognized by the FSM. • 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.

16. Safety Analysis of UCONA Theorem • The safety problem of a UCONA 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. • Proof idea: restrictions on creating policies • If c(s,o) is a creating policy, then it has must have “updateAttribute s.a” action, and ’(s.a) (s.a) • There is no policies that can update ’(s.a) to(s.a) in any state.

17. Expressive Power of Decidable UCONA • RBAC96 model with URA97 or PRA97 scheme • A state in RBAC96: S, P, R, UA, UAA, PA, RH, where P  O x R • URA97 scheme: can_assign  ARxCRx2R, can_revoke  ARx2R • A can_assign(ar, cr, [r1,r2]) or can_revoke(ar, [r1,r2]) can be reduced to a set of UCONA policies: • ri  [r1,r2], cr = x y

18. 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 UCONA • DRM applications with consumable rights • Limited number of copies

19. Contribution Summary • Formal study of the expressive power of UCONA: • UCONA is at least as expressive as ATAM. • Safety analysis of UCONA: • Safety undecidability of the general model • Two safety-decidable models with restrictions on the form of the policies in the general model • Expressive power of the decidable models by simulating • RBAC96 with URA97 or PRA97 • DRM applications

20. Ongoing and Future Work • Comparing expressive power between UCON authorization and obligations models • Efficiently decidable UCON models • An administrative model of UCON • Expressive power and safety analysis of UCON ongoing models. • UCON architectures and mechanisms

21. Thank you! Q & A