Key generation for a cluster of nodes within a single security association

Abstract

Each computing node in a computing cluster includes at least a key generator and a cryptographic engine. The key generator implements a key derivation function and generates a first data encryption key based on the key derivation key. The key derivation key is a global security association encryption key shared by multiple nodes in the computing cluster. The first data encryption key is unique to a node pair, including a first node and a second node among multiple nodes. The cryptographic engine uses the first data encryption key to encrypt data packets.

Description

Background Art

[0001] Data centers and high-performance computers typically include thousands of nodes. Current security mechanisms generally require a unique set of keys for each node pair. In these data centers, each node is similarly required to store a large number of encryption keys and keep the keys readily available (e.g., on-chip storage). Off-chip storage can be used, but the latency in obtaining the correct key for a node pair causes latency delays on the interface, potentially stalling the interface. Due to the latency associated with external storage of keys or large on-chip memories for high-performance operation, one proposed security mechanism is a mechanism that allows multiple nodes (including all nodes) to use the same encryption key for all node communications. However, the use of a single key presents multiple security concerns, including potentially significant violations of data if the key becomes known, loss of the ability to disconnect communications with specific nodes due to the nodes already knowing the key, an increase in side-channel attacks against the key, and the need for high-performance methods to update the key on all nodes.

[0002] This disclosure is better understood by reference to the accompanying drawings, and many of its features and advantages will be apparent to those of ordinary skill in the art. The use of the same reference numerals in different drawings indicates similar or identical items.

Brief Description of the Drawings

[0003] [Figure 1] FIG. 1 is a block diagram of an exemplary cluster computing environment implementing a global security association environment in which each node shares the same global security association key, according to some embodiments. [Figure 2] FIG. 2 is a block diagram of an exemplary node pair in the cluster computing environment of FIG. 1, according to some embodiments. [Figure 3] This figure shows an example of a key generation system for nodes in the node pair shown in Figure 2, according to several embodiments. [Figure 4] Figure 3 shows a key generation system that performs multiple iterations of a pseudo-random function to generate a unique data encryption key for the node pair in Figure 2, according to several embodiments. [Figure 5] Figure 2 illustrates, in several embodiments, an exemplary method for generating a unique data encryption key for the node pair shown in Figure 2, based on a shared global security association key and additional input data. [Figure 6] Figure 2 illustrates, in several embodiments, an exemplary method for generating a unique data encryption key for the node pair shown in Figure 2, based on a shared global security association key and additional input data. [Figure 7] This is a block diagram of a processing device according to several embodiments. [Modes for carrying out the invention]

[0004] Data centers typically use wired connections, such as Ethernet® connections, to communicate between different nodes (also referred to herein as nodes). These connections are made using network interface cards (NICs) and have the ability to provide security between nodes using Transport Security Layer (TLS) encryption on the link. When TLS is established between two nodes, it is known as a security association (SA). This association includes the sending and receiving keys and sequence numbers of the communication packets. If an error occurs, such as a TLS authentication error, the TLS session terminates and a new session is established.

[0005] Current data centers are being created with, for example, more than 32,000 nodes, and this number is expected to continue to increase. With current security mechanisms that implement a different key pair for each node pair, the number of Security Advisors (SAs) becomes very large, and the amount of storage required to maintain these SAs within the nodes becomes very expensive. While SA information, including keys, can be stored in external memory, the time it takes to access SA information from memory slows down the wired communication link. In some configurations, a cache of frequently used SAs is stored internally on the chip, but SAs not found in the cache can slow down the link for a while, which negatively impacts performance.

[0006] Due to the significant increase in the number of nodes, some security mechanisms attempt to reduce the number of keys required for communication between nodes. For example, some security mechanisms allow all nodes operating as a single system (owned by the same guest owner) to share a single key as a global SA (GSA). However, for example, with 32,000 nodes processing data at 800 gigabits per second (Gbps), the counter value of an Advanced Encryption Standard (AES) using Galois / Counter mode (GCM) encryption is typically exhausted every few hours. Furthermore, concerns about side-channel attacks and the amount of data encrypted using a single key become problematic. Key rolling with a shared key among 32,000 nodes is generally not feasible due to the amount of coordination effort required. For example, a large amount of storage is needed for old keys to account for timing discrepancies and delays in distributing new keys among all 32,000 nodes. Furthermore, because all nodes share the same key, a malicious node can generate packets that appear to have been obtained from any other node. Determining which node the data originated from can be difficult or impossible. Therefore, it may be impossible to revoke the key from a bad actor (for example, a node that holds the key and generates packets through impersonation). In addition, a feature of TLS is that any authentication error will terminate the node session. However, if multiple nodes use the same key, removing a single node from the network also becomes extremely difficult or impossible (because all those nodes use the same key).

[0007] Furthermore, as mentioned above, using a single key leads to an increase in side-channel attacks against that key, such as differential power analysis and differential electromagnetic field analysis (collectively referred to as DPA in this specification). DPA attacks use power monitoring (EM) techniques to discover and interpret the encryption key used within the encryption algorithm. These attacks can be applied to both hardware and software versions of the algorithm. DPA attacks monitor power usage and correlate the power used, input / output values ​​from the encryption operation, and inferences in the lower part of the key (e.g., the 8-bit lower part in the case of AES). Mathematical software attempts to determine this correlation using the power values ​​and input / output values. While some algorithms are more difficult to DPA against AES, standard National Institute of Standards and Technology (NIST) algorithms are generally susceptible to DPA attacks. Although AES can implement power masking, the amount of encrypted blocks quickly overwhelms its ability to mask power without frequent key changes.

[0008] The effectiveness of a DPA attack depends on many factors, including the attacker's equipment, their ability to obtain power (EM) traces, and the amount of signal (power associated with the key) versus noise in the system. The lower the signal level compared to the noise, the more samples are needed to boost the signal. Complex AES engines, sometimes without countermeasures, such as pipelining AES or multiple AES cores used to further increase throughput, are likely to have less signal and consequently require more samples to decrypt the encryption key. Due to the ability to carry out DPA attacks, many industries (e.g., government, finance, smart card technology, etc.) require protection against DPA attacks, such as countermeasures, signal reduction or masking, key rolling, or a combination thereof.

