United States Patent
`Anand et al.
`
`[19]
`
`US006044466A
`Patent Number:
`Date of Patent:
`
`[11]
`[45]
`
`6,044,466
`Mar. 28, 2000
`
`[54] FLEXIBLE AND DYNAMIC DERIVATION OF
`PERMISSIONS
`
`[75] Inventors: RangachariAnand, Teaneck, N.J.;
`Frederique-Anne Giraud, Ossining,
`N.Y.; Nayeem Islam, Thornwood, N.Y.;
`Trent Ray J aeger, Croton-on Hudson,
`NY; Jochen Liedtke, Ossining, NY.
`
`[73] Assignee: International Business Machines
`Corp., Armonk, NY.
`
`[21] Appl. No.: 08/979,807
`[22] Filed:
`Nov. 25, 1997
`
`[51] Int. Cl.7 .................................................... .. G06F 12/14
`[52] US. Cl. ............................................................ .. 713/200
`[58] Field of Search ................................... .. 713/200, 201;
`709/225, 229; 364/2225, 286.4, 286.5;
`711/163; 707/9
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,265,221 11/1993 Miller .................................... .. 395/725
`5,335,346
`8/1994
`395/600
`5,649,099
`7/1997 Theimer et al. ................. .. 395/18701
`5,911,143
`6/1999 Deinhart et al. ...................... .. 707/103
`
`5,924,094
`
`7/1999 simei . . . . . . . . . . . .
`
`. . . . .. 707/10
`
`7/1999 Hsieh .......... ..
`5,925,126
`5,966,715 10/1999 Sweeney et al.
`5,968,177 10/1999 Batten-Carew et al. .
`
`713/200
`707/203
`.. 713/201
`
`OTHER PUBLICATIONS
`
`Yellin, “Low Level Security in Java”, http://java.sun.com/
`sfaq/veri?erhtml, pp 1—12, Dec. 1996.
`Bank, “Java Security”,
`http://www—swiss.ai.mit.edu/
`~jbank/javapaper.html, pp 1—11, Dec. 1995.
`Thomas, “The Navigator Java Environment: Current Secu
`rity Issues”, http://developer.netscape.com/docs/manuals/
`javasecurityhtml, pp. 1—3, Jan. 1996.
`Jaeger et al., “Implementation of a Discretionary Access
`Control Model for Scrip—based Systems”, 8th IEEE Com
`puter Security Foundations Workshop Proceedings, pp
`70—84, Jun. 1995.
`
`Sandhu et al., “Role—Based Access Control: A Multi—Di
`mensional View”, IEEE 10th Annual Computer Security
`Applications Conference Proceedings, pp 54—62, Dec. 1994.
`
`Anand et al., “A Flexible Security Model for Using Internet
`Content”, IEEE The Sixteenth Symposium on Reliable
`Distributed Systems Proceedings, pp 89—96, Oct. 1997.
`Unknown, “HotJava(tm): The Security Story”, http://java
`.sun.com/sfaq/may95/security.html, pp. 1—7, May 1995.
`
`Trent J aeger, Aviel D. Rubin, Atul Prakash, “Building Sys
`tems That Flexibly Control Downloaded Executable Con
`tent”, USENIX Association, 6th USENIX Security Sympo
`sium, pp. 131—148.
`
`Nayeem Islam, Rangachari Anand, Trent J aeger and Josyula
`R. Rao, “A Flexible Security System For Using Internet
`Content”, IEEE Software, Sep./Oct. 1997, pp. 52—59.
`
`Primary Examiner—Robert W. Beausoliel, Jr.
`Assistant Examiner—Stephen C. Elmore
`Attorney, Agent, or Firm—Scully, Scott, Murphy & Presser;
`Kevin N. Jordan, Esq.
`
`[57]
`
`ABSTRACT
`
`A dynamic derivation mechanism is de?ned which enables
`limited permissions to be dynamically and ?exibly derived
`for executables based upon their authenticated description.
`The dynamic derivation mechanism uses the authenticated
`description to determine the maximal permissions that indi
`vidual principals can delegate to the content. A principal’s
`maximal permissions for content de?ne a superset of the
`rights that that principal will actually delegate to that con
`tent. Although the maximal permissions are derived from
`prede?ned speci?cations, the speci?cations can be sensitive
`to runtime state on the downloader’s system or previous
`delegations to enable the dynamic (i.e., runtime) derivation.
`Multiple principals can delegate a subset of their maximal
`permissions for the executable content. The mechanism uses
`policy for combining the delegated permissions into the
`content’s runtime permissions.
`
`44 Claims, 11 Drawing Sheets
`
`nmiiiiailiiii
`riimipa
`IL]
`
`c?lllelll
`Description
`1L
`
`:i.
`'7
`
`0n Maximal Pl‘lIlllSE-IOD Policy
`Graph i0! 0?, : rt
`
`w
`
`(Vigil
`
`Sim‘f' lypF 6i
`Maximal Fermi.
`
`Maximal Pernils
`Maximal PPl'mlS
`
`imiiiiil
`Peiiiiissimii @
`
`‘Dull/e iiiiiimul PHWSSHHS ZZUJ
`
`Petitioner Apple Inc. - Ex. 1049, p. 1
`
`

