Ulllted States Patent [19]
`Dan et al.
`
`USOO5825877A
`[11] Patent Number:
`[45] Date of Patent:
`
`5,825,877
`Oct. 20, 1998
`
`[54] SUPPORT FOR PORTABLE TRUSTED
`SOFTWARE
`
`[75] Inventors: Asit Dan, West Harrison; Rajiv
`Ramaswami, Ossining; Dinkar
`Sitaram, Yorktown Heights, all of NY.
`
`[73] Assignee: International Business Machines
`Corporation, Armonk, NY.
`
`[21] APPL NO. 661,517
`
`[22]
`
`Filed;
`
`Jun, 11, 1996
`
`6
`[51] Int. Cl. ...................................................... .. H04L 9/00
`[52]
`380/4; 380/23; 380/25
`[58] Field of Search ................................... .. 380/23, 25, 4
`
`[56]
`
`References Cited
`
`Us PATENT DOCUMENTS
`
`5,005,200
`5,283,830
`
`4/1991 Fischer .................................... .. 380/30
`2/1994 Hinsley et al. ..
`.... .. 380/25
`
`5,412,717
`
`5/1995 Fischer . . . . . . . . . . . .
`
`. . . . . . .. 380/4
`
`5,450,593
`
`9/1995 Howell et a1. ........................ .. 395/650
`
`Primary Examiner—Thomas H. TarcZa
`Assistant Examiner—Carmen D. White
`Attorney, Agent, or Firm—Heslin & Rothenberg, PC;
`Richard M, Ludwin, Esq,
`
`ABSTRACT
`[57]
`A form of authentication is provided Wherein a trusted third
`party signs a certi?cate to identify the author of a program
`and to secure its integrity. The program code is encapsulated
`or otherWise associated With the certi?cate and an access
`control list (ACL). The access control list describes the
`permissions and resources required by the code. An enforce
`ment mechanism Which allocates system permissions and
`resources in accordance With the ACL. In a preferred
`embodiment, a Code production System Communicates With
`a certi?cation agency, Which is a trusted third party. The
`Certi?cation agency issues a Certi?cate for the Code and a
`certi?cate for the access list of that code. Once the certi?cate
`is issued it is not possible for any party to modify the code
`or access list Without invalidating the certi?cate. The code
`and its ACL, along With their certi?cates are stored on a
`server. A ‘client’ doWnloading the code or access list can
`verify the integrity of the code/ access list and the system can
`enforce the access list such that the permissions and
`resources are not exceeded
`
`20 Claims, 8 Drawing Sheets
`
`10?
`
`CODE PRUDUCTIUN
`SYSTEM
`
`140?
`
`CERTIFICATE (CODE)
`
`ACL
`
`CODE
`
`All
`L
`15o
`
`CODE, CERTIFICATE (CODE)
`ACL, CERTIFICATE (ACL)
`
`CERTIFICATE [ACU
`
`CODE
`CERTIFICATION
`AGENCY
`
`5
`15
`
`301
`
`sERvER
`L
`20
`
`CODE
`5
`14°
`
`7150
`ACL
`
`vERIFIER
`
`PERMISSION
`FLAGS
`L
`16°
`
`CODE, CERTIFICATE (CCTIE)
`ACI, CERTIFICATE IACI)
`
`ACI ENFOHCEH
`ACL MANACER
`1805
`CLIENT SYSTEM
`L130
`
`000001
`
`Symantec 1006
`IPR of U.S. Pat. No. 6,154,844
`
`Patent Owner Finjan, Inc. - Ex. 2002, p. 1
`
`

`

`U.S. Patent
`
`0a. 20, 1998
`
`Sheet 1 of8
`
`5,825,877
`
`FIG. 1
`
`101
`
`CODE RRTTTIUCTICN
`SYSTEM
`
`140?
`
`CERTIFICATE (CODE)
`
`ACL
`
`CODE
`
`“1
`L
`15o
`
`CCITE, CERTIFICATE (CODE)
`ACL, CERTIFICATE (ACL)
`
`CERTIFICATE (ACE)
`
`CITITE
`CERTTEICATIoN
`AGENCY
`
`5
`15
`
`30?
`
`sERvER
`L
`20
`
`CODE
`5
`“0
`
`W50
`ACL
`
`vERIEIER
`
`PERMISSIUN
`FLAGS
`L
`16°
`
`CODE, CERTIFICATE (CODE)
`ACL, CERTIFICATE (ACL)
`
`ACL ENECRCER
`
`ACL NANACER
`
`1505
`
`CLIENT SYSTEM
`
`L 130
`
`000002
`
`Patent Owner Finjan, Inc. - Ex. 2002, p. 2
`
`

`

