United States Patent [19]
`Apperson et al.
`
`[54] SYSTEM AND METHOD FOR SAFETY
`DISTRIBUTING EXECUTABLE OBJECTS
`
`[75] Inventors: Norman Apperson, Bellevue; Brian C.
`Beckman, Renton, both of Wash.
`
`[73] Assignee: Microsoft Corporation, Redmond,
`Wash.
`
`[21] Appl. No.: 08/639,290
`_
`[22]
`Filed:
`Apr. 25, 1996
`
`Int. Cl.6 .............................. .. H04K 1/00; H04L 9/00
`[51]
`[52] US. Cl. ................................................. .. 380/25; 380/4
`[58] Fleld 0f Search ................................ .. 380/25, 221, 253,
`380/4’ 39 /1 7
`
`[56]
`
`References Cited
`Us‘ PATENT DOCUMENTS
`
`4,868,877
`9/1989 Fischer .................................... .. 380/25
`5,005,200
`4/1991 Fischer ..
`.... .. 380/25
`572147702
`5/1993 Fischer __
`__ 380/25
`5,311,591
`5/1994 Fischer ..
`380/4
`5’412’717
`5/1995 Escher "
`"" " 380/25
`5,412,774
`5/1995 Agrawal
`395/157
`5 692 047 11/1997 McManiS __
`380/4
`5,745,574
`4/1998 Muftic ..... ..
`380/25
`5,825,877 10/1998 Dan 6181. ..............................
`380/25
`
`OTHER PUBLICATIONS
`
`Schneier, Bruce, “Applied Cryptography, Second Edition:
`Protocols, Algorigthms, and Source Code in C,” (1996), pp.
`574—577.
`
`US005978484A
`Patent Number:
`Date of Patent:
`
`[11]
`[45]
`
`5,978,484
`Nov. 2, 1999
`
`Bank, Joseph A., “Java Security,” (Dec. 8, 1995), found at
`Internet URL http://sWissnet.ai.mit.edu/~jbank/javapaper/
`javapaper'htmu'
`
`P '' ima" y Examiner—Benjamin R- Fuller
`Assistant Examiner—Robin Clark
`Attorney, Agent, or Firm—Lee & Hayes, PLLC
`
`[57]
`
`ABSTRACT
`
`The invention includes a method and system for distributing
`and executing executable code, Before sending executable
`Code to a Client, a distributing authority associates a privi_
`lege request code With the executable code. The privilege
`request code indicates a requested set of privileges that the
`executable code Wlll potentially exercise during execution.
`The distributing authority digitally signs the executable code
`and associated privilege request Code and then distributes it
`_
`_
`_
`for eventual execution by clients. Before executing the
`executable code, a client veri?es the digital signature to
`con?rm the authenticity and integrity of the executable code
`_
`_
`_
`_
`_
`_
`and associated privilege request code. This veri?cation
`utiliZes a hierarchy of certifying authorities. While the code
`executes, the client monitors it and prevents it from exer
`cising privileges that are not in the requested set of privi
`leges.
`
`20 Claims, 4 Drawing Sheets
`
`ESTABLISH
`HIERARCHY
`
`02
`I
`
`03
`I
`
`ASS/6N PRIV/LEGE
`AUTHORIZATION
`CODES
`
`
`
`O4 I
`
`
`
`06 I
`
`CREA TE DIGITAL
`CERT/FICA TES
`
`CR54 TE
`OBJECT
`
`08
`1
`
`ASSOC/A TE PRIVILEGE
`RE OUES T CODE
`
`1 IO
`
`SIGN EXECUTABLE CODE,
`DATA, AND PRIVILEGE
`REQUEST CODE
`
`I
`
`SEND EXECUTABLE
`OBJECT
`
`RECEIVE OBJECT
`AND VERIFY
`DIGITAL SICNA TURE
`0E DISTRIBUTING
`A U THORI TY
`
`CERTIFY
`DISTRIBUTING
`A UTHORI TY
`
`118
`
`VERIFY PRIV/L E GE
`RE OUE S T CODE
`
`VERIF/CA TION?
`
`I 22
`
`EXECUTE
`XECUIABLE COD
`
`I26
`
`MONITOR
`EXECUTION
`
`l
`
`724
`REi/E C T
`E XE CU TABL E
`CODE
`
`Symantec 1021
`IPR of U.S. Pat. No. 8,677,494
`
`000001
`
`

`
`U.S. Patent
`
`Nov. 2, 1999
`
`Sheet 1 of4
`
`5,978,484
`
`r
`
`f 12
`I \
`
`16
`/
`DA TA
`PROCESSOR “/
`;___2
`
`,—_\ l8
`MEMORY _//
`EXECUTABLE
`OBJECT
`
`70
`
`f
`
`f 14
`'
`w
`
`,_____\ 22
`DA TA
`/
`PROCESSOR ‘/
`a.‘
`
`(__—“ 24
`MEMORY _//
`APPLICATION
`PROORAM
`
`26
`2O
`9 \—__—J
`
`COMPUTER
`sERvER
`
`CLIENT
`COMPUTER
`
`L
`
`J
`
`\
`
`J
`
`20
`WW %
`/
`EXECUTABLE CODE
`4/30
`
`DATA
`
`#/32
`
`PR/V/LEGE REOuEsr CODE J /34
`
`S/GNA TURE
`
`i /‘36
`
`CREDENT/ALS
`
`’ /38
`
`000002
`
`

