DETAILED DESCRIPTION OF THE INVENTION

[0040] The present invention relates to computer systems and computer operating systems. More specifically, one embodiment of the present invention relates to a combined-hardware-and-software secure-platform and a combined-hardware-and-software secure-platform interface that provides a secure foundation on which one or more operating systems can be layered in order to produce secure computer systems. The combined-hardware-and-software platform and combined-hardware-and-software-platform interface represent an evolutionary step in machine/operating system interfaces. As discussed above, with reference to FIGS. 2 - 4 , the machine/operating-system interface evolved from a set of instructions and registers, as illustrated in FIG. 2 , to a set of non-privileged instructions and registers, a set of privileged instructions and registers, hardware interruption mechanisms, and a set of firmware-implemented services, as illustrated in FIG. 5 . One embodiment of the present invention is a secure platform and secure-platform/operating-system interface that provides a set of non-privileged instructions and registers and a set of secure platform services that include callable routines that provide support for memory management, dispatchable object dispatching, exception handling, interruption handling, debugging and performance monitoring, cryptographic services, secure data repository services, domain control services, logical and physical processor control services, inter- and intra-domain communications services, platform policy management services, caller authentication services, and other services. Another view of this embodiment of the present invention is that the hardware and the overlying secure platform software together represent a new type of machine, just as the firmware and hardware in the system illustrated in FIG. 4 represents a new and different type of machine with respect to the earlier systems illustrated in FIGS. 2 and 3 . This new machineprovides secure, basic functionalities on top of which secure operating systems and secure systems can be constructed. Rather than simply relying on hardware privilege levels, an operating system can employ an entire suite of basic functionalities that execute at a higher privilege level than the operating system, and that remain secure from the operating system.

[0041] In order to describe the combined-hardware-and-software secure-platform interface, discussions of security, an example hardware platform suitable for use in the combined-hardware-and-software secure platform, and a general discussion of cryptography are presented in three following subsections. Then, in a fourth subsection, and in Appendices A and B that follow, a detailed description of the combined-hardware-and-software secure-platform interface that represents one embodiment of the present invention is discussed in detail.

[0042] Computer Security

[0043] There are many different ways to define computer security. Quite often, security problems and security deficiencies that arise in computer systems represent entire classes of problems that were initially not recognized by system designers as security issues. Properly and comprehensively defining the term “computer security” may constitute an important and even essential step in designing a secure computer system. A step in the design of the combined-hardware-and-software secure-platform interface that represents one embodiment of the present invention is the recognition that the a secure computer system encompasses at least the following nine characteristics and properties:

[0044] Availability

[0045] An available system is a system that can be trusted and relied upon to be functioning and to respond correctly whenever an end user invokes a system service. Availability can be addressed, in part, by incorporating redundant configurations of reliable hardware components within a system, and detecting and/or compensating for incorrect operation of either a hardware or software component. However, availability also may be greatly facilitated by expanding the class of detectable errors and limiting the damage resulting from the occurrence of errors.

[0046] Confidentiality

[0047] Information stored within a computer system, transmitted across a network, or residing in archival storage needs to be intelligible only to authorized parties. Confidentiality may be greatly facilitated by specifying cryptographic ciphers and protocols that can be employed to assure that the intelligibility of data and system information can be restricted solely to authorized parties via encryption of file data, paging data, communications between local system components, and communications over the Internet.

[0048] Authentication

[0049] The identities of persons, servers, clients, appliances, printing subsystems, storage subsystems, and other hardware and software components that generate and access data need to be correctly ascertained before services are provided to these entities. Authentication may be greatly facilitated by specifying the cryptographic means and protocols by which all such identities can be authenticated.

[0050] Access Control

[0051] Access to information stored within a computer system or residing in archival storage needs to be permitted only when properly authorized. Access control may be facilitated by providing a range of access control schemes.

[0052] Nonrepudiation

[0053] In E-commerce transactions, neither the sending party nor the receiving party of messages should be able to deny the existence and transmission of messages specifying and effecting a transaction. For example, means need to be provided to insure that a party sending a message ordering a shipment of “widgets” later cannot claim that the “widgets” never were ordered. Nonrepudiation is facilitated by identifying cryptographic mechanisms and protocols, such as digital signatures, that can be used to ensure that parties to a transaction are accountable.

[0054] Policy Control

[0055] Owners and administrators need to be equipped to define for systems under their control policies that govern the behavior of the security elements of those systems.

[0056] Digital Rights Protection

[0057] Secure systems need to protect digital content, particularly guarding digital images from unauthorized duplication. Examples include currency, MPEG home entertainment content, high quality images of fine art, and printed materials for limited distribution.

