DETAILED ACTION
Notice 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 .
Summary
This action is a responsive to the application filed on 4/29/2025.
Claims 1-15 have been canceled.
Claims 16-35 are new.
Claims 16-35 are pending and have been examined.
Claims 16-35 are rejected.
Information Disclosure Statement
The information disclosure statements (IDS)s submitted on 4/29/2025 & 7/22/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 19, 33 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The claim attempts to define the subject-matter in terms of the result to be achieved, which merely amounts to a statement of the underlying problem, without providing the technical features necessary for achieving this result. It is in particular unclear how the controller is able to distinguish hardware generated keys from software generated keys. For the purpose of compact prosecution, this claim will be interrupted as receiving a key.
Claim Rejections - 35 USC § 103
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 16-17, 20-29 are rejected under 35 U.S.C. 103 as being unpatentable over Dewan et al. (US 20220197825 A1) and further in view of BADAM (US 20260081764 A1).
As to claim 16, Dewan et al. teaches A method comprising: receiving, at a flash storage wrapper, via a first bus and from a hardware key manager (See ¶¶ [0035], [0043], [0040], Teaches that Hardware key engine receives its keys from the CPU ISA 340 (as programmed by software) or from a security controller. The requested data is encrypted using the encryption keys. The encryption keys may be provided by Software 340. Software 340 supports multiple encryption keys. Software 340 may program the Keys. There may be four types of keys: (1) hardware generated, (2) hardware wrapped, (3) plaintext keys, and (4) no-encryption “key”.);
receiving, at the flash storage wrapper, via a second bus and from a flash storage driver, a memory command (See ¶¶ [0034], [0042], Teaches that NVMe drive 302 issues DMA Read Request 310 to SOC 320. When using a PCIe link between the NVMe drive 302 and the SOC 320, the Read Request 310 may adhere to the PCIe transaction layer packet (TLP) format for a read request, where the TLP header may be used to indicate a key table index and an offset to the LBA, so as to facilitate the encryption of the requested data by the Crypto Controller 322.);
and encrypting, at the flash storage wrapper, a file using the first child key and in accordance with the memory command and directing a write of the encrypted file to a location of a flash storage device, the location based on the memory command received from the flash storage driver (See ¶¶ [0043], [0046], Teaches that The requested data is encrypted using the encryption keys. The encryption keys may be provided by Software 340. Data read from memory 360 for storage on the NVMe drive 302 is encrypted by the Crypto Controller 322 before passing the read data to the NVMe drive.);
or reading, at the flash storage wrapper, a file on the flash storage device, a location of the file based on the memory command received from the flash storage driver and decrypting, at the flash storage wrapper, the file using the first child key and in accordance with the memory command (See ¶ [0046], Teaches that Encrypted data emanating from the NVMe drive 302 is decrypted by the Crypto Controller 322 before passing it to another device, e.g., to memory 360.).
However, it does not expressly teach the details of a first child key, the first child key generated from a base key by the hardware key manager.
BADAM, from analogous art, teaches a first child key, the first child key generated from a base key by the hardware key manager (See ¶¶ [0054]-[0057], Teaches that the method 300 includes identifying a unique identifier for a computer chip with a system-on-chip design. A random identifier is burned into each processor at manufacturing. This value may not be readable by firmware or software and is directly read by the processor's hardware. In an aspect, the random identifier is a 256-bit random identifier. The random identifier may be combined with a random secret at every power up of the SoC to create a power-cycle specific unique identifier that is only valid for that power cycle. This further diversifies the keys that are generated and makes them unique every power cycle. In aspects, the unique identifier identified at step 310 may be either the random identifier burned into the processor or the power-cycle specific unique identifier. At step 330, the method 300 includes combining the unique identifier with a representation of the location to form a cryptographic salt for the cryptographic key. At step 340, the method 300 includes providing the cryptographic salt to a cryptographic function as a first part of an input. The second part of the input may be a cryptographic key associated with a parent node for the location. If an upper level key is being generated, then the root key may be used. At step 350, the method 300 includes generating, at the cryptographic function, the cryptographic key using the input. In addition, the cryptographic function may be executed a level-specific amount of iterations. At step 360, the method 300 includes using the cryptographic key to encrypt a portion of computer memory on the computer chip.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of BADAM into Dewan et al. in order to create a secure hardware platform that is resilient to security attacks (See BADAM ¶ [0002]).
As to claim 17, the combination of Dewan et al. and BADAM teaches the method according to claim 16 above. Dewan et al. further teaches wherein the first bus and the second bus are different (See ¶¶ [0035], [0043], [0040], [0034], [0042], Fig. 3A, Teaches that Hardware key engine receives its keys from the CPU ISA 340 (as programmed by software) or from a security controller. The requested data is encrypted using the encryption keys. The encryption keys may be provided by Software 340. Software 340 supports multiple encryption keys. Software 340 may program the Keys. There may be four types of keys: (1) hardware generated, (2) hardware wrapped, (3) plaintext keys, and (4) no-encryption “key”. NVMe drive 302 issues DMA Read Request 310 to SOC 320. When using a PCIe link between the NVMe drive 302 and the SOC 320, the Read Request 310 may adhere to the PCIe transaction layer packet (TLP) format for a read request, where the TLP header may be used to indicate a key table index and an offset to the LBA, so as to facilitate the encryption of the requested data by the Crypto Controller 322).
As to claim 20, the combination of Dewan et al. and BADAM teaches the method according to claim 16 above. Dewan et al. further teaches wherein: the memory command identifies a location within a key table within a host controller interface of the flash storage wrapper; and the method further comprises storing the first child key at the location within the key table identified in the memory command (See ¶¶ [0037], [0042], [0044], Teaches that Memory circuitry 327 may store one or more instructions to cause the one or more processor circuitries (not shown) in Crypto Controller 322 to execute a plurality of desired tasks. The tasks include, for example, receipt and storing of cryptographic information required to encrypt or decrypt data, forming data and/or key tables and communicating encrypted or decrypted data with components external to the SOC 320. Once formed, such tables may be stored at Key Lookup Table (KLT) 326. In one embodiment, the Crypto Memory Circuitry 327 may include KLT 326. In another embodiment the KLT 326 may be in DRAM 360 and the memory 327 inside the crypto controller may serve as a cache. During an exemplary implementation NVMe driver (e.g., SSD) 302 transmits a read request 310 to SOC 320. Read Request 310 may not be encrypted. In an optional embodiment, a portion of the Read Request 310 may be encrypted. Read Request 310 contains a key table index (or key lookup index) and optionally further an offset to the LBA which allow the Crypto Controller 322 identifying one or more encryption of the requested data. When using a PCIe link between the NVMe drive 302 and the SOC 320, the Read Request 310 may adhere to the PCIe transaction layer packet (TLP) format for a read request, where the TLP header may be used to indicate a key table index and an offset to the LBA, so as to facilitate the encryption of the requested data by the Crypto Controller 322. An embodiment uses the TLP Prefix in the header of a TLP packet to send the key table index and the offset value. In another embodiment, some of the address bits in the header of Read Request 310 (and Write Request 370 described herein below) may be used to indicate the key table index and an offset to the LBA. In the PCIe context, the address bits may be comprised in the TLP header. An example is outlined in connection with FIG. 11 below. The Read Request 310 and Write Request 370 may be DMA requests that can have 64 bits of address information. The address information can be one of the following three information: physical address, Guest Physical Address, or IO Virtual Address. A number of the available address bits may be used to index a table of 4K entries with 8 bytes per entry (i.e., 32 K byte table). The remaining available bits may be used for offset to the base LBA in the table.).
As to claim 21, the combination of Dewan et al. and BADAM teaches the method according to claim 20 above. Dewan et al. further teaches wherein the encrypting of the file using the first child key comprises encrypting the file using a first cryptographic engine within the host controller interface of the flash storage wrapper, the first cryptographic engine using the first child key stored in the key table (See ¶¶ [0037], [0042], [0044], Teaches that Memory circuitry 327 may store one or more instructions to cause the one or more processor circuitries (not shown) in Crypto Controller 322 to execute a plurality of desired tasks. The tasks include, for example, receipt and storing of cryptographic information required to encrypt or decrypt data, forming data and/or key tables and communicating encrypted or decrypted data with components external to the SOC 320. Once formed, such tables may be stored at Key Lookup Table (KLT) 326. In one embodiment, the Crypto Memory Circuitry 327 may include KLT 326. In another embodiment the KLT 326 may be in DRAM 360 and the memory 327 inside the crypto controller may serve as a cache. During an exemplary implementation NVMe driver (e.g., SSD) 302 transmits a read request 310 to SOC 320. Read Request 310 may not be encrypted. In an optional embodiment, a portion of the Read Request 310 may be encrypted. Read Request 310 contains a key table index (or key lookup index) and optionally further an offset to the LBA which allow the Crypto Controller 322 identifying one or more encryption of the requested data. When using a PCIe link between the NVMe drive 302 and the SOC 320, the Read Request 310 may adhere to the PCIe transaction layer packet (TLP) format for a read request, where the TLP header may be used to indicate a key table index and an offset to the LBA, so as to facilitate the encryption of the requested data by the Crypto Controller 322. An embodiment uses the TLP Prefix in the header of a TLP packet to send the key table index and the offset value. In another embodiment, some of the address bits in the header of Read Request 310 (and Write Request 370 described herein below) may be used to indicate the key table index and an offset to the LBA. In the PCIe context, the address bits may be comprised in the TLP header. An example is outlined in connection with FIG. 11 below. The Read Request 310 and Write Request 370 may be DMA requests that can have 64 bits of address information. The address information can be one of the following three information: physical address, Guest Physical Address, or IO Virtual Address. A number of the available address bits may be used to index a table of 4K entries with 8 bytes per entry (i.e., 32 K byte table). The remaining available bits may be used for offset to the base LBA in the table.).
As to claim 22, the combination of Dewan et al. and BADAM teaches the method according to claim 20 above. Dewan et al. further teaches wherein the directing of the write of the encrypted file to the flash storage device comprises directing, by the host controller interface of the flash storage wrapper, the write of the encrypted file to the flash storage device (See ¶¶ [0037], [0042], [0044], Teaches that Memory circuitry 327 may store one or more instructions to cause the one or more processor circuitries (not shown) in Crypto Controller 322 to execute a plurality of desired tasks. The tasks include, for example, receipt and storing of cryptographic information required to encrypt or decrypt data, forming data and/or key tables and communicating encrypted or decrypted data with components external to the SOC 320. Once formed, such tables may be stored at Key Lookup Table (KLT) 326. In one embodiment, the Crypto Memory Circuitry 327 may include KLT 326. In another embodiment the KLT 326 may be in DRAM 360 and the memory 327 inside the crypto controller may serve as a cache. During an exemplary implementation NVMe driver (e.g., SSD) 302 transmits a read request 310 to SOC 320. Read Request 310 may not be encrypted. In an optional embodiment, a portion of the Read Request 310 may be encrypted. Read Request 310 contains a key table index (or key lookup index) and optionally further an offset to the LBA which allow the Crypto Controller 322 identifying one or more encryption of the requested data. When using a PCIe link between the NVMe drive 302 and the SOC 320, the Read Request 310 may adhere to the PCIe transaction layer packet (TLP) format for a read request, where the TLP header may be used to indicate a key table index and an offset to the LBA, so as to facilitate the encryption of the requested data by the Crypto Controller 322. An embodiment uses the TLP Prefix in the header of a TLP packet to send the key table index and the offset value. In another embodiment, some of the address bits in the header of Read Request 310 (and Write Request 370 described herein below) may be used to indicate the key table index and an offset to the LBA. In the PCIe context, the address bits may be comprised in the TLP header. An example is outlined in connection with FIG. 11 below. The Read Request 310 and Write Request 370 may be DMA requests that can have 64 bits of address information. The address information can be one of the following three information: physical address, Guest Physical Address, or IO Virtual Address. A number of the available address bits may be used to index a table of 4K entries with 8 bytes per entry (i.e., 32 K byte table). The remaining available bits may be used for offset to the base LBA in the table.).
As to claim 23, the combination of Dewan et al. and BADAM teaches the method according to claim 20 above. Dewan et al. further teaches wherein the reading of the file on the flash storage device comprises reading, by the host controller interface of the flash storage wrapper, the file on the flash storage device (See ¶¶ [0037], [0042], [0044], Teaches that Memory circuitry 327 may store one or more instructions to cause the one or more processor circuitries (not shown) in Crypto Controller 322 to execute a plurality of desired tasks. The tasks include, for example, receipt and storing of cryptographic information required to encrypt or decrypt data, forming data and/or key tables and communicating encrypted or decrypted data with components external to the SOC 320. Once formed, such tables may be stored at Key Lookup Table (KLT) 326. In one embodiment, the Crypto Memory Circuitry 327 may include KLT 326. In another embodiment the KLT 326 may be in DRAM 360 and the memory 327 inside the crypto controller may serve as a cache. During an exemplary implementation NVMe driver (e.g., SSD) 302 transmits a read request 310 to SOC 320. Read Request 310 may not be encrypted. In an optional embodiment, a portion of the Read Request 310 may be encrypted. Read Request 310 contains a key table index (or key lookup index) and optionally further an offset to the LBA which allow the Crypto Controller 322 identifying one or more encryption of the requested data. When using a PCIe link between the NVMe drive 302 and the SOC 320, the Read Request 310 may adhere to the PCIe transaction layer packet (TLP) format for a read request, where the TLP header may be used to indicate a key table index and an offset to the LBA, so as to facilitate the encryption of the requested data by the Crypto Controller 322. An embodiment uses the TLP Prefix in the header of a TLP packet to send the key table index and the offset value. In another embodiment, some of the address bits in the header of Read Request 310 (and Write Request 370 described herein below) may be used to indicate the key table index and an offset to the LBA. In the PCIe context, the address bits may be comprised in the TLP header. An example is outlined in connection with FIG. 11 below. The Read Request 310 and Write Request 370 may be DMA requests that can have 64 bits of address information. The address information can be one of the following three information: physical address, Guest Physical Address, or IO Virtual Address. A number of the available address bits may be used to index a table of 4K entries with 8 bytes per entry (i.e., 32 K byte table). The remaining available bits may be used for offset to the base LBA in the table.).
As to claim 24, the combination of Dewan et al. and BADAM teaches the method according to claim 20 above. Dewan et al. further teaches wherein the decrypting of the file using the first child key comprises decrypting the file using a first cryptographic engine within the host controller interface of the flash storage wrapper, the first cryptographic engine using the first child key stored in the key table (See ¶¶ [0037], [0042], [0044], Teaches that Memory circuitry 327 may store one or more instructions to cause the one or more processor circuitries (not shown) in Crypto Controller 322 to execute a plurality of desired tasks. The tasks include, for example, receipt and storing of cryptographic information required to encrypt or decrypt data, forming data and/or key tables and communicating encrypted or decrypted data with components external to the SOC 320. Once formed, such tables may be stored at Key Lookup Table (KLT) 326. In one embodiment, the Crypto Memory Circuitry 327 may include KLT 326. In another embodiment the KLT 326 may be in DRAM 360 and the memory 327 inside the crypto controller may serve as a cache. During an exemplary implementation NVMe driver (e.g., SSD) 302 transmits a read request 310 to SOC 320. Read Request 310 may not be encrypted. In an optional embodiment, a portion of the Read Request 310 may be encrypted. Read Request 310 contains a key table index (or key lookup index) and optionally further an offset to the LBA which allow the Crypto Controller 322 identifying one or more encryption of the requested data. When using a PCIe link between the NVMe drive 302 and the SOC 320, the Read Request 310 may adhere to the PCIe transaction layer packet (TLP) format for a read request, where the TLP header may be used to indicate a key table index and an offset to the LBA, so as to facilitate the encryption of the requested data by the Crypto Controller 322. An embodiment uses the TLP Prefix in the header of a TLP packet to send the key table index and the offset value. In another embodiment, some of the address bits in the header of Read Request 310 (and Write Request 370 described herein below) may be used to indicate the key table index and an offset to the LBA. In the PCIe context, the address bits may be comprised in the TLP header. An example is outlined in connection with FIG. 11 below. The Read Request 310 and Write Request 370 may be DMA requests that can have 64 bits of address information. The address information can be one of the following three information: physical address, Guest Physical Address, or IO Virtual Address. A number of the available address bits may be used to index a table of 4K entries with 8 bytes per entry (i.e., 32 K byte table). The remaining available bits may be used for offset to the base LBA in the table.).
As to claim 25, the combination of Dewan et al. and BADAM teaches the method according to claim 26 above. However, it does not expressly teach the details of further comprising generating the first child key by: receiving, at the hardware key manager, via a third bus and from the flash storage driver, a first nonce; receiving, at the hardware key manager, via the third bus and from the flash storage driver, an identity of the base key in a base key table within the hardware key manager; and applying, by the hardware key manager, the first nonce to the base key to generate the first child key using the received identity.
BADAM, from analogous art, teaches further comprising generating the first child key by: receiving, at the hardware key manager, via a third bus and from the flash storage driver, a first nonce; receiving, at the hardware key manager, via the third bus and from the flash storage driver, an identity of the base key in a base key table within the hardware key manager; and applying, by the hardware key manager, the first nonce to the base key to generate the first child key using the received identity (See ¶¶ [0054]-[0057], [0046]-[0049], Teaches that the method 300 includes identifying a unique identifier for a computer chip with a system-on-chip design. A random identifier is burned into each processor at manufacturing. This value may not be readable by firmware or software and is directly read by the processor's hardware. In an aspect, the random identifier is a 256-bit random identifier. The random identifier may be combined with a random secret at every power up of the SoC to create a power-cycle specific unique identifier that is only valid for that power cycle. This further diversifies the keys that are generated and makes them unique every power cycle. In aspects, the unique identifier identified at step 310 may be either the random identifier burned into the processor or the power-cycle specific unique identifier. At step 330, the method 300 includes combining the unique identifier with a representation of the location to form a cryptographic salt for the cryptographic key. At step 340, the method 300 includes providing the cryptographic salt to a cryptographic function as a first part of an input. The second part of the input may be a cryptographic key associated with a parent node for the location. If an upper level key is being generated, then the root key may be used. At step 350, the method 300 includes generating, at the cryptographic function, the cryptographic key using the input. In addition, the cryptographic function may be executed a level-specific amount of iterations. At step 360, the method 300 includes using the cryptographic key to encrypt a portion of computer memory on the computer chip. The salt generator 146 generates a cryptographic salt that is used as an input to a cryptographic function. In this case, the cryptographic salt is the root key concatenated with the unique identifier. Adding the unique identifier to the root key improves the probability that the salt is unique in the event the same root key is generated for multiple. The input to the cryptographic function for a given location in the cryptographic hierarchy is a location-specific representation concatenated with the cryptographic salt and the cryptographic key from the parent node. In the case of upper level keys, the root key 201 is used as input as a parent node. The cryptographic function is then executed a level-specific amount of iterations to generate the cryptographic key for a location. By way of example, the input provided to the cryptographic function to generate the upper key one 211 is the root key 201 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010000) for the upper key one 211). The input provided to the cryptographic function to generate the intermediate key three 223 is the upper key one 211 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010300) for the intermediate key three 223). The input provided to the cryptographic function to generate the lower key two 232 is the intermediate key three 223 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010302) for the lower key two 232).).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of BADAM into the combination of Dewan et al. and BADAM in order to create a secure hardware platform that is resilient to security attacks (See BADAM ¶ [0002]).
As to claim 26, the combination of Dewan et al. and BADAM teaches the method according to claim 25 above However, it does not expressly teach the details of wherein the applying of the first nonce to the base key comprises applying the first nonce to the base key using a second cryptographic engine within the hardware key manager.
BADAM, from analogo.us art, teaches wherein the applying of the first nonce to the base key comprises applying the first nonce to the base key using a second cryptographic engine within the hardware key manager (See ¶¶ [0054]-[0057], [0046]-[0049], Teaches that the method 300 includes identifying a unique identifier for a computer chip with a system-on-chip design. A random identifier is burned into each processor at manufacturing. This value may not be readable by firmware or software and is directly read by the processor's hardware. In an aspect, the random identifier is a 256-bit random identifier. The random identifier may be combined with a random secret at every power up of the SoC to create a power-cycle specific unique identifier that is only valid for that power cycle. This further diversifies the keys that are generated and makes them unique every power cycle. In aspects, the unique identifier identified at step 310 may be either the random identifier burned into the processor or the power-cycle specific unique identifier. At step 330, the method 300 includes combining the unique identifier with a representation of the location to form a cryptographic salt for the cryptographic key. At step 340, the method 300 includes providing the cryptographic salt to a cryptographic function as a first part of an input. The second part of the input may be a cryptographic key associated with a parent node for the location. If an upper level key is being generated, then the root key may be used. At step 350, the method 300 includes generating, at the cryptographic function, the cryptographic key using the input. In addition, the cryptographic function may be executed a level-specific amount of iterations. At step 360, the method 300 includes using the cryptographic key to encrypt a portion of computer memory on the computer chip. The salt generator 146 generates a cryptographic salt that is used as an input to a cryptographic function. In this case, the cryptographic salt is the root key concatenated with the unique identifier. Adding the unique identifier to the root key improves the probability that the salt is unique in the event the same root key is generated for multiple. The input to the cryptographic function for a given location in the cryptographic hierarchy is a location-specific representation concatenated with the cryptographic salt and the cryptographic key from the parent node. In the case of upper level keys, the root key 201 is used as input as a parent node. The cryptographic function is then executed a level-specific amount of iterations to generate the cryptographic key for a location. By way of example, the input provided to the cryptographic function to generate the upper key one 211 is the root key 201 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010000) for the upper key one 211). The input provided to the cryptographic function to generate the intermediate key three 223 is the upper key one 211 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010300) for the intermediate key three 223). The input provided to the cryptographic function to generate the lower key two 232 is the intermediate key three 223 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010302) for the lower key two 232).).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of BADAM into the combination of Dewan et al. and BADAM in order to create a secure hardware platform that is resilient to security attacks (See BADAM ¶ [0002]).
As to claim 27, the combination of Dewan et al. and BADAM teaches the method according to claim 25 above. However, it does not expressly teach the details of wherein the first bus, the second bus, and the third bus are different.
BADAM, from analogous art, teaches wherein the first bus, the second bus, and the third bus are different (See ¶¶ [0054]-[0057], [0046]-[0049], Teaches that the method 300 includes identifying a unique identifier for a computer chip with a system-on-chip design. A random identifier is burned into each processor at manufacturing. This value may not be readable by firmware or software and is directly read by the processor's hardware. In an aspect, the random identifier is a 256-bit random identifier. The random identifier may be combined with a random secret at every power up of the SoC to create a power-cycle specific unique identifier that is only valid for that power cycle. This further diversifies the keys that are generated and makes them unique every power cycle. In aspects, the unique identifier identified at step 310 may be either the random identifier burned into the processor or the power-cycle specific unique identifier. At step 330, the method 300 includes combining the unique identifier with a representation of the location to form a cryptographic salt for the cryptographic key. At step 340, the method 300 includes providing the cryptographic salt to a cryptographic function as a first part of an input. The second part of the input may be a cryptographic key associated with a parent node for the location. If an upper level key is being generated, then the root key may be used. At step 350, the method 300 includes generating, at the cryptographic function, the cryptographic key using the input. In addition, the cryptographic function may be executed a level-specific amount of iterations. At step 360, the method 300 includes using the cryptographic key to encrypt a portion of computer memory on the computer chip. The salt generator 146 generates a cryptographic salt that is used as an input to a cryptographic function. In this case, the cryptographic salt is the root key concatenated with the unique identifier. Adding the unique identifier to the root key improves the probability that the salt is unique in the event the same root key is generated for multiple. The input to the cryptographic function for a given location in the cryptographic hierarchy is a location-specific representation concatenated with the cryptographic salt and the cryptographic key from the parent node. In the case of upper level keys, the root key 201 is used as input as a parent node. The cryptographic function is then executed a level-specific amount of iterations to generate the cryptographic key for a location. By way of example, the input provided to the cryptographic function to generate the upper key one 211 is the root key 201 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010000) for the upper key one 211). The input provided to the cryptographic function to generate the intermediate key three 223 is the upper key one 211 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010300) for the intermediate key three 223). The input provided to the cryptographic function to generate the lower key two 232 is the intermediate key three 223 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010302) for the lower key two 232).).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of BADAM into the combination of Dewan et al. and BADAM in order to create a secure hardware platform that is resilient to security attacks (See BADAM ¶ [0002]).
As to claim 28, the combination of Dewan et al. and BADAM teaches the method according to claim 25 above. However, it does not expressly teach the details of further comprising generating a second child key by: receiving, at the hardware key manager, via the third bus and from the flash storage driver, a second nonce; receiving, at the hardware key manager, via the third bus and from the flash storage driver, the identity of the base key in the base key table within the hardware key manager; and applying, by the hardware key manager, the second nonce to the base key to generate the second child key using the received identity.
BADAM, from analogous art, teaches further comprising generating a second child key by: receiving, at the hardware key manager, via the third bus and from the flash storage driver, a second nonce; receiving, at the hardware key manager, via the third bus and from the flash storage driver, the identity of the base key in the base key table within the hardware key manager; and applying, by the hardware key manager, the second nonce to the base key to generate the second child key using the received identity (See ¶¶ [0054]-[0057], [0046]-[0049], Teaches that the method 300 includes identifying a unique identifier for a computer chip with a system-on-chip design. A random identifier is burned into each processor at manufacturing. This value may not be readable by firmware or software and is directly read by the processor's hardware. In an aspect, the random identifier is a 256-bit random identifier. The random identifier may be combined with a random secret at every power up of the SoC to create a power-cycle specific unique identifier that is only valid for that power cycle. This further diversifies the keys that are generated and makes them unique every power cycle. In aspects, the unique identifier identified at step 310 may be either the random identifier burned into the processor or the power-cycle specific unique identifier. At step 330, the method 300 includes combining the unique identifier with a representation of the location to form a cryptographic salt for the cryptographic key. At step 340, the method 300 includes providing the cryptographic salt to a cryptographic function as a first part of an input. The second part of the input may be a cryptographic key associated with a parent node for the location. If an upper level key is being generated, then the root key may be used. At step 350, the method 300 includes generating, at the cryptographic function, the cryptographic key using the input. In addition, the cryptographic function may be executed a level-specific amount of iterations. At step 360, the method 300 includes using the cryptographic key to encrypt a portion of computer memory on the computer chip. The salt generator 146 generates a cryptographic salt that is used as an input to a cryptographic function. In this case, the cryptographic salt is the root key concatenated with the unique identifier. Adding the unique identifier to the root key improves the probability that the salt is unique in the event the same root key is generated for multiple. The input to the cryptographic function for a given location in the cryptographic hierarchy is a location-specific representation concatenated with the cryptographic salt and the cryptographic key from the parent node. In the case of upper level keys, the root key 201 is used as input as a parent node. The cryptographic function is then executed a level-specific amount of iterations to generate the cryptographic key for a location. By way of example, the input provided to the cryptographic function to generate the upper key one 211 is the root key 201 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010000) for the upper key one 211). The input provided to the cryptographic function to generate the intermediate key three 223 is the upper key one 211 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010300) for the intermediate key three 223). The input provided to the cryptographic function to generate the lower key two 232 is the intermediate key three 223 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010302) for the lower key two 232).).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of BADAM into the combination of Dewan et al. and BADAM in order to create a secure hardware platform that is resilient to security attacks (See BADAM ¶ [0002]).
As to claim 29, Dewan et al. teaches An apparatus comprising: and a flash storage wrapper connected to the hardware key manager and configured to: receive, via a first bus and from the hardware key manager, the first child key (See ¶¶ [0035], [0043], [0040], Teaches that Hardware key engine receives its keys from the CPU ISA 340 (as programmed by software) or from a security controller. The requested data is encrypted using the encryption keys. The encryption keys may be provided by Software 340. Software 340 supports multiple encryption keys. Software 340 may program the Keys. There may be four types of keys: (1) hardware generated, (2) hardware wrapped, (3) plaintext keys, and (4) no-encryption “key”.);
receive, via a second bus and from a flash storage driver, a memory command (See ¶¶ [0034], [0042], Teaches that NVMe drive 302 issues DMA Read Request 310 to SOC 320. When using a PCIe link between the NVMe drive 302 and the SOC 320, the Read Request 310 may adhere to the PCIe transaction layer packet (TLP) format for a read request, where the TLP header may be used to indicate a key table index and an offset to the LBA, so as to facilitate the encryption of the requested data by the Crypto Controller 322.);
and encrypt a file using the first child key and in accordance with the memory command and direct a write of the encrypted file to a location of a flash storage device, the location based on the memory command received from the flash storage driver (See ¶¶ [0043], [0046], Teaches that The requested data is encrypted using the encryption keys. The encryption keys may be provided by Software 340. Data read from memory 360 for storage on the NVMe drive 302 is encrypted by the Crypto Controller 322 before passing the read data to the NVMe drive.);
or read a file on the flash storage device, a location of the file based on the memory command received from the flash storage driver, and decrypt the file using the first child key and in accordance with the memory command (See ¶ [0046], Teaches that Encrypted data emanating from the NVMe drive 302 is decrypted by the Crypto Controller 322 before passing it to another device, e.g., to memory 360.).
However, it does not expressly teach the details of a hardware key manager configured to generate a first child key from a base key.
BADAM, from analogous art, teaches a hardware key manager configured to generate a first child key from a base key (See ¶¶ [0054]-[0057], Teaches that the method 300 includes identifying a unique identifier for a computer chip with a system-on-chip design. A random identifier is burned into each processor at manufacturing. This value may not be readable by firmware or software and is directly read by the processor's hardware. In an aspect, the random identifier is a 256-bit random identifier. The random identifier may be combined with a random secret at every power up of the SoC to create a power-cycle specific unique identifier that is only valid for that power cycle. This further diversifies the keys that are generated and makes them unique every power cycle. In aspects, the unique identifier identified at step 310 may be either the random identifier burned into the processor or the power-cycle specific unique identifier. At step 330, the method 300 includes combining the unique identifier with a representation of the location to form a cryptographic salt for the cryptographic key. At step 340, the method 300 includes providing the cryptographic salt to a cryptographic function as a first part of an input. The second part of the input may be a cryptographic key associated with a parent node for the location. If an upper level key is being generated, then the root key may be used. At step 350, the method 300 includes generating, at the cryptographic function, the cryptographic key using the input. In addition, the cryptographic function may be executed a level-specific amount of iterations. At step 360, the method 300 includes using the cryptographic key to encrypt a portion of computer memory on the computer chip.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of BADAM into Dewan et al. in order to create a secure hardware platform that is resilient to security attacks (See BADAM ¶ [0002]).
Claims 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Dewan et al. (US 20220197825 A1) and BADAM (US 20260081764 A1) and further in view of Mayer et al. (US 20180210852 A1).
As to claim 18, the combination of Dewan et al. and BADAM teaches the method according to claim 16 above. However, it does not expressly teach the details of wherein: the receiving of the first child key and the receiving of the memory command comprise receiving the first child key from an arbiter and receiving the memory command from the arbiter, respectively, the arbiter connected to the first bus and the second bus; and the method further comprises arbitrating, by the arbiter, communications between the first and second buses and a host controller interface of the flash storage wrapper.
Mayer et al., from analogous art, teaches wherein: the receiving of the first child key and the receiving of the memory command comprise receiving the first child key from an arbiter and receiving the memory command from the arbiter, respectively, the arbiter connected to the first bus and the second bus; and the method further comprises arbitrating, by the arbiter, communications between the first and second buses and a host controller interface of the flash storage wrapper (See ¶¶ [0022], [0029], Teaches that he on-chip bus protocols and the on-chip bus systems 108 and 128 can correspond respectively to the SoCs 101 and 121 with other components such as an arbitrator or interrupt service provider operable via the on-chip bus systems 108 and 128 at respective dies with system address maps to control or manage requests for resources (e.g., memory 104, peripheral components 110, or the like). In an aspect, when coupled with other SoCs (e.g., the first SoC 101), the master agents (e.g., the processor core 122) can operatively communicate based on various arbitration schemes or on-chip bus protocols throughout the system 100 for control of any of the components or resources via the transparent interface 140. The system 100 of multiple SoCs on different dices can be operable to include one or more SoCs 101, 121 and integrate these different SoCs 101, 121 with their corresponding on-chip bus protocols and components, for example. ).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Mayer et al. into the combination of Dewan et al. and BADAM in to control or manage requests for resources (e.g., memory 104, peripheral components 110, or the like) (See Mayer et al. ¶ [0022]).
As to claim 19, the combination of Dewan et al. and BADAM and Mayer et al. teaches the method according to claim 18 above. Dewan et al. further teaches wherein: the receiving of the first child key and the receiving of the memory command comprise receiving the first child key from a controller and receiving the memory command from the controller, respectively, the controller connected to the first bus and the second bus (See ¶¶ [0034], [0042], Teaches that NVMe drive 302 issues DMA Read Request 310 to SOC 320. When using a PCIe link between the NVMe drive 302 and the SOC 320, the Read Request 310 may adhere to the PCIe transaction layer packet (TLP) format for a read request, where the TLP header may be used to indicate a key table index and an offset to the LBA, so as to facilitate the encryption of the requested data by the Crypto Controller 322);
and the method further comprises: enabling, by the controller, reception of the first child key by the host controller interface of the flash storage wrapper; and preventing, by the controller, reception of a software-generated key by the host controller interface of the flash storage wrapper (See ¶¶ [0035], [0043], [0040], Teaches that Hardware key engine receives its keys from the CPU ISA 340 (as programmed by software) or from a security controller. The requested data is encrypted using the encryption keys. The encryption keys may be provided by Software 340. Software 340 supports multiple encryption keys. Software 340 may program the Keys. There may be four types of keys: (1) hardware generated, (2) hardware wrapped, (3) plaintext keys, and (4) no-encryption “key”.).
Claims 30-35 are rejected under 35 U.S.C. 103 as being unpatentable over Dewan et al. (US 20220197825 A1) and further in view of BADAM (US 20260081764 A1) and Mayer et al. (US 20180210852 A1).
As to claim 30, Dewan et al. teaches A system comprising: a first bus configured to receive communications from a hardware key manager (See ¶¶ [0035], [0043], [0040], Teaches that Hardware key engine receives its keys from the CPU ISA 340 (as programmed by software) or from a security controller. The requested data is encrypted using the encryption keys. The encryption keys may be provided by Software 340. Software 340 supports multiple encryption keys. Software 340 may program the Keys. There may be four types of keys: (1) hardware generated, (2) hardware wrapped, (3) plaintext keys, and (4) no-encryption “key”.);
a second bus configured to receive communications from a flash storage driver (See ¶¶ [0034], [0042], Teaches that NVMe drive 302 issues DMA Read Request 310 to SOC 320. When using a PCIe link between the NVMe drive 302 and the SOC 320, the Read Request 310 may adhere to the PCIe transaction layer packet (TLP) format for a read request, where the TLP header may be used to indicate a key table index and an offset to the LBA, so as to facilitate the encryption of the requested data by the Crypto Controller 322.);
and a host controller interface having a communication line connected to the output line of the arbiter, the host controller interface including a first cryptographic engine and a key table, the host controller interface configured to receive the first child key from the hardware key manager over the first bus and via the arbiter (See ¶¶ [0035], [0043], [0040], [0034], [0042], Teaches that Hardware key engine receives its keys from the CPU ISA 340 (as programmed by software) or from a security controller. The requested data is encrypted using the encryption keys. The encryption keys may be provided by Software 340. Software 340 supports multiple encryption keys. Software 340 may program the Keys. There may be four types of keys: (1) hardware generated, (2) hardware wrapped, (3) plaintext keys, and (4) no-encryption “key”. NVMe drive 302 issues DMA Read Request 310 to SOC 320. When using a PCIe link between the NVMe drive 302 and the SOC 320, the Read Request 310 may adhere to the PCIe transaction layer packet (TLP) format for a read request, where the TLP header may be used to indicate a key table index and an offset to the LBA, so as to facilitate the encryption of the requested data by the Crypto Controller 322);
and the first cryptographic engine configured to use the first child key to encrypt or decrypt a file in accordance with a memory command received from the flash storage driver over the second bus and via the arbiter (See ¶¶ [0043], [0046], Teaches that The requested data is encrypted using the encryption keys. The encryption keys may be provided by Software 340. Data read from memory 360 for storage on the NVMe drive 302 is encrypted by the Crypto Controller 322 before passing the read data to the NVMe drive. Encrypted data emanating from the NVMe drive 302 is decrypted by the Crypto Controller 322 before passing it to another device, e.g., to memory 360).
However, it does not expressly teach the details of the key table including a first child key generated by the hardware key manager; and a flash storage wrapper including: an arbiter connected to the first bus and the second bus, the arbiter having an output line.
BADAM, from analogous art, teaches the key table including a first child key generated by the hardware key manager (See ¶¶ [0054]-[0057], Teaches that the method 300 includes identifying a unique identifier for a computer chip with a system-on-chip design. A random identifier is burned into each processor at manufacturing. This value may not be readable by firmware or software and is directly read by the processor's hardware. In an aspect, the random identifier is a 256-bit random identifier. The random identifier may be combined with a random secret at every power up of the SoC to create a power-cycle specific unique identifier that is only valid for that power cycle. This further diversifies the keys that are generated and makes them unique every power cycle. In aspects, the unique identifier identified at step 310 may be either the random identifier burned into the processor or the power-cycle specific unique identifier. At step 330, the method 300 includes combining the unique identifier with a representation of the location to form a cryptographic salt for the cryptographic key. At step 340, the method 300 includes providing the cryptographic salt to a cryptographic function as a first part of an input. The second part of the input may be a cryptographic key associated with a parent node for the location. If an upper level key is being generated, then the root key may be used. At step 350, the method 300 includes generating, at the cryptographic function, the cryptographic key using the input. In addition, the cryptographic function may be executed a level-specific amount of iterations. At step 360, the method 300 includes using the cryptographic key to encrypt a portion of computer memory on the computer chip.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of BADAM into Dewan et al. in order to create a secure hardware platform that is resilient to security attacks (See BADAM ¶ [0002]).
However, it does not expressly teach the details of a flash storage wrapper including: an arbiter connected to the first bus and the second bus, the arbiter having an output line.
Mayer et al., from analogous art, teaches a flash storage wrapper including: an arbiter connected to the first bus and the second bus, the arbiter having an output line (See ¶¶ [0022], [0029], Teaches that he on-chip bus protocols and the on-chip bus systems 108 and 128 can correspond respectively to the SoCs 101 and 121 with other components such as an arbitrator or interrupt service provider operable via the on-chip bus systems 108 and 128 at respective dies with system address maps to control or manage requests for resources (e.g., memory 104, peripheral components 110, or the like). In an aspect, when coupled with other SoCs (e.g., the first SoC 101), the master agents (e.g., the processor core 122) can operatively communicate based on various arbitration schemes or on-chip bus protocols throughout the system 100 for control of any of the components or resources via the transparent interface 140. The system 100 of multiple SoCs on different dices can be operable to include one or more SoCs 101, 121 and integrate these different SoCs 101, 121 with their corresponding on-chip bus protocols and components, for example. ).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Mayer et al. into the combination of Dewan et al. and BADAM in to control or manage requests for resources (e.g., memory 104, peripheral components 110, or the like) (See Mayer et al. ¶ [0022]).
As to claim 31, the combination of Dewan et al. and BADAM and Mayer et al. teaches the system according to claim 30 above. Dewan et al. further teaches further comprising: the hardware key manager connected to the host controller interface over the first bus and via the arbiter (See ¶¶ [0035], [0043], [0040], [0034], [0042], Teaches that Hardware key engine receives its keys from the CPU ISA 340 (as programmed by software) or from a security controller. The requested data is encrypted using the encryption keys. The encryption keys may be provided by Software 340. Software 340 supports multiple encryption keys. Software 340 may program the Keys. There may be four types of keys: (1) hardware generated, (2) hardware wrapped, (3) plaintext keys, and (4) no-encryption “key”. NVMe drive 302 issues DMA Read Request 310 to SOC 320. When using a PCIe link between the NVMe drive 302 and the SOC 320, the Read Request 310 may adhere to the PCIe transaction layer packet (TLP) format for a read request, where the TLP header may be used to indicate a key table index and an offset to the LBA, so as to facilitate the encryption of the requested data by the Crypto Controller 322).
However, it does not expressly teach the details of the hardware key manager configured to generate the first child key.
BADAM, from analogous art, teaches the hardware key manager configured to generate the first child key (See ¶¶ [0054]-[0057], Teaches that the method 300 includes identifying a unique identifier for a computer chip with a system-on-chip design. A random identifier is burned into each processor at manufacturing. This value may not be readable by firmware or software and is directly read by the processor's hardware. In an aspect, the random identifier is a 256-bit random identifier. The random identifier may be combined with a random secret at every power up of the SoC to create a power-cycle specific unique identifier that is only valid for that power cycle. This further diversifies the keys that are generated and makes them unique every power cycle. In aspects, the unique identifier identified at step 310 may be either the random identifier burned into the processor or the power-cycle specific unique identifier. At step 330, the method 300 includes combining the unique identifier with a representation of the location to form a cryptographic salt for the cryptographic key. At step 340, the method 300 includes providing the cryptographic salt to a cryptographic function as a first part of an input. The second part of the input may be a cryptographic key associated with a parent node for the location. If an upper level key is being generated, then the root key may be used. At step 350, the method 300 includes generating, at the cryptographic function, the cryptographic key using the input. In addition, the cryptographic function may be executed a level-specific amount of iterations. At step 360, the method 300 includes using the cryptographic key to encrypt a portion of computer memory on the computer chip.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of BADAM into the combination of Dewan et al. and BADAM and Mayer et al. in order to create a secure hardware platform that is resilient to security attacks (See BADAM ¶ [0002]).
As to claim 32, the combination of Dewan et al. and BADAM and Mayer et al. teaches the system according to claim 31 above. Dewan et al. further teaches wherein: the flash storage wrapper includes a controller connected to the first bus and the second bus; (See ¶¶ [0035], [0043], [0040], [0034], [0042], Teaches that Hardware key engine receives its keys from the CPU ISA 340 (as programmed by software) or from a security controller. The requested data is encrypted using the encryption keys. The encryption keys may be provided by Software 340. Software 340 supports multiple encryption keys. Software 340 may program the Keys. There may be four types of keys: (1) hardware generated, (2) hardware wrapped, (3) plaintext keys, and (4) no-encryption “key”. NVMe drive 302 issues DMA Read Request 310 to SOC 320. When using a PCIe link between the NVMe drive 302 and the SOC 320, the Read Request 310 may adhere to the PCIe transaction layer packet (TLP) format for a read request, where the TLP header may be used to indicate a key table index and an offset to the LBA, so as to facilitate the encryption of the requested data by the Crypto Controller 322).
However, it does not expressly teach the details of the arbiter is connected between the controller and the host controller interface.
Mayer et al., from analogous art, teaches the arbiter is connected between the controller and the host controller interface (See ¶¶ [0022], [0029], Teaches that he on-chip bus protocols and the on-chip bus systems 108 and 128 can correspond respectively to the SoCs 101 and 121 with other components such as an arbitrator or interrupt service provider operable via the on-chip bus systems 108 and 128 at respective dies with system address maps to control or manage requests for resources (e.g., memory 104, peripheral components 110, or the like). In an aspect, when coupled with other SoCs (e.g., the first SoC 101), the master agents (e.g., the processor core 122) can operatively communicate based on various arbitration schemes or on-chip bus protocols throughout the system 100 for control of any of the components or resources via the transparent interface 140. The system 100 of multiple SoCs on different dices can be operable to include one or more SoCs 101, 121 and integrate these different SoCs 101, 121 with their corresponding on-chip bus protocols and components, for example. ).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Mayer et al. into the combination of Dewan et al. and BADAM and Mayer et al. in to control or manage requests for resources (e.g., memory 104, peripheral components 110, or the like) (See Mayer et al. ¶ [0022]).
As to claim 33, the combination of Dewan et al. and BADAM and Mayer et al. teaches the system according to claim 32 above. Dewan et al. further teaches wherein the controller is configured to: allow the first child key to be communicated to the host controller interface; and prevent a software-generated key from being communicated to the host controller interface (See ¶¶ [0035], [0043], [0040], Teaches that Hardware key engine receives its keys from the CPU ISA 340 (as programmed by software) or from a security controller. The requested data is encrypted using the encryption keys. The encryption keys may be provided by Software 340. Software 340 supports multiple encryption keys. Software 340 may program the Keys. There may be four types of keys: (1) hardware generated, (2) hardware wrapped, (3) plaintext keys, and (4) no-encryption “key”.).
As to claim 34, the combination of Dewan et al. and BADAM and Mayer et al. teaches the system according to claim 31 above. Dewan et al. further teaches wherein: the hardware key manager includes a second cryptographic engine and a base key table (See ¶¶ [0037], [0042], [0044], Teaches that Memory circuitry 327 may store one or more instructions to cause the one or more processor circuitries (not shown) in Crypto Controller 322 to execute a plurality of desired tasks. The tasks include, for example, receipt and storing of cryptographic information required to encrypt or decrypt data, forming data and/or key tables and communicating encrypted or decrypted data with components external to the SOC 320. Once formed, such tables may be stored at Key Lookup Table (KLT) 326. In one embodiment, the Crypto Memory Circuitry 327 may include KLT 326. In another embodiment the KLT 326 may be in DRAM 360 and the memory 327 inside the crypto controller may serve as a cache. During an exemplary implementation NVMe driver (e.g., SSD) 302 transmits a read request 310 to SOC 320. Read Request 310 may not be encrypted. In an optional embodiment, a portion of the Read Request 310 may be encrypted. Read Request 310 contains a key table index (or key lookup index) and optionally further an offset to the LBA which allow the Crypto Controller 322 identifying one or more encryption of the requested data. When using a PCIe link between the NVMe drive 302 and the SOC 320, the Read Request 310 may adhere to the PCIe transaction layer packet (TLP) format for a read request, where the TLP header may be used to indicate a key table index and an offset to the LBA, so as to facilitate the encryption of the requested data by the Crypto Controller 322. An embodiment uses the TLP Prefix in the header of a TLP packet to send the key table index and the offset value. In another embodiment, some of the address bits in the header of Read Request 310 (and Write Request 370 described herein below) may be used to indicate the key table index and an offset to the LBA. In the PCIe context, the address bits may be comprised in the TLP header. An example is outlined in connection with FIG. 11 below. The Read Request 310 and Write Request 370 may be DMA requests that can have 64 bits of address information. The address information can be one of the following three information: physical address, Guest Physical Address, or IO Virtual Address. A number of the available address bits may be used to index a table of 4K entries with 8 bytes per entry (i.e., 32 K byte table). The remaining available bits may be used for offset to the base LBA in the table.).
However, it does not expressly teach the details of the hardware key manager is configured to apply a nonce to a base key in the base key table to generate the first child key.
BADAM, from analogous art, teaches the hardware key manager is configured to apply a nonce to a base key in the base key table to generate the first child key (See ¶¶ [0054]-[0057], [0046]-[0049], Teaches that the method 300 includes identifying a unique identifier for a computer chip with a system-on-chip design. A random identifier is burned into each processor at manufacturing. This value may not be readable by firmware or software and is directly read by the processor's hardware. In an aspect, the random identifier is a 256-bit random identifier. The random identifier may be combined with a random secret at every power up of the SoC to create a power-cycle specific unique identifier that is only valid for that power cycle. This further diversifies the keys that are generated and makes them unique every power cycle. In aspects, the unique identifier identified at step 310 may be either the random identifier burned into the processor or the power-cycle specific unique identifier. At step 330, the method 300 includes combining the unique identifier with a representation of the location to form a cryptographic salt for the cryptographic key. At step 340, the method 300 includes providing the cryptographic salt to a cryptographic function as a first part of an input. The second part of the input may be a cryptographic key associated with a parent node for the location. If an upper level key is being generated, then the root key may be used. At step 350, the method 300 includes generating, at the cryptographic function, the cryptographic key using the input. In addition, the cryptographic function may be executed a level-specific amount of iterations. At step 360, the method 300 includes using the cryptographic key to encrypt a portion of computer memory on the computer chip. The salt generator 146 generates a cryptographic salt that is used as an input to a cryptographic function. In this case, the cryptographic salt is the root key concatenated with the unique identifier. Adding the unique identifier to the root key improves the probability that the salt is unique in the event the same root key is generated for multiple. The input to the cryptographic function for a given location in the cryptographic hierarchy is a location-specific representation concatenated with the cryptographic salt and the cryptographic key from the parent node. In the case of upper level keys, the root key 201 is used as input as a parent node. The cryptographic function is then executed a level-specific amount of iterations to generate the cryptographic key for a location. By way of example, the input provided to the cryptographic function to generate the upper key one 211 is the root key 201 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010000) for the upper key one 211). The input provided to the cryptographic function to generate the intermediate key three 223 is the upper key one 211 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010300) for the intermediate key three 223). The input provided to the cryptographic function to generate the lower key two 232 is the intermediate key three 223 and the salt (e.g., unique identifier concatenated with a location representation (e.g., 010302) for the lower key two 232).).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of BADAM into the combination of Dewan et al. and BADAM and Mayer et al. in order to create a secure hardware platform that is resilient to security attacks (See BADAM ¶ [0002]).
As to claim 35, the combination of Dewan et al. and BADAM and Mayer et al. teaches the system according to claim 30 above. However, it does not expressly teach the details of wherein: the flash storage wrapper includes a configuration interface connected between the output line of the arbiter and the communication line of the host controller interface; and the arbiter is configured to arbitrate communication with the configuration interface between the first bus and the second bus.
Mayer et al., from analogous art, teaches wherein: the flash storage wrapper includes a configuration interface connected between the output line of the arbiter and the communication line of the host controller interface; and the arbiter is configured to arbitrate communication with the configuration interface between the first bus and the second bus (See ¶¶ [0022], [0029], Teaches that he on-chip bus protocols and the on-chip bus systems 108 and 128 can correspond respectively to the SoCs 101 and 121 with other components such as an arbitrator or interrupt service provider operable via the on-chip bus systems 108 and 128 at respective dies with system address maps to control or manage requests for resources (e.g., memory 104, peripheral components 110, or the like). In an aspect, when coupled with other SoCs (e.g., the first SoC 101), the master agents (e.g., the processor core 122) can operatively communicate based on various arbitration schemes or on-chip bus protocols throughout the system 100 for control of any of the components or resources via the transparent interface 140. The system 100 of multiple SoCs on different dices can be operable to include one or more SoCs 101, 121 and integrate these different SoCs 101, 121 with their corresponding on-chip bus protocols and components, for example. ).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Mayer et al. into the combination of Dewan et al. and BADAM and Mayer et al. in to control or manage requests for resources (e.g., memory 104, peripheral components 110, or the like) (See Mayer et al. ¶ [0022]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Shacham (US 20140310536 A1) teaches Various features pertain to inline encryption and decryption. In one aspect, inline read/write operations are performed by configuring an off-chip storage device to provide parameters to facilitate inline encryption/decryption of data by a host storage controller of a system-on-a-chip (SoC.) The parameters provided by the storage device to the host storage controller include an identifier that is the same for read and write operations for a particular block of data but differs from one block of data to another. The host storage controller employs the parameters as initial vectors to generate encryption keys for use in encrypting/decrypting data. Exemplary read and write operations of the host storage controller and the off-chip storage device are described herein. Examples are also described wherein the parameters are obtained from host memory rather than from the storage device.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to James R Hollister whose telephone number is (571)270-3152. The examiner can normally be reached Mon - Fri 7:30 am - 4:00 pm.
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, Philip Chea can be reached at (571) 272-3951. 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.
James Hollister
/J.R.H./Examiner, Art Unit 2499 9/12/26
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights