Methods and systems that selectively permit changes to a cryptographic hardware unit's state

In at least some embodiments, a system comprises a hardware unit and a plurality of software agents that couple to and utilize at least one function of the hardware unit. The system further comprises a consensus module coupled to the hardware unit and the software agents. The consensus module is configured to detect an event that changes a state of the hardware unit, notify the software agents of the event before the state changes and selectively permit the state to change based on responses from the software agents.

BACKGROUND

When applications utilize cryptographic hardware such as the Trusted Platform Module (TPM), there are cases when a TPM state change command such as a “disable” command deems a device or a computer system unusable. For example, if the TPM is utilized to authenticate a user before the Basic Input/Output System (BIOS) boots a system, executing a TPM disable command without first notifying the BIOS causes the system to fail to boot at the next power cycle. Also, if the TPM is utilized to encrypt and un-encrypt data (e.g., data on a hard disk), executing a TPM disable command without first notifying parties (or programs) that depend on the encrypted data prevents the parties from later “unwrapping” the encrypted data. Not being able to recover encrypted data may result in a permanent loss of data as well as a loss of access to the computer system.

Notation and Nomenclature

DETAILED DESCRIPTION

The following discussion is directed to various embodiments of the invention. Although one or more of these embodiments may be preferred, the embodiments disclosed should not be interpreted, or otherwise used, as limiting the scope of the disclosure. In addition, one skilled in the art will understand that the following description has broad application, and the discussion of any embodiment is meant only to be exemplary of that embodiment, and not intended to intimate that the scope of the disclosure is limited to that embodiment.

As more applications (i.e., software agents) are deployed that take advantage of the security capabilities offered by cryptographic hardware such as the Trusted Platform Module (TPM), there is a need to notify these software agents of events that change a critical operational state of the cryptographic hardware (e.g., a command to disable the cryptographic hardware). By notifying the software agents of such events before changes to the critical operational state occur, security services (e.g., security services provided by the software agents) that are dependent on the cryptographic hardware are better protected from data loss or denial of service. For example, in some embodiments, notifying the software agents of such events enables the software agents to delay changes to the critical operational state of the cryptographic hardware for a time or until predetermined criteria is met (e.g., until a timer expires or until predetermined operations provided by the cryptographic hardware are finalized). Additionally or alternatively, notifying the software agents of such events enables the software agents to appropriately disassociate themselves from the cryptographic hardware before (or after) the critical operational state change occurs. In this manner, the software agents are able to continue functioning without unexpected data loss or denial of service due to the critical operational state change of the cryptographic hardware.

FIG. 1shows a system100in accordance with embodiments of the invention. As shown inFIG. 1, the system100comprises a plurality of software agents110A-110N. In at least some embodiments, the software agents110A-110N are capable of being registered as part of a software chain108that will be described in further detail below. The software agents110A-110N couple to a TPM102via a TPM software stack (TSS)104and depend on the TPM102for security services such as encryption and decryption. The TSS104operates as “middleware” for the TPM102providing common abstraction, isolation, and management services through a common application programming interface (API). As shown, the TSS104comprises a consensus module106having a registering component112, a monitoring component114, a querying component116and a policy component118. In alternative embodiments, another cryptographic hardware module and software stack (besides the TPM102and the TSS104) may be implemented. In such embodiments, the software stack comprises “middleware” that operates on top of a cryptographic hardware module, providing common abstraction, isolation, and management services through a common application programming interface (API).

If a predetermined event occurs (e.g., a state change command is issued), each registered software agent in the callback chain108is notified in sequence. A software chaining mechanism can be defined in many ways. In at least some embodiments, the software chain108is defined such that each of the registered software agents of the software chain108is notified in a predetermined order. For example, to notify the third software agent of the chain, one starts at the first software agent, proceeds to the second software agent and then the third software agent. Alternatively, the software chain108could be defined as an arrangement of software agents that are notified one after the other, but in a non-sequential manner. In at least some embodiments, one or more registered software agents of the software chain108is given power to allow, to delay and/or to prevent an intended action (e.g., a state change) of the predetermined event.

