Time-limited key derivation

Abstract

Methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for time-limited key derivation. In some implementations, a module receives a request to provide a key identifier and obtains a control value indicative of a future time. The module obtains a counter value indicative of a first time, where the counter value is based on a current state of the counter, and where the counter is configured to update the state of the counter at a predetermined frequency. The module generates a comparison result based on comparing a control value indicative of a future time to a counter value indicative of a first time. The module generates a key based on the key identifier, the control value, the comparison result, and the stored random number, and the module provides the key in response to the request.

Description

Background Art

[0001] A hardware-based or software-based engine may be used to generate keys for cryptography. A key may include alphanumeric symbols or bits that, when applied to the data with an appropriate function, encrypt or decrypt the data. The encrypted data may be unrecognizable compared to the original unencrypted data. The encrypted data may be decrypted with a decryption key. Encryption and decryption may use the same key, as in symmetric key cryptography, or different keys, as in public key private key cryptography. Summary of the invention

[0002] In some implementations, a computer system includes a security module that is configured to generate a cryptographic key and enforce a time limit on the key. After the key is generated, the security module allows the key to be obtained again, but a time constraint is applied that limits when the key can be obtained again. The security module can allow many different keys to be generated, and different, customized time limits can be enforced for the corresponding keys. The security module can be configured so that when the time limit for the key is met, the security module can repeatedly generate and provide the same key. However, when the time limit is not met (e.g., after the expiration time of the key is reached), the original key cannot be obtained. For example, if the time limit is not met, attempting to obtain a key from the security module will generate a new key that does not match the original key.

[0003] The security module can be used to generate keys and enforce time constraints on obtaining the keys without storing the keys or corresponding time limits. This enables the security module to generate a large number of unique keys, with only a minimum amount of state information stored in the security module. This is a significant advantage because the security module does not need to include memory for key storage, and does not need to keep track of the generated keys and their corresponding time constraints. The security module can be configured to regenerate each key when a key is requested, rather than storing the generated keys. As long as the time constraints are met, providing the same set of inputs results in the generation of the same key.

[0004] When generating a key, the security module provides an input set such as a key derivation context as an input to a key derivation function. The input set includes an identifier of the key and a value representing a time limit for the key. The security module also determines whether the time limit has been reached and includes the result in the input set. For example, the security module compares a counter value from an internal counter with a received control value representing a time limit for the key, and the comparison result is included in the input set provided to the key derivation function. Since the key derivation process uses the comparison result as an input, a change in the comparison result (e.g., due to the expiration time of the key) will produce a key different from the key originally obtained. Therefore, once the expiration time is reached, the security module actually "forgets" the original key, and the original key cannot be generated again by the security module or obtained again from the security module.

[0005] The security module can apply various types of time constraints to the generation of keys. As an example, a time constraint on a key can set an expiration time so that the key can be regenerated before the expiration time, but not after. As another example, a time constraint on a key can prevent the key from being generated before a predetermined time, but allow the key to be generated after. This mode can provide a "time vault" or time lock function, where access is not obtained until a predetermined time is reached.

[0006] The security module may be configured to provide a key in response to a request from an operating system, an application, a software or hardware module, or another requestor. The request for the key may include a key identifier that identifies the key. The request may also include a control value that indicates an expiration time after which the key cannot be generated again or an access time before which the key cannot be generated again. The security module may process the key identifier and the control value, including comparing the control value with a counter value of a counter from the security module to generate an input data set that uniquely identifies the key to be generated. The security module may then use the input data set to generate the requested key. The security module may provide the key to the requestor for subsequent cryptographic operations, such as encryption or decryption.

[0007] The security module can provide the ability to limit the time range in which a key can be obtained, and can do so with greater efficiency and security than other methods. For example, some traditional key derivation methods use a key repository that stores multiple active or inactive keys. The key repository requires storage resources sufficient to store all required keys. In contrast, the process described herein allows the device to maintain a collection of active or inactive keys that are time-limited without storing the keys. Instead, the entity requesting the key stores a key identifier and a control value representing the time limit. Since the key is generated by the identification information and control value provided by the requester, the security module that generates the key does not need to store any key or access the storage component that stores the key. In this way, the number of keys in circulation is not limited by storage requirements. Security is also improved because there are no stored keys that can be potentially accessed by an attacker without authorization.

[0008] In order to obtain the key, an entity such as a requestor may provide an identifier and a control value. The security module may perform operations based on the identifier and the control value, as discussed further below, to generate the corresponding key. The security module may be configured to operate in a variety of different modes to generate keys with different types of time constraints. For example, a key generated in one mode may be provided with an expiration time, so the key may be generated before the expiration time, but the security module "forgets" the key after the expiration time, and the key becomes unrecoverable. As another example, the following mode may be used to generate the key: in this mode, after the initial generation of the key, the key cannot be generated again until a predetermined future access time. In effect, the key is protected in a time-locked "vault", and after the access time occurs, the "vault" is opened and the key can be generated again. The access time or expiration time may be defined by the control value used.

[0009] The technology described herein can be used to provide strong, time-based protection for access control information. Many systems use keys bound to lock screen knowledge factors. For example, some cryptographic keys can be generated only after a user presents a lock screen knowledge factor (LSKF) such as a personal identification number (PIN), pattern, or password. However, enforcing time limits on authorization is usually done using software policies or attributes that may be easily circumvented or attacked. In order to provide stronger enforcement of time limits on access control, keys bound to LSKF and authorization tokens can be cached after the access token is first encrypted using a time-limited key (e.g., a key generated using a time-limited export process discussed herein). Since key generation is subject to time constraints, after reaching an expiration time (e.g., a predetermined time, such as one hour after entering the LKSF), the key cannot be generated again. This can enforce the desired authorization time limit and force the re-entry of the LKSF after the expiration time to authorize new access. After the expiration time, applications will not be able to obtain the time-limited key, and thus any application that did not obtain the time-limited key before the expiration time will not be able to decrypt and use the encrypted authorization token from the cache.

[0010] The innovative aspects of the subject matter described in this specification are embodied in a method comprising: receiving a request to provide a key identifier; obtaining a control value indicating a future time; obtaining a counter value indicating a first time, wherein the counter value is based on a current state of a counter, wherein the counter is configured to update the state of the counter at a predetermined frequency; generating a comparison result based on comparing the control value indicating the future time with the counter value indicating the first time; generating a key based on the key identifier, the control value, the comparison result, and a stored random number; and providing the key in response to the request.

[0011] Other implementations of this and other aspects include corresponding systems, devices, and computer programs configured to perform the actions of these methods, encoded on computer storage devices. The system of one or more computers may be so configured due to software, firmware, hardware, or a combination thereof installed on the system that causes the system to perform actions during operation. One or more computer programs may be so configured due to having instructions that, when executed by a data processing device, cause the device to perform actions.

[0012] The foregoing and other embodiments may each optionally include one or more of the following features, alone or in combination. For example, in some implementations, at least obtaining a counter value, generating a comparison result, and generating a key are performed by a secure hardware module.

[0013] In some implementations, at least obtaining the counter value, generating the comparison result, and generating the key are performed by a secure hardware module of a system-on-chip of the mobile device.

[0014] In some implementations, prior to receiving the timestamp, the actions include providing (i) a counter value from a hardware-based counter and (ii) a frequency of the counter value.

[0015] In some implementations, the stored random numbers are generated by a hardware-based random number generator.

[0016] In some implementations, the actions include: detecting manipulation of the counter; and in response to detecting manipulation of the counter, replacing the stored random number with a new random number obtained from a hardware-based random number generator.

[0017] In some implementations, the actions include: detecting an overflow of a counter; and in response to detecting the overflow of the counter, replacing the stored random number with a new random number obtained from a hardware-based random number generator.

[0018] In some implementations, the predetermined frequency is based on a frequency of a clock signal; and the actions include: detecting a change in the frequency of the clock signal; and in response to detecting the change in the frequency of the clock signal, replacing the stored random number with a new random number obtained from a hardware-based random number generator.

[0019] In some implementations, after generating the key and before providing the key in response to the request, the actions include: obtaining a second counter value from the counter based on a state of the counter after generating the key; determining that the second counter value satisfies a predetermined condition specifying a relationship relative to the control value; and wherein providing the key in response to the request is performed in response to determining that the second counter value satisfies the predetermined condition.

[0020] In some implementations, determining that the second counter value satisfies the predetermined condition includes determining that the second counter value represents a time before the future time represented by the control value.

[0021] In some implementations, the control value is a future counter value that represents a value that the counter will reach at a future time.

[0022] In some implementations, the control value specifies a counter value that, when reached by the counter, disallows further generation of keys based on the key identifier and the control value.

[0023] In some implementations, the action includes operating a secure hardware module configured to (i) enable the key to be generated again before a future time in response to receiving the control value and the key identifier, and (ii) not allow the key to be generated after the future time.

[0024] In some implementations, the counter value is a first counter value and the key is a first key; the secure hardware module is configured to not allow generation of the first key after a future time by providing a second key different from the first key in response to receiving a control value and a key identifier; and based on a comparison result of comparing the second counter value with the control value being different from a comparison result of comparing the first counter value with the control value, the second key is generated to be different from the first key.

[0025] In some implementations, the key is a first key and the comparison result is a first comparison result; and the actions include: after generating the first key, receiving a second request associated with a key identifier and a control value; obtaining a second counter value based on a state of the counter, the second counter value indicating a second time, the second time being after the first time and before a future time indicated by the control value; generating a second comparison result based on comparing the control value indicating the future time with the second counter value indicating the second time, wherein the second comparison result is the same as the first comparison result; and generating a second key based on the key identifier, the control value, the second comparison result, and the stored random number, wherein the second key is the same as the first key.

[0026] In some implementations, the key is a first key and the comparison result is a first comparison result; and the actions include: after generating the first key, receiving a second request associated with a key identifier and a control value; obtaining a second counter value based on a state of the counter, the second counter value indicating a second time, the second time being after a future time indicated by the control value; generating a second comparison result based on comparing the control value indicating the future time with the second counter value indicating the second time, wherein the second comparison result is different from the first comparison result; and generating a second key based on the key identifier, the control value, the second comparison result, and the stored random number, wherein the second key is different from the first key.