[0058] Privacy

[0059] The property of privacy depends upon the preceding properties, but needs additional capabilities for managing and controlling information associated with identities of persons and groups. Information private to an individual needs to be protected from unauthorized access. In some cases, even if access is authorized, the identities of individuals should not be disclosed. Features of a system that secure privacy include: (1) legitimate collection of information about individuals, in a legitimate manner, relevant to and not in excess of, the purpose for collection; (2) maintaining accurate and up-to-date information about individuals; (3) processing information about an individual fairly and lawfully, obtaining an individual's consent for retention, use, or transfer of information to third parties; (4) individuals should be entitled to access information about themselves, including the right to have such information rectified or deleted; (5) individuals need to be told what personal information is to be collected, its intended use, the responsible entity, and the choices the individual has regarding the uses of the information; (6) individuals need to be given the ability to select and/or update the choices for dealing with their personal information; and (7) means need to be provided for demonstrating to an oversight or enforcement agency that private information has been handled correctly and lawfully.

[0060] Data Integrity

[0061] Data in the custody of a computer system is a precious and critical information asset. A secure system needs to ensure that data assets are not lost or damaged, and not subjected to unauthorized falsification, deletion, forgery, permutation, or other forms of tampering. A combination of well-designed file and data base systems, systematic back up and restore procedures, and cryptographic protections for the integrity and confidentiality of the data itself are needed to assure this property.

[0062] A Modem Computer Architecture

[0063] Processors built to comply with the Intel® IA-64 computer architecture represent one fundamental hardware interface of a series of modern computer hardware platforms suitable for combination with a secure platform software layer to produce the combined-hardware-and-software secure-platform interface that represents one embodiment of the present invention. FIG. 7 is a block diagram showing the registers within one modern processor. The registers hold values that define the execution state of the processor, and, when saved to memory, capture the state of an executing process prior to stopping execution of the process. Restoring certain registers saved in memory allows for resumption of execution of an interrupted process. The register set shown in FIG. 7 is quite complex, and only certain of the more important registers are described, below.

[0064] One important register is the process status register (“PSR”) 702 . The PSR is a 64-bit register that contains control information for the currently executing process. The PSR comprises many bit fields, including a 2-bit field that contains the current privilege level (“CPL”) at which the currently executing process is executing. There are four privilege levels: 0, 1, 2, and 3. The highest privilege level is privilege level 0. The lowest privilege level is privilege level 3. Only processes executing at privilege level 0 are allowed to access and manipulate certain machine resources, including the subset of registers, known as the “system-register set,” shown in FIG. 7 within the lower rectangle 704 . These system registers include a set of region registers 706 , a set of protection-key registers 708 , data and instruction translation look aside buffer registers 710 , a set of debug-break-point registers 712 , a set of performance-monitor-configuration registers 714 , and a set of control registers 716 . One control register, the interruption processor status register (“IPSR”) 718 , stores the value of the PSR for the most recently interrupted process. The interruption status register (“ISR”) 720 contains a number of fields that indicate the nature of the interruption that most recently occurred. Other control registers store information related to other events, such as virtual memory address translation information related to a virtual address translation fault, pointers to the last successfully executed instruction bundle, and other such information. Sets of external control interrupt registers 722 are used, in part, to set interrupt vectors.

[0065] The registers shown in FIG. 7 in the upper rectangular region 724 are known as the “application-register set.” These registers include a set of general registers 726 , sixteen of which 728 are banked in order to provide immediate registers for interruption handling code. At least 96 general registers 730 form a general-register stack, portions of which may be automatically stored and retrieved from backing memory to facilitate linkages among calling and called software routines. The application-register set also includes floating point registers 732 , predicate registers 734 , branch registers 736 , an instruction pointer 738 , a current frame marker 740 , a user mask 742 , performance monitor data registers 744 , processor identifiers 746 , an advanced load address table 748 , and a set of specific application registers 750 .

[0066] The IA-64 architecture provides a 2-bit privilege-level field in the processor status register, in turn providing for 4 privilege levels: PL0—the most privileged, kernel privilege level; PL1—the next most privileged privilege level; PL2—the next most privileged level; and PL3—the application-level privilege level.

[0067] The memory and virtual-address-translation architecture of the IA-64 computer architecture is described below, with references to FIGS. 8 - 11 . The virtual address space defined within the Intel IA-64 computer architecture includes 2 ²⁴ regions, such as regions 802 - 807 shown in FIG. 8 , each containing 2 ⁶¹ bytes that are contiguously addressed by successive virtual memory addresses. Thus, the virtual memory address space can be considered to span a total address space of 2 ⁸⁵ bytes of memory. An 85-byte virtual memory address 808 can then be considered to comprise a 24-bit region field 810 and a 61-bit address field 812 .