If, for example, a software agent aborts the intended action, the consensus module106is configured to inform other software agents (e.g., software agents that previously allowed the intended action) that the intended action is being aborted. Also, the consensus module106may provide information regarding which software agent aborted the intended action. If, on the other hand, every registered software agent allows the intended action, the consensus module106is configured to inform the software agents that occurrence of the intended action is now imminent. In alternative embodiments, other chaining mechanisms, now known or later developed, could be used as long as registered software agents are empowered to abort or delay an intended action.

As previously mentioned, the TSS104comprises a consensus module106having a registering component112, a monitoring component114, a querying component116and a policy component118. The consensus module106allows the software agents110A-110N to be notified of events that change a critical operational state of the TPM102before the critical operational state change occurs. After notification, the software agents110A-110N are able to delay changes to the critical operational state of the TPM102for a time or until predetermined criteria is met. Additionally or alternatively, the software agents110A-110N are able to disassociate themselves from the TPM102before (or after) the critical operational state change occurs without unexpected data loss or denial of service.

To notify the software agents110A-110N of events that change the critical operational state of the TPM102, the software agents110A-110N register with the TSS104. For example, the registering component112of the consensus module106may permit the software agents110A-110N to request registration or permit the consensus module106to query the applications110A-110N for registration. Thereafter, the registering component112stores information that identifies which of the software agents110A-110N are registered. In at least some embodiments, only the software agents which are registered with the registering component112will be notified of events that change the critical operational state of the TPM102.

The monitoring component114monitors data from the data lines120A-120N to detect events that change a critical operational state of the TPM102. In at least some embodiments, the monitoring component114is configured to detect TPM disable commands. For example, an owner or authorized user of the TPM102may issue a TPM disable command that disables the TPM102temporarily or permanently. Although other events (e.g., an enable command) may change a critical operational state of the TPM102, an illustrative example based on a TPM disable command is described herein.

Upon detecting the TPM disable command, the monitoring component114causes the TPM disable command to be buffered, re-directed or otherwise prevents the TPM disable command from being processed by the TPM102until a predetermined amount of time has passed or until predetermined criteria is met. The monitoring component114also notifies the querying component116that the TPM disable command was detected.

The querying component116notifies the software agents110A-110N (assuming all of the software agents110A-110N are registered) of the intended TPM disable command and queries the software agents110A-110N for a response via the query signals122A-122N. In at least some embodiments, the querying component116is associated with a “call-back” mechanism. As used herein, a call-back mechanism refers to a communication interface between the TSS104and software agents that are registered to be informed if the TPM's state changes (e.g., from “active” to “disabled”). The communication interface may be, for example, a component object model (COM) interface, a distributed component object model (DCOM) remote procedure call (RPC) interface, a Web Services-based interface, an Extensible Markup Language (XML) interface, a Simple Object Access Protocol (SOAP) interface or another interface now known or later developed.

The policy component118establishes rules that determine how the software agents110A-110N are queried and how responses received (or not received) from the software agents110A-110N are interpreted. In at least some embodiments, the policy component118establishes that each registered software agent in the chain108is notified of intended critical state changes to the TPM102and is given an opportunity to respond before the TPM102is allowed to change states (e.g., from active to disabled).

For example, in some embodiments, each registered software agent is informed of the intended critical state change in turn (e.g., in round-robin fashion). Upon being notified, a registered software agent is able to complete all tasks that are necessary for continued successful operation after the TPM102is disabled. Once a registered software agent has completed the necessary tasks, control of the chain108is given back to the “caller” (e.g., the call-back mechanism implemented by the TSS104), which notifies the next registered software agent in the chain108. At the end of the chaining operation, the critical state change is allowed (e.g., the TPM102is allowed to process the TPM disable command).

In some embodiments, the policy component118establishes a response time period for each registered software agent. Thus, each registered software agent is given a threshold amount of time to respond to the notification before control of the chain108is passed again to the caller, which notifies the next registered software agent. If a registered software agent does not respond within the threshold amount of time, the policy component118is configured to interpret the lack of response. For example, the lack of response may be interpreted as a permission to process the TPM disable command, as an “unable to respond” state or as a “hung” state.

In at least some embodiments, the policy component118establishes that one or more of the registered software agents can veto or otherwise cause the TPM disable command to be rejected. For example, the policy component118may establish that registered software agents that are unable to automatically disassociate (or re-associate) themselves with the TPM102are granted veto power over TPM disable commands. Likewise, the policy component118may establish that registered software agents that are unable to transparently (without notifying a user) disassociate (or re-associate) themselves with the TPM102are granted veto power over TPM disable commands. Likewise, the policy component118may establish that registered software agents that are unable to disassociate (or re-associate) themselves with the TPM102without a predetermined amount of complexity are granted veto power over TPM disable commands. In at least some embodiments, the TSS104is configured to record which software agent vetoed the TPM disable command and to inform the administrator or authorized user that issued the TPM disable command accordingly.

As an example of a software agent that is given veto power, consider a case where the TPM102is used to protect a hard disk drive lock password (commonly referred to as “Drive Lock”). Drive Lock is typically only enabled or disabled during a computer system's boot time. Thus, it is not feasible (and in some instances, not possible) to disable the Drive Lock feature until the next time the computer system reboots. In this case, the TPM Disable Command should not be executed until the hard disk has been unlocked. Otherwise, the system BIOS (or an equivalent software agent) will not be able to use to the TPM102to unlock the drive, resulting in a loss of usability for the hard drive. If the hard drive is the primary drive of the computer system, a user also loses access to the computer system as well.

As another example of a software agent that is given veto power, consider a full disk encryption software agent that uses the TPM102to protect a symmetric key that protects the entire contents of the hard disk. Before the TPM102is disabled, the full disk encryption software agent needs time to disassociate the data protection key from the TPM102(and protect it by other means) or to unprotect the entire contents of the hard disk. Otherwise, the next time the computer system boots, the full disk encryption software will not be able to use the TPM102to unlock the protection key for the disk. In such case, the computer system will no longer be able to boot and the user will have no access to the data on the disk.

The policies provided by the policy component118are dynamically customizable or selectable by an administrator or authorized user. For example, an authorized administrator may select whether to implement a response time period or not. If a response time period is selected, the authorized administrator is able to choose the response time period and/or the interpretation of a non-response (e.g., non-responses may be interpreted as a response giving permission to process the TPM disable command, an “unable to respond” state or a “hung” state). The authorized administrator is also able to select whether to implement veto power or not. If veto power is selected, the authorized administrator is able to choose which software agents have veto power and/or under what conditions software agents are able to exercise veto power. For example, in some embodiments, software agents that are unable to automatically disassociate or re-associate themselves with the TPM102are granted veto power.

In response to a query, registered software agents are able to provide one of a set of responses. For example, each registered software agent may provide one of an “OK to disable” (OK) response, a “reject disable command” (REJECT) response and a “check back later” (CHECK BACK) response. The policy component118establishes which of these responses are accepted by the TSS104. For example, if the policy component118establishes that no software agents are authorized to veto the TPM disable command, the TSS104will not honor REJECT responses. Also, the policy component118may establish that only up to a predetermined number of CHECK BACK responses from each software agent (or all of the software agents) will be honored before the TPM102is able to process the TPM disable command.

Based on the responses (and non-responses) from the registered software agents, the policy component118also establishes one of a set of actions for the TSS104to perform. In at least some embodiments, the policy component118establishes a “disable the TPM” (DISABLE) action, a “leave the TPM enabled” (LEAVE ENABLED) action, a “call back software agents later” (CALL BACK) action and an “ask for TPM owner's direction” (ASK OWNER) action.

If the DISABLE action is performed, the TSS104allows the TPM102to process the TPM disable command. Alternatively, the DISABLE action may generate and transmit a new TPM disable command (e.g., if the original TPM disable command is no longer available or if generating a new TPM disable command reduces complexity). If the LEAVE ENABLED action is performed, the TSS104does not allow the issued TPM disable command to be processed. If the CALL BACK action is performed, the TSS104waits for a predetermined amount of time before querying appropriate software agents (e.g., software agents that provided a REJECT response, a CHECK BACK response or a non-response) again.