`
`U.S. Patent
`
`Nov. 2, 1999
`
`Sheet 2 of4
`
`5,978,484
`
`42
`
`CERTIFY/N6
`AUTHORITY
`CA R00 T
`
`CE I? TIFYING
`AU THORI TY
`CA 1
`
`42
`
`CE RTIFY/NG
`AU THORI TY
`
`CERT IFYING
`AU T HORITY
`CA 2
`
`CERTIFY/N6‘
`AU THOR/ TY
`
`/0\
`/
`\
`/ /
`
`42
`
`CE R TIFY/NG
`AU THORI TY
`
`CERT IFYING
`AU THORI TY
`
`/ \
`/
`\
`/ /
`
`/ \
`/
`\
`/ /
`
`l/ 44
`DISTRIBUTING
`AU THOR/ TY
`
`l/ 44
`DISTRIBUTING
`AU THORI TY
`DA 3
`
`/ A \
`/
`\
`
`/
`
`\
`
`CLIENT
`COMPUTER
`
`000003
`
`

`
`U.S. Patent
`
`Nov. 2, 1999
`
`Sheet 3 of4
`
`5,978,484
`
`/ 60
`
`HOLDER '5 ID
`
`HOLDER'S PUBLIC ENCRYPTION KEY
`
`ISSUE DA TE
`
`E X PIRA T ION DA TE
`
`ISSUER'S ID
`
`HOLDER 'S PRIVATE
`AUTHORIZATION CODE
`
`ISSUER'S CERTIFICATE
`
`SIGNATURE BY ISSUER
`
`62
`
`64
`
`66
`
`68
`
`70
`
`72
`
`77
`
`74
`
`000004
`
`

`
`U.S. Patent
`
`Nov. 2, 1999
`
`Sheet 4 0f 4
`
`5,978,484
`
`ESTABLISH
`HIE RARCHY
`
`ASS/GN PRIV/LE GE
`AU T HOR/ZA TION
`CODES
`
`I04
`
`4
`CREA TE DIGITAL
`CERT/FICA TE S
`
`v
`
`106
`
`C REA TE
`OBJECT
`
`I74
`
`RECEIVE OBJECT
`AND VERIFY
`DIGITAL SIGNA TURE
`OF DISTRIBUTING
`AU THORI TY
`
`"
`
`776
`
`CE R T/FY
`DISTRIBUTING
`AU THORI TY
`
`778
`
`VERIFY PRIVIL E GE
`RE OUE S T CODE
`
`120
`
`VE RIF ICA T/ON? NO
`
`724
`REJE C T
`EXECUTABLE
`CODE
`
`/ I O8
`
`YES
`
`[ASSOC/A TE PRIVILEGE]
`
`RE OUES T CODE
`
`/1IO
`s/c/v EXECUTABLE 00b5,
`DA TA, AND PR/V/LEGE
`REQUEST 0005
`
`I
`
`772
`
`SEND EXECUTABLE
`OBJECT
`
`EXECUTE
`EXECUTABLE COD
`
`MON/TOR
`EXECUTION
`
`000005
`
`