[0068] In general, however, virtual memory addresses are encoded as 64-bit quantities. FIG. 9 illustrates translation of a 64-bit virtual memory address into a physical memory address via information stored within region registers, protection key registers, and a translation look-aside buffer (“TLB”). In the Intel® IA-64 architecture, virtual addresses are 64-bit computer words, represented in FIG. 9 by a 64-bit quantity 902 divided into three fields 904 - 906 . The first two fields 904 and 905 have sizes that depend on the size of a memory page, which can be adjusted within a range of memory page sizes. The first field 904 is referred to as the “offset.” The offset is an integer designating a byte within a memory page. If, for example, a memory page contains 4096 bytes, then the offset needs to contain 12 bits to represent the values 0-4095 in the binary number system. The second field 905 contains a virtual page address. The virtual page address designates a memory page within a virtual address space that is mapped to physical memory, and further backed up by memory pages stored on mass storage devices, such as disks. The third field 906 is a three-bit field that designates a region register containing the identifier of a region of virtual memory in which the virtual memory page specified by the virtual page address 905 is contained.

[0069] Translation of the virtual memory address 902 to a physical memory address 908 that includes the same offset 910 as the offset 904 in the virtual memory address, as well as a physical page number 912 that references a page in the physical memory components of the computer system, is carried out by the processor, at times in combination with kernel and operating system routines. If a translation from a virtual memory address to a physical memory address is contained within the TLB 914 , then the virtual-memory-address-to-physical-memory-address translation can be entirely carried out by the processor without operating system intervention. The processor employs the region register selector field 906 to select a register 916 within a set of region registers 918 . The selected region register 916 contains a 24-bit region identifier. The processor uses the region identifier contained in the selected region register and the virtual page address 905 together in a hardware function to select a TLB entry 920 containing a region identifier and virtual memory address that match the region identifier contained in the selected region register 916 and the virtual page address 905 . Each TLB entry, such as TLB entry 922 , contains fields that include a region identifier 924 , a protection key associated with the memory page described by the TLB entry 926 , a virtual page address 928 , privilege and access mode fields that together compose an access rights field 930 , and a physical memory page address 932 .

[0070] If an entry in the TLB can be found that contains the region identifier contained within the region register specified by the region register selector field of the virtual memory address, and that contains the virtual page address specified within the virtual memory address, then the processor determines whether the virtual memory page described by the virtual memory address can be accessed by the currently executing process. The currently executing process may access the memory page if the access rights within the TLB entry allow the memory page to be accessed by the currently executing process and if the protection key within the TLB entry can be found within the protection key registers 934 in association with an access mode that allows the currently executing process access to the memory page. The access rights contained within a TLB entry include a 3-bit access mode field that indicates one, of a combination of, read, write, and execute privileges, and a 2-bit privilege level field that specifies the privilege level needed by an accessing process. Each protection key register contains a 24-bit protection key associated with an access mode field specifying allowed read, write, and execute access modes and a valid bit indicating whether or not the protection key register is currently valid. Thus, in order to access a memory page described by a TLB entry, the accessing process needs to access the page in a manner compatible with the access mode associated with a valid protection key within the protection key registers and associated with the memory page in the TLB entry, and needs to be executing at a privilege level compatible with the privilege level associated with the memory page within the TLB entry.

[0071] If an entry is not found within the TLB with a region identifier and a virtual page address equal to the virtual page address within the virtual memory address and a region identifier selected by the region register selection field of a virtual memory address, then a TLB miss occurs and hardware attempts to locate the correct TLB entry from an architected mapping control table, called the VHPT, located in kernel memory. If the hardware is unable to locate the correct TLB entry from the mapping control table, a TLB fault occurs and a kernel or operating system routine is invoked in order to find the specified memory page within physical memory or, if necessary, load the specified memory page from an external device into physical memory, and then insert the proper translation as an entry into the VHPT and TLB. If, upon attempting to translate a virtual memory address to a physical memory address, the process does not find a valid protection key within the protection key registers 934 , or if the attempted access by the currently executing process is not compatible with the access mode in the TLB entry or the read/write/execute bits within the protection key in the protection key register, or the privilege level at which the currently executing process executes is less than the privilege level needed by the TLB entry, then a fault occurs that is handled by a kernel routine that dispatches execution to an operating system routine.

