Methods and systems for modifying an integrity measurement based on user authentication

A computer system is provided that comprises a processor and a Basic Input/Output System (BIOS) accessible to the processor. During a boot process, the BIOS determines an integrity measurement for the computer system and modifies the integrity measurement based on a user authentication.

BACKGROUND

Many authentication strategies limit the number of separate user identities or secrets that can be authenticated. For example, some drive lock mechanisms only support authentication of a single password. To authenticate a drive lock password, a Basic Input/Output System (BIOS) requests that a user enter a password during a pre-boot environment and provides the value entered by the user to the hard drive. If the password is correct, the hard drive will start spinning (i.e., the drive is “unlocked”). If the password is incorrect, the drive will not spin (i.e., the drive is “locked”). This pre-boot authentication feature is somewhat incompatible in a multi-user environment (e.g., a workplace). While a common password could be shared by multiple users (enabling any of multiple users to be authenticated using the same password), security and user-friendliness are better served using individualized passwords. Furthermore, other authentication processes (e.g., smartcard or biometric processes) may be associated with individual users rather than groups. Thus, an authentication strategy that involves authenticating a single secret or a limited number of secrets becomes incompatible, or at least inconvenient, in a multi-user environment where authenticating many user identities or secrets is desirable.

NOTATION AND NOMENCLATURE

DETAILED DESCRIPTION

Many authentication strategies limit the number of separate user identities or secrets that can be authenticated. Embodiments of the invention support authenticating any of multiple user identities or secrets as a prerequisite to accessing a secure device (or privilege) that, without an embodiment of the invention, only supports authentication of a single secret or a limited set of secrets (i.e., the number of potential users that will access the secure device is greater than the number of secrets that can be authenticated for or by the secure device).

In at least some embodiments, a computing platform's Basic Input/Output System (BIOS) acts as a trusted agent between multiple users and the secure device. In other words, the BIOS controls the secret that unlocks the secure device or privilege. During a boot process, the BIOS can authenticate any of the multiple users based on individual passwords, smartcards, biometrics or some other authentication process. If user authentication is successful, the BIOS securely accesses the secret associated with the secure device. In some embodiments, the BIOS retrieves the secret from a Trusted Platform Module (TPM) which is able to seal and unseal the secret. Once received, the BIOS uses the secret to unlock the secure device or to access a privilege. As an example, the secure device may be a disk drive protected by a drive lock mechanism. Additionally or alternatively, the BIOS may use the secret to access a secure privilege such as decryption of encrypted data.

FIG. 1shows a computer100in accordance with embodiments of the invention. The computer100may be, for example, a server, a desktop computer, a laptop computer or a handheld device. In some embodiments, the computer100comprises a processor134coupled to a Trusted Platform Module (TPM)120and a disk drive140having a drive lock function142. As shown, the processor134has access to a Basic Input/Output System (BIOS)110which may be implemented, for example, as part of a chipset (e.g., a “Southbridge”) or other non-transitory computer readable storage medium. The processor134also couples to an authentication interface150that enables a user to input data to the computer100for user authentication. The authentication interface150could be, for example, a keyboard, a mouse, a virtual token (e.g., a Universal Serial Bus (USB) token) source, a smartcard reader, a biometric scanner, or some other interface that receives data for user authentications.

The TPM120is configured to provide cryptographic functions such as an RSA asymmetric algorithm for digital signature and for encryption, SHA-1 hashing, a Hash-based Message Authentication Code (HMAC) function, secure storage, random number generation, or other functions The TPM120is implemented using software, firmware and/or hardware. The TPM components shown inFIGS. 1 and 2have been generalized and are not all-inclusive. Also, TPM architectures and functions may possibly change over time as authorized by the Trusted Computing Group (TCG).

As shown inFIG. 1, the TPM120comprises an input/output (I/O) interface122in communication with the processor134. The I/O interface122couples to other TPM components such as cryptographic services124, a random number source126, asymmetric algorithms128, storage130and Platform Configuration Registers (PCRs)132. The cryptographic services124support functions such as hashing, digital signing, encryption and decryption. The random number source126generates random numbers for the cryptographic services124. For example, in some embodiments, the cryptographic services124use random numbers to generate encryption keys. The asymmetric algorithms128enable the TPM120to perform asymmetric key operations. The storage130securely stores secrets (e.g., encryption keys or other data) protected by the TPM120. The PCRs132store information about the current state of the computer100. For example, in some embodiments, the PCRs132store individual integrity measurements related to the computer100as well as sequences of integrity measurements. As will later be described, the integrity measurements stored in at least one of the PCRs132can be verified as a prerequisite to providing a secret associated with the drive lock function142to the BIOS110.

