Cryptographically-enabled privileged mode execution

A method, computer program product, and data processing system are disclosed for protecting sensitive program code (and also data) from unauthorized access in a memory space not subject to protection fault detection. In a preferred embodiment, secure initialization hardware loads the sensitive code from a storage location accessible only to the secure initialization hardware itself and decrypts the sensitive code into a portion of the processor-accessible memory space, from which the code is executed. Once execution of the sensitive code has completed, all or at least a portion of the code is deleted before passing control to application software. If the application software needs to cause the sensitive code to be executed, the secure initialization hardware is activated to reload/decrypt a fresh copy of the sensitive code into the memory space and cause the code to be executed. Before control is returned to the application software, the sensitive code is again deleted to prevent unauthorized access.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is related to U.S. patent application Ser. No. 11/754,667, entitled “Application-Specific Secret Generation;” U.S. patent application Ser. No. 11/754,658, entitled “Updateable Secure Kernel Extensions;” and U.S. patent application Ser. No. 11/754,649, entitled “Cryptographic Secure Program Overlays,” which are filed even date hereof, assigned to the same assignee, and incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to memory protection and privileged software execution in a data processing system. Specifically, the present invention is directed to a method of providing a privileged mode without the necessity of detecting protection faults.

2. Description of the Related Art

Many, if not most, modern operating systems and the hardware platforms that support them provide some form of facility for “memory protection.” Each application is allocated memory by the operating system and must access only those addresses in memory allocated to it. If a process attempts to access memory that is outside of the memory regions allocated to it, the illegal access attempt is detected by the operating system as an error (often called a “protection fault” or “segmentation fault”) and the offending process is terminated before disaster occurs. Memory protection can prevent many system crashes or other destructive behavior caused by software errors or malicious code (“malware”). Another important reason for restricting access to certain memory locations is to prevent proprietary or security-sensitive data or code from being examined by user-level processes, so as to prevent the creation of malware or the reverse engineering or unauthorized access to or copying of proprietary information (such as piracy of media and entertainment digital content, or privacy invasion such as stealing credit card numbers).

Although memory protection schemes are very useful, particularly for running today's very complex software, the protection schemes themselves increase the complexity of the computing hardware and the operating systems it supports. In some applications, this added complexity is highly undesirable. For example, a processor intended for high-end multimedia or real-time computationally intensive applications may have multiple specialized processor cores (such as specialized vector processing cores) on a single chip for intensive number-crunching. In such instances, the added hardware and software complexity involved in implementing conventional memory protection for each core's local memory could severely impact the attainable degree of parallelism as well as the performance of each individual processor core.

What is needed, therefore, is a method of protecting sensitive data and code from unauthorized reads and writes without relying on the additional complexity of protection-fault-detection mechanisms. The present invention provides a solution to this and other problems, and offers other advantages over previous solutions.

SUMMARY OF THE INVENTION

Accordingly, the present invention provides a method, computer program product, and data processing system for protecting sensitive program code (and also data) from unauthorized access in a memory space not subject to protection fault detection. In a preferred embodiment, secure initialization hardware loads the sensitive code from a storage location and decrypts the sensitive code into a portion of the processor-accessible memory space, from which the code is executed. Once execution of the sensitive code has completed, all or at least a portion of the code is deleted before passing control to application software. If the application software needs to cause the sensitive code to be executed, the secure initialization hardware is activated to reload/decrypt a fresh copy of the sensitive code into the memory space and cause the code to be executed. Before control is returned to the application software, the sensitive code is again deleted to prevent unauthorized access.

DETAILED DESCRIPTION

FIG. 1is a block diagram of an exemplary data processing system100in which a preferred embodiment of the present invention may be implemented. Data processing system100comprises a monolithic multiprocessor101containing several processor cores on a single integrated circuit. Monolithic multiprocessor101includes a general-purpose primary processing element102and several secondary processing units for performing more specialized, computationally-intensive functions (secondary processing units110,112, and114), connected by an internal bus104. An external bus105, external to monolithic multiprocessor101, interfaces monolithic multiprocessor101with main memory106and secondary storage108, as well as other peripheral devices (not shown).

Each of secondary processing units110,112, and114contains its own local memory in addition to main memory106. This allows secondary processing units110,112, and114to operate independently of primary processing element102in isolation mode, in which a particular secondary processing unit performs computations using its local memory without interference from primary processing element102. When not in isolation mode, secondary processing units110,112, and114may allow primary processing element102to access their respective local memory spaces. In this preferred embodiment primary, processing element102includes hardware support for memory protection (in main memory106), but secondary processing units110,112, and114do not contain memory protection hardware to prevent improper memory accesses of local memory within a secondary processing unit while in isolation mode.