[0072] FIG. 10 shows one form of a data structure employed by an operating system routine to find a memory page in physical memory corresponding to a virtual memory address. The virtual memory address 902 is shown in FIG. 10 with the same fields and numerical labels as in FIG. 9 . The operating system routine employs the region selector field 906 and the virtual page address 905 to select an entry 1002 within a virtual page table 1004 . The virtual page table entry 1002 includes a physical page address 1006 that references a page 1008 in physical memory. The offset 904 of the virtual memory address is used to select the appropriate byte location 1010 in the virtual memory page 1008 . The virtual page table 1002 includes a bit field 1012 indicating whether or not the physical address is valid. If the physical address is not valid, then the operating system selects a memory page within physical memory to contain the memory page, and retrieves the contents of the memory page from an external storage device, such as a disk drive 1014 . The virtual page table entry 1002 contains additional fields from which the information needed for a TLB entry can be retrieved. Once the operating system successfully maps the virtual memory address into a physical memory address, that mapping is entered into the virtual page table entry and, formatted as a TLB entry, is inserted into the TLB.

[0073] FIG. 11 shows the access rights encoding used in a TLB entry. Access rights comprise a 3-bit TLB.ar mode field 1102 that specifies read, write, execute, and combination access rights, and a 2-bit TLB.pl privilege level field 1104 that specifies the privilege level associated with a memory page. In FIG. 11 , the access rights for each possible value contained within the TLB.ar and TLB.pl fields are shown. Note that the access rights depend on the privilege level at which a current process executes. Thus, for example, a memory page specified with a TLB entry with TLB.ar equal to 0 and TLB.pl equal to 3 can be accessed for reading by routines running at any privilege level, shown in FIG. 11 by the letter “R” in the column corresponding to each privilege level 1106 - 1109 , while a memory page described by a TLB entry with TLB.ar equal to 0 and TLB.pl equal to 0 can be accessed by reading only by a process running at privilege level 0, as indicated in FIG. 11 by the letter “R” 1110 under the column corresponding to privilege level 0. The access rights described in FIG. 11 nest by privilege level according to the previous discussion with reference to FIG. 4 . In general, a process running at a particular privilege level may access a memory page associated with that privilege level and all lower privilege levels. Using only the access rights contained in a TLB entry, it is not possible to create a memory region accessible to a process running at level 3 and kernel routines running at level 0, but not accessible to an operating system routine running at privilege level 2. Any memory page accessible to a routine running at privilege level 3 is also accessible to an operating system routine executing at privilege level 2.

[0074] Because computer resources are partitioned according to privilege levels, processes generally access instructions and data from memory pages associated with the privilege level of the executing process or a lower privilege level, with privilege level 0 considered the highest privilege level. An executing process may be interrupted by a hardware-generated interruption, in which case an interruption handling routine is automatically invoked by the hardware to execute at privilege level 0. Once the interruption is partially or completely handled, the interruption handling routine may execute a return from interrupt (“rfi”) instruction to return execution to the point of the previously executing routine at which the interrupt occurred, lowering the CPL back down to the CPL at which the previously executing routine had been executing prior to the interruption.

[0075] The interruption process is illustrated in FIG. 12 . In FIG. 12, a process executing an application program executes instructions from a memory page 1202 associated with the low privilege level of an application-program process. Execution of instructions from the memory page is represented by the dark, or filled-in, curved arrows 1204 - 1206 . Execution of the interruption-handling routine, at privilege level 0, is indicated in FIG. 12 by the light, or open, curved arrow 1208 . Initially, the application-program process successively executes instructions stored at memory locations 1210 - 1215 . During execution of the instruction stored in memory location 1215 , a machine interruption occurs, invoking the privilege-level-0 interruption handler, which then begins executing an instruction stored at memory location 1216 within a memory page 1218 associated with privilege level 0. The interrupt handler executes a number of instructions before finally executing an rfi instruction stored at memory location 1220 , causing the CPL to be demoted back to the low privilege level at which the application-program process had been executing prior to the occurrence of the interruption, and returning control to the application program as indicated by dark, or filled-in arrow 1205 . The application program then resumes executing, as indicated by dark, or filled-in arrow 1206 . For certain types of interruptions, the privilege-level-0 interrupt handler may execute entirely within the context of the interrupted process. In order to handle more complex interruptions, the operating system may store context information associated with the application-program process in the PCB associated with that process and prepare a new context in which the interruption handler can execute, restoring the application-program context when the application-program process is restored following handling of the interruption.