`
`U.S. Patent
`
`Mar. 28,2000
`
`Sheet 1 0f 11
`
`6,044,466
`
`Downloading
`Principal
`112
`
`Content
`Description
`22
`
`Site
`Security Policy
`29
`
`Protection
`Domain
`Derivation
`Server
`5.0.
`
`Dynamic
`Derivation
`Mechanism
`
`L99
`
`Derivation Instance lQQ
`(Figs. 6,7)
`Maximal Permissions 129
`
`Derivation Instance @
`(Figs. 6,7)
`Current Permissions L49
`
`FIG.1
`
`Petitioner Apple Inc. - Ex. 1049, p. 2
`
`

`
`U.S. Patent
`
`Mar. 28,2000
`
`Sheet 2 0f 11
`
`6,044,466
`
`Downloading
`Principal
`m
`
`Content
`Description
`120
`
`Site
`Security Policy
`1_39
`
`Dynamic
`Derivation
`Mechanism
`1-09
`
`Create Derivation Instance
`(Fig-7)
`2_0O_
`J’
`Retrieve Permissions Propositions
`(Fig-8)
`3L0
`
`Derive Maximal Permissions
`(Fig.9)
`Q32
`I
`Obtain Current Permissions
`Contributions (Fig.12) @
`I
`Compute Current Permissions
`Q2
`
`Derivation Instance l_6_0
`
`Derivation Instance L6__O
`
`Maximal Permissions 1%
`
`Current Permissions ED
`
`Petitioner Apple Inc. - Ex. 1049, p. 3
`
`

`
`U.S. Patent
`
`Mar. 28,2000
`
`Sheet 3 0f 11
`
`6,044,466
`
`Site Security Policy @
`
`Current Permission
`Propositions Q9
`
`.
`P0110)’ Graphs 3 0
`
`l
`
`1
`
`Equation _301
`(P1 U P2) n P3
`Constraint
`Propositions
`_Q:2,_
`If X_>Then Y
`
`__
`
`Principal @
`
`Traversal Method
`3_2g
`_
`.
`C0mblna§l2€1 Method
`
`Directed Graph %
`
`Access Control List
`i251
`
`Maximal Permission
`Propositions
`§_1_0
`
`Permissions
`(Fig.5)
`
`3Q
`
`1
`
`l
`
`Equations w
`
`Constraint
`Proposition g; r_
`
`Permissions/Node
`.
`
`O
`
`0
`.
`
`Petitioner Apple Inc. - Ex. 1049, p. 4
`
`

`
`U.S. Patent
`
`Mar. 28,2000
`
`Sheet 4 of 11
`
`6,044,466
`
`Policy Graph Directed Graph 32-4
`
`Attribute
`$1.9
`ALL
`
`Manufacturer
`
`Qt]
`entry : PB
`Value
`: IBM Access Control List
`= System Admin RW
`IBM
`4_4(_>
`
`401/ £39
`
`Node 400
`
`* _ A
`
`Value
`:Netscalm
`
`Description
`W Value
`—— N‘ide n. : IBM
`2%
`£1.03
`
`\
`_
`entry —¢
`
`Value entryIPN
`:Netscape
`
`Application
`Class
`__
`
`Value
`: Gam€s
`520:
`
`entry : PC
`
`Application
`Name
`
`entry I PX
`Value
`I Doom
`119A
`
`Petitioner Apple Inc. - Ex. 1049, p. 5
`
`

`
`U.S. Patent
`
`Mar. 28,2000
`
`Sheet 5 of 11
`
`6,044,466
`
`Permissions Structure
`139
`
`Positive Rights:
`2.52
`Negative Rights:
`96o
`Transforms:
`in
`
`Object Group
`El
`Object Group
`our
`Principal
`Q11
`
`Operations
`2152
`Operations
`263
`Action
`so
`
`Limit
`5111
`
`Result
`.57_3
`
`FIG.5
`
`Derivation lnstance
`Structure
`
`Downloading Principal 11
`
`Content Description
`
`Site Security Policy
`
`1 0
`
`l O
`
`Current Permissions
`
`1 O
`
`Maximal Permissions
`
`1 O
`
`FIG.6
`
`Petitioner Apple Inc. - Ex. 1049, p. 6
`
`

