Microcode patch authentication

BACKGROUND

[0001] A typical instruction in a computer processor performs a series of operations, with microinstructions that define each operation being encoded in a non-volatile storage area in the form of microcode. The microcode defines all or a portion of the executable instruction set for the processor, and may also define internal operations that are not implemented in software-accessible code. The microcode is typically placed in a read-only memory (ROM) within the processor at the time the processor is manufactured. However, microcode sometimes needs to be modified after the processor is manufactured, and even after the processor has been placed into operation. Microcode patches allow such modification by inserting new microinstructions in place of the original microinstructions. The microcode patches can be delivered to the processor in various ways (such as by being downloaded over a communications channel, installed by a service technician, or provided with an operating system), and are then stored in the processor for operational use. Since the microcode ROM cannot be easily altered, microcode patches are typically placed into a patch memory within the processor, such as a random-access memory (RAM), and references to the modified microinstructions are redirected into the patch RAM rather than the ROM. Because the patch RAM may be volatile, the microcode patches are usually stored either on disk or in the Basic Input-Output System (BIOS), and are loaded into the patch RAM when the system is booted.

[0002] If a processor is to be used in a secure environment, various security measures should be taken in the design of the software and/or hardware to provide protection against tampering with the operation of the secure features. The ability to insert unauthorized microcode patches into a processor represents one way that a hostile attacker may thwart conventional security measures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The invention may be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention.

[0004]FIG. 1 shows a block diagram of a system to validate and install microcode patches, according to one embodiment of the invention.

[0005]FIG. 2 shows a block diagram of a system to convert microcode patches into a secure form for delivery, according to one embodiment of the invention.

[0006]FIG. 3 shows a patch package containing elements delivered from the system of FIG. 2 to the system of FIG. 1, according to one embodiment of the invention.

[0007]FIG. 4 shows a flow chart of an overall process for preparing, delivering, and validating a patch package, according to one embodiment of the invention.

[0008]FIG. 5 shows a flow chart of a process for preparing a patch package, according to one embodiment of the invention.

[0009]FIG. 6 shows a flow chart of a process for validating a patch package, according to one embodiment of the invention.

DETAILED DESCRIPTION

[0010] In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure an understanding of this description. References to “one embodiment”, “an embodiment”, “example embodiment”, “various embodiments”, etc., indicate that the embodiment(s) described may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes the particular feature, structure, or characteristic. Also, the features, structures, or characteristics described for different embodiments may be combined into a single embodiment. Further, repeated use of the phrase “in one embodiment” does not necessarily refer to the same embodiment, although it may.

[0011] References herein to cryptography may include one or both of encryption and decryption. References herein to “symmetric” cryptography, keys, encryption, or decryption, refer to cryptographic techniques in which the same key is used for encryption and the associated decryption. The well known Data Encryption Standard (DES) published in 1993 as Federal Information Publishing Standard FIPS PUB 46-2, and Advanced Encryption Standard (AES), published in 2001 as FIPS PUB 197, are examples of symmetric cryptography. Reference herein to “asymmetric” cryptography, keys, encryption, or decryption, refer to cryptographic techniques in which different but related keys are used for encryption and the associated decryption. So called “public key” cryptographic techniques, including the well-known Rivest-Shamir-Adleman (RSA) technique, are examples of asymmetric cryptography. One of the two related keys of an asymmetric cryptographic process is referred to herein as a private key (because it is generally kept secret), and the other key is referred to as a public key (because it is generally made freely available). In some embodiments either the private or public key may be used for encryption while the other key is used for the associated decryption.

[0012] Embodiments of the invention may be implemented in one or a combination of hardware, firmware, and software. Embodiments of the invention may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by at least one processor to perform the operations described herein. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), and others.

[0013] Various embodiments of the invention involve the encoding and/or decoding of a microcode patch (also referred to herein simply as a ‘patch’) so that the patch can be authenticated as valid before being installed in a target processor (a processor in which the patch is intended to be used). Encoding/decoding may include one or more of: 1) encryption/decryption, 2) the use of cryptographic hash functions, 3) the use of digital signatures, 4) etc. A target system is the system in which the patch is to be installed, while an originating system is the system that prepares the patch for secure delivery to the target system. In one embodiment, a common set of patches is produced for a particular type of computer system, where “type” may indicate a particular generation, a particular model number, some category within the model number, etc. Once a patch is produced, it may be encoded in the manner described herein before delivery to each of the target systems for which it is intended. Within each target system, one or more patches may be decoded and installed as described herein so that the patches become an operational part of the target system.

[0014] Any convenient method of delivery may be used, including but not limited to delivery over a communications link, installation by a technician, inclusion in an operating system by the manufacturer of that operating system, inclusion in a basic input output system (BIOS), etc. Once delivered, the patch may be stored in its encoded form until it is operationally installed. Operational installation includes decoding the encoded patch, validating that the patch is authorized, and placing the patch into a patch memory. Validating may include either or both of: 1) determining that the patch has not been modified since it was prepared for delivery in the origination system, and 2) determining that the patch was prepared in an authorized system. In one embodiment, the encoded patch is stored on disk or in the BIOS of the target system, to be operationally installed in volatile patch RAM each time the system is booted. In another embodiment, the encoded patch is operationally installed in non-volatile patch memory and is not reinstalled during subsequent reboots.

[0015]FIG. 1 shows a block diagram of a system to validate and install microcode patches, according to one embodiment of the invention. In the illustrated embodiment of FIG. 1, system <b>100</b> includes a processor <b>110</b>, chipset <b>130</b>, disk <b>140</b>, main memory <b>150</b>, and communications interface (Comm I/F) <b>160</b>. Processor <b>110</b> may include microcode ROM <b>112</b>, a patch memory <b>114</b>, a secure memory <b>118</b>, and one or more keys <b>116</b>. Chipset <b>130</b> may include BIOS <b>132</b>. A patch package, described later, may be stored in at least one of disk <b>140</b>, BIOS <b>132</b>, or another part of system <b>100</b> that includes non-volatile storage.

[0016] In some embodiments, the operations of decoding, validating and installing the patch may be performed by a sequence of microinstructions contained in microcode ROM <b>112</b>. In a particular embodiment the sequence is initiated by executing a special instruction that transfers execution to the entry point of the sequence. In another particular embodiment the sequence is initiated in response to writing a predetermined value to a predetermined section of a machine-specific register (MSR). Other methods may also be used to initiate the sequence.

[0017] The data being operated upon during the decoding, validating and installing of the patch may be located in secure memory <b>118</b>, which may be secured in a manner that makes it unavailable for access by non-secure code. In some embodiments secure memory <b>118</b> may contain, at various times, the encoded patch, the decoded patch, and interim products created during decoding of the encoded patch. In one embodiment, secure memory <b>118</b> does not have enough capacity to hold all of the aforementioned patches and/or interim products, and may simultaneously contain only portions of one or more of the encoded patch, decoded patch, and the interim products.

[0018] In one embodiment, secure memory <b>118</b> is a dedicated RAM memory which may be disposed either inside or outside of processor <b>110</b>, that is used only for secure operations. In another embodiment, secure memory <b>118</b> is a dedicated cache of processor <b>110</b>, and access to the dedicated cache is blocked to all other operations during the decoding, validating, and installing of the patch. Other embodiments may use other methods of providing secure memory <b>118</b> during the described operations.

[0019] Although system <b>100</b> illustrates a particular embodiment, other embodiments may also be used. For example, in one embodiment, BIOS <b>132</b> may be included in processor <b>110</b>, and another embodiment may not have a chipset <b>130</b>.

[0020] In one embodiment, keys <b>116</b> are one or more security keys (values that are used in encoding and/or decoding) that have been embedded in processor <b>110</b>. “Embedded” keys are manufactured into the processor <b>110</b> in a manner that prevents them from being changed by system <b>100</b>'s software and that prevents them from being read by non-secure software. In a particular embodiment, embedded keys may not be read directly by any software, but one or more particular instructions may cause a specific embedded key to be transferred into other hardware for use in a decoding sequence.

[0021] In one embodiment, a particular embedded key is one of the two keys for an asymmetric cryptographic algorithm, with the other of the two keys being kept in the patch origination system under secure control. In another embodiment, a particular embedded key includes a hash value of a public key for an asymmetric cryptographic algorithm, the public key being delivered with the associated patch. Other embodiments may include other types of keys as embedded keys.

[0022] In some embodiments, microcode <b>112</b> is located in non-volatile storage such as read only memory (ROM) and cannot be directly altered after manufacture. A patch may be placed in patch memory <b>114</b> for system operation so that in response to a reference to a section of modified microcode, the reference is redirected to patch memory <b>114</b> to access the modified microcode. In one embodiment patch memory <b>114</b> includes RAM, and the patch is installed in the RAM of patch memory <b>114</b> each time the system <b>100</b> is reset and/or rebooted. In another embodiment patch memory <b>114</b> includes a non-volatile form of memory such as flash memory, and once installed, each patch remains intact in patch memory <b>114</b> until the patch is replaced by a subsequent patch.

[0023] Before installation, an encoded patch may be stored in non-volatile memory such as the BIOS <b>132</b> or on disk <b>140</b>, to be decoded and validated each time the patch is installed in patch memory <b>114</b>. In one embodiment, a patch from a BIOS vendor may be stored in BIOS <b>132</b> and installed by BIOS-resident code during an initial boot process. In another embodiment, a patch from an operating system (OS) vendor may be stored on disk and installed by an OS boot loader later in the boot process. Both embodiments may be combined in the same system.

[0024] In one embodiment, patches are delivered over a communications correction (e.g. the Internet) and are received through Comm I/F <b>160</b> and stored for use. In other embodiments, patches may be delivered through other means.

[0025]FIG. 2 shows a block diagram of a system to convert patches into a secure form for delivery, according to one embodiment of the invention. In the illustrated embodiment of FIG. 2, system <b>200</b> includes a processor <b>210</b>, chipset <b>230</b>, disk <b>240</b>, main memory <b>250</b>, and communications interface <b>260</b>. The basic functions of each of these devices may be similar to their counterparts in FIG. 1. However, as an originator of patches, in one embodiment system <b>200</b> is in a protectable centralized installation where protection against attackers may be provided for the overall system <b>200</b>. In the illustrated embodiment, this protection may be provided by a secure perimeter <b>270</b>. As used herein, the term “perimeter” is conceptual rather than physical, and secure perimeter <b>270</b> may include numerous protective measures, including but not limited to physical protection of the system <b>200</b>, limited access of personnel to the system <b>200</b>, a firewall or other protective software device to prevent unauthorized invasion of the system through communications interface <b>260</b>, etc. System <b>200</b> may also utilize internal security features similar to those shown in FIG. 1. In one embodiment, system <b>200</b> is used to generate patch packages for a single type of target system. In another embodiment, system <b>200</b> is used to generate different patch packages for multiple types of target systems. The code for the patches may either be generated in system <b>200</b>, or may be generated elsewhere and delivered to system <b>200</b> for preparation of the associated patch packages. Information to be used and stored in system <b>200</b> may include one or more of, but is not limited to, non-encrypted patches <b>244</b>, encrypted patches <b>242</b>, and associated keys <b>246</b>, all of which are shown stored on disk <b>240</b>. Since different target systems may require different patches and involve different keys, disk <b>240</b> may be segmented into different storage areas, each storage area for a separate set of patches and associated key(s).

[0026]FIG. 3 shows a patch package containing elements deliverable from the system of FIG. 2 to the system of FIG. 1, according to one embodiment of the invention. In one embodiment, a patch package <b>300</b> includes a patch header <b>310</b>, a patch <b>320</b>, and a digital signature <b>330</b>. Another embodiment may also include one or more deliverable keys <b>340</b>. The patch header <b>310</b> contains identifying information that may identify one or more of, but is not limited to, the following: the type of target system for which the patch is intended, the type of patch, where the patch is to be used, how the patch is to be used, and any other relevant information that may be needed by the target system <b>100</b>. In one embodiment, patch header <b>310</b> is not encrypted, to facilitate identification and disposition of the patch package <b>300</b> by the target system <b>100</b> before authentication and/or decryption of the patch. Patch <b>320</b> contains the microcode for placement in patch memory <b>114</b>, although patch <b>320</b> may be in encrypted form while in patch package <b>300</b>. Encryption of patch <b>320</b> may be used to protect trade secrets or other confidential information that could be derived from the patch itself. Digital signature <b>330</b> includes data for validating the authenticity of the patch to be installed, so that a change to the patch after preparation of the patch package may be detected. In one embodiment the digital signature <b>330</b> is generated only for patch <b>320</b>. In another embodiment the digital signature <b>330</b> is generated for both the patch <b>320</b> and the patch header <b>310</b>, so that an unauthorized alteration to either may be detected by the target system <b>100</b>. In still other embodiments, the digital signature <b>330</b> may also be generated for other components of patch package <b>300</b>.

[0027] In one embodiment, all keys needed by target system <b>100</b> are embedded in processor <b>110</b> at the time of manufacture. For a particular such embodiment, patch package <b>300</b> does not include any keys to be used in decoding the patch. In another particular embodiment, one or more of the keys to be used by the system <b>100</b> are delivered to the system <b>100</b> as a part of patch package <b>300</b>, and are designated herein as deliverable keys <b>340</b> (the plural term “keys” also encompasses embodiments having only a single deliverable key). Deliverable keys <b>340</b> may be associated with other keys that are used either in target system <b>100</b> or origination system <b>200</b>. For example, in a particular embodiment a deliverable key includes the public key of a public/private key pair in an asymmetric cryptographic algorithm, with the private key remaining in the origination system <b>200</b>, and a hash value derived from the public key is embedded in processor <b>100</b> and is used to validate the authenticity of the delivered public key. An embedded hash value may also be used to validate one or more keys provided through other means, e.g. key(s) placed on disk with an operating system upgrade or placed into BIOS with a BIOS upgrade. Other embodiments may use other combinations of keys and encryption schemes. Each of the elements of patch package <b>300</b> is described in more detail later in the disclosure.

[0028] In still another embodiment, an embedded key or hash value may be used with a chain of key certificates. In one such embodiment, the embedded key or hash value is used to validate a second key, which is used to validate a third key, etc., thus providing multiple layers of security with each key associated with a particular layer. The keys may be delivered through one or more of the previously mentioned delivery methods, and/or through other methods not described.

[0029]FIG. 4 shows a flowchart of an overall process for preparing, delivering and validating a patch package according to one embodiment of the invention. In the illustrated embodiment of FIG. 4, flowchart <b>400</b> has two parts. Blocks <b>410</b> through <b>430</b> show a patch origination process, in which a patch origination system prepares an existing patch for secure delivery. Blocks <b>440</b> through <b>495</b> show a patch validation/installation process, which is performed in the target system.

[0030] In one embodiment, the patch origination process begins with encrypting the patch at block <b>410</b>. As previously mentioned, some embodiments may not encrypt the patch because the contents of the patch are not considered confidential and do not need protection. Whether the patch is encrypted or not, the operations of blocks <b>420</b> and <b>430</b> may be used to permit detection of tampering with the patch before its installation in the target system. At block <b>420</b>, a digital signature is generated for the patch. In one embodiment, the digital signature is generated for both the patch header and the patch so that neither may be tampered with without detection. In another embodiment, the digital signature is generated for the patch but not the patch header. In still another embodiment the digital signature is also generated for the deliverable keys. At block <b>430</b> the digital signature and the patch, along with any other included elements, are combined to form a patch package. If the patch was encrypted at block <b>410</b> then the encrypted patch is included at block <b>430</b>.