A more detailed depiction of secondary processing unit110in accordance with a preferred embodiment of the present invention is provided inFIG. 2. Secondary processing unit110is interfaced to internal bus104(internal to monolithic multiprocessor101), but also contains its own intra-unit bus222internal to itself. Secondary processing unit110contains a main datapath220, which comprises the control logic, registers, and functional units used to execute stored programs of instructions in secondary processing unit110. In addition to its main datapath220, secondary processing unit110contains its own local random access memory (RAM)224and persistent-storage memory228(which may or may not comprise a non-volatile memory technology, such as flash memory), for storing information persistently between operating sessions.

Startup of secondary processing unit110is handled by secure initialization hardware226, which is independent of main datapath220. It should be noted that in this context, the term “initialization” is used loosely to refer to an initialization of secondary processing unit110, which need not occur in conjunction with initialization of data processing system100as a whole. In a preferred embodiment of the present invention, initialization of secondary processing unit110occurs each time secondary processing unit110is brought into isolation mode, which may occur many times between actual system reinitializations, for example. Hence, in this context, “initialization hardware” refers to the hardware used to initialize the particular processing unit or datapath to be used for executing the secure kernel (which, in the case of the preferred embodiment described herein, is secondary processing unit110).

However, this usage of the term “initialization” should not be understood as limiting the scope of the present invention to the particular hardware of the preferred embodiment. For example, the encryption-based protection scheme of the present invention could also be applied to a single-datapath processor (or “uniprocessor”), in which case initialization of the single datapath by secure initialization hardware would be essentially equivalent to a “warm initialization” or “reset” of the data processing system as a whole.

In addition to resetting and enabling main datapath220during an initialization of secondary processing unit110, secure initialization hardware226also contains decryption hardware for decrypting an encrypted master copy of a system kernel (master copy230) into local RAM224as part of the initialization process. The decryption key for decrypting master copy230is embedded into secure initialization hardware226such that it cannot be read from main datapath220(or from intra-unit bus222, for that matter). This can be done by storing the key securely in non-volatile memory internal to secure initialization hardware226or by actually hard-wiring the decryption process into the logic of secure initialization hardware226, such that the decryption key is not stored, but integrated implicitly into the decryption logic. Once the system kernel has been decrypted, secure initialization hardware226triggers main datapath220to begin executing the decrypted secure kernel. The decrypted secure kernel then uses a combination of public-key cryptography and digital signature verification to provide a software-based form of protection that is local to secondary processing unit110and may be used in isolation mode.

In public-key cryptography, separate keys are used for encryption and decryption. Each party has two keys, a “public key,” used for encryption, and a “private key” used to decrypt messages encrypted with the public key. A party's public key is “public” in the sense that the party makes the public key available to anyone who wishes to send encrypted messages to that party, while the private key remains secret. Even though multiple parties may possess the same public key, only the private key may be used to decrypt messages encrypted with the public key. In other words, it is computationally infeasible to decrypt a message encrypted with the public key unless one possesses the private key. This is in contrast to traditional secret key cryptosystems in which the same secret key is used for both encryption and decryption. Perhaps the best-known and most widely used public-key cryptosystem is the Rivest-Shamir-Adleman or RSA crypto system, which is described in U.S. Pat. No. 4,405,829. Public-key cryptography is widely used for making secure transactions over the Internet, as it prevents eavesdropping by third parties.

Although public-key cryptography is very useful in keeping information secret, public-key cryptography does not guard against forged or corrupted information. Since the public key can be distributed to others, and anyone possessing the public-key can encrypt messages that may only be read with the private key, public-key cryptography provides no way for the recipient of a message to know whether the message being received is genuine or originates with the source it purports to have originated from. For this reason, public-key cryptography is often used in conjunction with other cryptographic techniques that can be used to authenticate communications and verify the integrity of a message. Digital signatures are a natural complement to public-key cryptography that can be used to verify the identity of the originator of a message. With digital signatures, the sender of a message has a public/private key pair. When the sender sends a message, the sender uses its private key and the text of the message itself to compute a code that can be affixed to the message. This code is referred to as a digital signature. The recipient of the message will possess the sender's public key, which it can use to verify that the digital signature attached to a particular message was signed using the private key of the sender corresponding to that public key. One of the earliest digital signature schemes was the Rivest-Shamir-Adleman or RSA digital signature scheme, which, like the RSA public-key cryptosystem, is described in U.S. Pat. No. 4,405,829.

A preferred embodiment of the present invention makes extensive use of both public-key cryptography and digital signatures to provide data secrecy, preserve data integrity, and prevent unauthorized actions. However, one skilled in the art will recognize that implementation of the present invention is not dependent on the use of any particular type of cryptosystem or digital signature scheme. Any presently known or future-developed cryptosystem or digital signature scheme may be utilized in an embodiment of the present invention.

FIG. 3is a memory map showing memory usage in a data processing system made in accordance with a preferred embodiment of the present invention. The most privileged piece of software in the system is secure kernel302, whose main function is to validate and authenticate other pieces of software, including kernel extensions, which reside in kernel extension area304. Kernel extensions provide the main functionality to system software, and may be updated, replaced, or added, as necessary or desired. Secure kernel302, on the other hand, is endowed with minimal functionality and is intended to remain the same during the lifetime of the data processing system. Secure kernel302is “secure” because its sensitive internals are shielded from inspection or access by other programs residing in the data processing system. As will be seen, this security is maintained through a combination of selective deletion of secret information and careful use of cryptographic techniques. Among the sensitive pieces of internal information contained in secure kernel302is a private key that is specific to that particular copy of secure kernel302. In a preferred embodiment of the invention, secure kernel302's private key is specific to the particular chip (so that another chip from the same manufacturer of the same type and version would still have a different private key). Secure kernel302also has a public key corresponding to its private key, but the public key need not be kept secret (since it is a public key). Other sensitive pieces of information contained in secure kernel302would include other cryptographic keys as well as instructions for performing operations deemed to be privileged.

Secure kernel302is loaded into memory from a master copy whenever secondary processing unit110is initialized by secure initialization hardware226. This master copy is stored in encrypted form. The decryption key needed to decrypt the master copy is incorporated into secure initialization hardware226(FIG. 2) and is not accessible to software. Consequently, secure kernel302can only be loaded into memory when secure initialization hardware226is activated (during an initialization of secondary processing unit110, as described above). This not only keeps sensitive portions of secure kernel302secret, but it also ensures that secure kernel302, when loaded into memory, is genuine and has not been tampered with.

Application software is loaded into and executes from application area306. Because no hardware memory protection scheme exists in a preferred embodiment of the present invention, applications executing from application area306may freely access other parts of the memory space, including such memory areas as kernel extension area304and secure kernel area302. The effect of memory protection is achieved, however, by deleting sensitive information from secure kernel area302and kernel extension area304prior to transferring control to an application residing in application area306, and by using secure initialization hardware to reload secure kernel302and any kernel extensions, when it becomes necessary to invoke kernel extension code.

For an application residing in application area306to make use of a kernel service, the application first writes information to mailbox area308. This information will include information regarding the particular kernel service requested as well as information necessary to return control to the application, such as a callback address. Once this information has been written to mailbox area308, the application triggers secure initialization hardware226to re-initialize secondary processing unit110. This causes a fresh copy of secure kernel302(including any sensitive portions thereof) to be loaded before any kernel services are performed. The sensitive portions of secure kernel302as well as any kernel extensions are then deleted before returning control to the application, according to the instructions left in mailbox area308.

A similar mechanism is also used for kernel extensions to prevent particular kernel extensions from having access to all of secure kernel302's secrets. Those sensitive portions of secure kernel302that are not needed by a kernel extension to perform a task are deleted by secure kernel302prior to passing control to the kernel extension. In this way, secure kernel302can delegate all or only some of its powers and responsibilities to a given kernel extension. Using kernel extensions to perform most system software tasks allows system software to be updated without having to modify secure kernel302. This allows secure kernel302's master copy to be decrypted using an unrecoverable decryption key incorporated in secure initialization hardware226. Since secure kernel302will never change, even if other system software is updated or replaced, there is no need to store the decryption key (or a corresponding encryption key, assuming it is different) anywhere outside of the secure initialization hardware—or if the decryption process is hard-wired into the logic of the hardware, anywhere at all.

Additionally, a persistent storage area310is provided to allow applications to store persistent data. Persistent data is data that remains stored between invocations of one or more applications. An example of persistent data might be a database, or in the case of a video game console, a list of high scorers for a game.

As mentioned above, secure kernel302authenticates and validates the integrity of other pieces of software in the data processing system, including applications and kernel extensions.FIG. 4is a memory diagram of an application400for use in a data processing system made in accordance with a preferred embodiment of the present invention. In addition to the actual executable code itself (code image402), application400includes a public key404, which may be used to verify a digital signature406of application400. In a preferred embodiment of the present invention, public key404is specific to a particular application title, but not to a particular version of that application, so that multiple versions of the same application have the same public key404.

In addition, a cryptographic hash value408computed over code image402is provided to allow the integrity of application400to be verified. A hash value is a numerical value that is the result of a function mapping a larger block of data into a limited number of bits. A cryptographic hash value is computed using a one-way function (OWF), which is a function in which it is computationally intractable to compute the function's inverse. An example of a cryptographic hash value is the well-known SHA-1 algorithm (Secure Hash Algorithm 1), developed by the National Institute of Standards and Technology (NIST), a U.S. federal agency. Other cryptographic hash algorithms (such as SHA-256, MD5 [Message Digest 5], and many others) are known in the art and may be applied to the present invention without limitation and without departing from the scope and spirit thereof. To verify the integrity of application400, the cryptographic hash value of code image402can be computed by secure kernel302and compared to cryptographic hash value408stored as part of the application. If the two values match, the application's integrity has not been compromised (i.e., code image402has not been tampered with or become corrupted).

Since public key404is used to verify signature406, it is important that public key404not be a forgery. Therefore, a digital signature computed over public key404(public key signature410) is also included in application400. This signature can be verified by secure kernel302using one or more pre-defined public keys known to secure kernel302.

Finally, additional storage space412is provided for the creation of application-specific and application-version-specific secrets. An application may wish to store or transmit information that can only be viewed by other versions of that application or other instances of the same version of that application. In a preferred embodiment of the present invention, secure kernel302, upon loading an application such as application400, generates an application-specific secret and an application-version-specific secret, which are stored in storage area412. The application-specific secret is generated by computing a one-way function of secure kernel302's private key (which is specific to that copy of secure kernel302) and public key404, which is specific to the application (but not version specific). Thus, every instance of any version of the application running under that particular copy of secure kernel302will receive the same application-specific secret from secure kernel302.

The application-version-specific secret, on the other hand, is generated by computing a one-way function of secure kernel302's private key and a cryptographic hash value of the application image (possibly, but not necessarily the same as hash value408). This results in a secret that is specific to not only the application title and secure kernel instance, but to the particular version of the application itself.

These application-specific and application-version-specific secrets may be used for secret-key (symmetric-key) encryption of information that is to be comprehendible to only a particular application title or particular version of an application (for storage in non-volatile storage310, for example). Further, because the secrets are computed using private key information known only to a particular copy of secure kernel302, two different processors (running two different copies of secure kernel302with different private keys) will compute different application-specific and application-version-specific secrets, thus making the overall encryption scheme harder to crack. An additional benefit to having the secrets computed by secure kernel302upon loading is that the secrets themselves need not be stored permanently. When an application terminates, the secrets can be safely deleted, since secure kernel302will re-compute the secrets (with the same value) the next time the application is executed.

Kernel extensions resemble applications in that they also include a digital signature, so they may be organized in much the same way as application400is inFIG. 4. An important difference between kernel extensions and applications, however, is that kernel extensions are stored in encrypted form such that they can only be decrypted using secure kernel302's private key, which itself is only available when secure kernel302is loaded and executed immediately following a secure initialization (using the secure initialization hardware). Public-key cryptography makes it possible to update, replace, or add kernel extensions without compromising secure kernel302's private key. The source (manufacturer, publisher, distributor, etc.) of a kernel extension need only be supplied secure kernel302's public key (which, unlike the private key, is not a secret) in order to encrypt a new kernel extension so that only that copy of secure kernel302(with its unique private key) can decrypt the kernel extension.

As stated above, secure kernel302may delegate one or more of its powers/responsibilities to a kernel extension. Secure kernel302does this by retaining (i.e., not deleting) the sensitive portions of secure kernel302needed to perform a particular privileged task when passing control to the kernel extension. Secure kernel302determines which portions to retain by examining the public key used to validate the kernel extension's digital signature. Secure kernel302recognizes a pre-defined set of “privileged public keys” used to sign kernel extensions. Each privileged public key is associated with a particular level of privilege—i.e., each privileged public key corresponds to one or more sensitive parts of secure kernel302to be retained when secure kernel302passes control to a kernel extension signed with that privileged public key. Thus, a kernel extension may be delegated all or only some of the secrets/privileges of secure kernel302, according to the privilege level specified by the kernel extension's public key.