[0027] In some implementations, obtaining the control value includes receiving a time value indicating a future time or an amount of time until the future time is reached; and determining a future counter value to be reached at the future time as the control value, the future counter value being determined based on a current counter value from the counter, a time value, and a predetermined frequency.

[0028] In some implementations, the action includes, after providing the key, not allowing further key generation until a future time is reached.

[0029] In some implementations, the action includes determining a vault context value based on a comparison result, wherein the comparison result is used to select the vault context value from a vault counter value and an input vault context value; and generating a key involves applying a key derivation function to a set of values ​​including a key identifier, a control value, the comparison result, a stored random number, and the vault context value.

[0030] In some implementations, the action includes providing a vault context value. In some implementations, the action includes obtaining a mode selection value configured to select from a plurality of modes for generating a key, the plurality of modes including (i) a first mode that does not allow further generation of the key after a future time; and (ii) a second mode that does not allow further generation of the key before the future time; and generating the key involves applying a key derivation function to a value set including the key identifier, the control value, the comparison result, the stored random number, and the mode selection value.

[0031] Innovative aspects of the subject matter described in this specification are embodied in a hardware module for generating cryptographic keys, the hardware module comprising: an input interface configured to receive (i) a control value representing time and (ii) a key identifier; a random number generator and a memory element configured to store random numbers generated by the random number generator; a counter configured to change monotonically based on a clock signal; a comparator configured to generate a comparison result based on a comparison of the control value with a counter value from the counter; and a key derivation circuit configured to generate a key based on the key identifier, the control value, the comparison result, and the random number stored in the memory element.

[0032] In some implementations, the hardware module enables the key to be generated again before a future time in response to receiving the control value and the key identifier, and the hardware module does not allow the key to be generated after the time indicated by the control value.

[0033] In some implementations, the hardware module limits a time period in which the key may be regenerated, and the control value represents a future counter value that sets a future time at which the time period expires.

[0034] In some implementations, the hardware module limits a time period in which keys may be regenerated, and the control value represents a future counter value that sets a future time at which the time period begins.

[0035] In some implementations, the hardware module is configured to determine whether a counter value from the counter has a predetermined relationship relative to the control value; and the hardware module is configured to selectively output the key depending on whether the counter value from the counter has the predetermined relationship relative to the control value.

[0036] In some implementations, the hardware module is configured to determine a second counter value based on a state of the counter after generating the key, and determine whether the second counter value has a predetermined relationship with respect to the control value; and the hardware module is configured to (i) output the key if the second counter value has the predetermined relationship with respect to the control value; and (ii) prevent output of the key if the second counter value does not have the predetermined relationship with respect to the control value.

[0037] In some implementations, the hardware module is configured to detect a change in the clock signal and, in response to detecting the change in the clock signal, replace the random number stored in the memory element with a new random number from the random number generator.

[0038] In some implementations, the hardware module is configured to detect an overflow of the counter and, in response to detecting the overflow of the counter, replace the random number stored in the memory element with a new random number from the random number generator.

[0039] In some implementations, the hardware module is configured to output a counter value from the counter.

[0040] In some implementations, a hardware module can generate multiple different keys and enforce individually specified expiration times for the ability to regenerate the respective keys without storing the keys and without storing the expiration times.

[0041] In some implementations, the input interface is configured to receive an input context value; the hardware module is configured to determine a context value based on a comparison result, wherein the comparison result is used to select a context value from (i) a counter value from a second counter and (i) the input context value; and the key derivation circuit is configured to apply a key derivation function to a value set including a key identifier, a control value, the comparison result, a stored random number, and the determined context value.

[0042] In some implementations, the hardware module is configured to provide the determined context value as an output of the hardware module.

[0043] In some implementations, the input interface is configured to receive a mode selection value that identifies a mode selected from a plurality of modes for generating keys, the plurality of modes comprising (i) a first mode that does not allow further key generation after a future time; and (ii) a second mode that does not allow further key generation before a future time; and the key derivation circuit is configured to apply a key derivation function to a value set comprising a key identifier, a control value, a comparison result, a stored random number, and the mode selection value.

[0044] In some implementations, the hardware module is configured to perform an operation on the mode selection value and the comparison result, and the key derivation circuit uses the result of the operation when generating the key.

[0045] In some implementations, the operation is an XOR operation.

[0046] In some implementations, the hardware module includes a multiplexer configured to select from a plurality of input values ​​to provide a context value to a key derivation circuit; the plurality of input values ​​include a predetermined value, an input context value, and a counter value from a second counter; the multiplexer is configured to select the context value from the plurality of input values ​​based on a mode selection value and a comparison result; and the context value selected by the multiplexer is included in a value set to which the key derivation circuit applies a key derivation function to generate a key.

[0047] In some implementations, the hardware module includes a second counter configured to change its stored value in response to a generated key read from the security hardware module; the hardware module is configured to use the counter value from the second counter in the generation of the key, such that after the generated key is read from the hardware module, the hardware module prevents further generation of the key until a time indicated by the control value is reached.

[0048] The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features and advantages of the invention will become apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 is a diagram illustrating an example of a system for time-limited key derivation.

[0050] Figure 2A is a diagram illustrating an example of a security module that may be used to perform time-limited key derivation.

[0051] Figure 2B is a diagram illustrating a second example of a security module that may be used to perform time-limited key derivation.

[0052] Figure 2C is a diagram illustrating an example of an iterative key engine for performing time-limited key derivation.

[0053] Figure 3 is a diagram illustrating a third example of a security module that may be used to perform time-limited key derivation.

[0054] Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION

[0055] Figure 1 1 is a diagram illustrating an example of a system 100 for time-limited key derivation. The system 100 includes a device 104 operated by a user 102. The device 104 may be a computing device such as a laptop computer, a desktop computer, a server computer, a tablet computer, a smart phone, a smart watch, a smart speaker, a navigation device, a television, a home appliance, an entertainment device, etc. The device 104 includes a security module 108 configured to generate cryptographic keys and set limits on the time range in which the keys can be obtained. The security module 108 may be implemented as a module of an integrated circuit such as a system on a chip (SoC), a central processing unit, a chipset, or a trusted platform module. In some implementations, the security module 108 operates within a trusted execution environment (TEE) of the device 104.

[0056] Figure 1 A series of operations and data flows are shown, labeled as stages (A)-(C). In short, two software modules running on device 104 - a first application 106 and a second application 118 - each interact with security module 108 to obtain a key from security module 108. First application 106 requests a key before a predetermined expiration time, and therefore receives the expected key 116. In contrast, second application 118 requests a key after a predetermined expiration time, and therefore receives a different key 120. This illustrates how security module 108 enforces a time limit on the generation of keys, such that the original key 116 can no longer be obtained from security module 108 after the expiration time.

[0057] In phase (A), the first application 106 interacts with the security module 108 to obtain the key 116. In this example, to request the key, the application provides two items: (1) a context, which serves as an identifier of the key to be generated, and (2) a control value, which specifies a time limit on the generation of the key (e.g., an expiration time). The security module 108 uses these two items, along with other data, to generate the key.

[0058] To enforce the time limit, the security module 108 includes a monotonic counter that is periodically updated based on a clock signal. The control value may specify an expiration time as a value that the counter will reach at the expected expiration time. To enable the application to determine the control value and set a custom expiration time for the key, the security module 108 is configured to provide a current counter value as an output. Here, the security module 108 provides a counter value 110 indicating the current value of the counter. In some implementations, the security module 108 provides the counter value 110 in response to a request from the first application 106 for the counter value 110. In other implementations, the security module 108 may make the counter value 110 available in a register, memory, or other element so that the first application 106 or another element can simply read the current value of the counter.

[0059] The application 106 generates and sends a request for a key including a context 112 and a control value 114. The context 112 is a key identifier that identifies the key to be generated. The context 112 may indicate the purpose of the key being generated or the type of key being generated, and is used to distinguish the key from other keys that may have the same expiration time. The context 112 may be represented as text, numbers, or any other appropriate form.

[0060] The application 106 determines a control value 114 to set an expected expiration time after which no key can be generated. The expiration time can be specified as a future value of a counter in the security module, for example, a counter value that will occur at the expected expiration time. For example, the application 106 can use the current counter value 110 from the security module and add an offset to it to obtain the control value 114. The value of the offset is determined based on the expected expiration time and the rate at which the counter is incremented. For example, if the counter is incremented every clock cycle, the offset can be determined by multiplying the clock frequency (e.g., number of cycles per second) by the number of future seconds that the expiration should occur.

[0061] For example, to calculate the control value 114, the first application 106 may determine the amount of time between the current time and the expected future expiration time. The first application 106 may determine the number of clock cycles that will occur from the current time until the expiration time, and therefore the counter increments, based on the clock frequency of the clock that generates the counter value 110. For example, if the expiration time is 1 hour in the future and the counter is updated at a rate of once per second, the control value 114 may be determined by adding together the current counter value 110 and the number of increments that will occur in 1 hour (e.g., 3600, for 3600 seconds multiplied by a counter update frequency of 1 Hz).

[0062] The security module 108 receives a request for a key from a first application at a first time, labeled "Time 1" in the figure. The security module 108 obtains the context 112 and the control value 114 from the request. As part of generating the requested key, the security module 108 performs a comparison between the received control value 114 and the current state of a counter within the security module 108. This is represented as a first comparison 115, and the result indicates whether the expiration time represented by the control value 114 has been reached. For example, the comparison result may be "0" to indicate that the current counter value is still less than the control value 114. The security module 108 generates the requested key, in this case key 116, using the control value 114 and the comparison result in the input set provided by the security module 108 to the key derivation function. Including the comparison result in the input set for key derivation ensures that the key 116 can only be generated before the expiration time. After the expiration time, the comparison result will be different (e.g., "1" instead of "0"), thereby generating a key different from the key 116.

[0063] exist Figure 1 In the example of FIG. 1 , the security module 108 provides the first key 116 in response to obtaining the context 112 and the control value 114. Details about the process of generating the key are described below with respect to subsequent figures (including FIGS. 2 to 3 ). Figure 3 ) for further discussion.