[0031] After the patch package is created, the patch package may be delivered to the target system through any feasible means. The patch validation/installation process, which takes place in the target system, begins at block <b>440</b> with the patch package being received and stored. The patch package may be stored on the disk <b>140</b>, in the BIOS <b>132</b>, or in any feasible storage location in target system <b>100</b>. In one embodiment, patches are not installed in an operational condition until the system is booted, a process which begins at block <b>450</b>. At block <b>460</b>, the digital signature from the patch package is decrypted and is used to validate the patch at block <b>470</b>. Decryption and validation may take any of several forms as described later. If the patch was encrypted at block <b>410</b>, then it is decrypted at block <b>480</b> to expose the actual patch. At block <b>490</b>, the exposed patch is installed in processor <b>110</b> in a manner that makes it operational. At block <b>495</b>, processor <b>110</b> may operate using the patched microcode.

[0032]FIG. 5 shows a flowchart of a process for preparing a patch package, according to one embodiment of the invention. Flowchart <b>500</b> shows a more detailed description of the patch origination process of FIG. 4. The embodiment shown in FIG. 5 includes an encryption of the patch and the creation of a digest to be used to validate that the received patch is correct. In one embodiment, encryption of the patch is performed with a symmetric encryption algorithm (e.g., AES, DES, etc.) A digest, as used herein, is a parameter obtained by performing an operation on a block of data, in which identical blocks of data produce identical digests, but any change in the block of data is likely to produce a different digest. In one embodiment the digest is a hash digest, i.e., a digest created by applying a hashing algorithm to the patch. In one embodiment the digest is created first and then the patch is encrypted, while in another embodiment the patch is encrypted first and then the digest is created for the encrypted patch. FIG. 5 shows both embodiments. In the first embodiment, at block <b>510</b> the unencrypted patch and the patch header are subjected to a hash process to create a digest. In a particular embodiment, the hash process uses the Secure Hash Algorithm (SHA-1), published in 1994 under the Federal Information Publishing Standard FIPS PUB 180-1. Subsequently, at block <b>520</b> the patch is encrypted. If the patch is not to be encrypted, block <b>520</b> may be omitted. In the second embodiment, at block <b>530</b> the patch is encrypted first and at block <b>540</b> the encrypted patch and the patch header are subjected to the hash process to create the digest. In either embodiment, if a subsequent operation requires that the digest consist of a certain number of bits, at block <b>550</b> the digest may be padded (i.e., data added to it) to increase the number of bits as needed. The pad may consist of predetermined data or random data. At block <b>560</b>, the padded digest is encrypted to create a digital signature. In one example, the padded digest is encrypted using the private key of a public/private key pair in an asymmetric encryption process. In a particular embodiment, the encryption follows the RSA encryption process using a 2048-bit private key. As is well known, in the RSA encryption process both the key and the encrypted message have the same number of bits, necessitating that the digest be padded at block <b>550</b> if the digest is smaller than the key. In another embodiment, the digest and the key are already the same size and the padding at block <b>550</b> may be eliminated. In still another embodiment, an encryption method is used in which the key and the message do not need to be the same size, in which case the padding at block <b>550</b> may also be eliminated. At block <b>570</b>, the digital signature, the patch (encrypted or not encrypted) and the patch header are combined into a patch package for a delivery to the target system. In one embodiment, the patch package may also include other information, depending on the requirements of the system.

[0033]FIG. 6 shows a flowchart of a process for validating a patch package, according to one embodiment of the invention. Flowchart <b>600</b> shows a more detailed description of the patch validation and installation process of FIG. 4. At block <b>610</b>, the patch package is obtained from within the target system. In one embodiment the patch package was previously received by the target system and placed in storage, and is obtained from that storage. In another embodiment the patch package is obtained at block <b>610</b> as soon as it is received by the target system, without intermediate storage. While in one embodiment the entire patch package as delivered by the originating system is obtained, in another embodiment any unnecessary elements of the package are stripped away before the patch package is obtained.

[0034] In one embodiment in which a key is delivered in the patch package, a hash value may be calculated for the key at block <b>612</b>. If this calculated hash value matches an associated hash value embedded in processor <b>110</b>, then the key has been validated and may be used in subsequent validation operations. If the calculated hash value does not match the embedded hash value, then validation fails and control may move to block <b>690</b>, which is described later. In an embodiment that does not involve a delivered key, the operations of blocks <b>612</b> and <b>614</b> may be omitted.