[0009] Conventional mechanisms to protect AES engine implementations from DPA attacks include masking operations that attempt to apply a random mask to the input / output data used by the AES engine. This masking typically needs to be added before subblocks of AES operations, and the mask generally needs to be removed after the subblocks. These masking operations increase the size of the AES design (hardware) by adding masking gates in the design and additional logic gates to the timing path. This requires synthesis tools to use physically larger gates to achieve the same clock speed as an unmasked design. Thus, some AES cores resistant to side-channel attacks may be 3-4 times the size of an "unprotected" AES core. The effectiveness of countermeasures is typically unknown until measurements are performed. Furthermore, knowing the effectiveness of countermeasures such as masking gates can be difficult until an experienced test team can test and measure such countermeasures on actual hardware. Pre-tape-out power analysis is useful, but real-world data is required to reconcile pre-tape-out power analysis across multiple iterations. Furthermore, while there are available AES mask cores that can mask a large number of samples, the keys still need to be updated multiple times per second to ensure security, which is not feasible in a global SA environment.

[0010] Another way to prevent DPA attacks against encryption keys is to change them frequently enough that an attacker cannot obtain enough samples to crack them. This behavior is known as key rolling. The frequency of key rolling depends on either time or data. In time-dependent key rolling schedules, the time should be chosen based on the number of encryption operations that can be performed in a given time (this can also be a way to determine data dependency). The mechanism used to change the key also minimizes the time required to update the key. In other words, the delay associated with the mechanism used to make the key roll presents a floor function for the rate at which the key can be rolled. Key rolling is a strong countermeasure for applications where the key is not needed for a long period of time (for example, the key used for encryption generally only needs to be stored until the data is decrypted). Examples of these applications include link-based encryption, including TLS for Ethernet® security. In link encryption, data is encrypted by the sender, then sent to the receiver, and then decrypted by the receiver. Once the data is decrypted, the key can be changed.

[0011] Accordingly, this disclosure describes embodiments of systems and methods for generating keys for a cluster of nodes in a global (single) security association environment, while effectively addressing at least the security concerns described above, while minimizing the amount of storage per node pair. In at least some embodiments, each node in the node cluster implements a shared (i.e., the same) data encryption key (also referred to herein as a global SA key). Each node uses the shared global SA key as a key derivation key (KDK), thereby configuring each node to have the same KDK. A pair of nodes uses the KDK, along with other information such as a source node identifier (ID) and destination node ID, as a shared secret, etc., to generate / derive one or more data encryption keys unique to the pair of nodes. In other words, nodes in a node pair can generate unique keys for sending and receiving data based on the shared data encryption key. Thus, the techniques described herein enable nodes in a global SA configuration to save individual device storage space without being affected by the harmful security impact of all nodes using the same encryption key for data encryption operations. Furthermore, the described technology enables node pairs to automatically roll their keys, prevent DPA attacks, implement masking functions to prevent spoofing attacks even though all nodes use the same KDK, and eliminate the need for dedicated software and synchronization operations.

[0012] Figure 1 shows an example of a computing environment 100 that can implement the security mechanisms described herein for generating unique data encryption keys for a cluster of nodes within a single security association. In the example shown in Figure 1, the computing environment 100 includes a cluster 102 of computing nodes 104 (referred to as nodes 104-1 to 104-9). Each node 104 in the cluster 102 can establish a communication link 106 (referred to as communication links 106-1 to 106-5) with one or more other nodes 104 in the cluster 102 (also referred to herein as node cluster 102). The communication links 106 established between node pairs are protected using one or more security mechanisms that encrypt data bidirectionally between the nodes 104 of the node pair. For example, the Internet Protocol security (IPsec) protocol can be implemented to protect data packet communication between two nodes 104, such as node A1 104-1 and node B1 104-4. However, before data can be securely transferred between nodes 104 using the IPsec framework, a security association (SA) typically needs to be established between the nodes 104.

[0013] In at least some embodiments, an SA defines a mutually agreed key, one or more security protocols, and security parameters such as a security parameter index (SPI). In at least some configurations, the SA defines security parameters for a one-way connection. In these configurations, separate SAs are typically configured for each direction, i.e., for sending data and receiving data. However, in cluster computing environments implementing conventional IPsec SA configurations, the number of SAs maintained by a single node is very large, and the amount of storage required to maintain these SAs is very expensive. Therefore, the computing environment 100 in Figure 1 implements a global SA (GSA) configuration in which each of the nodes 104 shares a single key as a global SA (GSA). For example, Figure 1 shows that each of the nodes 104 in cluster 102 shares the same data encryption key 108 (shown as GSA keys 108-1 to 108-9) in a GSA configuration. In at least some embodiments, a single data encryption key is used for encryption and decryption, one key is used for encryption and another for decryption, or multiple keys are used for encryption and decryption. In at least some embodiments, the GSA key 108 is an encryption key generated by a server (or other entity) and distributed to each of the nodes 104 in the cluster 102. However, other mechanisms for generating and distributing the GSA key 108 are also applicable.

[0014] Implementing a shared GSA key 108 across all nodes 104 in cluster 102 reduces the number of SAs stored on node 104, thereby saving storage space. However, as described above, implementing a single shared GSA key 108 across all nodes 104 presents several security concerns, such as node removal from the GSA, error handling, key rolling, and the amount of data encrypted with a single key. Therefore, in at least some embodiments, nodes 104 in cluster 102 are configured to use the shared GSA key 108 as a Key Derivation Key (KDK) so that node 104 can derive a specific data encryption key between pairs of nodes 104. In addition, as described below, each node 104 implements a fast key derivation function with additional inputs so that pairs of nodes have individual encryption keys (per direction) and can individually roll the KDK to prevent side-channel analysis attacks. Therefore, the techniques described herein address security concerns associated with using shared GSA keys in a node cluster, and enable a reduction in the number of SAs stored by the nodes and the total amount of storage required to provide a single security association per pair of nodes. The techniques described herein further provide a method for rapidly rolling keys to prevent DPA attacks and to eliminate, or at least reduce, slow dedicated software operations and synchronous operations that adversely impact bandwidth and latency.

[0015] Figure 2 shows an example of a node pair 200 from cluster 102 in Figure 1. In this example, each node 104 of the node pair 200 implements the techniques described herein for generating individual keys in a global (single) security association. Although Figure 2 shows only one node pair 200, it should be understood that the following description is applicable to any number of node pairs in cluster 102. In the example shown in Figure 2, the node pair 200 includes a first node 104-1 and a second node 104-4. A communication link 106-1 is established between these nodes 104. The first node 104-1 and the second node 104-4 correspond to devices configured to interface with each other, for example, using the communication link 106-1. Examples of these devices include entire computing systems or components of computing systems such as device processors (e.g., graphics processing units and central processing units), disk array controllers, hard disk drive host adapters, memory cards, solid-state drives, wireless communication hardware connections, Ethernet® hardware connections, switches, bridges, and network interface controllers.