[0064] In some implementations, the first key 116 is a cryptographic key that can be used to encrypt or decrypt data. For example, the user 102 or application 106 can encrypt the data with the first key 116 before sending the encrypted data to a data storage, a process or module of the device 104, or another device. In order to enable another module to obtain the first key 116 and decrypt the data, the context 112 and the control value 114 can be provided to the other module so that the other module can also request and obtain the first key 116 from the security module 108. In some implementations, the context 112 and the control value 114 are sent in an encrypted form that has been encrypted using another encryption key known to the other module. For example, the module can decrypt the data including the context 112 and the control value 114, and then provide the context 112 and the control value 114 to the security module 108 to obtain a key for decrypting the data encrypted with the first key 116.

[0065] In phase (B), the first application 106 provides information to the second application 118 that enables the second application 118 to obtain the first key 116 from the security module 108, subject to a time limit for generating the first key 116. As shown, the first application 106 provides the context 112 and the control value 114 to the second application 118. In some implementations, the first application 106 provides the context 112 and the control value 114 to the second application 118 in addition to other data that may be encrypted with the first key 116. In some implementations, a data packet sent from the first application 106 to the second application 118 includes the context 112 and the control value 114 encrypted using an encryption key that is different from the first key 116. In this case, the second application 118 may decrypt the data packet including the context 112 and the control value 114 and use these values ​​to request the first key 116 from the security module 108.

[0066] In phase (C), the second application 118 attempts to obtain the first key 116 from the security module 108. However, because the time limit for the generation of the first key 116 has been reached, the security module 108 is no longer allowed to generate the first key 116. The second application 118 sends a request to the security module 108 at a second time, labeled "Time 2". In the example, this time is after Time 1 and also after the expiration time specified by the control value 114. The request sent by the second application 118 provides the security module 108 with the same context 112 and the same control value 114 that the first application 106 used when initially obtaining the first key 116. If the second time is before the expiration time, as was the case when the first key 116 was initially generated, the security module 108 will generate the same first key 116 that was provided to the first application 106. However, because the second time is after the expiration time, the set of values ​​used to generate the key is different, and therefore the security module 108 generates a second key 120 that is different from the first key 116.

[0067] As part of responding to the request from the second application 118, the security module 108 performs a second comparison 119 to determine whether the current time is before the expiration time of the key. For example, the security module 108 obtains a current counter value indicating the value of an internal counter. The security module 108 compares the current clock value with the control value 114. A comparison result of, for example, "1" indicates that the counter value is greater than the control value 114, and therefore the current time is after the expiration time. Due to timing reasons, the result of the comparison 119 ("1") is different from the result of the earlier comparison 115 ("0"). The result of the comparison 119 is included in the input set for generating the key in response to the request from the second application 118, and therefore the security module generates a key 120 that is different from the key 116, even if both keys 116, 120 are generated based on the same context 112 and control value 114. By generating a different key 120 after the time limit expires, the security module 108 ensures that the time limit for the generation of the first key 116 is enforced.

[0068] above Figure 1 The discussion of describes setting an expiration time for the ability to generate the first key 116, but other types of time constraints may also be set. For example, the security module 108 may operate in a time vault mode in which the first key 116 may be generated once, but cannot be generated again until a certain time has passed, such as an access time. In this case, the first key 116 may represent an initial key generated, and the second key 120 may represent a key requested before a predetermined access time. Thus, in the time vault mode, the security module 108 may prevent the requesting module from obtaining a key until the access time, and after the access time, the first key 116 becomes available.

[0069] In some implementations, the operations described as being performed by the first application 106 or the second application 118 are performed by another program or component of the device 104. For example, the request to obtain the key may be provided by an operating system, a non-application software module, a hardware module on the same integrated circuit as the security module 108 or on a different integrated circuit, etc.

[0070] Figure 2A2 is a diagram showing an example of a system 200 for generating a key with an expiration time. The system 200 includes a security module 108, and further details the operation of the security module 108 in the device 104 and the interaction of the security module with an application or other modules. The security module 108 can be implemented as a part of a system on a chip (SoC) or another integrated circuit of the device 104. The security module 108 includes a comparator 214, a clock counter 216, a clock monitoring module 218, a random number generator 220, an overflow monitoring module 222, a key input register 213, a key derivation engine 232, and a verification engine 234. The system 200 also includes a control value engine 210 and an application 212.

[0071] In some implementations, the security module 108 is a hardware element of a computer or other electronic device. For example, the security module 108 can be implemented using one or more integrated circuits. The security module 108 can be implemented in secure hardware that is tamper-resistant to avoid external interference with the key generation process.

[0072] Figure 2A The example of shows that the security module 108 generates a key with a custom time constraint on the time range in which the key can be obtained. As an overview, the security module 108 obtains data from an entity such as an application 212 to generate a value in a key input register 213. The security module 108 then sends the data in the key input register 213 to a key derivation engine 232, which applies a key derivation function to the data to generate a key 236. In some implementations, the key 236 is represented by one or more alphanumeric symbols as shown in item 238. The key derivation engine 232 provides the key 236 as an output 240, for example, in response to a request to generate a key from the application 212. In general, the system 200 can generate a key and provide the key to any entity including a process or device.

[0073] The security module 108 is configured to generate a key based on the value in the key input register 213. Changing any value in the key input register 213 will change the resulting key that will be generated. Figure 2A In the example of , two of the values ​​(user context 226 and control value 228) are provided from outside the security module by the application 212 requesting the key. The two other values ​​(random number 224 and comparison result 230) are generated within the security module 108 and cannot be changed by the external module. The contents of the key input registers 213 are combined to form an overall key derivation function (KDF) context that serves as source data or seed data for the key derivation engine 232 to generate keys. The security module 108 can be configured to continuously use the same key derivation function over time so that when the same KDF context is repeatedly provided, the same key is generated.

[0074] The security module 108 includes an entropy source in the form of a random number generator 220. The random number generator 220 generates a random number 224 stored in the key input register 213. The random number 224 is not replaced with each key request, but is maintained over time and reused for many key requests unless a specific condition occurs to change the stored random number. Since the random number 224 is part of the KDF context of all keys generated, the change of the stored random number 224 irreversibly makes all previous keys unretrievable. Therefore, the value of the stored random number 224 is usually only changed or initialized in response to an event that expects to make the previous key unretrievable (such as each power cycle of the device 104, a manual reset of the device 104, an overflow of the clock counter 216, or a change in the clock signal (e.g., a slowdown or stop of the clock signal, which can affect the measurement of the time used to enforce the time constraint)). The random number 224 is an important and sensitive part of the key generation process, and therefore it is protected from leakage and manipulation, for example, against glitches and access or manipulation through power or timing side channels.

[0075] The security module 108 uses a clock signal to measure the passage of time and enforce time limits. The clock signal is typically provided by an external source such as a clock generation module of a SoC or integrated circuit including the security module 108. In order to track the passage of time, the security module 108 uses a clock counter 216 to monotonically change states in response to pulses of the clock signal. For example, the clock counter 216 can be a digital counter configured to increment the stored value at each clock cycle (e.g., for each rising edge of the clock signal). Of course, other variants can also be used. For example, the clock counter 216 can be configured to decrement the counter value instead of incrementing the counter value. As another example, the clock counter 216 can be configured to adjust the stored value after a certain number of clock cycles have occurred (e.g., every 10 cycles, every 100 cycles, etc.) instead of for each cycle.

[0076] Because the security module 108 relies on the clock signal and the clock counter 216 to track the passage of time, the security module 108 may include elements for detecting and responding to conditions that interfere with this time tracking. For example, the clock monitoring module 218 can detect changes in the clock signal (e.g., a change in the clock frequency or a stop of the clock), and in response can trigger the random number generator 220 to replace the stored random number 224 with a new random number. Similarly, the overflow monitoring module 222 can detect an overflow of the clock counter 216, and in response can trigger the random number generator 220 to replace the stored random number 224 with a new random number. These changes to the stored random number 224 make all previously generated keys non-retrievable to avoid the possibility of obtaining any key outside of the appropriate time limit. The monitoring modules 218, 222 are discussed further below.

[0077] To request a key, the application 212 provides the user context 226 and the control value 228 to the security module 108. These two values ​​uniquely identify the desired key and enable the security module 108 to generate the desired key, as long as the time constraints for the key are met and the random number 224 does not change. The user context 226 is a key identifier that can specify the key or its purpose. In some implementations, the user context 226 can be an arbitrary value selected by the application that originally requested the creation of the key, subject to size restrictions.

[0078] Control value 228 specifies the time limit to be applied to the key. Figure 2A In the example of FIG. 1 , the security module 108 is configured such that the control value 228 specifies an expiration time after which no further keys can be generated. The expiration time can be selected by the application 212 that is requesting the key to be generated. Using the control value, the security module 108 allows a separate, customized expiration time to be specified for each key generated by the security module. When a key is generated for the first time, the control value 228 can be requested to be a future time so that the expiration time is not reached before the initial key generation.

[0079] The control value 228 may specify an expiration time relative to the state of the clock counter 216 in the security module 108. For example, the control value 228 may be a timestamp representing an expiration time, specifically, a future time after which key generation will no longer be permitted. To enable an application or other module to determine the control value, the security module 108 allows the counter value to be read outside of the security module 108. Thus, the current counter value serves as a base value or reference from which to specify future times. The counter value 204 together with the known clock frequency 208 or counter update frequency may be used to set the control value 228 to the desired expiration time when a new key is requested.

[0080] In some implementations, a control value engine 210 is provided to generate a control value representing an expected expiration time. For example, the application 212 may provide the expected expiration time 206 to the control value engine 210, and the control value engine 210 may return a control value 228 representing the expiration time 206. The data set used by the control value engine 210 to generate the control value 228 includes a current clock counter value 204 from the clock counter 216, the expiration time 206 specified by the application 212, and a clock frequency 208 indicating the rate at which the clock counter 216 is updated. In some implementations, the control value engine 210 obtains the clock frequency 208 from the security module 108. For example, in addition to the clock frequency 208, the security module 108 may also provide the clock counter value 204. As discussed above, the clock counter 216 monotonically changes (e.g., continuously increases or continuously decreases) its value based on the clock frequency 208.

