Abstract:
A secure processor assuring application software is executed securely, and assuring only authorized software is executed, monitored modes and secure modes of operation. The former executes application software transparently to that software. The latter verifies execution of the application software is authorized, performs any extraordinary services required by the application software, and verifies the processor has obtained rights to execute the content. The secure processor (1) appears hardware-identical to an ordinary processor, with the effect that application software written for ordinary processors can be executed on the secure processor without substantial change, (2) needs only a minimal degree of additional hardware over and above those portions appearing hardware-identical to an ordinary processor. The secure processor operates without substantial reduction in speed or other resources available to the application software. Functions operating in secure mode might reside in an on-chip non-volatile memory, or might be loaded from external storage with authentication.

Description:
BACKGROUND OF THE INVENTION 
   1. Field of the Invention 
   The invention relates to secure processors and to secure software execution thereon, such as for example to secure processors capable of secure execution of application software. 
   2. Related Art 
   In known computing systems, the availability of processing capability, such as provided by microprocessors and other processing devices, is no longer a significant limit when considering the value of the computing system. Availability of application software and multimedia content, or more precisely, authorization to use that application software and multimedia content, for execution by those processors (and for presentation by those processors) has become a substantial limit. One effect of this is that a substantial value to many computing systems is the application software and multimedia content that executes on the device or platform. Both application software and multimedia content have become more easily distributed, such as for example using a communication network or by distribution using inexpensive CD-ROM media, with the effect that protecting against unauthorized copying and distribution (sometimes called “software piracy”) has become an economically important concern. Accordingly, one problem in the known art is to assure that such application software and multimedia content, being valuable, are only used on processors when the right to do so has been authorized, such as for example when that right has been properly paid for, or the integrity of the content verified with respect to information from a trusted content publishing entity. 
   Another problem in the known art is that, while it is desired to provide application software and multimedia content with the property that such application software and multimedia content cannot be used on processors without authorization or alteration, it is not desirable to redesign or re-author the application software or multimedia content to provide this property. There is a sufficient set of application software and multimedia content available, and the value of that application software and multimedia content is sufficiently large, that the approach of altering that application software or that multimedia content would likely be expensive, unreliable, and unwieldy. 
   Accordingly, it would be advantageous to restrict application software and multimedia content to those processors for which that application software and multimedia content is authorized, without having to substantially alter the original application software or multimedia content. 
   SUMMARY OF THE INVENTION 
   The invention provides a secure processor, and a method and system for using that secure processor, capable of assuring that application software is executed securely, and capable of assuring that only authorized application software is executed and only authorized multimedia content is presented. Further, it is also important to ensure that the authorized content can be played only on the device on which rights or permission for the content have been purchased and can be verified. The secure processor includes two modes of operation, a monitored mode and a secure mode. The former executes application software transparently to that application software. The latter verifies that execution of the application software (and presentation of the multimedia content) is authorized, and performs any extraordinary services required by the application software. The secure processor appears hardware-identical, to the application software, to an ordinary processor, with the effect that application software written for ordinary processors can be executed on the secure processor without substantial change. The secure processor needs only a minimal degree of additional hardware over and above those portions that appear hardware-identical to an ordinary processor, with the effect that the secure processor can operate without substantial reduction in speed or other resources available to the application software. In one embodiment, a portion of the secure processor is substantially identical to a semiconductor die for an original ordinary processor (except for using different die size or manufacturing technology), with the effect that there is substantial assurance that the application software will execute identically on the secure processor as it would have on the original ordinary processor. 
   In one embodiment, the secure processor initiates execution at power-on in secure mode. In this initial operation phase, the secure processor executes secure code in secure mode. The secure code is maintained in a persistent memory internal to the secure processor chip and therefore trustable. The secure code loads additional source code from one or more trusted sources, verifying both the trustworthiness of the sources and the authenticity of the additional source code, with reference to security information also maintained in the persistent memory internal to the secure processor chip and therefore trustable. The security information might include, but is not necessarily limited to, encryption keys, secure hash values, or other data for verification of the trusted sources and authentication of the additional source code. 
   Once loaded, the additional secure code causes the secure processor to request application software from trusted sources, verifies that the secure processor has authorization to execute the requested application software, verifies that the application software has been correctly loaded, and checks the integrity of that application software. In the context of the invention, there is no particular requirement that either the persistent memory or the trusted source have the particular implementation described herein. For one example, not intended to be limiting in any way, either the persistent memory, or one or more of the trusted sources, might be replaced or supplemented with a hardware device coupled to the secure processor (such as by a user). In this example, the secure processor would verify the integrity of the coupling and verify the authenticity and correct operation of the hardware device before trusting any code loaded from that source. 
   The secure processor is able to exit secure mode and execute the application software that has been correctly loaded in monitored mode. Application software executes without substantial change in original code for that application software, with the effect that the application software sees a processor environment that is not substantially different from an ordinary processor. When the application software needs services the secure processor oversees, the application software generates an interrupt, causing the secure mode to be re-entered, the services to be delivered to the application software, and the secure mode to be exited, with the effect that the application software can continue to execute in monitored mode. For one example, not limiting in any way, the application software might request additional application software modules to be requested, loaded, and executed. Among other services, the secure processor might oversee I/O operations, which the application software might request using an API (application programming interface) provided to secure code executable by the secure processor. 
   The secure processor is also able to interrupt the application software using a timer, enter secure mode, perform any desired steps, and re-enter monitored mode. Where secure mode might be entered by more than one technique, the secure processor is able to determine by which technique secure mode is entered. The secure processor is also able to record accesses to external memory, with the effect of being able to verify correct execution by the application software. Among other features, the secure processor might have the capability of overseeing (that is, reviewing and confirming the propriety of) I/O operations, or the secure processor might have the capability of performing (preferably, after reviewing and confirming the propriety of) secure operations at the request of application software. 
   For one example, not intended to be limiting in any way, the secure processor is able to examine those locations in external memory the application software attempts to access. If the application software attempts to access any locations outside a range of locations permitted by the secure processor, the secure processor might determine in response thereto that the application software is acting improperly. For example, not intended to be limiting in any way, in such cases the application software might have a software error, might include a software virus, or might be designed to be actively malicious. In response thereto, the secure processor might take appropriate action to limit any such improper effect. For example, again not intended to be limiting in any way, in such cases the secure processor might take action to limit access by the application software to those external memory locations, might take action to halt operation by the application software, or might take action to perform a software virus check or software virus clean-up of the application software. 
   The secure processor is also able to perform encryption or decryption on behalf of application software, with the effect that the application software need not be aware that encryption or decryption, or other security features, are being performed with regard to its ordinary operations. For a first example, not intended to be limiting in any way, the application software might perform a check for authenticity on additional code or on multimedia content loaded from a server, from external mass storage, or from external memory, without having access to the unique ID or private keys for the secure processor, but still using the full power of the security features of the secure processor. For a second example, again not intended to be limiting in any way, the application software might encrypt or decrypt secure information it communicates with external entities, again without having access to the unique ID or encryption or decryption keys for the secure processor, but still using the full power of the security features of the secure processor. 
   In one embodiment, the secure processor includes a unique ID, and is capable of using that unique ID (and unique encryption or decryption keys associated with that unique ID) to uniquely identify the particular instance of the secure processor. In such embodiments, when performing encryption or decryption on behalf of application software, the secure processor uses the unique ID and unique encryption or decryption keys. For example, not intended to be limiting in any way, the secure processor might perform encryption or decryption on behalf of application software, and thus use the unique ID and unique encryption or decryption keys, when communicating with external entities. In one such example, the secure processor might perform communication with external entities to confirm, exchange, or obtain DRM (digital rights management) information. 
   The secure processor maintains the unique ID, code signatures or cryptographic hashes, and unique encryption or decryption keys, as well as any other information specific to the particular instance of the secure processor, in a non-volatile memory (such as for example an NVROM). The NVROM includes a non-bonded pin used during manufacture or configuration of the secure processor to record information specific to the particular instance of the secure processor, which is left non-bonded after manufacture or configuration, with the effect that the NVROM cannot be written a second time. 
   Having a unique ID (and unique encryption or decryption keys) provides systems including the secure processor with several advantages:
         Use of the secure processor to communicate with servers is traceable, so that users making unauthorized attempts to download application software or multimedia content can be called to account.   Securely embedding the unique ID and unique encryption or decryption keys allows servers to trust the secure processor without having to verify or trust the portion of the secure processor, such as its secure boot code, which attempts to download application software or multimedia content. The server need only trust the manufacturer to securely embed the unique ID and unique encryption or decryption keys.   Systems including the secure processor are resistant to tampering by users attempting to intercept signals to and from the secure processor, or otherwise present in the system, because sensitive data communicated with the secure processor can be encrypted for security. Attempting to compromise sensitive data would otherwise involve difficult deconstruction of the secure processor chip.   In the secure processor, the CPU that executes application software or presents multimedia content is substantially identical to an original non-secure processor, so attempts to disable the security features of the secure processor would also disable desired functionality of that CPU.   The secure processor can securely verify rights by the CPU to execute application software or to present multimedia content. For example, not intended to be limiting in any way, a trusted server (or other trusted entity, such as a certification authority) might issue a secure digital purchase receipt for which authenticity can be verified by the secure processor, such as using the unique ID and unique encryption or decryption keys. In such examples, the secure digital purchase receipt might uniquely identify the specific device (or class of device) having the right to execute application software or to present multimedia content.   The secure processor can enforce copy prevention and copy protection of application software and multimedia content. For example, not intended to be limiting in any way, such content might include (1) a set of purchased application software the CPU is permitted to execute, or purchased multimedia content the CPU is permitted to present, (2) digital rights to enable such execution or presentation, (3) information for use between the CPU and another device, such as for example a peer-to-peer message, intended to be limited to a specific device (or class of devices).       

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  shows a block diagram of a system including a secure processor capable of secure execution. 
       FIGS. 2   a  and  2   b  show a process flow diagram of a method of operating a secure processor capable of secure execution. 
       FIG. 3  shows a block diagram of a circuit including a device for programming a non-volatile memory in a substantially non-erasable way. 
       FIG. 4  shows a process flow diagram of a method of operating a circuit including a device for programming a non-volatile memory in a substantially non-erasable way. 
   

   DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
   In the description herein, a preferred embodiment of the invention is described, including preferred process steps and data structures. Those skilled in the art would realize, after perusal of this application, that embodiments of the invention might be implemented using a variety of other techniques not specifically described, without undue experimentation or further invention, and that such other techniques would be within the scope and spirit of the invention. 
   Lexicography 
   The following terms relate or refer to aspects of the invention or its embodiments. The general meaning of each of these terms is intended to be illustrative and in no way limiting.
         The phrase “secure processor” describes a device having the capability of assuring that only trusted software is executed on a subunit, the subunit including a “processor” or “processing unit,” (herein sometimes referred to as a “CPU”). Within the secure processor, the concept of a processor or processing unit is broad, and is intended to include at least the following: a general-purpose processor having a general instruction set, a special purpose processor having a limited instruction set, a set of special purpose circuitry capable of executing or interpreting program instructions, a set of firmware program instructions capable of emulating a secure processor of any type, any reasonable generalization thereof, and the like.   The phrase “application software” describes a set of instructions or parameters capable of being executed or interpreted by a processor. As noted herein, the concept of application software is broad, and is intended to include at least the following: software or firmware program instructions, software or firmware program parameter values, source code capable of being compiled by a programming language compiler or interpreted by a programming language interpreter, macro definitions for a compiled or interpreted programming language, commands or requests to be received and acted upon by an application program, any reasonable generalization thereof, and the like.   The phrase “multimedia content” describes a set of information or parameters capable of being presented to a user. As noted herein, the concept of multimedia content is broad, and is intended to include at least the following: animation, audiovisual movies, still pictures, or sound, whether embedded in data for interpretation and presentation by software or firmware program instructions; embedded in software or firmware program instructions for producing such data themselves; embedded in a markup language for multimedia content, such as DHTML, SGML, VRML, Macromedia Flash, and the like; commands or requests to be received and acted upon by an application program; any reasonable generalization thereof; and the like.   The phrases “monitored mode” and “secure mode” describe possible operational states of the secure processor. As noted herein, the concepts of monitored mode and secure mode are broad, and are intended to include at least the following: any distinguishable states in which instructions executed or interpreted by the secure processor have distinguishable degrees of access to capabilities of the processor, and in which the secure processor when in secure mode is capable of performing any type of monitoring or restriction of the secure processor when in monitored mode, and the like.   The concepts of transparent execution (of application software by the secure processor) and apparent hardware identity (of the secure processor to the application software) describe the capability of the secure processor to execute application software, in the view of that application software, as if that application software were executing on an ordinary processor. This has the effect that the secure processor can execute that application software without any need for modification of that application software, but is still capable of maintaining security features as described herein. For just one example, not limiting in any way, a portion of the secure might be substantially identical to a semiconductor die for an original ordinary processor, with the effect that there is substantial assurance that the application software will execute identically on the secure processor as it would have on an original ordinary processor.   The phrase “power on” describes an initial operation phase of a processing unit, whether occurring after an actual change in power supply, a reset signal, or any other substantial initialization in state for the secure processor. As noted herein, the concept of power-on is broad, and is intended to include any initial operational state described herein, as well as generalizations thereof.   The phrases “secure code” and “secure boot loader code” describe program instructions, interpretable or executable by the secure processor, and known to the secure processor to be trustable. Secure code might, for example, not limiting in any way, be known to be trustable by virtue of having been maintained in persistent memory in the secure processor chip. Starting from such trustable secure code, additional source code can be established as “secure code” by virtue of having been received from a trusted source and authenticated to be accurate by previously established “secure code” or “secure boot loader code”. As noted herein, the concept of secure code is broad, and is intended to include any program code for which the secure processor can trust that code, including for example, to perform security functions.   The phrases “security functions” and “security kernel software” describe program instructions, interpretable or executable by the secure processor, known to the secure processor to be verifiable, and capable of implementing functions relating to security, authentication, or verification. For example, not intended to be limiting in any way, functions including digital signatures, encryption and decryption, verification of digital signatures, and the like, might be implemented by security functions or security kernel software. In one embodiment, such security functions or security kernel software might be made available for use by application software using an API (application programming interface). In one embodiment, the security kernel software is loaded by the secure boot loader code and verified for integrity and/or authenticity before execution. That portion of software related to security, having been authenticated and maintained in (possibly volatile) memory within the secure processor chip, is included within the concept of “secure code”.   The phrase “secure processor chip” (herein sometimes referred to as the “chip”) describes the physical hardware on which the secure processor is implemented. As described herein, the secure processor chip includes hardware structure and program instructions, known to the secure processor to be trustable, and difficult for others to interfere with or to breach the security of.       

   The scope and spirit of the invention is not limited to any of these definitions, or to specific examples mentioned therein, but is intended to include the most general concepts embodied by these and other terms. 
   System Elements 
     FIG. 1  shows a block diagram of a system including a secure processor capable of secure execution. 
   A system  100  includes a secure processor  110 , a communication link  120 , and at least one software or content publisher  130 . Optionally, the software or content publisher  130  (herein sometimes called the trusted server  130 ) might include a trusted server capable of online or offline additional content delivery to the secure processor  110  or to devices controlled by the secure processor  110 . 
   In one embodiment, the system  100  also includes an application device  140 , including at least one input device  141  and at least one output device  142 , operating under control of application software  143  executed by the secure processor  110 . 
   The application device  140  might perform any application desired when the secure processor operates in monitored mode. For one example, not limiting in any way, the application device  140  might include a device for playing or participating in a real-time audiovisual game, such as might be installed in an arcade or at a personal computer. However, there is no particular requirement in the context of the invention that the application device  140  is so specific. Rather, the application device  140  may generally include a gaming device; a personal computer or personal workstation; any hand-carried device, such as a pager, a PDA (personal digital assistant) or other hand-held computer, a notebook or laptop computer, a telephone, a watch, a location or condition sensor, a biometric sensing or reporting device, a pacemaker, a telemetry device, or a remote homing device. 
   More generally, so long as the secure processor  110  is able to perform the functions described herein, the application device  140  may include any device following a computing paradigm. 
   For additional delivery of authentic applications or content to the chip, the communication link  120  might include a communication path from the trusted server  130  to the secure processor  110 . For example, not intended to be limiting in any way, the communication link  120  might include a communication path using the Internet or a portion thereof, either in real time, or using one or more store and forward devices, or using one or more intermediate caching devices, or physical delivery through storage media. However, in alternative embodiments, the communication link  120  may include a communication path to a private or public switched telephone network, a leased line or other private communication link, a radio transceiver, a microwave transceiver, a wireless or wireline modem, or any other device or system capable of communication with the trusted server  130  on behalf of the secure processor  110 . More generally, the communication link  120  might include any conceivable technique for delivery of content, such as for example storage media (such as a CD-ROM) physically shipped and delivered from the trusted server  130 . 
   The trusted server  130  includes a content publishing, delivery, or serving entity, such as for example as part of an electronic distribution system. In one embodiment, the trusted server  130  is (optionally) capable of generating a digital signature for any content it distributes, such as for example application software or multimedia content, with the effect that the secure processor  110  is capable of verifying the authenticity of that content. In one embodiment, that digital signature might be generated using a digital signature technique used with a public key cryptosystem, a system of a like nature, or another type of system capable of generating information from which the content can be verified for authenticity. 
   In alternative embodiments, the trusted server  130  may include a logically remote device capable of receiving messages including requests for information, and generating messages including responses to those requests for information. For example, not intended to be limiting in any way, the trusted server  130  might include an internet server including a high-end PC or workstation. Although in one embodiment the trusted server  130  includes a stand-alone server, there is no particular requirement in the context of the invention that the trusted server  130  is so specific. Rather, the trusted server  130  may generally include any device capable of acting as described herein, and may include either hardware components or software components or both. Moreover, there is no particular requirement in the context of the invention that the trusted server  130  includes any particular combination of components, or even that the trusted server  130  is a single device or even that it includes the whole of any particular device. Rather, the trusted server  130  may generally include one or more portions of another device, and may generally include more than one device (or portions thereof) operating in conjunction or cooperation. More generally, as described above, the trusted server  130  might include any conceivable device for creation or encapsulation of content for delivery, such as for example a device for writing storage media (such as a CD-ROM) to be physically shipped and delivered to the secure processor  110 . 
   As noted above, more generally, the trusted server  130  might include any conceivable technique for delivery of content. In the context of the invention, there is no particular requirement for any actual online content delivery, or even for any live or real-time link between the secure processor  110  and the trusted server  130 . For one example, not intended to be limiting in any way, application software or multimedia content might be delivered from the trusted server  130  to the secure processor  110  by any of the following techniques, or some combination or conjunction thereof:
         The application software or multimedia content might be delivered using an interactive or switched communication system.   The application software or multimedia content might be delivered using physical storage media.   The application software or multimedia content might be delivered, by any technique, from a third party, in an encoded or encrypted form, and a key for decoding or decryption might be delivered, by any technique, from the trusted server  130 .   The application software or multimedia content might be delivered, by any technique, from a third party, and a certificate or other guarantee of authenticity might be delivered, by any technique, from the trusted server  130 .   The application software or multimedia content might be delivered, by any technique, using intermediate storage devices or other types of caching devices, using the Internet or any other distribution technique.       

   The secure processor  110  includes a monitored processor  111 , a set of security logic  112 , and a set of security information  113 . The secure processor  110  can operate in either a monitored mode or a secure mode. When operating in the monitored mode, the secure processor  110  uses circuitry including the monitored processor  111 . When operating in the secure mode, the secure processor  110  uses circuitry including the monitored processor  111  and the security logic  112 , and also uses data including the security information  113 . 
   1. Monitored Processor 
   The monitored processor  111  includes an internal bus  114 , a CPU A 100 , a CPU memory interface A 103 , a mass storage interface A 135 , a memory interface A 140 , a set of application-specific circuitry A 145 , a mass storage device A 150 , a set of RAM A 155 . 
   The internal bus  114  is capable of communicating signals, including requests for data and responses including data, among portions of the monitored processor  111 . The internal bus  114  is coupled to the CPU memory interface A 103 , the mass storage interface A 135 , the memory interface A 140 , the application-specific circuitry A 145 , and the mass storage device A 150 . 
   The CPU A 100  might include any general-purpose processor or special purpose processor capable of carrying out the functions described herein. For example, the CPU A 100  might include a general-purpose processor such as those made by AMD or Intel, or a special purpose processor such as a DSP or an embedded micro-controller. 
   The CPU memory interface A 103  is coupled to the CPU A 100 . The CPU memory interface A 103  receives memory access requests from the CPU A 100  and records accesses by the CPU A 100  to RAM A 155 . Although in one embodiment the CPU memory interface A 103  records all such accesses, in alternative embodiments the CPU memory interface A 103  may choose to record only some of such accesses, such as only those accesses specified in a selected set of memory locations specified by the security logic  112  or the security information  113 . 
   The mass storage interface A 135  performs appropriate interface functions with the mass storage device A 150 . The mass storage device A 150  might include a hard disk, floppy disk, tape, or other types of mass storage. 
   The memory interface A 140  performs appropriate interface functions with the external memory (that is, the RAM A 155 ). The RAM A 155  includes all forms of random access memory, whether writable or not, and if writable, whether writable more than once or only once. 
   The application-specific circuitry A 145  performs any other functions specific to the particular monitored processor  111 , not already performed by the CPU A 100 . The CPU A 100  and the application-specific circuitry A 145  might perform selected functions in conjunction or cooperation. 
   2. Security Logic 
   The security logic  112  includes a secure mode switch circuit A 105 , a secure timer circuit A 110 , a set of secure boot code A 115 , an access control circuit A 133 , a secure mode active signal A 160 , a set of access control signals A 163 , a NMI (non-maskable interrupt) signal A 165 , and a port A 171  for receiving an external reset signal A 170 . In addition, a set of secure code A 120  that assists with security functions might be maintained in mass storage A 150 . 
   The secure processor  110  is capable of responding to the external reset signal A 170 . In response to the reset signal A 170 , the CPU A 100  transfers control to (that is, begins execution of instructions at a new location) a pre-selected reset location in the secure boot code A 115 . Neither the pre-selected reset location nor the secure boot code A 115  is alterable by the CPU A 100  or any application software. 
   In response to the reset signal A 170 , the secure mode switch circuit A 105  generates the secure mode active signal A 160 , which sets up access rights so that the CPU A 100  is allowed to access the secure boot code A 115 , execute its instructions, and read and write data using the security information  113 . On reset, the secure processor  110  transfers control to the reset location and executes the secure boot code A 115 , and (the secure mode active signal A 160  being logical TRUE) allows the CPU A 100  to access restricted secure portions of the chip. In one embodiment, the secure boot code A 115  is maintained in a separate non-volatile memory A 115 , and neither its location nor its contents are alterable by any application software. 
   The secure boot code A 115  locates and loads any additional software and security functions included in the secure kernel code A 120  from external mass store A 150  and into internal RAM A 120 , after performing any necessary security checks. 
   After locating and loading any additional secure code A 120 , the CPU A 100  transfers control to, and begins execution of, that secure code A 120 . The secure code A 120  causes the CPU A 100  to prepare to authenticate and execute the application code  143 . Once the preparation to execute the application code  143  is complete, the secure code A 120  causes the secure processor  110  to exit secure mode. 
   The secure processor  110  is also capable of responding to an NMI signal A 165 . The NMI signal A 165  might for example be generated by application code  143  (such as for example by a program instruction executable by the CPU A 100 ) to request a service to be performed in secure mode. An example of such a service might be to perform a secure function or another function that only the secure code A 120  has authority to perform. To request such a service, the application code  143  sets selected bits in the security logic  112 . The secure mode logic sets the secure mode active signal A 160  to be logical TRUE, which enables the CPU A 100  to have access to secure parts of the secure processor  110 . Simultaneously the security logic  112  sends the NMI signal A 165  to the CPU A 100 , causing the CPU A 100  to transfer control to the secure boot code A 115  internal to the chip. The secure boot code  115  performs services for the application, renders the results to some shared memory locations in RAM A 155 , and exits to the monitored mode using the security logic  112 . The pre-selected NMI handler location, the secure boot code A 120 , and the technique by which the security kernel software is loaded and authenticated, are not alterable by the CPU A 100  or by any application software. 
   As described herein, the secure kernel code A 120  is maintained in internal memory (either non-volatile memory, or in a volatile memory, in which case it is loaded from external storage and authenticated). The secure mode switch circuit A 105  generates the secure mode active signal A 160 , which enables the CPU A 100  to access the non-volatile memory C 100  including the secure boot code A 115 , so that the CPU A 100  can execute its instructions, and read and write data using the security information  113 . 
   The secure timer circuit A 110  is capable of generating a timer interrupt signal for the CPU A 100 , in response to parameters set by the secure mode switch circuit A 105 . The security logic  112  can also generate an NMI signal A 165  to the CPU A 100  in response to a timeout from a secure timer. In response, the CPU A 100  transfers control to a pre-selected timer interrupt handler location in the secure kernel code A 120 . Neither the pre-selected timer interrupt location nor the secure kernel code A 120  is alterable by the CPU A 100  or any application software (or any other software maintained in the external storage A 150 ). 
   In response to the timer interrupt signal A 165 , and similar to other methods of entering secure mode, the secure processor  110  sets the secure mode active signal A 160  to be logical TRUE, with the effect of enabling access to secure portions of the secure chip. 
   The access control circuit A 133  controls access to elements of the secure processor  110  in response to the secure mode active signal A 160 , by generating the access control signals A 163 , which are coupled to each element of the secure process  110  for which access control is performed. When the secure mode active signal A 160  indicates that the secure processor  110  is in a secure mode, the access control circuit A 133  allows the CPU A 100  to access all elements of the secure processor  110 . When the secure mode active signal A 160  indicates that the secure processor  110  is in a monitored mode, the access control circuit A 133  allows the CPU A 100  to only access backward-compatible monitored-mode portions of the secure processor  110 . In a preferred embodiment, these backward-compatible monitored-mode portions exclude the security logic  112  (except for indicating entry into secure mode) and the security data  113 . 
   More specifically, when the secure mode active signal A 160  indicates that the secure processor  110  is in a monitored mode, the access control circuit A 133  prevents the CPU A 100  from accessing the secure mode switch circuit A 105  (except for indicating entry into secure mode), the secure timer circuit A 110 , the secure boot code A 115 , the secure kernel code A 120 , the access control circuit A 133  itself, the secure mode active signal A 160 , the access control signals A 163 , the read-only secure data A 125 , the R/W volatile secure state value A 130 , the encryption/decryption keys B 101 , and the licensing information B 102 . 
   3. Security Information 
   The security information  113  includes a set of read-only secure data A 125 , a R/W volatile secure state value A 130 , a set of private (such as from a public key cryptosystem), a set of encryption/decryption keys, a set of optional unique IDs and a set of signature information B 101 . 
   The read-only secure data A 125  includes a set of secure code, as described herein, such as code available to be executed by the CPU A 100  in response to the reset signal A 170 , optionally in response to the NMI signal A 165 , in response to the timer interrupt signal A 165 , or otherwise when the secure mode is entered. 
   In one embodiment, the read-only secure data A 125  includes a set of one or more private keys, and a set of encryption/decryption keys B 101 , preferably unique to the individual secure processor  110 . In such embodiments, the secure processor  110  uses the encryption/decryption keys B 101  for decrypting messages from trusted sources using a public-key cryptosystem (such as for example by using a private key of a private/public key pair in a public-key cryptosystem). Alternatively, the secure processor  110  might have another set of code signatures B 103 , differing from the encryption/decryption keys B 101 , with which to authenticate trusted sources using other techniques for authentication. Similarly, in such embodiments, the secure processor  110  uses the code signatures B 101  for verifying the accuracy of additional secure code to be loaded into memory, such as by noting the correctness of a digital signature or secure hash associated with that additional secure code when received from authenticated trusted sources. 
   In one embodiment, the read-only secure data A 125  also includes a set of key information B 102 , by which the individual secure processor  110  is able to authenticate sources and verify that the individual secure processor  110  has the right to receive and perform relevant application software. For example, the licensing information B 102  might include a signed certificate from a trusted authority, indicating that the individual secure processor  110  is licensed to perform the relevant application software. In such embodiments, in response to the licensing information B 102 , the authenticated trusted sources provide the relevant capabilities for the secure processor  110  to load and execute application software. In one embodiment, these capabilities include either the application software itself, or a DRM (digital rights management) certificate authorizing the secure processor  110  to load and execute the application software. 
   The R/W volatile secure state value A 130  includes any read/write volatile memory the secure processor  110  needs to execute the secure code. In one embodiment, the secure processor  110  maintains all of its volatile state in the R/W volatile secure state value A 130 , with the effect that application code cannot access any of the state information used by the secure code. The secure processor  110  also includes, in the secure kernel code A 120 , instructions performable by the CPU A 100  to make relevant authentication and validity checks for any software to be executed by the CPU A 100 . Maintaining all of the volatile state for the secure processor  110  in the R/W volatile secure state value A 130  also has the effect of increasing the work factor for users to attempt to read that state and violate the security of secure mode operation for the secure processor  110 . However, in alternative embodiments, the secure processor  110  may maintain at least some of its volatile state in ordinary memory, with the effect that it may be possible for application code to access some of the values associated with that state. 
   Method of Operation 
     FIG. 2  shows a process flow diagram of a method of operating a secure processor capable of secure execution. 
   A method  200  is performed by the system  100 . Although the method  200  is described serially, the flow points and steps of the method  200  can be performed by separate elements in conjunction or in parallel, whether asynchronously or synchronously, in a pipelined manner, or otherwise. There is no particular requirement that the method  200  must be performed in the same order in which this description lists flow points or steps, except where explicitly so indicated. 
   1. Power On 
   At a flow point  210 , the secure processor  110  is ready for power on. 
   At a step  211 , the secure processor  110  is powered on. 
   At a step  212 , the reset signal A 170  is asserted, with the effect of indicating that the secure processor  110  has just been reset. When the secure processor  110  is reset, the secure mode active signal A 160  is asserted (that is, set to logical TRUE) and the CPU A 100  jumps to (that is, transfers execution control to) the secure boot code A 115 . 
   At a step  213 , the secure mode switch circuit A 105  asserts the secure mode active signal A 160 , which indicates to the non-volatile memory C 100  ( FIG. 3 ) that the CPU A 100  is allowed to access the secure boot code A 115 , execute its instructions, and read and write data using the security information  113 . The CPU A 100  then transfers control to a pre-selected reset location in the secure boot code A 115 . 
   At a step  214 , the CPU A 100  executes instructions from the secure boot code A 115 . 
   At a step  215 , the CPU A 100  executes the secure boot code A 115 . 
   In one embodiment, the following illustrative implementation on a MIPS or MIPS compatible processor results in the entry into secure mode upon reset. This illustrative implementation begins at a flow point  250 , and includes actions that would be included in the step  214  and the step  215 .
         At a step  251 , the reset signal causes a request to enter secure mode.   At a step  252 , the security logic  112  prepares to set the secure mode signal A 165  to logical TRUE, if and only if a subsequent uncached read to the reset location 0×1fbc0000 is made.   At a step  253 , the CPU A 100  interrupts normal execution to respond to the reset signal.   At a step  254 , the CPU A 100  attempts to fetch the next instruction from location 0×1fbc0000, with the effect of invoking a reset interrupt handler or NMI interrupt handler.   At a step  255 , the security logic  112  sets the secure mode signal A 165  to logical TRUE, with the effect of enabling access for secure parts of the chip and the execution of boot secure code.   At a step  256 , the CPU A 100  proceeds to execute the reset interrupt handler or NMI interrupt handler in the secure boot code A 120 .       

   After the execution of the secure boot code A 120 , the following steps load the security kernel or security functions, if any, from mass storage A 150 . 
   The secure boot code A 115  reads the security information  113 , receives additional cryptographically signed or verifiable instructions, and records those additional instructions in the internal RAM A 155 . To perform this step, the CPU A 100  performs the following sub-steps:
         At a sub-step  215 , the CPU A 100 , operating in secure mode executes software (possibly obtained from a server device) from external mass storage A 150 , after having been loaded and authenticated by secure boot code A 120 . In one embodiment, the message is encrypted using encryption/decryption keys B 101  from the read-only secure data A 125 , accessible only by the CPU A 100  while operating in secure mode.       

   Although in one embodiment the CPU A 100  obtains the additional instructions using the communication link  120 , in alternative embodiments the system  100  may obtain additional instructions (either some or all of them) by other means. Some examples, not intended to be limiting in any way, are described herein, including the possibilities of obtaining such additional instructions either (1) by means of physical media, or (2) from a third party, with a DRM (digital rights management) certificate or other capability being obtained from a server device. 
   Moreover, although in one embodiment the additional instructions are sent in an encrypted form, in alternative embodiments the system  100  may obtain such additional instructions (either some or all of them) in a non-encrypted form, with enforcement of the right to use those additional instructions being managed using a DRM certificate, other capability, or other technique.
         At a sub-step  216 , the CPU A 100 , operating in secure mode, also authenticates the software and verifies its integrity with respect to secure information either from within the chip or verified with respect to messages from trusted servers whose trust has in turn been already established by secure software or data. In one embodiment, the CPU A 100  performs this authentication sub-step using a public key cryptosystem, including encryption keys or code signatures B 101  from the read-only secure data A 125 , and using information about the trusted server  130  (such as for example a public key for the trusted server  130 ) included in the encryption/decryption keys B 101  or other read-only secure data A 125 .   At a sub-step  216 , the trusted server optionally  130  verifies that the secure processor  110  is authorized to receive application software or other additional instructions from the trusted server  130 . In one embodiment, the CPU A 100  performs this verification sub-step using a public key cryptosystem, using encryption/decryption keys B 101  from the read-only secure data A 125 , and using licensing information B 102  or other information from the read-only secure data A 125 .       

   Those of ordinary skill in the art will recognize, after perusal of this application, that many other techniques might be used to authenticate software or data from a server using cryptographic signatures and trusted root keys. Moreover, there is no particular requirement that such authentication need be for only the trusted server  130 . In alternative embodiments, it may be that both server and client authenticate each other.
         At a sub-step  217 , the CPU A 100 , operating in secure mode, receives the application software or other additional instructions from the trusted server  130 , and verifies the accuracy of that application software or those other additional instructions. In one embodiment, the CPU A 100  performs this verification sub-step using a public key cryptosystem, using encryption/decryption keys B 101  from the read-only secure data A 125 , or using a secure hash for the application software or other additional instructions from the read-only secure data A 125 .   At a sub-step  218 , the CPU A 100 , operating in secure mode, records the application software or other additional instructions in RAM A 155 . A result of this sub-step is that the application software or other additional instructions are ready to be executed by the CPU A 100 .       

   Although one example method is described herein for authenticating and loading application software, other and further techniques are also possible for doing so. As described above, in the context of the invention, there is no requirement that authentication of the application software involves any particular technique, and in particular, there is no requirement that authentication of the application software involves interactive communication with the trusted server  130 . 
   In one embodiment, at least some portions of the secure kernel code A 120  itself are obtained by the secure processor  110  as such additional instructions. In one embodiment, the following technique might be used:
         At start-up (either power-on or upon receipt of the reset signal), the CPU A 100  is forced to perform the secure kernel code A 120 , which is verified to be correct and secure by secure boot code.   The CPU A 100  performs the secure kernel code A 120 , after loading program code by a bootstrap loader, with the effect of locating and copying code for performing security functions from mass storage A 150 , or other external devices, to an internal memory. In one embodiment, the internal memory is an on-chip volatile memory, such as for example an SRAM memory.   The non-volatile write-once memory C 110  ( FIG. 3 ) is initialized, at the time of manufacture of the secure processor chip, with a cryptographically-strong signature value, such as for example a 160-bit secure hash or digest value. In one embodiment, the secure hash or digest value might include an SHA1 secure hash or other known cryptographically-strong signature values. As described herein, construction and initialization of the non-volatile write-once memory prevents it from being modified by application software after manufacture of the secure processor chip.   The bootstrap loader portion of the secure kernel code A 120  computes a signature of the newly loaded program code, and compares that computed signature with a pre-computed signature already internally stored in the non-volatile memory C 110 . If the computed signature and the pre-computed signature match, the bootstrap loader portion of the secure kernel code A 120  concludes that the newly loaded program code is accurate and trustworthy. Upon this conclusion, the CPU A 100  is permitted to execute the newly loaded program code in secure mode.   In one embodiment, the CPU A 100  re-verifies the newly loaded program code as being accurate and trustworthy each time it attempts to load additional software intended to be executed in secure mode. For example, not limiting in any way, these cases might include (1) each time a portion of the secure kernel code A 120  is loaded from RAM A 155 , mass storage A 150 , or any other external device, (2) each time additional software is desired to be loaded and added to the secure kernel code A 120 , such as for example a new security function or a new function to be provided by the secure kernel code A 120 .   As noted herein, in one embodiment, the CPU A 100  separately verifies each module of the newly loaded program code as being accurate and trustworthy. For example, not limiting in any way, these cases might include (1) maintaining a separately pre-computed signature for each module, when multiple modules are loaded from RAM A 155 , mass storage A 150 , or any other external device, (2) locating a new pre-computed signature in each module for a next such module, when additional software is desired to be loaded in a sequence of modules, (3) maintaining both a separately pre-computed signature for each module, and a pre-computed signature for a set of such modules.       

   At a step  219 , the secure processor  110  exits from the secure mode to the monitored mode. A general illustrative method of exit from secure mode is outlined later herein. 
   2. Requests for Services 
   At a flow point  220 , the secure processor  110  is executing application software in monitored mode. The secure mode is ready to receive a request for services from the application software. 
   At a step  221 , the application software presents a request for services to the secure processor  110 . 
   At a step  222 , in one embodiment, the application software places parameters for the request for services in a set of selected registers in the secure mode logic. 
   At a step  223 , the secure mode logic  112  sets the secure mode signal A 160  to logical TRUE. 
   At a step  224 , the secure mode logic  112  generates the NMI interrupt signal A 165  to the CPU A 100 , with the effect that the CPU A 100  transfers control to the secure kernel code A 120  to satisfy the request for services. 
   At a step  225 , similar to the step  213 , the CPU A 100  jumps to a pre-selected interrupt handler location in the secure code. The secure mode switch circuit is responsible for A 105  asserting the secure mode active signal A 160 , which enables the CPU A 100  to access the secure code, execute its instructions, and read and write data using the security information  113 . 
   At a step  226 , similar to the step  214 , the CPU A 100  executes instructions from the secure code. The secure code handles the NMI interrupt. 
   In one embodiment, the following illustrative implementation on a MIPS or MIPS compatible processor results in the entry into secure mode at the request of the application code  143 . This illustrative implementation begins at a flow point  250 .
         The application performs an uncached read to a register in secure mode logic. This “arms” the secure mode logic to conditionally enter secure mode if and only if it encounters a subsequent read from NMI reset location 0×1bfc0000.   At a step  252 , the security logic  112  prepares to set the secure mode signal A 165  to logical TRUE, if and only if a subsequent uncached read to the reset location 0×1fbc0000 is made.   At a step  253 , the security logic  112  causes an NMI signal to be asserted to the CPU A 100 .   At a step  254 , the CPU A 100  attempts to fetch the next instruction from location 0×1fbc0000, with the effect of invoking a reset interrupt handler or NMI interrupt handler.   At a step  255 , the security logic  112  sets the secure mode signal A 165  to logical TRUE, with the effect of enabling access for secure parts of the chip and the execution of boot secure code.   At a step  256 , the CPU A 100  proceeds to execute the reset interrupt handler or NMI interrupt handler in the secure code A 120 .       

   In one embodiment, a register in the secure mode logic is reserved to indicate the reason for entry into secure mode; for example, due to a reset, due to a request from the application code, and the like. 
   The secure kernel determines the cause of entry to secure mode and performs the services requested by the application by possibly reading restricted areas of the chip, and returns the result to a memory area shared with the application. 
   After performing the requested operation, the secure kernel triggers a defined exit sequence (as described below) through the secure mode logic and returns to the application code  143 . 
   At a step  227 , the secure processor  110  saves a result of the requested operation in a shared memory, such as the RAM A 155 . 
   In one embodiment, the request for services presented by the application software might include a request to perform an I/O operation. In such embodiments, the secure processor  110  reserves at least some I/O operations to be performed in secure mode, with the effect that the application software cannot perform those I/O operations without assistance from secure code. 
   The application software presents a request for services, indicating by the parameters associated with the request that the requested service is an I/O operation. The parameters associated with the request follow an API (application programming interface) selected for the secure processor  110  by its designers, preferably to operate in cooperation with the application software without substantial change in the application software. 
   In one embodiment, the request for services presented by the application software might include a request to load additional software. In such embodiments, the secure processor  110  performs steps similar to the step  214  and its sub-steps. Accordingly, in the system  100 , in sub-steps similar to those of the step  214 , the CPU A 100  authenticates the server device as a trusted server  130 , the CPU A 100  receives or loads the additional software, either from mass storage A 150  from the trusted server  130 , and the CPU A 100  records the additional software in RAM A 155  after verifying the authenticity and integrity of such software. 
   Error traps or I/O emulation can be handled by the same illustrative mechanism above through the secure mode logic. The secure mode logic forces the CPU to enter secure mode in those cases and execute pre-authenticated software to handle error traps or I/O requests as necessary. 
   At a step  228 , the secure processor  110  exits from the secure mode to the monitored mode. A general illustrative method of exit from secure mode is outlined later herein. 
   3. Timer Interrupts 
   At a flow point  230 , the secure processor  110  has set a timer that might interrupt application software executing in monitored mode, and the timer is ready to go off. 
   At a step  231 , similar to the step  221 , the timer goes off, and the application software is interrupted. 
   At a step  232 , similar to the step  222 , the timer interrupt signal A 165  is asserted, with the effect of indicating that processing on the secure processor  110  has just been interrupted. 
   One illustrative method of the implementation of the secure timer trap on a MIPS or MIPS compatible processor is as follows. This illustrative method is similar to the steps beginning with the flow point  250 .
         The secure timer is programmed in the CPU reset secure boot software to count down to zero and reset to a value that determines the periodicity of the secure time trap. This mechanism is not maskable or interruptible by any application software, and runs continuously while the application continues to execute.   The timer counts down from the programmed setting and upon reaching zero, triggers an NMI signal A 165  to the CPU (which interrupts its execution path), and arms the secure mode logic to conditionally assert the secure mode active signal if an only if a subsequent uncached read request is made to the NMI routine location.   The CPU jumps to execute the NMI routine where the secure kernel resides to perform the desired action upon timer interrupt.   The secure mode logic, upon acknowledging the read to the NMI location, sets secure mode active signal to true and permits access to secure regions of the chip.   The secure kernel routine responsible for handling the timer trap performs its operation and finally exits secure mode again through the secure mode logic.       

   At a step  236 , the CPU A 100  exits the secure code, and returns to the application software execution point. The secure mode switch circuit A 105  de-asserts the secure mode active signal A 160 , with the effect of indicating that the CPU A 100  is no longer allowed to access the secure code, execute its instructions, or read and write data using the security information  113 . 
   4. Monitored Memory Access 
   At a flow point  240 , the secure processor  110  is ready to record accesses to external memory by application software executing in monitored mode. 
   At a step  241 , the CPU A 100  attempts to read from or write to RAM A 155 . To perform this step, the CPU A 100  sends a memory address to the CPU memory interface A 103 . 
   At a step  242 , the CPU memory interface A 103  couples that memory address to the internal bus  114 , which couples that memory address to the memory interface A 140  and to the security logic  112 . 
   At a step  243 , the security logic  112 , including the access control circuit A 133 , determines if the CPU A 100  should be allowed to access that memory address in the RAM A 155 . In one embodiment, the CPU A 100  is generally always allowed to access any memory address in the RAM A 155 . However, in alternative embodiments, the access control circuit A 133  might restrict the CPU A 100  from accessing selected memory addresses, with the effect of isolating selected portions of the RAM A 155  from when the CPU A 100  is operating in monitored mode. 
   At a step  244 , the security logic  112 , including the access control circuit A 133 , records the attempt to access that memory address in the RAM A 155  by the CPU A 100 . In one embodiment, the CPU A 100  records only selected such memory addresses. For one example, not limiting in any way, the access control circuit A 133  might select one or more portions of the RAM A 155  for which to record accesses when the CPU A 100  is operating in monitored mode. However, in alternative embodiments, the access control circuit A 133  may attempt to record all such memory accesses, may attempt to record memory accesses in response to a pattern thereof, or may attempt to record memory accesses in response to some other criteria selected by the CPU A 100  operating in secure mode. The application specific restriction information could be loaded by the security software during application launch with the usual authentication checks on the restrictions. 
   In one embodiment, a method of implementation of the exit from secure mode in any of the above mechanisms.
         The register indicating the reason for entry into secure mode is cleared.   The software clears all caches or internal memory regions used to execute secure kernel software.   The secure kernel software returns from NMI routine.
 