As shown inFIG. 1, the BIOS110comprises a drive lock interface114and a trusted agent function116. For convenience in describing embodiments of the invention, the terms “initialization stage” and “verification stage” will be used. In the initialization stage, a secret is securely stored such that the secret can only be accessed if certain conditions are satisfied. In the verification stage, a determination is made as to whether the conditions have been satisfied. If the conditions have been satisfied, the secret becomes accessible to the BIOS110. Otherwise, the secret remains securely stored and inaccessible. As described herein, both the drive lock interface114and the trusted agent function116perform certain functions in the initialization stage and the verification stage.

During the initialization stage, the drive lock interface114enables an administrator or other authorized entity to enter a secret to be used with the drive lock function142of the disk drive140(i.e., the secret can be used to lock and/or unlock the disk drive140). Alternatively, the drive lock interface114causes the BIOS110to generate the secret without user input. In either case, the trusted agent function116causes the secret to be securely stored such that the secret can only be accessed if certain conditions are met. In at least some embodiments, the trusted agent function116causes the secret to be sealed by the TPM120such that only the TPM120can unseal the secret.

To seal the secret, the TPM120inserts the secret into a data structure (sometimes referred to as a “blob”). In at least some embodiments, the format of the blob is defined by the TCG. Portions of the blob (such as the area containing the secret) are encrypted by the TPM120. The blob also may include a PCR value that has been “extended” based on boot operations or integrity measurements performed by the BIOS110. Some examples of values that the BIOS110can extend to a given PCR132include, but are not limited to, a Power-On Self-Test (POST) start value, platform specific values, a successful user authentication value, a failed user authentication value, a POST exit value (i.e., integrity measurements of the platform's hardware, firmware, or software), or other values. In at least some embodiments, the PCR value that is sealed with the secret has been extended based on a POST start value, platform specific values and a successful user authentication value. Using the cryptographic services124, the TPM120seals the blob containing the secret and the PCR value such that only the TPM120can unseal the blob. In at least some embodiments, the TPM120verifies that current PCR values match the PCR values specified in the blob before releasing the secret to the BIOS110. If the TPM120is involved with user authentication as may be the case in some embodiments, a user password (or other identifier) can also be inserted in the blob and sealed by the TPM120. In such case, the TPM120could verify this password before releasing the secret to the BIOS110.

During the verification stage (e.g., during a subsequent boot), the BIOS110again performs boot operations or integrity measurements of the computer100. These integrity measurements can be stored, for example, in at least one of the PCRs132. At some point during the verification stage, the trusted agent function116performs authentication of any of multiple users that access the computer100. The user authentication can be based on passwords, smartcards, biometrics or any other authentication process supported by the authentication interface150and the BIOS110. The TPM120may or may not be involved with user authentication, although the TPM120selectively unseals the secret based, in part, on successful user authentication. If the TPM120is involved with user authentication, the user can be authenticated by entering the password that was sealed with the secret as previously mentioned.

If the user is successfully authenticated (regardless of whether the TPM120is involved or not), the trusted agent function116causes the BIOS110to modify an integrity measurement of the computer100. For example, the BIOS110could modify an integrity measurement by extending a successful user authentication value to a given PCR132. In at least some embodiments, the given PCR132would already have had a POST start value and platform specific values of the computer100extended to it. Alternatively, the values (measurements) could be extended to the given PCR132in a different order (e.g., the successful user authentication value could be extended to the given PCR132before the platform specific values of the computer100are extended to the given PCR132). The order and the number of values that are extended to the given PCR132can vary as long as the same process is used during the initialization stage and the verification stage. In other words, one purpose of the verification stage is to selectively generate the same PCR value that was generated and sealed in the initialization stage. In at least some embodiments, the PCR value that was generated in the initialization stage is generated in the verification stage only if the user authentication is successful and certain platform specific measurements of the computer100have not changed.

If desired, the order and number of values that are extended to the given PCR132during the initialization stage and the verification stage can be updated. Such an update could occur routinely to increase security of the initialization stage and the verification stage and/or could occur if a need arises to update the hardware, firmware, or software of the computer100.

If the user is not successfully authenticated, the trusted agent function116causes the BIOS110to modify an integrity measurement of the computer100such that the modified integrity measurement based on the failed user authentication is different than the modified integrity measurement based on the successful user authentication. For example, the BIOS110could modify an integrity measurement by extending a failed user authentication value to a given PCR132. In at least some embodiments, the given PCR132would already have had a POST start value and platform specific values extended to it. As previously mentioned, the order and the number of values that are extended to the given PCR132can vary as long as the same process is used during the initialization stage and the verification stage.

After the integrity measurement has been modified based on a successful or failed user authentication, the trusted agent function116requests access to the secret that has been securely stored. The secret is released to the trusted agent function116if the modified integrity measurement equals a predetermined value that corresponds, in part, to a successful user authentication. In some embodiments, the TPM120releases the secret to the trusted agent function116if a PCR value generated during the verification stage matches a PCR value that was generated during the initialization stage and sealed with the secret.

If the user authentication fails, the PCR value that was generated in the initialization stage is not generated in the verification stage. Additionally or alternatively, if certain platform specific measurements of the computer100have changed, the PCR value that was generated in the initialization stage is not generated in the verification stage. At least the PCR value that was generated in the initialization stage would not be generated at the time the PCR values are compared in the verification stage. On the other hand, if the user authentication is successful and certain platform specific measurements of the computer100have not changed, the PCR value that was generated in the initialization stage is generated in the verification stage such that successful comparison of the PCR values occurs.

Upon successful comparison of the modified integrity measurement with the predetermined integrity measurement, the BIOS110receives the secret. For example, in some embodiments, upon successful comparison of a PCR value generated during the verification stage with a PCR value that was generated during the initialization stage and sealed with the secret, the BIOS110receives the secret from the TPM120. The drive lock interface114can then use the secret to unlock the drive lock function142of the disk drive140. If the comparison fails, the secret is not provided to the BIOS110and the disk drive140remains locked.

FIG. 2shows a system200in accordance with embodiments of the invention. As shown inFIG. 2, the system200comprises a computer202having a processor234coupled to a Trusted Platform Module (TPM)120. The functions of the TPM120were previously described forFIG. 1and, for convenience, will not be repeated forFIG. 2. However, it should be understood that while the TPM functions previously described have not changed, the manner in which the TPM120is used inFIG. 2could be different from the manner in which the TPM120is used inFIG. 1. Also, if the computer100ofFIG. 1and the computer202ofFIG. 2are separate computers, each would implement a separate TPM120.

As shown inFIG. 2, the processor234has access to a BIOS210which may be implemented, for example, as part of a chipset (e.g., a “Southbridge”) or other non-transitory computer readable storage medium. The BIOS210is similar to the BIOS110ofFIG. 1with the exception that the BIOS210comprises an encryption interface214rather than a drive lock interface114as inFIG. 1. In alternative embodiments, the BIOS210may comprise both a drive lock interface114as inFIG. 1and an encryption interface214as inFIG. 2.

As shown inFIG. 2, the processor234also couples to other components such as a secondary storage240, random access memory (RAM)238, a network interface244, an authentication interface250and input/output (I/O) devices246. As an example, the I/O devices246could be printers, scanners, video monitors, liquid crystal displays (LCDs), touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, paper tape readers, or other I/O devices.

In at least some embodiments, the secondary storage240comprises at least one disk drive or tape drive that stores encrypted data242. The encrypted data242may be part or all of the data stored by the secondary storage240and only an appropriate encryption key can be used to decrypt the encrypted data242. The secondary storage240is used for non-volatile storage of data and as an over-flow data storage device if the RAM238is not large enough to hold all working data. Also, the secondary storage240may be used to store programs which are loaded into the RAM238when such programs are selected for execution. The RAM238may store volatile data and/or instructions.

InFIG. 2, the processor234executes instructions, codes, computer programs, or scripts which are accessed from hard disks, floppy disks, optical disks (these various disk based systems may all be considered secondary storage240), RAM238, or the network interface244. In order for the processor234to access or execute the encrypted data242stored on the secondary storage240, decryption of the encrypted data242is necessary. This decryption involves the BIOS210gaining access to an encryption key that is securely stored as will later be described.

The network interface244may take the form of modems, modem banks, Ethernet cards, Universal Serial Bus (USB) interface cards, serial interfaces, token ring cards, fiber distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards such as code division multiple access (CDMA) and/or global system for mobile communications (GSM) radio transceiver cards, or other network interfaces. Via the network interface244, the processor234is able to connect to and communicate with the Internet or intranet(s). With such a network connection, it is contemplated that the processor234might receive information from the network, or might output information to the network in the course of performing user authentications or accessing an encryption key which is securely stored by the computer202. For example, if the computer202is booted from a remote location, as may be the case in some embodiments, at least some functions performed by the encryption interface214and the trusted agent function216could be controlled remotely rather than locally. If a TPM is used to securely store the encryption key, the same TPM that seals the encryption key would unseal the encryption key.

For convenience in describing embodiments of the invention, the terms “initialization stage” and “verification stage” will again be used. In the initialization stage, an encryption key is securely stored such that the encryption key can only be accessed if certain conditions are satisfied. In the verification stage, a determination is made as to whether the conditions have been satisfied. If the conditions have been satisfied, the encryption key is accessible to the BIOS210. Otherwise, the encryption key remains securely stored and inaccessible. As described herein, both the encryption interface214and the trusted agent function216perform certain functions in the initialization stage and the verification stage.

During the initialization stage, the encryption interface214enables an administrator or other authorized entity to enter an encryption key that is used to encrypt data (e.g., data of the secondary storage240). Alternatively, the encryption interface214could cause the BIOS210to generate the encryption key without user input. In either case, the trusted agent function216causes the encryption key to be securely stored such that the encryption key can only be accessed if certain conditions are met. In at least some embodiments, the trusted agent function216causes the encryption key to be sealed by the TPM120such that only the TPM120can unseal the encryption key.

To seal the encryption key, the TPM120inserts the encryption key into data structure referred to as a “blob” of data. As previously mentioned, in some embodiments, the format of the blob is defined by the TCG. Portions of the blob (such as the area containing the encryption key) are encrypted by the TPM120. The blob also may include a PCR value that has been “extended” based on boot operations or integrity measurements performed by the BIOS210for the computer202. Some examples of values that the BIOS210can extend to a given PCR132include, but are not limited to, a Power-On Self-Test (POST) start value, platform specific values (i.e., integrity measurements of the platform's hardware, firmware, or software), a successful user authentication value, a failed user authentication value, a POST exit value, or other values. In at least some embodiments, the PCR value that is sealed with the encryption key has been extended based on a POST start value, platform specific values and a successful user authentication value. Using the cryptographic services124, the TPM120seals the blob containing the encryption key and the PCR value such that only the TPM120can unseal the blob. In at least some embodiments, the TPM120verifies that current PCR values match the PCR values specified in the blob before releasing the encryption key to the BIOS210. If the TPM120is involved with user authentication as may be the case in some embodiments, a user password (or other identifier) can also be inserted in the blob and sealed by the TPM120. In such case, the TPM120could verify the user password before releasing the encryption key to the BIOS210.

During the verification stage (e.g., during a subsequent boot), the BIOS210again performs boot operations or integrity measurements of the computer202. These integrity measurements can be stored, for example, in at least one of the PCRs132. At some point during the verification stage, the trusted agent function216performs authentication of any of multiple users that access the computer202. The user authentication can be based on passwords, smartcards, biometrics or some other authentication process supported by the authentication interface250and the BIOS210. The TPM120may or may not be involved with user authentication, although the TPM120will later unseal the encryption key based, in part, on successful user authentication. If the TPM120is involved with user authentication, the user can be authenticated by entering the password that was sealed with the encryption key as previously mentioned.

If the user is successfully authenticated (regardless of whether the TPM120is involved or not), the trusted agent function216causes the BIOS210to modify an integrity measurement of the computer202. For example, the BIOS210could modify an integrity measurement by extending a successful user authentication value to a given PCR132. In at least some embodiments, the given PCR132would already have had a POST start value and platform specific values of the computer202extended to it. Alternatively, the values (measurements) could be extended to the given PCR132in a different order (e.g., the successful user authentication value could be extended to the given PCR132before the platform specific values of the computer202are extended to the given PCR132). The order and the number of values that are extended to the given PCR132can vary as long as the same process is used during the initialization stage and the verification stage. In other words, one purpose of the verification stage is to selectively generate the same PCR value that was generated and sealed in the initialization stage. In at least some embodiments, the PCR value that was generated in the initialization stage is generated in the verification stage if the user authentication is successful and the certain platform specific measurements of the computer202have not changed. Examples of platform specific measurements include but are not limited to the BIOS version, the actual BIOS code, device configuration values, and a hard drive identifier.

If desired, the order and number of values that are extended to the given PCR132during the initialization stage and the verification stage can be updated. Such an update could occur routinely to increase security of the initialization stage and the verification stage and/or could occur if a need arises to update the hardware, firmware, or software of the computer202.

If the user is not successfully authenticated, the trusted agent function216causes the BIOS210to modify an integrity measurement of the computer202such that the modified integrity measurement based on the failed user authentication is different than the modified integrity measurement based on the successful user authentication. For example, the BIOS210could modify an integrity measurement by extending a failed user authentication value to a given PCR132. In at least some embodiments, the given PCR132would already have had a POST start value and platform specific values extended to it. As previously mentioned, the order and the number of values that are extended to the given PCR132can vary as long as the same process is used during the initialization stage and the verification stage.

After the integrity measurement has been modified based on a successful or failed user authentication, the trusted agent function216requests access to the encryption key that has been securely stored. The encryption key is released to the trusted agent function216if the modified integrity measurement equals a predetermined value that corresponds, in part, to a successful user authentication. In some embodiments, the TPM120releases the encryption key to the trusted agent function216if a PCR value generated during the verification stage matches a PCR value that was generated during the initialization stage and sealed with the encryption key.

If the user authentication fails, the PCR value that was generated in the initialization stage is not generated in the verification stage. Additionally or alternatively, if certain platform specific measurements of the computer202have changed, the PCR value that was generated in the initialization stage is not generated in the verification stage. At least the PCR value that was generated in the initialization stage would not be generated at the time the PCR values are compared in the verification stage. On the other hand, if the user authentication is successful and certain platform specific measurements of the computer202have not changed, the PCR value that was generated in the initialization stage is generated in the verification stage such that successful comparison of the PCR values occurs.

Upon successful comparison of the modified integrity measurement with the predetermined integrity measurement, the BIOS210receives the encryption key. For example, in some embodiments, upon successful comparison of a PCR value generated during the verification stage with a PCR value that was generated during the initialization stage and sealed with the encryption key, the BIOS210receives the encryption key from the TPM120. The encryption interface114can then use the encryption key to decrypt the encrypted data242. Alternately, the BIOS210can pass the encryption key to some other secure interface (e.g., another encryption interface) which performs the decryption of the data. If the comparison of PCR values fails, the encryption key is not provided to the BIOS210. In such case, the encrypted data242cannot be decrypted.

FIG. 3illustrates a method300in accordance with embodiments of the invention. In at least some embodiments, the method300corresponds to the initialization stage previously described. As shown inFIG. 3, the method300comprises extending a POST start value to a PCR (block302). At block304, platform specifics are measured and corresponding values are extended to the PCR. At block306, a successful user authentication value is extended to the PCR. A secret and the PCR value are then sealed (block308). The secret can be used, for example, to unlock a drive lock function or to decrypt encrypted data. Finally, a POST exit value is extended to the PCR (block310). By extending the POST exit value to the PCR, the previous PCR value that was sealed with the secret cannot be ascertained (i.e., each extend operation changes the PCR value in a way that prevents any of the previous PCR values from being ascertained). The method300can be performed, for example, during a boot process using a BIOS in communication with a TPM.

FIG. 4illustrates another method400in accordance with embodiments of the invention. In at least some embodiments, the method400corresponds to the verification stage previously described. As shown inFIG. 4, the method400comprises extending a POST start value to a PCR (block402). At block404, platform specifics are measured and corresponding values are extended to the PCR. At block406, any of multiple users are authenticated. The user authentication occurs during a computing platform's boot process and may be based on passwords, smartcards, biometrics or another authentication process or combination of authentication processes.

If a user is not authenticated (determination block408), a failed user authentication value is extended to the PCR (block410). Alternatively, if the user is authenticated (determination block408), a successful user authentication value is extended to the PCR (block412). The PCR value is then validated (block414). If the PCR value is incorrect (determination block416) (i.e., the current PCR value does not match the PCR value that was sealed with the secret), the secret stays sealed (block418). Alternatively, if the PCR value is correct (determination block416) (i.e., the current PCR value matches the PCR value that was sealed with the secret), the secret is released to the computing platform's BIOS (block420). Finally, the secret is used to access a secure device or privilege (block422). For example, the secret may enable the BIOS to unlock a disk drive or to decrypt data.