[0081] Based on the data 202, the control value engine 210 generates a control value 228. The expiration time 216 may be represented as a specific time (e.g., 1:02 p.m., with a desired level of precision) or as an offset (e.g., 1 hour in the future). In some implementations, the control value engine 210 determines a time difference between the current time and the expiration time 206. For example, the control value engine 210 may obtain the current time from a local time service of the device 104. The control value engine 210 may calculate the difference between the current time and the expiration time 206. Based on the clock frequency 208, the control value engine 210 may calculate the number of increments that will occur within a time period from the current time to the expiration time 206. The control value engine 210 may add the number of increments to the current clock counter value 204 to generate a control value 228 that indicates a future value of the clock counter 216 that will occur at the expiration time 206. The control value engine 210 provides the control value 228 to the application 212.

[0082] After the application 212 provides the control value 228 and the user context 226 to the security module 108, the security module 108 fills the contents of the key input register 213. The control value 228 and the user context 226 may be directly included in the key input register 213. However, this is not required, and in some implementations, the security module 108 may generate a modified version of the user context provided by the application 212. For example, the security module 108 may apply a rule to adjust one or more values ​​of the user context provided by the application 212 to generate the user context 226 stored in the key input register 213. The adjustment may include an adjustment for making the user context conform to a specific format to be included in the key input register 213, such as adjusting the data format, truncating the data, or adding a padding value to fit the expected data size, etc. If any adjustments are made, they are done in a repeatable manner so that the same input user context generates the same user context in the key input register 213 each time.

[0083] The security module 108 also determines a comparison result 230 to be included in the key input register 213. The comparison result 230 indicates whether the current clock counter value exceeds the control value. In fact, this checks whether the current time is after the expiration time 206. In order to perform the comparison, the security module 108 provides the control value 228 and the current counter value to the comparator 214. The comparator 214 implements a Boolean comparison function. For example, the comparator 214 can perform a less than comparison, a less than or equal to comparison, a greater than comparison, or a greater than or equal to comparison. The specific comparison used (e.g., less than and greater than) is not important here, as long as the same comparison function is used and the comparison result changes after the expiration time.

[0084] Comparator 214 generates comparison result 230 based on comparison of control value 228 with the counter value from clock counter 216. In some implementations, comparison result 230 includes one or more bits. For example, comparison result 230 may be a single bit indicating the comparison result from comparator 214. For example, a value of "0" may be provided for a comparison result before the expiration time, and a value of "1" may be provided for a comparison result after the expiration time. Comparison result 230 completes the data set in key input register 213.

[0085] The security module 108 provides the data set in the key input register 213 (eg, the stored random number 224, user context 226, control value 228, and comparison result 230) as input to the key derivation engine 232. The key derivation engine 232 may be a component of the security module 108.

[0086] The key derivation engine 232 generates the key 236. In some implementations, the key derivation engine 232 generates the key 236 based on a Rivest-Shamir-Adleman (RSA) scheme. In some implementations, the key derivation engine 232 generates the key 236 based on one or more secure hash algorithms (SHA), such as SHA-224, SHA-256, SHA-384, SHA-512, SHA-512 / 224, SHA-512 / 256.

[0087] The key derivation engine 232 generates the key 236 based on the set of inputs in the key input register 213 such that any change to the contents of the key input register 213 will change the resulting key generated, but the same contents of the key input register 213 will generate the same key 236. That is, if an entity, such as the application 212 or another application, process, or device, provides the user context 226 and the control value 228 to the security module 108 and the time conditions for key generation are met, then the entity can obtain the same key 236 that the application 212 obtained.

[0088] The security module 108 provides the key 236 as an output 240 to the application 212. In general, the security module 108 can be used by any of a variety of entities to provide context values ​​and control values ​​to obtain keys from the security module 108. Thus, the security module 108 can provide key generation services for many different hardware modules and software modules to obtain keys, each of which has its own customized expiration time.

[0089] In some implementations, the security module 108 includes a verification engine 234 that checks that one or more conditions are satisfied. For example, it is desirable for the security module 108 to ensure, at least in the first instance of requesting a key, that the time limit for the key has not expired before generating the key. Specifically, it is desirable to ensure that a key is generated with a counter value that is still less than the control value 228, so that the key generation is based on a comparison result 230 indicating that the expiration time has not been reached. Otherwise, if the comparison result 230 used to create the original key shows that the expiration time has passed, all future key requests will produce the same key, no matter how far in the future they occur. In fact, generating a key at a time after the expiration time set by the control value 228 will create a key that will never expire. If an application or module expects to enforce a time limit, but in fact there is no time limit to constrain future generation of keys, this behavior will be unexpected and undesirable.

[0090] To verify that the generated key was validly generated, with an expiration time that is still in the future, the verification engine 234 can obtain a counter value from the clock counter 216. For example, the verification engine 234 can obtain a counter value that represents the state of the counter 216 after the key derivation engine 232 has derived the key 236. The verification engine 234 then compares the obtained counter value with the control value 228 to ensure that even after the key 236 is generated, the current counter value is still less than the control value 228 (e.g., the counter value has not yet been incremented to the extent that it reaches or exceeds the control value 228). The verification engine 234 can use other techniques to determine that the key 236 is correctly generated based on a future expiration time rather than an inappropriate past time. For example, the verification engine 234 can check that the counter value used to generate the comparison result 230 is less than the control value 228, or the verification engine 234 can check the comparison result 230 itself to verify that it shows that the counter has not reached the control value 228.

[0091] In some implementations, the verification engine 234 can check one or more other conditions, such as whether the difference between the counter value from the clock counter 216 and the control value 228 satisfies a threshold. For example, the verification engine 234 can calculate the difference between the counter value and the control value 228. The verification engine 234 can compare the difference to a threshold. The threshold can represent a minimum amount of time for regeneration of a key. For example, the threshold can be set to require a minimum of 5 seconds between the generation of a key and a subsequent expiration time associated with the key.

[0092] If the verification engine 234 determines that the appropriate conditions are not met, the verification engine 234 can send a signal or message (e.g., a flag, an error, an exception, etc.) indicating the problem. For example, if the expiration time occurs before the key is generated, the verification engine 234 can notify the application 212 that the key will not enforce future expiration, or that the key is not the version of the key requested by the input value. In a similar manner, if the expiration time will occur within less than a minimum amount of time since the key was generated, the verification engine 234 can similarly indicate this to the application 212. In some implementations, if the conditions checked by the verification engine 234 are not met, the verification engine 234 can prevent the output of the generated key. In the case of generating an original key for which a time restriction on a future expiration time is expected to be enforced, preventing the output of the key may be useful to avoid the application 212 receiving a key for which no time restriction is applied. If a request from the application 212 or the operating mode of the security module 108 requires the application of a future time constraint, the security module 108 can indicate to the application 212 that a different control value indicating a later expiration time is required.

[0093] As discussed above, the security module 108 measures the passage of time by relying on a clock signal with a consistent frequency to periodically change the value in the clock counter 216. If the clock signal slows or stops, or if the clock counter overflows, the time conditions enforced on key generation may potentially be circumvented. To prevent this, the clock monitoring module 218 and the overflow monitoring module 222 perform monitoring to detect conditions that interfere with the enforcement of time limits, and trigger replacement of the stored random number 224 if those conditions occur.

[0094] The clock monitoring module 218 monitors the clock signal received by the security module to ensure that the clock frequency remains sufficiently consistent (e.g., with a predetermined tolerance). If a significant decrease in the clock frequency is detected, the clock monitoring module 218 renders all previous keys irretrievable by triggering a random number to provide a new random number to replace the stored random number 224. This is done because an unexpected or unmanaged change in the clock frequency will alter the security module's detection of the passage of time and, therefore, may allow keys to be generated outside of the restricted time set for the keys.

[0095] Overflow monitoring module 222 detects overflow of clock counter 216 and responds to the overflow. In some implementations, clock counter 216 obtains a counter value from clock counter 216 and detects when an overflow occurs (e.g., when the value rolls over to zero after exceeding a maximum value of counter 216). Additionally or alternatively, overflow monitoring module 222 may obtain an overflow flag (e.g., a signal or event notification) sent by clock counter 216 indicating that clock counter 216 has overflowed.

[0096] In some implementations, the overflow monitoring module 222 periodically obtains the counter value. The overflow monitoring module 222 can be configured to detect an overflow of the clock counter 216 based on the obtained counter value. For example, the clock monitoring module 218 can compare the counter value obtained from the clock counter 216 with an overflow value indicating the value of the counter value after an overflow of the clock counter 216 occurs. In some implementations, the clock counter 216 starts from 0 and increments until the overflow starts counting from 0 again. In some implementations, the clock counter 216 starts from another value and increments or decrements until the initial value is reached again. The overflow monitoring module 222 can detect an overflow by comparing one or more counter values ​​obtained from the counter value 216 with a value associated with the overflow (such as an initial counter value).

[0097] When overflow monitoring module 222 detects an overflow, it sends a signal to instruct random number generator 220 to generate a new random number to replace the stored random number 224. This change makes all keys generated using the previously stored random number 224 irrecoverable. This is done because, after counter 216 overflows, a comparison of the counter value with the corresponding control value of the previously generated key will no longer be an accurate indication of whether the time constraint is met. Therefore, resetting the value of clock counter 216 by overflow or otherwise results in an overall reset of key generation so that the time constraint is correctly judged relative to the new state of counter 216.

[0098] In some implementations, the random number generator 220 is a hardware-based random number generator (HRNG). For example, the random number generator 220 can generate random numbers, such as the random number 224, that vary with one or more physical environmental properties (e.g., temperature, electrical noise, etc.). The physical environmental properties may include the state of the charge within the random number generator 220. The hardware-based random number generator provides security by helping to ensure that parties cannot easily model the state of the random number generator 220 to determine the corresponding generated random number. In some implementations, the random number generator 220 includes one or more pseudo-random number generators (PRNG). For example, the random number generator 220 may include one or more functions configured to generate random numbers that are difficult to model based solely on the generated random number output of the random number generator 220.

