DETAILED ACTION
This action is in response to arguments filed 11/14/2025. Claims 26-20 are pending.
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 .
Response to Arguments
Applicant's arguments filed 11/14/2025 have been fully considered.
A) Applicant's arguments with respect to the 103 rejection of claims 26, 36, 41 and 46 that Yu does not disclose “allocating, to one or more customers, compute resources provided by the platform hardware to facilitate execution of one or more customer applications and services used to perform one or more customer workloads” because in YU the “the compute, memory, networking and storage resousces for the blade server or server are allocated to a single customer commonly referred to as a tenantwho leased the premise when he data center infrastructure for a cloud service node is leased to a customer” have been fully considered but they are not persuasive (See response pages 12-16 and 27-29).
Regarding A) the claim clearly states “one or more customer workloads” therefore the claim reads on a single customer.
B) Applicant's arguments with respect to the 103 rejection of claims 26, 36, 41 and 46 that Yu does not disclose “provisioning, for a customer application or customer service” because in “YU does not provision a hardware protection key for a customer application or customer service. Rather YU provisions a hardware protected key for a cloud node (e.g. a physical server, such as a blade server)“ have been fully considered but they are not persuasive (See response page 16).
Regarding B) YU teaches “provisioning, for a customer application or customer service” in the Summarize section on page 6 i.e. In the era of cloud computing, tenants' services and applications are operated and maintained by cloud computing providers in a "hosted" manner. How to ensure that private keys will not be leaked is an issue that must be considered. From the perspective of cloud services, key protection capabilities are one of the services that a secure cloud must provide, and are as important as computing, storage, and networking. Intel® KPT is based on Intel® QAT and Intel® PTT, which not only provides security protection for keys, but also accelerates data signature and decryption operations. We believe that Intel® KPT can be used as a tool for cloud computing providers to ensure the security of tenant keys, and become a powerful weapon to ultimately win the market.
C) Applicant's arguments with respect to the 103 rejection of claims 26, 36, 41 and 46 that Yu does not disclose “enabling the customer application or customer service to securely access the hardware protected key provisioned for the customer application or customer service while preventing any other customer application or customer service from accessing that hardware protected key” because in “YU does not provision a hardware protection key for a customer application or customer service“ have been fully considered but they are not persuasive (See response page 17-23).
D) In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify YU in view of Kwan to have generated the used a permanent private storage key owned by the module to generate a session key as one of many ways to generate a session key (see Kwan paragraph 0027). Therefore one would have been motivated to have used a permanent device key to generate a session 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.
Claim(s) 26, 27, 35, 36, 41, 43, 46 and 48 are rejected under 35 U.S.C. 103 as being unpatentable over YU, Wendian et al. "Protecting Your Own Private Key in Cloud: Security, Scalability and Performance” in view of Kwan et al (US 2007/0288747).
With respect to claim 26 Yu teaches a method implemented on a compute platform comprising platform hardware including one or more processors, comprising:
allocating, to one or more customers, compute resources provided by the platform hardware to facilitate execution of one or more customer applications and services used to perform one or more customer workloads (see YU section II System Design i.e. Intel® KPT is a now feature in Intel® servers based on the Intel® Xeon® Scalable Processor Family Intel KPT works in conjunction with Intel platform feature called Intel Platform Trust Technology (PTT), which is used to store user secrets (keys) at rest. Intel PTT is an Intel implementation of TPM (Trusted Platform Module) and Intel Ouick Assist Technology (QAT) is hardware cryptography accelerator. There is a secure hardware link between Intel® QAT and Intel PPT in Intel C627/C628 Chipset to share keys. Figure 1 describes the system design of this whole solution, which includes two major parts, the key management server (KMS) and the cloud platform running applications based on Intel architecture);
provisioning, for a customer application or customer service, a hardware protected key (see YU section II System Design i.e. Key Provision/Sharing: Symmetric Wrapping Kev (SWK) is provisioned to Intel® PTT on the cloud platform via a key provision app KPTtool, which follows TPM key export-import protocol as defined in TPM 2.0 specifications. The user’s original clear private kev (CPK) is encrypted using the SWK to output a wrapped private key (WPK) in a trusted environment inside the KMS, WPK, when deployed and shared on compute nodes, is now secured and protected by SWK. A new private key PEM format following ASN. 1 syntax is defined in order to specify the process of generating a WPK from its CPK. The new PEM format specifies details such as the algorithm and key size of the SWK, the IV and etc. New PEM format of RSA private key is defined as below Figure 2:); and
enabling the customer application or customer service to securely access the hardware protected key provisioned for the customer application or customer service while preventing any other customer application or customer service from accessing that hardware protected key (see YU section II System Design i.e. Runtime: Our prototype is based on a vertical integration of nginx and OpenSSL with Intel® QAT API library, driver and HW engine. WPE is deployed on cloud platform and used in memory instead of CPK. nginx/OpenSSL triggers Intel® PTT to send SWK. to Intel® QAT via internal secure hardware link. Inside Intel®) QAT, WPK is unwrapped to CP, which is used for private key operations. In the whole life, CPE is never exposed in memory of hypervisor or container; and section III Security Analysis and Performance Evaluation).
While YU discloses a hardware protected key (i.e. symmetric wrapping key) but does not disclose that it is generated using a per-part device key that is embedded in a hardware component on the platform.
Kwan teaches that a hardware protected key is generated using a per-part device key that is embedded in a hardware component on the platform (see Kwan paragraph 0027 i.e. The DRM module may retrieve a storage key, SK, which may be a permanent private storage key owned by the DRM module and generate a storage session key, SSK. The DRM module may encrypt or wrap the subject private key, SPrivK, with the storage session key, SSK, to arrive at a wrapped storage private key, SSK(SPrivK)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify YU in view of Kwan to have generated the used a permanent private storage key owned by the module to generate a session key as one of many ways to generate a session key (see Kwan paragraph 0027). Therefore one would have been motivated to have used a permanent device key to generate a session key.
With respect to claim 27 Yu and Kwan teach the method of claim 26, wherein the hardware protected key comprises a Symmetric Wrapping Key (SWK) (see YU section II System Design i.e. Key Provision/Sharing: Symmetric Wrapping Kev (SWK) is provisioned to Intel® PTT on the cloud platform via a key provision app KPTtool, which follows TPM key export-import protocol as defined in TPM 2.0 specifications. The user’s original clear private kev (CPK) is encrypted using the SWK to output a wrapped private key (WPK) in a trusted environment inside the KMS, WPK, when deployed and shared on compute nodes, is now secured and protected by SWK. A new private key PEM format following ASN. 1 syntax is defined in order to specify the process of generating a WPK from its CPK. The new PEM format specifies details such as the algorithm and key size of the SWK, the IV and etc. New PEM format of RSA private key is defined as below Figure 2:).
With respect to claim 35 Yu and Kwan teach the method of any of the preceding claims, wherein the hardware component with the per-part device key comprises one of a central processing unit (CPU), a Graphic Processor Unit (GPU), a General Purpose GPU (GP-GPU), a Tensor Processing Unit (TPU), a Data Processor Unit (DPU), an Infrastructure Processing Units (IPU), a SmartNIC (network interface controllers), an Artificial Intelligence (AI) processor or an Al inference unit (see YU section II System Design i.e. Key Provision/Sharing: Symmetric Wrapping Kev (SWK) is provisioned to Intel® PTT on the cloud platform via a key provision app KPTtool, which follows TPM key export-import protocol as defined in TPM 2.0 specifications. The user’s original clear private kev (CPK) is encrypted using the SWK to output a wrapped private key (WPK) in a trusted environment inside the KMS, WPK, when deployed and shared on compute nodes, is now secured and protected by SWK. A new private key PEM format following ASN. 1 syntax is defined in order to specify the process of generating a WPK from its CPK. The new PEM format specifies details such as the algorithm and key size of the SWK, the IV and etc. New PEM format of RSA private key is defined as below Figure 2:).
With respect to claim 36 Yu teaches a compute platform, comprising: one or more processors; and
wherein the compute platform is configured to execute applications and/or services for multiple customers using compute resources including the one or more processors allocated to the multiple customers (see YU section II System Design i.e. Intel® KPT is a now feature in Intel® servers based on the Intel® Xeon® Scalable Processor Family Intel KPT works in conjunction with Intel platform feature called Intel Platform Trust Technology (PTT), which is used to store user secrets (keys) at rest. Intel PTT is an Intel implementation of TPM (Trusted Platform Module) and Intel Ouick Assist Technology (QAT) is hardware cryptography accelerator. There is a secure hardware link between Intel® QAT and Intel PPT in Intel C627/C628 Chipset to share keys. Figure 1 describes the system design of this whole solution, which includes two major parts, the key management server (KMS) and the cloud platform running applications based on Intel architecture), and wherein the compute platform is further configured to
provision, for a customer application or customer service, a hardware protected key (see YU section II System Design i.e. Key Provision/Sharing: Symmetric Wrapping Kev (SWK) is provisioned to Intel® PTT on the cloud platform via a key provision app KPTtool, which follows TPM key export-import protocol as defined in TPM 2.0 specifications. The user’s original clear private kev (CPK) is encrypted using the SWK to output a wrapped private key (WPK) in a trusted environment inside the KMS, WPK, when deployed and shared on compute nodes, is now secured and protected by SWK. A new private key PEM format following ASN. 1 syntax is defined in order to specify the process of generating a WPK from its CPK. The new PEM format specifies details such as the algorithm and key size of the SWK, the IV and etc. New PEM format of RSA private key is defined as below Figure 2:); and
enable a customer application or customer service to securely access the hardware protected key provisioned to the customer application or customer service while preventing any customer application or customer service for another customer from accessing that hardware protected key (see YU section II System Design i.e. Runtime: Our prototype is based on a vertical integration of nginx and OpenSSL with Intel® QAT API bbrary, driver and HW engine. WPE is deployed on cloud platform and used in memory insicad of CPR. nginx/OpenSSL triggers Intel® PTT to send SWK. to Intel® QAT via internal secure hardware link. Inside Intel®) QAT, WPK is unwrapped to CP, which is used for private key operations. In the whole life, CPE is never exposed in memory of hypervisor or container; and section III Security Analysis and Performance Evaluation).
Yu a hardware component having a permanent per-part device key;
While YU discloses a hardware protected key (i.e. symmetric wrapping key) but does not disclose a hardware component having a permanent per-part device key; and that the hardware protected key is generated using a per-part device key that is fused in a hardware component on the platform.
Kwan teaches a hardware component having a permanent per-part device key; and that the hardware protected key is generated using a per-part device key that is fused in a hardware component on the platform (see Kwan paragraph 0027 i.e. The DRM module may retrieve a storage key, SK, which may be a permanent private storage key owned by the DRM module and generate a storage session key, SSK. The DRM module may encrypt or wrap the subject private key, SPrivK, with the storage session key, SSK, to arrive at a wrapped storage private key, SSK(SPrivK)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify YU in view of Kwan to have generated the used a permanent private storage key owned by the module to generate a session key as one of many ways to generate a session key (see Kwan paragraph 0027). Therefore one would have been motivated to have used a permanent device key to generate a session key.
With respect to claim 41 YU teaches a device, comprising: embedded logic to, generate a Symmetric Wrapping Key (SWK) (see YU section II System Design i.e. Key Provision/Sharing: Symmetric Wrapping Kev (SWK) is provisioned to Intel® PTT on the cloud platform via a key provision app KPTtool, which follows TPM key export-import protocol as defined in TPM 2.0 specifications. The user’s original clear private kev (CPK) is encrypted using the SWK to output a wrapped private key (WPK) in a trusted environment inside the KMS, WPK, when deployed and shared on compute nodes, is now secured and protected by SWK. A new private key PEM format following ASN. 1 syntax is defined in order to specify the process of generating a WPK from its CPK. The new PEM format specifies details such as the algorithm and key size of the SWK, the IV and etc. New PEM format of RSA private key is defined as below Figure 2:); and enable secure access to the SWK (see YU section II System Design i.e. Runtime: Our prototype is based on a vertical integration of nginx and OpenSSL with Intel® QAT API library, driver and HW engine. WPE is deployed on cloud platform and used in memory instead of CPK. nginx/OpenSSL triggers Intel® PTT to send SWK. to Intel® QAT via internal secure hardware link. Inside Intel®) QAT, WPK is unwrapped to CP, which is used for private key operations. In the whole life, CPE is never exposed in memory of hypervisor or container; and section III Security Analysis and Performance Evaluation).
While YU discloses a hardware protected key (i.e. symmetric wrapping key) YU does not disclose a permanent per-part device key; and wherein the Symmetric Wrapping Key (SWK) is generated using the permanent per-part device key.
Kwan teaches a hardware protected key (i.e. symmetric wrapping key) and wherein the Symmetric Wrapping Key (SWK) is generated using the permanent per-part device key (see Kwan paragraph 0027 i.e. The DRM module may retrieve a storage key, SK, which may be a permanent private storage key owned by the DRM module and generate a storage session key, SSK. The DRM module may encrypt or wrap the subject private key, SPrivK, with the storage session key, SSK, to arrive at a wrapped storage private key, SSK(SPrivK)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify YU in view of Kwan to have generated the used a permanent private storage key owned by the module to generate a session key as one of many ways to generate a session key (see Kwan paragraph 0027). Therefore one would have been motivated to have used a permanent device key to generate a session key.
With respect to claim 43 Yu and Kwan teach the device of claim 41, wherein the device comprises one of a Graphic Processor Unit (GPU), a General Purpose GPU (GP-GPU), a Tensor Processing Unit (TPU), a Data Processor Unit (DPU), an Infrastructure Processing Unit (IPU), a SmartNIC (network interface controller), an Artificial Intelligence (AI) processor or an Al inference unit (see YU section II System Design i.e. Key Provision/Sharing: Symmetric Wrapping Kev (SWK) is provisioned to Intel® PTT on the cloud platform via a key provision app KPTtool, which follows TPM key export-import protocol as defined in TPM 2.0 specifications. The user’s original clear private kev (CPK) is encrypted using the SWK to output a wrapped private key (WPK) in a trusted environment inside the KMS, WPK, when deployed and shared on compute nodes, is now secured and protected by SWK. A new private key PEM format following ASN. 1 syntax is defined in order to specify the process of generating a WPK from its CPK. The new PEM format specifies details such as the algorithm and key size of the SWK, the IV and etc. New PEM format of RSA private key is defined as below Figure 2:).
With respect to claim 46 Yu teaches a non-transitory machine-readable medium having instruction stored thereon configured to be executed on a processor in a compute platform including one or more hardware devices, wherein execution of the instructions enables the compute platform to:
provision an SWK for a service instance see YU section II System Design i.e. Key Provision/Sharing: Symmetric Wrapping Kev (SWK) is provisioned to Intel® PTT on the cloud platform via a key provision app KPTtool, which follows TPM key export-import protocol as defined in TPM 2.0 specifications. The user’s original clear private kev (CPK) is encrypted using the SWK to output a wrapped private key (WPK) in a trusted environment inside the KMS, WPK, when deployed and shared on compute nodes, is now secured and protected by SWK. A new private key PEM format following ASN. 1 syntax is defined in order to specify the process of generating a WPK from its CPK. The new PEM format specifies details such as the algorithm and key size of the SWK, the IV and etc. New PEM format of RSA private key is defined as below Figure 2:); and
enable only the service instance for which the SWK is provisioned to access the SWK (see YU section II System Design i.e. Runtime: Our prototype is based on a vertical integration of nginx and OpenSSL with Intel® QAT API library, driver and HW engine. WPE is deployed on cloud platform and used in memory instead of CPK. nginx/OpenSSL triggers Intel® PTT to send SWK. to Intel® QAT via internal secure hardware link. Inside Intel®) QAT, WPK is unwrapped to CP, which is used for private key operations. In the whole life, CPE is never exposed in memory of hypervisor or container; and section III Security Analysis and Performance Evaluation).
YU does not disclose a permanent per-part device key and configured to generate one or more Symmetric Wrapping Keys (SWKs) using the permanent per-part device key and store the one or more SWKs on the hardware device.
Kwan teaches a permanent per-part device key and configured to generate one or more Symmetric Wrapping Keys (SWKs) using the permanent per-part device key and store the one or more SWKs on the hardware device (see Kwan paragraph 0027 i.e. The DRM module may retrieve a storage key, SK, which may be a permanent private storage key owned by the DRM module and generate a storage session key, SSK. The DRM module may encrypt or wrap the subject private key, SPrivK, with the storage session key, SSK, to arrive at a wrapped storage private key, SSK(SPrivK)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify YU in view of Kwan to have generated the used a permanent private storage key owned by the module to generate a session key as one of many ways to generate a session key (see Kwan paragraph 0027). Therefore one would have been motivated to have used a permanent device key to generate a session key.
With respect to claim 48 Yu and Kwan teach the non-transitory machine-readable medium of claim 46, wherein the instructions are implemented in one of a host operating system, a Virtual Machine Monitor (VMM), a hypervisor, a virtual machine (VM), or a container (see YU section II System Design i.e. Intel® KPT is a now feature in Intel® servers based on the Intel® Xeon® Scalable Processor Family Intel KPT works in conjunction with Intel platform feature called Intel Platform Trust Technology (PTT), which is used to store user secrets (keys) at rest. Intel PTT is an Intel implementation of TPM (Trusted Platform Module) and Intel Ouick Assist Technology (QAT) is hardware cryptography accelerator. There is a secure hardware link between Intel® QAT and Intel PPT in Intel C627/C628 Chipset to share keys. Figure 1 describes the system design of this whole solution, which includes two major parts, the key management server (KMS) and the cloud platform running applications based on Intel architecture).
Claims 28 and 42 are rejected under 35 U.S.C. 103 as being unpatentable over YU, Wendian et al. "Protecting Your Own Private Key in Cloud: Security, Scalability and Performance” in view of Kwan et al (US 2007/0288747) in view of Shin (US 2023/0327886).
With respect to claim 28 Yu and Kwan teach the method of claim 27, but do not disclose further comprising generating an Elliptic-curve cryptography (ECC) wrapped private key (WPK) by: applying an ECC algorithm using the SWK to a private key blob including a curve object identifier (Curve_OID) to generate cipher text; and appending an authentication tag to the cipher text.
Shin teaches further comprising generating an Elliptic-curve cryptography (ECC) wrapped private key (WPK) by: applying an ECC algorithm using the SWK to a private key blob including a curve object identifier (Curve_OID) to generate cipher text; and appending an authentication tag to the cipher text (see Shin paragraph 0119 i.e. the contract private key K1 to which the authentication tag is combined may be encrypted with the AES in the GCM mode based on the ECDH shared secret key generated from the public key 412 of the OEM provisioning certificate; also see paragraph 0152 i.e. the EDCH curve may be an elliptic curve cryptography (ECC) curve that the eMSP is to use to generate a session key or seed used to encrypt the contract certificate private key).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify YU and Kwan in further view of Shin to used elliptic curve cryptography (ECC) to encrypt a private key as one of many different encryption algorithms that could be used to encrypt a private key (see shin paragraph 0119). Therefore one would have been motivated to have used and elliptic curve cryptography (ECC) algorithms to encrypt the private key.
With respect to claim 42 Yu and Kwan teaches the device of claim 41, but do not disclose further comprising embedded firmware configured to implement a hardcoded Elliptic-curve cryptography (ECC) parameters table including a curve identifier field and a curve parameters field.
further comprising embedded firmware configured to implement a hardcoded Elliptic-curve cryptography (ECC) parameters table including a curve identifier field and a curve parameters field (see Shin paragraph 0119 i.e. the contract private key K1 to which the authentication tag is combined may be encrypted with the AES in the GCM mode based on the ECDH shared secret key generated from the public key 412 of the OEM provisioning certificate).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify YU and Kwan in further view of Shin to used elliptic curve cryptography (ECC) to encrypt a private key as one of many different encryption algorithms that could be used to encrypt a private key (see shin paragraph 0119). Therefore one would have been motivated to have used and elliptic curve cryptography (ECC) algorithms to encrypt the private key.
Claims 29 and 37 are rejected under 35 U.S.C. 103 as being unpatentable over YU, Wendian et al. "Protecting Your Own Private Key in Cloud: Security, Scalability and Performance” in view of Kwan et al (US 2007/0288747) in view of Hawkes et al (US 2004/0019783).
With respect to claim 29 Yu and Kwan teaches the method of claim 27, further comprising generating an RSA (Rivest-Shamir- Adleman) wrapped private key (WPK) by: applying a symmetric cryptographic algorithm using the SWK to a private key blob to generate cipher text (see YU section II System Design i.e. Key Provision/Sharing: Symmetric Wrapping Kev (SWK) is provisioned to Intel® PTT on the cloud platform via a key provision app KPTtool, which follows TPM key export-import protocol as defined in TPM 2.0 specifications. The user’s original clear private kev (CPK) is encrypted using the SWK to output a wrapped private key (WPK) in a trusted environment inside the KMS, WPK, when deployed and shared on compute nodes, is now secured and protected by SWK. A new private key PEM format following ASN. 1 syntax is defined in order to specify the process of generating a WPK from its CPK. The new PEM format specifies details such as the algorithm and key size of the SWK, the IV and etc. New PEM format of RSA private key is defined as below Figure 2:).
Yu and Kwan do not teach appending an authentication tag to the cipher text.
Hawkes teaches appending an authentication tag to the cipher text (see Hawkes paragraph 0009 i.e. a single authentication tag for verifying both the plaintext portion and the ciphertext portion of the data message).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify YU and Kwan in view of Hawkes to have included an authentication tag as a way to verify both the plaintext and the ciphertext (see Hawkes paragraph 0009). Therefore one would have been motivated to have appending an authentication tag.
With respect to claim 37 Yu and Kwan teaches the compute platform of claim 36, wherein the hardware protected key comprises a Symmetric Wrapping Key (SWK), and wherein the compute platform is further configured to: apply a symmetric cryptograph algorithm using the SWK to a private key blob to generate cipher text (see YU section II System Design i.e. Key Provision/Sharing: Symmetric Wrapping Kev (SWK) is provisioned to Intel® PTT on the cloud platform via a key provision app KPTtool, which follows TPM key export-import protocol as defined in TPM 2.0 specifications. The user’s original clear private kev (CPK) is encrypted using the SWK to output a wrapped private key (WPK) in a trusted environment inside the KMS, WPK, when deployed and shared on compute nodes, is now secured and protected by SWK. A new private key PEM format following ASN. 1 syntax is defined in order to specify the process of generating a WPK from its CPK. The new PEM format specifies details such as the algorithm and key size of the SWK, the IV and etc. New PEM format of RSA private key is defined as below Figure 2:).
Yu and Kwan do not teach appending an authentication tag to the cipher text.
Hawkes teaches appending an authentication tag to the cipher text (see Hawkes paragraph 0009 i.e. a single authentication tag for verifying both the plaintext portion and the ciphertext portion of the data message).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify YU and Kwan in view of Hawkes to have included an authentication tag as a way to verify both the plaintext and the ciphertext (see Hawkes paragraph 0009). Therefore one would have been motivated to have appending an authentication tag.
Claims 31-34, 38-40, 44, 45, 49 and 50 are rejected under 35 U.S.C. 103 as being unpatentable over YU, Wendian et al. "Protecting Your Own Private Key in Cloud: Security, Scalability and Performance” in view of Kwan et al (US 2007/0288747) in view of Smith et al (US 2019/0228166).
With respect to claim 31 Yu and Kwan teach the method of claim 26, but do not disclose further comprising: implementing a table including a plurality of entries, each entry including a unique identifier associated with an application or service instance and a key handle; and enabling an application or service instance associated with a unique identifier to only access entries in the table with a matching unique identifier.
Smith teaches further comprising: implementing a table including a plurality of entries, each entry including a unique identifier associated with an application or service instance and a key handle; and enabling an application or service instance associated with a unique identifier to only access entries in the table with a matching unique identifier (see Smith paragraph 0036 i.e. In the illustrative embodiment, each accelerator device 160, 162 further includes a decryption logic unit 224, which may be embodied as any device or circuitry configured to receive an accelerator key from the secure server 170 with a tenant ID of the client compute device 110 that is requesting workload acceleration via an authenticated channel and read, decrypt, and process the encrypted workload using the accelerator key. In some embodiments, the decryption logic unit 224 may further update a key storage table in response to a receipt of the accelerator key and the tenant ID. Each entry of the key storage table includes an accelerator key and a tenant ID of a client compute device 110 that the client key associated with the accelerator key was assigned to. In some embodiments, the key storage table may also include a process address space id (PASID). The key storage table may be used to keep track of the accelerator key and the client key pair when the accelerator device 160 receives encrypted workloads from more than one client compute device. In such embodiments, the accelerator device 160 may determine which accelerator key to use to process the encrypted data received from a client compute device 110).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Yu and Kwan in view of Smith to have used a key storage table that includes an accelerator key and a tenant ID of a client device that the client key associated with the accelerator key was assigned to as well is the process address space id (PASID) as a way used to keep track of the accelerator key and the client key pair when the accelerator device receives encrypted workloads from more than one client compute device process address space id (PASID) (see Smith paragraph 0025). Therefore one would have been motivated to have a key storage table may be used to keep track of the accelerator key and the client key pair.
With respect to claim 32 Yu, Kwan and Smith teach the method of claim 31, wherein the table is implemented in the hardware component including the per-part device key (see YU section II System Design i.e. Key Provision/Sharing: Symmetric Wrapping Kev (SWK) is provisioned to Intel® PTT on the cloud platform via a key provision app KPTtool, which follows TPM key export-import protocol as defined in TPM 2.0 specifications. The user’s original clear private kev (CPK) is encrypted using the SWK to output a wrapped private key (WPK) in a trusted environment inside the KMS, WPK, when deployed and shared on compute nodes, is now secured and protected by SWK. A new private key PEM format following ASN. 1 syntax is defined in order to specify the process of generating a WPK from its CPK. The new PEM format specifies details such as the algorithm and key size of the SWK, the IV and etc. New PEM format of RSA private key is defined as below Figure 2:).
With respect to claim 33 Yu, Kwan and Smith teach the method of claim 31, wherein the unique identifier associated with an application or service comprises a Process Address Space Identifier (PASID) (see Smith paragraph 0036 i.e. In the illustrative embodiment, each accelerator device 160, 162 further includes a decryption logic unit 224, which may be embodied as any device or circuitry configured to receive an accelerator key from the secure server 170 with a tenant ID of the client compute device 110 that is requesting workload acceleration via an authenticated channel and read, decrypt, and process the encrypted workload using the accelerator key. In some embodiments, the decryption logic unit 224 may further update a key storage table in response to a receipt of the accelerator key and the tenant ID. Each entry of the key storage table includes an accelerator key and a tenant ID of a client compute device 110 that the client key associated with the accelerator key was assigned to. In some embodiments, the key storage table may also include a process address space id (PASID). The key storage table may be used to keep track of the accelerator key and the client key pair when the accelerator device 160 receives encrypted workloads from more than one client compute device. In such embodiments, the accelerator device 160 may determine which accelerator key to use to process the encrypted data received from a client compute device 110).
With respect to claim 34 Yu, Kwan and Smith teach the method of claim 31, wherein the table comprises a first table and a key handle is used to access a hardware protected key stored on the hardware component having the per-part device key, further comprising: implementing a second table mapping service instances to key handles; and enabling a service instance to obtain a hardware protected key from the hardware component using the second table (see Smith paragraph 0036 i.e. In the illustrative embodiment, each accelerator device 160, 162 further includes a decryption logic unit 224, which may be embodied as any device or circuitry configured to receive an accelerator key from the secure server 170 with a tenant ID of the client compute device 110 that is requesting workload acceleration via an authenticated channel and read, decrypt, and process the encrypted workload using the accelerator key. In some embodiments, the decryption logic unit 224 may further update a key storage table in response to a receipt of the accelerator key and the tenant ID. Each entry of the key storage table includes an accelerator key and a tenant ID of a client compute device 110 that the client key associated with the accelerator key was assigned to. In some embodiments, the key storage table may also include a process address space id (PASID). The key storage table may be used to keep track of the accelerator key and the client key pair when the accelerator device 160 receives encrypted workloads from more than one client compute device. In such embodiments, the accelerator device 160 may determine which accelerator key to use to process the encrypted data received from a client compute device 110).
With respect to claim 38 Yu and Kwan teach the compute platform of claim 36, but do not disclose further configured to: implement a table including a plurality of entries, each entry including a unique identifier associated with an application or service instance and a key handle; and enable an application or service instance associated with a unique identifier to only access entries in the table with a matching unique identifier.
Smith teaches further configured to: implement a table including a plurality of entries, each entry including a unique identifier associated with an application or service instance and a key handle; and enable an application or service instance associated with a unique identifier to only access entries in the table with a matching unique identifier (see Smith paragraph 0036 i.e. In the illustrative embodiment, each accelerator device 160, 162 further includes a decryption logic unit 224, which may be embodied as any device or circuitry configured to receive an accelerator key from the secure server 170 with a tenant ID of the client compute device 110 that is requesting workload acceleration via an authenticated channel and read, decrypt, and process the encrypted workload using the accelerator key. In some embodiments, the decryption logic unit 224 may further update a key storage table in response to a receipt of the accelerator key and the tenant ID. Each entry of the key storage table includes an accelerator key and a tenant ID of a client compute device 110 that the client key associated with the accelerator key was assigned to. In some embodiments, the key storage table may also include a process address space id (PASID). The key storage table may be used to keep track of the accelerator key and the client key pair when the accelerator device 160 receives encrypted workloads from more than one client compute device. In such embodiments, the accelerator device 160 may determine which accelerator key to use to process the encrypted data received from a client compute device 110).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Yu and Kwan in view of Smith to have used a key storage table that includes an accelerator key and a tenant ID of a client device that the client key associated with the accelerator key was assigned to as well is the process address space id (PASID) as a way used to keep track of the accelerator key and the client key pair when the accelerator device receives encrypted workloads from more than one client compute device process address space id (PASID) (see Smith paragraph 0025). Therefore one would have been motivated to have a key storage table may be used to keep track of the accelerator key and the client key pair.
With respect to claim 39 Yu, Kwan and Smith teach the compute platform of claim 38, wherein the hardware components comprises a processor that is configured to execute software processes and associate a respective Process Address Space Identifier (PASID) for a software process, and wherein the unique identifier associated with an application or service comprises a Process Address Space Identifier (PASID) (see Smith paragraph 0036 i.e. In the illustrative embodiment, each accelerator device 160, 162 further includes a decryption logic unit 224, which may be embodied as any device or circuitry configured to receive an accelerator key from the secure server 170 with a tenant ID of the client compute device 110 that is requesting workload acceleration via an authenticated channel and read, decrypt, and process the encrypted workload using the accelerator key. In some embodiments, the decryption logic unit 224 may further update a key storage table in response to a receipt of the accelerator key and the tenant ID. Each entry of the key storage table includes an accelerator key and a tenant ID of a client compute device 110 that the client key associated with the accelerator key was assigned to. In some embodiments, the key storage table may also include a process address space id (PASID). The key storage table may be used to keep track of the accelerator key and the client key pair when the accelerator device 160 receives encrypted workloads from more than one client compute device. In such embodiments, the accelerator device 160 may determine which accelerator key to use to process the encrypted data received from a client compute device 110).
With respect to claim 40 Yu, Kwan and Smith teach the compute platform of claim 38, wherein the table comprises a first table and a key handle is used to access a hardware protected key stored on the hardware component with the per-part device key, and wherein the compute platform is further configured to: implement a second table mapping service instances to key handles; and enable a service instance to obtain a hardware protected key from the hardware component using the second table (see Smith paragraph 0036 i.e. In the illustrative embodiment, each accelerator device 160, 162 further includes a decryption logic unit 224, which may be embodied as any device or circuitry configured to receive an accelerator key from the secure server 170 with a tenant ID of the client compute device 110 that is requesting workload acceleration via an authenticated channel and read, decrypt, and process the encrypted workload using the accelerator key. In some embodiments, the decryption logic unit 224 may further update a key storage table in response to a receipt of the accelerator key and the tenant ID. Each entry of the key storage table includes an accelerator key and a tenant ID of a client compute device 110 that the client key associated with the accelerator key was assigned to. In some embodiments, the key storage table may also include a process address space id (PASID). The key storage table may be used to keep track of the accelerator key and the client key pair when the accelerator device 160 receives encrypted workloads from more than one client compute device. In such embodiments, the accelerator device 160 may determine which accelerator key to use to process the encrypted data received from a client compute device 110).
With respect to claim 44 Yu and Kwan teach the device of claim 41, but do not disclose further comprising embedded logic to: implement a Wrapping Key Table (WKT) including a plurality of WKT entries, wherein each WKT entry comprises a SWK and a unique identifier; and enforce an access mechanism that employs the unique identifiers in the WKT entries to enable access to associated SWKs.
Smith teaches further comprising embedded logic to: implement a Wrapping Key Table (WKT) including a plurality of WKT entries, wherein each WKT entry comprises a SWK and a unique identifier; and enforce an access mechanism that employs the unique identifiers in the WKT entries to enable access to associated SWKs (see Smith paragraph 0036 i.e. In the illustrative embodiment, each accelerator device 160, 162 further includes a decryption logic unit 224, which may be embodied as any device or circuitry configured to receive an accelerator key from the secure server 170 with a tenant ID of the client compute device 110 that is requesting workload acceleration via an authenticated channel and read, decrypt, and process the encrypted workload using the accelerator key. In some embodiments, the decryption logic unit 224 may further update a key storage table in response to a receipt of the accelerator key and the tenant ID. Each entry of the key storage table includes an accelerator key and a tenant ID of a client compute device 110 that the client key associated with the accelerator key was assigned to. In some embodiments, the key storage table may also include a process address space id (PASID). The key storage table may be used to keep track of the accelerator key and the client key pair when the accelerator device 160 receives encrypted workloads from more than one client compute device. In such embodiments, the accelerator device 160 may determine which accelerator key to use to process the encrypted data received from a client compute device 110).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Yu and Kwan in view of Smith to have used a key storage table that includes an accelerator key and a tenant ID of a client device that the client key associated with the accelerator key was assigned to as well is the process address space id (PASID) as a way used to keep track of the accelerator key and the client key pair when the accelerator device receives encrypted workloads from more than one client compute device process address space id (PASID) (see Smith paragraph 0025). Therefore one would have been motivated to have a key storage table may be used to keep track of the accelerator key and the client key pair.
With respect to claim 45 Yu, Kwan and Smith teach the device of claim 44, wherein the device comprises a central processing unit (CPU) that is configured to execute software processes and associate a respective Process Address Space Identifier (PASID) for a software process, and further where the unique identifiers in the WKT comprises PASIDs (see Smith paragraph 0036 i.e. In the illustrative embodiment, each accelerator device 160, 162 further includes a decryption logic unit 224, which may be embodied as any device or circuitry configured to receive an accelerator key from the secure server 170 with a tenant ID of the client compute device 110 that is requesting workload acceleration via an authenticated channel and read, decrypt, and process the encrypted workload using the accelerator key. In some embodiments, the decryption logic unit 224 may further update a key storage table in response to a receipt of the accelerator key and the tenant ID. Each entry of the key storage table includes an accelerator key and a tenant ID of a client compute device 110 that the client key associated with the accelerator key was assigned to. In some embodiments, the key storage table may also include a process address space id (PASID). The key storage table may be used to keep track of the accelerator key and the client key pair when the accelerator device 160 receives encrypted workloads from more than one client compute device. In such embodiments, the accelerator device 160 may determine which accelerator key to use to process the encrypted data received from a client compute device 110).
With respect to claim 49 YU and Kwan teach the non-transitory machine-readable medium of claim 46, but do not disclose wherein execution of the instructions on the processor further enables the compute platform to: generate a service instance - key handle mapping table comprising a service instance field and a key handle field; and in conjunction with allocating an SWK to the service instance, adding an entry to the service instance - key handle mapping table including an identifier associated with the service instance and a key handle to the SWK.
Smith teaches wherein execution of the instructions on the processor further enables the compute platform to: generate a service instance - key handle mapping table comprising a service instance field and a key handle field; and in conjunction with allocating an SWK to the service instance, adding an entry to the service instance - key handle mapping table including an identifier associated with the service instance and a key handle to the SWK (see Smith paragraph 0036 i.e. In the illustrative embodiment, each accelerator device 160, 162 further includes a decryption logic unit 224, which may be embodied as any device or circuitry configured to receive an accelerator key from the secure server 170 with a tenant ID of the client compute device 110 that is requesting workload acceleration via an authenticated channel and read, decrypt, and process the encrypted workload using the accelerator key. In some embodiments, the decryption logic unit 224 may further update a key storage table in response to a receipt of the accelerator key and the tenant ID. Each entry of the key storage table includes an accelerator key and a tenant ID of a client compute device 110 that the client key associated with the accelerator key was assigned to. In some embodiments, the key storage table may also include a process address space id (PASID). The key storage table may be used to keep track of the accelerator key and the client key pair when the accelerator device 160 receives encrypted workloads from more than one client compute device. In such embodiments, the accelerator device 160 may determine which accelerator key to use to process the encrypted data received from a client compute device 110).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Yu and Kwan in view of Smith to have used a key storage table that includes an accelerator key and a tenant ID of a client device that the client key associated with the accelerator key was assigned to as well is the process address space id (PASID) as a way used to keep track of the accelerator key and the client key pair when the accelerator device receives encrypted workloads from more than one client compute device process address space id (PASID) (see Smith paragraph 0025). Therefore one would have been motivated to have a key storage table may be used to keep track of the accelerator key and the client key pair.
With respect to claim 50 YU, Kwan and Smith teach the non-transitory machine-readable medium of claim 49, wherein the compute platform comprises a plurality of hardware devices configured with respective permanent per-part device keys and configured to generate one or more Symmetric Wrapping Keys (SWKs) using the hardware device's permanent per-part device key and store the one or more SWKs on the hardware device, wherein the service instance key handle mapping table further includes a device field, and wherein execution of the instructions further enables the compute platform to:
provision an SWK on one of the plurality of hardware devices for a service instance (see YU section II System Design i.e. Key Provision/Sharing: Symmetric Wrapping Kev (SWK) is provisioned to Intel® PTT on the cloud platform via a key provision app KPTtool, which follows TPM key export-import protocol as defined in TPM 2.0 specifications. The user’s original clear private kev (CPK) is encrypted using the SWK to output a wrapped private key (WPK) in a trusted environment inside the KMS, WPK, when deployed and shared on compute nodes, is now secured and protected by SWK. A new private key PEM format following ASN. 1 syntax is defined in order to specify the process of generating a WPK from its CPK. The new PEM format specifies details such as the algorithm and key size of the SWK, the IV and etc. New PEM format of RSA private key is defined as below Figure 2:); and
add an entry to the service instance key handle mapping table including an identifier associated with the service instance, a key handle to the SWK, and a device identifier in the device field that identifies the hardware device (see Smith paragraph 0036 i.e. In the illustrative embodiment, each accelerator device 160, 162 further includes a decryption logic unit 224, which may be embodied as any device or circuitry configured to receive an accelerator key from the secure server 170 with a tenant ID of the client compute device 110 that is requesting workload acceleration via an authenticated channel and read, decrypt, and process the encrypted workload using the accelerator key. In some embodiments, the decryption logic unit 224 may further update a key storage table in response to a receipt of the accelerator key and the tenant ID. Each entry of the key storage table includes an accelerator key and a tenant ID of a client compute device 110 that the client key associated with the accelerator key was assigned to. In some embodiments, the key storage table may also include a process address space id (PASID). The key storage table may be used to keep track of the accelerator key and the client key pair when the accelerator device 160 receives encrypted workloads from more than one client compute device. In such embodiments, the accelerator device 160 may determine which accelerator key to use to process the encrypted data received from a client compute device 110).
Claim 47 are rejected under 35 U.S.C. 103 as being unpatentable over YU, Wendian et al. "Protecting Your Own Private Key in Cloud: Security, Scalability and Performance” in view of Kwan et al (US 2007/0288747) in view of Schmatz et al (US 11,265,160).
With respect to claim 47 Yu and Kwan teaches the non-transitory machine-readable medium of claim 46, but does not disclose wherein the instructions comprise a shim layer operating as an API (Application Program Interface) adaptor between a cryptographic library and a key protection service API.
Schmatz teaches wherein the instructions comprise a shim layer operating as an API (Application Program Interface) adaptor between a cryptographic library and a key protection service API (see Schmatz column 2 lines 19-46 i.e. This method involves a key management system, which notably comprises a hardware security module (HSM) equipped with a secure memory. The system further includes a HSM driver, implementing an application programming interface, or API (e.g., implemented as an API library), interfaced with the HSM to provide handles to cryptographic objects stored on the secure memory of the HSM. In addition, a shim layer is interfaced with the HSM driver. The shim layer is nevertheless configured to enable a client application to interact with the HSM via the HSM driver (i.e., for the HSM to manage cryptographic objects for the client application), notwithstanding the presence of the shim layer. Moreover, the system includes external memory storage means, which reside outside the HSM and are interfaced with the shim layer. The method basically comprises, at the shim layer, instructing to: (i) encrypt cryptographic objects from the HSM (this operation being performed with the help of the HSM driver, i.e., via the latter) and store the resulting encrypted objects at respective memory locations on the external storage means, in order to be able to free up memory space on the secure memory; and (ii) store, on the external storage means, handles to such cryptographic objects along with references to said respective memory locations).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify YU and Kwan in view of Schmatz to have used a shim layer to enable a client application to interact with the HSM via the HSM driver (see Schmatz column 2 lines 19-46).
Allowable Subject Matter
Claim 30 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
With respect to claim 30 the prior art does not teach the method of claim 29, wherein the RSA WPK comprises an RSA Chinese Remainder Theorem (CRT) WPK, and wherein the private key blob includes a concatenation of prime1(p), prime2(q), exponent1(dP), exponent1(dQ), coefficient(qinv) and publicExponent(e).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEVIN E ALMEIDA whose telephone number is (571)270-1018. The examiner can normally be reached on Monday-Thursday from 7:30 A.M. to 5:00 P.M. The examiner can also be reached on alternate Fridays from 7:30 A.M. to 4:00 P.M.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Rupal Dharia, can be reached on 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/DEVIN E ALMEIDA/Examiner, Art Unit 2492 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492