66/6~/L0
`llll llll lllll lllll lllll 11111111111111111
`·
`, - OJ.a • s • n tL9:::>~
`i4
`This is a request for filing a PROVISIONAL APPLICATION under 37 C.F.R. § l.53(e.)'
`
`PROVISIONAL PATENT APPLICATION cover sheet
`
`CERTIFICATE OF EXPRESS MAILING
`I hereby certify that this correspondence is being deposited with the Umted States Postal Services "Express Mail Post Office to Addressee" service under 37 CFR 1.10, in an
`envelope addressed to: Assistant Commissioner for Patents, Washington, D.C. 20231 on July 29 1999.
`. ~ ~~
`Express Mail Label No. EL133803643US
`S1gned:_~---r1---r-----~---------(cid:173)
`Roger Yamamoto
`
`EL 13 3 8 a 3 b 4 3 us
`
`Docket No.
`
`07 451.6005-00000
`
`Type a plus sign(+)
`inside this box ...
`
`+
`
`INVENTOR(S)/APPLICANT(S)
`
`LAST NAME
`
`SIBERT
`
`MIDDLE INITIAL
`
`RESIDENCE (City & Either State or Foreign Country)
`
`FIRST NAME
`w
`TITLE OF THE INVENTION (280 characters max.)
`
`OLIN
`
`Lexington, MA
`
`SYSTEMS AND METHODS FOR USING CRYPTOGRAPHY TO PROTECT SECURE AND INSECURE COMPUTING ENVIRONMENTS
`
`CORRESPONDENCE ADDRESS
`
`FINNEGAN, HENDERSON, FARA.BOW, GARRETT & DUNNER, L.L.P.
`1300 I Street, N.W.
`Washington, D.C. 20005
`Telephone No.: (202) 408-4000
`
`ENCLOSED APPLICATION PARTS (check all that apply)
`
`181 J;specification consisting of 43 pages.
`o ; ii( Small Entity Statement
`• 181 " Drawing( s)
`;:,.;Number of Sheets: 28 sheets of drawings (Figs. 1-22B)
`181 :::';other (specify): 17 pages of claims (71 claims) and 1 page of Abstract
`
`METHOD OF PAYMENT (check one)
`o ;,~ check or money order is enclosed to cover the Provisional filing fees.
`181 ;'};he Commissioner is hereby authorized to charge filing fees and credit Deposit
`'~ccount Number 06-0916.
`
`PROVISIONAL
`FILING FEE
`181 $150.00
`
`The invention was made by an agency of the United States Government or under a contract with an agency of the United States
`Government.
`rill No.
`D Yes, the name of the U.S. Government agency and
`
`July 29, 1999
`·~~~~~~;J,,,.hc~;;;;:-==::-Y&te:
`+--'~=...p::...o.,.,="""-----'Registration No.:-=2=6.,,.0.::.1..:.4 _ _ _
`
`o Additional inventors are being named on separately numbered sheets attached hereto.
`
`PROVISIONAL APPLICATION FILING ONLY
`
`Page 1 of 90
`
`GOOGLE EXHIBIT 1019
`
`

`

`SYSTEMS AND METHODS FOR USING CRYPTOGRAPHY TO PROTECT
`
`SECURE AND INSECURE COMPUTING ENVIRONMENTS
`
`FIELD OF THE INVENTION
`
`The present invention relates to computer security, and more particularly to secure
`
`5
`
`and/or protected computer execution environments. Still more specifically, the present
`
`invention relates to computer security techniques based at least in part on cryptography,
`
`that protect a computer processing environment against potentially harmful computer
`
`executables, programs and/or data; and to techniques for certifying load modules such as
`
`executable computer programs or fragments thereof as being authorized for use by a
`
`10
`
`protected or secure processing environment.
`
`BACKGROUND AND SUMMARY OF THE INVENTION
`
`Computers have become increasingly central to business, finance and other
`important aspects of our lives. It is now more important than ever to protect computers
`from "bad" or harmful computer programs. Unfortunately, since many of our most
`
`15
`
`critical business, financial and governmental tasks now rely heavily on computers,
`
`dishonest people have a great incentive to use increasingly sophisticated and ingenious
`
`computer attacks.
`
`Imagine, for example, if a dishonest customer of a major bank could reprogram
`
`the bank's computer so it adds to instead of subtracts from the customer's account- or
`
`20
`
`diverts a penny to the customer's account from anyone else's bank deposit in excess of
`$10,000. If successful, such attacks would not only allow dishonest people to steal, but
`could also undermine society's confidence in the integrity and reliability of the banking
`
`system.
`
`1
`
`Page 2 of 90
`
`

`

`Terrorists can also try to attack us through our computers. We cannot afford to
`
`have harmful computer programs destroy the computers driving the greater San Francisco
`
`metropolitan air traffic controller network, the New York Stock Exchange, the life
`
`support systems of a major hospital, or the Northern Virginia metropolitan area fire and
`
`5
`
`paramedic emergency dispatch service.
`
`There are many different kinds of "bad" computer programs, which in general are
`
`termed "Trojan horses"
`
`programs that cause a computer to act in a manner not
`
`intended by its operator, named after the famous wooden horse of Troy that delivered an
`
`attacking army disguised as an attractive gift. One of the most notorious kinds is so-
`
`l O
`
`called "computer viruses" -
`
`"diseases" that a computer can "catch" from another
`
`computer. A computer virus can be a computer program that instructs the computer to do
`
`harmful or spurious things instead of useful things
`
`and can replicate itself to spread
`
`from one computer to another. Since the computer does whatever its instructions tell it to
`
`do, it will carry out the bad intent of a malicious human programmer who wrote the
`
`15
`
`computer virus program -
`
`unless the computer is protected from the computer virus
`
`program. Special "anti-virus" protection software exists, but it unfortunately is only
`
`partially effective -
`
`for example, because new viruses can escape detection until they
`
`become widely known and recognized, and because sophisticated viruses can escape
`
`detection by masquerading as tasks the computer is supposed to be performing.
`
`20
`
`Computer security risks of all sorts -
`
`including the risks from computer viruses
`
`-
`
`have increased dramatically as computers have become increasingly connected to one
`
`another over the Internet and by other means. Increased computer connectivity provides
`
`increased capabilities, but also creates a host of computer security problems that haven't
`
`been fully solved. For example, electronic networks are an obvious path for spreading
`
`25
`
`computer viruses. In October 1988, a university student used the Internet (a network of
`
`computer networks connected to millions of computers worldwide) to infect thousands of
`
`university and business computers with a self-replicating ''worm" virus that took over the
`
`infected computers and caused them to execute the computer virus instead of performing
`
`2
`
`Page 3 of 90
`
`

`

`the tasks they were supposed to perform. This computer virus outbreak ( which resulted
`
`in a criminal prosecution) caused widespread panic throughout the electronic community.
`
`Computer viruses are by no means the only computer security risk made even
`
`more significant by increased computer connectivity. For example, a significant
`
`5
`
`percentage of the online electronic community has recently become committed to a new
`
`"portable" computer language called Java™ developed by Sun Microsystems of
`
`Mountain View, California. Java was designed to allow computers to interactively and
`
`dynamically download computer program code fragments ( called "applets") over an
`
`electronic network such as the internet, and execute the downloaded code fragments
`
`10
`
`locally. The Java programming language's "download and execute" capability is valuable
`
`because it allows certain tasks to be performed locally on local equipment using local
`
`resources. For example, a user's computer could run a particularly computationally or
`
`data-intensive routine
`
`relieving the provider's computer from having to run the task
`
`and/or eliminating the need to transmit large amounts of data over the communications
`
`15
`
`path.
`
`While Java's "download and execute" capability has great potential, it raises
`
`significant computer security concerns. For example, Java applets could be written to
`
`damage hardware, software or information on the recipient computer, make the computer
`
`unstable by depleting its resources, and/or access confidential information on the
`
`20
`
`computer and send it to someone else without first getting the computer owner's
`
`permission. People have expended large amounts of time and effort trying to solve
`
`Java's security problems. To alleviate some of these concerns, Sun Microsystems has
`
`developed a Java interpreter providing certain built-in security features such as:
`a Java verifier that will not let an applet execute until the verifier verifies the
`applet doesn't violate certain rules,
`
`•
`
`25
`
`•
`
`a Java class loader that treats applets originating remotely differently from
`
`those originating locally,
`
`•
`
`a Java security manager that controls access to resources such as files and
`
`network access, and
`
`3
`
`Page 4 of 90
`
`

`

`In addition, Sun has indicated that in the future the Java interpreter may use digital
`
`signatures to authenticate applets.
`
`Numerous security flaws have been found despite these techniques. Moreover, a
`
`philosophy underlying this overall security design is that a user will have no incentive to
`
`5
`
`compromise the security of her own locally installed Java interpreter- and that any such
`
`compromise is inconsequential from a system security standpoint because only the user's
`
`own computer (and its contents) are at risk. This philosophy-which is typical of many
`is seriously flawed in many useful electronic commerce
`
`security system designs -
`
`contexts.
`
`10
`
`Load modules may contain algorithms, data, cryptographic keys, shared secrets,
`
`and/or other information that permits a load module to interact with other system
`
`components (e.g., other load modules and/or computer programs operating in the same or
`
`different protected processing environment). For a load module to operate and interact as
`
`intended, it should execute without unauthorized modification and its contents may need
`
`15
`
`to be protected from disclosure.
`
`Unlike many other computer security scenarios, there may be a significant
`
`incentive for an owner of a protected processing environment to attack his or her own
`
`protected processing environment. For example:
`
`•
`
`the owner may wish to "turn off' payment mechanisms necessary to ensure
`
`20
`
`that people delivering content and other value receive adequate compensation;
`
`or
`
`•
`
`the owner may wish to defeat other electronic controls preventing him or her
`
`from performing certain tasks ( for example, copying content without
`
`authorization); or
`
`25
`
`•
`
`the owner may wish to access someone else's confidential information
`
`embodied within electronic controls present in the owner's protected
`
`processing environment; or
`
`4
`
`Page 5 of 90
`
`

`

`•
`
`the owner may wish to change the identity of a payment recipient indicated
`
`within controls such that they receive payments themselves, or to interfere
`
`with commerce; or
`
`•
`
`the owner may wish to defeat the mechanism(s) that disable some or all
`
`5
`
`functions when budget has been exhausted, or audit trails have not been
`
`delivered.
`
`Security experts can often be heard to say that to competently do their job, they
`
`must "think like an attacker." For example, a successful home security system installer
`
`must try to put herself in the place of a burglar trying to break in. Only by anticipating
`
`10
`
`how a burglar might try to break into a house can the installer successfully defend the
`
`house against burglary. Similarly, computer security experts must try to anticipate the
`
`sorts of attacks that might be brought against a presumably secure computer system.
`
`From this "think like an attacker" viewpoint, introducing a bogus load module is
`
`one of the strongest forms of attack (by a protected processing environment user or
`
`15
`
`anyone else) on the virtual distribution environment. Because load modules have access
`
`to internal protected data structures within protected processing environments and also ( at
`
`least to an extent) control the results brought about by those protected processing
`
`environments, bogus load modules can (putting aside for the moment additional possible
`
`local protections such as addressing and/or ring protection and also putting aside system
`
`20
`
`level fraud and other security related checks) perform almost any action possible in the
`
`virtual distribution environment without being subject to intended electronic controls.
`
`Especially likely attacks may range from straightforward changes to protected data (for
`
`example, adding budget, billing for nothing instead of the desired amount, etc.) to
`
`wholesale compromise (for example, using a load module to expose a protected
`
`25
`
`processing environment's cryptographic keys). For at least these reasons, the methods for
`
`validating the origin and soundness of a load module are critically important.
`
`5
`
`Page 6 of 90
`
`

`

`A variety of techniques can be used to secure protected processing environments
`
`against inauthentic load modules introduced by the computer owner, user, or any other
`
`party, including for example:
`
`• Encrypting and authenticating load modules whenever they are shared
`
`5
`
`between protected processing environments via a communications path
`
`outside of a tamper-resistant barrier and/or passed between different virtual
`
`distribution environment participants;
`
`• Using digital signatures to determine if load module executable content is
`
`intact and was created by a trusted source (i.e., one with a correct certificate
`
`10
`
`for creating load modules);
`
`• Strictly controlling initiation of load module execution by use of encryption
`
`keys, digital signatures and/or tags;
`
`• Carefully controlling the process of creating, replacing, updating or deleting
`
`load modules; and
`
`15
`
`• Maintaining shared secrets (e.g., cryptographic keys) within a tamper resistant
`
`enclosure that the owner of the electronic appliance cannot easily tamper with.
`
`The present invention provides improved techniques for protecting secure
`
`computation and/or execution spaces from unauthorized (and potentially harmful) load
`
`modules or other "executables" or associated data. In accordance with one aspect
`
`20
`
`provided by the present invention, one or more trusted verifying authorities validate load
`
`modules or other executables by analyzing and/or testing them. A verifying authority
`
`digitally "signs" and "certifies" those load modules or other executables it has verified
`
`(using a public key based digital signature and/or certificate based thereon, for example).
`
`Protected execution spaces such as protected processing environments can be
`
`25
`
`programmed or otherwise conditioned to accept only those load modules or other
`
`executables bearing a digital signature/certificate of an accredited ( or particular) verifying
`
`authority. Tamper resistant barriers may be used to protect this programming or other
`
`conditioning. The assurance levels described below are a measure or assessment of the
`
`effectiveness with which this programming or other conditioning is protected.
`
`6
`
`Page 7 of 90
`
`

`

`A web of trust may stand behind a verifying authority. For example, a verifying
`
`authority may be an independent organization that can be trusted by all electronic value
`
`chain participants not to collaborate with any particular participant to the disadvantage of
`
`other participants. A given load module or other executable may be independently
`certified by any number of authorized verifying authority participants. If a load module or
`
`5
`
`other executable is signed, for example, by five different verifying authority participants,
`
`a user will have (potentially) a higher likelihood of finding one that they trust. General
`
`commercial users may insist on several different certifiers, and government users, large
`
`corporations, and international trading partners may each have their own unique "web of
`
`10
`
`trust" requirements. This "web of trust" prevents value chain participants from
`
`conspiring to defraud other value chain participants.
`
`In accordance with another aspect provided by this invention, each load module
`
`or other executable has specifications associated with it describing the executable, its
`
`operations, content, and functions. Such specifications could be represented by any
`
`15
`
`combination of specifications, formal mathematical descriptions that can be verified in an
`
`automated or other well-defined manner, or any other forms of description that can be
`
`'·<:
`
`processed, verified, and/or tested in an automated or other well-defined manner. The
`
`load module or other executable is preferably constructed using a programming language
`
`(e.g., languages such as Java or Python) and/or design/implementation methodology (e.g.,
`
`20 Gypsy, FDM) that can facilitate automated analysis, validation, verification, inspection,
`
`and/or testing.
`
`A verifying authority analyzes, validates, verifies, inspects, and/or tests the load
`
`module or other executable, and compares its results with the specifications associated
`
`with the load module or other executable. A verifying authority may digitally sign or
`
`25
`
`certify only those load modules or other executables having proper specifications -
`
`and
`
`may include the specifications as part of the material being signed or certified.
`
`A verifying authority may instead, or in addition, selectively be given the
`
`responsibility for analyzing the load module and generating a specification for it. Such a
`
`7
`
`Page 8 of 90
`
`

`

`specification could be reviewed by the load module's originator and/or any potential
`
`users of the load module.
`
`A verifying authority may selectively be given the authority to generate an
`
`additional specification for the load module, for example by translating a formal
`
`5 mathematical specification to other kinds of specifications. This authority could be
`
`granted, for example, by a load module originator wishing to have a more accessible, but
`
`verified ( certified), description of the load module for purposes of informing other
`
`potential users of the load module.
`
`Additionally, a verifying authority may selectively be empowered to modify the
`
`10
`
`specifications to make it accurate -
`
`but may refuse to sign or certify load modules or
`
`other executables that are harmful or dangerous irrespective of the accuracy of their
`
`associated specifications. The specifications may in some instances be viewable by
`
`ultimate users or other value chain participants
`
`providing a high degree of assurance
`
`that load modules or other executables are not subverting the system and/or the legitimate
`
`15
`
`interest of any participant in an electronic value chain the system supports.
`
`In accordance with another aspect provided by the present invention, an execution
`
`environment protects itself by deciding -based on digital signatures, for example
`
`which load modules or other executables it is willing to execute. A digital signature
`
`allows the execution environment to test both the authenticity and the integrity of the load
`
`20 module or other executables, as well permitting a user of such executables to determine
`
`their correctness with respect to their associated specifications or other description of
`
`their behavior, if such descriptions are included in the verification process.
`
`A hierarchy of assurance levels may be provided for different protected
`
`processing environment security levels. Load modules or other executables can be
`
`25
`
`provided with digital signatures associated with particular assurance levels. Appliances
`
`assigned to particular assurance levels can protect themselves from executing load
`
`modules or other executables associated with different assurance levels. Different digital
`
`signatures and/or certificates may be used to distinguish between load modules or other
`
`8
`
`Page 9 of 90
`
`

`

`executables intended for different assurance levels. This strict assurance level hierarchy
`
`provides a framework to help ensure that a more trusted environment can protect itself
`
`from load modules or other executables exposed to environments with different work
`
`factors (e.g., less trusted or tamper resistant environments). This can be used to provide a
`
`5
`
`high degree of security compartmentalization that helps protect the remainder of the
`
`system should parts of the system become compromised.
`
`For example, protected processing environments or other secure execution spaces
`
`that are more impervious to tampering (such as those providing a higher degree of
`
`physical security) may use an assurance level that isolates it from protected processing
`
`10
`
`environments or other secure execution spaces that are relatively more susceptible to
`
`tampering (such as those constructed solely by software executing on a general purpose
`
`digital computer in a non-secure location).
`
`A verifying authority may digitally sign load modules or other executables with a
`
`digital signature that indicates or implies assurance level. A verifying authority can use
`
`15
`
`digital signature techniques to distinguish between assurance levels. As one example,
`
`each different digital signature may be encrypted using a different verification key and/or
`
`fundamentally different encryption, one-way hash and/or other techniques. A protected
`
`processing environment or other secure execution space protects itself by executing only
`
`those load modules or other executables that have been digitally signed for its
`
`20
`
`corresponding assurance level.
`
`The present invention may use a verifying authority and the digital signatures it
`
`provides to compartmentalize the different electronic appliances depending on their level
`
`of security ( e.g., work factor or relative tamper resistance). In particular, a verifying
`
`authority and the digital signatures it provides isolate appliances with significantly
`
`25
`
`different work factors
`
`preventing the security of high work factor appliances from
`
`collapsing into the security of low work factor appliances due to free exchange of load
`
`modules or other executables.
`
`9
`
`Page 10 of 90
`
`

`

`Encryption can be used in combination with the assurance level scheme discussed
`
`above to ensure that load modules or other executables can be executed only in specific
`
`environments or types of environments. The secure way to ensure that a load module or
`
`other executable can't execute in a particular environment is to ensure that the
`
`5
`
`environment doesn't have the key(s) necessary to decrypt it. Encryption can rely on
`
`multiple public keys and/or algorithms to transport basic key(s). Such encryption
`
`protects the load module or other executable from disclosure to environments ( or
`
`assurance levels of environments) other than the one it is intended to execute in.
`
`In accordance with another aspect provided by this invention, a verifying
`
`10
`
`authority can digitally sign a load module or other executable with several different
`
`digital signatures and/or signature schemes. A protected processing environment or other
`
`secure execution space may require a load module or other executable to present multiple
`
`digital signatures before accepting it. An attacker would have to "break" each (all) of the
`
`several digital signatures and/or signature schemes to create an unauthorized load module
`
`15
`
`or other executable that would be accepted by the protected processing environment or
`
`other secure execution space. Different protected processing environments (secure
`
`execution spaces) might examine different subsets of the multiple digital signatures -
`
`so
`
`that compromising one protected processing environment ( secure execution space) will
`
`not compromise all of them. As an optimization, a protected processing environment or
`
`20
`
`other secure execution space might verify only one of the several digital signatures (for
`
`example, chosen at random each time an executable is used) -
`
`thereby speeding up the
`
`digital signature verification while still maintaining a high degree of security.
`
`In accordance with yet another aspect provided by the present invention(s), a
`
`tamper-resistant mechanism is provided for allowing a trusted element to validate
`
`25
`
`certifications presented by applications intended to be run or otherwise used, at least in
`
`part, within an insecure environment. Such techniques can detect whether applications
`
`have been certified and/or modified (i.e., tampered with) in a way that makes them no
`
`longer trustworthy.
`
`10
`
`Page 11 of 90
`
`

`

`Briefly, examples of these techniques provide a credential having multiple
`
`elements covering corresponding parts of the credential and preferably having a
`
`combined overall effect of covering all ( or a substantial portion) of the application. For
`
`example, the credential can provide verification information for different byte ranges,
`
`5
`
`virtual paths and/or other portions of application. Sufficient verification information may
`
`be provided to substantially cover the application ( or at least portions of the application
`
`most likely to be tampered with).
`
`To validate the credential, the trusted element first authenticates the credential,
`
`and then issue challenges based on different parts of the authenticated credential that the
`
`10
`
`trusted element selects in an unpredictable (e.g., random) way. For example, the trusted
`
`element can repeatedly challenge the application or other agent to provide ( or can itself
`
`generate) a cryptographic hash value corresponding to application portions or ranges the
`
`trusted element randomly selects. The trusted element can compare the responses to its
`
`challenges with information the authenticated credential provides -- and deny services ( or
`
`15
`
`take other appropriate action) if the comparison fails. The challenges may be repeated on
`
`an ongoing basis (e.g., during execution of the application) and/or interleaved with non(cid:173)
`
`predetermined challenges not defined by the credential, to increase tamper-resistance of
`
`the verification.
`
`11
`
`Page 12 of 90
`
`

`

`BRIEF DESCRIPTION OF THE DRAWINGS
`
`These and other features and advantages provided in accordance with this
`
`invention may be better and more completely understood by referring to the following
`
`detailed description of example preferred embodiments in conjunction with the drawings,
`
`5
`
`in which:
`
`Figure 1 illustrates how defective or bogus load modules can wreak havoc in the
`
`electronic community;
`
`Figure 2 shows an example verification authority that protects the electronic
`
`community from unauthorized load modules;
`
`10
`
`Figure 3 shows how a protected processing environment can distinguish between
`
`load modules that have been approved by a verifying authority and those that have not
`
`been approved;
`
`Figure 4 shows an example process a verifying authority may perform to
`
`authenticate load modules;
`
`15
`
`Figure 5 shows how a verifying authority can create a certifying digital signature;
`
`Figure 6 shows how a protected processing environment can securely authenticate
`
`a verifying authority's digital signature to guarantee the integrity of the corresponding
`
`load module;
`
`Figure 7 shows how several different digital signatures can be applied to the same
`
`20
`
`load module;
`
`Figure 8 shows how a load module can be distributed with multiple digital
`
`signatures;
`
`12
`
`Page 13 of 90
`
`

`

`Figure 8A shows how key management can be used to compartmentalize
`
`protected processing environments;
`
`Figures 9 shows how a load module can be segmented and each segment
`
`protected with a different digital signature;
`
`5
`
`Figures lOA-lOC show how different assurance level electronic appliances can be
`
`provided with different cryptographic keys for authenticating verifying authority digital
`
`signatures;
`
`Figures 1 lA-1 lC show how a verifying authority can use different digital
`
`signatures to designate the same or different load modules as being appropriate for
`
`10
`
`execution by different assurance level electronic appliances;
`
`Figures 12, 13 and 13A show how assurance level digital signatures can be used
`
`to isolate electronic appliances or appliance types based on work factor and/or tamper
`
`resistance to reduce overall security risks;
`
`Figure 14 shows example overall steps that may be performed within an
`
`15
`
`electronic system (such as, for example, a virtual distribution environment) to test,
`
`certify, distribute and use executables;
`
`Figure 15 shows an example appliance having both secure and insecure execution
`
`spaces;
`
`Figure 16 shows an example process for certifying applications intended to be run
`
`20
`
`in insecure execution spaces;
`
`Figure 16A shows an example application including multiple components;
`
`Figure 17 shows an example overall credential creation process;
`
`Figure 18 shows an example range hash block;
`
`Figure 19 shows example credential creation from a set of range hash blocks;
`
`13
`
`Page 14 of 90
`
`

`

`Figure 20 shows an example threat model;
`
`Figure 20A shows an example of non-overlapping hash ranges;
`
`Figure 20B shows an example of overlapping hash ranges;
`
`Figure 20C shows an example use of pseudo-random validation paths within an
`
`5
`
`application;
`
`Figure 21 shows an example simplified credential validation process; and
`
`Figures 22A and 22B show an example more detailed credential validation
`
`process.
`
`14
`
`Page 15 of 90
`
`

`

`DETAILED DESCRIPTION
`
`A detailed description of a preferred embodiment of the invention is provided
`
`below. While the invention is described in conjunction with this preferred embodiment,
`
`it should be understood that the invention is not limited to any one embodiment, and
`
`5
`
`encompasses instead, numerous alternatives, modifications and equivalents. While
`numerous specific details are set forth in the following description in order to provide a
`
`thorough understanding of the present invention, the present invention may be practiced
`
`without some or all of these specific details. Moreover, for the purpose of clarity, certain
`
`specifics relating to technical material that is known in the art related to the invention
`
`10
`
`have not been described in order to avoid unnecessarily obscuring the present invention
`
`in such detail.
`
`Figure 1 shows how defective, bogus and/or unauthorized computer information
`
`can wreak havoc within an electronic system 50. In this example, provider 52 is
`
`authorized to produce and distribute "load modules" 54 for use by different users or
`
`15
`
`consumers 56. Figure 1 shows "load module" 54 as a complicated looking machine part
`
`for purposes of illustration only; the load module preferably comprises one or more
`
`computer instructions and/or data elements used to assist, allow, prohibit, direct, control
`
`or facilitate at least one task performed at least in part by an electronic appliance such as
`
`a computer. For example, load module 54 may comprise all or part of an executable
`
`20
`
`computer program and/or associated data ("executable"), and may constitute a sequence
`
`of instructions or steps that bring about a certain result within a computer or other
`
`computation element.
`
`Figure 1 shows a number of electronic appliances 61 such as, for example, a set
`
`top box or home media player 58, a personal computer 60, and a multi-media player 62.
`
`25
`
`Each of appliances 58, 60, 62 may include a secure execution space. One particular
`
`example of a secure execution space is a protected processing environment 108.
`
`Protected processing environments 108 provide a secure execution environment in which
`
`15
`
`Page 16 of 90
`
`

`

`appliances 58, 60, 62 may securely execute load modules 54 to perform useful tasks. For
`
`example:
`
`• Provider 52 might produce a load module 54a for use by the protected
`
`processing environment 108A within set top box or home media player 58.
`
`5
`
`Load module 54a could, for example, enable the set top box/home media
`
`player 58 to play a movie, concert or other interesting program, charge users
`
`56a a "pay per view" fee, and ensure that the fee is paid to the appropriate
`
`rights holder (for example, the film studio, concert promoter or other
`
`organization that produced the program material).
`
`10
`
`• Provider 52 might produce another load module 54b for delivery to personal
`
`computer 60's protected processing environment 108B. The load module 54b
`
`might enable personal computer 60 to perform a financial transaction, such as,
`
`for example, home banking, a stock trade or an income tax payment or
`
`reporting.
`
`15
`
`• Provider 52 could produce a load module 54c for delivery to multi-media
`
`player 62's protected processing environment 108c. This load module 54c
`
`might allow user 56c to view a particular multi-media presentation while
`
`preventing the user from making a copy of the presentation--or it could
`
`control a portion of a transaction ( e.g. a meter that rec