`U.S. Patent
`
`0a. 20, 1998
`
`Sheet 2 of8
`
`5,825,877
`
`01
`
`
`22222228 2 + was 5+5
`$5255 _ _ :10:
`
`
`
`
` 5% % _ Os “r ........... I- i .............. IEMEL"
`
`
`
`wag ?wm?
`
`
`
`o: a; “ $22; 2 5:52 52 M O a 5 w
`
`_ W
`
`
`
` 02 “o2 7 as _ .
`
`H u n
`
`2 m E _
`
`U j ............................... i.
`
`55m? 3&5.
`
`“WEE/é Emma 35%. was,‘ V252. 3%
`mamamwm 515 ~
`
`, m:
`
`N M q m
`
`n L n
`
`£22251 “ 02 m
`02 E256 maxim 2 m
`
`
`
`000003
`
`Patent Owner Finjan, Inc. - Ex. 2002, p. 3
`
`

`

`U.S. Patent
`
`0a. 20, 1998
`
`Sheet 3 of8
`
`5,825,877
`
`F I 6 . 3
`
`200 \‘
`
`PHYSICAL
`RESOURCE
`MAME 205
`
`REsUURcE
`AIIRIRUIE
`210
`
`MAXIMUM
`CUNSUMP.
`RAIE 215
`
`SPACE
`
`I/U
`
`DISK
`
`DISK
`
`MEMURY
`
`CPU
`
`100/5
`
`50 MIPS
`
`MAXIMUM
`AMUUMI
`220
`
`100 MB
`
`10 MB
`
`8 MB
`
`1 SEC
`
`250 \
`LOGICAL
`PARAMETER
`RESOURCE
`LIST
`NAME 255
`260
`
`OPEN
`
`BIND
`
`\
`
`IMI 102A-$MAXIMI
`
`I
`I
`
`255
`f’
`sIR/tmp/*. $APPLEI_UIR/*
`, sIR PW
`
`*
`STH$DB/
`
`5TH r
`
`I
`'
`PARMIYPE 270
`
`PARM.vAL.275
`
`nextPE 280
`
`l
`
`000004
`
`Patent Owner Finjan, Inc. - Ex. 2002, p. 4
`
`

`

