PATENT DOCUMENT

Publication Number: US-11539518-B2
Application Number: US-201816614346-A
Country: US
Kind Code: B2

Title: Time-based encryption key derivation

Abstract:
Techniques are disclosed securely communicating traffic over a network. In some embodiments, an apparatus includes a first circuit having a local clock configured to maintain a local time value. The first circuit is configured to determine a synchronized time value based on the local time value, the synchronized time value being an expected time value of a reference clock. The first circuit is further configured to generate a first encryption key by calculating a key derivation function based on the synchronized time value and encrypt a portion of a packet using the first encryption key, the portion of the packet being to be communicated to a second circuit. In some embodiments, the apparatus further includes a first network node coupled to the first circuit and configured to communicate the packet to a second network node coupled to the second circuit and to include the synchronized time value in the packet.

Claims:
What is claimed is: 
     
       1. An apparatus, comprising:
 a first circuit having a local clock configured to maintain a local time value, wherein the first circuit is configured to:
 apply a determined offset to a current local time value to determine a synchronized time value, wherein the synchronized time value is an expected time value of a reference clock, and wherein the offset is determined using previously received synchronization communications; 
 generate a first encryption key by calculating a key derivation function based on the synchronized time value; 
 encrypt a portion of a packet using the first encryption key, wherein the portion of the packet is to be communicated to a second circuit; and 
 provide the synchronized time value used to generate the first encryption key for inclusion in the packet. 
 
 
     
     
       2. The apparatus of  claim 1 , further comprising:
 a first network node coupled to the first circuit, wherein the first network node is configured to: 
 communicate the packet to a second network node coupled to the second circuit; and 
 include the synchronized time value in the packet as a packet identifier usable by the second circuit to validate the packet. 
 
     
     
       3. The apparatus of  claim 2 , wherein the first circuit is configured to:
 generate a second encryption key for the first network node by calculating a key derivation function based on the synchronized time value; and 
 provide the second encryption key to the first network node, wherein the first network node is configured to encrypt of a payload of the packet using the second encryption key. 
 
     
     
       4. The apparatus of  claim 1 , wherein calculating the key derivation function includes encrypting the synchronized time value using a different encryption key that has a longer validity period than a validity period of the first encryption key. 
     
     
       5. The apparatus of  claim 4 , wherein the first circuit is configured to receive the different encryption key from a source that is external to the first circuit. 
     
     
       6. The apparatus of  claim 4 , wherein calculating the key derivation function includes:
 generating a random value using a random number generator; and 
 encrypting the synchronized time value and the random value using the different encryption key to generate the first encryption key. 
 
     
     
       7. The apparatus of  claim 6 , wherein the first circuit is configured to:
 determine, based on the local clock, that the first encryption key has expired; 
 in response to the first encryption key expiring, generate a subsequent encryption key using the different encryption key to encrypt another synchronized time value and the random value; and 
 encrypt a portion of a different packet using the subsequent encryption key, wherein the portion of the different packet is to be communicated to the second circuit. 
 
     
     
       8. The apparatus of  claim 1 , wherein the first circuit is configured to:
 receive, from a third circuit, an encrypted portion of a different packet having a synchronized time value included by the third circuit; derive a key based on the included synchronized time value; and 
 use the derived key to decrypt the encrypted portion of the different packet. 
 
     
     
       9. A non-transitory computer readable medium having program instructions stored therein that are executable by an apparatus to cause the apparatus to perform operations comprising:
 maintaining, by a first circuit of the apparatus, a local time value in a local clock; 
 determining a synchronized time value by applying a determined offset to the local time value, wherein the synchronized time value is an expected time value of a reference clock, and wherein the offset is determined using previously received synchronization communications; 
 generating a first encryption key by calculating a key derivation function based on the synchronized time value; 
 encrypting a portion of a packet using the first encryption key, wherein the portion of the packet is to be communicated to a second circuit; and 
 providing the synchronized time value used to generate the first encryption key for inclusion in the packet. 
 
     
     
       10. The computer readable medium of  claim 9 , wherein calculating the key derivation function includes encrypting the synchronized time value using a different encryption key that has a longer validity period than a validity period of the first encryption key. 
     
     
       11. The computer readable medium of  claim 10 , wherein the operations further comprise:
 receiving the different encryption key from a source that is external to the first circuit. 
 
     
     
       12. The computer readable medium of  claim 10 , wherein calculating the key derivation function includes:
 generating a random value using a random number generator; and 
 encrypting the synchronized time value and the random value using the different encryption key to generate the first encryption key. 
 
     
     
       13. The computer readable medium of  claim 9 , wherein the operations further comprise:
 communicating, by a first network node coupled to the first circuit, the packet to a second network node coupled to the second circuit; and 
 including, by the first network node, the synchronized time value in the packet as a packet identifier usable by the second circuit to validate the packet. 
 
     
     
       14. A method, comprising:
 maintaining, by a local clock of a first circuit, a local time value; 
 determining, by the first circuit, a synchronized time value by applying a determined offset to the local time value, wherein the synchronized time value is an expected time value of a reference clock, and wherein the offset is determined using previously received synchronization communications; 
 generating, by the first circuit, a first encryption key by calculating a key derivation function based on the synchronized time value; 
 encrypting, by the first circuit, a portion of a packet using the first encryption key, wherein the portion of the packet is to be communicated to a second circuit; and 
 providing, by the first circuit, the synchronized time value used to generate the first encryption key for inclusion in the packet. 
 
     
     
       15. The method of  claim 14 , further comprising:
 communicating, by a first network node coupled to the first circuit, the packet to a second network node coupled to the second circuit; and 
 including, by the first network node, the synchronized time value in the packet as a packet identifier usable by the second circuit to validate the packet. 
 
     
     
       16. The method of  claim 15 , wherein the first network node is an electronic control unit (ECU) configured to control a system of a vehicle. 
     
     
       17. The method of  claim 15 , further comprising:
 generating, by the first circuit, a second encryption key for the first network node by calculating a key derivation function based on the synchronized time value; and 
 providing, by the first circuit, the second encryption key to the first network node, wherein the first network node is configured to encrypt of a payload of the packet using the second encryption key. 
 
     
     
       18. The method of  claim 14 , wherein the reference clock is monotonic. 
     
     
       19. The method of  claim 14 , wherein calculating the key derivation function includes encrypting the synchronized time value using a different encryption key that has a longer validity period than a validity period of the first encryption key. 
     
     
       20. The method of  claim 19 , wherein calculating the key derivation function includes:
 generating a random value using a random number generator; and 
 encrypting the synchronized time value and the random value using the different encryption key to generate the first encryption key.