If the ASK OWNER action is performed, the TSS104transmits a message (e.g., an email, a pop-up message or another message) to the TPM owner or authorized user. The message may be transmitted directly or indirectly through intermediaries designated as authorized delegates on behalf of the owner or the authorized user. This allows the TPM owner or authorized user to select the DISABLE action, the LEAVE ENABLE action or the CHECK BACK action provided by the TSS104. In some embodiments, the message comprises information regarding the responses of the registered software agents. The administrator or authorized user is thus able to make an informed decision regarding whether to disable the TPM102or not. The message also may facilitate the administrator's or authorized user's access to existing policies as well as policy options of the policy component118by listing those policies (or providing a link to access the policies) in the message.

Although the notification process ofFIG. 1is illustrated with respect to a TPM disable command, the notification process is also extendable to the case where the TPM102is enabled (after being disabled). In such a case, the registering component112registers software agents to be notified if a TPM enable command is issued. In response to detecting the TPM enable command by the monitoring component114, the querying component116informs registered or interested software agents that the TPM102is again available. The software agents are able to respond to the query by associating their operations with the security (e.g., encryption and decryption) provided by the TPM102. For example, a hard disk software agent is able to encrypt data and decrypt data on the hard drive based on the cryptographic capabilities of the TPM102. In the case of enabling the TPM, the policy component118may establish policies for handling responses from the registered software agents, prioritizing the registered software agents, calling back software agents that are busy or are otherwise non-responsive, or other policies. Again, the policies established by the policy component118may be dynamically customized and selected by an administrator or authorized user of the TPM102.

FIG. 2shows a network-based system200in accordance with embodiments of the invention. As shown inFIG. 2, the system200comprises a plurality of user computers202A-202N coupled to a server206via a network204. The server206comprises a TPM102and a TSS104having a consensus module106. Also, the user computers202A-202N each have at least one software agent that depends on the TPM102for security operations (e.g., encryption and decryption). As shown, the user computer202A is associated with the software agent110A, while the user computer202B is associated with the software agent110B and so on. The software agents110A-110N may be, for example, applications, device drivers, or other software proxy agents acting for the BIOS of each of the user computers202A-202N. The system200also may comprise an administrator computer208that is configured to transmit enable commands210and disable commands212to the TPM102based on input from an administrator or authorized user.

As previously described, the consensus module106may register the software agents110A-110N to be notified of events that change the critical operational state of the TPM102. For example, an event that changes the critical operational state of the TPM102may be the issuance of the enable command210or the disable command212. Upon detecting the event, the consensus module106queries the software agents102A-102N before the TPM's state is allowed to change. In at least some embodiments, the system200implements a chained call-back mechanism214to notify or inform the software agents102A-102N of the event as previously described.

The software agents110A-110N are able to transmit responses to the TSS104via the network204. Each response may give permission to change the critical operational state of the TPM102, request that the change not be allowed, request that the change be delayed for a predetermined amount of time or request a “call-back” after a predetermined amount of time. The consensus module106determines an action to perform based on the responses and based on established policies. As previously described, the consensus module106may implement the policy module118to establish and update policies. In at least some embodiments, the policies are customizable and/or selectable by an administrator or authorized user. In this manner, time limits, veto power and other policy considerations may be adjusted to meet the different needs or the changing needs of TPM-based applications, TPM owners or authorized TPM users.

The TPM102is capable of being used for a variety of purposes. In at least some embodiments, the TPM102is implemented to authenticate users of the user computers202A-202N. For example, a user may be authenticated by the TPM102before or during each user computer's boot process. The user-authentication provided by the TPM102takes place by virtue of a middle agent such as a computer system's BIOS, which indirectly verifies the user of the TPM102by asking the user to provide authentication secrets. The authentication secrets are used by the middle agent with the TPM102(e.g., by comparing the authentication secrets with a TPM-protected secret that was previously stored). The TPM-protected secret may be, for example, a TPM user-key BLOB (binary large object). If the TPM102decrypts the BLOB correctly, the user is determined to be the rightful owner/user of the computer system by virtue of having the correct authentication secrets.

