2Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on November 12, 2025 has been entered.
Response to Arguments
Applicant’s arguments, see pages 7-10, filed on November 12, 2025 with respect to the rejection(s) of claim(s) 1-9 and 17-22 under 35 U.S.C. 103 as being unpatentable over have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Hanzlik et al (US 20040044891 A1 -hereinafter – “Hanzlik”).
Applicant’s arguments, see pages 1-14, filed on November 12, 2025 with respect to the rejection(s) of claim(s) 10-16 under 35 U.S.C. and Turon have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view Koerkel et al (US 20120283010 A1 –hereinafter – “Koerkel”).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Wisniewski et al. (US 20200053065 A1—hereinafter—"Wisniewski”) in view of Hanzlik et al (US 20040044891 A1 -hereinafter – “Hanzlik”) in further view of Cox et al. (US 20140189365 A1 –hereinafter—“Cox”).
As per claim 1:
Wisniewski discloses a method comprising:
deriving a first data encryption key ([0031] The tenant secrets 275, such as DEKs, managed by the key management system 200 may be encrypted by a KEK. A KEK may be stored in the HSMs 205 of the HSM fleet 210. Each DEK may be retrieved by the HSM fleet 210 and wrapped, or encrypted, by the KEK in an HSM 205. After encrypting the DEK, the HSM fleet 210 may transmit the encrypted DEK back to the database 215);
wherein the first data encryption key is unique to communication between a corresponding node pair of a plurality of nodes ([0036] In some cases, the KEK rotation process may generate a unique advanced encryption standard (AES) key per BYOK DEK and encrypt each BYOK DEK with a corresponding, unique AES key. The KEK rotation process may then encrypt each unique AES key with the master key. For example, each content key (e.g., BYOK DEK) may have a unique AES key which is encrypted by a single RSA key. In some cases, the single RSA key may be an example of a master KEK key stored in the HSMs 205. For example, the RSA key may be an example of the BYOK KEK described herein, where the RSA key is rotated during the KEK rotation. In some examples, the RSA key may live in (e.g., not leave from) the HSMs 205. In some cases, the AES key may be an example of a DEK-specific KEK. The AES key may also be stored in the database 215) ; and
encrypting a data packet using the first data encryption key ([0029] Each cluster 225 may support or include a number of nodes 220. A node 220 may be an example of a device or machine used for processing or data storage. A node 220 may be a physical device or a virtual partition of a device. In the illustrated example, each cluster 225 may support five nodes 220. In some cases, a node 220 may store a set of tenant secrets 275 or be used to handle processing associated with the set of tenant secrets 275, or both. In some cases, the tenant secrets 275 may be encrypted. For example, the tenant secrets 275 may be encryption keys such as DEKs. In some examples, the tenant secrets 275 may be encrypted by keys, such as KEKs, which are stored in the HSM fleet 210. In some cases, nodes 220 may be grouped into a cluster 225 based on geographical location, capabilities, tenant association, or any combination of these factors. In an example, each node 220 in a first cluster 225 may be for a same tenant of the database 215. In the example, the nodes 220 of the first cluster 225 may be associated with an availability, storage capacity, or server latency requested by or associated with the tenant).
Wisniewski does not explicitly disclose wherein the first data encryption key is shared among a plurality of nodes, wherein the first data encryption key is generated based on identifiers of a corresponding node pair of the plurality of nodes and such that the first data encryption key is unique to communication between the node pair. Hanzlik, in analogous art however, discloses the first data encryption key is shared among a plurality of nodes ([0009] creating a virtual private group definition on a policy server, establishing a plurality of secure connections between the policy server and a plurality of group nodes, sending a copy of the virtual private group definition from the policy server to the group nodes, sending a shared traffic encryption key from the policy server to each of the group nodes, and sharing secure communication information among the group nodes using the shared traffic encryption key. [0027-0028] A Virtual Private Group (VPG) communication system allows a group of computing devices to communicate securely. A group of two or more computing devices communicate securely over a network. The group of computing devices may be part of a wireless network, or, in another embodiment, may be part of a wired network. In a wireless network, the computing devices may include devices such as cellular telephones or personal digital assistants (PDA's). The VPG communication system, the system supports peer-to-peer communications within the defined group. The VPG allows every member of a group to communicate with every other member of the group while providing data confidentiality, packet integrity, and source authentication. The structure of the VPG is completely independent of the physical topology of the underlying network);
the first data encryption key is generated based on identifiers of a corresponding node pair of the plurality of nodes ([0028] The VPG provides a means of managing keys for the group that is simpler than building (N*(N-1))/2 pairwise connections, and the group management supports members joining and leaving the group). [0042] A key distribution protocol is used between policy server 202 and the VPG nodes to distribute the membership key and VPG parameters (such as membership lists and sets of traffic encryption keys) to the nodes. A VPG protocol is used between the VPG nodes to allow the nodes to send and receive encrypted traffic. The membership keys are key encryption keys that are shared by all members of a group. These keys are used for securing VPG control messages between VPG nodes. These control messages allow nodes to update VPG parameters in peer nodes without requiring the peer node to always be in contact with policy server 202. The key distribution keys are pairwise keys shared between policy server 202 and each node. Distribution key 204 is used to secure communications between policy server 202 and VPG node 216. Distribution key 206 is used to secure communications between policy server 202 and VPG node 214. And distribution key 208 is used to secure communications between policy server 202 and VPG node 210. The traffic encryption keys 212 are the keys used to encrypt the traffic sent between the VPG nodes. In certain embodiments, this maybe Internet Protocol (IP) unicast, multicast, or broadcast. Traffic encryption keys 212 is a set of one or more keys on each VPG node. System 200 supports a smooth rollover scheme that allows the group to transition from one key within a set to another key without losing the ability to communicate during the transition. [0043] The VPG nodes receive VPG parameters (such as a list of members by IP address, VPG traffic encryption keys, and membership key) from policy server 202. The VPG nodes then apply the membership list to packets being sent and received. If a packet is going to or coming from a member of the list (based upon IP address, in this embodiment), then the VPG traffic encryption key is applied to encrypt or decrypt the packet).
such that the first data encryption key is unique to communication between the node pair ([0031] policy server 102 transmits unique security policies to each of group nodes 108, 112, 114, and 116, wherein each unique security policy is tailored to the specific operation of each group node. Each of these unique security policies are generated from security policy 104 maintained on policy server 102. [0046] Policy server 202 distributes sets of traffic encryption keys 212 to the group. Thus, there is no loss of communications as nodes rollover from the older traffic encryption key to the newer key. This scheme is unique in that it allows nodes to gradually learn that they need to shift to the new key instead of forcing every node to switch the new key at the same time. [0047] The more "up to date "nodes will have discarded old VPG traffic encryption keys but they will still have the same membership key. System 200 contains a unique mechanism for bringing the nodes up to the same version of the key set).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of encryption key disclosed by Wisniewski to include wherein the first data encryption key is shared among a plurality of nodes, wherein the first data encryption key is generated based on identifiers of a corresponding node pair of the plurality of nodes and such that the first data encryption key is unique to communication between the node pair. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide secure group communications that includes creating a virtual private group definition on a policy server, establishing a plurality of secure connections between the policy server and a plurality of group nodes and sharing secure communication information among the group nodes using the shared traffic encryption key for distributed collaborative environment as suggested by Hanzlik ([0009-0010]).
Wisniewski and Hanzlik do not explicitly disclose the derived first data encryption key is from a key derivation key. Cox , in analogous art however, discloses the derived first data encryption key is from a key derivation key ([0030] Referring again to FIG. 1, the secure key derivation and cryptography logic 102 also includes key derivation logic 108 (e.g., a key derivation engine or module). The key derivation logic may be operable to derive one or more derived keys from the one or more root keys. By way of example, the one or more derived keys may be generated or derived by evaluating an on-die logic implemented key derivation algorithm with the one or more root keys. Different key derivation algorithms are suitable for different embodiments. Examples of suitable key derivation algorithms include, but are not limited to, NIST SP800-108, SP800-56C, key derivation algorithms based on hash functions, key derivation algorithms based on block ciphers, other NIST or FIPS approved key derivation algorithms, and the like. In some embodiments, the key derivation logic may be implemented predominantly, almost entirely, or entirely in hardware within the boundary 116 of the secure key derivation and cryptography logic and on-die and/or on-processor. In some embodiments, root key generation logic and key derivation logic may be implemented in hardware within a security certified boundary as a vertical intellectual property block. Advantageously, the one or more derived keys may be cryptographically derived from the one or more root keys (e.g., one or more PUF based root keys). In one aspect, this may be used to provide multiple different derived keys without needing to have multiple different sets of PUF or fuses, which would otherwise tend to increase the size, manufacturing cost, and power consumption of the logic. [0064] In some embodiments, cryptographic logic 607 may use the domain IDs in order to help enforce domain separation. In some embodiments, the cryptographic logic 607 may include key derivation logic that is operable to derive one or more keys based on and/or dependent on the domain IDs. For example, when a given domain provides request for a key to the logic 602 (e.g., provides a derivation string), the key derivation logic may generate a key that is based on a given domain ID corresponding to that domain (e.g., the key derivation function may be evaluated with the provided derivation string and the given domain ID). Similarly, when other domains make requests for keys, the keys will be generated based on their corresponding different and unique domain IDs. By way of example, a first key derivation request from domain X with a personalization string of "793" would not be return the same derived key as a second key derivation request from domain N with a personalization string of "793," since the domains X and N would have different domain IDs that would be incorporated into the evaluation of the key derivation function. Advantageously, this may be used to provide domain separation based key derivation). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of encryption key disclosed by Wisniewski and Hanzlik to include the derived first data encryption key is from a key derivation key. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a security boundary containing a root key generation logic to protect sensitive or secure information through encryption/decryption as suggested by Cox ([0004-0005]).
As per claim 2:
Wisniewski and Hanzlik in view Cox disclose the method of claim 1, further comprising: transmitting, by a first node in the node pair, the encrypted data packet for receipt by a second node in the node pair (Wisniewski [0034] The HSMs 205 may implement an HSM API 280 and run a small amount of software to ensure security of the HSMs 205. New code for the HSMs 205 may be signed before being uploaded to the HSMs 205. Each HSM 205 may store a Rivest-Shamir-Adleman (RSA) key pair generated at initialization time and signed using an offline certificate authorization. The HSM API 280 running in the HSMs 205 may cryptographically control the export of the KEKs used to encrypt BYOK DEKs. In some cases, the KEKs used to encrypt the BYOK DEKs may be exportable if wrapped using a suitably signed key of another HSM 205. For example, a KEK used to encrypt the BYOK DEKs may be exportable from HSM 205-a to HSM 205-b and other HSMs 205 in the HSM fleet 210. However, the KEK used to encrypt the BYOK DEKs may only be accessible by an official authorized HSM (e.g., an HSM 205 of the HSM fleet 210).
As per claim 17:
Claim 17 is directed to a method having substantially similar corresponding limitations of claim 1 and therefore claim 17 is rejected with the same rationale given above to reject claim 1.
Claims 3-9 and 18-22 are rejected under 35 U.S.C. 103 as being unpatentable over Wisniewski and Hanzlik in view Cox in further view of Turon et al. (US 20180242379 A1 --hereinafter – “Turon”).
As per claims 3 and 18:
Wisniewski and Hanzlik in view Cox disclose wherein generating deriving the first data encryption key comprises: invoking, by a key derivation function, a first iteration taking as input a key derivation key, first iteration-dependent input data, and fixed input data, wherein the key derivation key is a global security association encryption key shared by the plurality of nodes in a computing cluster (Wisniewski [0014] A key management system may support KEK rotation. Each tenant-provided encryption key (e.g., BYOK DEKs) stored in a database may be encrypted by a first KEK. The first KEK may be stored in a set of HSMs and exist only in the set of HSMs. A KEK rotation may be triggered, where the set of HSMs may generate a new, or a second, KEK. The set of HSMs may then retrieve each BYOK DEK encrypted with the first KEK, decrypt each of the BYOK DEKs encrypted by using the first KEK, re-encrypt the BYOK DEKs using the second KEK, and send the re-encrypted BYOK DEKs back to the database for storage. [0015] the KEK rotation process may be triggered based on a request from a tenant, a severance of services to a tenant, a request to sever services to a tenant, an expiration of a timer, a connection status of the HSMs or the database, or any combination of these events. In some cases, a KEK may be exportable from one HSM to another HSM of the set of HSMs, but the KEK may not be exportable to other places (e.g., other HSMs not associated with the key management system, other databases, stores, or servers, etc.); and
responsive to invoking the first iteration of the function, generating a first set of keying material (Wisniewski [0032] The key management system 200 may support KEK rotation for KEKs used to encrypt DEKs provided by tenants of the database 215. In KEK rotation, the HSM fleet 210 may re-encrypt each DEK (e.g., each BYOK DEK) in the database 215 using a newly generated KEK and delete the previously-used KEK. For example, the HSM fleet 210 may have encrypted each DEK in the database 215 using a first KEK. An HSM 205 of the HSM fleet 210 may generate a new KEK and propagate the new KEK to the rest of the HSMs 205 in the HSM fleet 210. The HSM fleet 210 may retrieve each DEK stored in the database 215 encrypted by the first KEK and decrypt the DEKs using the first KEK. The HSM fleet 210 may then re-encrypt each DEK of the database 215 using the new KEK. Once each DEK of the database 215 is re-encrypted using the new KEK, the HSM fleet 210 may delete the first KEK. Because the KEKs are stored only in the HSM fleet 210, the first KEK may be effectively permanently deleted and unrecoverable);
Wisniewski and Hanzlik in view Cox do not explicitly disclose the iteration of the function is a pseudo-random function. Turon, in analogous art however, discloses the iteration of the function is a pseudo-random function ([0075] To improve the security of the PSKc, cryptographic techniques may be applied to increase the entropy of the commissioning credential in the derived PSKc, relative to the equivalent human-scaled commissioning credential passphrase entered by the user. By using key stretching, the derived key can be safely stored on embedded nodes which may be physically compromised, and the user's passphrase won't be compromised. This is helpful because users often reuse passphrases for multiple websites and accounts. For example, any suitable cryptographic technique, such as applying a cryptographic hash multiple times, is be used to stretch the key. For example, Password-Based Key Derivation Function 2 (PBKDF2) can be used to apply Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128). For example, the PSKc may be derived as shown in equation 1: where, PRF is a type Pseudo-Random Function to use by the PBKDF2, P is the commissioning credential, S is a salt for the cryptographic function (e.g., a string such as a network type concatenated with the network name), c is a number of iterations of the PRF, and dkLen is the desired length of the derived key (PSKc). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the iteration of the function disclosed by Wisniewski and Hanzlik in view Cox to include the iteration of the function is a pseudo-random function. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide enhance key encryption rotation of Wisniewski and expand with a commissioning device that can establish a secure joiner communication session between the commissioning device and a joining device, authenticate the joining device using an encrypted device identifier, and join the joining device to a mesh network as suggested by Turon ([0004-0005]).
As pe claims 4 and 19:
Wisniewski and Hanzlik in view Cox and in further view of Turon disclose wherein generating deriving the first data encryption key further comprises generating the first data encryption key based on the first set of keying material (Wisniewski [0036] In some cases, the KEK rotation process may generate a unique advanced encryption standard (AES) key per BYOK DEK and encrypt each BYOK DEK with a corresponding, unique AES key. The KEK rotation process may then encrypt each unique AES key with the master key).
As per claims 5 and 20:
Wisniewski and Hanzlik in view Cox and in further view of Turon disclose wherein generating deriving the first data encryption key further comprises:
invoking, by the key derivation function, at least a second iteration of the pseudo- random function, the second iteration of the pseudo-random function taking as input the key derivation key, second iteration-dependent input data, and the fixed input data; Wisniewski [0036] the KEK rotation process may generate a unique advanced encryption standard (AES) key per BYOK DEK and encrypt each BYOK DEK with a corresponding, unique AES key. The KEK rotation process may then encrypt each unique AES key with the master key. For example, each content key (e.g., BYOK DEK) may have a unique AES key which is encrypted by a single RSA key)
responsive to invoking the second iteration of the pseudo-random function, generating at least a second set of keying material (Wisniewski [0038] The HSMs 205 may also include a next BYOK KEK. The next BYOK KEK may be the “next” BYOK KEK used to encrypt the BYOK DEKs in the database 215. The next BYOK KEK may be set when propagating KEKs between HSMs 205 during KEK rotation. In some cases, the HSMs 205 may include a next BYOK KEK copy, which may be marked for code-safe-only access. In some cases, the HSMs 205 may include an HSM private key. The HSM private key may be a per-HSM RSA private key generated during the HSM initialization process. The HSM private key may be used to import NVRAM BYOK keys into the HSM during key rotation. The associated public key certificate may be signed by an offline certificate authorization during initialization);; and
deriving the first data encryption key based on the first set of keying material and the second set of keying material (Wisniewski [0039] The HSMs 205 may include an import private key, which may be an RSA private key shared by all HSMs 205. The import private key may be used for importing BYOK keys from customers and for encrypting replication messages sent between data centers. The import private key may be rotated automatically after a set period (e.g., after seven days). In some cases, the HSMs 205 may also include a next import private key, which may be set when propagating keys between HSMs and data centers when rotating the import key. [0040] An HSM control plane service 230 may manage the HSM fleet 210. The HSM control plane service 230 may propagate configuration changes to the HSMs 205 in the HSM fleet 210. In some cases, the HSM control plane service 230 may manage BYOK key rotation and re-encrypting BYOK keys in the database 215 during KEK rotation. In some cases, the HSM control plane service 230 may manage code updates for the HSMs 205).
As per claims 6 and 21:
Wisniewski and Hanzlik in view Cox and in further view of Turon disclose wherein the first iteration-dependent input data and the second iteration-dependent input data each comprise a different counter value that is incremented after each iteration of the pseudo-random function, and wherein the fixed input data of the first iteration and the second iteration comprises a source identifier, a destination identifier, and a transmit sequence number (Turon [0073] a Service Set Identifier (SSID) in Wi-Fi networks. Once the first device is commissioned, the first device becomes the leader 216 of the mesh network 100. The first device forms the mesh network 100, including determining a unique Personal Area Network Identifier (PAN ID) and a unique Extended PAN ID (XPANID) for the mesh network 100 and the network key for the mesh network 100).
As per claim 7:
Wisniewski and Hanzlik in view Cox and in further view of Turon disclose the method of claim 6, further comprising: applying a masking function to the first iteration-dependent input data, the second iteration-dependent input data, and the fixed input data (Wisniewski [0031] The tenant secrets 275, such as DEKs, managed by the key management system 200 may be encrypted by a KEK. A KEK may be stored in the HSMs 205 of the HSM fleet 210. Each DEK may be retrieved by the HSM fleet 210 and wrapped, or encrypted, by the KEK in an HSM 205. After encrypting the DEK, the HSM fleet 210 may transmit the encrypted DEK back to the database 215).
As per claim 8:
Wisniewski and Hanzlik in view Cox and in further view of Turon disclose the method of claim 3, wherein the pseudo-random function is an Advanced Encryption Standard (AES) cipher-based message authentication code (CMAC) (Wisniewski [0075] To improve the security of the PSKc, cryptographic techniques may be applied to increase the entropy of the commissioning credential in the derived PSKc, relative to the equivalent human-scaled commissioning credential passphrase entered by the user. By using key stretching, the derived key can be safely stored on embedded nodes which may be physically compromised, and the user's passphrase won't be compromised. This is helpful because users often reuse passphrases for multiple websites and accounts. For example, any suitable cryptographic technique, such as applying a cryptographic hash multiple times, is be used to stretch the key. For example, Password-Based Key Derivation Function 2 (PBKDF2) can be used to apply Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128). For example, the PSKc may be derived as shown in equation 1: where, PRF is a type Pseudo-Random Function to use by the PBKDF2, P is the commissioning credential, S is a salt for the cryptographic function (e.g., a string such as a network type concatenated with the network name), c is a number of iterations of the PRF, and dkLen is the desired length of the derived key (PSKc).
As per claims 9 and 22:
Wisniewski and Hanzlik in view Cox and in further view of Turon disclose the method of claim 1, further comprising: responsive to a key rolling event having occurred, rolling from the first data encryption key to a second data encryption key (Wisniewski [0031] The tenant secrets 275, such as DEKs, managed by the key management system 200 may be encrypted by a KEK. A KEK may be stored in the HSMs 205 of the HSM fleet 210. Each DEK may be retrieved by the HSM fleet 210 and wrapped, or encrypted, by the KEK in an HSM 205. After encrypting the DEK, the HSM fleet 210 may transmit the encrypted DEK back to the database 215).
Claims 10-16 are rejected under 35 U.S.C. 103 as being unpatentable over Wisniewski et al. (US 20200053065 A1—hereinafter—"Wisniewski”) in view of Koerkel et al (US 20120283010 A1 –hereinafter – “Koerkel”) and in further view of Sullivan (US 20200186351 A1) further view of view of Turon et al. (US 20180242379 A1 --hereinafter – “Turon”).
As per claim 10:
Wisniewski discloses a method comprising:
invoking a first iteration of a function, the at first iteration taking as input a key, first iteration-dependent input data, and fixed input data ([0014] A key management system may support KEK rotation. Each tenant-provided encryption key (e.g., BYOK DEKs) stored in a database may be encrypted by a first KEK. The first KEK may be stored in a set of HSMs and exist only in the set of HSMs. A KEK rotation may be triggered, where the set of HSMs may generate a new, or a second, KEK. The set of HSMs may then retrieve each BYOK DEK encrypted with the first KEK, decrypt each of the BYOK DEKs encrypted by using the first KEK, re-encrypt the BYOK DEKs using the second KEK, and send the re-encrypted BYOK DEKs back to the database for storage. [0015] the KEK rotation process may be triggered based on a request from a tenant, a severance of services to a tenant, a request to sever services to a tenant, an expiration of a timer, a connection status of the HSMs or the database, or any combination of these events. In some cases, a KEK may be exportable from one HSM to another HSM of the set of HSMs, but the KEK may not be exportable to other places (e.g., other HSMs not associated with the key management system, other databases, stores, or servers, etc.);
responsive to invoking the first iteration of the function, generating a first set of keying material ([0032] The key management system 200 may support KEK rotation for KEKs used to encrypt DEKs provided by tenants of the database 215. In KEK rotation, the HSM fleet 210 may re-encrypt each DEK (e.g., each BYOK DEK) in the database 215 using a newly generated KEK and delete the previously-used KEK. For example, the HSM fleet 210 may have encrypted each DEK in the database 215 using a first KEK. An HSM 205 of the HSM fleet 210 may generate a new KEK and propagate the new KEK to the rest of the HSMs 205 in the HSM fleet 210. The HSM fleet 210 may retrieve each DEK stored in the database 215 encrypted by the first KEK and decrypt the DEKs using the first KEK. The HSM fleet 210 may then re-encrypt each DEK of the database 215 using the new KEK. Once each DEK of the database 215 is re-encrypted using the new KEK, the HSM fleet 210 may delete the first KEK. Because the KEKs are stored only in the HSM fleet 210, the first KEK may be effectively permanently deleted and unrecoverable);
invoking at least a second iteration of the function, the second iteration taking as input the key, second iteration-dependent input data, and the fixed input data ([0036] the KEK rotation process may generate a unique advanced encryption standard (AES) key per BYOK DEK and encrypt each BYOK DEK with a corresponding, unique AES key. The KEK rotation process may then encrypt each unique AES key with the master key. For example, each content key (e.g., BYOK DEK) may have a unique AES key which is encrypted by a single RSA key);
responsive to invoking the second iteration of the function, generating at least a second set of keying material ([0038] The HSMs 205 may also include a next BYOK KEK. The next BYOK KEK may be the “next” BYOK KEK used to encrypt the BYOK DEKs in the database 215. The next BYOK KEK may be set when propagating KEKs between HSMs 205 during KEK rotation. In some cases, the HSMs 205 may include a next BYOK KEK copy, which may be marked for code-safe-only access. In some cases, the HSMs 205 may include an HSM private key. The HSM private key may be a per-HSM RSA private key generated during the HSM initialization process. The HSM private key may be used to import NVRAM BYOK keys into the HSM during key rotation. The associated public key certificate may be signed by an offline certificate authorization during initialization); and
generating a first data encryption key based on the first set of keying material and the second set of keying material ([0039] The HSMs 205 may include an import private key, which may be an RSA private key shared by all HSMs 205. The import private key may be used for importing BYOK keys from customers and for encrypting replication messages sent between data centers. The import private key may be rotated automatically after a set period (e.g., after seven days). In some cases, the HSMs 205 may also include a next import private key, which may be set when propagating keys between HSMs and data centers when rotating the import key. [0040] An HSM control plane service 230 may manage the HSM fleet 210. The HSM control plane service 230 may propagate configuration changes to the HSMs 205 in the HSM fleet 210. In some cases, the HSM control plane service 230 may manage BYOK key rotation and re-encrypting BYOK keys in the database 215 during KEK rotation. In some cases, the HSM control plane service 230 may manage code updates for the HSMs 205).
Wisniewski does not explicitly disclose the function of the invoked first iteration is a pseudo-random function key generator. Koerkel, in analogous art however, discloses the function of the invoked first iteration is a pseudo-random function key generator ([0032] Key generator 302 includes a key random number generator (RNG) 308. An RNG may also be referred to as a pseudo-random number generator. Kek RNG 308 may be any type of RNG now known in the art or developed in the future. In some embodiments, key RNG 308 is used solely in the generation of encryption keys and is thus separate from other RNGs that may be present on a wagering game machine, such as an RNG that is used to determine outcomes of a wagering game. Key RNG 308 takes a seed value which is used to produce a series of values, where the series of values varies depending on the seed that is supplied. After a seed value is supplied, each invocation of the RNG produces a new value in the series. Key RNG 308 may be any type of generator that, for a given initial state, generates the same output upon an invocation of the generator. For example, a pseudo-random number generator generates the same sequence of values for a given seed value. Similarly, an RNG may comprise a generator that uses a file or memory block that has data that does not change from invocation to invocation of the RNG, and where a starting offset in the file or block is randomly selected and used to provide values. Any RNG that uses the same starting offset and same file or memory block will produce the same sequence of values. In general, key RNG 308 may include any deterministic algorithm that provides a consistent sequence of values based on a known state, where it is computationally inconvenient to determine the sequence of values that will be produced if the starting point is not known. [0041] The key generator 302 maintains multiple key RNGs 308, one key RNG for each multicast group (i.e., channel) that is encrypted. Because each multicast group is assigned a different key RNG, and may have a different key index, a key, 330 may be efficiently generated without having to reseed a single key RNG and iteratively invoke the key RNG to obtain values used to generate a desired key or store numerous results of the key RNG.
Koerkel further discloses ([0048-0049] The generated seed data is submitted to the key RNG, which outputs random data in response. In some embodiments, the key RNG provides 16 bytes of random data. The random data produced in this first invocation of the RNG may be used to generate the first key for the multicast group, key.sub.0. In some embodiments, key.sub.0 is generated by forming a bitwise concatenation of the private passphrase, the random data and the private passphrase a second time. The bitwise concatenation is then submitted to a key hashing function (e.g., key hash 316, FIG. 3A). This output is then used as key.sub.0 in some embodiments. A key is selected according to the key index provided in the response to join the multicast group. A key is selected by invoking the key RNG the number of times indicated by the index plus one. For example, to obtain key.sub.n, the key RNG is seeded as described in block 504 and then iteratively invoked n+1 times).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the input key disclosed by Wisniewski to include the function of the invoked first iteration is a pseudo-random function key generator. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide encrypting multicast data transmitted or received in network systems as suggested by Koerkel ([0003]).
Wisniewski and Koerkel do not explicitly disclose the input key is a key derivation key. Sullivan, in analogous art however, discloses the input key is a key derivation key ([0028] Flow moves from operation 425 to operation 430 and the account creation module 210 derives a password key from the user's password and a salt using a key derivation function. For example, the account creation module 210 uses the key derivation function 335 that takes as input the user password 325 and the password key derivation salt 330 to produce the password key 340. The key derivation function 335 may be, for example, the scrypt key derivation function described in IETF draft “draft-josefsson-scrypt-kdf-01”, Sep. 24, 2014, by Percival et al. [0033] By way of example, the encryption module 215 uses the encryption algorithm 520 to generate a data key to encrypt the data and, for each unique combination of K users, encrypt 560 the data key with each encryption key of the K users thereby generating C(N, K) number of K user encrypted data keys, each of which is capable of decrypting the encrypted data key. Using the example above, a data key is generated and the encryption and decryption server 110 encrypts the data and encrypts the data key three separate times to generate three encrypted data keys for the three different combinations. The encrypted data 565 may be returned to the requester along with metadata to decrypt the encrypted data). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the input key disclosed by Wisniewski and Koerkel to include the input key is a key derivation key. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide delegation permission for user key to be used by encryption and decryption as suggested by Sullivan ([0025]).
Wisniewski, Koerkel and Sullivan do not explicitly disclose the iteration of the function is a pseudo-random function. Turon, in analogous art however, discloses the iteration of the function is a pseudo-random function ([0075] To improve the security of the PSKc, cryptographic techniques may be applied to increase the entropy of the commissioning credential in the derived PSKc, relative to the equivalent human-scaled commissioning credential passphrase entered by the user. By using key stretching, the derived key can be safely stored on embedded nodes which may be physically compromised, and the user's passphrase won't be compromised. This is helpful because users often reuse passphrases for multiple websites and accounts. For example, any suitable cryptographic technique, such as applying a cryptographic hash multiple times, is be used to stretch the key. For example, Password-Based Key Derivation Function 2 (PBKDF2) can be used to apply Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128). For example, the PSKc may be derived as shown in equation 1: where, PRF is a type Pseudo-Random Function to use by the PBKDF2, P is the commissioning credential, S is a salt for the cryptographic function (e.g., a string such as a network type concatenated with the network name), c is a number of iterations of the PRF, and dkLen is the desired length of the derived key (PSKc). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the iteration of the function disclosed by Wisniewski to include the iteration of the function is a pseudo-random function. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide enhance key encryption rotation of Wisniewski, Koerkel and Sullivan expand with a commissioning device that can establish a secure joiner communication session between the commissioning device and a joining device, authenticate the joining device using an encrypted device identifier, and join the joining device to a mesh network as suggested by Turon ([0004-0005]).
As per claim 11:
Wisniewski and Koerkel in view of Sullivan in further view of Turon discloses the method of claim 10, wherein the pseudo-random function is implemented by a key derivation function (Turon [0075] To improve the security of the PSKc, cryptographic techniques may be applied to increase the entropy of the commissioning credential in the derived PSKc, relative to the equivalent human-scaled commissioning credential passphrase entered by the user. By using key stretching, the derived key can be safely stored on embedded nodes which may be physically compromised, and the user's passphrase won't be compromised. This is helpful because users often reuse passphrases for multiple websites and accounts. For example, any suitable cryptographic technique, such as applying a cryptographic hash multiple times, is be used to stretch the key. For example, Password-Based Key Derivation Function 2 (PBKDF2) can be used to apply Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128). For example, the PSKc may be derived as shown in equation 1: where, PRF is a type Pseudo-Random Function to use by the PBKDF2, P is the commissioning credential, S is a salt for the cryptographic function (e.g., a string such as a network type concatenated with the network name), c is a number of iterations of the PRF, and dkLen is the desired length of the derived key (PSKc)).
As per claim 12:
Wisniewski and Koerkel in view of Sullivan in further view of Turon discloses the method of claim 10, wherein the key derivation key is a global security association encryption key shared by a plurality of nodes in a computing cluster (Wisniewski [0035] Each HSM 205 in the HSM fleet 210 may have a common security configuration and store a set of keys. In some cases, the HSMs 205 may store a master key, which may be derived from a set of smart cards and may be used as the KEK for all non-BYOK keys stored in the database 215. Rotating the master key may be a manual operation involving a signaling ceremony and a quorum of crypto operators).
As per claim 13:
Wisniewski and Koerkel in view of Sullivan in further view of Turon discloses the method of claim 10, further comprising: encrypting a data packet using the first data encryption key (Wisniewski [0036] In some cases, the KEK rotation process may generate a unique advanced encryption standard (AES) key per BYOK DEK and encrypt each BYOK DEK with a corresponding, unique AES key. The KEK rotation process may then encrypt each unique AES key with the master key. For example, each content key (e.g., BYOK DEK) may have a unique AES key which is encrypted by a single RSA key. In some cases, the single RSA key may be an example of a master KEK key stored in the HSMs 205. For example, the RSA key may be an example of the BYOK KEK described herein, where the RSA key is rotated during the KEK rotation. In some examples, the RSA key may live in (e.g., not leave from) the HSMs 205. In some cases, the AES key may be an example of a DEK-specific KEK. The AES key may also be stored in the database 215).
As per claim 14:
Wisniewski and Koerkel in view of Sullivan in further view of Turon discloses the method of claim 10, wherein the first iteration-dependent input data and the second iteration-dependent input data each comprise a different counter value that is incremented after each iteration of the pseudo-random function, and wherein the fixed input data of the first iteration and the second iteration comprises a source identifier, a destination identifier, and a transmit sequence number (Turon [0073] a Service Set Identifier (SSID) in Wi-Fi networks. Once the first device is commissioned, the first device becomes the leader 216 of the mesh network 100. The first device forms the mesh network 100, including determining a unique Personal Area Network Identifier (PAN ID) and a unique Extended PAN ID (XPANID) for the mesh network 100 and the network key for the mesh network 100).
As pe claim 15:
Wisniewski and Koerkel in view of Sullivan in further view of Turon discloses the method of claim 14, further comprising: 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 iteration and the second iteration of the pseudo-random function (Wisniewski [0049] The KEK rotation process 300 may be triggered by, for example, a timer expiring, a request from a tenant, or a severance of services to a tenant. An HSM 305 of the HSM fleet 310 may generate a second KEK 335, corresponding to the next BYOK KEK described in FIG. 2. The HSM 305 may propagate the second KEK 335 to the other HSMs 305 in the HSM fleet 310. For example, HSM 305-a may generate the second KEK 335, wrap the second KEK 335 using a suitably signed off key of another HSM 305, then propagate the second KEK 335 to the other HSMs 305 of the HSM fleet 310).
As per claim 16:
Wisniewski and Koerkel in view of Sullivan in further view of Turon discloses the method of claim 10, further comprising: responsive to a key rolling event having occurred, rolling from the first data encryption key to a second data encryption key (Wisniewski [0055] A KEK rotation may be triggered based on, for example, receiving a request from a tenant of the database to terminate services, receiving a request from the tenant of the database to delete a key of the set of encryption keys, determining a timer for periodically re-encrypting the set of encryption keys has expired, or a combination of these events. Upon detecting the KEK rotation trigger, the HSM fleet 410 may initiate the KEK rotation process. In some cases, if a tenant requests that a DEK is deleted from the database or if the tenant has terminated services, the DEK may not be re-encrypted by the new KEK during the next KEK rotation).
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior arts.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, LINGLAN EDWARDS can be reached on (571) 270-5440. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408