FIGS. 5-7are together a multi-page flowchart representation of the basic flow of execution of a secure kernel made in accordance with a preferred embodiment of the present invention.FIGS. 5-7illustrate how the various cryptographic features of a preferred embodiment work together under the direction of the secure kernel to create a system of privileged and non-privileged program code without the use of dedicated protection hardware. Before turning to the specifics ofFIGS. 5-7, it should first be noted that for the purpose of simplifying the presentation, each of the digital signature and hash value verifications has been presented here as a processing step (rectangle) rather than as a decision (diamond), although by nature each of these actions involves a determination as to whether the validation or verification succeeds or fails. It should be understood throughout the following description that the failure of any verification or validation action inFIGS. 5-7will trigger an error or exception condition that will interrupt the normal flow of execution depicted inFIGS. 5-7. Hence, each validation or verification described below should be understood as also implicitly including a decision step branching to an error condition on failure of the validation or verification.

Turning now toFIG. 5, when secure initialization hardware226initializes or re-initializes secondary processing unit110(as described above), before the main datapath of secondary processing unit110begins processing instructions, the secure initialization hardware decrypts the secure kernel into processor-accessible memory from the encrypted master copy (block500). Once the secure kernel has been decrypted, the secure initialization hardware starts the main datapath of the data processing system, which then begins to execute the secure kernel (block501).

The secure kernel then checks mailbox area308to determine what actions should be taken following the initialization, such as loading/executing a particular kernel extension or returning control to an application that triggered a warm initialization (block502). Additionally, checking mailbox area308allows the secure kernel to determine whether a warm or cold initialization has occurred. Next a determination is made as to whether a kernel extension should be loaded (block504). If so (block504:yes), then the secure kernel decrypts the desired kernel extension into processor-accessible memory using the secure kernel's private key (block506). The secure kernel validates the digital signature of the public key supplied with the kernel extension using a pre-defined public key known to the secure kernel (i.e., stored in the secure kernel's “key ring”) (block507). The secure kernel then validates the digital signature of the kernel extension itself using the kernel extension's public key (block508). Next, the secure kernel verifies the integrity of the kernel extension using by computing a hash value of the kernel extension and comparing the computed hash value to that supplied with the kernel extension (block510).

If the kernel extension passes each of these validations/verifications, a determination is made as to which sensitive portions of the secure kernel should be deleted or retained before passing control to the kernel extension (block512). As stated above, this determination is based on which public key was used to sign the kernel extension, each public key corresponding to a set of sensitive portions to be retained (or equivalently, which sensitive portions should be deleted) before passing control to a kernel extension signed with that public key. Once it is determined which sensitive portions of the secure kernel should be retained, the remainder of the sensitive portions of the secure kernel are deleted (block514) and the secure kernel passes control to the loaded kernel extension (block516).

Upon returning to execution of the secure kernel from the execution of a loaded kernel extension (following block516), or if no kernel extension was loaded (block504:No), a determination is made as to whether new application code should be loaded into memory for execution (block518). If so (block518:Yes), the application code is loaded into processor-accessible memory (block520). The signature of the public key of the newly loaded application code is then validated using a pre-defined public key known to the secure kernel (block521). The signature of the application itself is then validated using the application's validated public key (block522). Next, the integrity of the application is verified by computing a hash value of the application and comparing the computed hash value to that supplied with the application (block524).

Once the application has been validated and verified, the secure kernel generates an application-specific secret by computing a one-way function from the secure kernel's private key and the application's public key (block526). The secure kernel also generates an application-version-specific secret by computing a one-way function from the secure kernel's private key and a hash value computed from the bytes of the application itself (block528). These secrets are stored by the secure kernel in memory so as to be accessible to the loaded application (e.g., in secret space412of the application).

After application-specific and application-version-specific secrets have been computed by the secure kernel, the secure kernel deletes the sensitive portions of itself (including its private key, privileged code portions, and any other secrets of the secure kernel) (block530). The secure kernel then fully transfers control (branches) to the application (block532) (there being no further processing performed by the secure kernel until the next secure initialization). If a new application is not loaded (block518:No), then the secure kernel deletes the sensitive portions of itself (block534), then passes control to the application code address indicated in mailbox area308(i.e., to the application which initiated the warm initialization triggering the execution of the secure kernel) (block536).

One of the preferred implementations of the invention is a computer program, namely, a set of instructions (program code) or other functional descriptive material in a code module that may, for example, be resident in the random access memory of the computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network. Thus, the present invention may be implemented as a computer program product for use in a computer. In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps. Functional descriptive material is information that imparts functionality to a machine. Functional descriptive material includes, but is not limited to, computer programs, instructions, rules, facts, definitions of computable functions, objects, and data structures.