[0099] Figure 2A The example of shows an implementation in which the same user context 226 and control value 228 can be used to repeatedly generate a key until the expiration time 206, or until an earlier event that changes the stored random number 224 (e.g., a reset of the device 104, a manipulation of the clock signal, or an overflow of the clock counter 216). Before the expiration time 206 or any change to the stored random number 224, any entity can provide the user context 226 and control value 228 to the security module 108 to generate the same key 236. After the expiration time 206, at least the comparison result 230 provided to the key input register 213 will have changed, and therefore the resulting key will also change. As discussed above, the key derivation engine 232 can be configured so that changes in the input cause large changes in the output. Changes in the comparison result 230 will mean that even when the entity provides the same user context 226 and control value 228, the comparison result 230 will be different, which means that the key 236 cannot be generated again. After the expiration time, the original key 236 may still be used by applications or modules that have obtained the key 236 before the expiration time. However, any attempt to obtain the key 236 from the security module 108 after the expiration time will be unsuccessful.

[0100] Figure 2B 2 is a diagram illustrating an example system 250 for generating a key with an expiration time. Similar to system 200, system 250 includes a security module 108 that generates a key 236 to be used in a cryptographic operation, and the security module 108 sets an expiration time after which the key 236 cannot be generated again. However, when generating the key 236, the security module 108 in system 250 provides the key derivation function 232 with the key. Figure 2A System 250 stores the key derivation context in key input register 251 (rather than key input register 213), in which key 252 is stored instead of stored random number 224. To increase security, key 252 may be based on stored key 258 that is updated regularly and frequently (such as every minute, every five minutes, etc.).

[0101] Key 252 is set and periodically updated by iterative key engine 256, rather than by random number generator 220. Because key 252 is not solely dependent on the random number generator, system 250 can be more resilient to the random number generator being compromised. For example, in system 250, an attacker would have to compromise (e.g., gain control of) both random number generator 254 and iterative key engine 256 in order to compromise the security of the key generated using the value in key input register 251.

[0102] The security module 108 changes the value of the stored key 258 at regular intervals. Each change is made by taking the current value of the stored key 258 and running it through the key derivation function once to generate a new stored key 258 that replaces the previous value. Thus, in normal operation (e.g., no device reset or tampering to trigger a new random number to replace the stored key 258), the current stored key 258 is derived from the previous key, which itself was derived from the previous key, and so on. This mechanism provides a gradual, monotonic progression through a series of stored keys 258 over time. Future values ​​of the stored key 258 can be derived, but past values ​​of the stored key 258 cannot be derived because they are not stored and cannot be easily determined from the current stored key 258. Given the current value of the stored key 258, the value of the stored key 258 that will exist at a specific time in the future can be calculated by iteratively running the key derivation function an appropriate number of times.

[0103] When the security module 108 generates the key 236, the value for the key 252 in the key input register 251 is set based on the latest value of the stored key 258. However, the stored key 258 is not necessarily used directly as the value of the key 252. Instead, the iterative key engine 256 starts with the current value of the stored key 258 and performs a variable number of key derivation cycles to derive a value for the key 252. When multiple key derivation cycles are performed, in the first key derivation cycle, the stored key 258 is the input to the key derivation process, and then in each subsequent cycle, the iterative key engine 256 runs the key output of the previous cycle through the key derivation function again. The same key derivation function is used for each key derivation cycle, so that if the same starting input is used and if the same number of key derivation cycles are performed, the same final result can be repeatedly generated. The number of key derivation cycles to be performed in order to generate the key 252 is determined based on the control value 228 that specifies the expiration time of the generation of the key 236. When the security module 108 generates the key 236, the iterative key engine 256 sets the key 252 to the value of the stored key 258 that will exist at the expiration time. In this way, at any point in time before the expiration time set by the control value 228, the iterative key engine 256 can recreate the same stored key 258 that will exist at the expiration time and thus correctly generate the key 236.

[0104] In more detail, the iterative key engine 256 accesses the stored key 258. The stored key 258 is initially set to a random number generated by the random number generator 254. The stored key 258 is replaced by a random number when the device is reset, tampering is detected (e.g., a change in the clock signal), or the counter value 204 overflows completely. The iterative key engine 256 periodically updates the stored key 258, for example, in response to detecting an overflow of a portion of the clock counter value 204. The iterative key engine 256 can update the stored key 258 more frequently in response to detecting an overflow of only a portion of the counter value 204 (e.g., a change in an intermediate bit, such as the 7 least significant bits of the 32 bits of the clock counter value 204 returning to zero), rather than waiting for the entire counter value to overflow completely (e.g., a flip of the most significant bit, or if a 32-bit counter value is used, all 32 bits return to zero). One or more bits to be monitored for changes or overflows can be selected to trigger updating the stored key 258 at a desired interval (e.g., every 30 seconds, 1 minute, 5 minutes, etc.).

[0105] To generate the key 236 in response to the request, the iterative key engine 256 sets the value of the key 252 based on the stored key 258, the clock counter value 204, and the control value 228. The iterative key engine 256 iteratively applies the key derivation function to the stored key 258 to generate the key 252. For example, the iterative key engine 256 can compare the clock counter value 204 to the control value 228 to determine the number of partial overflows (e.g., overflows of a predetermined least significant portion of the counter value 204) that will occur from a time corresponding to the current clock counter value 204 to a time corresponding to the control value 228.

[0106] For each partial overflow (e.g., an overflow of the least significant portion), the iterative key engine 256 can perform an iteration of applying a key derivation function. The key derivation function can be a hash function or other function that deterministically maps an input value to an output value. The iteration of applying the key derivation function can include obtaining an input value and applying the key derivation function to the input value to generate an output. The first iteration can use the stored key 258 as an input value. Subsequent iterations can use the output of the previous iteration as input. After the iterative key engine 256 performs a number of iterations corresponding to the number of overflows that will occur from the time corresponding to the clock counter value 204 to the time corresponding to the control value 228, the output of the last iteration is used as the key 252.

[0107] In an example scenario, consider an implementation in which the stored key 258 is updated once per minute. Each update increments the version of the stored key 258, e.g., initially version 0, one update cycle later version 1, two update cycles later version 2, and so on. The application 212 provides the user context 226 and the control value 228 in a first request for the key 236 at a first time (e.g., 1:10 p.m.). The control value 228 of the key 236 specifies a time 10 minutes in the future (e.g., 1:20 p.m.), after which the stored key 258 will have been updated ten times through regular, minute-by-minute updates. At the first time, the clock counter value 204 is a first clock value, and the iterative key engine 256 determines, based on the difference between the first clock counter value and the control value 228, that 10 overflows will occur from the first time (e.g., 1:10 p.m.) to the expiration time corresponding to the control value 228 (e.g., 1:20 p.m.). Then, the iterative key engine 256 generates the key 252 by performing 10 key derivation cycles, wherein the second and subsequent cycles each act on the output of the previous cycle, as described above. To generate the original and authentic key 236, the key 252 (e.g., key version 10) is the result of iteratively applying the key derivation function 10 times to the value of the stored key 258 (e.g., version 0) that existed at the first time (e.g., 1:10 p.m.).

[0108] At a second time, such as 1:12 p.m., application 212 or another application may provide user context 226 and control value 228 in a second request for key 236. Between the first time and the second time, the determined number of bits representing clock counter value 204 has overflowed twice. In response to each overflow, iterative key engine 256 has updated stored key 258 by performing a key derivation function on stored key 258 and then replacing the previous stored key 258 with the output of the key derivation function. At the second time, stored key 258 has been updated since the original key request, resulting in key version 2 as the value of stored key 258. Although security module 108 does not store any state information about the original key, iterative key engine 258 may still determine the correct value of key 252 based on the difference between the current time and the expiration time (e.g., from clock counter value 204 and control value 228).

[0109] At a second time (e.g., 1:12 p.m.), the clock counter value 204 has increased to the second clock value, and the stored key 258 is now version 2. The iterative key engine 256 determines, based on the difference between the second clock value and the control value 228, that eight overflows will occur from the second time to the time specified by the control value 228. The iterative key engine 256 then generates the key 252 by performing eight key derivation cycles on the stored key 258 (e.g., version 2). The current stored key 258 (e.g., version 2) has the effect of two key derivation cycles incorporated into it. Applying eight further key derivation cycles to the version 2 key will achieve the same result achieved by applying ten key derivation cycles to the version 0 key (e.g., version 10). Therefore, the key 252 generated at the second time is the same value as the key 252 generated at the first time. Using the same key 252, system 250 will generate the same key 236 generated at the first time (e.g., 1:10 p.m.) at the second time (e.g., 1:12 p.m.) as that generated at the first time (e.g., 1:10 p.m.) as long as the other contents of key input register 251 (e.g., user context 226, control value 228, and comparison result 230) are the same as those used in response to the first request. In this way, keys such as key 236 can be used for cryptographic operations, and their derivation can be time-limited in the same manner as discussed with respect to system 200.

[0110] Still continuing with the example, a third request for the same key 236 may be received after the expiration time, such as at 1:21 p.m. At this point, the stored key 258 has been updated beyond the value used as the key 252 to generate the original key 236 in response to the first request and the second request. For example, at 1:21 p.m., the value of the stored key 238 is version 11, where the previous version 10 was used to generate the authentic original key 236. Because the stored key 258 is updated incrementally over time without storing previous versions, it is not possible to obtain previous versions of the stored key 258. As a result, in this example, within one minute of the expiration time set by the control value 228, the original key 236 becomes unrecoverable due to the unavailability of the correct value (e.g., version 10) of the key 252 required to generate the original key 236. This mechanism further enforces the enforcement of the expiration time in addition to the change in the comparison result 230, which also changes its value once the expiration time is reached.

[0111] exist Figure 2B In the example of FIG. 1 , the control value engine 210, the application 212, the comparator 214, the clock counter 216, the clock monitoring module 218, the key derivation engine 232 and the verification engine 234 are Figure 2A The random number generator 254 can be the same as the random number generator 220, except that the random number generator 254 sets the stored key 258 instead of the random number generator 220 setting the random number 224. Similarly, the overflow monitoring module 255 can perform the functions described for the overflow monitoring module 222, except that the overflow monitoring module 255 additionally determines a second type of overflow as discussed below, for example, a partial overflow representing an overflow of a subset of the least significant bits in the counter value 204.

