Patent Application
20120233449
1. Field of the Invention
The invention relates generally to implementations of self-protecting drives (“SPD”) and methods for maintaining the security of self-protecting drives without relying on the transitive chain of trust.
2. Description of Related Art
A Trusted Platform Module (“TPM”) is the name of a specification and standard that describes how to measure and verify the trustworthiness of a computing platform, in conjunction with accompanying BIOS code, which may be rooted in the core root of trust for measurement (“CRTM”). The TPM Specification is the work of the Trusted Computing Group (“TCG”), which has created a number of “trusted computing” specifications, including “TCG Storage Architecture Core Specification,” “Storage Work Group Storage Interface Interactions Specification,” “Storage Work Group Storage Security Subsystem Class: Opal,” “Storage Work Group Storage Security Subsystem Class: Enterprise,” and “Storage Work Group Storage Security Subsystem Class: Optical,” each of which are incorporated herein by reference, in their entirety.
Laptops, netbooks, and other computer platforms may contain both TPMs and self-protecting drives (“SPDs”). In a known system, e.g., the system disclosed in Patent Application Publication No. US 2009/0172378 A1, the integration of TPM and SPD functionality utilized a program loaded from the SPD to the pre-OS boot environment to provide integrity services during the boot of a computing platform. Known TPM systems relying on TCG Specifications may be found in Patent Application Publication No. US 2009/0172378 A1, U.S. Pat. Nos. 7,461,270 B2, and 7,426,747 B2, each of which are hereby incorporated by reference in their entirety.
The TPM stores, protects, and reports various measurements of the PC's (“Personal Computer”) integrity. The TPM also generates and stores cryptographic keys (for example, a public/private key pair) that may be used to authenticate those integrity measurements using, for example, digital signature and verification.
According to the standards promulgated by the TCG in the TPM Specification, various metrics may be utilized to characterize the integrity or trustworthiness of a particular PC. For example, every operating system (“OS”) platform includes a set of device drivers, executables, and other software components. A measurement, e.g., a hash digest, of the OS components when the OS is in a trusted state, e.g., a state in which the OS is initially installed on the PC, may function as an integrity metric. A comparison of that trusted measurement with a measurement taken at some later point in time would indicate whether the OS components had been altered or changed in some way. Particularly, any hash digest of the PC's software configuration potentially may be used as a measurement to later verify the integrity of that configuration.
In a known system, e.g., the system disclosed in Patent Application Publication No. US 2009/0172378 A1, the integrity of a PC's computing platform may be verified through the use of a transitive chain of trust. A transitive chain of trust is an iterative process that begins with a root of trust established in the PC that is configured to describe a trustworthy state of a second group of measurement functions. Based on this description, a verifier may determine the level of trust that it will place in this second group of functions. If the verifier determines this second group of functions to have an acceptable level of trustworthiness, then the trust boundary is extended from the root of trust to include the second group of functions. The now-trusted second group of functions may now be utilized to describe a trustworthy state of a third group of functions, which extends the trust boundary to the third group of functions, and so on.
The transitive trust model may be applied to measuring the integrity or trustworthiness of the components of the PC. The TCG's trusted computing standard currently describes two models for measuring the integrity of the components of the PC: static root of trust for measurement (“SRTM”) and dynamic root of trust for measurement (“DRTM”). The SRTM model uses a known starting state, e.g., the PC's power-on BIOS boot block, as a CRTM. Nevertheless, these systems rely on the integrity of the system running before them, and thus may be susceptible to malicious attacks directed at a CRTM.
Therefore, a need has arisen for systems and methods for verifying the integrity of storage devices without relying solely on the transitive chain of trust. In an embodiment, the SPD is enhanced with a template, e.g., the “Verifier SP Template” which may be instantiated along with a Locking SP that provides SPD services for self-verifying the TPM environment, including TPM-created PCRs, verification of TPM public key quoting, and TPM device identity as well as TPM-attested individual or domain identity using an Attestation Identity Key (“AIK”). In the invention, additional functions are implemented for ensuring that corruptions of software running in the preboot or OS-present environments do not impact the decisions made by the SPD to unlock itself for normal reading and writing, or the integrity of the TPM attestations to the SPD.
In an embodiment of the invention, the Verifier SP Template also contains methods for the SPD to report out its own internal verification that the firmware and possibly the hardware of the SPD have not been tampered with. This may be done in such a way that the TPM-based measurements can be extended to the firmware and hardware inside the security boundary of the SPD. Moreover, in an embodiment of the invention, the integrity of the pre-boot execution environment also may be evaluated inside the security boundary of the SPD.
In an embodiment of the invention, a method for measuring the trustworthiness of a self-protecting drive comprises receiving a measurement from an element within a transitive chain of trust, processing the received measurement, storing the measurement as a verification value, comparing the verification value with a reference verification value stored on the self-protecting drive, and unlocking at least a portion of the self-protecting drive when the reference verification value corresponds to the verification value.
In another embodiment of the invention, a self-protecting drive comprises a boot partition comprising an alternate master boot record, a trusted partition, a master boot partition comprising a master boot record, a primary partition, a secondary partition, and a particular table comprising a verification platform configuration register and a reference platform configuration register, wherein the primary partition is configured to be inaccessible until the self-protecting drive determines that a value stored in the verification platform configuration register corresponds to a value stored in the reference platform configuration register.
In still another embodiment of the invention, a computer system comprises a BIOS configured to execute a startup procedure and to send a measurement, and a self-protecting drive configured to receive the measurement. The self-protecting drive comprises, a boot partition comprising an alternate master boot record, a trusted partition, a master boot partition comprising a master boot record, a primary partition, a secondary partition, and a particular table comprising a verification platform configuration register configured to store a value generated from the measurement, and a reference platform configuration register configured to store a predetermined value, wherein the primary partition is configured to be locked until the self-protecting drive determines that the generated value stored in the verification platform configuration register corresponds to the predetermined value stored in the reference platform configuration register.
Other objects, features, and advantages of the invention will be apparent to persons of ordinary skill in the art in view of the foregoing detailed description of the invention and the accompanying drawings.
For a more complete understanding of the invention, needs satisfied thereby, and the objects, features, and advantages thereof, reference now is made to the following description taken in connection with the accompanying drawings.
Embodiments of the invention, and their features and advantages, may be understood by referring to
In accordance with an illustrative embodiment of the invention,
PC platform 100 includes a central processing unit (“CPU”) 120 that is directly or indirectly coupled to, for example, a random access memory (“RAM”) 130, a controller 140, and a display 150. Controller 140, which may or may not be integrated into any one of the previously described components, may be directly or indirectly coupled to a boot read-only-memory (“ROM”) 160 and TPM 110. Controller 140 may be further coupled to various embedded devices 170 and/or removable devices 180, and a self-protecting drive (“SPD”) 190. Boot ROM 160 may include a BIOS 160a and may also include one or more Option ROMs or platform extensions 160b. TPM 110 may include one or more shielded memory locations used to protect and report integrity measurements, called platform configuration registers (“PCRs”) 110a.
SPD 190 may include a primary partition 240, and a trusted partition 220. SPD 190 may also include one or more additional partitions, e.g., a secondary partition 250. Primary partition 240 may store the OS, applications and the Platform Trust Service (“PTS”) kernel.
The PTS is the trusted piece of code which will be relied upon to take measurements of executables and provide integrity reports of those measurements. An integrity report is output from the PTS that contains a TPM 100 signature over PCRs 110a and details of measurements taken by the PTS or input by applications that use the PTS. The integrity report may be used later in verifying the trustworthiness of the PC platform. The PTS kernel is that initial portion of the PTS that is measured prior to the execution of the PTS that extends the transitive trust chain to the entire PTS. Once the PTS kernel has been measured, the PTS may bootstrap itself to execute one or more portions of its code.
The Verifier SP Template will be described with reference to the OPAL 1.0 and Core 1.0 SPD specifications. Nevertheless, the use of these particular SSCs is merely for exemplary purposes. Other existing SSCs, e.g., Enterprise or Optical, could be used in place of the OPAL 1.0 program without an appreciable change to the method and system. Moreover, in an embodiment of the invention, the Verifier SP Template is designed with the TCG Specification. Nevertheless, the invention is not dependent on the TCG specification, which is used merely for exemplary purposes. Any other suitable interface language could be substituted with similar results. In an embodiment of the invention, certain tables from the Core 1.0 Specification are required by the Verifier that are optional in the Opal Specification.
In an embodiment of the invention, the Verifier SP Template enhances the Opal Locking SP with a set of tables. These tables include TPM Quoted PCR values that can be read and written, and that define the state of the Verifier Functions. Specifically, an embodiment of the invention uses at least two new tables. These tables are VerifierInfo Table and PCR Table. These tables are illustrated in
Trusted partition 220 of SPD 190 may store one or more computer programs that are accessible only when PC platform 100 executes a boot process. Upon completion of execution of the program or programs in trusted partition 220, SPD 190 may disable all access to trusted partition 220. This disabling of access to trusted partition 220 may occur prior to the execution of code in primary partition 240.
At Step S305, PC platform 100 boots the CRTM, which as was previously explained is the core trusted root for measurement of integrity, i.e. trustworthiness. At Step S310, CRTM “measures” PC platform's 100 BIOS 160a and extends the value of that measurement into a PCR 110a in TPM 110. As was previously noted, a measurement of any particular component may, in an embodiment of invention, be a hash digest of that component. While the measurement is preferably a hash digest, it need not be, and may instead take the form of any verifiable measurement, including encryption/decryption, digital signatures, and the like. Moreover, as an alternative embodiment, where an extensible firmware interface (“EFI”) is used instead of a conventional BIOS, then at Step S310, PC platform's EFI may be measured. One of ordinary skill in the art will readily appreciate that the invention may operate on platforms utilizing EFI instead of a conventional BIOS without substantial modification.
At Step S315, the CRTM retrieves an Application Identity Key (“AIK”) 620 for quoting the PCRs 110a. Referring now to
Referring again to
Referring now to
At Step S370, the SPD checks the value of Verify_SPD_ROM_Code of the VerifierInfo Table. If the value of Verify_SPD_ROM_Code is TRUE, e.g., “YES” at Step S370, then at Step S375, the SPD 190 measures its ROM code, and at Step S380, the SPD 190 issues a command to extend at least one of the PCRs 110a of the TPM. In an embodiment of the invention, it is PCR #4 of the PCRs 110a. Similarly to above, in an embodiment of the invention, when the value of PCR 110a is extended, then the Reference PCR Value of the SPD 190 also may be extended, depending on the authority level of the PCR 110a that is updated. Processing then moves to Step S382. If the Verify_SPD_ROM_Code is set to FALSE, e.g., “NO” at Step S370, then processing moves to Step S382.
At Step S382, the SPD 190 checks to determine if the current value of the Reference_PCR_Value field is 0 or null. If the Reference_PCR_Value field is 0 or null, e.g., “YES” at Step S382, then at Step S384, the Reference_PCR_Value field is set. Depending on the configuration of SPD 190, the Reference_PCR_Value may be set by a PUT command from an external application or device, or the Reference_PCR_Value may be internally computed, i.e., by the firmware of the SPD 190. Moreover, the Reference_PCR_Value may be computed by both internal and external calculations, e.g., as an extension of an existing PCR value modified by the measurement of the SPD 190's firmware. When the Reference_PCR_Value is set, processing moves to Step S386. If the Reference_PCR_Value previously has been set, e.g., “NO” at Step S382, then processing moves immediately to Step S386.
At Step S386, the Reference_PCR_Value is compared with the PCR_Value, to determine whether to unlock a specific Logical Block Address (“LBA”) of the SPD 190. If the Reference_PCR_Value matches the PCR_Value, e.g., “YES” at Step S388, then at Step S390, the appropriate LBA range is unlocked. In an embodiment of the invention, depending on the result of the comparison, different LBAs of the SPD 190 may be unlocked depending on the type of match between the Reference_PCR_Value and the PCR_Value. In another embodiment of the invention, each match of the Reference_PCR_Value and the PCR_Value may cause the entire writeable portion of the SPD 190 to be unlocked. After the specific LBA of the SPD 190 is unlocked, processing ends. If the Reference_PCR_Value does not match the PCR_Value, e.g., “NO” at Step S388, then processing moves to Step S399, no portion of the SPD 190 is unlocked, and processing ends.
VerifierInfo includes a PCR Size field, which designates the size of the PCR or PCRs stored in the PCR Table 500. This size varies based on the encryption method used by the TPM, i.e., if 2048-bit RSA encryption is used, then the size may be 32 bytes. Generally, the size is either 20 bytes or 32 bytes, although other sizes may be used in other embodiments, depending on the implementation of the SPD. VerifierInfo also includes a PCR_Signature field. As described above with respect to Step S335, the TPM Signature sent to the SPD is stored in this field. The next field in VerifierInfo, PCR_Signature_Check, is a boolean. If this field evaluates to “TRUE,” then the signature stored in PCR_Signature is verified. If this field evaluates to “FALSE,” then the signature stored in PCR_Signature is not checked. VerifierInfo also includes a Locality field, which is a byte-sized field that indicates the locality of the TPM 110 (e.g., BIOS, a different SPD).
VerifierInfo finally includes two boolean fields, Verify_SPD_ALT-MBR_Code, and Verify_SPD_ROM_Code. These two boolean fields, when evaluated to “TRUE” indicate that the PCR 110a should be extended with the SPD 190's ALT-MBR and ROM, respectively.
In an embodiment of the invention, the TPM Version 1.2 specification includes the C_RSA—2048 table, which provides 2048-bit encryption for use by the Verifier SP. This permits the definition of an Authority in the Authority table with sufficient privileges to perform the Public Key Verification, which may be used to quote the PCR values protected by the TPM 110, as previously described with respect to Step S320 of
While the invention has been described in connection with preferred embodiments, it will be understood by those of ordinary skill in the art that other variations and modifications of the preferred embodiments described above may be made without departing from the scope of the invention. Other embodiments will be apparent to those of ordinary skill in the art from a consideration of the specification or practice of the invention disclosed herein. The specification and the described examples are considered as exemplary only, with the true scope and spirit of the invention indicated by the following claims.