[0076] There are cases when an application-program process needs to call an operating-system subroutine or function that runs at a privilege level higher than that of the application-program process. Because the PSR can be accessed and changed only by a privilege-level-0 routine, an application program executing at a lower privilege level cannot directly modify the CPL. One way to effect such a call is to execute a “break” instruction containing an encoded parameter. This instruction causes an interruption to privilege-level-0, and the parameter encoded in the break instruction can be decoded to send control to the desired privilege-level-0 function. However, the IA-64 computer architecture provides a faster mechanism by which an application-program process may invoke a privilege-level-0 process. FIG. 13 illustrates the CPL-promotion mechanism that allows application-level routines to call higher-privilege-level routines. FIG. 13 employs the same illustration conventions as employed in FIG. 12 . The executing application program, represented by filled-in arrow 1302 , executes a call instruction stored in memory location 1304 in order to call a higher-privilege-level routine “A.” The higher-privilege-level routine is stored on a memory page 1306 associated with the higher privilege level. The higher-privilege-level routine initially executes an epc instruction, stored at memory location 1308 , which promotes the CPL to the CPL associated with the memory page that includes the instruction. The called routine can then execute at the higher privilege level, finishing execution with a br.ret instruction 1310 that returns execution to the application-level program and automatically demotes the CPL back to the CPL at which the application-level program executed prior to the subroutine call. Note that this mechanism does not provide a means for an application program to promote the CPL and carry out unauthorized access to protected computer resources. Memory pages may only be associated with privilege levels only by instructions executing at privilege level 0. Thus, routines that employ the epc CPL-promotion instruction need to be initially set up by privilege-level-0 routines. Thus, an operating system may use the epc mechanism to safely create operating-system entry points callable from lower privilege-level routines.

[0077] Cryptography

[0078] There are six basic types of cryptographic techniques: (1) symmetric (secret) key encryption; (2) asymmetric (public/private) key encryption; (3) one-way hash functions; (4) message authentication codes; (5) digital signatures; and (6) random number generators.

[0079] Encryption/Decryption

[0080] Symmetric and asymmetric key encryption both are used to scramble data so completely that an attacker lacking the correct key is unable to determine the content or meaning of the original unscrambled data. The data itself can be any form of digitized information, including letters or numbers of any language, special symbols for words or punctuation or control, or video and audio images.

[0081] The process of scrambling the data is called “encrypting,” or “enciphering” the data. The reverse operation, to unscramble the data back to its original form, is called “decrypting,” or “deciphering” the data. The original unscrambled data is called “clear text.” The scrambled data is called “cipher text.” There are many different algorithms for encrypting and decrypting. Encryption and decryption algorithms generally take two input arguments, and produce as output the encrypted or decrypted data, respectively. The first input argument is the data to be encrypted or decrypted. The second input argument is called the “key.” Best practice deems the secrecy of an encryption and decryption scheme to inhere solely in the key. Encryption and decryption can be concisely described as follows:

Cipher-text=Encrypt(Clear-text, Encrypt-key)

Clear-text=Decrypt(Cipher-text, Decrypt-key)

[0082] Symmetric Key Encryption

[0083] For symmetric key encryption, both the sender and receiver of encrypted messages employ the same secret key. For example, if the secret key were the word “applesauce”, the equations would be:

Cipher-text=Encrypt(Clear-text, “applesauce”)

Clear-text=Decrypt(Cipher-text, “applesauce”)

[0084] Keys normally used are long, randomized bit strings. The lengths of keys are determined by the specific symmetric cipher. The binary values of keys are generated by processes that are constructed to insure that the values are sufficiently unpredictable.

[0085] Symmetric ciphers are of two basic types: (1) block ciphers; and (2) stream ciphers. A block cipher encrypts or decrypts a single, fixed-size block at a time. The size of a block is defined by the specific block cipher. A streaming cipher generates a sequence of binary values that are XORed with the Clear-text to encrypt, or with the Cipher-text to decrypt. The size of each binary value generated by a stream cipher is defined by the specific stream cipher.

[0086] Symmetric key encryption executes at high speed. On grounds of security and performance, symmetric ciphers rank very highly. For any confidential, high-volume data interchange, symmetric key cryptography is the preferred choice, because of its high performance. The hard problem for deploying symmetric cryptography is the distribution and management of secret keys, aptly named the “Key Distribution Problem.”

[0087] The Key Distribution Problem, i.e. the definition of a process securely to distribute unique secret keys throughout a network, to every pair of persons or programs that needs to communicate in confidence, is very complex. Entire systems have been built solely to perform this function. One system developed dedicates entire servers simply to the task of being trusted third parties for distribution of secret keys.

[0088] Asymmetric Key Encryption