[0016] The first node 104-1 and the second node 104-4 communicate via communication link 106-1. In at least some embodiments, communication link 106-1 is a bidirectional communication link such that the first node 104-1 transmits data received by the second node 104-4 via communication link 106-1, and the second node 104-4 transmits data received by the first node 104-1 via communication link 106. Alternatively, communication link 106 facilitates unidirectional data transmission, for example, transmission of data by the first node 104-1 via communication link 106 for reception by the second node 104-4, or transmission of data by the second node 104-4 via communication link 106 for reception by the first node 104-1. In some variations of communication link 106 that facilitate unidirectional data transmission, the node pair 200 further includes one or more additional communication links (not shown) between the first node 104-1 and the second node 104-4. In at least one scenario in which communication link 106 facilitates the transmission of data from the first node 104-1 for reception by the second node 104-4, for example, the additional communication links facilitate the transmission of data from the second node 104-4 for reception by the first node 104-1. Alternatively or in addition, communication link 106-1 facilitates unidirectional data transmission of subsets (e.g., only one) of multiple different types of data packets, such as the transmission of a first type of data by the first node 104-1 via communication link 106 for reception by the second node 104-4, the transmission of a second type of data by the first node 104-1 via communication link 106 for reception by the second node 104-4, the transmission of a third type of data by the first node 104-1 via communication link 106 for reception by the second node 104-4, and so on.

[0017] In at least some embodiments, the first node 104-1 and the second node 104-4 include an encryption engine 202 (indicated as encryption engine 202-1 and encryption engine 202-2). Generally, the encryption engine 202 uses one or more keys to encrypt and decrypt data for communication over the communication link 106-1. In at least some embodiments, the encryption engine 202 authenticates encrypted data and checks the authentication of decrypted data. In at least some embodiments, the encryption engine 202 is configured according to an advanced encryption standard (AES) for encryption and decryption operations, or otherwise includes one or more components that utilize an advanced encryption standard.

[0018] In a scenario where the first node 104-1 corresponds to a transmitting device and the second node 104-4 corresponds to a receiving device, the first node 104-1 receives data 204 for communication to the second node 104-4. The encryption engine 202-1 in the first node 104-1 encrypts and authenticates the data 204. The first node 104-1 (for example, the transmitter of the first node 104-1) transmits an encrypted data packet 206 formed based on the encrypted and authenticated data 204 output by the encryption engine 202-1. The second node 104-4 receives the encrypted data packet 206. The encryption engine 202-2 in the second node 104-4 decrypts the encrypted data packet 206 and checks authentication to form decrypted data 208.

[0019] In a scenario where the second node 104-4 corresponds to the transmitting device and the first node 104-1 corresponds to the receiving device, the data flows in the opposite direction to the scenario described above. For example, the second node 104-4 receives data 204, the encryption engine 202-2 in the second node 104-4 encrypts and authenticates data 204, the second node 104-4 transmits the encrypted data packet 206 to the first node 104-1 via communication link 106-1, the encryption engine 202-1 in the first node 104-1 decrypts the encrypted data packet 206 to check authentication, and outputs the decrypted data 208.

[0020] As noted above, the encryption engine 202 uses one or more data encryption keys to encrypt and decrypt data. The encryption engine 202-1 in the first node 104-1 and the encryption engine 202-2 in the second node 104-4 use matching data encryption keys to encrypt and decrypt data communicated over the communication link 106-1. For example, the key used by the encryption engine 202-1 in the first node 104-1 to encrypt data 204 for communication over the communication link 106-1 and form an encrypted data packet 206 is the same key used by the encryption engine 202-2 in the second node 104-4 to decrypt the encrypted data packet 206. However, as mentioned above, the key shared by the first node 104-1 and the second node 104-4 (e.g., GSA key 108) is shared by the remaining node 104 in cluster 102, which raises potential security issues related to node removal from the GSA, error handling, key rolling, and the amount of data encrypted using a single key.

[0021] Therefore, in at least some embodiments, the first node 104-1 and the second node 104-4 (and the remaining nodes 104 in the cluster 102) implement a key generation system 210 that generates one or more data encryption keys 212 (also referred to herein as keys 212) using the shared GSA key 108 as the KDK. By using the shared GSA key 108 as the KDK, the key generation system 210 can generate / derive one or more data encryption keys 212 specific to the node pair 200. In other words, the first node 104-1 and the second node 104-4 can generate unique keys 212 for data transmission and reception based on the shared GSA key 108. In at least some embodiments, the data encryption key 212 is an encryption key such as a binary string used as a secret parameter by an encryption algorithm, e.g., an encryption engine 202 or a component of the engine. Examples of encryption keys include a random binary string of a length specified by the encryption algorithm and a pseudo-random binary string of a specified length. In at least some embodiments, the encryption engine 202 uses the data encryption key 212 and additional data to encrypt the data 204. Examples of additional data used for encryption include, for example, an initialization vector and / or an initial count value.

[0022] The first node 104-1 and the second node 104-4 also implement a key rolling system 220 (referred to as key rolling system 220-1 and key rolling system 220-2), which is either separate from or part of the key generation system 210, in at least some embodiments. In addition, the key rolling system 220 includes a key generator 214 or communicates with at least the key generator 214. The key rolling system 220 includes a key rolling event detector 222 (referred to as key rolling event detector 222-1 and key rolling event detector 222-2), in at least some embodiments. The key rolling system 220 is described in more detail below.

[0023] In at least some embodiments, the key generation system 210 includes a key generator 214, a key derivation function 216, and a storage 218. In at least some embodiments, the storage 218 functions as a cache for storing, for example, the last N keys generated by the key generator 214 based on the output of the key derivation function 216. In at least some embodiments, the storage 218 includes the shared GSA key 108. Although the key generation system 210 is shown separately from the encryption engine 202 in FIG. 2, in at least some embodiments, the key generation system 210 or one or more components of the key generation system 210 are included as part of the encryption engine 202. Additionally or alternatively, the key generation system 210 includes more, fewer, or different components than those shown in FIG. 2.

[0024] In at least some embodiments, the key generator 214 uses the key derivation function 216 to generate a data encryption key 212. The key derivation function takes an input that includes a key (e.g., KDK) and other data, and generates / derives key material that can be adopted by an encryption algorithm such as the encryption algorithm implemented by the encryption engine 202. As will be described in more detail below, in at least some embodiments, the key derivation function 216 uses the shared GSA key 108 as the KDK to generate the data encryption key 212. In at least some embodiments, the key derivation function 216 deterministically generates the data encryption key 212. Thus, when given the same input, the key derivation function 216-1 at the first node 104-1 and the key derivation function 216-2 at the second node 104-4 generate a matching data encryption key 126. For this purpose, the first data encryption key 212-1 generated by the key derivation function 216-1 at the first node 104-1 matches the first data encryption key 212-2 generated by the key derivation function 216-2 at the second node 104-4, for example, when the function first receives the same input (e.g., the shared GSA key 108 and additional input data 304 described below with respect to FIG. 3).