Additionally or alternatively, the TPM102may be implemented to encrypt and decrypt information stored on the user computers202A-202N (e.g., information stored on hard drives). Also, the TPM102may authenticate software (e.g., transaction software) running on a remote system of the network204. Also, the TPM102may uniquely or pseudo-anonymously identify computer systems on a network that is TPM-enabled. Also, the TPM102may be used to protect partial secrets on a computer system such as medical information, government identity numbers, a user finger print, a user address, or credit card information. For additional details on how the TPM102can be used, reference may be made to published information provided by the Trusted Computing Platform Alliance (TCPA) or the Trusted Computing Group (TCG).

By implementing the consensus module106, the software agents110A-110N of the user computers202A-202N that depend (or could depend) on the TPM102are at least notified if an event that changes the critical operational state of the TPM102has occurred. The software agents110A-110N are then able to perform actions and/or respond to the event before (or after) the state change occurs. For example, if an event occurs that will change the TPM's state from “enabled” to “disabled,” at least one of the software agents110A-110N may be able to disassociate itself from the TPM102before the TPM102is disabled. This prevents unexpected data loss or lack of service due to the disabled TPM102. Again, policies may be established, for example, that permit all software agents110A-110N to dissociate themselves before the TPM102is disabled, that provide a time limit to software agents110A-110N to dissociate themselves before the TPM102is disabled, or that grant one of more of the software agents110A-110N veto power to prevent the TPM102from being disabled.

In at least some embodiments, the veto power is based, for example, on one or more considerations such as software agent types, the ability of each software agent11A-110N to dissociate itself from the TPM102, the ability of each software agent110A-110N to re-associate itself with the TPM102or a prioritization of the software agents110A-110N by an administrator or authorized user. Also, other prioritization schemes may be implemented to establish how the software agents are registered or queried. The priority schemes may apply to how responses received from different software agents are considered by the consensus module106. For example, one software agent may be given more time to disassociate itself from the TPM102than other software agents and so on.

If an event occurs that changes the TPM's state from “disabled” to “enabled,” at least one of the software agents110A-110N may be able to re-associate itself automatically with the TPM102before or after the TPM102is enabled. This may be performed in a manner that is transparent to the users of the user computers202A-202N. Thus, software agents that are registered with the consensus module106are able to take advantage of the services provided by the TPM102in a manner that is automated and transparent to users. The registered software agents are also able to disassociate and re-associate themselves with the TPM102in an efficient manner that reduces unexpected data loss and lack of services. Again, policies of the consensus module106may be established that affect the registering processing, the querying process, how responses from the software agents110A-110N are interpreted and what actions are performed by the TSS104based on the responses (and non-responses).

FIG. 3shows a method300in accordance with embodiments of the invention. As shown inFIG. 3, the method300comprises registering software agents to be notified of an event that changes a TPM's state (block302). For example, the event may be a TPM enable command or a TPM disable command. The method300further comprises monitoring for the event that changes the TPM's state (block304). If the event is not detected (determination block306), the method300continues to monitor for the event that changes the TPM's state (block304). If the event is detected (determination block306), the registered software agents are notified of the event before the TPM's state changes (block308). Thereafter, responses from the registered software agents are monitored (block310). For example, the registered software agents may respond by giving permission to change the TPM's state, requesting that the TPM's state not be changed (at least not for a predetermined amount of time) or requesting to be called-back at a later time. Finally, the TPM's state change is allowed or prevented based on the responses from the registered software agents (block312). As previously described, policies may be established to determine the effect of the responses, to determine time limits for the responses, to enable registered software agents to veto the state change or other policy considerations. The policies are adjustable by a TPM administrator or authorized user.

The above discussion is meant to be illustrative of the principles and various embodiments of the present invention. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. For example, the consensus module is described as being part of a TSS (a TPM software stack). However, in some embodiments, the consensus module could be separate from the TSS and communicates with the TSS to perform the functions described herein. Also, the consensus module may comprise software elements, hardware elements or a combination of hardware and software elements. It is intended that the following claims be interpreted to embrace all such variations and modifications.