`
`1
`SYSTEM AND METHOD FOR SAFETY
`DISTRIBUTING EXECUTABLE OBJECTS
`
`TECHNICAL FIELD
`
`This invention relates to client-server environments in
`Which executable objects are downloaded or otherWise dis
`tributed from a distributing authority and executed on a
`different computer.
`
`BACKGROUND OF THE INVENTION
`
`There has been a dramatic increase in reliance upon
`service providers accessible via electronic data communi
`cations netWorks such as the Internet. Such service providers
`are generally interested in providing access to the Widest
`possible client audience at the loWest cost. Very recently, a
`number of solutions have emerged that alloW service pro
`viders to achieve these goals. In particular, there has been
`very rapid groWth in the use of the standardiZed hypertext
`capabilities of the World Wide Web
`on the Internet.
`The standardiZed nature of the WWW, as Well as the very
`loW costs involved in accessing the Internet, have eliminated
`many of the previous hurdles to service development and
`distribution.
`While the Internet’s World Wide Web and other similar
`environments alloW service providers to build systems that
`can efficiently deliver information to potentially large num
`bers of clients, they also impose limitations. These limita
`tions are a direct consequence of the desire to provide a
`simple, generic processing model for multiple purposes.
`It has been recogniZed that these limitations can be
`addressed to some degree by alloWing servers to send
`executable code to clients, for execution by the clients
`themselves. This alloWs a server to build client softWare for
`a speci?c purpose, thereby alloWing the service provider to
`add functionality to existing client softWare. An advantage
`of this approach is that it can in many cases reduce both the
`processing burdens on the server and the communications
`requirements betWeen the server and the client.
`While it might be very desirable for a client to execute
`server-provided softWare, the potential threat to security is a
`serious draWback. For a client to be Willing to execute
`server-de?ned functionality, the client must be assured that
`no adverse effects Will occur. Speci?cally, there must be a
`guarantee that existing client data Will not be read or
`modi?ed and that hostile code (viruses, Trojan horses, etc.)
`Will not be generated and installed on the client system.
`This is particularly problematic in the public netWork
`environment since mechanisms for establishing trust
`betWeen a client and server are not Widely deployed, and
`data communications channels are open to eavesdropping
`and tampering. Because of this, general purpose compiled
`programming languages are not a solution. It is inherently
`unsafe in a public netWork environment for a client to accept
`binary executable images from a server and execute them.
`Since the server-provided programs Would have access to
`the full resources of the client computer environment, they
`could potentially perform any of various different types of
`dangerous or hostile operations.
`Binary executable code also has the disadvantage of being
`architecture-speci?c. It is a signi?cant complication for the
`server to determine the computer hardWare in use by the
`client and the operating system, and to provide different
`executable modules for use With different systems.
`These issues lead naturally to consideration of an inter
`preted language. This approach alloWs a server to create
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`5,978,484
`
`2
`program scripts that can be executed on the client to extend
`its functionality, While providing a more controlled execu
`tion environment and architecture neutrality. Interpreters can
`be implemented on a variety of computer platforms and
`operating systems to provide an isolation layer betWeen the
`language speci?cation and the underlying architecture.
`Hence, a server can provide scripts for extensions that are
`executable on a variety of client machines. Interpreters can
`also perform runtime checking of various sorts to enforce
`access of speci?c resources and to detect When scripts have
`been tampered With. Sun Microsystem’s recently announced
`Java language is an example of this approach.
`From a client’s perspective, the optimal situation is one in
`Which it needs only trust the interpreter. Once a client has an
`interpreter from a trusted source, the client should be able to
`execute any script With complete safety. This is Where
`existing approaches fail. Java, for example, is a general
`purpose programming environment Which alloWs the gen
`eration of complex applications including I/O operations.
`Java is speci?cally designed to alloW easy access to netWork
`facilities, hence it has the potential to surreptitiously trans
`mit client con?dential information; destroy client data, and
`perform other hostile actions. The protection against such
`behavior relies on the ability to validate Java scripts and
`determine their authenticity. Importantly, hoWever, Java and
`many other systems rely on a trust relationship betWeen the
`server and the client as the basis for their safety. We believe
`that this is a signi?cant limitation Which our invention
`addresses.
`In addition to eliminating the requirement of a trust
`relationship betWeen the client and server, our invention
`provides for situations in Which a client may Wish to execute
`server-provided code that performs I/ O and other potentially
`dangerous operations. Our invention provides a secure
`extension mechanism that enables servers to doWnload
`general purpose executables With full client validation of
`their origin and authenticity.
`
`SUMMARY OF THE INVENTION
`
`The invention classi?es different types of security-related
`operations and services, Which might potentially be per
`formed by externally-provided code, into different catego
`ries. When providing executable code, a distributing author
`ity also provides a privilege request code, indicating a set of
`privileges or privilege categories that the executable code
`might perform on the client machine. The distributing
`authority digitally signs the executable code and the privi
`lege request code, and also provides a certi?cate that can be
`traced by the client to a knoWn certifying authority. The
`certi?cate indicates an authoriZed set of privileges that the
`distributing authority has been authoriZed to include in
`distributed code.
`The certi?cate is issued to the distributing authority by a
`certifying authority that is a member of a hierarchy of
`authorities. The certi?cate is signed by the certifying
`authority, and includes or refers to the certi?cate of an even
`higher certifying authority. Each certi?cate therefore relies
`for its veri?cation upon a higher certifying authority, except
`for a root authority that is knoWn to be trustWorthy.
`Each certi?cate indicates an authoriZed set of privileges
`that the holder of the certi?cate is authoriZed pass on to
`loWer members of the hierarchy. When a distributing author
`ity distributes actual executable code, the associated privi
`lege request code must indicate a subset of the privileges
`indicated by the privilege authoriZation code of the certi?
`cate held by the distributing authority. Before executing
`
`000006
`
`