[0025] In at least some embodiments, the key derivation function 216 is configured such that the first node 104-1 and the second node 104-4 can generate the key 212 upon request. Also, the input to the key derivation function 216 is configured or selected such that the node pair 200 can use a unique key for data transmission and reception. Further, this input provides for automatic key rolling and uses additional masking functions to provide the ability to ensure that one node cannot spoof packets to another node, even if those nodes are using the same KDK.

[0026] FIG. 3 shows an exemplary configuration of a key generation system 210 for generating the data encryption key 212 based on the shared GSA key 108 and an additional set of inputs using the key derivation function 216. As will be described in more detail below, the key derivation function 216 takes the shared GSA key 108 and additional data 304 (also referred to herein as additional input data 304) as input 302 and generates or derives key material 306. The key material 306 is segmentable into one or more keys. For example, the key generator 214 converts the key material 306 output by the key derivation function 216 into one or more encryption keys, such as one or more data encryption keys 212. Alternatively or additionally, the key material 306 also includes other parameters such as an initialization vector, a key-derivation-key nonce, etc. In at least some embodiments, the initialization vector is used as a counter for tracking the number of encrypted data packets 206 communicated or for tracking the number of encrypted data packets.

[0027] In at least some embodiments, the key generation system 210 is configured to implement one or more of a variety of key generation algorithms for generating a data encryption key 212 based on the shared GSA key 108 and additional input data 304. For example, in at least some embodiments, the key derivation function 216 implements a pseudo-random function (PRF) 308, such as an AES cipher-based message authentication code (CMAC), as defined in the National Institute of Standards and Technology (NIST) special publications (SP) 800-38B and SP 800-108. Other applicable pseudo-random functions include a keyed hash message authentication code (HMAC), a Keccak-based message authentication code (KMAC), and the like.

[0028] The pseudo-random function 308, in at least some implementations, accepts a shared GSA key 108 acting as the KDK and additional input data 304 as input. In configurations that implement AES CMAC as the pseudo-random function 308, the shared GSA key 108 is used as the block encryption key and the additional input data 304 is used as the message M for the CMAC operation performed by the pseudo-random function 308, as defined in NIST SP 800-38B. In at least some embodiments, the additional input data 304 includes a count value 310, a source identifier (ID) 312, a destination ID 314, and a sequence number 316. However, other inputs are also applicable. The count value 310 is used as input to each call of the pseudo-random function 308. For example, the count value 310 is an integer representing the current iteration of the pseudo-random function 308 and is incremented with each subsequent iteration. Source ID 312 is a unique identifier for node 104 of node pair 200 acting as the sender of data packets, and destination ID 314 is a unique identifier for node 104 of node pair 200 acting as the receiver. In at least some embodiments, node 104 of node pair 200 exchanges IDs when the communication link 106 is established. Sequence number 316 represents a count value of the number of packets sent from the source node to the destination node in node pair 200.

[0029] As shown above, the pseudorandom function 308 is, in at least some embodiments, an AES-based pseudorandom function such as the AES CMAC pseudorandom function. Since AES implements a 128-bit block size, the input to the pseudorandom function 308 is a 128-bit input, and the corresponding output (e.g., key material 306) is a 128-bit output. For example, the count value 310 is a 2-bit value, the source ID 312 is a 32-bit value, the destination ID 314 is a 32-bit value, and the sequence number 316 is a 62-bit value. However, other lengths are also applicable. In at least some embodiments, the sequence number 316 is filled with the upper bits of the transmission sequence number of the data packet transmitted by the source node 104 of the node pair 200. In at least some embodiments, if the key generation system 210 is configured to perform key rolling, for example, every 128 packets, the lower 7 bits of this field are not used. In other embodiments, if the key generation system 210 is configured to perform key rolling for each packet, the full sequence number is used in this field. However, other configurations are also applicable.

[0030] In at least some embodiments, one or more mechanisms are implemented to prevent DPA and other attacks against the pseudo-random function 308. For example, one or more masking functions are applied to the input 302 (e.g., count value 310, source ID 312, destination ID 314, and sequence number 316). An example of a masking function includes taking a 128-bit value of the input 302 and performing a modular Galois field multiplication with a 64-bit value shared between the two first nodes 104-1 and the second node 104-4 of the node pair 200. The shared value is agreed upon or communicated by node 104 in the node pair 200 when a communication link 106-1 is established, at least in some embodiments. Since each pair of nodes in the node cluster 102 has a unique 64-bit value, one node cannot generate a key addressed to a different node.

[0031] In at least some embodiments, the key generation system 210 is configured to generate data encryption keys 212 larger than 128 bits (e.g., 256-bit keys, 384-bit keys, 512-bit keys, etc.). However, in embodiments that implement an AES-based pseudorandom function, the pseudorandom function 308 generates 128 bits of key material 306 per iteration, as described above. Thus, in at least some embodiments, the key derivation function 216 invokes the pseudorandom function 308 multiple times based on a counter mode. However, other modes such as a feedback mode and a double-pipeline iteration mode are also applicable.

[0032] Figure 4 shows an example of a key derivation function 216 that invokes the AES CMAC pseudorandom function 308 multiple times in counter mode. In this example, each iteration of the pseudorandom function 308 takes a KDK 402, iteration-dependent input data 404, and fixed input data 406 as inputs. In at least some embodiments, the KDK 402 contains the shared GSA key 108, the iteration-dependent input data 404 contains a counter value 310 (represented as counter values ​​310-1 to 310-3), and the fixed input data 406 contains a source ID 312, a destination ID 314, and a sequence number 316. Since the fixed input data 406 remains the same for each iteration, the iteration-dependent input data 404 is used in combination with the fixed input data 406 to generate a different set of key material 306 (represented as key material 306-1 to 306-3) for each iteration.