`
`U.S. Patent
`
`Mar. 28,2000
`
`Sheet 6 0f 11
`
`6,044,466
`
`Downloading
`Principal
`11_0
`
`Content
`Description
`L32
`
`Site
`Security
`Policy Q9
`
`Create Derivation Instance
`M
`
`Set DI Downloading
`PrincipalzllO
`m
`
`Set DI Content
`Description1l20
`221
`
`Set DI Site
`Security Policy=l30
`m
`
`Set remaining attributes
`to N I L m
`
`l
`
`Derivation Instance
`LE
`
`(Create Derivation Instance 160)
`
`Petitioner Apple Inc. - Ex. 1049, p. 7
`
`

`
`U.S. Patent
`
`Mar. 28,2000
`
`Sheet 7 0f 11
`
`6,044,466
`
`Downloading
`Principal
`11_O
`
`Content
`Description
`1_2_Q
`
`Site
`Security
`Policy Q)
`
`Retrieve the Current
`Retrieve the Maximal
`Proposition Policy Graph
`Proposition Policy Graph
`for the Downloading
`for the Downloading
`Principal
`w Principal
`@
`
`Derive the Maximal
`Permissions Proposition
`from the Policy Graph
`(Figll)
`g9
`
`Derive the Current
`Permissions Proposition
`from the Policy Graph
`(Figll)
`@
`
`Maximal
`Permissions
`Proposition
`m
`
`Current
`Permissions
`Proposition
`m
`
`(Retrieve Permission Propositions 210)
`
`Petitioner Apple Inc. - Ex. 1049, p. 8
`
`

`
`U.S. Patent
`
`Mar. 28,2000
`
`Sheet 8 of 11
`
`6,044,466
`
`Downloading
`Principal
`1_1_0
`l
`
`Content
`Description
`1%
`l
`
`Maximal
`Site
`Permissions
`Security
`Policy Q9 Proposition 3_()
`l
`
`Retrieve Contributing
`Principals (CP) (Fig.10)
`
`91
`
`S t: M . P
`'
`'
`S t: ¢>
`22g
`e
`izzbx
`ermission e
`Max.:# of Contributing Principals
`
`Get Maximal Permission Policy
`Graph for CPi I PGi
`l
`Derive Maximal Permission Contribution
`from PGi using Content Description
`and Downloading Principal I result i
`(Fig.1l)
`9_4Q
`
`9_3Q
`
`l
`Store type of CPi and result i in
`Maximal Permission Set
`
`95_()
`
`Compute Maximal Permissions from
`Maximal Permission Set and
`Maximal Permission Propositions w
`l
`
`l
`Maximal
`Permissions Set Q8_0
`
`l
`Maximal
`Permissions
`
`Q9
`
`(Derive Maximal Permissions 220)
`
`Petitioner Apple Inc. - Ex. 1049, p. 9
`
`

`
`U.S. Patent
`
`Mar. 28,2000
`
`Sheet 9 0f 11
`
`6,044,466
`
`Maximal
`Permissions
`Propositions
`
`3 0
`
`Get Equation from
`Maximal Permissions
`Proposition
`1010
`
`Set: iIO
`Contributing Principals I nill
`Max.=# of equation elements
`
`112.0
`
`Yes
`
`If
`not Operand
`11E)
`
`Collect into
`Contributing Principals
`1&9
`
`Contributing
`Principals
`11M.)
`
`(Retrieve Contributing Principals)
`
`FIG.1O
`
`Petitioner Apple Inc. - Ex. 1049, p. 10
`
`