[0035] At block <b>620</b>, the digital signature is decrypted to obtain the digest created in the originating system. In one embodiment, the digital signature was generated with an asymmetric encryption algorithm using the private key of a public/private key pair, and the decryption of block <b>620</b> is performed using the associated public key. If the digest was padded during creation, then the operation of block <b>620</b> obtains the padded digest, and at block <b>630</b> the pad is removed to expose the digest that was previously generated in block <b>510</b> or block <b>540</b>. If the digest was not padded during creation, then the operation of block <b>620</b> produces the non-padded digest, and block <b>630</b> may be omitted.

[0036] At this point, the process followed depends on whether the digest was created before or after the patch was encrypted in flowchart <b>500</b>. In an embodiment in which the digest was created before encryption as shown in blocks <b>510</b> and <b>520</b>, then at block <b>640</b> the patch is decrypted and a hash function is performed on the decrypted patch and patch header at block <b>650</b> to get a calculated digest. At block <b>660</b> the calculated digest is compared with the actual digest obtained in blocks <b>620</b>-<b>630</b> to see if the two digests match. If the two digests are equivalent, then the patch has been validated and the patch may be installed at block <b>680</b>. In one embodiment, installing the patch includes placing the patch into the patch memory <b>114</b> of processor <b>110</b> in such a manner that any attempted access to the patched microcode will be directed to the patch memory <b>114</b> rather than to the original microcode <b>112</b>.

[0037] Returning to block <b>630</b>, in an embodiment in which the patch was encrypted before creation of the digest at blocks <b>530</b> and <b>540</b>, at block <b>645</b> the encrypted patch and header may be subjected to a hash operation to get the calculated digest. At block <b>665</b>, the calculated digest may be compared with the actual digest uncovered at block <b>630</b> to see if they match. If they are found to be equivalent, then the patch has been validated and the patch may be decrypted at block <b>670</b>. The validated and decrypted patch may then be installed at block <b>680</b>. In both embodiments, the hash operation used at blocks <b>645</b>, <b>650</b> is the same hash operation that was used at blocks <b>510</b>, <b>540</b>.

[0038] If the calculated digest does not match the actual digest at either block <b>660</b> or block <b>665</b>, this indicates that the patch package has been altered since its creation or is otherwise unsuitable for installation. Such alteration/unsuitability may have several causes, including but not limited to: a deliberate attempt by an unauthorized person to change the patch, an undetected/uncorrected data transmission error during delivery, delivery of the patch package to an incorrect target system, software or hardware failure, or human error. Regardless of the cause, if the actual digest does not match the calculated digest, the patch installation process may be aborted at block <b>690</b> by not installing the non-validated patch. Aborting the patch installation may take several forms, including but not limited to: 1) attempting to reinstall the patch, 2) skipping the defective patch but installing other patches, 3) reverting to a previous version of the patch, 4) shutting the system down, 5) rebooting the system, 6) etc.

[0039] In one embodiment, the validation process of blocks <b>610</b>-<b>670</b> is performed for the entire patch in secure memory <b>118</b>, and after validation the entire patch is installed in patch memory <b>114</b> at block <b>680</b>. In another embodiment, in which secure memory <b>118</b> does not have enough capacity to perform the entire validation process, the validation process of blocks <b>610</b>-<b>670</b> may be performed incrementally on separate portions of the patch. If any portion is not validated in this manner, the process may be aborted at block <b>690</b> as previously described. If all portions are validated in this manner, the patch may be validated incrementally a second time, with each portion being installed in patch memory <b>114</b> as it is validated. If any portion of the patch is not validated on the second pass (which could indicate it was tampered with after the first validation), the process may be aborted at block <b>690</b>. If the patch has been partially installed before being aborted at block <b>690</b>, the abort process of block <b>690</b> may include removing the newly-installed patch from patch memory <b>114</b>, in addition to one or more of the previously listed abort processes.

[0040] The foregoing description is intended to be illustrative and not limiting. Variations will occur to those of skill in the art. Those variations are intended to be included in various embodiments of the invention, which are limited only by the spirit and scope of the appended claims.