[0033] As shown in the example in Figure 4, the first iteration 408 of the pseudo-random function 308 takes the GSA key 108, counter value 310-1, source ID 312, destination ID 314, and sequence number 316 as input. In this iteration, the counter value 310-1 is set to, for example, 0. The pseudo-random function 308 performs an AES CMAC operation on the input (e.g., PRF(count=0,fixed_data_input)) to generate or derive a first set 306-1 of key material of a specified length, such as 128 bits (e.g., [127:0]). In at least some embodiments, the AES CMAC operation is performed in a pipelined manner. In this example, the key generation system 210 is configured to generate a data encryption key 212 that is larger than 128 bits. Thus, at least a second iteration 410 of the pseudo-random function 308 is performed. In this iteration, the pseudo-random function 308 also takes the GSA key 108, counter value 310-2, source ID 312, destination ID 314, and sequence number 316 as input. However, the counter value 310-2 is incremented and set to, for example, 1. Thus, the counter value 310-2 in the second iteration 408 has a different counter value from the counter value 310-1 in the first iteration 408, resulting in a second set of key material 306-2 (e.g., [255:128]=PRF(count=1,fixed_data_input)) different from the first set of key material 306-1. If additional key material 306 is needed, one or more additional iterations 412 of the pseudo-random function 308 are performed. Each subsequent iteration takes the same KDK402 and fixed input data 406 as the previous iteration, but takes a different incremented counter value 310 to generate a different set of key material 306-3 (e.g., [383:256]=PRF(count=2,fixed_data_input)) as described above for the second iteration 410.

[0034] After all iterations of the pseudo-random function 308 have been performed, the key material 306 is provided to the key generator 214, which converts at least a portion of the key material 306 into one or more encryption keys, e.g., one or more data encryption keys 212. In at least some embodiments, the generated data encryption keys 212 are maintained in the storage 218 of node 104. As described above, the data encryption keys 212 are used by the encryption engine 202 of the sending node of node pair 200 to encrypt data packets and by the encryption engine 202 of the receiving node of node pair 200 to decrypt encrypted data packets. In at least some embodiments, the most recently used data encryption keys 212 between nodes 104 of node pair 200 are maintained in a cache (e.g., storage 218) for subsequent use by node 104. The key generator 214 can also generate other parameters from the key material 306, such as initialization vectors and key derivation nonces. Therefore, nodes 104-1 and 104-4 of node pair 200 share the same GSA key 108 as all other nodes 104 in cluster 102, but each node can generate / derive one or more data encryption keys 212 that are unique to node pair 200.

[0035] In some cases, a side-channel attack may be carried out by a malicious entity attempting to circumvent or obtain data encryption keys implemented by nodes within a node cluster. One mechanism to mitigate or prevent side-channel attacks is key rolling, which refers to the act of replacing a key in use (for example, to perform encryption and decryption operations) with a different key. As described above, key rolling in a node cluster configured with a global SA is generally not feasible due to the number of nodes sharing the same key. However, the technique described herein implements a shared GSA key 108 as a KDK for the key derivation function 216, so that each node pair generates a data encryption key 212 unique to the node pair 200, thereby enabling efficient key rolling on the data encryption key 212.

[0036] To this end, the key rolling system 220 of node 104 in node pair 200 performs one or more automatic key rolling operations to improve the security of data processed by the first node 104-1 and the second node 104-4 and communicated via communication link 106-1. The key rolling system 220 communicates with the key generator 214, thereby causing the key generator 214 to automatically roll to the next key 212 in response to key rolling events known by the key rolling system 220 at both the first node 104-1 and the second node 104-4. "Known" means that the events are pre-configured (e.g., programmed) with each other so that, upon the occurrence of an event, both the key rolling system 220-1 at the first node 104-1 and the key rolling system 220-2 at the second node 104-4 detect the event and automatically replace the first data encryption key 212 (e.g., the key in use) with the second data encryption key 212 (e.g., the key not yet in use).

[0037] For example, the key rolling event detector 222 of the key rolling system 220 detects a key rolling event and initiates key rolling. It should be understood that the key rolling event detector 222 detects different events that initiate key rolling in various embodiments. In at least some embodiments, for example, pre-configured events correspond to usage events such as a specified number of encrypted data packets 206 being communicated over the communication link 106. For example, the key rolling event detector 222 detects when the number of communicated encrypted data packets 206 meets a specified threshold number of packets (e.g., 1 packet, 128 packets, etc.) and initiates key rolling. In such a scenario, both the key rolling event detector 222-1 at the first node 104-1 and the key rolling event detector 222-2 at the second node 104-4 are programmed to detect when the number of data packets communicated meets a specified threshold number of packets and initiate key rolling accordingly. For example, if the first node 104-1 is a transmitting device and the second node 104-4 is a receiving device, the packet counter at the first node 104-1 is incremented when data packets are encrypted, and the packet counter at the second node 104-4 is incremented when data packets are decrypted. Furthermore, the key rolling event detector 222-1 at the first node 104-1 detects when the number of transmitted packets, indicated by the packet counter at the first node 104-1, meets a specified threshold, and the key rolling event detector 222-2 at the second node 104-4 detects when the number of received packets, indicated by the packet counter at the second node 104-4, meets a specified threshold.Additionally or alternatively, embodiments of key rolling events detectable by the key rolling event detector 222 include, but are not limited to, the number of flow control units (FLITs) (e.g., 128) of the encrypted data being communicated, the number of sectors, the number of message authentication code (MAC) tags, MAC aggregation boundaries, the bit values ​​of the encrypted data (e.g., key change or key rolling bits), interface-specific events (e.g., PCIe-specific events), or the number of blocks encrypted with the data encryption key (e.g., if not all data packets have a uniform size).

[0038] In at least some embodiments, when the key rolling event detector 222-1 at the first node 104-1 and the key rolling event detector 222-2 at the second node detect a key rolling event, the data encryption key 212 currently in use by the cryptographic engine 202 is replaced with a different data encryption key 212. In at least some embodiments, the cryptographic engine 202 does not reuse the data encryption key 212. Instead, the cryptographic engine 202 retrieves a new data encryption key 212 from storage 218, which is generated, for example, by a key generator 214. For example, when a key rolling event is detected, the key rolling system 220 at each node 104 in the node pair 200 communicates with the key generator 214 to generate a new data encryption key 212, for example, by performing the key generation operation described above with respect to Figures 2 to 4. The generated data encryption key 212 can then be maintained in storage 218. Following the substitution, the encryption engine 202-1 at the first node 104-1 encrypts the data for communication via communication link 106-1 using the new data encryption key 212, and the encryption engine 202-2 at the second node 104-4 decrypts the data received via communication link 106-1 using the new data encryption key 212 and outputs the decrypted data 208.

[0039] Figures 5 and 6 both show flowcharts of Method 500 for generating a unique data encryption key 212 for a node pair in a cluster of nodes sharing a global security association key 108. It should be understood that the process described below with respect to Method 500 is described in more detail above with reference to Figures 1-4. For illustrative purposes, Method 500 will be described with respect to the first node 200-1 of node pair 104. However, the second node 200-4 of node pair 104 will perform a similar process. Furthermore, Method 500 is not limited to the sequence of operations shown in Figures 5 and 6, and at least some of the operations may be performed in parallel or in different sequences. Moreover, in at least some embodiments, Method 500 may include one or more operations different from those shown in Figures 5 and 6.