`U.S. Patent
`
`0a. 20, 1998
`
`Sheet 4 of 8
`
`5,825,877
`
`FIG. 4
`
`300 \
`
`ACTUAL
`CONSUMP.
`HATE 325
`
`AcIUAI
`USE
`330
`
`PHYSICAL
`RESOURCE
`NAME 305
`
`RESOURCE
`ATTHIBUTE
`310
`
`MAXIMUM
`CONSUMP.
`RATE 315
`
`SPACE
`
`I/0
`
`DISK
`
`DISK
`
`MEMORY
`
`CPU
`
`100/5
`
`50 MIPS
`
`MAxIMUM
`AM0UMI
`320
`
`100 MB
`
`10 MB
`
`0 MB
`
`1 SEC
`
`350 N
`
`LOGICAL
`RESOURCE
`NAME 355
`
`PARAMETER
`LIST
`360
`
`OPEN
`BIND
`
`\
`
`K. 305
`
`sIM/tmp?‘. $APPLET_DIR/*
`STR PW
`
`I
`'
`sIM$UB/*
`STE 0
`
`YES
`
`N0
`
`IMI I02A-$MAxIMI
`I
`YES
`'
`
`PAHM.TYPE 370
`
`PAHM.VAL.375
`
`nextPE 300
`
`ALLOW 305
`
`k
`
`CODE sIAMI TIME 395
`
`000005
`
`Patent Owner Finjan, Inc. - Ex. 2002, p. 5
`
`

`

`U.S. Patent
`
`0a. 20, 1998
`
`Sheet 5 of8
`
`5,825,877
`
`F I 6 . 5
`
`CHECK ROUTINE
`
`LOCATE NUMBER
`OF PARAMETERS,
`FUNCTION NAME
`
`415
`
`LOCATE
`FIRST RPE TABLE
`ENTRIES?
`
`LOCATE FIRST
`PARAMETER
`
`- GET NEXT ACL
`
`VALUE OF
`PARAMETER ALLOWED
`BY RPE?
`
`430
`
`MORE PARAMETERS?
`
`GET NEXT PARAMETER
`
`L
`
`455 1
`
`NO
`
`yA70
`
`1
`FAILURE
`-
`
`000006
`
`Patent Owner Finjan, Inc. - Ex. 2002, p. 6
`
`

`

`U.S. Patent
`
`0a. 20, 1998
`
`Sheet 6 0f 8
`
`5,825,877
`
`FIG.
`
`6
`
`525
`I
`
`527
`
`FAILURE
`
`535
`
`EXIT
`
`AMOUNT REOUESTED
`+ CURRENTLY USED > MAX.
`ALLOWED D NOT
`BLANK?
`
`YES
`
`510
`I
`COMPUTE RATE R FOR
`THIS CONSUMPTION
`REOUEST
`
`530
`I
`COMPUTE TIME WHEN
`CONSUMPTION
`WILL BE ALLOWED
`
`ALLOW CONSUMPTION
`
`55D
`
`AFTER
`CONSUMPTION
`
`UPDATE CONSUMPTION
`PARAMETERS
`
`000007
`
`Patent Owner Finjan, Inc. - Ex. 2002, p. 7
`
`

`

`U.S. Patent
`
`0a. 20, 1998
`
`Sheet 7 of 8
`
`5,825,877
`
`FIG. 7
`
`install_code:
`
`Receive program code, AOL and encrypted hash;
`Decrypt using third party's public key.
`Compute hash from code and ACL;
`if computed_hash not equal decrypted_hash then
`Reject code;
`exit;
`invoke ACL manager;
`
`Insert ' traps in code to verify_access whenever
`resource is accessed;
`Execute modified code;
`verify_access:
`
`Invoke ACL enforcer;
`If access permitted then
`continue;
`else if access delayed then
`delay program;
`else if access rejected then
`suspend program;
`
`E
`i
`I
`r
`
`FIG. 8
`
`If newly received code then
`Store code and ACL on disk;
`Display ACL for program;
`while more client input do
`read client input;
`Modify appropriate permission flags;
`dStore modified permission flags on disk;
`en
`
`000008
`
`Patent Owner Finjan, Inc. - Ex. 2002, p. 8
`
`

`

`U.S. Patent
`
`0a. 20, 1998
`
`Sheet 8 of8
`
`5,825,877
`
`FIG. 9
`
`check_logical_res_access:
`
`Locate HPE entries for this logical resource;
`while more HPE entries do
`while more parameters do
`if access to parameter not allowed then
`goto getNextRPE;
`
`end
`return access allowed;
`getNextHPE: get next RPE;
`en
`return access rejected;
`
`check JlhYSlCGlJ‘BSjCCBSSI
`
`Locate RPHT entry for this physical resource;
`if Max_allowed non-blank and amt .requested + used >
`max allowed then
`return access rejected;
`Computed projected consumption rate;
`if projected consumption rate > max. consumption
`rate then
`Compute required delay;
`1 return access delayed and required delay;
`e se
`return access allowed;
`
`000009
`
`Patent Owner Finjan, Inc. - Ex. 2002, p. 9
`
`

`

`1
`SUPPORT FOR PORTABLE TRUSTED
`SOFTWARE
`
`BACKGROUND OF THE INVENTION
`
`a. Field of the Invention
`The present invention relates generally to delivery of
`software through distribution systems such as netWorks.
`b. Related Art
`Software distribution is a major industry currently. Soft
`Ware is today distributed over diskettes, CDROMs and
`increasingly, over netWorks. In addition to simply doWn
`loading code from remote sites over the Internet, today
`clients can doWnload and run applets from servers, a para
`digm proposed in the Java programming language or in
`other languages such as Telescript.
`A signi?cant concern With code obtained from elseWhere
`is that of security. For example, in the Unix operating
`system, the code Will run in the client’s shell With all the
`client’s privileges, including access to all his ?les, as Well as
`possibly send mail, attempt illegal break ins etc. Java
`attempts to solve this problem for applets by running applets
`in a very restrictive environment. As a result, the usefulness
`and functionality of Java applets is limited. Java applications
`on the other hand rely on the security provided by the
`operating system and do not come With any degree With
`authentication. They thus pose the same security problems
`as any other code.
`A form of authentication is proposed in “Trusted Distri
`bution of SoftWare Over the Internet”, A. D. Rubin, Internet
`Society Symposium on NetWork and Distributed Security,
`1995. Here a trusted third party signs a certi?cate to identify
`the author of a program and to secure its integrity. While this
`alloWs a client to verify the authenticity of the code, it does
`not specify a ?exible set of permissions associated With the
`code nor does it provide an automated method for the client
`to enforce these permissions.
`
`SUMMARY OF THE INVENTION
`In vieW of the foregoing, the present invention provides a
`form of authentication Wherein a trusted third party signs a
`certi?cate to identify the author of a program and to secure
`its integrity. The program code is encapsulated or otherWise
`associated With the certi?cate and an access control list
`(ACL). The access control list describes the permissions and
`resources required by the code. The invention also provides
`an enforcement mechanism Which allocates system permis
`sions and resources in accordance With the ACL.
`In a preferred embodiment, a code production system
`communicates With a certi?cation agency, Which is a trusted
`third party. The certi?cation agency issues a certi?cate for
`the code and a certi?cate for the access list of that code.
`Once the certi?cate is issued it is not possible for any party
`to modify the code or access list Without invalidating the
`certi?cate. The code and its ACL, along With their certi?
`cates are stored on a server. A client doWnloading the code
`or access list can verify the integrity of the code/access list
`and the system can enforce the access list such that the
`permissions and resources are not exceeded.
`
`1O
`
`15
`
`25
`
`35
`
`45
`
`55
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 shoWs a block-diagram vieW of a code delivery and
`certi?cation system according the preferred embodiment of
`the invention;
`FIG. 2 shoWs hoW the different parts of the client system
`operate together to perform the functions described in the
`embodiment.
`
`65
`
`5,825,877
`
`2
`FIG. 3 shoWs the access control list (ACL);
`FIG. 4 shoWs the data structures used by the ACL
`enforcer;
`FIG. 5 shoWs hoW logical resource permissions are
`enforced by the ACL enforcer;
`FIG. 6 shoWs hoW physical resource limits are enforced
`by the ACL enforcer;
`FIG. 7 shoWs the pseudocode for the integrity veri?cation,
`execution and enforcement initialiZation operations of the
`client system;
`FIG. 8 shoWs the pseudocode for the ACL manager; and,
`FIG. 9 shoWs the pseudocode for the ACL enforcer.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`
`FIG. 1 shoWs a block-diagram vieW of a code delivery and
`certi?cation system according to a preferred embodiment of
`the invention. It includes of one or more code production
`systems (CPS) 10, a certi?cation agency (CA) 15, one or
`more servers 20 and one or more client systems 30. The
`client systems can be coupled to the servers by Way of a
`conventional Wide Area NetWork
`or by Way of a
`Local Area NetWork
`The CPS has a piece of
`program code (code) 140 and an access list (ACL) 150 for
`that code that it Wishes to get certi?ed by the certi?cation
`agency. The CA provides a public key K that is Widely
`available and knoWn to the client system. In addition the CA
`has a private key P that only it knoWs. To provide a
`certi?cate for the code the CA creates a certi?cate containing
`the code name and the cryptographic hash of the code and
`signs it using his private key. The certi?cate cannot noW be
`changed Without invalidating the CA’s signature. Similarly
`the CA creates and signs another certi?cate for the ACL
`associated With that code (if desired there could be a single
`certi?cate for both the code and its access list). In the
`embodiment of FIG. 1, the client systems receive the
`certi?cate, the ACL and the code by Way of the WAN or
`LAN. It should be understood, hoWever, that the client
`systems can also or alternatively receive certi?ed code by
`Way of a removable storage media read by local importation
`device such as a ?oppy or optical disk drive.
`The client system shoWn in FIG. 2 includes a veri?er 110,
`ACL manager 130, executor 170, ACL enforcer 180 and a
`client interface 190. The client system also includes a
`conventional CPU and associated control logic 192, a com
`munication controller/netWork interface 194, a CD-ROM
`and/or ?oppy disk subsystem 196 and other resources such
`as netWork access modules, a display subsystem and various
`special purpose adapters. Those of skill in the art Will
`recogniZe that the client system includes a number of
`additional, conventional components Which Will not be
`described in detail here.
`The ACL manager 130 and the ACL enforcer 180 are
`preferably embodied as program code, the operation of
`Which is described in more detail beloW. The executer is a
`conventional part of the client’s operating system (not
`shoWn) Which is used to execute the imported code on the
`client system. The client interface 190 can be embodied as
`a front of screen graphical user interface Which provides the
`client communication With the ACL manager (e. g. it enables
`the client to tell the ACL manager 130 to alloW or disalloW
`or control program access to speci?ed resource). The veri?er
`110 is preferably embodied as program code including a
`decryption module Which is used to verify the authenticity of
`the imported code, including the access control list. The
`
`000010
`
`Patent Owner Finjan, Inc. - Ex. 2002, p. 10
`
`

`

`3
`veri?er also includes a hashing module Which checks the
`integrity of the imported code and ACL.
`Upon downloading the code/ACL and its certi?cate (100),
`the veri?er (110) ?rst checks to see if the CA’s signature on
`the certi?cate is valid (using CA’s knoWn public key). The
`veri?er then computes the cryptographic hash of the code/
`ACL and veri?es that it matches the value in the certi?cate.
`If the signature is not valid or the hash does not match, the
`code and ACL are rejected (120). If the veri?cation is ok, the
`ACL manager (130) is invoked. The ACL manager displays
`the ACL (described beloW) to the client via the client
`interface (190) and ascertains Whether the client Wishes to
`alloW or disalloW the individual items in the ACL. The ACL
`manager stores the code (140) as directed by the client via
`the client interface and stores the ACL (150) together With
`permission ?ags (160).
`The resources that can have their access controlled by the
`ACL enforcer include both logical resources such as ?le
`systems speci?c ?les and system calls, as Well as physical
`resources including such things as the disk space, disk
`access, main memory allocation and access to various sys
`tem controllers and adapters. For access to logical resources
`(client system facilities), the permission ?ags 160 indicate
`Whether individual items are alloWed or not; for access to
`physical resources, the permission ?ags can be used to
`indicate the maximum alloWable quantity or rate of con
`sumption.
`FIG. 2 also shoWs hoW the different parts of the client
`system operate together. In a multi-user client system, each
`user may have their oWn set of permission ?ags. The ACL
`may also contain environment variables; changing the envi
`ronment variables during execution alloWs individual users
`to customiZe the access privileges. The ACL and permission
`?ags are stored in a secure area; reading or updating this area
`is a privilege enforced by the ACL enforcer (180).
`The ACL manager may be invoked at any time by the
`client to display or change the permissions of an ACL. The
`code is run by the executor (170). Before alloWing access to
`any resource, the executor invokes the ACL enforcer for
`checking the validity of the access. This is achieved by the
`executor 170 inserting traps in the code to a veri?cation
`routine that invokes the ACL enforcer. The operation of the
`ACL enforcer is described in more detail later.
`The system enables the code and its ACL to be doWn
`loaded separately or together as needed. For instance, the
`CPS may Want to provide the ACL free of charge to all
`clients but charge for the actual code.
`FIG. 3 shoWs the access control list. The ACL consists of
`tWo parts: the Physical Resources Table (PRT) 200 contain
`ing the physical resources required by the code and the
`Logical Resources Table (LRT) 250 containing the permis
`sions and logical resources required by the code.
`The PRT 250 contains a roW for each resource containing
`the physical resource name (PRN) 205, the resource attribute
`210, the maximum consumption rate 215 and the maximum
`amount 220. The resource attribute 210 is used When a
`physical device or resource disk has multiple attributes, such
`as space and number of I/Os for storage devices. The
`maximum consumption rate 215 and the maximum amount
`220 are the maximum alloWable consumption rate and
`maximum alloWable consumption of the resource and
`attribute respectively.
`The LRT 250 contains a roW for each call to an external
`routine required by the code (referred to as a logical
`resource). Each roW contains the logical resource name
`(LRN) 255, and a parameter list 260 that points to a list of
`
`45
`
`55
`
`65
`
`5,825,877
`
`10
`
`15
`
`25
`
`35
`
`4
`parameter entries. Each parameter entry 265 speci?es a set
`of valid parameter ranges; ie a set of values for each
`parameter that are valid in combination, together With a ?eld
`nextPE 280 that points to the next parameter entry. The
`parameter range for each parameter contains tWo ?elds—the
`parameter type 270 and the parameter value 275 that speci
`?es the valid range for that parameter. For string parameters,
`the parameter type 270 is STR and the parameter value 275
`is a list of regular expression that specify valid forms for the
`string. For integer parameters, the parameter type 270 is INT
`and the parm. value 275 is a list of integer ranges. The parm.
`value 275 may include the names of environment variables,
`in Which case the environment variable is assumed to
`contain a value Which is substituted at run time.
`The ACL enforcer in the client ensures that the permis
`sions and resources speci?ed in the ACL for the code are
`provided and no additional permissions/resources are
`alloWed.
`The ACL enforcement may be static or dynamic. In static
`enforcement, the enforcement can be done fully before the
`code is executed and no enforcement is required While the
`code is running. In dynamic enforcement, the enforcement
`must be performed While the code is being executed. If the
`CA itself veri?es the ACL and guarantees that they Will not
`be exceeded by the code, then the ACL enforcement function
`may not be required in the client system.
`FIG. 4 shoWs the data structures used by the ACL
`enforcer. The Runtime Physical Resources Table (RPRT)
`300 contains a roW for each resource. The resource name
`300, resource attribute 310, maximum consumption rate 315
`and maximum amount 320 are copies of the corresponding
`?elds from the PRT 200. The actual consumption rate 325
`and the actual use 330 ?elds are used to keep track of the
`actual consumption rate and the actual consumption,
`respectively, of the code during run time. The Runtime
`Logical Resource Table (RLRT) 350 contains a roW for each
`required logical resource. The RLRT is a copy of the LRT,
`With an additional ?ag that indicates for each valid combi
`nation of parameters, Whether the combination is alloWed by
`the ACL manager or not. The Logical Resource Name 355
`is a copy of the corresponding ?elds of the LRT 250 and the
`parameter list 360 points to a list of runtime parameter
`entries (RPE) 365. The parameter type 370, parameter value
`375 values of the runtime parameter entries are copies of the
`corresponding ?elds in the LRT. The nextPE 380 points to
`the next runtime parameter entry 365 and the alloW 385 ?eld
`may be set to YES or NO indicating Whether this runtime
`parameter entry 365 is alloWed or not. The ACL enforcer
`also keeps track of the code start time 395.
`FIG. 5 shoWs hoW logical resource permissions are
`enforced by the ACL enforcer. This path is invoked When
`ever the code makes a call to an external function. In step
`410, the ACL enforcer locates the number of parameters,
`their values, and the name of the function being invoked.
`The exact method for doing this is implementation depen
`dent; for example, in Java, these are located on the operand
`stack. In step 415, the ACL enforcer locates the roW for this
`function in the RLRT 350 and locates the ?rst RPE 365 With
`alloW set to YES. If the function name is not found, or there
`is no such RPE 365, the ACL enforcer proceeds to step 455
`Where it exits indicating that the call is not alloWed. In step
`420, the ACL enforcer locates the value of the ?rst parameter
`and makes that the current parameter. In step 425, the ACL
`enforcer checks if the value of the current parameter is
`alloWed by the RPE 365. If the value is alloWed, the ACL
`enforcer checks in step 430 if there are more parameters. If
`there are, in step 435 the ACL enforcer sets the current
`
`000011
`
`Patent Owner Finjan, Inc. - Ex. 2002, p. 11
`
`

`

`10
`
`15
`
`25
`
`5
`parameter to the next parameter and returns to step 425. If
`no more parameters are found in step 430, the ACL enforcer
`proceeds to step 450 and returns With an indication that the
`call is allowed.
`If the test for alloWability fails in step 425, the ACL
`enforcer proceeds to step 445 Where it checks the RLRT 350
`to ?nd another RPE 365 With allow 385 set to YES. If there
`is no such RPE, the ACL enforcer proceeds to step 455 and
`exits indicating that the call is not alloWed. If there is such
`an RPE 365, the ACL enforcer proceeds to step 420.
`FIG. 6 shoWs hoW physical requirements are enforced by
`the ACL enforcer. The ACL enforcer is invoked in step 500
`before allocating the resource. TWo parameters, the amount
`of the resource requested (REQAMT) and the estimated
`time of consumption (COMPT) are provided. For disk I/O,
`the REQAMT is the amount of disk I/O and the COMPT is
`the estimated time for the I/O to complete. In step 505, the
`ACL enforcer locates the roW in the RPRT 300 for this
`resource and checks Whether the maximum amount 320 is
`speci?ed and the actual use 330 plus REQAMT exceeds the
`maximum amount 320. If so, it returns a failure in step 527
`indicating that the consumption is not alloWed. If the maxi
`mum amount 320 is not exceeded, in step 510 the ACL
`enforcer computes the projected consumption rate of this
`resource as (Actual use 330 +REQAMT)/(current time—
`code start time 395+COMPT). In step 515, the ACL enforcer
`checks to see if the maximum consumption rate 315 is
`speci?ed and if the projected consumption rate is greater
`than the maximum consumption rate 315. If the maximum
`consumption rate 315 is not speci?ed or the projected
`consumption rate is not greater, the ACL enforcer returns
`With an indication that the consumption is alloWed. If the
`projected consumption rate is greater, the ACL enforcer in
`step 530 computes the required delay for performing this
`operation as (actual use 300+REQAMT)/maximum con
`sumption rate 315-(current time-code start time 395
`COMPT) and returns the required delay With an indication
`that the consumption has to be delayed for the computed
`delay.
`In step 550, the ACL enforcer is invoked after the con
`sumption of the resource With a parameter specifying the
`amount of resource consumed (CONSAMT). The ACL
`enforcer then updates the actual consumption rate 325 and
`the actual use 330.
`It is also possible for different users to be allocated
`different resources and permissions in the recipient system
`for the same code. This can be done either at the time the
`code is installed, by the ACL manager by looking at the
`privileges given to the different users and combining that
`With the resources and permissions alloWed to the code. In
`this case the set of resources and permissions for each user
`Would have to be stored separately. During code execution
`the resources and permissions Would be enforced on a
`per-user basis. Alternatively the resources and permissions
`55
`can be determined during execution of the code by the ACL
`enforcer by looking at the privileges given to the different
`users and combining that With the resources and permissions
`alloWed to the code.
`FIG. 7 shoWs the pseudocode for the integrity veri?cation,
`execution and enforcement initialiZation operations of the
`client system. It should be understood that the various tables,
`lists ?ags and other data structures described herein are
`instantiated in the memory of the client system (eg in
`volatile random access memory, disk or a combination of
`65
`both). As previously discussed, the ACL enforcer and ACL
`manager are preferably embodied as program code Which is
`
`35
`
`45
`
`5,825,877
`
`6
`linked or incorporated into the operating system of the client
`system. FIG. 8 shoWs pseudocode for the ACL manager.
`FIG. 9 shoWs pseudocode for the ACL enforcer.
`NoW that the invention has been described by Way of the
`preferred embodiment, various modi?cations and improve
`ments Will occur to those of skill in the art. Thus, it should
`be understood that the preferred embodiment has been
`provided as an example and not as a limitation. The scope of
`the invention is de?ned by the appended claims.
`We claim:
`1. A method for distributing program code comprising the
`steps of providing to a recipient system a trusted third party
`certi?cation, the trusted third party certi?cation including a
`computer readable description of resources and permissions
`required for veri?ed nonharmful operation of the code,
`Wherein the description of resources required includes data
`describing both a quantity of at least one resource to be used
`by the code and a maximum rate of consumption of at least
`one resource by the code.
`2. The method of claim 1 Wherein the providing com
`prises the step of encapsulating the certi?cation With the
`program code.
`3. The method of claim 1 comprising the further steps of
`reading the certi?cation by the recipient system; and, allo
`cating resources and permissions of the recipient system so
`as not to exceed the permissions speci?ed in the certi?ca
`tion.
`4. The method of claim 2 comprising the further steps of
`denying or granting the code access and permissions to
`resources of the recipient system in further accordance With
`user selected options associated With the certi?cation.
`5. The method of claim 1 Wherein the computer readable
`description of resources and permissions is provided to the
`recipient system in an encrypted form.
`6. The method of claim 1 Wherein the certi?cation further
`includes encrypted veri?cation data and Wherein the recipi
`ent system decrypts the veri?cation data to verify the
`integrity of the description of the resources and permissions.
`7. The method of claim 3 Wherein the description of
`permissions required includes data describing speci?c facili
`ties of the recipient system to be accessed by the code.
`8. The method of claim 1 Wherein the third party certi?
`cation includes a description of the functionality of the code
`as veri?ed by the third party.
`9. The method of claim 1 Wherein the program code is an
`applet doWnloaded from a server as a program object.
`10. The method of claim 1 Wherein different users are
`allocated different resources and permissions in the recipient
`system for the same code.
`11. The method of claim 10 Wherein the set of resources
`and permissions alloWed to different users is determined
`during installation of the code.
`12. The method of claim 10 Wherein the set of resources
`and permissions alloWed to different users is determined
`during execution of the code.
`13. A method for distributing program code comprising
`the steps of:
`providing a recipient system With an encrypted trusted
`third party certi?cation of the program code, the trusted
`third party certi?cation being encapsulated With the
`program code and including a computer readable
`description of resources and permissions required for
`veri?ed non-harmful operation of the code;
`reading the certi?cation by the recipient system:
`determining the integrity of the certi?cation by the recipi
`ent system; and,
`only after the integrity has been veri?ed,
`
`000012
`
`Patent Owner Finjan, Inc. - Ex. 2002, p. 12
`
`

`

`5,825,877
`
`7
`allocating resources and permissions of the recipient
`system in accordance With user selected options so as
`not to exceed the permissions speci?ed in the certi
`?cation; and,
`executing the program code in accordance With the
`allocating,
`Wherein the description of resources required includes
`data describing both a quantity of at least one
`resource to be used by the code and a maximum rate
`of consumption of at least one resource by the code
`and Wherein the description of permissions required
`includes data describing speci?c facilities of the
`recipient system to be accessed by the code.
`14. A computing system, comprising:
`an importation device for importing programs and data
`into the computing system;
`an operating system for controlling the operation of the
`computing system;
`access logic for extracting from the data and associating
`With a given program a computer readable description
`of resources required for veri?ed non-harmful opera
`tion of the given program, the access logic further
`including integrity checking logic for generating veri
`?cation data indicative of the integrity of the computer
`readable description; and,
`enforcement logic coupled to the operating system and
`responsive to the veri?cation data for tracking and
`allocating for at least one resource consumption and
`consumption rate Within the recipient system so as
`not to exceed the allocation speci?ed in the descrip
`tion for the given program; and,
`
`10
`
`15
`
`25
`
`8
`a processor for executing the given program in accor
`dance With the allocating.
`15. The system of claim 14 further including a data
`structure stored in a random access memory and coupled to
`the enforcement logic, the data structure including at least a
`?rst ?eld for tracking actual resources consumed and a
`second ?eld for tracking rate of consumption of the
`resources, a third ?eld for storing a limit on resource
`consumption derived from the description and a fourth ?eld
`for storing limit on the rate of consumption of the resource
`derived from the description.
`16. The system of claim 14 Wherein the access manager
`includes means for de-encapsulating the description from a
`package including the program code and means for decrypt
`ing the description.
`17. The system of claim 14 further Wherein the enforce
`ment logic includes means for denying or granting the code
`access and permissions to resources of the computing sys
`tem in further accordance With user selected options asso
`ciated With the description.
`18. The method of claim 1 comprising the further step of
`delaying operation of the code by the recipient system to
`conform to the maximum rate of consumption.
`19. The method of claim 13 comprising the further step of
`delaying operation of the code by the recipient system to
`conform to the maximum rate of consumption.
`20. The computing system of claim 14, Wherein the
`enforcement logic includes means for delaying operation of
`the given program to conform to the consumption rate.
`
`*
`
`*
`
`*
`
`*
`
`*
`
`000013
`
`Patent Owner Finjan, Inc. - Ex. 2002, p. 13
`
`