[0112] Figure 2C The operation of the iterative key engine 256 of the example system 250 is shown in greater detail. As discussed, the iterative key engine 256 updates the stored key 258 and sets the key 250 in the key input register 251. The iterative key engine 256 includes a key derivation engine 260. The key derivation engine 260 applies a key derivation function to an input value to generate an output value.

[0113] In the case where the iterative key engine 256 updates the stored key 258, the key iteration key engine obtains input from the overflow monitoring module 255. The overflow monitoring module 255 can detect different types of overflows of the clock counter 216 and respond, which can trigger different actions in the security module 108.

[0114] The first type of overflow may be a complete overflow of the clock counter value 204, e.g., all bits flip to zero after exceeding the maximum value of the counter 216. This may be detected as a change in the most significant bit from "1" to "0" when the counter is monotonically increasing. The overflow monitoring module 255 may generate a signal in response to the first type of overflow as discussed with respect to the overflow monitoring module 222 of the system 200 and send the signal to the random number generator 254. The security module 108 may be configured to respond to this signal by causing the random number generator 254 to generate a random number and setting the generated random number as a new stored key 258, thereby replacing the previous value of the stored key 258.

[0115] The second type of overflow may be a partial overflow, where only a subset of the bits in the clock counter value overflow. A predetermined portion of the clock counter value may be monitored for overflow to indicate an overflow of the least significant set of bits in the clock counter value 204. For example, if the clock counter value 204 is a 32-bit value, this second type of overflow may be an overflow of a predetermined number of bits in the least significant portion (e.g., the least significant 10 bits, 8 bits, or any pre-selected appropriate number). This may be detected as a change in an intermediate bit (e.g., a change in the 11th bit from "1" to "0") or as all zeros in a set of bits (e.g., bits 1 to 10). In general, the second type of overflow (e.g., a partial overflow or an intermediate overflow) may occur multiple times between the first type of overflow (e.g., an overflow of the most significant bits).

[0116] In response to the overflow monitoring module 255 detecting the second type of overflow (e.g., by monitoring the clock counter 216), the overflow monitoring module 255 may generate a signal and send the signal to the key derivation engine 260. The key derivation engine 260 may be configured to respond to this signal by obtaining the current stored key 258, applying the key derivation function to the stored key 258 to generate a temporary key 262, and replacing the stored key 258 with the newly generated temporary key 262.

[0117] The iterative key engine 256 is also used to set the key 252 of the key input register 251. In this case, the iterative key engine 256 obtains the control value 228 and the current clock counter value 204. The cycle counting engine 264 determines the number of second type overflows (e.g., overflows in the least significant portion) that will occur between the time represented by the current clock counter value 204 and the time represented by the control value 228. This number of second type overflows is then set to the number of key derivation cycles to be performed in order to generate the key 252. In some implementations, determining the number of second type overflows includes determining the difference between the control value 228 and the clock counter value 204. For example, the clock counter value 204 can be represented using 16 bits, and the second type overflow includes the least significant 10 bits flipped to 0. The cycle counting engine 264 can determine the difference between the most significant 6 bits of the control value 228 and the most significant 6 bits of the clock counter value 204. The difference between the values ​​of the most significant portions (e.g., the amount by which the control value 228 exceeds the current clock counter value 204 when the least significant portion is ignored) may be set to a key cycle count 266, which sets the number of key derivation cycles to be performed. The key cycle count 266 represents the number of second type overflows that will occur until the time set by the control value 228, and is a parameter that controls the number of iterations of applying the key derivation function to generate the key 252 for the input register 251 to be performed.

[0118] exist Figure 2C In the example of , the key cycle count 266 is a value that controls the number of iterations by applying the key derivation function of the key derivation engine 260. As an example, the cycle iteration engine 264 can determine that four second type overflows will occur between the time corresponding to the clock counter value 204 and the time corresponding to the control value 228. The iteration key engine 256 can generate the key 250 as the output of applying the key derivation function four times. In the first of the four iterations, the key derivation engine 260 obtains the current stored key 258 and applies the key derivation function to generate a temporary key 262a as an output. Then, the key derivation engine 260 performs the remaining iterations, each time using the temporary key 262a generated in the previous iteration as an input to the key derivation function to generate a new temporary key 262a as an output. The process of using the output of the key derivation function as the input of the key derivation function continues for the number of iterations specified by the key cycle count 266. The key derivation engine 260 provides the output from the last iteration as the key 252 of the key input register 251.

[0119] Variations may be made to the operation of the iterative key engine 256. For example, rather than updating the stored key 258 for every second type overflow, the iterative key engine 256 may update the stored key 258 every other second type overflow. To accommodate this, the period iteration engine 264 may determine the key period count 266 as half of the determined second type overflow that will occur during the time period between the clock counter value 204 and the control value 228. Other functions and update schedules may be used to update the stored key 258 based on overflows of bits representing the clock counter value 204, and determine the key period count 266 appropriately.

[0120] The key derivation engine 260 may include a hash function that maps an input value to an output value. In some implementations, the key derivation engine 260 uses the same key derivation function as the key derivation engine 232, or may even be the key derivation engine 232 itself.

[0121] Figure 3 1 is a diagram showing an example of a system 300 for time-limited key generation. In this example, the security module 108 has different configurations to be able to support operations in multiple modes. In one mode, the security module 108 can be configured as described above for Figure 2A The discussed approach regenerates the generated key as many times as desired until the expiration time. In the second mode - the "time vault" mode - the generated key is provided once and then cannot be regenerated until the access time. After the initial generation of the key, the key is symbolically kept locked in the vault and can only be obtained again from the security module 108 after the access time. Figure 3 The example of shows the security module 108 used in the time vault mode.

[0122] The security module 108 includes Figure 2A Many components are shown, such as clock monitoring module 218, random number generator 220, overflow monitoring module 222, comparator 214 and clock counter 216. Figure 3 In the illustrated implementation, the security module 108 additionally includes an AND operator 308, a multiplexer 310, and a vault counter 312. The security module 108 includes a Figure 2A The key input register 213 of the embodiment of the present invention further generates a key input register 314 of the embodiment of the present invention. The system 300 includes a control value engine 210 that assists in generating control values ​​and an application 212 that generates inputs and provides the inputs to the security module 108 to generate a key 320.

[0123] exist Figure 3In the example of , the key derivation context stored in the key input register includes a random number 224, a user context 226, a control value 315, a state mask 317, a calculation result 318, and a vault context 316. Among these items, the user context 226, the control value 315, and the state mask 317 are provided by the application 212 requesting the key. The random number 224 is a secret, stored random number generated by the random number generator 220. As discussed above, the random number 224 persists and is reused across multiple keys unless one of the specific conditions occurs to trigger the random number 224 to be replaced by a new random number. The calculation result 318 and the vault context 316 are determined by the security module 108 and are further discussed below. In the case of the vault context, the application 212 provides the input vault context used by the security module 108 under certain conditions.

[0124] When application 212 requests a key, application 212 can select from a plurality of operating modes of the security module. For example, application 212 sets the value of state mask 317 (also referred to as "SM") to indicate whether to apply an expiration time (e.g., set the latest time that a key can be generated) or to apply a "time vault" constraint (e.g., set the earliest time that a key can be generated) for generating a key. Thus, state mask 317 has the effect of selecting the type of time constraint that will be enforced on the key. A state mask 317 value of "0" selects the time vault constraint, and a state mask 317 value of "1" selects the expiration condition for generating a key. State mask 317 itself is a value used in the context of a key derivation function, and therefore different values ​​of state mask 317 will result in different keys being generated. Furthermore, since mode selection and time constraints are a result of the key generation process, security module 108 does not need to evaluate state mask 317 and perform other operations to select or switch modes. Instead, simply performing key generation with the logic shown has the effect of enforcing the appropriate type of constraint, as discussed below.

[0125] To determine the control value 315 to provide to the security module 108, the application 212 may interact with the control value engine 210 to obtain the control value 315 for a specified future time. Figure 2A As in the example of , control value 315 can be a timestamp or a value indicating a time. However, the type of time constraint applied using this time varies depending on the mode selected by state mask 317. If state mask 317 is set to "1", control value 315 will set an expiration time for the generation of keys. If state mask 317 is set to "0", control value 315 indicates the time at which further generation of keys becomes available.

[0126] Application 212 may provide control value engine 210 with data indicating a time, such as access time 304, at which further generation of keys should be allowed. Control value engine 210 uses access time 304, together with clock frequency 208 and clock counter value 204 (indicating the current value of clock counter 216) to generate control value 315 representing access time 304. Figure 2A As discussed, control value 315 may encode or specify a desired time as a future value of clock counter 216 that will occur at the desired time. Figure 2A 304, the control value engine 210 may calculate the difference between the current time and the access time 304. The control value engine 210 may calculate the number of increments of the clock counter 216 that will occur from the current time to the access time 304. The control value engine 210 may add the calculated number of increments to the clock counter value 204 to generate a control value 315 that indicates the access time 304. The same technique for specifying a time in a control value may be used for either the expiration mode or the time vault mode, but the security module 108 may apply different time constraints based on the specified time depending on the mode selected with the state mask 317.

[0127] Application 212 may provide reference Figure 2A The user context 226. In other words, the user context 226 may be a key identifier that identifies a key or its purpose, and may be any value within a predetermined size constraint.

[0128] The application 212 may also provide an input vault context 307 value. The input vault context 307 value is not used for the initial generation of the key 320, but an appropriate value is required to recreate the key 320 in the future. In effect, the input vault context 307 is the value required to unlock the vault to allow a previously generated key to be generated again. As discussed further below, in order to regenerate a previously generated key: (1) a time constraint must be satisfied so that the input vault context 307 can be passed into the key input register 314, and (2) the value of the input vault context 307 must match the vault context value used to previously generate the key.

[0129] When the security module 108 receives a request for a key from an application 212, the security module 108 provides the user context 226, the control value 315, and the state mask 317 directly to the key input register 314. The random number 224 in the key input register 314 is a random number previously generated and stored as discussed above. Then, the security module 108 generates the remaining two values ​​for the key input register 314, the operation result 318, and the vault context 316. The operation result 318 is used to enforce the time constraint for the expiration mode, and the vault context 316 is used to enforce the time constraint for the time vault mode. The values ​​of both the operation result 318 and the vault context 316 can be affected by the comparison result CMP indicating whether the current counter value of the clock counter 216 is greater than the received control value 315.