`
`U.S. Patent
`
`Mar. 28,2000
`
`Sheet 10 of 11
`
`6,044,466
`
`Policy Graph
`3%
`l
`
`Description
`LE)
`
`-
`l
`Set Results to Null
`11_10
`l
`
`Select Next Node
`——> to visit (Traversal
`Method) w
`
`Node = Null
`11 0
`
`Access Control
`List Permits Read
`
`by Caller 1140
`
`Yes
`
`Update Result (Using
`Combination Method)
`LE9
`
`Set Error: PG ACL
`Abort Derivation
`_
`
`Result
`1M)
`
`(Derive X from Policy 810)
`
`FIG.11
`
`Petitioner Apple Inc. - Ex. 1049, p. 11
`
`

`
`U.S. Patent
`
`Mar. 28,2000
`
`Sheet 11 0f 11
`
`6,044,466
`
`Current
`Permissions
`Proposition im
`L
`
`Maximal
`Permissions
`l_5_0
`l
`
`Maximal
`Positions Set
`QQQ
`l
`
`Retrieve Current Contributing
`Principals (Fig.10)
`it
`Set Current Permission I <0
`
`ii]
`
`12A
`
`l
`Execute Delegation Mechanism
`for next Contributing Principal ‘
`1220
`
`.
`Errol” Notlfy
`13g)
`
`Return I True
`
`Yes
`
`Put Principal at
`end of Contributing
`Principals
`12A)
`
`If
`Return is
`within Permissions 0
`Principals Entry in Maximal
`Permission Set and Maximal
`Permission
`E529
`
`Principals
`in)
`Yes
`Current Permission Set 1290
`'_
`
`Add mapping of Principal
`Return to Current Permission
`Set and remove Principal from
`Contributing Principals ll
`
`(Obtain Current Permission
`Contributions)
`
`Petitioner Apple Inc. - Ex. 1049, p. 12
`
`

