1 / 21

Safety Analysis of UCON Authorization Model

This paper presents a safety analysis of the Usage Control (UCON) authorization model, which is used for electronic commerce, information sharing, and other purposes. It explores the three phases of a usage process, decision continuity, attribute mutability, and ongoing access revocations, and discusses the motivations and formalization of UCON models.

tpeeler
Download Presentation

Safety Analysis of UCON Authorization Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related