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 .
Claim Objections
Claim 32 objected to because of the following informalities:
Claim 32, lines 1-2 recite “The method claim 19, wherein the memory encryption processing unit includes a hardware private key:” which should be changed to “The method of claim 19, wherein the memory encryption processing unit includes a hardware private key, further comprising:”
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“… memory encryption processing unit configured to establish an authenticated-encrypted data stream” in claim 1.
“… the host encryption processing unit configured to establish the authenticated-encrypted data stream” in claim 2.
“… memory encryption processing unit configured to, upon determining … execute the mutual authentication protocol …” in claim 11.
“… memory encryption processing unit is further configured to read data … and send the data …” in claim 12.
“… memory encryption processing unit is further configured to decrypt the data …” in claim 13.
“… memory encryption processing unit is further configured to: receive data … decrypt the data … save the data …” in claim 14.
“… memory encryption processing unit is further configured to: receive a math command … read … data, decrypt the … data. Execute the math operation on the… data” in claim 16.
“… memory encryption processing unit is further configured to … send … output data stream” in claim 17.
“establishing, via a memory encryption processing unit… data stream … with a host encryption processing unit by executing a mutual authentication protocol” in claim 19.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 2-6 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.
Claim limitations “memory encryption processing unit” and “host encryption processing unit” invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification discloses the following:
Paragraph 77, “Host computing device 230 may be similar to host computing device 202, with the exception that host computing device 230 includes a host encryption processing unit 232. Host encryption processing unit 232 may include much of the functionality described with respect to host encryption processing unit 208. with the inclusion of a root of trust (RoT) 234. RoT 234 includes cryptographic keys rooted in the hardware of a device that help the device establish a unique identity. In some examples, RoT 234 may include a hardware private key. In some examples, RoT 234 may perform data encryption and decryption, certificate validation and key management. In some examples. RoT 234 may include a hardware RoT, silicon-based RoT, a programmable RoT, or a combination thereof.”
While the cited paragraph 77 discloses the host encryption processing unit including a root of trust, where the root of trust may include a hardware root of trust, it does not disclose the specific structure of the host encryption processing unit or the root of trust beyond the root of trust’s inclusion of a root of trust based in hardware, making it unclear as to what the host encryption processing unit is defined to be.
Therefore, claim 2, which is reliant on this limitation is indefinite and rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claims 3-6, are additionally rejected under 112(b) by virtue of dependency on claim 2.
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.
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.
Claim(s) 1-2, 4-5, 7, 12-14, 19, and 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lal (US-20240036733-A1), in further view of Kakaiya (US-20240089239-A1), in further view of SPDM v1.1.0 (“Security Protocol and Data Model (SPDM) Specification,” 2020-07-15).
Regarding claim 1, Lal teaches a processing system comprising: a memory device including a destination memory in communication with a memory encryption processing unit, (Fig. 9 shows an acceleration server platform 904 that includes an HW accelerator device 950, with device memory 955. device memory 955 is in communication with CE 954. Paragraph 163, "… a cryptographic engine (CE) 954… "interpreted as a memory encryption processing unit. Paragraph 178. "The CE 954 of the HW accelerator device 950 can decrypt any incoming data received at remote NIC 960 and compute a running MAC as data is written into device memory 955. When the transfer is complete, the CE 954 finalizes the MAC and verifies it." CE 954 in addition to remote NIC 960 is the memory encryption processing unit. The memory device is the acceleration server platform 904.).
wherein the memory [device] is configured to establish an authenticated-encrypted data stream with a host encryption processing unit via a communications channel … (Paragraph 167, "In implementations herein, the CE 916 may apply a cryptographic algorithm, such as AES GCM, to encrypt and integrity protect the application's 912 data." Paragraph 168, "On the accelerator server platform 904 side, the corresponding CE 954 of the HW accelerator device 950 can decrypt the data and verify the integrity of the transfer including the order of data transfer. The CE 954 also verifies that the destination address is not modified by computing the hash of the address and comparing that with the hash that is included with the data." Paragraph 214, "In Example 5, the subject matter of any one of Examples 1-4 can optionally include wherein the data is received via a data communication channel that is an integrity-protected data channel between the hardware accelerator device and an application server platform, the data communication channel established via an attestation and key exchange protocol" AES GCM is interpreted as an authenticated-encrypted data stream over a channel establishing these keys, where the accelerator establishes the communications channel.).
However, Lal does not explicitly teach wherein the memory encryption processing unit is configured to establish … communication channel … by executing a mutual authentication protocol to establish a symmetric session key.
Kakaiya teaches wherein the memory encryption processing unit is configured to establish … communication channel … (Paragraph 42, “FIG. 3 illustrates an example scheme 300. In some examples, scheme 300 is a way to establish a secure session between TEE 116 at compute server 110 with accelerator 136 at service server 130 via programming of session keys to a key table maintained at accelerator 136.” Paragraph 52, “In some examples, at 3.10, key logic 222 of circuitry 137 programs a key table to include the session key provided by decryption logic 226.” Fig. 3 shows a host encryption processing unit 117 and memory encryption processing unit 137 establishing a session key between themselves with steps 3.3 to 3.10 (3.5 shows the providing of a session key, and 3.9 shows the session key being provided for programming the key table 222), after the authentication steps of 3.1 and 3.2.).
… by executing a mutual authentication protocol to establish a symmetric session key. (Paragraph 52, "As described more below, subsequent work requests originating from TEE 116 can indicate that index value to facilitate retrieval of the session key from the key table and then use the retrieved session key for decrypting/encrypting data received from or to be sent to TEE 116." Fig. 3, item 3.1 shows authentication between a first and second cryptographic module. Paragraph 43, "According to some examples, at 3.1, authentication logic 210 of circuitry 117 can be capable of using various specifications to include, but not limited to, a Distributed Management Task Force (DMTF) Secure Protocol and Data Model (SPDM) specification such as the SPDM specification, DSP0274, Ver. 1.0.1, published in March, 2021 by the Platform Management Components Intercommunication (PMCI) working group of the DMTF (hereinafter “the SPDM specification”) to acquire authentication information from/about accelerator 136. " The session key is interpreted as symmetric (it is used for encrypting and decrypting data), and this key has its establishment done after the authentication protocol is done. Fig. 3 shows a compute server with circuitry 117, the host encryption processing unit, and a circuitry 137, interpreted as a memory encryption processing unit.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal’s RDMA system with Kakaiya by enhancing Lal’s devices that are used to form an encrypted channel to additionally use an authentication protocol for performing a key exchange, where specifically the processing circuitry inside of the accelerator is configured to establish the mutually authenticated session, as taught by Kakaiya. The motivation is to ensure the memory a user is attempting to establish an RDMA session with is indeed the memory the user intended to access, with the session establishment best being done by the accelerator’s processing components that will perform the encryption, decryption and authentication, ensuring that the encrypted session has strong authentication and encryption.
However, Kakaiya does not teach … mutual authentication protocol …
SPDM v1.1.0 teaches … mutual authentication protocol … (Page 21 item 95 shows an SPDM session where a mutual authentication is performed.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal in view of Kakaiya’s RDMA system with SPDM v1.1.0, by enhancing Lal in view of Kakaiya’s SPDM version to be a version that supports mutual authentication, as taught by SPDM v1.1.0. The motivation is to authenticate requests to establish a session with the cryptographic module, protecting the RDMA memory handling system from malicious access requests.
Regarding claim 2, Lal in view of Kakaiya, in further view of SPDM v1.1.0, teaches The processing system of claim 1. Lal teaches further comprising:
host computing device including the host encryption processing unit, the host encryption processing unit being in communication with the memory encryption processing unit, (Paragraph 167, "In implementations herein, the CE 916 may apply a cryptographic algorithm, such as AES GCM, to encrypt and integrity protect the application's 912 data. In one implementation, a message authenticate code (MAC) is generated over the entire block of data being transferred to minimize overhead from integrity verification." Paragraph 168, "On the accelerator server platform 904 side, the corresponding CE 954 of the HW accelerator device 950 can decrypt the data and verify the integrity of the transfer including the order of data transfer. ").
wherein the host encryption processing unit is configured to establish the authenticated-encrypted data stream in conjunction with the memory [device]. (Paragraph 167, "In implementations herein, the CE 916 may apply a cryptographic algorithm, such as AES GCM, to encrypt and integrity protect the application's 912 data." Paragraph 168, "On the accelerator server platform 904 side, the corresponding CE 954 of the HW accelerator device 950 can decrypt the data and verify the integrity of the transfer including the order of data transfer. The CE 954 also verifies that the destination address is not modified by computing the hash of the address and comparing that with the hash that is included with the data." Paragraph 214, "In Example 5, the subject matter of any one of Examples 1-4 can optionally include wherein the data is received via a data communication channel that is an integrity-protected data channel between the hardware accelerator device and an application server platform, the data communication channel established via an attestation and key exchange protocol" AES GCM is interpreted as an authenticated-encrypted data stream over a channel establishing these keys.).
Kakaiya teaches wherein the host encryption processing unit is configured to establish the … data stream in conjunction with the memory encryption processing unit. (Paragraph 42, “FIG. 3 illustrates an example scheme 300. In some examples, scheme 300 is a way to establish a secure session between TEE 116 at compute server 110 with accelerator 136 at service server 130 via programming of session keys to a key table maintained at accelerator 136.” Paragraph 52, "As described more below, subsequent work requests originating from TEE 116 can indicate that index value to facilitate retrieval of the session key from the key table and then use the retrieved session key for decrypting/encrypting data received from or to be sent to TEE 116." Fig. 3, item 3.1 shows authentication between a first and second cryptographic module. Paragraph 43, "According to some examples, at 3.1, authentication logic 210 of circuitry 117 can be capable of using various specifications to include, but not limited to, a Distributed Management Task Force (DMTF) Secure Protocol and Data Model (SPDM) specification such as the SPDM specification, DSP0274, Ver. 1.0.1, published in March, 2021 by the Platform Management Components Intercommunication (PMCI) working group of the DMTF (hereinafter “the SPDM specification”) to acquire authentication information from/about accelerator 136. " The session key is interpreted as symmetric (it is used for encrypting and decrypting data), and this key has its establishment done after the authentication protocol is done. Fig. 3 shows a compute server with circuitry 117, the host encryption processing unit, and a circuitry 137, interpreted as a memory encryption processing unit.).
The motivation to combine Lal with Kakaiya is the same as in claim 1.
Regarding claim 4, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches the processing system of claim 2. Lal teaches … the memory encryption processing unit… (Paragraph 132, “The terms “logic”, “module”, “component”, “engine”, “circuitry”, “element”, and “mechanism” may include, by way of example, software, hardware and/or a combination thereof, such as firmware.” Paragraph 178, "The CE 954 of the HW accelerator device 950 can decrypt any incoming data received at remote NIC 960 and compute a running MAC as data is written into device memory 955. When the transfer is complete, the CE 954 finalizes the MAC and verifies it." CE 954 is the memory encryption processing unit.).
However, Lal does not teach wherein the … encryption processing unit comprises a data parallel processor.
Kakaiya teaches wherein the … encryption processing unit comprises a data parallel processor. (Paragraph 36, “Also, circuitry 137 of accelerator 136 can include an FPGA, ASIC or one or more cores of a CPU resident on accelerator 136 and hosted by service server 130.” Fig. 2, accelerator 136 shows Auth Logic, encryption logic, and decryption logic, circuitry 137 is interpreted as the data parallel processor.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal’s RDMA system with Kakaiya by enhancing Lal’s cryptographic engine to be a processor that can handle multiple types of processing logics, as taught by Kakaiya. The motivation is to enhance Lal’s cryptographic engine to be able to perform dedicated authentication protocols alongside encryption, so to strengthen the RDMA system’s overall channel security.
Regarding claim 5, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches the processing system of claim 4. Lal teaches wherein the … processor includes a … processing element operable to … receive data using the authenticated-encrypted data stream to the host encryption processing unit … (Paragraph 168, "On the accelerator server platform 904 side, the corresponding CE 954 of the HW accelerator device 950 can decrypt the data and verify the integrity of the transfer including the order of data transfer. The CE 954 also verifies that the destination address is not modified by computing the hash of the address and comparing that with the hash that is included with the data." The HW accelerator device decrypts data checks that the data is authentic, the data coming from the host encryption processing unit 910 with CE 916.).
Lal doesn’t explicitly teach that the the data parallel processor includes a first processing element operable to send … data using the … data stream to the host encryption processing unit and a second processing element.
Kakaiya teaches a system where the data parallel processor includes a first processing element operable to send … data using the … data stream to the host encryption processing unit and a second processing element. (Paragraph 52, "As described more below, subsequent work requests originating from TEE 116 can indicate that index value to facilitate retrieval of the session key from the key table and then use the retrieved session key for decrypting/encrypting data received from or to be sent to TEE 116. " Paragraph 77, " According to some examples, at 8.1, encrypted data with HMAC is sent from output buffer(s) 233 at service server 130. For these examples, the encrypted data can include data operated on by accelerator 136 that was encrypted based on a session key that was obtained based on a key table as described above for scheme 300 or scheme 500." Paragraph 83, "[0083] According to some examples, similar to as mentioned above for write flow 700, decryption logic 216 uses AES algorithms to decrypt data. … Alternatively, use of an AES-GCM algorithm would have built-in HMAC functionality and integrity logic 218 would not need to generate an HMAC value and read flow 800 would be modified to have decryption logic 216 pull the encrypted data from input buffer(s) 211, and based on a successful decryption is able to verify the integrity of the encrypted data." The decryption logic 216 is part of the host encryption processing unit. Fig. 2 shows encryption and decryption logic 224 and 226, interpreted as the first processing element, and auth logic 220, interpreted as the second processing element.).
The motivation to combine Lal with Kakaiya is the same as in claim 4.
Regarding claim 7, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches the processing system of claim 1. Lal teaches wherein the authenticated-encrypted data stream uses AES-GCM encryption. and the memory encryption processing unit comprises an AES-GCM endpoint (Paragraph 167-168, "In implementations herein, the CE 916 may apply a cryptographic algorithm, such as AES GCM, to encrypt and integrity protect the application's 912 data. … On the accelerator server platform 904 side, the corresponding CE 954 of the HW accelerator device 950 can decrypt the data and verify the integrity of the transfer including the order of data transfer. The CE 954 also verifies that the destination address is not modified by computing the hash of the address and comparing that with the hash that is included with the data." AES-GCM is used for encryption, with the HW accelerator device's CE 954 decrypting the AES-GCM encrypted data.).
Regarding claim 12, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches the processing system of claim 1. However, Lal does not explicitly teach wherein the memory encryption processing unit is further configured to read data from the destination memory and send the data via the authenticated-encrypted data stream to the host encryption processing unit.
Kakaiya teaches wherein the memory encryption processing unit is further configured to read data from the destination memory and send the data via the authenticated-encrypted data stream to the host encryption processing unit. (Paragraph 37, "In some example, the one or more storage devices included in storage array 140 can include volatile or non-volatile types of memory.” Paragraph 111-112, "FIG. 12 illustrates an example read flow 1200 at accelerator 136 at service server 130. … In some examples, read flow 1200 is for reading data from one or more storage devices (e.g., of storage array 140) based on a request originating from TEE 116 at compute server 110. Read flow 1200 assumes that a secure session has been established between TEE 116 and accelerator 136…" Paragraph 83, "According to some examples, similar to as mentioned above for write flow 700, decryption logic 216 uses AES algorithms to decrypt data. … Alternatively, use of an AES-GCM algorithm would have built-in HMAC functionality and integrity logic 218 would not need to generate an HMAC value and read flow 800 would be modified to have decryption logic 216 pull the encrypted data from input buffer(s) 211, and based on a successful decryption is able to verify the integrity of the encrypted data." " Paragraph 77-78, "According to some examples, at 8.1, encrypted data with HMAC is sent from output buffer(s) 233 at service server 130. For these examples, the encrypted data can include data operated on by accelerator 136 that was encrypted based on a session key that was obtained based on a key table as described above for scheme 300 or scheme 500. Logic and/or features of circuitry 137 or accelerator 136 could have also generated the HMAC that accompanies the encrypted data sent from output buffer(s) 233 to input buffer(s) 211. In some examples, at 8.2, integrity logic 218 obtains or receives the encrypted data with HMAC." the reading data is interpreted from destination memory is seen as reading data from the storage array 140, where it then encrypted and sent over to the host encryption processing unit to decrypt as shown in figure 8. AES-GCM is used, meaning that it is an authenticated-encrypted data stream.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal’s RDMA system with Kakaiya by enhancing Lal’s RDMA system to encrypt memory data using a negotiated session key prior to transmitting it to the requesting device, as taught by Kakaiya. The motivation is to protect RDMA traffic from being snooped on when traveling between the memory device and requesting device.
Regarding claim 13, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches The processing system of claim 12. Kakaiya teaches wherein the data comprises trusted compute encrypted data (Paragraph 34, "At least some elements or components utilized by TEE(s) 116 to access storage array 140 to include, but not limited to, host OS/VMM 112, fabric 120, service 132 and storage array 140 are considered as untrusted and confidential data associated with TEE(s) 116's access to storage array 140 needs to be encrypted as it passes to/from storage array 140 in order to maintain confidentiality." The data in the storage array is interpreted as trusted compute encrypted data.)
and the memory encryption processing unit is further configured to decrypt the data read from the destination memory before the data is sent to the host encryption processing unit via the authenticated-encrypted data stream (Paragraph 111-112, "FIG. 12 illustrates an example read flow 1200 at accelerator 136 at service server 130. … In some examples, read flow 1200 is for reading data from one or more storage devices (e.g., of storage array 140) based on a request originating from TEE 116 at compute server 110. Read flow 1200 assumes that a secure session has been established between TEE 116 and accelerator 136 as described above for scheme 300 or 500 and that the encrypted data was sent to input buffer(s) 231 at service server 130 in a similar manner as described above for read flow 800 shown in FIG. 8." Paragraph 122, "In some examples, at 12.10, integrity logic 228 generates a CRC value based on the transformed (e.g., decompressed) data and compare the generated CRC value to the CRC value that was provided by decryption logic 226 to verify that the clear text data has not been altered or corrupted from its original state. For example, the transformed (e.g., decompressed) data, if verified will be lossless and not altered or corrupted due to bit errors generated when reading the encrypted data from the storage device or following compression transformations and/or encryption (e.g., described in flow 1000) of the data prior to being written to the storage device." The destination memory/storage device has its data decrypted before it is encrypted and sent to the host encryption processing unit as seen with Fig. 12's combination with Fig. 8.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal’s RDMA system with Kakaiya by enhancing Lal’s RDMA system to store memory data at rest in an encrypted state, as taught by Kakaiya. The motivation is to protect the data being stored in the memory from being accessible if somebody simply gains physical access to the memory storage device.
Regarding claim 14, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches the processing system of claim 1. Lal teaches wherein the memory encryption processing unit is further configured to: receive data from the host encryption processing unit via the authenticated-encrypted data stream, (Paragraphs 167-168, "In implementations herein, the CE 916 may apply a cryptographic algorithm, such as AES GCM, to encrypt and integrity protect the application's 912 data. … On the accelerator server platform 904 side, the corresponding CE 954 of the HW accelerator device 950 can decrypt the data and verify the integrity of the transfer including the order of data transfer. The CE 954 also verifies that the destination address is not modified by computing the hash of the address and comparing that with the hash that is included with the data." The AES GCM data stream is decrypted by the HW accelerator after being received from CE 916 of the host encryption processing unit.)
decrypt the data received from the host encryption processing unit using the symmetric session key, and save the data in the destination memory. (Paragraph 178, "The CE 954 of the HW accelerator device 950 can decrypt any incoming data received at remote NIC 960 and compute a running MAC as data is written into device memory 955. When the transfer is complete, the CE 954 finalizes the MAC and verifies it." The decryption is done using the AES-GCM session key, where the writing is interpreted as saving in destination memory.).
Regarding claim 19, Lal teaches a method comprising: establishing, via a memory [device], an authenticated-encrypted data stream via a communications channel with a host encryption processing unit [key exchange protocol] to establish a symmetric session key, wherein the (Paragraph 167, "In implementations herein, the CE 916 may apply a cryptographic algorithm, such as AES GCM, to encrypt and integrity protect the application's 912 data." Paragraph 168, "On the accelerator server platform 904 side, the corresponding CE 954 of the HW accelerator device 950 can decrypt the data and verify the integrity of the transfer including the order of data transfer. The CE 954 also verifies that the destination address is not modified by computing the hash of the address and comparing that with the hash that is included with the data." Paragraph 214, "In Example 5, the subject matter of any one of Examples 1-4 can optionally include wherein the data is received via a data communication channel that is an integrity-protected data channel between the hardware accelerator device and an application server platform, the data communication channel established via an attestation and key exchange protocol" AES GCM is interpreted as an authenticated-encrypted data stream over a channel establishing these keys. The memory device is interpreted as the acceleration server platform 904.).
memory encryption processing unit is part of a memory device including a destination memory in communication with the memory encryption processing unit. (Fig. 9 shows an acceleration server platform 904 that includes an HW accelerator device 950, with device memory 955. device memory 955 is in communication with CE 954. Paragraph 163, "… a cryptographic engine (CE) 954… "interpreted as a memory encryption processing unit. Paragraph 178. "The CE 954 of the HW accelerator device 950 can decrypt any incoming data received at remote NIC 960 and compute a running MAC as data is written into device memory 955. When the transfer is complete, the CE 954 finalizes the MAC and verifies it." CE 954 is the memory encryption processing unit.).
However, Lal does not teach establishing, via a memory encryption processing unit, an [encrypted] data stream via a communications channel … by executing a[n] … authentication protocol to establish a symmetric session key …
Kakaiya teaches establishing, via a memory encryption processing unit, an [encrypted] data stream via a communications channel … (Paragraph 42, “FIG. 3 illustrates an example scheme 300. In some examples, scheme 300 is a way to establish a secure session between TEE 116 at compute server 110 with accelerator 136 at service server 130 via programming of session keys to a key table maintained at accelerator 136.” Paragraph 52, “In some examples, at 3.10, key logic 222 of circuitry 137 programs a key table to include the session key provided by decryption logic 226.” Fig. 3 shows a host encryption processing unit 117 and memory encryption processing unit 137 establishing a session key between themselves with steps 3.3 to 3.10 (3.5 shows the providing of a session key, and 3.9 shows the session key being provided for programming the key table 222), after the authentication steps of 3.1 and 3.2.).
… by executing a[n] … authentication protocol to establish a symmetric session key … (Paragraph 52, "As described more below, subsequent work requests originating from TEE 116 can indicate that index value to facilitate retrieval of the session key from the key table and then use the retrieved session key for decrypting/encrypting data received from or to be sent to TEE 116." Fig. 3, item 3.1 shows authentication between the first and second cryptographic module. Paragraph 43, "According to some examples, at 3.1, authentication logic 210 of circuitry 117 can be capable of using various specifications to include, but not limited to, a Distributed Management Task Force (DMTF) Secure Protocol and Data Model (SPDM) specification such as the SPDM specification, DSP0274, Ver. 1.0.1, published in March, 2021 by the Platform Management Components Intercommunication (PMCI) working group of the DMTF (hereinafter “the SPDM specification”) to acquire authentication information from/about accelerator 136. " The session key is interpreted as symmetric (it is used for encrypting and decrypting data), and this key has its establishment done after the authentication protocol is done. Fig. 3 shows a compute server with circuitry 117, the host encryption processing unit, and a circuitry 137, interpreted as a memory encryption processing unit.). Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal’s RDMA system with Kakaiya by enhancing Lal’s devices that are used to form an encrypted channel to additionally use an authentication protocol for performing a key exchange, as taught by Kakaiya. The motivation is to ensure the memory a user is attempting to establish an RDMA session with is indeed the memory the user intended to access.
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal’s RDMA system with Kakaiya by enhancing Lal’s devices that are used to form an encrypted channel to additionally use an authentication protocol for performing a key exchange, where specifically the processing circuitry inside of the accelerator is configured to establish the mutually authenticated session, as taught by Kakaiya. The motivation is to ensure the memory a user is attempting to establish an RDMA session with is indeed the memory the user intended to access, with the session establishment best being done by the accelerator’s processing components that will perform the encryption, decryption and authentication, ensuring that the encrypted session has strong authentication and encryption.
However, Kakaiya does not teach … mutual authentication protocol …
SPDM v1.1.0 teaches … mutual authentication protocol … (Page 21 item 95 shows an SPDM session where a mutual authentication is performed.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal in view of Kakaiya’s RDMA system with SPDM v1.1.0, by enhancing Lal in view of Kakaiya’s SPDM version to be a version that supports mutual authentication, as taught by SPDM v1.1.0. The motivation is to authenticate requests to establish a session with the cryptographic module, protecting the RDMA memory handling system from malicious access requests.
Regarding claim 30, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches the method of claim 19. Lal teaches further comprising: reading, via the memory encryption processing unit, data from the destination memory; (Fig. 9 shows the memory connected to CE 954 and, where the NIC is connected to the memory through the CE. Paragraph 150, " Another characteristic of RDMA is that the NIC processing the RDMA work (i.e., the initiator of RDMA) requests access to memory to the remote NIC through the RDMA protocol. The remote RNIC can access the remote memory in response without utilizing processing by the CPU (or other controller or processor) of the remote platform.").
However, Lal does not explicitly teach sending the data via the authenticated-encrypted data stream to the host encryption processing unit.
Kakaiya teaches sending the data via the authenticated-encrypted data stream to the host encryption processing unit. (Paragraph 111-112, "FIG. 12 illustrates an example read flow 1200 at accelerator 136 at service server 130. … In some examples, read flow 1200 is for reading data from one or more storage devices (e.g., of storage array 140) based on a request originating from TEE 116 at compute server 110. Read flow 1200 assumes that a secure session has been established between TEE 116 and accelerator 136 as described above for scheme 300 or 500 and that the encrypted data was sent to input buffer(s) 231 at service server 130 in a similar manner as described above for read flow 800 shown in FIG. 8." Paragraph 83, "According to some examples, similar to as mentioned above for write flow 700, decryption logic 216 uses AES algorithms to decrypt data. … Alternatively, use of an AES-GCM algorithm would have built-in HMAC functionality and integrity logic 218 would not need to generate an HMAC value and read flow 800 would be modified to have decryption logic 216 pull the encrypted data from input buffer(s) 211, and based on a successful decryption is able to verify the integrity of the encrypted data." Paragraph 37, "In some examples, the one or more storage devices included in storage array 140 can include volatile or non-volatile types of memory." Paragraph 77-78, "According to some examples, at 8.1, encrypted data with HMAC is sent from output buffer(s) 233 at service server 130. For these examples, the encrypted data can include data operated on by accelerator 136 that was encrypted based on a session key that was obtained based on a key table as described above for scheme 300 or scheme 500. Logic and/or features of circuitry 137 or accelerator 136 could have also generated the HMAC that accompanies the encrypted data sent from output buffer(s) 233 to input buffer(s) 211. In some examples, at 8.2, integrity logic 218 obtains or receives the encrypted data with HMAC." the reading data is interpreted from destination memory is seen as reading data from the storage array 140, where it then encrypted and sent over to the host encryption processing unit to decrypt as shown in figure 8. AES-GCM is used, meaning that it is an authenticated-encrypted data stream.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal’s RDMA system with Kakaiya by enhancing Lal’s RDMA system to encrypt memory data using a negotiated session key prior to transmitting it to the requesting device, as taught by Kakaiya. The motivation is to protect RDMA traffic from being snooped on when traveling between the memory device and requesting device.
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lal (US-20240036733-A1), in further view of Kakaiya (US-20240089239-A1), in further view of SPDM v1.1.0 (“Security Protocol and Data Model (SPDM) Specification,” 2020-07-15), in further view of Sharma (US-20200242255-A1).
Regarding claim 3, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches The processing system of claim 2. Lal teaches wherein the host encryption processing unit comprises a first [trusted execution environment] and the memory encryption processing unit comprises a second [trusted execution environment]. (Paragraph 157, "As illustrated, application server platform 902 may include a processor, such as a CPU 910, a memory 920, and a local NIC 930. In one embodiment, CPU 910 can host an application 912 and a user mode driver (UMD) 914. The UMD 914 may further host a cryptographic engine (CE) 916. In one implementation, CPU 910 may provide a TEE (not shown), which may be Intel® SGX, Intel® TDX, AMD® SEV or ARM® Realm, to name a few examples, in which an application 912 and the UMD 914 are running." Paragraph 163, "The HW accelerator device 950 can include a memory management unit (MMU) 953, a cryptographic engine (CE) 954, a compute kernel 952, and device memory 955. In implementations herein, the CE 954 and compute kernel 952 can be part of a TCB of a TEE (not shown) hosted on the HW accelerator device 950. The compute kernel 952 may include the accelerated part of application 912 workload's memory on the acceleration server platform 904.").
However, Lal in view of Kakaiya, in further view of SPDM v1.1.0, does not explicitly teach … root of trust …
Sharma teaches … root of trust (Paragraph 26, “Hardware platform providers have worked hard to provide a secure and isolated environment as a root of trust. Such a secure environment (e.g., Trustzone in ARM) has its own secure storage and other resources which are separate from main or primary processor. A separate operating system (OS) runs on secure processor in a high privilege mode, frequently known as trusted execution environment (TEE) that provides a root of trust when booting a device. During the boot process, TEE is considered as the root of trust as TEE loads a primary OS (BSP), but once the device is up and running, the control is with BSP only and TEE does not play much of a role.”).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal in view of Kakaiya, in further view of SPDM v1.1.0’s RDMA system with Sharma, by enhancing Lal in view of Kakaiya, in further view of SPDM v1.1.0’s Trusted execution environments to be roots of trust, as taught by Sharma. The motivation is to give the two encryption processors a secure way to boot up RDMA software, since they are the ones performing the encryption.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lal (US-20240036733-A1), in further view of Kakaiya (US-20240089239-A1), in further view of SPDM v1.1.0 (“Security Protocol and Data Model (SPDM) Specification,” 2020-07-15), in further view of OOBA (“Out of Band Authentication (OOB)”, 2019).
Regarding claim 6, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches The processing system of claim 5. Lal teaches … a sideband channel … (Paragraph 214, “In Example 5, the subject matter of any one of Examples 1-4 can optionally include wherein the data is received via a data communication channel that is an integrity-protected data channel between the hardware accelerator device and an application server platform, the data communication channel established via an attestation and key exchange protocol; and wherein a control communication channel that is separate from the data communication channel is secured between the hardware accelerator device and the application server platform.”).
However, Lal does not teach wherein the second processing element is operable to execute the mutual authentication protocol over a sideband channel.
Kakaiya teaches wherein the second processing element is operable to execute the … authentication protocol … (Paragraph 44, "In some examples, at 3.2, authentication logic 210 of circuitry 117 works in cooperation with authentication logic 220 of circuitry 137 to authenticate accelerator 136. For these examples, authentication logic 210 and authentication logic 220 implements a request-response messaging model described in the SPDM specification that includes a message exchange using an SPDM messaging protocol, for example, where each SPDM request message shall be responded to with an SPDM response message. For these examples, “measurement” for accelerator 136 can describe a process of using acquired certificate and measurement information for authentication logic 210 of TEE 116 to calculate a cryptographic hash value and tie the cryptographic hash value with accelerator 136's identity through a use of digital signatures. This allows authentication logic 210 of circuitry 117 to authenticate the identity of accelerator 136 if an SPDM response message from authentication logic 220 of circuitry 137 includes a value that matches the calculated cryptographic hash value. Following this authentication, accelerator 136 is now deemed as trusted and is brought within the TCB of TEE 1160." SPDM is an authentication protocol, where the authentication protocol is being done by Auth logic 220 as seen with 3.2.).
The motivation to combine Lal with Kakaiya is the same as in claim 4.
However, Lal in view of Kakaiya does not teach a … mutual authentication protocol over a sideband channel.
SPDM v1.1.0 teaches … mutual authentication protocol … (Page 21 item 95 shows an SPDM session where a mutual authentication is performed.).
The motivation to combine Lal in view of Kakaiya with SPDM v1.1.0 is the same as in claim 1.
However, Lal in view of Kakaiya, in further view of SPDM v1.1.0, does not explicitly teach a … mutual authentication protocol over a sideband channel.
OOBA teaches … authentication protocol over a sideband channel (Page 3, "Out of band authentication (OOBA) is an authentication process that utilizes a communications channel separate from the primary communication channel of two entities trying to establish a connection. Using a separate authentication channel makes it significantly more difficult for an attacker to intercept and subvert the authentication process (i.e. via man-in-the-middle attack), attacker to compromise two communications channels.").
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal in view of Kakaiya, in further view of SPDM v1.1.0’s RDMA system with OOBA, by enhancing Lal in view of Kakaiya, in further view of SPDM v1.1.0’s control channel to be a channel separate from the primary communication channel to perform the authentication protocol, as taught by OOBA. The motivation is to make it more difficult for attackers to intercept authentication processes, since there are different communication channels being used (OOBA page 3, “Using a separate authentication channel makes it significantly more difficult for an attacker to intercept and subvert the authentication process (i.e. via man-in-the-middle attack), attacker to compromise two communications channels.”).
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lal (US-20240036733-A1), in further view of Kakaiya (US-20240089239-A1), in further view of SPDM v1.1.0 (“Security Protocol and Data Model (SPDM) Specification,” 2020-07-15), in further view of DIMM (“Dual In-Line Memory Modules,” January 18, 2022).
Regarding claim 8, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches The processing system of claim 1. However, Lal in view of Kakaiya, in further view of SPDM v1.1.0 does not teach wherein the destination memory is a dual in-line memory module. (Page 1, "DIMM stands for Dual Inline Memory Module. DIMM is a module containing one or several Random Access Memory (RAM) or Dynamic RAM (DRAM) chips on a long, thin strip of printed circuit board with pins that connect it directly to the computer motherboard. A DIMM (of DDR2 or DDR3 sockets) typically has a 240-pin connector and supports 64/72-bit data transfer. Modern DIMMs based on double data rate fourth-generation (DDR4) or the latest double data rate fifth-generation (DDR5) use 288-pin connectors to computer motherboards, improving data throughput." DIMMs have data throughput from a motherboard.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal in view of Kakaiya, in further view of SPDM v1.1.0’s RDMA system with DIMM, by enhancing Lal in view of Kakaiya, in further view of SPDM v1.1.0’s RDMA accessible memory to be Dual in line memory modules, as taught by DIMM. The motivation is that DIMMs are widely available memory module types, making it beneficial to use them as the memory module type for procurement and assembly purposes.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lal (US-20240036733-A1), in further view of Kakaiya (US-20240089239-A1), in further view of SPDM v1.1.0 (“Security Protocol and Data Model (SPDM) Specification,” 2020-07-15), in further view of Bernat (US-20180027062-A1).
Regarding claim 9, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches the processing system of claim 1. However, Lal in view of Kakaiya, in further view of SPDM v1.1.0 does not teach wherein the memory device further comprises a high bandwidth memory in communication with the memory encryption processing unit.
Bernat teaches wherein the memory device further comprises a high bandwidth memory in communication with the memory encryption processing unit (Paragraph 2, "Typical architectures for accelerator devices such as field programmable gate arrays (FPGAs), cryptography accelerators, graphics accelerators, and/or compression accelerators (referred to herein as “accelerators” or “accelerator resources”) capable of accelerating the execution of a set of operations in a workload (e.g., processes, applications, services, etc.) may allow static assignment of specified amounts of shared resources of the accelerator device (e.g., high bandwidth memory, data storage, etc.) among different portions of the logic (e.g., circuitry) of the accelerator device. Each logic portion may execute a separate set of operations to be accelerated, such as on behalf of different customers of a cloud data center. The resource needs of the logic portions may change as their workloads are executed, such that while a particular logic portion may be allocated 60% of the available high bandwidth memory, it only uses 30% of the high bandwidth memory during certain phases of the workload." High bandwidth memory is a resource of the accelerator device, which is interpreted as the memory device.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal in view of Kakaiya, in further view of SPDM v1.1.0’s RDMA system with Bernat, by enhancing Lal in view of Kakaiya, in further view of SPDM v1.1.0’s RDMA accessible memory in its accelerator, that is in contact with the processing circuitry, to be High bandwidth memory, as taught by Bernat. The motivation is that High bandwidth memory is good for handling large amounts of data that needs to be kept on memory on a device.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lal (US-20240036733-A1), in further view of Kakaiya (US-20240089239-A1), in further view of SPDM v1.1.0 (“Security Protocol and Data Model (SPDM) Specification,” 2020-07-15), in further view of Karishma (“How OPTIGA™ Trust M prevents replay attacks?” 27 July 2022).
Regarding claim 11, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches the processing system of claim 1. Lal teaches wherein the symmetric session key is a first symmetric session key … (Paragraph 167, "In implementations herein, the CE 916 may apply a cryptographic algorithm, such as AES GCM, to encrypt and integrity protect the application's 912 data." Paragraph 168, "On the accelerator server platform 904 side, the corresponding CE 954 of the HW accelerator device 950 can decrypt the data and verify the integrity of the transfer including the order of data transfer. The CE 954 also verifies that the destination address is not modified by computing the hash of the address and comparing that with the hash that is included with the data." AES is symmetric.).
However, Lal does not teach … and wherein the memory encryption processing unit is configured to, upon determining that a predetermined number of transactions have executed after the first symmetric session key was established, execute the mutual authentication protocol to establish a second symmetric session key, wherein the predetermined number of transactions is less than three hundred million transactions and a transaction comprises a send operation or a receive operation over the authenticated-encrypted data stream.
Kakaiya teaches and wherein the memory encryption processing unit is configured to… execute the … authentication protocol to establish a … symmetric session key (Paragraph 52, "As described more below, subsequent work requests originating from TEE 116 can indicate that index value to facilitate retrieval of the session key from the key table and then use the retrieved session key for decrypting/encrypting data received from or to be sent to TEE 116. “Fig. 3, item 3.1 shows authentication between the first and second cryptographic module. Paragraph 43, "According to some examples, at 3.1, authentication logic 210 of circuitry 117 can be capable of using various specifications to include, but not limited to, a Distributed Management Task Force (DMTF) Secure Protocol and Data Model (SPDM) specification such as the SPDM specification, DSP0274, Ver. 1.0.1, published in March, 2021 by the Platform Management Components Intercommunication (PMCI) working group of the DMTF (hereinafter “the SPDM specification”) to acquire authentication information from/about accelerator 136." The session key is interpreted as symmetric (it is used for encrypting and decrypting data), and this key has its establishment done after the authentication protocol is done.).
The motivation to combine Lal with Kakaiya is the same as in claim 1.
However, Lal in view of Kakaiya does not teach … upon determining that a predetermined number of transactions have executed after the first symmetric session key was established, execute the mutual authentication protocol to establish a second symmetric session key, wherein the predetermined number of transactions is less than three hundred million transactions and a transaction comprises a send operation or a receive operation over the authenticated-encrypted data stream.
SPDM v1.1.0 teaches upon determining that a predetermined number of transactions have executed after the first symmetric session key was established (Page 97. "The RequesterContext is the contribution of the Requester to session key derivation. It shall contain a nonce (random number or monotonic counter) to make sure that the derived session keys are ephemeral to mitigate against replay attacks. It may also contain other information from the Requester." Page 102, "To update session keys, this request shall be used. There are many reasons for doing this but an important one is when the per-record nonce will soon reach its maximum value and rollover. The KEY_UPDATE request can be issued by the Responder as well using the GET_ENCAPSULATED_REQUEST mechanism. A KEY_UPDATE request shall update session keys in the direction of the request only. Because the Responder can also send this request, it is possible that two simultaneous key updates, one for each direction, can occur. However, only one KEY_UPDATE request for a single direction shall occur. Until the session key update synchronization successfully completes, subsequent KEY_UPDATE request for the same direction shall be considered a retry of the original KEY_UPDATE request." The maximum value where it will then roll over is interpreted as a predetermined number of transactions after the first symmetric key was established.).
execute the mutual authentication protocol to establish a second symmetric session key … (Page 102, "To update session keys, this request shall be used. There are many reasons for doing this but an important one is when the per-record nonce will soon reach its maximum value and rollover. The KEY_UPDATE request can be issued by the Responder as well using the GET_ENCAPSULATED_REQUEST mechanism. A KEY_UPDATE request shall update session keys in the direction of the request only. Because the Responder can also send this request, it is possible that two simultaneous key updates, one for each direction, can occur. However, only one KEY_UPDATE request for a single direction shall occur. Until the session key update synchronization successfully completes, subsequent KEY_UPDATE request for the same direction shall be considered a retry of the original KEY_UPDATE request." Page 102, "The data transport layer shall ensure that data transfer during key updates is managed in such a way that the correct keys are used before, during, and after the key update operation. How this is accomplished by the data transport layer is outside of the scope of this specification. Both the sender and the receiver shall derive the new keys as detailed in Major secrets update." The mutual authentication protocol will generate a second symmetric key after the nonce rolls over.).
… a transaction comprises a send operation or a receive operation over the authenticated-encrypted data stream (Page 97, "The RequesterContext is the contribution of the Requester to session key derivation. It shall contain a nonce (random number or monotonic counter) to make sure that the derived session keys are ephemeral to mitigate against replay attacks. It may also contain other information from the Requester." Page 99, "The ResponderContext is the contribution of the Responder to session key derivation. It should contain a nonce (random number or monotonic counter) and other information of the Responder. Because the Responder may be a constrained device that is not able to generate a nonce, ResponderContext is optional. However, the Responder is required to use ResponderContext if it can generate a nonce. 460 It should be noted that the nonce in ResponderContext is critical for anti-replay. If a nonce is not present in ResponderContext, then the Responder is not challenging the Requester for real-time knowledge of PSK. Such a session is subject to replay attacks - a man-in-the-middle attacker could record and replay prior PSK_EXCHANGE and PSK_FINISH messages and set up a session with the Responder. But the bogus session would not leak secrets, so long as the PSK or session keys of the prior replayed session are not compromised." A nonce is used for send and receive operations over an authenticated-encrypted data stream, a monotonic counter as the interpreted form of the nonce.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal in view of Kakaiya’s RDMA system with SPDM v1.1.0, by enhancing Lal in view of Kakaiya’s key handling system to include a key expiration condition, as taught by SPDM v1.1.0. The motivation is to prevent a key from going stale and becoming insecure over prolonged usage.
However, Lal in view of Kakaiya, in further view of SPDM v1.1.0, does not teach …wherein the predetermined number of transactions is less than three hundred million transactions …
Karishma teaches … wherein the predetermined number of transactions is less than three hundred million transactions (Page 1, "provides four monotonic counting data objects (up counters) and each counter can be updated up to a maximum of 600,000 times. These counter data objects have a fixed length of 8 bytes, which consist of the concatenated counter value (off set 3-0) and the regarded threshold (off set 7-4), as shown in the following figure.").
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal in view of Kakaiya, in further view of SPDM v1.1.0’s RDMA system with Karishma, by enhancing Lal in view of Kakaiya, in further view of SPDM v1.1.0’s key handling system to include a key expiration condition of 600,000 for the maximum value a monotonic counter for the key uses to reach, as taught by Karishma. The motivation is to put a reasonable maximum value the monotonic counter can reach before a key is forced to expire with a replacement.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lal (US-20240036733-A1), in further view of Kakaiya (US-20240089239-A1), in further view of SPDM v1.1.0 (“Security Protocol and Data Model (SPDM) Specification,” 2020-07-15), in further view of Bursell (US-12093371-B2).
Regarding claim 15, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches the processing system of claim 14, wherein the memory encryption processing unit includes … [an encryption key] and wherein saving the data in the destination memory further comprises encrypting the data using a trusted compute function and the [encryption key] before the data is saved to the destination memory. (Paragraph 86, "In some examples, write flow 1000 is for writing data to one or more storage devices (e.g., of storage array 140) based on a request originating from TEE 116 at compute server 110. Write flow 1000 assumes that a secure session has been established between TEE 116 and accelerator 136 as described above for scheme 300 or 500 and that the encrypted data was sent to input buffer(s) 231 at service server 130 in a similar manner as describe above for write flow 700 shown in FIG. 7." Paragraphs 92-93, "In some examples, at 10.6, integrity logic 228 forwards the encrypted data to decryption logic based on the integrity of the encrypted data being verified based on the generated HMAC value matching the HMAC read from input buffer(s) 231. According to some examples, at 10.7, decryption logic 226 uses the session key provided by key logic 222 to decrypt the encrypted data to generate clear text data that is at least temporarily stored to secure memory 225 and also provided to integrity logic 228." Paragraph 99, "According to some examples, at 10.13, encryption logic 224 encrypts the transformed data with the CRC to generate encrypted data. For example, if the transformed data included compressed data, then encryption logic 224 combines the CRC provided by integrity logic 228 with the compressed data to generate the encrypted data." Paragraph 102, "In some examples, at 10.16, integrity logic 228 causes the encrypted data with the new HMAC value to be sent to one or more output buffer(s) 233 at service server 130. Although not shown in FIG. 10, the encrypted data with the new HMAC value that was sent to output buffer(s) 233 can subsequently be sent to a storage device included in storage array 140. Write flow 1000 then comes to an end." Fig. 10 shows the received encrypted data being decrypted, then encrypted again to be sent to the storage device. The encryption logic is interpreted as a trusted compute function.).
However, Lal in view of Kakaiya, in further view of SPDM v1.1.0 does not teach a hardware private key, and encrypting the data using … the hardware private key before the data is saved to the destination memory.
Bursell teaches a hardware private key (Col. 26 lines 64-67 – Col. 28 lines 1 – 17, "… The processor of the data distribution device may provide the trusted execution environment and the memory encryption using hardware level encryption for the data stored in memory. The hardware level encryption may use cryptographic keys that are accessible to the processor and are inaccessible to all processes executed by the processor. In one example, the processor may receive a request from the first computing device to establish the trusted execution environment and perform a remote attestation of hardware and code of the data distribution device to the first computing device. The process may also configure the encrypted storage area and an area of the processor for the trusted execution environment." Col. 27, lines 18-36, "… encrypted storage area using a second key (e.g., storage key, memory key). … " The hardware private key is interpreted as a memory key.).
and encrypting the data using … the hardware private key before the data is saved to the destination memory. (Col. 9 lines 33-53, “Storage devices 212 may include any data storage device that is capable of storing data and may include physical memory devices. The physical memory devices may include volatile memory devices (e.g., RAM, DRAM, SRAM), non-volatile memory devices (e.g., NVRAM), other types of memory devices, or a combination thereof. … Storage devices 212 may be capable of storing data 122 associated with one or more of the computing processes 225A-C. In one example, data of computing process 225A may be received from a device that is internal or external to computing device 110A. The data may be encrypted using a cryptographic key that was provided (e.g., determined, derived, generated, assigned) by computing device 110A or by a different computing device. The received data may be decrypted using the same cryptographic key or a derivative of the cryptographic key and the decrypted data may be loaded into the trusted execution environment 120 (as shown by data 122) before, during or after being re-encrypted.” (Col. 27, lines 18-36, "At block 706, the processor of the data distribution device may load data of the first computing device into the trusted execution environment in the data distribution device. The data may include protected content and executable code to control access to the protected content. The protected content may include document data (e.g., secret document), cryptographic key data (e.g., secret key), other data, or a combination thereof that will be distributed by the data distribution device to one or more other computing devices. The processor may receive the data in an encrypted form and may decrypt the data using a first key (e.g., transport key, session key) and encrypt the data before, during, or after storing the data in the encrypted storage area using a second key (e.g., storage key, memory key). The first key may be location independent and the may not be based on the location that the data is stored and the second key may be location dependent and may be based on the location in which the data is stored (e.g., key based on physical or logical memory address)."The second key/memory key encrypts the data before storing it into the encrypted storage area.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal in view of Kakaiya, in further view of SPDM v1.1.0’s RDMA system with Bursell, by enhancing Lal in view of Kakaiya, in further view of SPDM v1.1.0’s memory storing system to include a separate encryption key for solely memory encryption, where it encrypts data before it is stored into the memory of a computing device, as taught by Bursell. The motivation is to have a key distinct from the session key, preventing a key compromise of the session key from causing a compromise of data stored in memory, as well as preventing any important data from entering the memory unit unencrypted, thus preventing physical memory access from giving an adversary access to sensitive information.
Claim(s) 16-17, 32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lal (US-20240036733-A1), in further view of Kakaiya (US-20240089239-A1), in further view of SPDM v1.1.0 (“Security Protocol and Data Model (SPDM) Specification,” 2020-07-15), in further view of Waldspurger (US-20230237169-A1).
Regarding claim 16, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches The processing system of claim 1. However, Lal does not teach that the system will receive a math command from the host encryption processing unit via the authenticated-encrypted data stream, the math command being associated with a math operation and destination memory data, read destination memory data from the destination memory, decrypt the destination memory data using a trusted compute function and a hardware private key to generate decrypted destination memory data, and execute the math operation on the decrypted destination memory data to generate a math operation output.
Kakaiya teaches wherein the memory encryption processing unit is further configured to: receive a math command from the host encryption processing unit via the authenticated-encrypted data stream, the math command being associated with a math operation and destination memory data, (Paragraph 37, "In some example, the one or more storage devices included in storage array 140 can include volatile or non-volatile types of memory." Paragraph 38, "Fabric 120 can also operate according to one or more InfiniBand Architecture or Fibre Channel specifications and can utilize remote direct memory access (RDMA) over Converged Ethernet (RoCE) or iWARP protocols (e.g., to enable TEE(s) 116 to access storage devices included in storage array 140)." Paragraph 112, "In some examples, read flow 1200 is for reading data from one or more storage devices (e.g., of storage array 140) based on a request originating from TEE 116 at compute server 110. Read flow 1200 assumes that a secure session has been established between TEE 116 and accelerator 136 … Paragraph 113, "According to some examples, at 12.1, service 132 sends a work descriptor to key logic 222 of circuitry 137 at accelerator 136. In other examples, although not shown in FIG. 12, the work descriptor can come directly from TEE 116. For either of these examples, the work descriptor can include a request for accelerator 136 to perform one or more operations on data included in encrypted data placed in one or more input buffer(s) 231. The one or more operations to transform data following decryption can include, but are not limited to, compression operations to decompress the compressed data read from a storage device (e.g., included in storage array 140) or de-duplication operations to identify possibly duplicated data and prevent duplicated data from being sent to TEE 116." Request for one or more operations interpreted as a math command, these math commands being "decompression/deduplication." Associated with destination memory data is interpreted as the work descriptor associated with the read request on a storage device, where it describes what the TEE wants done with data before receiving it.).
read destination memory data from the destination memory, (Paragraph 116, "In some examples, at 12.4, integrity logic 228 reads encrypted data with HMAC from input buffer(s) 231. For these examples, the data to read from input buffer(s) 231 can be identified in the work descriptor." The encrypted data in input buffer 231 is from the destination memory/storage array 140.)
decrypt the destination memory data using a trusted compute function and [an encryption] key to generate decrypted destination memory data. (Fig. 12 shows at step 12.7, the destination memory data is decrypted. Paragraph 119, "According to some examples, at 12.7, decryption logic 226 uses the session key provided by key logic 222 to decrypt the encrypted data to generate clear text compressed data that also includes an appended CRC value. The clear text compressed data and the appended CRC value is at least temporarily stored to secure memory 225. Also, the CRC value is provided to integrity logic 228.").
and execute the math operation on the decrypted destination memory data to generate a math operation output. (Fig. 12 shows at step 12.8, the data is transformed. Paragraph 120, "According to some examples, at 12.8, transformation logic 229 of circuitry 137 reads the clear text compressed data stored at secure memory 225, transforms the clear text compressed data based on what was indicated in the work descriptor (e.g., decompression), and stores the transformed data (e.g., decompressed data) to secure memory 225." the transformation/math operation is performed on the decrypted memory data, generating transformed memory data.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal’s RDMA system with Kakaiya by enhancing Lal’s RDMA system to store information in the memory in an encrypted manner, and also have the ability to make modifications to the stored memory prior to transmitting it to the requesting device, such as decompressing it, as taught by Kakaiya. The motivation is to give the requesting device multiple operations they can perform on the data they are to remotely access, an example being able to request the data in a compressed or uncompressed form to save bandwidth and storage.
However, Lal in view of Kakaiya, in further view of SPDM v1.1.0 does not teach … a hardware private key …
Waldspurger teaches … a hardware private key … (Paragraphs 15-16, "Hardware support for secure computing environments may provide cryptographic protection for data-in-use. For example, one implementation can associate a unique key with each virtual machine (VM), which the hardware memory controller can use to automatically encrypt data stored to main memory and decrypt data loaded from main memory. As a result, memory associated with one VM can be isolated cryptographically from both other VMs and the hypervisor. This arrangement can ensure data confidentiality, even if traditional access controls for memory are subverted, or the hypervisor itself is compromised. Per-VM encryption keys may be managed by a secure processor hardware and used only for local memory encryption while a VM is executing. When a VM interacts with external input/output (I/O) devices such as disks, or communicates with remote systems over a network, data transfers can be protected using conventional cryptographic approaches, such as encrypted storage for data-at-rest (using separate long-lived keys), and the secure sockets layer (SSL) protocol for data-in-transit (using separately negotiated per-session keys)." The per-VM encryption key is interpreted as a hardware private key.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal in view of Kakaiya, in further view of SPDM v1.1.0’s RDMA system with Waldspurger, by enhancing Lal in view of Kakaiya, in further view of SPDM v1.1.0’s memory storing system to include a separate encryption key for solely memory encryption, where it encrypts data before it is stored into the memory of a computing device, as taught by Waldspurger. The motivation is to have a key distinct from the session key, preventing a key compromise of the session key from causing a compromise of data stored in memory, used to encrypt all data stored in the accessible memory, thus preventing physical memory access from giving an adversary access to sensitive information.
Regarding claim 17, Lal in view of Kakaiya, in further view of SPDM v1.1.0, in further view of Waldspurger teaches the processing system of claim 16. Kakaiya teaches wherein the memory encryption processing unit is further configured to: send the math operation output to the host encryption processing unit via the authenticated-encrypted data stream. (Paragraphs 124-124, "In some examples, at 12.11, encryption logic 224 reads or obtains the transformed data from secure memory 225. According to some examples, at 12.12, encryption logic 224 encrypts the transformed data to generate encrypted data." Paragraph 127, "In some examples, at 12.15, integrity logic 228 causes the encrypted data with the new HMAC value to be sent to one or more output buffer(s) 233 at service server 110. Although not shown in FIG. 12, the encrypted data with the new HMAC value sent to output buffer(s) 233 can subsequently be sent to a TEE 116 at compute server 110. Read flow 1200 then comes to an end." The transformed data is encrypted, then send to the host encryption processing unit.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal’s RDMA system with Kakaiya by enhancing Lal’s RDMA system to encrypt memory data using a negotiated session key prior to transmitting it to the requesting device, as taught by Kakaiya. The motivation is to protect RDMA traffic from being snooped on when traveling between the memory device and requesting device.
Regarding claim 32, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches the method of claim 19. Lal teaches receiving, via the memory encryption processing unit, data from the host encryption processing unit via the authenticated-encrypted data stream; (Paragraphs 167-168, "In implementations herein, the CE 916 may apply a cryptographic algorithm, such as AES GCM, to encrypt and integrity protect the application's 912 data. … On the accelerator server platform 904 side, the corresponding CE 954 of the HW accelerator device 950 can decrypt the data and verify the integrity of the transfer including the order of data transfer. The CE 954 also verifies that the destination address is not modified by computing the hash of the address and comparing that with the hash that is included with the data." The AES GCM data stream is decrypted by the HW accelerator after being received from CE 916 of the host encryption processing unit.)
decrypting the data received from the host encryption processing unit using the symmetric session key; and saving the data in the destination memory. (Paragraph 178, "The CE 954 of the HW accelerator device 950 can decrypt any incoming data received at remote NIC 960 and compute a running MAC as data is written into device memory 955. When the transfer is complete, the CE 954 finalizes the MAC and verifies it." The decryption is done using the AES-GCM session key, where the writing is interpreted as saving in destination memory.).
However, Lal in view of Kakaiya, in further view of SPDM v1.1.0 does not teach wherein the memory encryption processing unit includes a hardware private key.
Waldspurger teaches wherein the memory encryption processing unit includes a hardware private key (Paragraphs 15-16, "Hardware support for secure computing environments may provide cryptographic protection for data-in-use. For example, one implementation can associate a unique key with each virtual machine (VM), which the hardware memory controller can use to automatically encrypt data stored to main memory and decrypt data loaded from main memory. As a result, memory associated with one VM can be isolated cryptographically from both other VMs and the hypervisor. This arrangement can ensure data confidentiality, even if traditional access controls for memory are subverted, or the hypervisor itself is compromised. Per-VM encryption keys may be managed by a secure processor hardware and used only for local memory encryption while a VM is executing. When a VM interacts with external input/output (I/O) devices such as disks, or communicates with remote systems over a network, data transfers can be protected using conventional cryptographic approaches, such as encrypted storage for data-at-rest (using separate long-lived keys), and the secure sockets layer (SSL) protocol for data-in-transit (using separately negotiated per-session keys)." The per-VM encryption key is interpreted as a hardware private key.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal in view of Kakaiya, in further view of SPDM v1.1.0’s RDMA system with Waldspurger, by enhancing Lal in view of Kakaiya, in further view of SPDM v1.1.0’s memory storing system to include a separate encryption key for solely memory encryption, where it encrypts data before it is stored into the memory of a computing device, as taught by Waldspurger. The motivation is to have a key distinct from the session key, preventing a key compromise of the session key from causing a compromise of data stored in memory, used to encrypt all data stored in the accessible memory, thus preventing physical memory access from giving an adversary access to sensitive information.
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lal (US-20240036733-A1), in further view of Kakaiya (US-20240089239-A1), in further view of SPDM v1.1.0 (“Security Protocol and Data Model (SPDM) Specification,” 2020-07-15), in further view of Decru (“Decru DataFort NAS SEP v1.” 2007)
Regarding claim 18, Lal in view of Kakaiya, in further view of SPDM v1.1.0 teaches The processing system of claim 1. Lal teaches wherein the memory encryption processing unit is connected to the destination memory via a memory link … (Fig. 9 shows the CE 954 connected to the device memory component. Paragraph 163, “As noted above, HW accelerator device 950 can be any type of accelerator device including, but not limited to, a GPU, FPGA, ASIC, special-purpose CPU, inference accelerator, cryptographic accelerator, and so on. The HW accelerator device 950 can include a memory management unit (MMU) 953, a cryptographic engine (CE) 954, a compute kernel 952, and device memory 955. In implementations herein, the CE 954 and compute kernel 952 can be part of a TCB of a TEE (not shown) hosted on the HW accelerator device 950. The compute kernel 952 may include the accelerated part of application 912 workload's memory on the acceleration server platform 904.”).
However, Lal in view of Kakaiya, in further view of SPDM v1.1.0, does teach … and the memory link includes a housing enclosing a circuitry with tamper-resistant features, the tamper- resistant features being operable to destroy the circuitry if the housing is removed to expose the circuitry.
Decru teaches … and the memory link includes a housing enclosing a circuitry with tamper-resistant features, the tamper- resistant features being operable to destroy the circuitry if the housing is removed to expose the circuitry. (Fig. 1 and fig. 2 shows potted/covered area with epoxy that includes an SEP. Page 29, "The SEP is protected with a hard, opaque tamper evident epoxy coating. With high probability, removal of this coating will destroy the underlying circuitry" Page 29, "The module shall include an upgrade service, whereby new firmware is loaded into the SEP. In this case, the module shall perform an external load test, computing the SHA-512 hash of the entire upgrade package." Page 31, “Decru Crypto Card – a PCI card that houses the SEP together with non cryptographic components such as DDRAM, a battery charger, etc” the SEP is interpreted to have a memory link.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Lal in view of Kakaiya, in further view of SPDM v1.1.0’s RDMA system with Decru, by enhancing Lal in view of Kakaiya, in further view of SPDM v1.1.0’s physical connections between components, to be covered with epoxy such that tampering with the link itself isn’t possible without destroying the underlying components, as taught by Decru. The motivation is to prevent tampering with the memory device in a way that could make future communications with it unsafe.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUHAMMAD H RASUL whose telephone number is (571)272-4613. The examiner can normally be reached Monday - Friday 6:30 A.M.- 5:00 P.M. E.D.T..
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, Rupal Dharia can be reached at 571-272-3880. 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.
/M.H.R./Examiner, Art Unit 2492 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492
Prosecution Insights