[0040] In block 502, the first node 104-1 of several nodes 104 in the computing cluster 102 establishes a communication link 106-1 with the second node 104-4 of the nodes 104. Each node 104 in the node cluster 102 shares a GSA key 108. In block 504, the key generation system 210-1 of the first node 104-1 applies a masking function to a set of data (e.g., counter value 310, source ID 312, destination ID 314, and transit sequence number 316) used as additional input data 304 for the key derivation function 216-1. However, in other embodiments, the masking function is not applied to the set of data. In block 506, the key generation system 210-1 provides a key derivation key, such as the GSA key 108, and the additional input data 304 (data in masked or unmasked form) as input to the key derivation function 216-1. In block 508, the key derivation function 216-1 invokes a pseudo-random function 308, such as the AES CMAC pseudo-random function, to generate key material 306 based on the GSA key 108 and additional input data 304.

[0041] In block 510, the key generation system 210-1 determines whether additional iterations of the pseudo-random function 308 should be performed to generate additional key material 306. In block 512, if additional key material 306 is generated, the counter value 310 contained in the additional input data 304 is incremented, and the process returns to block 506, where the GSA key 108 and the additional input data 304 (including the incremented counter value 310) are provided as input to the key derivation function 216-1. In block 508, the pseudo-random function 308 generates a new key material 306 that is different from the previously generated key material 306.

[0042] In block 514, once the required number of iterations of the pseudo-random function 308 have been performed, the key generator 214-1 of the key generation system 210-1 generates a data encryption key 212-1 unique to the first node 104-1 and the second node 104-4 using the generated / derived key material 306. In block 516, the encryption engine 202-1 encrypts the data packet 206 using the data encryption key 212-1. In block 518, the first node 104-1 transmits the encrypted data packet 206 to the second node 104-4. The second node 104-4 decrypts the data packet 206 using a matching data encryption key 212-2 generated by the key generation system 210-2, using a process similar to the process described above for blocks 504 to 514.

[0043] In block 520, the key rolling event detectors 222 in both the first node 104-1 and the second node 104-4 determine whether a specified number of key rolling events, such as transmitted packets, have been detected. In block 522, if no key rolling events are detected, the first node 104-1 and the second node 104-4 maintain the current data encryption key 212, and the process returns to, for example, block 516. In block 524, if a rolling event is detected, the key generation system 210 rolls from the current data encryption key 212 to a new data encryption key. For example, the process flows to block 504 and starts the process for generating a new data encryption key. The process then flows to block 506, and the operations described above are repeated with respect to block 514 from block 506 to generate a new data encryption key based on the shared GSA key 108 and additional input data 304 including an incremented counter value 310.

[0044] Figure 7 is a block diagram showing an example of a processing device 700, such as node 104 in cluster 102 of Figure 1, or a processing device that can include node 104 in cluster 102. Note that the number of components of the processing device 700 varies depending on the embodiment. In at least some embodiments, there are more or fewer components / sub-components than those shown in Figure 7. Also note that in at least some embodiments, the processing device 700 includes other components not shown in Figure 7. In addition, in other embodiments, the processing device 700 is constructed in a manner other than that shown in Figure 7. The components of the processing device 700 are implemented as hardware, circuitry, firmware, software, or any combination thereof. In some embodiments, the processing device 700 includes one or more software components, hardware components, circuitry, and firmware components in addition to or different from those shown in Figure 7.

[0045] In at least some embodiments, the processing device 700 includes one or more central processing units (CPUs) 702 and one or more accelerated processing units (APUs), such as graphics processing units (GPUs) 704. Other examples of APUs include various parallel processors (e.g., vector processors, coprocessors, general-purpose GPUs (GPGPUs), non-scalar processors, highly parallel processors, artificial intelligence (AI) processors, inference engines, machine learning processors, other multithreaded processing units, etc.), scalar processors, serial processors, or any combination thereof. In at least some embodiments, the CPU 702 includes one or more single-core or multi-core CPUs. In various embodiments, the GPU 704 includes any cooperating set of hardware and / or software that, in relation to resources such as conventional CPUs, conventional graphics processing units (GPUs), and combinations thereof, perform functions and computations associated with accelerated graphics processing tasks, data-parallel tasks, and nested data-parallel tasks in an accelerated manner.

[0046] In the embodiment shown in Figure 7, the CPU 702 and GPU 704 are formed and combined on a single silicon die or package to provide an integrated programming and execution environment. This environment allows the GPU 704 to be used as flexibly as the CPU 702 for several programming tasks. In other embodiments, the CPU 702 and GPU 704 are formed separately and mounted on the same or different substrates. It should be understood that the processing device 700 includes more or fewer components than those shown in Figure 7, at least in some embodiments. For example, the processing device 700 additionally includes one or more input interfaces, non-volatile storage, one or more output interfaces, a network interface, and one or more displays or display interfaces.

[0047] As shown in Figure 7, the processing device 700 includes system memory 706, an operating system (OS) 708, a communication infrastructure 710, and one or more applications 712. Access to the system memory 706 is managed by a memory controller (not shown) coupled to the system memory 706. For example, requests from the CPU 702 or other devices to read from or write to the system memory 706 are managed by the memory controller. In some embodiments, one or more applications 712 include various programs or commands for performing calculations that are also performed on the CPU 702. The CPU 702 sends selected commands for processing on the GPU 704. The operating system 708 and the communication infrastructure 710 are described in more detail below.

[0048] Within the processing device 700, system memory 706 includes non-persistent memory such as dynamic random access memory (not shown). In various embodiments, system memory 706 stores processing logic instructions, constant values, variable values ​​during the execution of an application or other part of processing logic, or other desired information. For example, in various embodiments, parts of control logic for performing one or more operations on the CPU 702 reside in system memory 706 during the execution of each part of the operation by the CPU 702. During execution, each application, operating system function, processing logic command, and system software resides in system memory 706. Control logic commands essential to the operating system 708 generally reside in system memory 706 during execution. In some embodiments, other software commands (e.g., a set of instructions or commands used to implement a device driver 714) reside in system memory 706 during the execution of the processing device 700.

