Patent Application
20080256363
Computer manufacturers generally need a way to update the contents of a trusted component, such as a basic input/output system (BIOS) flash memory, to fix bugs and/or provide new capabilities. However, enabling the BIOS flash memory or other trusted component to be modified renders the trusted component susceptible to corruption by malicious or unauthorized logic. t
For a more complete understanding of the present application, the objects and advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
In the embodiment illustrated in
Firmware memory 100 is coupled to CPU 120 for performing boot-up operations and memory 110 for reading data used by firmware memory 100. In the embodiment illustrated in
In the embodiment illustrated in
Trusted systems and trusted methods are systems and methods having a sufficient level of security to prevent unauthorized changes to the contents of the trusted memory. For example, trusted systems and trusted methods may use strong security methods, such as cryptographic algorithms including RSA Verify, Elliptic Curve Cryptography (ECC), Digital Signature Algorithm (DSA), the Secure Hash Algorithm 1 (SHA-1) and SHA-2 to ensure that a trusted source produced a certain digital file and/or that the digital file has not been changed or tampered with since the trusted source produced it. Trusted systems and trusted methods ensure that the digital file can be trusted prior to using the digital file to modify trusted memory. In this manner, logic that is unauthorized by the trusted source, as well as viruses, can be kept out of trusted memory, even though the trusted memory is modifiable.
In the embodiment illustrated in
Hash logic 104 is executed to verify the integrity of a digital file by performing a hash function, which is a mathematical operation producing a hash value as a result. In some embodiments, hash logic 104 comprises the SHA-1 algorithm, although other hash functions may be used alternatively or in addition. Hash value 105 is a previously computed integrity validation value, which is a number used for validating that a digital file (e.g., an executable computer program) has not been tampered with. In operation, hash logic 104 is executed on a digital file in order to calculate a hash value which is compared to a hash value 105 stored in firmware memory 100. Thus, if the calculated hash value corresponds to and/or otherwise matches hash value 105, the digital file is considered trustworthy. Hash logic 104 and hash value 105 are stored in boot block 102, which resides in firmware memory 100. In some embodiments, hash logic 104 and hash value 105 are initially placed in boot block 102 when computing system 121 is manufactured, refurbished, updated or repaired. Thus, update system 10 is able to extend trust from boot block 102 to digital files stored outside of firmware memory 100, thereby creating a chain of trust.
In the embodiment illustrated in
In some embodiments, digital signature 115 comprises an alphanumeric sequence attached to signed update 112 by the author of signed update 112, which uniquely identifies the author and also provides a basis for ensuring file integrity with a hash algorithm. Signature verification data 113 is data used by verify logic 111 to perform independent calculations using digital signature 115 and other portions of signed update 112. For example, in some embodiments, signature verification data 113 comprises a hash of update data 116 signed and/or encrypted by a private key of the trusted party. Verify logic 111 hashes at least a portion of signed update 112, for example update data 116, decrypts digital signature 115, and determines whether the hash of update data 116 corresponds to the decrypted digital signature 115. If the two values correspond, signed update 112 is considered to be a verified replication of a file authored by the trusted party that has not been tampered with since being produced. In some embodiments, verify logic 111 comprises RSA Verify, which is an algorithm suitable for digital signature verification.
Update data 116 comprises information to be used for modifying the contents of firmware memory 100, such as the contents of boot block 102, hash logic 104, hash value 105 and boot instructions 106. In some embodiments, signed update 112 may further or alternatively comprise modification information for verify logic 111. In some embodiments, signed update 112 comprises an executable patch program capable of modifying the contents of boot block 102 without using update logic 114.
In some embodiments of operation of update system 10, a manufacturer of computing system 121 or other entity generates verify logic 111 with signature verification data 113 that uniquely identifies the entity as a trusted source for future updates to firmware memory 100. The entity hashes all or a portion of verify logic 111 with a duplicate of hash logic 104 to calculate hash value 105. Hash logic 104, hash value 105 and boot instructions 106 are stored boot block 102 within firmware memory 100, and verify logic 111 is stored in memory 110. In some embodiments, each time computing system 121 boots up, boot instructions 106 search for an indication that an update, such as signed update 112, is available and/or waiting (e.g., waiting in memory 110, a hard disk or other storage medium) to be used to modify the contents of firmware memory 100. For example, during a previous use of computing system 121, the entity may have sent an electronic message over a computer network placing signed update 112 in memory 110.
If signed update 112 is found, hash logic 104 validates the integrity of verify logic 111 by hashing all or a portion of verify logic 111 and comparing the result of the hashing with hash value 105 to ensure that verify logic 111 has not been tampered with. If verify logic 111 is valid (i.e., it is considered to not have been tampered with based on the hash value of verify logic 111 corresponding to hash value 105), boot block 102 causes execution of verify logic 111 to verify the authorship of digital signature 115 using signature verification data 113. For example, in some embodiments, verify logic 111 is used to verify a digital signature file (e.g., digital signature 115) associated with signed update 112 by using a cryptographic method such as the RSA digital signature verification algorithm. Thus, in some embodiments, digital signature 115 represents a pre-calculated hash value of at least a portion of update data 116 that has been encrypted by a private key of a trusted party. In operation, verify logic 111 decrypts digital signature 115 (e.g., using signature verification data 113, such as a paired public key to the trusted party's private key), hashes a corresponding portion of update data 116, and compares the calculated hash value to the decrypted digital signature 115. If the verification of digital signature 115 is successful, boot block 102 executes update logic 114 to modify the contents of firmware memory 100, such as boot block 102, using update data 116. Thus, embodiments of system 10 enable a manufacturer or other trusted entity to fix bugs and/or otherwise modify firmware memory 100 while minimizing the risk of unauthorized or malicious changes to firmware memory 100 by an unauthorized entity.
At block 201, boot block 102 determines whether signed update 112 is present (e.g., present in memory 110 or elsewhere). If no signed update 112 is present, the method proceeds to block 222, where boot block 102 continues to boot computing system 121. If signed update 112 is available or present, boot block 102, hash logic 104 hashes verify logic 111 to produce a newly calculated hash value at block 204. At block 206, the newly calculated hash value is compared with hash value 105 stored in firmware memory 100 to determine the validity of verify logic 111. If, at decision block 208, the newly calculated hash value does not correspond to hash value 105, trusted component 90 will not be updated with such update, and boot block 102 instead continues to boot computing system 121 at block 222. If, at decision block 208, the newly calculated hash value corresponds to hash value 105, the method proceeds to block 212.
At block 212, verify logic 111 is executed and used to verify the digital signature of signed update 112 by hashing update data 116. At block 214, verify logic 111 decrypts digital signature 115 using signature verification data 113 and compares the hash of update data 116 with the decrypted digital signature 115 at block 216. If, at decision block 218, the hash of update data 116 does not correspond to decrypted digital signature 115, the digital signature of signed update 112 is not verified, and such update will not be loaded, installed or implemented, but instead boot block 102 continues to boot computing system 121 at block 222. If, at decision block 218, the hash of update data 116 does match the decrypted digital signature 115, the digital signature of signed update 112 is considered verified valid, and trusted component 90 is updated with update data 116 by executing update logic 114 at block 220. Boot block 102 continues to boot computing system 121 at block 222.
Thus, embodiments of update system 10 enable field updates to be made to trusted memory. It should be understood that in the described method, certain functions may be omitted, accomplished in a sequence different from that depicted in