`
`5,978,484
`
`3
`code provided from some external source such as a server,
`the client traces the authority of the distributing authority
`that signed the code, through one or more certifying authori
`ties to one that is knoWn to the client independently of the
`server. For each certifying authority, the client veri?es that
`the privilege authoriZation code indicates privileges that are
`a subset of the privileges indicated by the certi?cate of the
`next-higher certifying authority.
`If the client veri?es the signature and digital certi?cate of
`the distributing authority by tracing to an authority that is
`already knoWn to the client, the client executes the provided
`code. HoWever, it monitors the code, and prevents it from
`exercising any privileges that are not indicated in the asso
`ciated privilege request code.
`In practice, the client creates a granted privilege set for a
`particular executable object, and prevents the object from
`exercising any privileges not in the granted privilege set.
`The granted privilege set is preferably created by intersect
`ing the privilege authoriZation sets from the digital certi?
`cate of the distributing authority and of any higher authori
`ties encountered While tracing the certi?cate of the
`distributing authority. Any failure While checking the author
`ity of the distributing authority results in an empty granted
`privilege set. Every executable statement in the executable
`object is then checked against the granted privilege set
`before execution.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a block diagram of a computer system in
`accordance With the invention.
`FIG. 2 is a block diagram of an executable object in
`accordance With the invention.
`FIG. 3 is a block diagram of a hierarchy of authorities in
`accordance With the invention.
`FIG. 4 is illustrates an example of a digital certi?cate in
`accordance With the invention.
`FIG. 5 is a How chart shoWing preferred methodical steps
`in accordance With the invention.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`The invention described beloW utiliZes Well-knoWn digi
`tal encryption and signing techniques. The folloWing dis
`cussion therefore assumes familiarity With these topics. For
`example, the invention utiliZes public-key cryptography
`techniques such as described in Schneier, Bruce; Applied
`Cryptography Second Edition: Protocols, Algorithms, and
`Source Code in C; NeW York: John Wiley & Sons, 1996,
`Which is hereby incorporated by reference. Particularly, the
`invention utiliZes the RSA (Rivest, Shamir, and Adlemen)
`public-key algorithm for digital signatures, in conjunction
`With a hashing algorithm referred to as SHA (secure hash
`algorithm), although other public-key signature schemes,
`such as DSS, ElGamal, Elliptic Curve, can alternatively be
`used.
`FIG. 1 shoWs a computer system 10 in accordance With a
`preferred embodiment of the invention. Computer system 10
`includes a computer server 12 and a client computer 14.
`Computer server 12 includes a data processor 16, a
`computer-readable storage medium or memory 18, and other
`components (not shoWn) typical of a computer netWork
`server. Memory 18 includes both electronic and magnetic or
`optical mass storage memory.
`Computer server 12, in this case also referred to as a
`distributing authority, is con?gured to provide or distribute
`
`4
`one or more signed executable objects 20 for execution by
`client computer 14. An object 20 is initially stored by server
`12 in memory 18. Computer server 12 is connected to
`doWnload such executable objects to client computer 14
`over a communications channel or link, such as a local area
`netWork connection, a Wide area netWork connection, or a
`remote connection from an online service provider. The
`executable objects comprise both executable code and asso
`ciated data. The code might be in the form of textual scripts,
`byte codes, P-code, or binary object code.
`Client computer 14 is similarly connected to doWnload
`and execute executable objects 20 from the computer server.
`Client computer 14 includes a processing unit or data
`processor 22 and memory 24. Memory 24 includes elec
`tronic and optional mass-storage memory such as a magnetic
`or optical storage medium. Client computer 14 includes
`other components (not shoWn) such as are commonly incor
`porated in a personal or desktop computer.
`An application program 26 executes on data processor 22
`from memory 24. The application program in the preferred
`embodiment of the invention is a client program that inter
`acts With computer server 20. As an example, application
`program 26 might be a “broWser” application such as is
`commonly used to access resources on a public netWork
`such as the Internet or on a private “intranet.” The client
`program is con?gured to accept and execute executable code
`provided by computer server 20.
`FIG. 2 shoWs preferred components of executable object
`20. The object includes executable code 30, associated data
`32, a privilege request code 34, a digital signature 36, and
`digital credentials 38.
`Privilege request code 34 is a code that indicates a set of
`security-related privileges that executable code 30 of object
`20 Will potentially execute on client 14. The facilities of the
`client operating system or script interpreter are divided up
`into a set of privileges or privilege classes. In the WindoWs
`NT® operating system for example, these privilege classes
`might relate individually to ?le I/O, netWork operations,
`registry read/Write rights, graphics operations, WindoW
`management, and user list read/Write rights. The privilege
`request code indicates Which of these classes of services are
`potentially required by executable code 30.
`Digital signature 36 is a digital signature of the concat
`enated executable code, data, and privilege request code
`from the executable object 20. More particularly, this is an
`RSA-encrypted SHA-hash of the concatenated executable
`code, data, and privilege request code. This signature can be
`veri?ed by a client computer to con?rm the authenticity and
`integrity of the executable code, data, and associated privi
`lege authoriZation code. As Will be explained more fully
`beloW, the digital signature has the further important prop
`erty that it can be veri?ed Without relying on the trustWor
`thiness of server 12.
`Credentials 38, associated With the server computer or
`distributing authority, include a privilege authoriZation code
`indicating Which privileges or privilege classes are alloWed
`to be exercised by code distributed from server 12 or another
`distributing authority. The credentials are issued to server 12
`or to a distributing authority by one or more certifying
`authorities and are digitally signed by the certifying authori
`ties. The digital signature of at least one of the certifying
`authorities can be veri?ed by the client Without relying on
`the trustWorthiness of the server or other distributing
`authority, as Will be demonstrated beloW.
`The certifying authorities are responsible for verifying the
`trustWorthiness of the distributing authority that provided
`
`15
`
`35
`
`45
`
`55
`
`65
`
`000007
`
`

`
`5,978,484
`
`5
`the executable code and the level of trust that should be
`placed in the executable code and distributing authority.
`More speci?cally, the certifying authorities determine Which
`privileges any particular server or distributing authority
`should be alloWed to authoriZe. For instance, a certifying
`authority might issue credentials to one distributing author
`ity alloWing it to distribute code that exercises a full range
`of security-related privileges on a client computer, While the
`executable code from another distributing authority might be
`precluded from performing ?le I/O.
`Note that in the case shoWn in FIG. 1, server 12 is a
`distributing authority. While this con?guration has
`advantages, executable code might be signed by a distrib
`uting authority that is independent of the actual server that
`provides the code to client 14. In fact, the distribution path
`from a distributing authority to a client computer might take
`many forms. In the example shoWn, the distribution path is
`a netWork connection formed betWeen a server (acting as the
`distributing authority) and a client of the server. In other
`cases, the executable code might be distributed by ?oppy
`disk or some other portable storage medium from a distrib
`uting authority to a user’s computer. In still other cases, the
`executable code might be provided to various online servers
`from the distributing authorities, and users Would obtain the
`executable code from the servers. In each of these cases, the
`executable code and associated privilege request code Would
`be signed by the distributing authority, even though the code
`might be obtained by a user from an entity that has no direct
`connection to the distributing authority—such as an inde
`pendent online service provider. In this latter, case, the
`online service provider Would act as a code repository,
`Without participating directly in security measures. Thus,
`While the service provider might not Wish to participate in
`the security scheme described herein, a client computer
`could nevertheless rely on the veri?able digital signature of
`the distributing authority to establish the trustWorthiness of
`the executable code.
`The certifying authorities and distributing authorities are
`members of a hierarchy of authorities as shoWn in FIG. 3.
`The members of the hierarchy have different levels of
`authority, depending on their positions in the hierarchy and
`the privileges granted them by higher levels of the hierarchy.
`The structure of the hierarchy resembles a tree structure,
`With a “root” member at the top connected to loWer “leaf”
`members by “branches.” This “tree of trust” is utiliZed to
`verify signatures of distributing authorities and certifying
`authorities, and to verify the authority of a distributing
`authority to distribute code With a particular privilege
`request code.
`At the top of the hierarchy is a “root” certifying authority
`40, also designated CAROOT. This entity has authority over
`all possible privileges that an executable object might poten
`tially exercise. Beneath the root are different levels of
`certifying authorities 42, including a plurality of distributing
`authorities 44. Each certifying authority has authority over
`a potentially different set of privileges.
`Each certifying authority and distributing authority is
`assigned a privilege authoriZation code by the next-higher
`certifying authority in the hierarchy. The privilege authori
`Zation code of any particular authority indicates a set of
`privileges that can be authoriZed by that authority. In
`addition, the privilege authoriZation code indicates Whether
`an entity is authoriZed to certify loWer members of the
`hierarchy and Whether the entity is authoriZed to act as a
`distributing authority. The privilege authoriZation code held
`by any particular entity must indicate a subset of the
`privileges indicated by the privilege authoriZation code of
`the next-higher authority.
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`In general, any certifying authority can also act as a
`distributing authority. When acting as a certifying authority,
`an entity grants or assigns privilege authoriZation codes to
`loWer members of the hierarchy. The granted privilege
`authoriZation codes must indicate a subset of the privileges
`indicated by the certifying authority’s oWn privilege autho
`riZation code. When acting as a distributing authority, an
`entity distributes executable objects that include privilege
`request codes. Each such privilege request code must indi
`cate a subset of the privileges indicated by the distributing
`authority’s privilege authoriZation code.
`With this structure, each loWer level of authority in the
`hierarchy potentially has less and less authority for granting
`privileges to other members of the hierarchy or for distrib
`uting executable objects.
`In the example of FIG. 3, a client computer 46 receives an
`executable object from a distributing authority 44 designated
`as DA3. The executable object is signed by DA3 and
`includes the privilege authoriZation code of DA3. Distrib
`uting authority DA3, in turn, receives its privilege authori
`Zation code from a certifying authority CA2; DA3’s privilege
`authoriZation code is a subset of CA2’s privilege authoriZa
`tion code. CA2 receives its privilege authoriZation code from
`a higher certifying authority CA1, and CA1 receives its
`privilege authoriZation code from the root certifying author
`ity CAROOT. CAROOT has a privilege authoriZation code that
`includes all possible privileges that might be exercised by
`executable objects.
`To enforce this scheme, the authority of each certifying
`authority and distributing authority is recorded in a digital
`certi?cate, issued and signed by the next higher member of
`the hierarchy. The credentials discussed above comprise
`such a digital certi?cate.
`FIG. 4 shoWs an example of a digital certi?cate 60. It
`includes an identi?cation 62 of the holder of the certi?cate,
`the public encryption key 64 of the holder, the date 66 the
`certi?cate Was issued, the date 68 of its expiration, the
`privilege authoriZation code 72 authoriZed for the holder of
`the certi?cate by the certifying authority that issued the
`certi?cate, and an identi?cation 70 of the certifying author
`ity that issued the certi?cate (at the next higher level of the
`hierarchy). It also includes or refers to the certi?cate 71 of
`the certifying authority. Certi?cate 60 is digitally signed by
`the certifying authority, using the private signature key of
`the certifying authority. The digital signature 74 of the
`certifying authority is appended to and becomes part of the
`certi?cate.
`The certi?cate of the root certifying authority is slightly
`different in that it does not include the certi?cate or digital
`signature of any higher authority. Its privilege authoriZation
`code indicates all possible privileges.
`This scheme results in a chain of digital certi?cates
`leading from a distributing authority all the Way up the
`hierarchy to the root certifying authority. The chain of
`certi?cates can be traced upWard through the hierarchy until
`reaching the certi?cate of an authority Whose digital signa
`ture can be veri?ed Without relying on information obtained
`from the distributing authority.
`Referring back to FIG. 3, assume that distributing author
`ity DA3 doWnloads or otherWise provides a signed execut
`able object that is eventually executed by client computer
`46. The object includes credentials of distributing authority
`DA3, comprising a digital certi?cate as described above. The
`digital certi?cate includes the public signing key of distrib
`uting authority DA3, alloWing client computer 46 to verify
`the digital signature performed by distributing authority
`
`000008
`
`

`
`5,978,484
`
`7
`DA3 on the executable code and the privilege request code.
`The digital certi?cate also indicates information relating to
`the certifying authority CA2 that issued the certi?cate,
`including the certi?cate of certifying authority CA2.
`The certi?cate of distributing authority DA3, issued and
`signed by nexthigher certifying authority CA2, veri?es or
`con?rms the public signing key and the privilege authori
`Zation code of distributing authority DA3. The signature and
`privilege authority of certifying authority CA2 can in turn be
`veri?ed through information in CA2’s digital certi?cate,
`issued by certifying authority CA1.
`NoW suppose that certifying authority CA1 is knoWn to
`the client computer, independently of the executable object.
`If this is the case, client computer 46 can verify the certi?
`cate of certifying authority CA2 Without tracing any farther
`up the hierarchy. That is, client computer 46 Will knoW the
`public signing key of certifying authority CA1, indepen
`dently of the doWnloaded executable object, and Will thus be
`able to verify that CA1 signed the digital certi?cate of
`certifying authority CA2. Client computer 46 can rely on the
`knoWn trustWorthiness of certifying authority CA1 to con
`?rm the trustWorthiness (and digital signature) of CA2, and
`can then rely on the trustWorthiness of CA2 to con?rm the
`trustWorthiness (and digital signature) of CA3.
`Any certi?cate (except the certi?cate of the root authority)
`can be traced to a higher authority by folloWing the chain of
`digital certi?cates up the hierarchy. As used here, the term
`“tracing” refers to the process of folloWing a chain of digital
`certi?cates up through a hierarchy of authorities, While
`verifying the signature and authority of any particular mem
`ber of the hierarchy With reference to a certi?cate that is
`digitally signed and authoriZed by a higher level of the
`hierarchy.
`The invention includes a method as illustrated in FIG. 5
`of distributing and executing executable objects or code. The
`method includes a ?rst step 102 of establishing a hierarchy
`of authorities comprising a plurality of certifying authorities,
`including the root authority, and a plurality of distributing
`authorities. The members of the hierarchy are preferably
`computers connected for communications over a netWork or
`other communications medium.
`The method includes a step 103 of assigning a privilege
`authoriZation code to each member of the hierarchy. The
`privilege authoriZation code of any particular member of the
`hierarchy indicates a set of privileges that the particular
`member is authoriZed to incorporate in executable objects
`that might be provided from that member for execution on
`other computers. In addition, the privilege authoriZation
`code indicates the maximum set of privileges that member
`can include in the assigned privilege authoriZation codes of
`other, loWer members of the hierarchy. According to this
`scheme, the privilege authoriZation code of any member is
`assigned to that member by a higher member of the
`hierarchy, and indicates a subset of the privileges indicated
`in the privilege authoriZation code of the higher member.
`Step 104 includes creating and signing a digital certi?cate
`for each member of the hierarchy, Wherein the certi?cate of
`any particular member (except that of the root authority)
`includes or refers to the digital certi?cate of that higher
`member. This results in a chain of certi?cates and corre
`sponding digital signatures, as already described, that can be
`used for certifying the trustWorthiness and authority of any
`particular member of the hierarchy. The digital certi?cate of
`a member also includes the privilege authoriZation code for
`that member, assigned to that member by a higher member
`of the hierarchy.
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`8
`A step 106, performed by a distributing authority that is
`a member of the hierarchy of authorities, comprises creating
`an executable object as shoWn in FIG. 2. The object includes
`executable code and optional data, as Well as signed cre
`dentials of the distributing authority. In the preferred
`embodiment of the invention, the credentials comprise the
`digital certi?cate of the distributing authority, formatted as
`shoWn in FIG. 4.
`Step 108, also performed by the distributing authority,
`comprises associating a privilege request code With the
`executable code and the optional data. The privilege request
`code indicates a requested set of privileges that the execut
`able code Will potentially exercise on a client computer
`during execution. The requested set of privileges is a subset
`of the authoriZed set of privileges indicated the distributing
`authority’s credentials.
`A step 110 comprises digitally signing the executable
`code, any associated data, and the associated privilege
`request code. This step is performed by the distributing
`authority, using its private signing key. Speci?cally, the
`distributing authority produces an SHA hash of the concat
`enated executable code, data, and privilege request code, and
`encrypts the hash using an RSA encryption algorithm in
`conjunction With the distributing authority’s private signing
`key.
`Step 112 comprises sending or otherWise distributing the
`executable object, including the privilege request code,
`credentials and digital signature of the distributing authority,
`from the distributing authority to a client computer. This step