[0130] The security module 108 generates a comparison result CMP (eg, shown as Figure 2A The safety module 108 provides the control value 315 to the comparator 214, and as shown in the reference Figure 2A As discussed, comparator 214 compares control value 315 to the current value of clock counter 216. Instead of including comparison result CMP in key input register 314, security module 108 uses AND operator 308 to selectively pass comparison result CMP or status mask 317 depending on the mode selected by status mask 317.

[0131] If the status mask 317 has a value of "1", the expiration mode is selected and the result of applying the AND operator 308 to the status mask 317 and the comparison result CMP will be the comparison result CMP itself. This allows for Figure 2A In the expiration mode, the operation result 318 is the comparison result CMP, and when the counter value of the clock counter 216 is less than the control value 315, the key is initially generated with a comparison result CMP of "0". After the expiration time, the comparison result CMP becomes "1" (for example, because the counter value is greater than the control value 315), and thus the resulting key will no longer match the original key, making the original key unrecoverable after the expiration time.

[0132] On the other hand, if the state mask 317 has a value of "0", the time vault mode is selected and the operation result 318 will always be "0". The result of applying the AND operator 308 to the comparison result CMP and the zero-valued state mask 317 will be zero regardless of the comparison result CMP. This aspect of the security module 108 maintains the operation result 318 consistent with the time vault mode, so the vault context 316 - rather than the operation result 318 - enforces the time constraint.

[0133] The security module 108 generates a vault context 316 using the multiplexer 310 and the vault counter 312. The security module 108 is configured such that in the expiration mode, the vault context is always the same value, e.g., a zero value for each bit of the vault context 316. For the time vault mode, the vault context 316 changes, having a value selected from the value of the vault counter 312 and the input vault context 307.

[0134] The multiplexer 310 in the illustrated example has four inputs, two selection lines, and one output. The inputs and outputs are wide enough for multi-bit values, such as each supporting 8-bit, 16-bit, 32-bit, etc. values. The bit widths of the inputs and outputs can be the same as the bit width of the maximum value of the vault counter 312. The two selection lines each receive a single bit value, in this case, respectively (1) the comparison result CMP from the comparator 214 and (2) the state mask SM that selects the key generation mode to be used. When the state mask SM has a value of "1" (expiration mode), the multiplexer 310 selects zero as an output to be provided as the vault context 316, regardless of the value of the comparison result CMP. When the state mask SM has a value of "0" (time vault mode), the multiplexer 310 selects between the input vault context 307 and the value of the vault counter 312.

[0135] The vault counter 312 provides a monotonically changing value (e.g., only increments) that changes each time a value is read from the vault counter 312. The vault counter 312 can be configured to be initialized to zero and increment the counter value each time the counter value is read. For example, the security module 108 can read the vault counter 312 to provide the vault counter value to the multiplexer 310. After each read, the vault counter 312 increments the counter value. For example, if the vault counter 312 initially has a value of zero, a value of zero will be provided to generate a first key. For the next key request, the vault counter value will be one, having been incremented by the process of reading the vault counter 312 when generating an earlier key.

[0136] The multiplexer 310 is arranged to select the vault counter value as output when the state mask SM is "0" (e.g., the time vault mode is selected) and when the comparison result is "0" (e.g., the access time has not yet been reached, so the vault remains locked). At the first generation of a particular key, although the access time has not yet been reached, the key is generated with the vault context 316 being any value obtained from the vault counter 312. The action of reading the value counter 312 changes the state of the vault counter 312 by incrementing the stored value. Therefore, subsequent requests for the same key before the access time will generate a key using the incremented value counter value instead of the previously used value, and therefore the original key will not be generated. As long as the current time is still before the access time (e.g., the comparison result CMP is "0", indicating that the clock counter value is less than the control value 315), the current vault counter value will be used for the vault context 312, and this value will be different from the value required to obtain the original key. Therefore, all parties cannot generate a previous key before the access time for the key.

[0137] Once the access time for a particular key is reached, the vault counter value is no longer provided as the vault context 316. When the comparison result CMP is "1", the multiplexer 310 selects the input vault context 307 from the application 212 as the vault context 316, rather than selecting the vault counter value from the vault counter 312. If the application 212 provides the correct input vault context 307 value (e.g., the vault context value used to generate the original key), the application can cause the security module 108 to create the original key again. This operation effectively unlocks the vault and enables the generation of the previous key after the access time is reached.

[0138] Once the value in the key input register 314 is set, the security module provides the complete set of values ​​as input to the key derivation engine 232. Figure 2A As discussed, the key derivation engine 232 applies a key derivation function to the contents of the key input register 314 to generate a key, in this case a key 320. The key 320 may be represented by one or more alphanumeric symbols, bits, or other suitable representations. The security module 108 provides an output 324 including the key 320 to an entity or process, such as the application 212 requesting the key.

[0139] To facilitate future generation of keys, the security module 108 may provide as an output the vault context 316 used to generate the key. For example, when generating a key 320, the security module 108 may also provide the value of the vault context 316 used to generate the key 320. In order to regenerate a key generated in the time vault mode, the vault context 316 of the key needs to be known and provided to the security module 108 along with the request for the key. The security module 108 provides the value of the vault context 316 to the application 212 so that the application can forward it to another application or module, or the application 212 can regenerate the key 320 again if necessary. In summary, for another application or module that also generates the key 320, the other application or module will need to provide the user context 226, the control value 315, the state mask 317 value, and the vault context 316 for the key 320.

[0140] If a subsequent generation of key 320 is requested before access time 304, the value in key input register 314 will include a vault context 316 that does not match the vault context 316 that existed when key 320 was originally generated. Even if the correct vault context 316 is provided as input vault context 307, multiplexer 310 will select the vault counter value from vault counter 312 to use as vault context 316 rather than any input vault context 307 provided with the request. As a result, the generated key will not match key 320, and key 320 will not be able to be generated again until access time 304 specified by control value 315.

[0141] In the time vault mode, the security module 108 relies on the vault counter 312 to continuously increase its state so that previous counter values ​​are not repeated. Therefore, when the vault counter is reinitialized or experiences an overflow, the security module 108 can be configured to trigger the replacement of the random number 224 with a newly generated random number from the random number generator 220. For example, the overflow monitoring module 222 can be configured to monitor overflows in the vault counter 312 and the clock counter 216, and can be configured to replace the stored random number 224 with a new random number in response to the counter experiencing an overflow or improper operation.

[0142] In some implementations, the output 324 of the vault context 316 can be used to determine whether the key was generated as expected. For example, when regenerating a previous key, a user, entity, or process, such as the application 212, can obtain the vault context 316 from the output 324 and compare it to the known vault context 316 of the desired key. If the output vault context does not match the known vault context of the key 320, the key requester can determine that the access conditions have not been met and that the received key is not the expected key 320. The application 212 can then decide whether to use the key for cryptographic operations, such as encryption or decryption of data, based on comparing the provided vault context to the vault context 316.

[0143] A variety of implementations have been described. However, it should be understood that various modifications may be made without departing from the spirit and scope of the present disclosure. For example, various forms of the processes shown above may be used, with steps reordered, added, or deleted.

[0144] All operations in the embodiments of the present invention and the functional operations described in this specification may be implemented in a digital electronic circuit system or in computer software, firmware or hardware (including the structures disclosed in this specification and their structural equivalents), or in a combination of one or more of them. Embodiments of the present invention may be implemented as one or more computer program products, for example, one or more modules of computer program instructions, which are encoded on a computer-readable medium for execution by a data processing device or for controlling the operation of a data processing device. The computer-readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, a material composition that affects a machine-readable propagation signal, or a combination of one or more of them. The term "data processing device" covers all devices, devices and machines for processing data, including, by way of example, a programmable processor, a computer or multiple processors or computers. In addition to hardware, the device may also include code that creates an execution environment for the computer program involved, for example, code that constitutes a processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagation signal is an artificially generated signal (e.g., a machine-generated electrical, optical or electromagnetic signal) that is generated to encode information for transmission to a suitable receiver device.

[0145] A computer program (also referred to as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted languages, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or portions of code). A computer program may be deployed to execute on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communications network.

[0146] The processes and logic flows described in this specification may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by, and the apparatus may be implemented as, a special purpose logic circuit system, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0147] Processors suitable for executing computer programs include, by way of example, both general-purpose microprocessors and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or be operatively coupled to receive data from one or more mass storage devices or transfer data to one or more mass storage devices or both. However, a computer need not have such devices. In addition, a computer may be embedded in another device, such as a tablet computer, a mobile phone, a personal digital assistant (PDA), a mobile audio player, a global positioning system (GPS) receiver, to name a few. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, by way of example, semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices); magnetic disks (e.g., internal hard disks or removable disks); magneto-optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0148] To provide interaction with a user, embodiments of the present invention may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user, and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including sound, voice, or tactile input.

[0149] Embodiments of the present invention may be implemented in a computing system that includes a back-end component (e.g., as a data server), or includes a middleware component (e.g., an application server), or includes a front-end component (e.g., a client computer having a graphical user interface or a web browser through which a user can interact with an implementation of the present invention), or any combination of one or more such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), such as the Internet.

[0150] A computing system may include clients and servers. Clients and servers are generally remote from each other and typically interact through a communication network. The relationship of client and server arises from computer programs running on the respective computers and having a client-server relationship to each other.

[0151] Although this specification contains many details, these details should not be interpreted as limitations on the scope of the invention or the scope that may be claimed, but should be interpreted as descriptions of features peculiar to a particular embodiment of the invention. Certain features described in the context of a separate embodiment in this specification may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. In addition, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from the claimed combination may be deleted from the combination in some cases, and the claimed combination may involve a sub-combination or a variation of a sub-combination.

[0152] Similarly, although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring that such operations be performed in the particular order shown or in a sequential order, or that all of the operations shown be performed, to achieve the desired results. In some cases, multitasking and parallel processing may be advantageous. In addition, the separation of various system components in the above-described embodiments should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0153] In each instance where an HTML file is mentioned, other file types or formats may be substituted. For example, an HTML file may be replaced by XML, JSON, plain text, or other types of files. In addition, where a table or hash table is mentioned, other data structures (such as a spreadsheet, a relational database, or a structured file) may also be used.

