EP1752901A2 - Methods and systems that selectively permit changes to a hardware unit's state - Google Patents

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

Info

Publication number
EP1752901A2
EP1752901A2 EP06253607A EP06253607A EP1752901A2 EP 1752901 A2 EP1752901 A2 EP 1752901A2 EP 06253607 A EP06253607 A EP 06253607A EP 06253607 A EP06253607 A EP 06253607A EP 1752901 A2 EP1752901 A2 EP 1752901A2
Authority
EP
European Patent Office
Prior art keywords
tpm
hardware unit
software agents
state
responses
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP06253607A
Other languages
German (de)
French (fr)
Other versions
EP1752901B1 (en
EP1752901A3 (en
Inventor
Valiuddin Y. Ali
Lan Wang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Development Co LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Publication of EP1752901A2 publication Critical patent/EP1752901A2/en
Publication of EP1752901A3 publication Critical patent/EP1752901A3/en
Application granted granted Critical
Publication of EP1752901B1 publication Critical patent/EP1752901B1/en
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • TPM Trusted Platform Module
  • a TPM state change command such as a "disable” command deems a device or a computer system unusable.
  • a TPM state change command such as a "disable" command deems a device or a computer system unusable.
  • 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.
  • 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.
  • FIG. 1 shows a system in accordance with embodiments of the invention
  • FIG. 2 shows a network-based system in accordance with embodiments of the invention.
  • FIG. 3 shows a method in accordance with embodiments of the invention.
  • 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. 1 shows a system 100 in accordance with embodiments of the invention.
  • the system 100 comprises a plurality of software agents 110A-110N.
  • the software agents 110A-110N are capable of being registered as part of a software chain 108 that will be described in further detail below.
  • the software agents 110A-110N couple to a TPM 102 via a TPM software stack (TSS) 104 and depend on the TPM 102 for security services such as encryption and decryption.
  • TSS 104 operates as "middleware" for the TPM 102 providing common abstraction, isolation, and management services through a common application programming interface (API).
  • API application programming interface
  • the TSS 104 comprises a consensus module 106 having a registering component 112, a monitoring component 114, a querying component 116 and a policy component 118.
  • another cryptographic hardware module and software stack (besides the TPM 102 and the TSS 104) may be implemented.
  • 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).
  • API application programming interface
  • each registered software agent in the callback chain 108 is notified in sequence.
  • a software chaining mechanism can be defined in many ways.
  • the software chain 108 is defined such that each of the registered software agents of the software chain 108 is 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.
  • the software chain 108 could be defined as an arrangement of software agents that are notified one after the other, but in a non-sequential manner.
  • one or more registered software agents of the software chain 108 is given power to allow, to delay and/or to prevent an intended action (e.g., a state change) of the predetermined event.
  • the consensus module 106 is 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 module 106 may 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 module 106 is 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.
  • the TSS 104 comprises a consensus module 106 having a registering component 112, a monitoring component 114, a querying component 116 and a policy component 118.
  • the consensus module 106 allows the software agents 110A-110N to be notified of events that change a critical operational state of the TPM 102 before the critical operational state change occurs. After notification, the software agents 110A-110N are able to delay changes to the critical operational state of the TPM 102 for a time or until predetermined criteria is met. Additionally or alternatively, the software agents 110A-110N are able to disassociate themselves from the TPM 102 before (or after) the critical operational state change occurs without unexpected data loss or denial of service.
  • the software agents 110A-110N register with the TSS 104.
  • the registering component 112 of the consensus module 106 may permit the software agents 110A-110N to request registration or permit the consensus module 106 to query the applications 110A-110N for registration. Thereafter, the registering component 112 stores information that identifies which of the software agents 110A-110N are registered. In at least some embodiments, only the software agents which are registered with the registering component 112 will be notified of events that change the critical operational state of the TPM 102.
  • the monitoring component 114 monitors data from the data lines 120A-120N to detect events that change a critical operational state of the TPM 102.
  • the monitoring component 114 is configured to detect TPM disable commands. For example, an owner or authorized user of the TPM 102 may issue a TPM disable command that disables the TPM 102 temporarily or permanently. Although other events (e.g., an enable command) may change a critical operational state of the TPM 102, an illustrative example based on a TPM disable command is described herein.
  • the monitoring component 114 Upon detecting the TPM disable command, the monitoring component 114 causes the TPM disable command to be buffered, re-directed or otherwise prevents the TPM disable command from being processed by the TPM 102 until a predetermined amount of time has passed or until predetermined criteria is met. The monitoring component 114 also notifies the querying component 116 that the TPM disable command was detected.
  • the querying component 116 notifies the software agents 110A-110N (assuming all of the software agents 110A-110N are registered) of the intended TPM disable command and queries the software agents 110A-110N for a response via the query signals 122A-122N.
  • the querying component 116 is associated with a "call-back" mechanism.
  • a call-back mechanism refers to a communication interface between the TSS 104 and 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.
  • COM component object model
  • DCOM distributed component object model
  • RPC remote procedure call
  • XML Extensible Markup Language
  • SOAP Simple Object Access Protocol
  • the policy component 118 establishes rules that determine how the software agents 110A-110N are queried and how responses received (or not received) from the software agents 110A-110N are interpreted. In at least some embodiments, the policy component 118 establishes that each registered software agent in the chain 108 is notified of intended critical state changes to the TPM 102 and is given an opportunity to respond before the TPM 102 is allowed to change states (e.g., from active to disabled).
  • each registered software agent is informed of the intended critical state change in turn (e.g., in round-robin fashion).
  • a registered software agent Upon being notified, a registered software agent is able to complete all tasks that are necessary for continued successful operation after the TPM 102 is disabled.
  • control of the chain 108 is given back to the "caller" (e.g., the call-back mechanism implemented by the TSS 104), which notifies the next registered software agent in the chain 108.
  • the critical state change is allowed (e.g., the TPM 102 is allowed to process the TPM disable command).
  • the policy component 118 establishes a response time period for each registered software agent.
  • each registered software agent is given a threshold amount of time to respond to the notification before control of the chain 108 is 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 component 118 is 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.
  • the policy component 118 establishes 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 component 118 may establish that registered software agents that are unable to automatically disassociate (or re-associate) themselves with the TPM 102 are granted veto power over TPM disable commands. Likewise, the policy component 118 may establish that registered software agents that are unable to transparently (without notifying a user) disassociate (or re-associate) themselves with the TPM 102 are granted veto power over TPM disable commands.
  • the policy component 118 may establish that registered software agents that are unable to disassociate (or re-associate) themselves with the TPM 102 without a predetermined amount of complexity are granted veto power over TPM disable commands.
  • the TSS 104 is 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.
  • TPM 102 is 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 TPM 102 to 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.
  • a full disk encryption software agent that uses the TPM 102 to protect a symmetric key that protects the entire contents of the hard disk. Before the TPM 102 is disabled, the full disk encryption software agent needs time to disassociate the data protection key from the TPM 102 (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 TPM 102 to 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 component 118 are 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 TPM 102 are granted veto power.
  • registered software agents are able to provide one of a set of responses.
  • 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 component 118 establishes which of these responses are accepted by the TSS 104. For example, if the policy component 118 establishes that no software agents are authorized to veto the TPM disable command, the TSS 104 will not honor REJECT responses. Also, the policy component 118 may 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 TPM 102 is able to process the TPM disable command.
  • the policy component 118 Based on the responses (and non-responses) from the registered software agents, the policy component 118 also establishes one of a set of actions for the TSS 104 to perform. In at least some embodiments, the policy component 118 establishes 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.
  • the TSS 104 allows the TPM 102 to process the TPM disable command.
  • 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).
  • the LEAVE ENABLED action is selected, the TSS 104 does not allow the issued TPM disable command to be processed.
  • the CALL BACK action is selected, the TSS 104 waits 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.
  • the TSS 104 transmits 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 TSS 104.
  • 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 TPM 102 or 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 component 118 by listing those policies (or providing a link to access the policies) in the message.
  • the notification process of Figure 1 is illustrated with respect to a TPM disable command, the notification process is also extendable to the case where the TPM 102 is enabled (after being disabled).
  • the registering component 112 registers software agents to be notified if a TPM enable command is issued.
  • the querying component 116 informs registered or interested software agents that the TPM 102 is 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 TPM 102.
  • a hard disk software agent is able to encrypt data and decrypt data on the hard drive based on the cryptographic capabilities of the TPM 102.
  • the policy component 118 may 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 component 118 may be dynamically customized and selected by an administrator or authorized user of the TPM 102.
  • FIG. 2 shows a network-based system 200 in accordance with embodiments of the invention.
  • the system 200 comprises a plurality of user computers 202A-202N coupled to a server 206 via a network 204.
  • the server 206 comprises a TPM 102 and a TSS 104 having a consensus module 106.
  • the user computers 202A-202N each have at least one software agent that depends on the TPM 102 for security operations (e.g., encryption and decryption).
  • the user computer 202A is associated with the software agent 110A
  • the user computer 202B is associated with the software agent 110B and so on.
  • the software agents 110A-110N may be, for example, applications, device drivers, or other software proxy agents acting for the BIOS of each of the user computers 202A-202N.
  • the system 200 also may comprise an administrator computer 208 that is configured to transmit enable commands 210 and disable commands 212 to the TPM 102 based on input from an administrator or authorized user.
  • the consensus module 106 may register the software agents 110A-110N to be notified of events that change the critical operational state of the TPM 102.
  • an event that changes the critical operational state of the TPM 102 may be the issuance of the enable command 210 or the disable command 212.
  • the consensus module 106 queries the software agents 102A-102N before the TPM's state is allowed to change.
  • the system 200 implements a chained call-back mechanism 214 to notify or inform the software agents 102A-102N of the event as previously described.
  • the software agents 110A-110N are able to transmit responses to the TSS 104 via the network 204. Each response may give permission to change the critical operational state of the TPM 102, 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 module 106 determines an action to perform based on the responses and based on established policies. As previously described, the consensus module 106 may implement the policy module 118 to 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 TPM 102 is capable of being used for a variety of purposes.
  • the TPM 102 is implemented to authenticate users of the user computers 202A-202N.
  • a user may be authenticated by the TPM 102 before or during each user computer's boot process.
  • the user-authentication provided by the TPM 102 takes place by virtue of a middle agent such as a computer system's BIOS, which indirectly verifies the user of the TPM 102 by asking the user to provide authentication secrets.
  • the authentication secrets are used by the middle agent with the TPM 102 (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 TPM 102 decrypts 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.
  • TPM user-key BLOB binary large object
  • the TPM 102 may be implemented to encrypt and decrypt information stored on the user computers 202A-202N (e.g., information stored on hard drives). Also, the TPM 102 may authenticate software (e.g., transaction software) running on a remote system of the network 204. Also, the TPM 102 may uniquely or pseudo-anonymously identify computer systems on a network that is TPM-enabled. Also, the TPM 102 may 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 TPM 102 can be used, reference may be made to published information provided by the Trusted Computing Platform Alliance (TCPA) or the Trusted Computing Group (TCG).
  • TCPA Trusted Computing Platform Alliance
  • TCG Trusted Computing Group
  • the software agents 110A-110N of the user computers 202A-202N that depend (or could depend) on the TPM 102 are at least notified if an event that changes the critical operational state of the TPM 102 has occurred.
  • the software agents 110A-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 agents 110A-110N may be able to disassociate itself from the TPM 102 before the TPM 102 is disabled. This prevents unexpected data loss or lack of service due to the disabled TPM 102.
  • policies may be established, for example, that permit all software agents 110A-110N to dissociate themselves before the TPM 102 is disabled, that provide a time limit to software agents 110A-110N to dissociate themselves before the TPM 102 is disabled, or that grant one of more of the software agents 110A-110N veto power to prevent the TPM 102 from being disabled.
  • the veto power is based, for example, on one or more considerations such as software agent types, the ability of each software agent 110A-110N to dissociate itself from the TPM 102, the ability of each software agent 110A-110N to re-associate itself with the TPM 102 or a prioritization of the software agents 110A-110N by an administrator or authorized user.
  • 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 module 106. For example, one software agent may be given more time to disassociate itself from the TPM 102 than other software agents and so on.
  • At least one of the software agents 110A-110N may be able to re-associate itself automatically with the TPM 102 before or after the TPM 102 is enabled. This may be performed in a manner that is transparent to the users of the user computers 202A-202N.
  • software agents that are registered with the consensus module 106 are able to take advantage of the services provided by the TPM 102 in a manner that is automated and transparent to users.
  • the registered software agents are also able to disassociate and re-associate themselves with the TPM 102 in an efficient manner that reduces unexpected data loss and lack of services.
  • policies of the consensus module 106 may be established that affect the registering processing, the querying process, how responses from the software agents 110A-110N are interpreted and what actions are performed by the TSS 104 based on the responses (and non-responses).
  • Figure 3 shows a method 300 in accordance with embodiments of the invention.
  • the method 300 comprises registering software agents to be notified of an event that changes a TPM's state (block 302).
  • the event may be a TPM enable command or a TPM disable command.
  • the method 300 further comprises monitoring for the event that changes the TPM's state (block 304). If the event is not detected (determination block 306), the method 300 continues to monitor for the event that changes the TPM's state (block 304). If the event is detected (determination block 306), the registered software agents are notified of the event before the TPM's state changes (block 308). Thereafter, responses from the registered software agents are monitored (block 310).
  • 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.
  • the TPM's state change is allowed or prevented based on the responses from the registered software agents (block 312).
  • 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 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.

Abstract

In at least some embodiments, a system (200) comprises a hardware unit (102) and at least one computer (202A-202N) coupled to the hardware unit (102), the at least one computer (202A-202N) having software agents (110A-110N) that utilize a function provided by the hardware unit (102). The system (200) further comprises a consensus module (106) coupled to the hardware unit (102) and the at least one computer (202A-202N). The consensus module (106) is configured to detect an event that changes a state of the hardware unit (102), notify the software agents (110A-110N) of the event before the state changes, and selectively permit the state to change based on responses from the software agents (110A-110N).

Description

    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.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • For a detailed description of exemplary embodiments of the invention, reference will now be made to the accompanying drawings in which:
  • Figure 1 shows a system in accordance with embodiments of the invention;
  • Figure 2 shows a network-based system in accordance with embodiments of the invention; and
  • Figure 3 shows a method in accordance with embodiments of the invention.
  • NOTATION AND NOMENCLATURE
  • Certain terms are used throughout the following description and claims to refer to particular system components. As one skilled in the art will appreciate, computer companies may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms "including" and "comprising" are used in an open-ended fashion, and thus should be interpreted to mean "including, but not limited to...." Also, the term "couple" or "couples" is intended to mean either an indirect, direct, optical or wireless electrical connection. Thus, if a first device couples to a second device, that connection may be through a direct electrical connection, through an indirect electrical connection via other devices and connections, through an optical electrical connection, or through a wireless electrical connection.
  • 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 and Operating Systems (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.
  • Figure 1 shows a system 100 in accordance with embodiments of the invention. As shown in Figure 1, the system 100 comprises a plurality of software agents 110A-110N. In at least some embodiments, the software agents 110A-110N are capable of being registered as part of a software chain 108 that will be described in further detail below. The software agents 110A-110N couple to a TPM 102 via a TPM software stack (TSS) 104 and depend on the TPM 102 for security services such as encryption and decryption. The TSS 104 operates as "middleware" for the TPM 102 providing common abstraction, isolation, and management services through a common application programming interface (API). As shown, the TSS 104 comprises a consensus module 106 having a registering component 112, a monitoring component 114, a querying component 116 and a policy component 118. In alternative embodiments, another cryptographic hardware module and software stack (besides the TPM 102 and the TSS 104) 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 chain 108 is notified in sequence. A software chaining mechanism can be defined in many ways. In at least some embodiments, the software chain 108 is defined such that each of the registered software agents of the software chain 108 is 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 chain 108 could 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 chain 108 is 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 module 106 is 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 module 106 may 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 module 106 is 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 TSS 104 comprises a consensus module 106 having a registering component 112, a monitoring component 114, a querying component 116 and a policy component 118. The consensus module 106 allows the software agents 110A-110N to be notified of events that change a critical operational state of the TPM 102 before the critical operational state change occurs. After notification, the software agents 110A-110N are able to delay changes to the critical operational state of the TPM 102 for a time or until predetermined criteria is met. Additionally or alternatively, the software agents 110A-110N are able to disassociate themselves from the TPM 102 before (or after) the critical operational state change occurs without unexpected data loss or denial of service.
  • To notify the software agents 110A-110N of events that change the critical operational state of the TPM 102, the software agents 110A-110N register with the TSS 104. For example, the registering component 112 of the consensus module 106 may permit the software agents 110A-110N to request registration or permit the consensus module 106 to query the applications 110A-110N for registration. Thereafter, the registering component 112 stores information that identifies which of the software agents 110A-110N are registered. In at least some embodiments, only the software agents which are registered with the registering component 112 will be notified of events that change the critical operational state of the TPM 102.
  • The monitoring component 114 monitors data from the data lines 120A-120N to detect events that change a critical operational state of the TPM 102. In at least some embodiments, the monitoring component 114 is configured to detect TPM disable commands. For example, an owner or authorized user of the TPM 102 may issue a TPM disable command that disables the TPM 102 temporarily or permanently. Although other events (e.g., an enable command) may change a critical operational state of the TPM 102, an illustrative example based on a TPM disable command is described herein.
  • Upon detecting the TPM disable command, the monitoring component 114 causes the TPM disable command to be buffered, re-directed or otherwise prevents the TPM disable command from being processed by the TPM 102 until a predetermined amount of time has passed or until predetermined criteria is met. The monitoring component 114 also notifies the querying component 116 that the TPM disable command was detected.
  • The querying component 116 notifies the software agents 110A-110N (assuming all of the software agents 110A-110N are registered) of the intended TPM disable command and queries the software agents 110A-110N for a response via the query signals 122A-122N. In at least some embodiments, the querying component 116 is associated with a "call-back" mechanism. As used herein, a call-back mechanism refers to a communication interface between the TSS 104 and 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 component 118 establishes rules that determine how the software agents 110A-110N are queried and how responses received (or not received) from the software agents 110A-110N are interpreted. In at least some embodiments, the policy component 118 establishes that each registered software agent in the chain 108 is notified of intended critical state changes to the TPM 102 and is given an opportunity to respond before the TPM 102 is 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 TPM 102 is disabled. Once a registered software agent has completed the necessary tasks, control of the chain 108 is given back to the "caller" (e.g., the call-back mechanism implemented by the TSS 104), which notifies the next registered software agent in the chain 108. At the end of the chaining operation, the critical state change is allowed (e.g., the TPM 102 is allowed to process the TPM disable command).
  • In some embodiments, the policy component 118 establishes 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 chain 108 is 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 component 118 is 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 component 118 establishes 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 component 118 may establish that registered software agents that are unable to automatically disassociate (or re-associate) themselves with the TPM 102 are granted veto power over TPM disable commands. Likewise, the policy component 118 may establish that registered software agents that are unable to transparently (without notifying a user) disassociate (or re-associate) themselves with the TPM 102 are granted veto power over TPM disable commands. Likewise, the policy component 118 may establish that registered software agents that are unable to disassociate (or re-associate) themselves with the TPM 102 without a predetermined amount of complexity are granted veto power over TPM disable commands. In at least some embodiments, the TSS 104 is 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 TPM 102 is 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 TPM 102 to 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 TPM 102 to protect a symmetric key that protects the entire contents of the hard disk. Before the TPM 102 is disabled, the full disk encryption software agent needs time to disassociate the data protection key from the TPM 102 (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 TPM 102 to 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 component 118 are 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 TPM 102 are 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 component 118 establishes which of these responses are accepted by the TSS 104. For example, if the policy component 118 establishes that no software agents are authorized to veto the TPM disable command, the TSS 104 will not honor REJECT responses. Also, the policy component 118 may 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 TPM 102 is able to process the TPM disable command.
  • Based on the responses (and non-responses) from the registered software agents, the policy component 118 also establishes one of a set of actions for the TSS 104 to perform. In at least some embodiments, the policy component 118 establishes 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 selected, the TSS 104 allows the TPM 102 to 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 selected, the TSS 104 does not allow the issued TPM disable command to be processed. If the CALL BACK action is selected, the TSS 104 waits 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 selected, the TSS 104 transmits 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 TSS 104. 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 TPM 102 or 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 component 118 by listing those policies (or providing a link to access the policies) in the message.
  • Although the notification process of Figure 1 is illustrated with respect to a TPM disable command, the notification process is also extendable to the case where the TPM 102 is enabled (after being disabled). In such a case, the registering component 112 registers software agents to be notified if a TPM enable command is issued. In response to detecting the TPM enable command by the monitoring component 114, the querying component 116 informs registered or interested software agents that the TPM 102 is 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 TPM 102. 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 TPM 102. In the case of enabling the TPM, the policy component 118 may 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 component 118 may be dynamically customized and selected by an administrator or authorized user of the TPM 102.
  • Figure 2 shows a network-based system 200 in accordance with embodiments of the invention. As shown in Figure 2, the system 200 comprises a plurality of user computers 202A-202N coupled to a server 206 via a network 204. The server 206 comprises a TPM 102 and a TSS 104 having a consensus module 106. Also, the user computers 202A-202N each have at least one software agent that depends on the TPM 102 for security operations (e.g., encryption and decryption). As shown, the user computer 202A is associated with the software agent 110A, while the user computer 202B is associated with the software agent 110B and so on. The software agents 110A-110N may be, for example, applications, device drivers, or other software proxy agents acting for the BIOS of each of the user computers 202A-202N. The system 200 also may comprise an administrator computer 208 that is configured to transmit enable commands 210 and disable commands 212 to the TPM 102 based on input from an administrator or authorized user.
  • As previously described, the consensus module 106 may register the software agents 110A-110N to be notified of events that change the critical operational state of the TPM 102. For example, an event that changes the critical operational state of the TPM 102 may be the issuance of the enable command 210 or the disable command 212. Upon detecting the event, the consensus module 106 queries the software agents 102A-102N before the TPM's state is allowed to change. In at least some embodiments, the system 200 implements a chained call-back mechanism 214 to notify or inform the software agents 102A-102N of the event as previously described.
  • The software agents 110A-110N are able to transmit responses to the TSS 104 via the network 204. Each response may give permission to change the critical operational state of the TPM 102, 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 module 106 determines an action to perform based on the responses and based on established policies. As previously described, the consensus module 106 may implement the policy module 118 to 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 TPM 102 is capable of being used for a variety of purposes. In at least some embodiments, the TPM 102 is implemented to authenticate users of the user computers 202A-202N. For example, a user may be authenticated by the TPM 102 before or during each user computer's boot process. The user-authentication provided by the TPM 102 takes place by virtue of a middle agent such as a computer system's BIOS, which indirectly verifies the user of the TPM 102 by asking the user to provide authentication secrets. The authentication secrets are used by the middle agent with the TPM 102 (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 TPM 102 decrypts 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 TPM 102 may be implemented to encrypt and decrypt information stored on the user computers 202A-202N (e.g., information stored on hard drives). Also, the TPM 102 may authenticate software (e.g., transaction software) running on a remote system of the network 204. Also, the TPM 102 may uniquely or pseudo-anonymously identify computer systems on a network that is TPM-enabled. Also, the TPM 102 may 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 TPM 102 can 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 module 106, the software agents 110A-110N of the user computers 202A-202N that depend (or could depend) on the TPM 102 are at least notified if an event that changes the critical operational state of the TPM 102 has occurred. The software agents 110A-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 agents 110A-110N may be able to disassociate itself from the TPM 102 before the TPM 102 is disabled. This prevents unexpected data loss or lack of service due to the disabled TPM 102. Again, policies may be established, for example, that permit all software agents 110A-110N to dissociate themselves before the TPM 102 is disabled, that provide a time limit to software agents 110A-110N to dissociate themselves before the TPM 102 is disabled, or that grant one of more of the software agents 110A-110N veto power to prevent the TPM 102 from 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 agent 110A-110N to dissociate itself from the TPM 102, the ability of each software agent 110A-110N to re-associate itself with the TPM 102 or a prioritization of the software agents 110A-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 module 106. For example, one software agent may be given more time to disassociate itself from the TPM 102 than 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 agents 110A-110N may be able to re-associate itself automatically with the TPM 102 before or after the TPM 102 is enabled. This may be performed in a manner that is transparent to the users of the user computers 202A-202N. Thus, software agents that are registered with the consensus module 106 are able to take advantage of the services provided by the TPM 102 in a manner that is automated and transparent to users. The registered software agents are also able to disassociate and re-associate themselves with the TPM 102 in an efficient manner that reduces unexpected data loss and lack of services. Again, policies of the consensus module 106 may be established that affect the registering processing, the querying process, how responses from the software agents 110A-110N are interpreted and what actions are performed by the TSS 104 based on the responses (and non-responses).
  • Figure 3 shows a method 300 in accordance with embodiments of the invention. As shown in Figure 3, the method 300 comprises registering software agents to be notified of an event that changes a TPM's state (block 302). For example, the event may be a TPM enable command or a TPM disable command. The method 300 further comprises monitoring for the event that changes the TPM's state (block 304). If the event is not detected (determination block 306), the method 300 continues to monitor for the event that changes the TPM's state (block 304). If the event is detected (determination block 306), the registered software agents are notified of the event before the TPM's state changes (block 308). Thereafter, responses from the registered software agents are monitored (block 310). 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 (block 312). 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.

Claims (10)

  1. A system (200), comprising:
    a hardware unit (102);
    at least one computer (202A-202N) coupled to the hardware unit (102), the at least one computer (202A-202N) having software agents (110A-110N)
    that utilize a function provided by the hardware unit (102); and
    a consensus module (106) coupled to the hardware unit (102) and the at least one computer (202A-202N), the consensus module (106) is configured to detect an event that changes a state of the hardware unit (102), notify the software agents (110A-110N) of the event before the state changes, and selectively permit the state to change based on responses from the software agents (110A-110N).
  2. The system (200) of claim 1 wherein the hardware unit (102) comprises a cryptographic hardware unit.
  3. The system (200) of claim 2 wherein the cryptographic hardware unit comprises a Trusted Platform Module (TPM).
  4. The system (200) of claim 1 wherein the responses are selected from the group consisting of a response that grants permission to changing the state, a response that rejects changing the state and a response that requests a delay before changing the state.
  5. The system (200) of claim 4 wherein the consensus module (106) comprises a policy component (118) that enables a user to customize how the responses are considered.
  6. A method, comprising:
    querying a plurality of software agents (110A-110N) regarding an event that changes an operational state of a cryptographic hardware unit (102); and
    selectively permitting changes to the operational state of the cryptographic hardware unit (102) based on responses from the software agents (110A-110N).
  7. The method of claim 6 further comprising monitoring a data line to detect the event, the event selected from a group consisting of a command that disables the cryptographic hardware unit (102) and a command that enables the cryptographic hardware unit (102).
  8. The method of claim 6 further comprises registering the plurality of software agents (110A-110N) to be notified of the event and to provide a response.
  9. The method of claim 8 wherein selectively permitting changes to the operational state of the cryptographic hardware unit (102) comprises considering responses that give permission to change the operational state, responses that reject changing the operational state and responses that request a delay before changing the operational state.
  10. The method of claim 6 further comprising prioritizing the responses based on each software agent's ability to disassociate itself with the cryptographic hardware unit (102).
EP06253607.3A 2005-08-10 2006-07-10 Method and systems that selectively permit changes to a cryptographic hardware unit's state Expired - Fee Related EP1752901B1 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/201,008 US7711953B2 (en) 2005-08-10 2005-08-10 Methods and systems that selectively permit changes to a cryptographic hardware unit's state

Publications (3)

Publication Number Publication Date
EP1752901A2 true EP1752901A2 (en) 2007-02-14
EP1752901A3 EP1752901A3 (en) 2007-10-24
EP1752901B1 EP1752901B1 (en) 2013-10-02

Family

ID=37398385

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06253607.3A Expired - Fee Related EP1752901B1 (en) 2005-08-10 2006-07-10 Method and systems that selectively permit changes to a cryptographic hardware unit's state

Country Status (3)

Country Link
US (1) US7711953B2 (en)
EP (1) EP1752901B1 (en)
CN (1) CN1912886B (en)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080148387A1 (en) * 2006-10-18 2008-06-19 Madina Shab H Trusted platform module management system and method
US8385551B2 (en) * 2006-12-22 2013-02-26 Telefonaktiebolaget L M Ericsson (Publ) Highly available cryptographic key storage (HACKS)
US8549619B2 (en) * 2007-01-22 2013-10-01 Dell Products L.P. Removable hard disk with embedded security card
US8607359B2 (en) * 2007-01-22 2013-12-10 Dell Products L.P. Removable hard disk with front panel input
US7917741B2 (en) * 2007-04-10 2011-03-29 Standard Microsystems Corporation Enhancing security of a system via access by an embedded controller to a secure storage device
US8556991B2 (en) * 2008-08-08 2013-10-15 Absolute Software Corporation Approaches for ensuring data security
CA2732831C (en) * 2008-08-08 2015-07-14 Absolute Software Corporation Secure computing environment using a client heartbeat to address theft and unauthorized access
US8566961B2 (en) 2008-08-08 2013-10-22 Absolute Software Corporation Approaches for a location aware client
US20110131418A1 (en) * 2009-12-02 2011-06-02 Giga-Byte Technology Co.,Ltd. Method of password management and authentication suitable for trusted platform module
US20110154023A1 (en) * 2009-12-21 2011-06-23 Smith Ned M Protected device management
CN102812431A (en) 2010-03-22 2012-12-05 Lrdc系统有限公司 A method of identifying and protecting the integrity of a set of source data
US8595493B2 (en) 2010-04-13 2013-11-26 Microsoft Corporation Multi-phase storage volume transformation
US8856875B2 (en) * 2011-07-25 2014-10-07 Intel Corporation Software delivery models
US9455879B1 (en) * 2013-03-04 2016-09-27 Amazon Technologies, Inc. Validating changes to attributes for computing resources
US9411975B2 (en) 2014-03-31 2016-08-09 Intel Corporation Methods and apparatus to securely share data
CN106557359B (en) * 2015-09-30 2021-02-05 腾讯科技(深圳)有限公司 Task scheduling method and system
US20210342487A1 (en) * 2020-04-30 2021-11-04 Dell Products, L.P. One-time programmable features for storage devices

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030159056A1 (en) * 2002-02-15 2003-08-21 International Business Machines Corporation Method and system for securing enablement access to a data security device

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030159056A1 (en) * 2002-02-15 2003-08-21 International Business Machines Corporation Method and system for securing enablement access to a data security device

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BRESLAU ET AL: "Dynamic Object Temporary Stop/Disappearance Notification/Permission" IP.COM JOURNAL, IP.COM INC., WEST HENRIETTA, NY, US, 1 December 1995 (1995-12-01), XP013105047 ISSN: 1533-0001 *

Also Published As

Publication number Publication date
CN1912886A (en) 2007-02-14
EP1752901B1 (en) 2013-10-02
US20070038856A1 (en) 2007-02-15
CN1912886B (en) 2012-01-04
US7711953B2 (en) 2010-05-04
EP1752901A3 (en) 2007-10-24

Similar Documents

Publication Publication Date Title
US7711953B2 (en) Methods and systems that selectively permit changes to a cryptographic hardware unit's state
US11093604B2 (en) Personalized and cryptographically secure access control in trusted execution environment
US9507964B2 (en) Regulating access using information regarding a host machine of a portable storage drive
JP4219561B2 (en) Smart card user interface for trusted computing platforms
US8402267B1 (en) Security enhanced network device and method for secure operation of same
EP1380916B1 (en) Data protection program, method and apparatus
US5949882A (en) Method and apparatus for allowing access to secured computer resources by utilzing a password and an external encryption algorithm
US20070079373A1 (en) Preventing the installation of rootkits using a master computer
US20070101156A1 (en) Methods and systems for associating an embedded security chip with a computer
US20070118646A1 (en) Preventing the installation of rootkits on a standalone computer
US20030041255A1 (en) Method and apparatus for locking an application within a trusted environment
US10897359B2 (en) Controlled storage device access
EP2936369A1 (en) Verification of password using a keyboard with a secure password entry mode
CN101771689A (en) Method and system for enterprise network single-sign-on by a manageability engine
US20040199769A1 (en) Provision of commands to computing apparatus
WO2013025592A1 (en) Method and apparatus for token-based conditioning
WO2013025599A2 (en) Apparatus and method for handling transaction tokens
WO2013025586A2 (en) Apparatus and method for performing session validation
WO2013025590A1 (en) Method and apparatus for making token-based access decisions
US20090089881A1 (en) Methods of licensing software programs and protecting them from unauthorized use
Sze et al. Hardening openstack cloud platforms against compute node compromises
CN103890717A (en) Providing a function of a basic input/output system (BIOS) in a privileged domain
US9129098B2 (en) Methods of protecting software programs from unauthorized use
US20170201528A1 (en) Method for providing trusted service based on secure area and apparatus using the same
US7200861B2 (en) Method and system for validating physical access to an information handling system

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

17P Request for examination filed

Effective date: 20080408

17Q First examination report despatched

Effective date: 20080519

AKX Designation fees paid

Designated state(s): DE GB

RTI1 Title (correction)

Free format text: METHOD AND SYSTEMS THAT SELECTIVELY PERMIT CHANGES TO A CRYPTOGRAPHIC HARDWARE UNIT'S STATE

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 602006038644

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: G06F0021000000

Ipc: G06F0021570000

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 21/57 20130101AFI20130308BHEP

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20130502

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): DE GB

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602006038644

Country of ref document: DE

Effective date: 20131128

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602006038644

Country of ref document: DE

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20140703

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602006038644

Country of ref document: DE

Effective date: 20140703

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20210623

Year of fee payment: 16

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20201214

Year of fee payment: 16

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 602006038644

Country of ref document: DE

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20220710

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220710

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230201