Description:
BACKGROUND 
     Technical Field 
     This disclosure relates generally to computer networks, and, more specifically, to securely communicating traffic over a network. 
     Description of the Related Art 
     Encryption is frequently used in network communications, such as those over the Internet, to prevent content of intercepted traffic from being viewed. When symmetric encryption is used, two communicating parties establish a shared secret (e.g., a shared key) to facilitate encryption and decryption. In some instances, a shared secret may be established using an out-of-band connection between parties—e.g., one person may hand another a USB key including an encryption key. In other instances, a key exchange algorithm may be performed to establish a shared secrete—e.g., the Diffie-Hellman key exchange perhaps being the most commonly used algorithm. In still other instances, a shared key may be established using asymmetric encryption. Under such a scheme, a first party may derive a key and encrypt it using a public key of a second party, which then decrypts the encrypted key using a corresponding private key. 
     SUMMARY 
     The present disclosure describes embodiments in which network traffic is communicated securely using a cryptographic key derived based on a time value. In some embodiments, an apparatus includes a first circuit having a local clock configured to maintain a local time value. The first circuit determines a synchronized time value based on the local time value, the synchronized time value being an expected time value of a reference clock. The first circuit generates a first encryption key by calculating a key derivation function based on the synchronized time value and encrypts a portion of a packet using the first encryption key. The portion is then communicated to a second circuit. In some embodiments, the apparatus further includes a first network node coupled to the first circuit. The first network node communicates the packet to a second network node coupled to the second circuit and includes the synchronized time value in the packet as a packet identifier usable by the second circuit to validate the packet. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG.  1    is a block diagram illustrating an example of a network that implements secure communications using time-based key derivation. 
         FIG.  2    is a block diagram illustrating an example of a hardware security module configured to perform time synchronization and key derivation. 
         FIG.  3    is a block diagram illustrating an example of a cryptographic accelerator, which may be included in the hardware security module. 
         FIG.  4    is a block diagram illustrating an example of a data frame communicated over the network. 
         FIGS.  5 A- 5 C  are flow diagrams illustrating examples of methods that may be performed by network components to securely communicate using derived keys. 
         FIG.  6    is a block diagram illustrating an exemplary computer system. 
     
    
    
     This disclosure includes references to “one embodiment” or “an embodiment.” The appearances of the phrases “in one embodiment” or “in an embodiment” do not necessarily refer to the same embodiment. Particular features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure. 
     Within this disclosure, different entities (which may variously be referred to as “units,” “circuits,” other components, etc.) may be described or claimed as “configured” to perform one or more tasks or operations. This formulation—[entity] configured to [perform one or more tasks]—is used herein to refer to structure (i.e., something physical, such as an electronic circuit). More specifically, this formulation is used to indicate that this structure is arranged to perform the one or more tasks during operation. A structure can be said to be “configured to” perform some task even if the structure is not currently being operated. A “node configured to communicate traffic over a network” is intended to cover, for example, a device that has circuitry that performs this function during operation, even if the device in question is not currently being used (e.g., a power supply is not connected to it). Thus, an entity described or recited as “configured to” perform some task refers to something physical, such as a device, circuit, memory storing program instructions executable to implement the task, etc. This phrase is not used herein to refer to something intangible. Thus, the “configured to” construct is not used herein to refer to a software entity such as an application programming interface (API). 
     The term “configured to” is not intended to mean “configurable to.” An unprogrammed FPGA, for example, would not be considered to be “configured to” perform some specific function, although it may be “configurable to” perform that function and may be “configured to” perform the function after programming. 
     Reciting in the appended claims that a structure is “configured to” perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112(f) for that claim element. Accordingly, none of the claims in this application as filed are intended to be interpreted as having means-plus-function elements. Should Applicant wish to invoke Section 112(f) during prosecution, it will recite claim elements using the “means for” [performing a function] construct. 
     As used herein, the terms “first,” “second,” etc. are used as labels for nouns that they precede, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless specifically stated. For example, an exchange between a first circuit and a second circuit may include the communication of multiple messages. The terms “first” and “second” can be used to refer to any two of messages in the exchange. In other words, the “first” and “second” messages are not limited to the initial two messages in the exchange, for example. 
     As used herein, the term “based on” is used to describe one or more factors that affect a determination. This term does not foreclose the possibility that additional factors may affect a determination. That is, a determination may be solely based on specified factors or based on the specified factors as well as other, unspecified factors. Consider the phrase “determine A based on B.” This phrase specifies that B is a factor is used to determine A or that affects the determination of A. This phrase does not foreclose that the determination of A may also be based on some other factor, such as C. This phrase is also intended to cover an embodiment in which A is determined based solely on B. As used herein, the phrase “based on” is thus synonymous with the phrase “based at least in part on.” 
     As used herein, the term “synchronize” refers to calculating, for a first clock, an adjustment to be made to the first clock to determine the value of a second clock. While this term encompasses adjusting the value in the first clock to have the same time as the second clock, this term, for the sake of this disclosure, also encompasses not adjusting the value in the first clock. For example, “synchronizing” a first clock with a second clock may include calculating an adjustment for the first clock and applying the adjustment to a time value output by the first clock in order to determine a time value of the second clock. This determined time value may be referred to herein as a “synchronized time value.” 
     DETAILED DESCRIPTION 
     When communicating traffic between two parties, it is important to periodically generate new encryption keys as a precaution against a given one of the encryption keys becoming compromised. In many instances, a pseudorandom number generator may be used to supply entropy for generating new encryption keys. A downside of using this approach, however, is that a pseudorandom number generator can potentially produce the same entropy once in a while, which may result in a previously generated encryption key being regenerated and used again. If this previous key was ever compromised, any subsequent traffic encrypted using the regenerated key is susceptible to decryption with the compromised key. 
     The present disclosure describes various techniques for reducing the possibility of regenerating a previously used encryption key. As will be described below, in various embodiments, a network node communicating encrypted traffic may include (or be associated with) a clock configured to maintain a time value used to derive encryption keys. (As used herein, the terms “encrypt” and “encryption” refer broadly to the performance of a cryptographic operation, which can include encryption as well as decryption, keyed-hash generation and verification, digital signature generation and verification, etc.) In some embodiments, this clock is substantially monotonic. (As used herein, the term “sustainably monotonic” refers to a clock that does not roll over for the lifetime of the device including the clock—i.e., the value maintained by the clock increases (or decreases) for the lifetime of the device without repeating.) As a result, keys may be derived using a non-reoccurring seed, and thus, are not inadvertently regenerated. In various embodiments, time is also synchronized across network nodes communicating encrypted traffic. In doing so, one network node may be prevented from inadvertently deriving and using a key that was previously used by another node in the network. That is, if the clock of a first node were lagging behind a second node&#39;s clock, for example, the first node might use the same time value previously used by the second node to generate a key. This potential issue, however, is mitigated when time is synchronized between the two nodes. Still further, in some embodiments, synchronized time may also be used to coordinate when nodes roll over keys (i.e., generate a new key and discontinue use of an old key) and to validate encrypted traffic. 
     In some embodiments, encryption keys are generated by secure circuits coupled to network nodes communicating the encrypted traffic (as opposed to the nodes themselves handling key generation). As used herein, the term “secure circuit” refers to a circuit that protects an isolated, internal resource from being directly accessed by an external entity. As will be described below, in various embodiments, a secure circuit may maintain a local clock for a network node and keys used to encrypt and decrypt network traffic. The secure circuit may also perform some (or all) of the encryption and decryption for a node. In some instances, using secure circuits to process messages (as opposed to the nodes) may provide additional security to the network. 
     Turning now to  FIG.  1   , a block diagram of a secure network  100  that uses time-based encryption keys is depicted. In the illustrated embodiment, network  100  includes a switch  110  coupled to multiple nodes  120 A-C via links  112 . Nodes  120 A-C, in turn, are coupled via links  114  to respective hardware security modules (HSMs)  130 A-C, which include local clocks  132 A-C. As shown, switch  110  is coupled to HSM  140 , which includes a reference clock  142 . Switch  110  is also coupled to a gateway  150 , which may be coupled to an external network. In various embodiments, network  100  may be implemented differently than shown. Accordingly, in some embodiments, more (or less) switches  110  and/or nodes  120  may be present. In some embodiments, HSM  140  may be coupled to a node  120  (as opposed to a switch  110 ). In some embodiments, functionality described herein with respect to HSMs  130  may be implemented by circuitry in nodes  120 . 
     Network  100 , in some embodiments, is a local area network (LAN) configured to communicate network traffic  122  among nodes  120 . In various embodiments, network traffic is routed among nodes  120  by switches  110 . Accordingly, switches  110  may be configured to queue received messages (i.e., data frames/packets) from nodes  120  and analyze the source and destination addresses specified by the frames in order to appropriately send the messages on to their specified destinations. In some embodiments, switches  110  are configured to route data frames in accordance with IEEE 802.3 (i.e., Ethernet Frames); however, in other embodiments, other networking protocols may be supported. In the illustrated embodiment, network  100  is coupled to an external network (e.g., the Internet) via a gateway device  150 . In some embodiments, gateway  150  is configured to implement a firewall and perform network address translation (NAT) for network  100 . 
     Nodes  120  may correspond to any suitable devices configured to communicate traffic  122 , which may be encrypted in order to provide data integrity, data origin authentication, and/or confidentiality. In some embodiments, nodes  120  may be devices within a home or office network such as desktop and laptop computers, mobile devices, smart television, smart appliances, etc. In some embodiments, nodes  120  are machines within a fabrication plant that are configured to perform various operations. In some embodiments, nodes  120  are electronic control units (ECUs) in a vehicle such as an aircraft, boat, automobile, recreational vehicle, etc. As used herein, the term “electronic control unit (ECU)” is to be interpreted according to its understood meaning in the art, and includes an embedded system (e.g., microcontroller) that controls one or more systems of a vehicle. As used herein, the term “vehicle network” refers to an internal communications network that interconnects components (e.g., ECUs) inside a vehicle. In some embodiments, nodes  120  may include, for example, a motor ECU that communicates torque-control messages and wheel-speed messages in order to control operation of a motor, a brake-system ECU that communicates brake control messages in order to apply braking, a LIDAR ECU that processes data received from one or more LIDAR sensors, a flight yoke ECU that communicates angles of the yoke controls, etc. 
     Hardware security modules (HSMs)  130 , in one embodiment, are secure circuits configured to generate encryption keys used to encrypt traffic  122  being communicated between nodes  120 . In some embodiments, HSMs  130  generate node keys  134  for their respective nodes  120 , which are configured to use the keys  134  perform encryption and decryption of network traffic  122 . In some embodiments, HSMs  130  are configured to generate HSM keys  136  and use the keys  136  to encrypt and decrypt network traffic  122  for nodes  120 . In the illustrated embodiment, however, HSMs  130  are configured to generate both node keys  134  used by nodes  120  to encrypt a portion of a packet and HSM keys  136  used by HSMs  130  to encrypt another portion of the packet. (As used herein, the term “portion” may refer to less than an entirety or an entirety of something.) In various embodiments, keys  134  and  136  are generated on a per-node basis. For example, if node  120 A is supposed to communicate traffic  122  to nodes  120 B and node  120 C, HSM  130 A may generate a first set of keys  134  and  136  for communicating with node  120 B and a second set of keys  134  and  136  for communicating with node  120 C. In some embodiments, keys  134  and  136  may be applicable to only one direction of traffic flow. For example, node  120 A may generate a first set of keys  134  and  136  for encrypting traffic  122  to node  120 B and a second set of keys  134  and  136  for decrypting traffic  122  received from node  120 B. In various embodiments, keys  134  and  136  are generated anew for each new network session. For example, if nodes  120 A and  120 B establish a network session every 100 ms for communicating traffic  122 , HSMs  130 A and  130 B may generate new keys  134  and  136  every 100 ms. Still further, in some embodiments, HSMs  130  are configured to roll over keys  134  and  136  periodically, which may occur during a given network session. For example, HSMs  130  may roll over keys  134  and  136  every four seconds. If a network session is ongoing, HSMs  130  and nodes  120  may transition from using one set of keys  134  and  136  to another, new set of keys  134  and  136 . 
     As will be described below, in various embodiments, HSMs  130  are configured to generate keys  134  and  136  based on time values maintained by local clocks  132 , which are synchronized with a reference clock  142 . In some embodiments, HSMs  130  may also use local clocks  132  for other purposes such as provide timing information to nodes  120 , which may use the timing information to coordinate various operation such as coordinating communication of traffic  122  over network  100 . 
     HSM  140 , in one embodiment, is a secure circuit configured to isolate reference clock  142 , which is configured to maintain a reference time for network  100 —i.e., the time to which local clocks  132  are synchronized. In the illustrated embodiment, local clocks  132  synchronize with reference clock  142  via sync communications  144 . In various embodiments, sync communications  144  include sync messages that periodically sent by HSM  140  to announce the current value of reference clock  142 . HSMs  130  may use this information to determine offsets between their respective clocks  132  and clock  142 . Such an offset may account for a difference between the value of a local clock  132  and the announced value of reference clock  142  as well as any difference in frequency that may exists between a clock  132  and a clock  142 . Sync messages may be sent on a periodic basis (e.g., eight times a second) as the individual frequencies of clocks  132  and  142  may fluctuate with temperature changes over time. In various embodiments, sync communications  144  also include performance of a propagation delay exchange in order for a given HSM  130  to determine the propagation delay between it and HSM  140 , and thus, adjust the announced time in a received sync message to account for this propagation delay. Accordingly, once a given HSM  130  has calculated the offset between its local clock  132  and reference clock  142 , the HSM  130  may determine a synchronized time value (i.e., the expected current value of reference clock  142 ) by applying the offset to the current value of its local clock  132 . This value may be described an “expected” value because the actual offset could change after it has been calculated. In some embodiments, sync communication  144  may be performed in accordance with a protocol such as IEEE 802.1AS, the Network Time Protocol (NTP), etc. 
     In various embodiments, a given HSM  130  is configured to generate keys  134  and  136  by calculating a key derivation function based on a synchronized time value determined from a sync communication  144 . As noted above, in some embodiments, reference clock  142  and local clocks  132  are substantially monotonic—e.g., in one embodiment, clocks  132  and  142  are 64-bit clocks that do not rollover for several hundred years. As such, synchronized time may be used as a reliable source for non-reoccurring entropy in order to prevent regenerating previously used keys. Since time is predictable, however, one or more additional factors are used in a calculating the key derivation function such as a salt provided by a random number generator and a provisioned key  152  stored at the HSM  130 . (As used herein, the term “salt” refers to a value (e.g., random data) that is combined with other factors to increase entropy for a cryptographic operation such as deriving keys. As used herein, the term “random data” refers to data generated by a pseudo random data generator (e.g., a Yarrow generator, Blum Blum Shub generator, etc.) 
     or data generated by a true random number generator (TRNG) (e.g., hardware that analyzes quantum phenomena.) In some embodiments, calculation of the key derivation function may include using the provisioned key  152  to perform an encryption operation on a current synchronized time value and a salt in order to produce a node key  134  or an HSM key  136  as will be described in greater detail below with respect to  FIG.  3   . 
     In various embodiments, gateway  150  is configured to provision HSMs  130  with the keys  152  used to generate keys  134  and  136 . In such an embodiment, gateway  150  may receive keys  152  over a wide area network (e.g., the Internet) from a source external to network  100 , and distribute these keys  152  to the appropriate HSMs  130 . In some embodiments, keys  134  and  136  are ephemeral keys (i.e., have a short life span); however, provisioned keys  152  may have a longer life span. As with keys  134  and  136 , provisioned keys  152  may be specific to particular source and destination nodes  120 —e.g., a provisioned key  152  specifically for traffic communicated from node  120 A to node  120 C. Provisioned keys  152  may also be applicable to a specific direction of traffic. Thus, keys  134  and  136  derived from a given provision key  152  may inherit the properties from that provisioned key—e.g., a provisioned key  152  applicable to traffic being communicated from node  120 A to  120 C cannot be used to derive keys  134  and  136  for communications between  120 A to  120 B. Still further, gateway  150  may provision a given HSM  130  with only the keys  152  that it needs to communicate—e.g., node  120 A may not be provisioned with a key  152  for communicating with node  120 C if node  120 A is not intended to communicate with node  120 C. In some embodiments in which an HSM  130  is deriving a node key  134  and a corresponding HSM key  136 , the HSM  130  may be provisioned with two keys  152 —i.e., one for the node key  134  and another for the HSM key  136 . 
     In various embodiments, when keys  134  and  136  are used to encrypt a packet being communicated from one node to another node, an HSM  130  may provide information that is included in the packet in order for a recipient node  120 &#39;s HSM  130  to determine which keys  134  and  136  are to be used for decryption. As will be described in greater detail below with respect to  FIG.  4   , in some embodiments, this provided information may include a key identifier, which may correspond to a salt used to derive the keys  134  and  136 . This information may also include the synchronized time value used to derive the keys  134  and  136 . Accordingly, when a recipient node  120  receives an encrypted packet, the node  120  may provide this information to its HSM  130 , which, in some embodiments, uses this information along with a provisioned key  152  to derive the keys  134  and  136  used to decrypt the packet. In some embodiments discussed with  FIG.  4   , the synchronized time value may be included as a packet identifier, which is additionally used to validate the packet. 
     In various embodiments, HSMs  130  are configured to periodically roll over keys  134  and  136  in order to account for a key  134  or  136  becoming compromised. In some embodiments, HSMs  130  coordinate key rollover based on the synchronized time among local clocks  132 . In doing so, HSMs  130  may provide rollback protection such that a given node  120  or HSM  130  is not attempting to use keys  134  or  136  after they have expired. Still further, in some embodiments, HSMs  130  may be configured to generate a set of new keys  134  and  136  in anticipation of a rollover (i.e., prior discontinuing use of the older set of keys  134  and  136 ), so that transition to using the new set can occur more seamlessly. As will be described below with  FIG.  4   , a network session may rely on the same salt for the entire session. Thus, if any rollover occurs during the session, the new keys can be derived using the previously established salt and the value of synchronized time when the rollover is to occur. 
     Turning now to  FIG.  2   , a block diagram of an HSM  130  is depicted. As noted above, in some embodiments, HSMs  130  may be used for key generation and maintaining local time because HSMs  130  may be more secure for the reasons discussed below. In the illustrated embodiment, HSM  130  includes a network interface  210 , one or more processors  220 , a read only memory (ROM)  230 , a cryptographic accelerator  240 , a key storage  250 , and local clock  132  coupled together via an interconnect  260 . ROM  230  also includes firmware  232 . Key storage  250  also includes one or more HSM keys  136  and provisioned keys  152 . In some embodiments, HSM  130  may include more (or less) components than shown. (In some embodiments, HSM  140  may implement functionality described herein with respect to HSM  130 .) 
     Network interface  210 , in one embodiment, is configured to facilitate communication with a node  120 . Accordingly, interface  210  may encode and decode data across a link  114 , which, in some embodiments, is a serial peripheral interface (SPI) bus. In various embodiments, interface  210  is also configured to isolate internal components  132  and  220 - 250  from an external entity such as node  120 , by filtering incoming read and write operations. In some embodiments, HSM  130  presents a limited attack surface by supporting only a small number of commands. For example, in one embodiment, HSM  130  supports a command allowing node  120  to request creation of keys  134  and  136 , request encryption and decryption using an HSM key  136 , and request the current time. If interface  210  receives data from a node  120  that is not a supported command, interface  210  may prevent the data from entering HSM  130 . In doing so, HSM  130  prevents, for example, node  120  from being able to access local clock  132  directly. 
     Processor  220 , in one embodiment, is configured to execute program instructions to implement various operations described herein with respect to HSM  130 . In some embodiments, processor  220  is hardwired to fetch from a specific address range at boot in order to boot firmware  232  from ROM  230 . Notably, because memory  230  is a ROM (as opposed to some other type of memory that can easily be written to), firmware  232  is resistant to modification, and thus, being tampered with. As a result, HSM  130  can be restored to a default, trusted state by merely causing processor  220  to reboot, which, in the illustrated embodiment, can be initiated by asserting reset signal  202 . Thus, processor  220  may further serve to isolate components in HSM  130 . 
     Cryptographic accelerator  240 , in one embodiment, is circuitry configured to perform cryptographic operations for HSM  130  including key derivation. Cryptographic accelerator  240  may implement any suitable encryption algorithm such as Data Encryption Standard (DES), Advanced Encryption Standard (AES), Rivest Shamir Adleman (RSA), HMAC, etc. In the illustrated embodiment, accelerator  240  is configured to use keys stored in key storage  250 , which accelerator  240  may isolate from being accessed by other components of HSM  130 . That is, in some embodiments, accelerator  240  may allow a provisioned key  152  to be updated by processor  220 , but not allow the key  152  to be read from storage  250  by processor  220 . 
     Turning now to  FIG.  3   , a block diagram of cryptographic accelerator  240  is depicted. As noted above, in some embodiments, keys  134  and  136  may be determined using a key derivation function that is calculated by performing encryption. Accordingly, in the illustrated embodiment, accelerator  240  includes an advanced encryption standard (AES) engine  310 , mask  320 , and random number generator (RNG)  330  for determining keys  134  and  136 . In some embodiments, accelerator  240  may include more (or less) components than shown. 
     AES engine  310 , in one embodiment, is circuitry configured to perform AES encryption and decryption operations. In the illustrated embodiment, AES engine  310  is configured to derive a node key  134  or an HSM key  136  by using a provisioned key  152  to encrypt a portion of a synchronized time value  312  and a salt  314 , which may be concatenated together prior to encryption. In some embodiments, engine  310  may specifically perform 128-bit encryption using AES in Galois/Counter Mode (AES-GCM) and/or electronic codebook (ECB) mode. In other embodiments, cryptographic algorithms other than AES may be used such as those noted above; still further other forms of key derivation functions may be employed. In some embodiments, additional factors may be included such as additional padding to increase the number characters encrypted by engine  310 . 
     As shown in  FIG.  3   , engine  310  may receive synchronized time value  312  from a local clock  132  or from encrypted traffic  122 . Reception from local clock  132  may occur when the node  120  coupled to the HSM  130  is the sender of encrypted traffic  122 . In such an event, synchronized time value  312  may be determined as discussed above based on the current value of local clock  132  adjusted to account for an offset determined based on sync communications  144 . Reception from encrypted traffic  122  may occur when the node  120  coupled to the HSM  130  is the recipient of traffic  122 . In such an event, node  120  may extract a synchronized time value  312  from the encrypted traffic  122  (e.g., from a packet identifier field in a packet as discussed below) and provide this value to HSM  130  for deriving keys  134  and  136  used to decrypt the received encrypted traffic  122 . 
     Mask  320 , in one embodiment, is circuitry configured to provide only a subset of the bits specifying the current synchronized time value  312 . Accordingly, in some embodiments, mask  320  is circuitry configured to read a portion of the register storing synchronized time value  312 . For example, the register may support reading half of its contents corresponding to the higher-order bits. In other embodiments, mask  320  may include OR gates configured to replace a portion of bits with a default value (e.g., all ones) and leave the portion provide to engine  310  intact. In some embodiments, mask  320  may be implemented by program instructions executable by processor  220 . 
     In some embodiments, HSM  130  may determine when to roll over keys  134  and  136  based on whether any bits in the provided portion of time value  312  have changed. For example, synchronized time value  312  may be represented using 64 bits, where mask  320  removes the lower-order 32 bits of value  312  and provides the higher-order 32 bits of value  312  to engine  310 . In this example, synchronized time value  312  may be incremented every nanosecond; however, the higher-order 32 bits may only change once every four second. Accordingly, HSM  130  may determine to roll over keys  134  and  136  every four seconds in response to any of the higher-order 32 bits changing. 
     RNG  330 , in one embodiments, is circuitry configured to generate a salt  314  by using a random number generator (RNG) algorithm. RNG  330  may use any suitable algorithm such as Yarrow, a linear congruential generator (LCG), etc. In some embodiments, these algorithms may also use a synchronized time value  312  as an input. As will discussed with  FIG.  4   , a salt  314  may be included in a packet as a key identifier usable by a recipient to derive a decryption key. 
     Turning now to  FIG.  4   , a block diagram of a packet  400  included in encrypted traffic  122  is depicted. As noted above, in various embodiments, encrypted traffic  122  may include packets having portions encrypted by node  120  and by HSM  130  as well as information usable by a recipient to determine appropriate decryption keys  134  and  136 . In the illustrated embodiment, encrypted traffic  122  includes a packet  400  having fields for a header  410 , packet identifier  420 , key number  430 , payload  440 , and a message authentication code (MAC)  450 . In some embodiments, more (or less) fields may be included in packet  400 . For example, in one embodiment, each of the depicted fields may be included if packet  400  is an initial packet in a given network session; however, subsequent packets  400  may omit, for example, key number  430 . 
     Header  410  includes information usable to route packet  400  through network  100  such as a sender&#39;s network address and a recipient&#39;s network address. In various embodiments, this information may be used to determine which keys  134  and  136  to use for encryption and decryption for a given packet  400 . This information may also be used to determine which provisioned keys  152  to be use for deriving keys  134  and  136 . In some embodiments, header  410  may include one or more of fields  420 ,  430 , or  450 . 
     Packet identifier  420  is a value that is uniquely assigned to a given packet and may be used to determine an ordering in which packets are transmitted within a given session of network traffic  122 . As shown, in various embodiments, a synchronized time value  312  may be used as the packet identifier  420 —i.e., the current value of synchronized time at transmission may be inserted into packet  400  as packet identifier  420 . In doing so, a packet identifier  420  may be used by the HSM  130  coupled to a receiving node  120  to derive the keys  134  and  136  for decrypting payload  440  and MAC  450  discussed below. Still further, in some embodiments, packet identifiers  420  may be used by an HSM  130  to validate received encrypted traffic  122 . First, in such an embodiment, an HSM  130  may perform a timeliness check in which the HSM  130  compares the packet identifier  420  of a given packet with the current value of synchronized time in order to ensure that the difference does not exceed a threshold amount (e.g., because the packet identifier  420  is old, pertains to a time too far into the future, or is received out of sequence). If the difference does exceed this threshold, the HSM  130  may consider the packet  400  to be invalid. Second, an HSM  130  may compare a packet identifier  420  of a given packet with identifiers  420  of other packets  400  in a given network session. If the identifier  420  of the given packet  400  indicates that the packet  400  is received out of order (or, at least, has a value that significantly differs from the other packets in that session), the HSM  130  may consider the packet  400  to be invalid. 
     Key number  430  is a value that identifies the keys  134  and  136  used to encrypt a packet  400 , and thus, usable to decrypt a packet. As shown, in various embodiments, key number  430  is the salt  314  used to derive keys  134  and  136 . In some embodiments, a key number  430  is valid for an entire network session and does not change for the session even if a key rollover is performed during the session. In doing so, an HSM  130  may predetermine keys  134  and  136  prior to a rollover. That is, in some embodiments, once an HSM  130  is aware of the key number  430  (either because it determined the number or it received the number in an earlier packet  400 ), the HSM  130  can predict what the subsequent synchronized time value  312  will be at rollover and derive the corresponding keys  134  and  136  based on the key number  430  and predicted time value  312 . This predicted time value  312  may be determined from an earlier packet  400  or based on an HSM  130 &#39;s local clock  132 . 
     Payload  440  includes the encrypted content being transported by packet  400 . In the illustrated embodiment, payload  440  is the portion of packet  400  that is encrypted by a node  120  using a node key  134 . In other embodiments, payload  440  may be encrypted by an HSM  130  using an HSM key  136  (or by circuitry other than nodes  120  and HSMs  130  in some embodiments). 
     MAC  450  is a message authentication code usable by an HSM  130  (or node  120 ) to verify the integrity of packet  400 . In the illustrated embodiment, MAC  450  is encrypted by an HSM  130  of the sending node  120  using an HSM key  136  and later decrypted and verified by an HSM  130  of the receiving node  120 . In some embodiments, MAC  450  is produced by a node  120  when performing an AES-GCM encryption using a node key  134 ; the node  120  then provides this MAC  450  to its HSM  130  for encryption using an HSM key  136 . (In other embodiments, MAC  450  may be encrypted by a node  120  using a node key  134  or by circuitry other than nodes  120  and HSMs  130 . In some embodiments, HSMs  130  may encrypt portions other than MAC  450 ; MAC  450  may also not be encrypted.) 
     Turning now to  FIG.  5 A , a flow diagram of a method  500  is depicted. Method  500  is one example of a method for encrypting packet data using an encryption key derived based on time such as keys  134  and  136  discussed above. In various embodiments, method  500  is performed by a circuit having a local clock such as an HSM  130  having a local clock  132 . In various embodiments, performance of method  500  prevents inadvertent reuse of previously derived keys. 
     In step  505 , the circuit (e.g., HSM  130 A) determines a synchronized time value (e.g., time value  312 ) based on the local time value (e.g., as maintained by a local clock  132 ) such that the synchronized time value is an expected time value of a reference clock (e.g., reference clock  142 ). In various embodiments, step  505  may include determining an offset based on a time difference and/or a frequency difference between the local clock and the reference clock, and applying the offset to the local time value. In some embodiments, step  505  may include using an algorithm such as IEEE 802.1AS, NTP, etc. 
     In step  510 , the circuit generates a first encryption key (e.g., an HSM key  136 ) by calculating a key derivation function based on the synchronized time value. In various embodiments, calculating the key derivation function includes encrypting the synchronized time value using another encryption key (e.g., a provisioned key  152 ) that has a longer validity period than a validity period of the first encryption key. In some embodiments, the first circuit receives the other encryption key (e.g., via gateway  150 ) from a source that is external to the first circuit. In some embodiments, calculating the key derivation function includes generating a random value (e.g., salt  314 ) using a random number generator (e.g., RNG  330 ), and encrypting the synchronized time value and the random value using the other encryption key to generate the first encryption key. In some embodiments, step  510  further includes generating a second encryption key (e.g., a node key  134 ) for a first network node (e.g., node  120 A) coupled to the circuit by calculating a key derivation function based on the synchronized time value, and providing the second encryption key to the first network node. 
     In step  515 , the circuit encrypts a portion (e.g., MAC  450 ) of a packet using the first encryption key, the portion of the packet to be communicated to a second circuit (e.g., HSM  130 B). In various embodiments, the first network node coupled to the first circuit communicates the packet to a second network node (e.g., node  120 B) coupled to the second circuit. In some embodiments, the first node includes the synchronized time value in the packet as a packet identifier (e.g., identifier  420 ) usable by the second circuit to validate the packet. In some embodiments, the first network node encrypts of a payload (e.g., payload  440 ) of the packet using the second encryption key generated in step  510 . 
     In some embodiments, method  500  further includes determining, based on the local clock, that the first encryption key has expired. In response to the first encryption key expiring, the first circuit generates a subsequent encryption key using the other encryption key to encrypt another synchronized time value and the random value, and encrypts a portion of another packet using the subsequent encryption key, the portion of the other packet to be communicated to the second circuit. In various embodiments, method  500  further includes receiving, from a third circuit, an encrypted portion of another packet having a synchronized time value included by the third circuit. In such an embodiment, the first circuit may derive a key based on the included synchronized time value and use the derived key to decrypt the encrypted portion of the other packet. 
     Turning now to  FIG.  5 B , a flow diagram of a method  530  is depicted. Method  530  is another example of a method for encrypting packet data using an encryption key derived based on time such as keys  134  and  136  discussed above. In various embodiments, method  500  is performed by an apparatus having a circuit configured to derive the key, such as an HSM  130 , and a network node configured to perform the encryption, such as a node  120 . 
     Method  530  begins in step  535  with a first circuit (e.g., HSM  130 A) that has a local clock synchronizing the local clock with a reference clock (e.g., reference clock  142 ) external to the first circuit. In step  540 , the first circuit derives a first encryption key (e.g., a node key  134 ) based on the synchronized local clock. In some embodiments, the first circuit receives a second encryption key (e.g., a provisioned key  152 ) via a network interface (e.g., gateway  150 ) configured to communicate over a wide area network, and uses the second encryption key to derive the first encryption key. In step  545 , a first network node encrypts a first packet (e.g., payload  440 ) with the first encryption key derived by the first circuit. In some embodiments, the first network node uses the first encryption key for encrypting packets sent to a second network node, but not for decrypting packets received from the second network node. In some embodiments, the first network node is an electronic control unit (ECU) configured to control operation of a vehicle. In step  550 , the first network node sends the encrypted first packet to a second network node (e.g., node  120 B) associated with a second circuit (e.g., HSM  130 B) having a local clock synchronized with the reference clock. In some embodiments, the first network node includes a time value of the synchronized local clock in the first packet such that the time value is used by the first circuit to generate the first encryption key and is usable by the second circuit to derive the first encryption key. 
     In some embodiments, method  530  may include the first network node sending a plurality of packets of a network session to the second network node, the first packet being one of the plurality of packets. In such an embodiment, the first circuit may determine, during the network session, that the first encryption key has expired, derive a third encryption key based on the second encryption key, and use the third encryption key to encrypt a second packet of the plurality of packets. In some embodiments, method  530  may include the first network node receiving an encrypted second packet from a third network node. In such an embodiment, the first circuit may derive a third encryption key based on a fourth encryption key received via the network interface, and use the third encryption key to decrypt the second encrypted packet. 
     Turning now to  FIG.  5 C , a flow diagram of a method  560  is depicted. Method  560  is one example of a method for decrypting packet data using an encryption key derived based on time such as keys  134  and  136  discussed above. In various embodiments, method  560  is performed by a circuit such as an HSM  130 . In various embodiments, performance of method  500  prevents inadvertent reuse of previously derived keys. 
     Method  560  begins in step  565  with a first circuit (e.g., HSM  130 A) storing a first key (e.g., a provisioned key  152 ) usable to encrypt data. In step  570 , the first circuit receives, from a second circuit (e.g., HSM  130 B), an encrypted portion (e.g., MAC  450 ) of a first packet and a first timestamp (e.g., Packet ID  420 ) included in the first packet. In various embodiments, a first network node (e.g., node  120 A) coupled to the first circuit receives the first packet and requests that the first circuit decrypt the encrypted portion of the first packet. In some embodiments, the first network node is an electronic control unit (ECU) configured to receive the first packet over a vehicle network. In step  575 , the first circuit generates a second key (e.g., HSM key  136 ) based on the first key and a portion of the first timestamp (e.g., after application of mask  320 ). In some embodiments, the first circuit includes a first local clock, and synchronizes the first local clock with a reference clock. In such an embodiment, the second circuit has a second local clock, and synchronizes the second local clock with the reference clock. The second circuit then generates the first timestamp based on the synchronized second clock. In step  580 , the first circuit decrypts the encrypted portion using the second key. In some embodiments, the first circuit may receive an encrypted portion of a second packet and a second timestamp included in the second packet, the first packet and the second packet being communicated within the same network session. In such an embodiment, the first circuit may validate the second packet by comparing the first timestamp with the second timestamp, and based on validation of the second packet, determine whether to decrypt the encrypted portion of the second packet. 
     Exemplary Computer System 
     Turning now to  FIG.  6   , a block diagram of an exemplary computer system  600  is depicted. Computer system  600  is one embodiment of a computer system that may be used to implement one or more components of secure network  100  such as switch  110 , nodes  120  or gateway  150 . In the illustrated embodiment, computer system  600  includes a processor subsystem  620  that is coupled to a system memory  640  and I/O interfaces(s)  660  via an interconnect  680  (e.g., a system bus). I/O interface(s)  660  is coupled to one or more I/O devices  670 . Computer system  600  may be any of various types of devices, including, but not limited to, a server system, personal computer system, network computer, an embedded system, etc. Although a single computer system  600  is shown in  FIG.  6    for convenience, system  600  may also be implemented as two or more computer systems operating together. 
     Processor subsystem  620  may include one or more processors or processing units. In various embodiments of computer system  600 , multiple instances of processor subsystem  620  may be coupled to interconnect  680 . In various embodiments, processor subsystem  620  (or each processor unit within  620 ) may contain a cache or other form of on-board memory. 
     System memory  640  is usable store program instructions executable by processor subsystem  620  to cause system  600  perform various operations described herein. System memory  640  may be implemented using different physical, non-transitory memory media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read only memory (PROM, EEPROM, etc.), and so on. Memory in computer system  600  is not limited to primary storage such as memory  640 . Rather, computer system  600  may also include other forms of storage such as cache memory in processor subsystem  620  and secondary storage on I/O Devices  670  (e.g., a hard drive, storage array, etc.). In some embodiments, these other forms of storage may also store program instructions executable by processor subsystem  620  to perform operations described herein. 
     I/O interfaces  660  may be any of various types of interfaces configured to couple to and communicate with other devices, according to various embodiments. In one embodiment, I/O interface  660  is a bridge chip (e.g., Southbridge) from a front-side to one or more back-side buses. I/O interfaces  660  may be coupled to one or more I/O devices  670  via one or more corresponding buses or other interfaces. Examples of I/O devices  670  include storage devices (hard drive, optical drive, removable flash drive, storage array, SAN, or their associated controller), network interface devices (e.g., to a local or wide-area network), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, computer system  600  is coupled to a network via a network interface device  670  (e.g., configured to communicate over WiFi, Bluetooth, Ethernet, etc.). 
     Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even where only a single embodiment is described with respect to a particular feature. Examples of features provided in the disclosure are intended to be illustrative rather than restrictive unless stated otherwise. The above description is intended to cover such alternatives, modifications, and equivalents as would be apparent to a person skilled in the art having the benefit of this disclosure. 
     The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. Accordingly, new claims may be formulated during prosecution of this application (or an application claiming priority thereto) to any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the appended claims.

Metadata:
Filing Date: 20180430
Publication Date: 20221227
Grant Date: 20221227
Priority Date: 20170517
Inventors: SCHAAP, TRISTAN F.
Assignee: APPLE INC
CPC Classifications: [{"code": "H04L9/0819", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F1/12", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/0872", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04L9/0869", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/0872", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04L9/14", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L2209/84", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F1/12", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/14", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/0869", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/0872", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04L9/0819", "inventive": true, "first": false, "tree": "[]"}]
Family ID: 62218320