`
`1
`FLEXIBLE AND DYNAMIC DERIVATION OF
`PERMISSIONS
`BACKGROUND OF THE INVENTION
`1. Field of the Invention
`The present invention is related to a mechanism that
`enables ?exible and dynamic derivation of permissions for
`system processes using an authenticated description of the
`executable content run by the process and a site security
`policy that prescribes the principals that can delegate per
`missions to content of that description and limits to the
`permissions that may be delegated.
`
`Object
`
`Operation
`
`Principal
`
`Permissions
`
`Current Permissions
`
`Maximal Permissions
`
`Glossary
`
`Data containing
`entity.
`An action that uses
`an object.
`A system subject
`that performs
`operations on
`objects (e.g., process)
`The set of objects
`and operations that
`(or Access Rights)
`are permitted upon
`those objects for a
`speci?c principal.
`The permissions of
`a principal at the
`current time.
`A principal’s
`permissions that is
`alWays a superset
`of that principal’s
`current permissions.
`
`2. Discussion of the Prior Art
`DoWnloaded executable content are messages that contain
`programs that are executed upon receipt. It is Well-knoWn
`that doWnloaded executable content must be executed With
`limited permissions to prevent content providers from gain
`ing unauthoriZed access to the doWnloading principal’s
`resources (e.g., private ?les).
`HoWever, deriving a proper, limited set of permissions
`that control the execution of content can be dif?cult. There
`are tWo main problems: (1) content can be transient, so their
`permissions must often be derived aneW and (2) no single
`principal has complete knoWledge of What permissions are
`required and safe for content. Content execution systems
`enable the creation of custom content that may only be
`executed once per doWnloading principal, so the derivation
`of permissions must not depend upon complete prior knoWl
`edge of its behavior. Several principals have limited knoWl
`edge about the permissions that a content should be granted,
`but no one has the breadth of knoWledge necessary to derive
`content permissions. For example, system administrators are
`often trusted to specify permissions of processes completely
`(e.g., mandatory access control). HoWever, the control of
`content requires that system administrators knoW hoW a
`custom application needs to access user data. System admin
`istrators cannot knoW the rights needed by custom content
`nor can they knoW the semantics of user ?les, so they are
`limited in the access control decisions they can make. Other
`principals, such as users and application developers, may
`knoW these ansWers, but they are not completely trusted to
`make access control decisions.
`Current systems depend upon prede?ned mappings
`betWeen content and principals. Typically, this mapping is
`
`6,044,466
`
`2
`based upon the identity of an authenticated signer for the
`doWnloaded content. In addition, codebases (i.e., the source
`locations from Which content Was doWnloaded) are also used
`to identify the rights of content. Derivation of protection
`domains is limited because only one input is available and
`this input may be orthogonal to the rights required. The use
`of the signing principal or codebase to derive rights requires
`that all content from this principal or codebase be executed
`With the same rights. Therefore, When neW content is created
`(and its associated public key or codebase) its rights cannot
`be derived even if the manufacturer and application class are
`knoWn. A separation betWeen author identity, location, and
`content description is necessary to overcome this limitation.
`Current systems demonstrate that multiple principals can
`provide information to derive content permissions, but these
`systems lack a model of hoW these principals interact to
`make such decisions. Most systems rely primarily on one
`principal to make access control decisions, such as the
`content execution system developer (see S. Thomas, The
`Navigator Java Environment: Current Security Issues, at
`Web site (URL), http://developer.netscape.com/library/
`documentation/j avasecurity.html, Which describes the
`Netscape 2.0 and 3.0 security model) or the user (see T.
`Jaeger et al., Implementation of a Discretionary Access
`Control Model for Scripted-based Systems, in Proceedings
`of the 8th IEEE Computer Security Foundations Workshop,
`pgs. 70—84, 1995). Most systems provide access control
`mechanisms, but make no commitment to hoW permissions
`are derived (see N. Borenstein, Email With a Mind of Its
`OWn: The Safe-Tcl Language for Enabled Mail, ULPAA ’94
`Proceedings, pgs. 389—402, 1994 as an early example). A
`feW systems use multiple means for deriving permissions.
`FlexxGuard enables users and/or system administrators to
`select permissions for content, but users have the ultimate
`decision-making poWer (see N. Islam et al., A Flexible
`Security System for Using Internet Content, in IEEE
`SoftWare, pgs. 52—59, September, 1997). In Netscape’s Java
`Capabilities API (see Netscape Communications Corp.,
`Introduction to the Capabilities Classes, at URL html for the
`Netscape 4.0 security model), application developers
`request access rights Within a limited domain speci?ed by
`users and/or system administrators. HoWever, users are not
`limited in the rights that they can delegate to content, and the
`content developer can obtain any rights Within the maximal
`permissions by simply activating them. In a Tcl ?exible
`content interpreter (see T. Jaeger et al., Building Systems
`That Flexibly Control DoWnloaded Executable Content, in
`Proceedings of the Sixth USENIX Security Symposium,
`pgs. 131—148, 1996.), system administrators can de?ne hoW
`application developers may limit other content’s access
`rights, but users may not grant rights.
`RBAC models have also been used extensively to repre
`sent access control policy management, but also presently
`lack the ?exibility to express hoW multiple principals can
`affect common access control decisions. RBAC models
`permit principals to assume a role, Which is another principal
`With its oWn permissions. RBAC models are often used by
`system administrators to specify mandatory access control
`(MAC) policies (see R. Sandhu et al., Role-based Access
`Control: A Multi-Dimensional VieW, Proceedings of the 10th
`Computer Security Applications Conference). A MAC sys
`tem partitions the World into tWo groups: (1) system admin
`istrators Who specify access control policy and (2) users that
`are controlled by the policy. Thus, these RBAC models
`enable system administrators to describe the rights available
`to principals. The only decision a principal can make is
`Whether to delegate all these rights to another principal.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`Petitioner Apple Inc. - Ex. 1049, p. 13
`
`

`
`3
`Dynamic creation of permissions to delegate to processes is
`not possible because of the mandatory nature of the systems.
`In addition, current RBAC systems that permit discretionary
`access control use ACLs Which do not enable the creation of
`dynamic principals (because ACLs need to be updated).
`Therefore, users, content execution systems, and application
`developers must develop ad hoc mechanisms for ?exibly
`and dynamically limiting the rights that are to be delegated
`to the content that they execute. There appears to be nothing
`inherently limiting about RBAC that prevents its use in
`dynamic derivation of rights, but current systems are not
`suitable for such derivation.
`
`SUMMARY OF THE INVENTION
`The present invention de?nes a dynamic derivation
`mechanism that enables limited permissions to be dynami
`cally and ?exibly derived for executables based upon their
`authenticated description. The dynamic derivation mecha
`nism uses the authenticated description to determine the
`maximal permissions that individual principals can delegate
`to the content. A principal’s maximal permissions for con
`tent de?ne a superset of the rights that that principal Will
`actually delegate to that content. Although the maximal
`permissions are derived from prede?ned speci?cations, the
`speci?cations may be sensitive to runtime state on the
`doWnloader’s system or previous delegations to enable the
`dynamic (i.e., runtime) derivation. Multiple principals can
`delegate a subset of their maximal permissions for the
`executable content. The mechanism uses policy for combin
`ing the delegated permissions into the content’s current
`permissions.
`Therefore, trusted principals (e.g., system administrators)
`can specify limits in Which users, application developers,
`and content execution systems can ?exibly delegate rights to
`the speci?ed content.
`In accordance With a preferred embodiment, a method is
`de?ned for deriving current and maximal permissions for
`executable content using:
`a. one or more executable content descriptions;
`b. one or more sets of permissions (access rights) that
`describe the operations that executable content can
`perform on objects;
`c. one or more permission equations that compute one set
`of permissions from one or more other sets of permis
`sions;
`d. one or more permission propositions that specify con
`ditions under Which associated modi?cations to per
`missions apply;
`e. one or more policy graphs that associate permissions,
`permission equations, and/or permission propositions
`With graph nodes;
`The method for deriving current and maximal permissions
`comprises the folloWing steps;
`f. deriving one or more permission equations and one or
`more permission propositions from policy graphs;
`g. deriving of one or more maximal sets of permissions
`from policy graphs;
`h. selecting granted permissions from Within an associ
`ated maximal set of permissions;
`i. combining one or more maximal sets of permissions
`into the maximal permissions using one permission
`equation and one or more permission propositions;
`j. combining one or more granted permissions into one
`current set of permissions Which are a subset of the
`maximal permissions using one permission equation
`and one or more permission propositions.
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6,044,466
`
`4
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 illustrates hoW a dynamic derivation mechanism
`pursuant to the present invention takes an authenticated
`description of some executable content, a site security
`policy, and the identity of the doWnloading principal, and
`derives current and maximal permissions for this instance of
`the content’s doWnload.
`FIG. 2 illustrates ?ve major steps implemented by the
`dynamic derivation mechanism of the present invention.
`FIG. 3 shoWs the site security policy Which includes sets
`of policy graphs used to derive the maximal permissions
`contributions that any principal can delegate to the content
`and sets of permissions propositions used to compute the
`current and maximal permissions from the maximal permis
`sions contributions and the current permissions contribu
`tions delegated by those principals.
`FIG. 4 illustrates that the nodes of a policy graph’s
`directed graph consist of an attribute, a value, an entry, and
`an access control list.
`FIG. 5 illustrates a preferred embodiment of the permis
`sions structure, and shoWs that permissions include positive
`and negative rights and transforms.
`FIG. 6 illustrates the structure of a derivation instance
`Which maps a content description and doWnloading principal
`to its current and maximal permissions, given a site security
`policy.
`FIG. 7 illustrates hoW the ?rst step of the dynamic
`derivation mechanism creates a derivation instance and sets
`its attributes values.
`FIG. 8 illustrates hoW the second step of the dynamic
`derivation mechanism retrieves the maximal and current
`permissions propositions for the doWnloading principal and
`content description from the site security policy.
`FIG. 9 illustrates hoW the third step of the dynamic
`derivation mechanism derives the maximal permissions
`from the contributions of each principal in the maximal
`permissions proposition equation.
`FIG. 10 illustrates hoW the contributing principals are
`extracted from the maximal permissions proposition.
`FIG. 11 illustrates hoW results are derived from a policy
`graph.
`FIG. 12 illustrates hoW the ?fth step of the dynamic
`derivation mechanism derives the current permission set
`from the principals that can contribute to the current per
`mission set.
`
`DETAILED DESCRIPTION OF THE DRAWINGS
`As FIG. 1 depicts, the derivation mechanism (100) takes
`an authenticated description of some executable content
`(120), a site security policy (130), the identity of the
`doWnloading principal (110) and derives current and maxi
`mal permissions (140,150) for this instance of the content’s
`doWnload (160). When the content is executed by the
`doWnloading principal, its operations are to be authoriZed
`against the current permissions (150). It is possible to extend
`the current permissions (150) by adding permissions that are
`Within the maximal permissions of the content (140).
`FIG. 1 also shoWs that the derivation mechanism is
`executed by a Permission Derivation Server (170). This
`server (170) can be run on the doWnloading principal’s
`system or on a server machine trusted by the doWnloading
`principal (e.g., a secure server in Which messages are
`communicated to the doWnloading principal’s system via a
`secure channel).
`
`Petitioner Apple Inc. - Ex. 1049, p. 14
`
`

`
`6,044,466
`
`5
`As FIG. 2 depicts, the derivation mechanism (100) con
`sists of the following ?ve steps: (1) create a derivation
`instance (200) for this content description (120) and down
`loading principal (110); (2) retrieve the current and maximal
`permissions propositions (210) from the site security policy
`(130) for the derivation instance (160); (3) derive the
`maximal permissions (150) from the contributions of each
`principal in the maximal permission proposition (220); (4)
`obtain the current permissions contributions (230) delegated
`by each principal in the current permission proposition
`(300), as illustrated in FIG. 3; and (5) compute the current
`and maximal permissions (140,150,240) using the current
`and maximal permissions propositions (300,310) and the
`current and maximal contributions (230,220) of the propo
`sitions’ principals. The current permissions (150), by
`de?nition, must always be a subset of the maximal permis
`sions (140).
`The description of executable content (120) is a set of
`attribute-value pairs. One possible embodiment is RDF
`(“Resource Description Framework”) labels that describe
`the meta-data of a website’s URI (“Universal Resource
`Identi?er”). RDF is a Web Consortium Activity (see
`http://www.w3.org/metadata/RDF/overview.html).
`Attributes with string values can be used to describe a URI.
`Table 1 shows attributes used in a preferred embodiment
`for the content description (120). This is a modi?cation of
`the content description structure used by FlexxGuard (see N.
`Islam et al., A Flexible Security System for Using Internet
`Content, in IEEE Software, pgs. 52—59, September, 1997).
`
`TABLE 1
`
`Content Description Attributes
`
`@ Description Field
`
`De?nition
`
`121 Manufacturer
`
`122 Description Author
`
`123 Application Classes
`
`124 Application Name
`125 Version
`126 Requested Permissions
`
`127 Content Digest
`
`128 Application Role
`
`Content’s originating
`manufacturer
`Principal responsible
`for the description
`Application types
`to which the
`content belongs
`Application name
`Content version
`Permissions
`requested by the content
`A cryptographic
`digest of the content
`Role of content in
`the application
`
`The content is created by its manufacturer (121). The
`content description (120) is authenticated to be from the
`description author (122). The description author (122) can
`be different from the manufacturer (121), but the derivation
`mechanism (100) may limit the permissions granted (140,
`150) based on the site security policy’s (130) trust in the
`description author (122). The application classes (123) indi
`cate the types of applications to which this content belongs.
`The application name (124) and version (125) specify the
`name and version of the content. The content’s crypto
`graphic digest (127) enables veri?cation that the content
`description (120) refers to the expected content. In a pre
`ferred embodiment, a one-way, collision-free hash function
`(see National Institute of Standards and Technology, US.
`Department of Commerce, Secure Hash Standard, Publica
`tion FIPS PUB 180-1) is used to generate such digests. The
`application role (128) speci?es the principal that the content
`assumes from the application’s perspective.
`Content descriptions (120) should be cryptographically
`authenticated (i.e., integrity and source veri?cation) or sent
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`over a trusted communication link prior to use. In a preferred
`embodiment, public key cryptography is used to verify the
`integrity and source of content descriptions (120). Two
`additional ?elds are added to the description (120): (1) a
`?eld that contains a list of signatures and (2) a ?eld that
`contains a list of public key certi?cates. The certi?cates
`enable the veri?cation of any of the contained signatures.
`FIG. 3 shows the site security policy (130). It includes sets
`of policy graphs (320) used to derive the maximal permis
`sions contributions (150) that any principal can delegate to
`the content and sets of permissions propositions (300,310)
`used to compute the current and maximal permissions
`(140,150) from the maximal permissions contributions (150)
`and the current permissions contributions delegated by those
`principals.
`FIG. 3 also shows the structure of a policy graph (320). A
`policy graph consists of a directed graph (324), a traversal
`method (322), a combination method (323), an access con
`trol list (325), and a downloading principal to whom the
`graph applies (321). The directed graph (324) stores the
`security policy speci?c to the speci?ed downloading prin
`cipal (321). The traversal method (322) determines how the
`directed graph (324) is traversed (e.g., from a root down or
`from a leaf up) when it is evaluated. The combination
`method (323) determines how the node’s entries (430) are
`combined into the resultant policy value. The access control
`list (325) limits access to the policy graph (320). Principals
`can be permitted to modify any of the policy graph attributes
`(321—325).
`As shown in FIG. 4, the nodes (400) of a policy graph’s
`(320) directed graph (324) consist of an attribute (410), a
`value (420), an entry (430), and an access control list (440).
`The traversal method uses the node attribute (410) and node
`value (420) to match the node with the content’s description
`(120). If a match occurs, then the combination method (323)
`applies the node entry (430) to the current result derived so
`far from the policy graph traversal (810). In a preferred
`embodiment, node entries (430) refer to permissions. The
`access control list (440) controls access to the node. In a
`preferred embodiment, principals can be permitted to read,
`write, delete, and create children of the node.
`In the directed graph (324) shown in FIG. 4, an example
`traversal method (322) speci?es that traversal starts at the
`root of the directed graph (324) and repeatedly follows the
`child link whose node’s (400) attribute (410) value (420) is
`the same as the content description’s (120) value for that
`attribute. An example combination method (323) is the
`union set operator. A traversal method (322) that goes from
`the root (400) to the manufacturer=IBM node (401) to the
`description author=IBM (402) to the application classes=
`games node (403) results in the permissions (580) PA U PB
`PC.
`Note that Netscape content shares the same node at the
`application type level of the policy graph as the IBM content
`in our example. Therefore, the resulting permissions (580)
`for a content description (120) of manufacturer=Netscape
`(121), description author=Netscape (122), and application
`classes=games (123) is PA U PN PC.
`The permissions structure (330) in a preferred embodi
`ment is shown in FIG. 5. Permissions (330) include positive
`(550) and negative rights (560) and transforms (570). Rights
`associate an object group (551) with a set of operations that
`are permitted or denied (552) and a limit for the number of
`times this permission may be used (553). In authoriZation, if
`a positive right (550) exists that grants an operation on an
`object and a negative right (560) exists that precludes the
`operation on that object, then the operation is not authoriZed.
`
`Petitioner Apple Inc. - Ex. 1049, p. 15
`
`

`
`6,044,466
`
`7
`That is, positive rights (550) are always superseded by
`negative rights (560). Object groups (551,561) may refer to
`logical objects and be mapped to physical objects at runtime
`to permit the same speci?cation to cover multiple principals.
`Transforms (570) associate a delegating principal’s (571)
`action (e.g., operation) (572) With modi?cations to permis
`sions (573) (e.g., addition or removal of rights). For a
`transform (570) to apply, the rights to be delegated must be
`Within the delegating principal’s (571) maximal permissions
`contribution (140) for the delegatee’s content. Also, the
`delegated rights must be Within the maximal permissions
`(140) of the delegatee’s content. Transforms (570) enable
`the current permissions (150) to evolve based on the state of
`the application.
`The permissions propositions (300,310) describe hoW the
`current and maximal permissions (140,150) are derived
`from the contributions from multiple contributing principals.
`In a preferred embodiment, set operations (e.g., union,
`intersection) (301,311) are used to combine the permissions
`contributed by the contributing principals (110) and con
`straint propositions (302,312) imply the addition or removal
`(e.g, implication of positive or negative rights) of permis
`sions.
`A derivation instance (160) maintains the state of the
`derivation. Its structure is shoWn in FIG. 6. A derivation
`instance (160) maps a content description (120) and doWn
`loading principal (110) to its current and maximal permis
`sions (140,150) given a site security policy (130). Other
`?elds can be added to maintain the state of the derivation.
`Mechanism Description
`As shoWn in FIG. 7, step 1