[0089] For asymmetric key encryption, the key used to encrypt data is a different key from that used to decrypt data. Unlike symmetric key encryption, which uses the same secret key both for encryption and decryption, asymmetric key encryption uses two different keys. The advantage of asymmetric key encryption is that only one of the keys needs to be kept private (i.e. secret). The other key can be widely known, i.e. can be made public. It is for this reason that asymmetric key encryption popularly is called “public/private” key encryption. Asymmetric ciphers greatly ameliorate problems of key distribution. Symbolically:

Cipher-text=Encrypt(Plain-text, public-key)

Plain-text=Decrypt(Cipher-text, private-key)

[0090] The most widely used asymmetric cipher is called “RSA,” an acronym composed of the first letters of the last names of its inventors. RSA operates upon very large integers modulo the product of two secret prime numbers. RSA public and private keys each are pairs of such large integers. For good security today, 1024 to 2048 bit integers are used, although some applications continue to use 512 bit integers. The cryptographic strength of RSA derives from the difficulty in factoring the product into the two secret primes.

[0091] More recent work has shown that finite groups of points lying on an “elliptic curve” provide a perhaps stronger base than RSA for asymmetric cryptography. The security of the schemes based upon elliptic curves derives from the difficulty in solving the discrete log problem over elliptic curves. (For details, see: Blake, Seroussi, Smart, Elliptic Curves in Cryptography , Cambridge Univ. Press, 1999.) The keys needed for computations are shorter than those needed for RSA. The elliptic curve key equivalent in strength to a 1024-bit RSA key, for example, would be fewer than 200 bits in length. The computations, however, are more complex than those for RSA. The primary disadvantage of asymmetric encryption is that it needs much, much more computation. In other words, asymmetric encryption is significantly slower than symmetric encryption. Because of the relative strengths and weaknesses of symmetric and asymmetric cryptography, a usual practice is to use asymmetric key cryptography for key distribution, and symmetric key cryptography for the bulk of the transferred data.

[0092] One-Way Hash Functions

[0093] One-way hash functions are algorithms that transform an arbitrary input bit stream into a fixed-size result. They are called “one-way” because, while it is straightforward to perform the hash function, it is provably impossible to compute the inverse of the hash function—that is, to compute the input bit stream given only the fixed-size hash function output.

[0094] Further, secure hash functions are designed so that, to the extent possible, the value of every bit of the output of the function is affected by the value of every bit of the input, and that for a given hash output value it is a prohibitively difficult task to find another input bit stream that would produce the identical hash function output. These properties of secure hash functions permit one reasonably to use the hash output value as an identifying “signature” or “digest” for the input bit stream. Hash function outputs are like digital fingerprints of the input bit stream.

[0095] Secure hash functions typically operate in two phases. First, the arbitrary-length input bit stream is padded in a specific manner to a multiple of a fixed block size. Usually, the bit length of the entire input stream appears as the final 64-bit value in the last 64-bit double word of the final pad block. Second, the padded input is processed a block at a time by the hash function, using output values from each block as initial input values to the processing of the next block. The combined result after processing the final block is the output of the hash function. Symbolically:

Message-Digest=Hash-Function(Pad-Function(M essage-Input-Bits))

[0096] Hash functions are one of the most versatile and widely employed cryptographic tools. They are used in nearly every Internet protocol. Whenever it is necessary logically to associate a number of elements, a common practice is to concatenate the byte-strings representing the elements and hash the total result. This produces a digital fingerprint reflecting every element as well as the entire, ordered association. Hash values of documents, data structures, and code images are crucial for digital signatures.

[0097] Message Authentication Codes

[0098] Message Authentication Codes (“MACs”) are designed to protect the authentication and integrity of messages and data rather than to protect their confidentiality. A MAC is a value appended to a message or data that permits one to assure that the content of the message or data has not been modified in any way.

[0099] MACs, like symmetric key encryption, use a secret key. If it is not important to protect the content of a message, but only to insure its integrity, the secret key is used to compute a MAC, which then is appended to the message. Any party who knows the secret key can recalculate the MAC from the received message, and compare the newly calculated value with the MAC appended to the received message. If the newly computed and transmitted values match, the message has been transmitted correctly.

[0100] MACs are used in secure IP (“IPSec”) to assure that packet contents have not been modified during transmission. They also are used in transfer protocols between banks to authenticate messages. MACs also can be attached to data stored in files or databases. In all cases any one knowing the secret key can verify that the data over which the MAC was calculated has not been altered. Computations of MACs utilize symmetric key encryption over the data, or sometimes over secure hashes of the data.

[0101] Digital Signatures

[0102] Digital signatures are similar to MACs in providing a guarantee of the integrity of stored or transmitted data. But digital signatures differ from MACs with respect to the secrets employed and the distribution of those secrets.