[0154] Certain embodiments of the present invention have been described. Other embodiments are within the scope of the following claims. For example, the steps recited in the claims can be performed in a different order and still achieve desirable results.

Claims

1. A method comprising: receiving a request to provide a key identifier; obtaining a control value indicative of a future time; obtaining a counter value indicative of a first time, wherein the counter value is based on a current state of a counter, wherein the counter is configured to update the state of the counter at a predetermined frequency; generating a comparison result based on comparing the control value indicating the future time with the counter value indicating the first time; generating a key based on the key identifier, the control value, the comparison result, and a stored random number; and The key is provided in response to the request.

2. The method according to claim 1, wherein: At least obtaining the counter value, generating the comparison result and generating the key are performed by a secure hardware module.

3. The method according to any one of claims 1 to 2, wherein: At least obtaining the counter value, generating the comparison result, and generating the key are performed by a secure hardware module of a system on chip of the mobile device.

4. The method according to any one of claims 1 to 3, comprising before receiving the timestamp: (i) a counter value from the hardware-based counter and (ii) a counter value frequency are provided.

5. The method according to any one of claims 1 to 4, wherein: The stored random numbers are generated by a hardware-based random number generator.

6. The method according to claim 5, comprising: detecting manipulation of the counter; as well as In response to detecting the manipulation of the counter, the stored random number is replaced with a new random number obtained from the hardware-based random number generator.

7. The method according to claim 5 or 6, comprising: detecting an overflow of the counter; as well as In response to detecting the overflow of the counter, the stored random number is replaced with a new random number obtained from the hardware-based random number generator.

8. The method according to any one of claims 5 to 7, wherein: The predetermined frequency is based on the frequency of the clock signal; and Wherein, the method comprises: detecting a change in the frequency of the clock signal; and In response to detecting the change in the frequency of the clock signal, the stored random number is replaced with a new random number obtained from the hardware-based random number generator.

9. The method according to any one of claims 1 to 8, comprising, after generating the key and before providing the key in response to the request: After generating the key, obtaining a second counter value from the counter based on a state of the counter; determining that the second counter value satisfies a predetermined condition specifying a relationship relative to the control value; and in, Providing the key in response to the request is performed in response to determining that the second counter value satisfies the predetermined condition.

10. The method according to claim 9, wherein: Determining that the second counter value satisfies the predetermined condition includes determining that the second counter value represents a time before the future time represented by the control value.

11. The method according to any one of claims 1 to 10, wherein: The control value is a future counter value representative of the value that the counter will reach at the future time.

12. The method according to any one of claims 1 to 11, wherein: The control value specifies a counter value that, when reached by the counter, disallows further generation of the key based on the key identifier and the control value.

13. The method according to any one of claims 1 to 12, comprising: Operating a secure hardware module, the secure hardware module is configured to (i) enable the key to be generated again before the future time in response to receiving the control value and the key identifier, and (ii) not allow the key to be generated after the future time.

14. The method according to claim 13, wherein: The counter value is a first counter value, and the key is a first key; wherein the secure hardware module is configured to not allow generation of the first key after the future time by providing a second key different from the first key in response to receiving the control value and the key identifier; and The second key is generated to be different from the first key based on that a comparison result of comparing the second counter value with the control value is different from a comparison result of comparing the first counter value with the control value.

15. The method according to any one of claims 1 to 14, wherein: The key is a first key, and wherein the comparison result is a first comparison result; and The method further comprises, after generating the first key: receiving a second request associated with the key identifier and the control value; obtaining a second counter value based on a state of the counter, the second counter value indicating a second time after the first time and before the future time indicated by the control value; generating a second comparison result based on comparing the control value indicating the future time with the second counter value indicating the second time, wherein the second comparison result is the same as the first comparison result; and A second key is generated based on the key identifier, the control value, the second comparison result, and the stored random number, wherein the second key is the same as the first key.

16. The method according to any one of claims 1 to 15, wherein: The key is a first key, and wherein the comparison result is a first comparison result; and The method further comprises, after generating the first key: receiving a second request associated with the key identifier and the control value; obtaining a second counter value based on a state of the counter, the second counter value indicating a second time after the future time indicated by the control value; generating a second comparison result based on comparing the control value indicating the future time with the second counter value indicating the second time, wherein the second comparison result is different from the first comparison result; and A second key is generated based on the key identifier, the control value, the second comparison result, and the stored random number, wherein the second key is different from the first key.

17. The method according to any one of claims 1 to 16, wherein: Obtaining the control value includes: receiving a time value indicative of the future time or an amount of time until the future time is reached; and A future counter value to be reached at the future time is determined as the control value, the future counter value being determined based on a current counter value from the counter, the time value, and the predetermined frequency.

18. The method according to any one of claims 1 to 17, further comprising: After the key is provided, no further generation of the key is allowed until the future time is reached.

19. The method according to any one of claims 1 to 18, further comprising: determining a vault context value based on the comparison result, wherein the comparison result is used to select the vault context value from a vault counter value and an input vault context value; and Wherein, generating the key involves applying a key derivation function to a set of values ​​including the key identifier, the control value, the comparison result, the stored random number, and the vault context value.

20. The method of any one of claims 1 to 19, further comprising providing the vault context value.

21. The method of any one of claims 1 to 20, comprising obtaining a mode selection value, the mode selection value being configured to select from a plurality of modes for generating a key, the plurality of modes comprising (i) a first mode that does not allow further generation of the key after the future time, and (ii) a second mode that does not allow further generation of the key before the future time; and in, Generating the key involves applying a key derivation function to a set of values ​​including the key identifier, the control value, the comparison result, the stored random number, and the mode selection value.

22. A hardware module for generating a cryptographic key, the hardware module comprising: an input interface configured to receive (i) a control value representing a time and (ii) a key identifier; a random number generator and a memory element configured to store random numbers generated by the random number generator; a counter configured to change monotonically based on a clock signal; a comparator configured to generate a comparison result based on a comparison of the control value and a counter value from the counter; as well as A key derivation circuit is configured to generate a key based on the key identifier, the control value, the comparison result, and the random number stored in the memory element.

23. The hardware module according to claim 22, wherein: The hardware module enables the key to be generated again before the future time in response to receiving the control value and the key identifier, and wherein the hardware module does not allow the key to be generated after the time represented by the control value.

24. The hardware module according to any one of claims 22 to 23, wherein: The hardware module limits a time period in which the key can be regenerated, and wherein the control value represents a future counter value that sets a future time at which the time period expires.

25. The hardware module according to any one of claims 22 to 24, wherein: The hardware module limits a time period during which the key can be regenerated, and wherein the control value represents a future counter value that sets a future time at which the time period begins.

26. The hardware module according to any one of claims 22 to 25, wherein: The hardware module is configured to determine whether the counter value from the counter has a predetermined relationship with respect to the control value; and Wherein the hardware module is configured to selectively output the key depending on whether the counter value from the counter has the predetermined relationship with respect to the control value.

27. The hardware module according to any one of claims 22 to 26, wherein: the hardware module being configured to determine a second counter value based on a state of the counter after generating the key, and to determine whether the second counter value has a predetermined relationship with respect to the control value; and Wherein, the hardware module is configured to: (i) output the key if the second counter value has the predetermined relationship with respect to the control value; and (ii) if the second counter value does not have the predetermined relationship with respect to the control value, preventing output of the key.

28. The hardware module according to any one of claims 22 to 27, wherein: The hardware module is configured to detect a change in the clock signal and, in response to detecting the change in the clock signal, replace the random number stored in the memory element with a new random number from the random number generator.

29. The hardware module according to any one of claims 22 to 28, wherein: The hardware module is configured to detect an overflow of the counter and, in response to detecting an overflow of the counter, replace the random number stored in the memory element with a new random number from the random number generator.

30. The hardware module according to any one of claims 22 to 29, wherein: The hardware module is configured to output a counter value from the counter.

31. A hardware module according to any one of claims 22 to 30, wherein: The hardware module is capable of generating multiple different keys and enforcing individually specified expiration times for the ability to regenerate the respective keys without storing the keys and without storing the expiration times.

32. A hardware module according to any one of claims 22 to 31, wherein: The input interface is configured to receive an input context value; wherein the hardware module is configured to determine a context value based on the comparison result, wherein the comparison result is used to select the context value from (i) a counter value from a second counter and (i) the input context value; and The key derivation circuit is configured to apply the key derivation function to a value set including the key identifier, the control value, the comparison result, the stored random number and the determined context value.

33. The hardware module of claim 32, wherein: The hardware module is configured to provide the determined context value as an output of the hardware module.

34. A hardware module according to any one of claims 22 to 33, wherein: The input interface is configured to receive a mode selection value, the mode selection value identifying a mode selected from a plurality of modes for generating a key, the plurality of modes comprising (i) a first mode that does not allow further generation of the key after the future time, and (ii) a second mode that does not allow further generation of the key before the future time; and The key derivation circuit is configured to apply the key derivation function to a value set including the key identifier, the control value, the comparison result, the stored random number and the mode selection value.

35. The hardware module of claim 34, wherein: The hardware module is configured to perform an operation on the mode selection value and the comparison result, and wherein the key derivation circuit uses a result of the operation when generating the key.

36. The hardware module of claim 35, wherein: The operation is an exclusive-OR operation.

37. A hardware module according to any one of claims 34 to 36, further comprising a multiplexer configured to select from a plurality of input values ​​to provide a context value to the key derivation circuit; in, the plurality of input values ​​comprising a predetermined value, an input context value, and a counter value from a second counter; wherein the multiplexer is configured to select the context value from the plurality of input values ​​based on the mode selection value and the comparison result; and wherein the context value selected by the multiplexer is included in the set of values ​​to which the key derivation circuit applies the key derivation function to generate the key.

38. A hardware module according to any one of claims 22 to 37, comprising a second counter configured to change its stored value in response to reading the generated key from the secure hardware module; in, The hardware module is configured to use the counter value from the second counter in the generation of a key such that after reading a generated key from the hardware module, the hardware module prevents further generation of the key until the time represented by the control value is reached.

Images