Non-Volatile Memory
       

     FIG. 3  shows a block diagram of a circuit including a device for programming a non-volatile memory in a substantially non-erasable way. 
   A circuit  300  includes a non-volatile memory C 100 , a disable logic circuit C 110 , an external program logic circuit C 120 , a non-bonded pin C 130 , and a set of external programming pins  340 . 
   In one embodiment, the non-volatile memory C 100  includes a flash memory or other memory capable of being electrically programmed, and capable of being read, with the effect that the circuit  300  can determine whether the non-volatile memory C 100  has been programmed with data or not. In the context of the invention, there is no particular requirement that the non-volatile memory C 100  includes any particular memory technology, so long as it can perform the functions described herein. 
   The disable logic circuit C 110  is coupled to the external program logic circuit C 120 , with the effect that when the program enable signal from the disable logic circuit C 110  is turned off, inputs to the external program logic circuit C 120  are disabled and the non-volatile memory C 100  cannot be electrically programmed from the external programming pins. 
   The disable logic circuit C 110  is also coupled to the non-volatile memory C 100 , and is capable of reading values from the non-volatile memory C 100  and comparing those values with a program enable signature value, with the effect that the disable logic circuit C 110  can determine if the non-volatile memory C 100  has been initially programmed or not. If the non-volatile memory C 100  has been initially programmed with a program enable signature value, the disable logic circuit C 110  causes inputs to the external program logic circuit C 120  to be enabled, with the effect that the non-volatile memory C 100  can be electrically programmed. If the program enable signature value is not present the program enable output from the disable logic C 110  will be disabled. 
   The non-bonded pin C 130  includes an electrically conducting pad, located on the secure processor chip die and capable of being probed before the die is packaged, but not bonded to any external wiring or packaging. This has the effect that the non-bonded pin C 130  can be electrically coupled to external circuitry when the secure processor chip is manufactured, but that after manufacture and packaging, the non-bonded pin C 130  is substantially unable to be electrically coupled to any external circuitry. Thus, after manufacture and before packaging of the secure processor chip, the non-bonded pin C 130  is available for use when programming the non-volatile memory C 100 , but when manufacture and packaging are completed, the non-bonded pin C 130  is no longer available for use when programming the non-volatile memory C 100 , with the effect that the non-volatile memory C 100  cannot be externally programmed. 
   On wafer test after manufacture, the non-bonded pin C 130  is coupled to a selected voltage (logic “0”), with the effect that the external program logic circuit C 120  is enabled and the non-volatile memory C 100  can be electrically programmed, regard-less of the state of the program enable output from the disable logic C 110 . 
   Method of Recording Unique Information 
     FIG. 4  shows a process flow diagram of a method of operating a circuit including a device for programming a non-volatile memory in a substantially non-erasable way. 
   A method  400  is performed with regard to the circuit  300  when constructing the secure processor  110 . Although the method  400  is described serially, the flow points and steps of the method  400  can be performed by separate elements in conjunction or in parallel, whether asynchronously or synchronously, in a pipelined manner, or otherwise. There is no particular requirement that the method  400  must be performed in the same order in which this description lists flow points or steps, except where explicitly so indicated. 
   At a flow point  410 , the non-volatile memory C 100  in the secure processor  110  is ready to be programmed. In one embodiment, a result of the method is to cause security information unique to that particular secure processor  110  to be recorded in a non-volatile memory. 
   At a step  411 , the non-bonded pin C 130  is coupled to a selected voltage (logic “0”), with the effect that the external program logic circuit C 120  is enabled and the non-volatile memory C 100  can be electrically programmed. 
   At a step  412 , the non-volatile memory C 100  is electrically programmed with an initial program enable signature value (disposed in its last memory location), with the effect that the non-volatile memory C 100  is ready to be further programmed. 
   At a step  413 , the circuit  300  is packaged, with the effect that the non-bonded pin C 130  is no longer available for coupling to external circuitry. 
   At a step  414 , the non-volatile memory C 100  is electrically programmed. 
   In one embodiment, when this step is performed, security information  113  unique to the particular instance of the secure processor  110  is recorded in the non-volatile memory C 100 . This has the effect that the particular instance of the secure processor  110  becomes uniquely distinguishable from each other instance of the secure processor  110 , and can uniquely identify itself to trusted servers  130 . 
   At a step  415 , the non-volatile memory C 100  is further electrically programmed to erase the program enable signature value. When the program enable signature value is no longer present, the disable logic circuit C 110  determines that the non-volatile memory C 100  is no longer available for programming, and causes the external program logic circuit C 120  to be disabled. This has the effect that the non-volatile memory C 100  can no longer be further electrically programmed from the external programming pins. 
   At a flow point  420 , the non-volatile memory C 100  no longer includes the program enable signature value, the disable logic circuit C 110  determines that the non-volatile memory C 100  is no longer available for programming, and the disable logic circuit C 110  causes the external program logic circuit C 120  to be disabled. On power-up for the secure processor  110 , the non-volatile memory C 100  can no longer be further electrically programmed from the external programming pins. 
   ALTERNATIVE EMBODIMENTS 
   Although preferred embodiments are disclosed herein, many variations are possible which remain within the concept, scope, and spirit of the invention. These variations would become clear to those skilled in the art after perusal of this application.
         There is no particular requirement that all executable code, or even all secure code, need be present on the chip on which the secure processor  110  is integrated. In alternative embodiments, the secure processor  110  may involve secure code or other executable code maintained in the external RAM A 155 , in the mass storage A 150 , or in other external devices.   There is no particular requirement that the secure processor  110  need be implemented as a single integrated chip. In alternative embodiments, the secure processor  110  may include multiple devices, coupled using signals that are either encrypted or otherwise secured against snooping or tampering.   There is no particular requirement that all secure code need be loaded all at once. In alternative embodiments, the secure processor  110  may involve multiple segments of secure code, which are loaded and verified at different times, such as in a sequence, or such as on an on-demand basis. For a first example, not intended to be limiting in any way, the secure kernel code A 120  might include signatures of one or more modules of additional software to be loaded and integrated into the instructions performed by the CPU A 100  when operating in secure mode. For a second example, not intended to be limiting in any way, the secure kernel code A 120  might include signatures of one or more modules of additional software to be loaded, each of which itself includes signatures of one or more modules of additional software to be loaded.   Memory and mass storage access checks might be performed in response to selected events. For a first example, not intended to be limiting in any way, these selected events might include any request for encryption/decryption services, I/O services, or secure signature or verification services by the application software. For a second example, not intended to be limiting in any way, these selected events might include periodic intercepts of memory of mass storage access (such as every N th  access, for a selected value of N), periodic timer interrupts, and the like.   Authentication and verification checks might be performed in response to selected events, similar to memory or mass storage access checks. For a first example, not intended to be limiting in any way, these selected events might include any request for encryption/decryption services, I/O services, or secure signature or verification services by the application software. For a second example, not intended to be limiting in any way, these selected events might include periodic intercepts of memory of mass storage access (such as every N th  access, for a selected value of N), periodic timer interrupts, and the like.   The secure kernel code A 120  might offer additional security services, besides those mentioned herein above, to the application software. For example, not intended to be limiting in any way, these additional services might include authentication and verification of messages from servers (other than the trusted server  130 , which is already described above) and other messaging partners (such as in peer-to-peer protocols and such as in protocols in which the application software has the role of a server), encryption/decryption of messages exchanged with servers (other than the trusted server  130 , which is already described above) and other messaging partners, public-key signature of messages exchanged with servers (other than the trusted server  130 , which is already described above) and other messaging partners, authentication and verification of further additional software to load and execute from secondary trusted servers  130 , management of DRM licensing information, periodic (or in response to selected events, as noted above) authentication and verification of software loaded for execution by the CPU A 100 , and the like.   The secure kernel code A 120  might offer additional services other than those related to security, besides those mentioned herein above, to the application software. For example, not intended to be limiting in any way, these additional services might include specific device drivers or operation of specific hardware for which the application software is licensed to operates, and the like.       

   Those skilled in the art will recognize, after perusal of this application, that these alternative embodiments and variations are illustrative and are intended to be in no way limiting.