[0049] The input-output memory management unit (IOMMU) 716 is a multi-context memory management unit. In use in this invention, the context takes into account the environment in which the kernel is executed and the domains in which synchronization and memory management are defined. The context includes a set of devices, the memory accessible to those devices, the corresponding memory properties, and one or more command queues used to schedule the execution of kernels or operations on memory objects. The IOMMU 716 contains logic for performing virtual-to-physical address translation for memory page access for devices such as the GPU 704. In some embodiments, the IOMMU 716 includes or has access to a translation lookaside buffer (TLB) (not shown). The TLB is implemented in content addressable memory (CAM) and accelerates the translation of logical (i.e., virtual) memory addresses to physical memory addresses for data in system memory 706 in response to requests from the GPU 704.

[0050] In various embodiments, the communication infrastructure 710 interconnects the components of the processing device 700. The communication infrastructure 710 includes one or more of the following: peripheral component interconnect (PCI) buses, extended PCI (PCI-E) buses, advanced microcontroller bus architecture (AMBA) buses, advanced graphics ports (AGP), or other such communication infrastructures and interconnections (not shown). In some embodiments, the communication infrastructure 710 includes an Ethernet® network or any other suitable physical communication infrastructure that satisfies the data transfer rate requirements of the application. The communication infrastructure 710 includes functions for interconnecting components, including the components of the processing device 700.

[0051] A driver, such as a device driver 714, communicates with a device (e.g., a GPU 704) via an interconnection or communication infrastructure 710. When a calling program invokes a routine within the device driver 714, the device driver 714 issues a command to the device. When the device sends data back to the device driver 714, the device driver 714 invokes the routine of the original calling program. Generally, device drivers are hardware-dependent and operating system-specific in order to provide essential interrupt handling to any necessary asynchronously dependent hardware interfaces. In some embodiments, a compiler 718 is embedded within the device driver 714. The compiler 718 compiles the source code into program instructions necessary for execution by the processing device 700. During such compilation, the compiler 718 applies transformations to program the instructions at various stages of compilation. In other embodiments, the compiler 718 is a standalone application. In various embodiments, the device driver 714 controls the operation of the GPU 704 by, for example, providing an application programming interface (API) to software (e.g., application 712) running on the CPU 702 to access various functions of the GPU 704.

[0052] The CPU 702 includes one or more of the following (not shown): a control processor, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or a digital signal processor (DSP). The CPU 702 executes at least a portion of the control logic that controls the operation of the processing device 700. For example, in various embodiments, the CPU 702 executes an operating system 708, one or more applications 712, and a device driver 714. In some embodiments, the CPU 702 initiates and controls the execution of one or more applications 712 by distributing the processing associated with one or more applications 712 across the CPU 702 and other processing resources such as a GPU 704.

[0053] The GPU 704 executes commands and programs for selected functions, such as graphics operations and other operations, which are particularly well-suited for parallel processing. Generally, the GPU 704 is frequently used to perform graphics pipeline operations such as pixel operations, geometric calculations, and rendering images to a display. In some embodiments, the GPU 704 executes computational operations (unrelated to graphics, such as video operations, physical simulations, computational fluid dynamics, etc.) based on commands or instructions received from the CPU 702. For example, such commands include special instructions not typically defined in the instruction set architecture (ISA) of the GPU 704. In some embodiments, the GPU 704 receives image geometry representing a graphics image, along with one or more commands or instructions for rendering and displaying the image. In various embodiments, the image geometry corresponds to a representation of a two-dimensional (2D) or three-dimensional (3D) computer graphics image.

[0054] In various embodiments, the GPU 704 includes one or more computing units, such as one or more processing cores 720 (indicated as 720-1 and 720-2), each containing one or more single-instruction multiple-data (SIMD) units 722 (indicated as 722-1 to 722-4), each SIMD unit 722 configured to execute a thread concurrently with the execution of other threads in a wavefront by other SIMD units 722, for example, according to a SIMD execution model. A SIMD execution model is one in which multiple processing elements share a single program control flow unit and program counter, and thus can execute the same program but with different data. The processing cores 720 are also referred to as shader cores or streaming multi-processors (SMX). The number of processing cores 720 implemented in the GPU 704 is configurable. Each processing core 720 includes one or more processing elements, such as a scalar and / or vector floating-point unit, an arithmetic and logic unit (ALU), etc. In various embodiments, the processing core 720 includes dedicated processing units (not shown), such as an inverse square root unit and a sine / cosine unit.

[0055] Each of the one or more processing cores 720 processes input data by performing its own instantiation of a specific work item, and the basic unit of execution in one or more processing cores 720 is a work item (e.g., a thread). Each work item represents a single instance creation of a collection of parallel executions of kernels launched on the device by, for example, parallel-executing commands. A work item is executed in one or more processing elements as part of a work group executed in the processing cores 720.

[0056] The GPU 704 issues and executes work items, such as groups of threads, that run concurrently as “wavefronts” on a single SIMD unit 722. In at least some embodiments, a wavefront is interchangeably referred to as a warp, vector, or thread. In some embodiments, a wavefront includes an instance of parallel execution of a shader program, but each wavefront includes multiple work items that run concurrently on a single SIMD unit 722 according to a SIMD paradigm (e.g., one instruction control unit that executes multiple data and the same instruction stream). The scheduler 724 is configured to perform operations related to scheduling various wavefronts on different processing cores 720 and SIMD units 722, as well as performing other operations to coordinate various tasks on the GPU 704.

[0057] To reduce latency associated with off-chip memory access, various GPU architectures include a memory cache hierarchy (not shown) that includes, for example, an L1 cache and a local data share (LDS). The LDS is a high-speed, low-latency memory dedicated to each processing core. In some embodiments, the LDS is a full gather / scatter model, allowing workgroups to write anywhere within the allocated space.

[0058] The parallel processing provided by one or more processing cores 720 is suitable for graphics-related operations such as pixel value calculation, vertex transformation, tessellation, geometry shading operations, and other graphics operations. The graphics processing pipeline 726 accepts graphics processing commands from the CPU 702, thereby providing computation tasks to one or more processing cores 720 for parallel execution. Some graphics pipeline operations, such as pixel processing and other parallel computation operations, require that the same command stream or computation kernel be performed on a stream or collection of input data elements. Each instance of the same computation kernel is executed simultaneously on multiple SIMD units 722 in one or more processing cores 720 to process such data elements in parallel. As referred to herein, for example, a computation kernel is declared in a program and executed on an accelerated processing device (APD) processing core 720. This function is also referred to as a kernel, shader, shader program, or program.