[0103] For MACs there is a non-empty set of persons who know the secret key used to compute the MAC. Any of the people in the set can verify a MAC computed with the secret key. At the same time, any of these persons also can compute a MAC for different messages or data, or can forge a MAC for an altered message or data. All the persons who know the secret need to trust each other—both to keep the secret key secret and to employ the secret key properly.

[0104] MACs work well when there is but a single individual who holds the secret. This person can use the secret to protect his or her data and to assure its integrity. MACs also work well for sets of two persons. These folks trust each other not to reveal the secret, and can send messages back and forth knowing that the integrity of each message has not been compromised. These models fit many important situations.

[0105] Digital signatures are an integrity protection mechanism where there is but a single party who is capable of constructing the signature, but everyone then is able to verify the signature. In this model, one specified party, the sole holder of the enabling secret, becomes responsible for computing and appending the signature to the data. This is called “signing” the data. After the data has been signed, anyone can verify that the specified party, more exactly, the specified secret key, in fact did compute the signature. This model fits many important commercial and practical situations.

[0106] Digital signatures are computed by using a remarkable property of asymmetric key cryptography. Namely, digital signatures also work in reverse. In the previous section on asymmetric key cryptography we wrote symbolically:

Cipher-text=Encrypt(Plain-text, public-key)

Plain-text=Decrypt(Cipher-text, private-key)

[0107] But it turns out that the keys can be used in the reverse order, namely:

Cipher-text=Encrypt(Plain-text, private-key)

Plain-text=Decrypt(Cipher-text, public-key)

[0108] In the first case the owner of the secret key does the decrypting, and anyone can do the encrypting. In the latter case, the owner of the secret does the encrypting, and anyone can do the decrypting. The latter case is used for digital signatures.

[0109] Digital signatures can be used by themselves, or in combination with encryption designed to protect confidentiality. Often, it is not important that the data contents are confidential, but it is extremely important that the data are accurate. Digital signatures are not computed by encrypting all of the data with the private key, but rather are computed by using a private key to encrypt a secure hash of the data. In effect, we first take a digital fingerprint of the data, and then encrypt the digital fingerprint with the private key. Symbolically:

Digital-Signature=Encrypt(Hash-Function(Mes sage-Input-Bits), private-key)

Digital-Fingerprint=Decrypt(Digital-Signatu re, public-key)

[0110] Digital signatures also are verified in two steps. First the digital fingerprint of the data contents is recomputed using the hash function. Then the appended digital signature is decrypted using the public key. If the recomputed digital fingerprint and the decrypted digital signature match, the signature has been verified.

[0111] Random Number Generators

[0112] Random numbers are employed throughout cryptographic algorithms and protocols. They are used for keys, challenge values, nonces, pre-hashing appendages for passwords, etc. Hardware devices based upon some form of physical randomness are beginning to appear. The problem with such hardware devices, of course, is testing them to assure they're operating correctly. Computational means exist for computing numbers that are sufficiently unpredictable that they can be used in lieu of truly random numbers. Such numbers are called “Pseudo-Random Numbers” (“PRNs”). Some of the pseudo-random number generation methods employ values based upon physical measurements of random events in a computer system, such as typing rates, arbitrary mouse motions, arrival times of disk I/O interrupts, etc. Others are based upon symmetric cryptography or the difficulty of hard mathematical problems such as the factoring problem. Pseudo random number generators (“PRNGs”) that produce sufficiently unpredictable values are called “Cryptographically Strong Pseudo Random Number Generators” (“CSPRNGs”).

[0113] The Secure-Platform Kernel Embodiment of the Present Invention

[0114] FIG. 14 illustrates layering of an operating system directly on an IA-64 processor-based machine. The operating system 1402 , in this direct layering approach, uses the IA-64 architecture-specified interface 1404 provided by the IA-64 processor-based machine 1406 as the computing resources to manage and to parcel out to application programs via operating system services. The IA-64 architecture-specified interface 1404 comprises non-privileged and privileged instructions and registers, hardware interruption mechanisms, and firmware interfaces. However, by employing a direct layering of the operating system onto the IA-64 hardware interface, the many security problems and deficiencies inherent in current operating systems cannot be easily addressed using features of the IA-64 architecture. As one example, should I/O drivers continue to be incorporated within the operating system and executed at PL 0, the problem illustrated in FIG. 6 would remain a potential vulnerability for the computer system. Operating systems are relatively large programs, and in practice impossible to verify for correctness and secure operation.