[0059] In some embodiments, certain aspects of the technology described above are implemented by one or more processors of a processing system that executes the software. The software includes one or more sets of executable instructions, which are stored in a non-temporary computer-readable storage medium or otherwise clearly embodied. The software may also include instructions and specific data, which, when executed by one or more processors, operate the one or more processors to execute one or more aspects of the technology described above. Non-temporary computer-readable storage mediums may include, for example, magnetic or optical disk storage devices, solid-state storage devices such as flash memory, caches, random-access memory (RAM), or other non-volatile memory devices (one or more). Executable instructions stored in a non-temporary computer-readable storage medium can be implemented as source code, assembly language code, object code, or other instruction forms that can be interpreted or otherwise executed by one or more processors.

[0060] In addition to the foregoing, it should be noted that not all activities or elements described in the summary are required, and certain activities or parts of devices may not be required, and one or more additional activities may be performed, and one or more additional elements may be included. Furthermore, the order in which the activities are listed does not necessarily indicate the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, those skilled in the art will understand that various modifications and variations can be made without departing from the scope of the invention as described in the claims. Therefore, the specification and drawings should be considered illustrative rather than restrictive, and all of these variations are intended to fall within the scope of the invention.

[0061] Benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, benefits, advantages, solutions to problems, and features that may give rise to or manifest any benefits, advantages, or solutions are not to be construed as essential, necessary, or indispensable features to any or all of the claims. Furthermore, the disclosed invention can be modified and implemented in different but similar ways, in ways that are obvious to those skilled in the art who are interested in the teachings of this specification; therefore, the specific embodiments described above are merely illustrative. There are no limitations to the details of the configuration or design shown herein beyond those described in the appended claims. Accordingly, the specific embodiments described above may be modified or altered, and it is clear that all such modifications are within the scope of the disclosed invention. Accordingly, the protection sought herein is described in the appended claims.

Claims

1. The method involves generating a first data encryption key based on a key derivation key, wherein the first data encryption key is unique to a node pair of multiple nodes, This includes encrypting a data packet using the first data encryption key, method.

2. The first node in the node pair transmits the encrypted data packet for reception by the second node in the node pair, The method according to claim 1.

3. Generating the first data encryption key is The method involves initiating a first iteration of a pseudorandom function using a key derivation function, wherein the first iteration of the pseudorandom function accepts a key derivation key, first iteration-dependent input data, and fixed input data as input, and the key derivation key is a global security association encryption key shared by the multiple nodes in the computing cluster. The process includes generating a first set of key material in response to invoking a first iteration of the pseudo-random function, The method according to claim 1.

4. Generating the first data encryption key includes generating the first data encryption key based on a first set of key materials. The method according to claim 3.

5. Generating the first encryption key is The key derivation function is used to invoke at least a second iteration of the pseudorandom function, wherein the at least second iteration of the pseudorandom function receives the key derivation key, the second iteration-dependent input data, and the fixed input data as inputs. In response to invoking a second iteration of the pseudo-random function, at least a second set of key material is generated, The process includes generating the first data encryption key based on the first set of key materials and the second set of key materials, The method according to claim 3.

6. Each of the first iteration-dependent input data and the second iteration-dependent input data includes a different counter value that is incremented after each iteration of the pseudo-random function, and the fixed input data for the first and second iterations includes a source identifier, a destination identifier, and a transmission sequence number. The method of claim 5.

7. This includes applying a masking function to the first iteratively dependent input data, the second iteratively dependent input data, and the fixed input data. The method according to claim 6.

8. The aforementioned pseudo-random function is a message authentication code (CMAC) based on Advanced Encryption Standards (AES). The method according to claim 3.

9. In response to a key rolling event, the system includes rolling from the first data encryption key to the second data encryption key. The method according to any one of claims 1 to 8.

10. This involves initiating a first iteration of a pseudo-random function, the first iteration of which receives a key derivation key, first iteration-dependent input data, and fixed input data as inputs. In response to invoking the first iteration of the pseudo-random function, a first set of key materials is generated, The process involves initiating at least a second iteration of the pseudo-random function, wherein the second iteration receives the key derivation key, the second iteration-dependent input data, and the fixed input data as inputs. In response to invoking a second iteration of the pseudo-random function, at least a second set of key material is generated, The process includes generating a first data encryption key based on a first set of key materials and a second set of key materials, method.

11. The aforementioned pseudo-random function is implemented by a key derivation function. The method of claim 10.

12. The aforementioned key derivation key is a global security association encryption key shared by multiple nodes within a computing cluster. The method of claim 10.

13. This includes encrypting the data packet using the first data encryption key, The method of claim 10.

14. Each of the first iteration-dependent input data and the second iteration-dependent input data includes a different counter value that is incremented after each iteration of the pseudo-random function, and the fixed input data for the first and second iterations includes a source identifier, a destination identifier, and a transmission sequence number. The method of claim 10.

15. The process includes applying a masking function to the first iteration-dependent input data, the second iteration-dependent input data, and the fixed input data for each of the first and second iterations of the pseudo-random function, The method according to claim 14.

16. In response to a key rolling event, the system includes rolling from the first data encryption key to the second data encryption key. The method according to any one of claims 10 to 15.

17. A computing node, A key generator that generates a first data encryption key based on a key derivation key, wherein the first data encryption key is unique to the computing node and to another computing node among a plurality of computing nodes, The system comprises an encryption engine that encrypts data packets using the first data encryption key, Computing node.

18. The aforementioned key generator is The method involves initiating a first iteration of a pseudorandom function using a key derivation function, wherein the first iteration of the pseudorandom function accepts a key derivation key, first iteration-dependent input data, and fixed input data as inputs, and the key derivation key is a global security association encryption key configured to be shared by the multiple computing nodes. In response to invoking the first iteration of the pseudo-random function, a first set of key materials is generated, The first data encryption key is generated by the following: A computing node according to claim 17.

19. The key generator generates the first data encryption key based on the first set of key materials. A computing node according to claim 18.

20. The aforementioned key generator is The key derivation function is used to invoke at least a second iteration of the pseudorandom function, wherein the at least second iteration of the pseudorandom function receives the key derivation key, the second iteration-dependent input data, and the fixed input data as inputs. In response to invoking a second iteration of the pseudo-random function, at least a second set of key material is generated, The first data encryption key is generated based on the first set of key materials and the second set of key materials. The first data encryption key is generated by the following: A computing node according to claim 18.

21. Each of the first iteration-dependent input data and the second iteration-dependent input data includes a different counter value that is incremented after each iteration of the pseudo-random function, and the fixed input data for the first and second iterations includes a source identifier, a destination identifier, and a transmission sequence number. A computing node according to claim 20.

22. Equipped with a key rolling event detector that detects key rolling events, In response to the key rolling event detector detecting the key rolling event, the encryption engine rolls from the first data encryption key to the second data encryption key. A computing node according to any one of claims 17 to 21.

Images