[0115] One embodiment of the present invention is a combined-hardware-and-software secure-platform interface that provides a secure layer that interfaces with one or more computer operating systems and customized control programs. The combined-hardware-and-software secure platform (“SP”) allows an operating system or customized control program to directly access, via a combined-hardware-and-software secure-platform interface (“SPI”), non-privileged machine instructions and registers as well as to invoke software routines that provide control of the hardware to an operating system or customized control program without exposing the privileged machine instructions and registers. In addition, the SP and SPI provide a set of secure repository services that include, among other things, encryption and decryption services, security policy management, and other security-related services that employ internally generated, secret data, such as encryption keys in the clear, that cannot be exposed to the operating systems and customized control programs, nor to other routines of the software portion of the combined-hardware-and-software secure platform. The SPI can be thought of as a machine interface to a machine that includes not only hardware, including one or more processors, busses, memory components, and other hardware components shown in FIG. 1 , but also firmware interfaces and an extensible set of software routines. Thus, the SPI is an interface to the SP, a composite hardware, firmware, and software machine. The SPI also can be thought of as an interface provided by a new type of software layer underlying operating systems and customized control programs.

[0116] FIG. 15 is a block diagram illustrating the SP within a computer system comprising the SP and one or more operating systems and customized control programs. The SPI 1502 lies between the software layer 1504 of the SP and one or more operating systems and/or customized control programs 1506 . The SP comprises the software layer 1504 , a hardware and firmware platform interface 1508 , and the hardware and firmware platform 1510 . As discussed above, the non-privileged instructions and registers provided at the hardware interface 1508 are directly exposed by the SPI 1502 , as indicated in FIG. 15 by vertical arrow 1512 . The other components of the hardware interface, to the right of the vertical dashed line 1514 , are not exposed. Instead, functionality provided through these hardware-interface components is made available to operating systems and customized control programs via the secure-platform-services component 1516 and secure-repository-services component 1518 of the SPI.

[0117] It is important to emphasize, in addition to the capabilities that SP provides, that the SP is quite different from an operating system or a traditional virtual machine, and the SPI is different from an operating-system interface or virtual-machine interface. A virtual machine is a software abstraction of an underlying hardware platform that either directly exposes or simulates the privileged instructions and registers and firmware interfaces of the underlying hardware platform. Virtual machines are useful in a number of situations, such as operating system development. But the SP is unlike a virtual machine interface. The SPI deliberately prevents all access to privileged instructions and registers and firmware interfaces by overlying operating systems. Moreover, the SP mechanisms provide an extensible, rich set of secure services, such as cryptographic services, that extend well beyond the scope of capabilities provided by virtual machines. SP secure services are made secure by completely compartmentalizing and isolating their code images and data from overlying operating systems and custom control programs. This compartmentalization and isolation is possible only because operating systems and custom control programs have no direct access whatsoever to privileged instructions and registers and firmware interfaces. SP encryption services, for example, are thus able to completely conceal actual values of encryption keys, and keying materials derived from encryption keys, from all operating systems, custom control programs, and application programs, while still allowing those operating systems, custom control programs, and application programs freely to employ the encryption services.

[0118] While the SP is a secure platform for operating systems, the SP does not, by itself, ensure the security of a computer system that is built upon the SP. Unlike a system control program, such as an operating system, the SP provides solely a set of callable mechanisms in addition unprivileged instructions and registers. The SP mechanisms provide basic building blocks from which a secure system can be constructed, as described below. The SP mechanisms allow an operating system to exercise sufficient control over the underlying hardware to provide full operating system services to application programs and users. But the SPI provides this functionality without exposing any privileged instructions or registers or firmware interfaces to an overlying operating system or custom control program. Internally, in the IA-64 embodiment of the invention, the SP mechanisms consistently utilize the protection capabilities of the IA-64 architecture in a manner designed to reduce vulnerabilities to virus and penetration attacks. The practices employed include: all executable code images are first validated by checking their digital signatures before they are set to be executable; executable code images never are permitted simultaneously to be both executable and writable; stacks and data areas may be read or written, but never executed; SP mechanisms are compartmentalized by the use of privilege levels and protection keys, to isolate the code and data of each mechanism from all overlying operating systems and custom control programs, and from all other SP mechanisms. Operating systems and custom control programs overlying the SP also can adopt similar memory protection practices to improve their security. But, indeed, any operating system or custom control program may fail to properly secure itself, despite being provided the tools to do so by the SP interface.

[0119] SP organizes the resources of the system into one or more disjoint, mutually isolated partitions, called “domains.” Each domain operates under the control of an operating system or custom control program. SP allocates a range of virtual memory addresses, a range of physical memory addresses, a number of logical and physical CPUs, a set of I/O devices, and a set of identifier values to each domain. In order to provide the SP services, the SP software layer needs certain specific functionality from the SP hardware layer, in addition to the non-privileged ins