DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after 16 March 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to papers filed on 11 July 2024. Claims 1, 12, and 16 are independent. Claims 1-20 are pending.
Priority
Acknowledgment is made of Applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). This application claims the foreign priority of foreign patent application KR10-2024-0012371, filed 26 January 2024. Receipt is acknowledged of certified copies required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11 July 2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
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:
“… host attestation module … configured to …” in claims 2-6, 10, and 16-18.
“… device attestation module … configured to …” in claims 7-8.
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 § 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 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 1 is rejected under 35 U.S.C. 103 as being unpatentable over Duval, US 2022/0350894 A1 (hereinafter, “Duval ‘894”), in view of Ruan et al., US 2022/0321361 A1 (hereinafter, “Ruan ‘361”), and further in view of Paatero, US 2003/0163700 A1 (hereinafter, “Paatero ‘700”).
As per claim 1: Duval ‘894 discloses:
An electronic system, comprising: (a computing system 100 comprising a host system 120 and a memory sub-system 110, where the memory sub-system 110 may be a storage device such as a solid-state drive (SSD), a flash drive, a universal serial bus (USB) flash drive, or a hard disk drive (HDD) [Duval ‘894, ¶¶24-25; Fig.1])
a storage device configured to generate a device public key and a device private key based on a device compound device identifier (CDI) generated from a device DICE (Device Identifier Composition Engine) (a memory sub-system 110 (storage device) having a security manager 113, where a unique device secret (UDS) stored in the memory device is used, following algorithms defined by device identity composition engine (DICE) and the robust internet-of-things (RIoT) standards, to generate a cryptographic key at boot time based on a combination of the UDS and other data, and where the security manager combines identifiers of components with the identifier of the secure memory device to produce a pair of a private key and a public key, and where the keys are referred to as DICE device ID keys [Duval ‘894, ¶¶12-13, 15, 22; Figs.1-3]),
and a host device (a host system 120 comprising a processing device 118 and a controller 116 [Duval ‘894, ¶¶24, 28; Fig.1]) configured to
As stated above, Duval ‘894 does not explicitly disclose the limitations “... generate a host certificate including a first device signature generated by signing a host public key with the device private key in response to receiving a request of generating the host certificate including the host public key, and send a request of generating a device certificate including the host certificate and the device public key; ... generate the host public key and a host private key based on a host CDI generated by a host DICE, generate the device certificate including a first host signature generated by signing the device public key with the host private key in response to the request of generating the device certificate, and send the device certificate to the storage device.”
Ruan ‘361, however, discloses:
…
… generate the host public key and a host private key based on a host CDI generated by a host DICE (a FIPS-compliant DICE certificate chain architecture for embedded systems including processors, where a DICE generates an asymmetric key pair (i.e., an ECDSA private key and a corresponding public key) from a CDI for each DICE layer, and where the CDI is the result of a one-way function that accepts as input the TCI of the next component and the CDI value received from the previous component, and where the CDI is derived from a Unique Device Secret (UDS) [Ruan ‘361, ¶¶15, 34, 42, 49, 52; Figs.2A-2B, 3]),
.
Duval ‘894 and Ruan ‘361 are analogous art because they are from the same field of endeavor, namely that of device authentication and attestation using DICE-based key generation architectures. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 and Ruan ‘361 before them, to modify the system in Duval ‘894 to include the teachings of Ruan ‘361, namely to implement the host system of Duval ‘894 to include a DICE architecture, as disclosed in Ruan ‘361, where the host generates a host public key and a host private key based on a host CDI generated by a host DICE. A motivation for doing so would be to provide a hardware root of trust for the host device, thereby enabling both the storage device and the host device to derive their keys from DICE-based hardware, and to construct certificate chains on embedded systems that link security states and transitions to layer-specific attestation keys (see Ruan ‘361, ¶¶15, 17, 34-35).
As stated above, Duval ‘894 in view of Ruan ‘361 does not explicitly disclose the limitations “... generate a host certificate including a first device signature generated by signing a host public key with the device private key in response to receiving a request of generating the host certificate including the host public key, and send a request of generating a device certificate including the host certificate and the device public key; ... generate the device certificate including a first host signature generated by signing the device public key with the host private key in response to the request of generating the device certificate, and send the device certificate to the storage device.”
Paatero ‘700, however, discloses:
… generate a host certificate including a first device signature generated by signing a host public key with the device private key in response to receiving a request of generating the host certificate including the host public key (a wireless device 36 having a wireless identity module (WIM) 38 containing a private key, where a PC 10 generates its own private-public key pair and places the user generated public key in a user generated certificate, and where the user generated certificate is transferred to the wireless device 36, and where a certificate signing module 40 of the wireless device signs the user generated certificate by hashing the certificate data and encrypting the hash value using the private key of the wireless device within WIM 38 [Paatero ‘700, ¶¶8, 27-28, 34, 42; Figs.2a, 5]),
and send a request of generating a device certificate including the host certificate and the device public key (the signed user generated certificate is transferred back to the PC, where the signed certificate and associated key information are communicated for establishing identity and secure communication between the devices [Paatero ‘700, ¶¶29, 37, 43]);
... generate the device certificate including a first host signature generated by signing the device public key with the host private key in response to the request of generating the device certificate, and send the device certificate to the storage device (mutual certificate-based authentication between the two devices; as stated above, Paatero ‘700 discloses the mechanism of a first device signing a certificate containing a second device’s public key using the first device’s private key [Paatero ‘700, ¶¶8, 27-28, 34, 42; Figs.2a, 5])
Duval ‘894 (modified by Ruan ‘361) and Paatero ‘700 are analogous art because they are from the same field of endeavor, namely that of establishing trust between devices using public key cryptography and certificate-based authentication. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361) and Paatero ‘700 before them, to modify the system in Duval ‘894 (modified by Ruan ‘361) to include the teachings of Paatero ‘700, namely to implement the authentication process between the storage device and the host device of Duval ‘894 such that the storage device signs a certificate for the host device’s public key using the storage device’s private key, as taught by the certificate-signing mechanism of Paatero ‘700 where a first device signs a certificate for a second device’s public key using the first device’s private key; and further to apply this certificate-signing mechanism in the reverse direction such that the host device signs a certificate for the storage device’s public key using the host device’s private key and returns the signed certificate to the storage device. A motivation for doing so would be to enable the storage device and the host device to each certify the other’s public key and establish mutual trust without relying on an external Certification Authority at runtime, thereby simplifying the authentication process between the two devices (see Paatero ‘700, ¶¶6, 26, 43).
Claims 2-11 and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Duval ‘894, in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata et al., US 2017/0366359 A1 (hereinafter, “Scarlata ‘359”), and further in view of Sibert et al., US 2020/0159966 A1 (hereinafter, “Sibert ‘966”).
As per claim 2: Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700 discloses all limitations of claim 1, as stated above, from which claim 2 is dependent upon. Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700 does not explicitly disclose the limitations of claim 2. Scarlata ‘359, however, discloses:
wherein the host device includes: a host processor configured to execute an application (a host system 110 including one or more processor devices 205 and a set of applications (e.g., 220, 225, 230), where one or more of the applications may be secured using a secure enclave 235 [Scarlata ‘359, ¶¶28-29; Fig.2]),
and a host attestation module (a quoting enclave 255 provided on the host system 110, where the quoting enclave 255 reliably measures or assesses an application 230 and/or the corresponding application enclave 235 and signs the measurement with an attestation key [Scarlata ‘359, ¶¶30, 32; Figs.2, 4])
configured to generate a first measurement value of the application in response to the request of generating the application certificate (the quoting enclave 255 can measure or identify attributes of the application and/or application enclave, where the quoting enclave can provide this information in a quote containing data, at least a portion of which is signed using the attestation key at the quoting enclave [Scarlata ‘359, ¶¶30, 32; Figs.2, 4]),
generate a second host signature by signing the first measurement value with the host private key (the quoting enclave signs the measurement using an attestation key, and where secure enclaves enable a host system platform to measure a corresponding application’s trusted code and produce a signed attestation, rooted in the processor, that includes this measurement [Scarlata ‘359, ¶¶28, 30, 32; Figs.2, 4]),
Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) and Scarlata ‘359 are analogous art because they are from the same field of endeavor, namely that of platform security and attestation using hardware roots of trust. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) and Scarlata ‘359 before them, to modify the host device of Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) to include the teachings of Scarlata ‘359, namely to implement a host attestation module (i.e., a quoting enclave) on the host device that measures applications executing on the host processor and generates signed attestation data including the measurement values. A motivation for doing so would be to enable the host device to verify the integrity and authenticity of applications prior to granting them access to sensitive resources such as the storage device, thereby guarding against insecure, malicious, and faulty transactions by confirming that applications have not been improperly modified (see Scarlata ‘359, ¶¶27-29, 32).
As stated above, Duval ‘894 in view of Ruan ‘361 and Paatero ‘700, and further in view of Scarlata ‘359, does not explicitly disclose the limitations “... generate an application public key and an application private key based on an application ID, and send a request of generating an application certificate including the application public key; ... and generate the application certificate including the first measurement value, the application public key, and the second host signature.”
Sibert ‘966, however, discloses:
… generate an application public key and an application private key based on an application ID (an application 122 includes metadata 230 having an application identifier 232, where application identifier 232 is a value that uniquely identifies application 122 such as a name of the application, a version number, a random value, or a combination thereof, and where in response to receiving metadata 230, SEP 130 may verify that it correctly corresponds to the application 122, and if the verification is successful, SEP 130 may generate a public key pair, and where the derived keys are unique to an application 122 on device 100 (or even unique to the version of application 122), and where key storage 360 includes metadata 362 about keys 132 usable to retrieve keys 132 such as their associated application identifiers [Sibert ‘966, ¶¶33, 35, 50; Figs.2A, 3]),
and send a request of generating an application certificate including the application public key (the application 122 sends an enrollment request 242 to SEP 130, where the request 242 includes metadata 230, and where enrollment may also include SEP 130 generating a certificate for the public key pair, in doing so, SEP 130 may be acting as a certificate authority (CA), and where the certificate may include the public key [Sibert ‘966, ¶¶27, 35; Figs.2A-2B]);
… and generate the application certificate including the first measurement value, the application public key, and the second host signature (key certificate 246 includes the public key of the public key pair and a signature generated with the private key (which is application key 132), and where key certificate 246 may further include at least a portion of metadata 230 such as application identifier 232 and/or signed hash values 236, where signed hash values 236 are generated by applying a hash function to program instructions 210 for a valid copy of application 122, and where this certificate may include additional content such as a reference to the developer certificate used in the verification and the signed hash values from the certificate [Sibert ‘966, ¶¶27, 33, 35, 54; Figs.2A-2B]).
Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application attestation and integrity verification using hardware-based secure circuits. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 before them, to modify the system of Duval ‘894 (as modified) to include the teachings of Sibert ‘966, namely to have the host processor generate application-specific key pairs based on the application’s unique identifier, send a request for an application certificate including the application public key to the host attestation module, and have the host attestation module generate the application certificate including the measurement value (i.e., hash values of the application), the application public key, and a signature generated using the host private key. A motivation for doing so would be to enable the system to bind application-specific cryptographic keys to verified application identities and to bundle the application’s integrity measurement, public key, and a trusted signature into a single certificate structure, thereby providing a comprehensive and verifiable attestation of application identity and integrity that a relying party such as the storage device can validate using the host public key (see Sibert ‘966, ¶¶20, 27, 35, 54).
As per claim 3: Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata ‘359, and further in view of Sibert ‘966 discloses all limitations of claims 1-2, as stated above, from which claim 3 is dependent upon. Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700 does not explicitly disclose the limitations of claim 3. Scarlata ‘359, however, discloses:
wherein (the quoting enclave 255 can measure or identify attributes of the application and/or application enclave, and can provide this information in a quote [Scarlata ‘359, ¶¶30, 32; Figs.2, 4])
Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) and Scarlata ‘359 are analogous art because they are from the same field of endeavor, namely that of platform security and attestation using hardware roots of trust. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) and Scarlata ‘359 before them, to modify the host device of Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) to include the teachings of Scarlata ‘359, namely to have the host attestation module generate a fresh measurement of the application when the host processor requests access to the storage device, as disclosed in Scarlata ‘359. A motivation for doing so would be to prevent replay of stale attestation data by using a fresh measurement to ensure the application’s current integrity is verified, together providing robust protection against both replay attacks and runtime application tampering (see Scarlata ‘359, ¶¶30, 32).
As stated above, Duval ‘894 in view of Ruan ‘361 and Paatero ‘700, and further in view of Scarlata ‘359, does not explicitly disclose the limitations “... the host attestation module is configured to generate a first nonce ... in response to receiving a request of accessing the storage device from the host processor, and verify the application executed by the host processor based on the first nonce and the second measurement value.”
Sibert ‘966, however, discloses:
… the host attestation module is configured to generate a first nonce ... in response to receiving a request of accessing the storage device from the host processor (a challenge 252, which may include random data or some other value, is generated in order to prevent a potential replay attack, and the challenge 252 is used in the verification of the application [Sibert ‘966, ¶33; Fig.2A]; furthermore, the verification of the application may include reading program instructions and/or data 220 to generate one or more hash values, which are compared against signed hash values 236 [Sibert ‘966, ¶¶26, 33; Fig.2A]),
and verify the application executed by the host processor based on the first nonce and the second measurement value (in response to receiving a request, SEP 130 may retrieve the appropriate key 132 for application 122 and use the key 132 to generate a digital signature from challenge 252, and where the verification of the application includes comparing hash values generated from the application against signed hash values in the certificate [Sibert ‘966, ¶¶26, 33; Figs.1A, 2A]).
Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application attestation and integrity verification using hardware-based secure circuits. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 before them, to modify the system of Duval ‘894 (as modified) to include the teachings of Sibert ‘966, namely to generate a nonce and a measurement value of the application in response to receiving a request from the host processor to access the storage device, and to verify the application based on the nonce and the measurement value, as disclosed in Sibert ‘966. A motivation for doing so would be to prevent replay attacks and using it in application verification, as well as verifying the application by comparing hash values generated from the application against stored hash values (see Sibert ‘966, ¶¶26, 33).
As per claim 4: Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata ‘359, and further in view of Sibert ‘966 discloses all limitations of claims 1-3, as stated above, from which claim 4 is dependent upon. Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata ‘359 does not explicitly disclose the limitations of claim 4. Sibert ‘966, however, discloses:
wherein when verifying the application, the host processor is configured to send an application signature generated by signing the first nonce with the application private key to the host attestation module (in usage exchange 204A, a challenge 252, which may include random data, is conveyed along with a request 124, and in response to receiving request 124, SEP 130 may use the application key 132 to generate a digital signature from challenge 252, where application key 132 is a private key of a public key pair unique to the application [Sibert ‘966, ¶¶27, 33; Figs.1A, 2A]),
and the host attestation module is configured to obtain a second nonce generated by decrypting the application signature with the application public key (the verifier uses key certificate 246, which includes the public key of the public key pair, to verify attestation 134 (i.e., the digital signature generated from the challenge), where the verification of a digital signature using a public key inherently involves recovering the signed data from the signature [Sibert ‘966, ¶¶27, 33; Fig.2A]),
and verify the application based on the first nonce and the second nonce (if the verification is successful, meaning that application 122 has been verified by SEP 130 as corresponding to application certificate 234, the verifier may proceed to provide a requested service, where the verification confirms that the data recovered from the signature matches the originally issued challenge [Sibert ‘966, ¶33; Fig.2A]).
Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application attestation and integrity verification using hardware-based secure circuits. For the reasons stated in claim 3, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 before them, to modify the system of Duval ‘894 (as modified) to include the teachings of Sibert ‘966.
As per claim 5: Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata ‘359, and further in view of Sibert ‘966 discloses all limitations of claims 1-3, as stated above, from which claim 5 is dependent upon. Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata ‘359 does not explicitly disclose the limitations of claim 5. Sibert ‘966, however, discloses:
wherein when verifying the application, the host attestation module is configured to verify the application based on the second measurement value and the first measurement value included in the application certificate (the verification of application 122 may include SEP 130 (or OS 126) reading program instructions and/or data 220 to generate one or more hash values (i.e., the second measurement value), which are compared against signed hash values 236 included in the application certificate 234 (i.e., the first measurement value included in the application certificate), and where if the hash values generated from the application match the signed hash values in the certificate, the application is considered verified [Sibert ‘966, ¶¶26, 33; Figs.1A, 2A]).
Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application attestation and integrity verification using hardware-based secure circuits. For the reasons stated in claim 3, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 before them, to modify the system of Duval ‘894 (as modified) to include the teachings of Sibert ‘966.
As per claim 6: Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata ‘359, and further in view of Sibert ‘966 discloses all limitations of claims 1-3, as stated above, from which claim 6 is dependent upon. Furthermore, Duval ‘894 discloses:
wherein the host attestation module is configured to send a request of registering the application (the endpoint 205 can register its identity with the server 201 by providing the device ID public key 162, where the registration operation can include the storing of the public key to indicate that the endpoint is an authorized user [Duval ‘894, ¶70; Fig.4])
As stated above, Duval ‘894 does not explicitly disclose the limitations “… including a third host signature generated by signing the second measurement value with the host private key, the second measurement value, and the application certificate … based on a result of verifying the application.”
Scarlata ‘359, however, discloses:
… including a third host signature generated by signing the second measurement value with the host private key (the quoting enclave 255 can measure or identify attributes of the application and/or application enclave and can provide this information in a quote containing data, at least a portion of which is signed using the attestation key at the quoting enclave [Scarlata ‘359, ¶¶30, 32; Figs.2, 4]), …
Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) and Scarlata ‘359 are analogous art because they are from the same field of endeavor, namely that of platform security and attestation using hardware roots of trust. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) and Scarlata ‘359 before them, to modify the host device of Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) to include the teachings of Scarlata ‘359, namely to sign the fresh measurement value of the application with its private key when generating the registration request, as disclosed by Scarlata ‘359. A motivation for doing so would be to include a host signature over the measurement value in the registration request because doing so would enable the storage device to verify the authenticity and integrity of the measurement data using the host public key, ensuring that the measurement value has not been tampered with in transit (see Scarlata ‘359, ¶¶30, 32).
As stated above, Duval ‘894 in view of Ruan ‘361 and Paatero ‘700, and further in view of Scarlata ‘359, does not explicitly disclose the limitations “... the second measurement value, and the application certificate … based on a result of verifying the application.”
Sibert ‘966, however, discloses:
… the second measurement value (SEP 130 may sign hash values generated from application 122 to generate attestation 134, where the hash values are included in the attestation data [Sibert ‘966, ¶28; Fig.1A]), and the application certificate (application 122 may provide key certificate 246 and attestation 134 together to remote server 150 for verification, where key certificate 246 includes the public key and signed hash values [Sibert ‘966, ¶¶27, 33; Figs.1A, 2A]) … based on a result of verifying the application (in response to a successful verification of application 122, SEP 130 is configured to retrieve the corresponding application key 132 and generate a corresponding attestation 134 [Sibert ‘966, ¶28; Fig.1A]).
Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application attestation and integrity verification using hardware-based secure circuits. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 before them, to modify the system of Duval ‘894 (as modified) to include the teachings of Sibert ‘966, namely to include the measurement value and the application certificate in the registration request sent to the storage device, as disclosed by Sibert ‘966. A motivation for doing so would be to bundle the measurement value and the application certificate with the registration request because doing so would provide the storage device with all information necessary to independently verify both the application’s current integrity and the authenticity of its credentials, enabling the storage device to establish a complete record of authorized applications for use in subsequent data access decisions (see Sibert ‘966, ¶¶27-28, 33).
As per claim 7: Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata ‘359, and further in view of Sibert ‘966 discloses all limitations of claims 1-3 and 6, as stated above, from which claim 7 is dependent upon. Furthermore, Duval ‘894 discloses:
wherein the storage device includes a device attestation module (the memory sub-system 110 includes a security manager 113 configured to control access to the memory device 130 and to perform cryptographic operations [Duval ‘894, ¶¶42, 49; Figs.1, 3]) (the endpoint 205 can register its identity with the server 201, where the registration operation can include the storing of the public key to indicate that the endpoint is an authorized user, and the server processes the registration in response to receiving the identity information [Duval ‘894, ¶70; Fig.4]).
As stated above, Duval ‘894 in view of Ruan ‘361 and Paatero ‘700, and further in view of Scarlata ‘359, does not explicitly disclose the limitations “... configured to register information of the application including the second measurement value based on a result of verifying the second host signature and the third host signature included in the application certificate with the host public key …”.
Sibert ‘966, however, discloses:
… configured to register information of the application including the second measurement value (key storage 360 includes metadata 362 about keys 132 usable to retrieve keys 132, such as their associated application identifiers, thereby maintaining per-application stored data [Sibert ‘966, ¶50; Fig.3]) based on a result of verifying the second host signature and the third host signature included in the application certificate with the host public key (remote server 150 verifies attestation 134 using key certificate 246, where the key certificate includes the public key usable to verify the attestation, and if the verification is successful the verifier may proceed to provide a requested service [Sibert ‘966, ¶¶27, 33; Figs.1A, 2A]) …
Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application attestation and integrity verification using hardware-based secure circuits. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 before them, to modify the system of Duval ‘894 (as modified) to include the teachings of Sibert ‘966, namely to configure the device attestation module of Duval ‘894 (as modified) to verify the host signatures using the host public key before registering the application information, and to store per-application data including the measurement value, as disclosed by Sibert ‘966. A motivation for doing so would be to have the storage device verify both host signatures using the host public key before registering the application, because doing so would confirm that the registration data originated from a trusted host attestation module and has not been tampered with, and to store the measurement value as part of the registration record so it can be referenced during subsequent attestation verification to detect any changes to the application (see Sibert ‘966, ¶¶27, 33, 50).
As per claim 8: Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata ‘359, and further in view of Sibert ‘966 discloses all limitations of claims 1-3 and 6-7, as stated above, from which claim 8 is dependent upon. Furthermore, Duval ‘894 discloses:
wherein the device attestation module is configured to send a token (the certificate 165 is generated by the security manager 113 of the memory sub-system 110 and communicated for authentication, where the certificate contains a digital signature 169 signed using the device ID private key 160 [Duval ‘894, ¶¶59-60, 69; Figs.1, 3, 4]).
As stated above, Duval ‘894 in view of Ruan ‘361 does not explicitly disclose the limitations “... including a second device signature generated by signing the application certificate with the device private key and the application certificate …”.
Paatero ‘700, however, discloses:
… including a second device signature generated by signing the application certificate with the device private key (a user generated certificate is signed using the private key of the first system, where the signing is performed by calculating a hash value of the data forming at least part of the user generated certificate and encrypting the hash value using the private key, and the encrypted hash value is appended to the certificate [Paatero ‘700, ¶¶27-28; Figs.2a-2b]) …
Duval ‘894 (modified by Ruan ‘361) and Paatero ‘700 are analogous art because they are from the same field of endeavor, namely that of establishing trust between devices using public key cryptography and certificate-based authentication. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361) and Paatero ‘700 before them, to modify the system in Duval ‘894 (modified by Ruan ‘361) to include the teachings of Paatero ‘700, namely to configure the device attestation module of Duval ‘894 (as modified) to sign the application certificate with the device private key and return it as a token to the host processor, as disclosed by Paatero ‘700. A motivation for doing so would be to have the storage device sign the application certificate with the device private key and return the signed token to the host processor, because the device signature over the application certificate would serve as the storage device’s endorsement that the application has been successfully registered, providing the host processor with a verifiable credential that can be presented in subsequent data access requests to prove that the application has been authorized by the storage device (see Paatero ‘700, ¶¶27-29).
As stated above, Duval ‘894 in view of Ruan ‘361 and Paatero ‘700, and further in view of Scarlata ‘359, does not explicitly disclose the limitations “... and the application certificate …”.
Sibert ‘966, however, discloses:
… and the application certificate (application 122 may provide key certificate 246 together with attestation data for verification, where key certificate 246 includes the public key and signed hash values [Sibert ‘966, ¶¶27, 33; Figs.1A, 2A]) …
Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application attestation and integrity verification using hardware-based secure circuits. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 before them, to modify the system of Duval ‘894 (as modified) to include the teachings of Sibert ‘966, namely to include the application certificate in the token sent to the host processor, as disclosed by Sibert ‘966. A motivation for doing so would be to bundle the application certificate with the device signature in the token, because doing so would provide the host processor with a self-contained credential that includes both the storage device’s endorsement and the application’s certified public key and measurement data, enabling the host processor to present a complete authorization package in subsequent interactions without requiring additional round trips to retrieve the application certificate separately (see Sibert ‘966, ¶¶27, 33).
As per claim 9: Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata ‘359, and further in view of Sibert ‘966 discloses all limitations of claims 1-2, as stated above, from which claim 9 is dependent upon. Furthermore, Duval ‘894 discloses:
wherein the storage device is configured to (the host system 120 can provide data to be stored at the memory sub-system 110 and can request data to be retrieved from the memory sub-system 110, and in response to receiving a request to access the memory device 130, the security manager 113 performs cryptographic operations to verify that the request is from a requester having the cryptographic key authorized for the access, before providing memory data [Duval ‘894, ¶¶49-50; Figs.1, 3]).
As stated above, Duval ‘894 in view of Ruan ‘361 and Paatero ‘700, and further in view of Scarlata ‘359, does not explicitly disclose the limitations “... send a request of attesting an application to the host attestation module …”.
Sibert ‘966, however, discloses:
… send a request of attesting an application to the host attestation module (remote server 150 may request an attestation 134 as a prerequisite to establishing a connection with application 122 or providing any service requested by application 122, and the attestation 134 is a signed challenge issued by remote server 150 and signed using an application key 132 maintained by SEP 130, such that the service provider requires attestation of the application before granting access to a requested service [Sibert ‘966, ¶¶23, 28; Figs.1A, 2A]) …
Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application attestation and integrity verification using hardware-based secure circuits. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 before them, to modify the system of Duval ‘894 (as modified) to include the teachings of Sibert ‘966, namely to configure the storage device of Duval ‘894 (as modified) to send a request of attesting the application to the host attestation module in response to receiving a data access request from the host processor, as disclosed by Sibert ‘966. A motivation for doing so would be to have the storage device send an attestation request to the host attestation module upon receiving a data access request from the host processor, because doing so would ensure that the application’s integrity is verified at the time of each data access request, thereby preventing unauthorized or compromised applications from accessing sensitive data stored on the storage device (see Sibert ‘966, ¶¶23, 28).
As per claim 10: Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata ‘359, and further in view of Sibert ‘966 discloses all limitations of claims 1-2 and 9, as stated above, from which claim 10 is dependent upon. Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700 does not explicitly disclose the limitations of claim 10. Scarlata ‘359, however, discloses:
wherein the host attestation module is configured to generate a third measurement value of the application in response to the request of attesting the application (the quoting enclave 255 can measure or identify attributes of the application and/or application enclave as well as the hosting platform, and can provide this information in a quote containing data, at least a portion of which is signed using the attestation key at the quoting enclave, where the measurement is generated when attestation is requested [Scarlata ‘359, ¶¶30, 32; Figs.2, 4]),
Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) and Scarlata ‘359 are analogous art because they are from the same field of endeavor, namely that of platform security and attestation using hardware roots of trust. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) and Scarlata ‘359 before them, to modify the host device of Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) to include the teachings of Scarlata ‘359, namely to configure the host attestation module of Duval ‘894 (as modified) to generate a fresh measurement of the application in response to an attestation request, as disclosed by Scarlata ‘359. A motivation for doing so would be to generate a new measurement at each attestation request rather than relying solely on a previously stored measurement, because doing so would provide the storage device with current evidence of the application’s integrity, thereby detecting any modifications to the application that may have occurred after initial registration (see Scarlata ‘359, ¶¶30, 32).
As stated above, Duval ‘894 in view of Ruan ‘361 and Paatero ‘700, and further in view of Scarlata ‘359, does not explicitly disclose the limitations “... and send application attestation data including the third measurement value to the storage device.”
Sibert ‘966, however, discloses:
… and send application attestation data including the third measurement value to the storage device (SEP 130 may sign hash values generated from application 122 to generate attestation 134, and application 122 may deliver the attestation 134 to remote server 150 for verification, where the attestation includes hash values and may further include a timestamp [Sibert ‘966, ¶28; Figs.1A]).
Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application attestation and integrity verification using hardware-based secure circuits. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 before them, to modify the system of Duval ‘894 (as modified) to include the teachings of Sibert ‘966, namely to send the application attestation data including the measurement value to the storage device, as disclosed in Sibert ‘966. A motivation for doing so would be to have the host attestation module send the signed attestation data including the fresh measurement value to the storage device, because doing so would provide the storage device with verifiable evidence of the application’s current state, enabling the storage device to make an informed access control decision based on up-to-date integrity information (see Sibert ‘966, ¶28).
As per claim 11: Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata ‘359, and further in view of Sibert ‘966 discloses all limitations of claims 1-2 and 9-10, as stated above, from which claim 11 is dependent upon. Furthermore, Duval ‘894 discloses:
wherein (the security manager 113 can check the integrity of a set of instructions by comparing a hash value computed at the current time with a pre-calculated hash value, and where, if the two hash values agree with each other, the set of instructions can be considered to have not been tampered with [Duval ‘894, ¶43; Fig.1]).
As stated above, Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700 does not explicitly disclose the limitations “… the storage device is configured to generate a shared key for data communication with the application … and the third measurement value included in the application attestation data …”.
Scarlata ‘359, however, discloses:
… … and the third measurement value included in the application attestation data (the quoting enclave provides measurement data describing the application in a quote to the relying party for verification [Scarlata ‘359, ¶¶30, 32; Figs.2, 4]) …
Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) and Scarlata ‘359 are analogous art because they are from the same field of endeavor, namely that of platform security and attestation using hardware roots of trust. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) and Scarlata ‘359 before them, to modify the host device of Duval ‘894 (modified by Ruan ‘361 and Paatero ‘700) to include the teachings of Scarlata ‘359, namely to use the fresh measurement value from the application attestation data as a basis for shared key generation, as disclosed in Scarlata ‘359. A motivation for doing so would be to incorporate the fresh attestation measurement into the shared key derivation process, because doing so would bind the encryption key to the current verified state of the application, ensuring that any subsequent modification to the application would invalidate the shared key and prevent unauthorized access (see Scarlata ‘359, ¶¶30, 32).
As stated above, Duval ‘894 in view of Ruan ‘361 and Paatero ‘700, and further in view of Scarlata ‘359, does not explicitly disclose the limitations “... the storage device is configured to generate a shared key for data communication with the application …”.
Sibert ‘966, however, discloses:
… the storage device is configured to generate a shared key for data communication with the application (after attestation verification, the application generated key 222 is used to establish a secure exchange 254 with remote server 150, such as using key 222 in an elliptic-curve Diffie-Hellman (ECDH) exchange to establish a shared key [Sibert ‘966, ¶¶32, 37-38; Fig.2C]) …
Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application attestation and integrity verification using hardware-based secure circuits. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361, Paatero ‘700, and Scarlata ‘359) and Sibert ‘966 before them, to modify the system of Duval ‘894 (as modified) to include the teachings of Sibert ‘966, namely to generate a shared key for data communication with the application based on a stored measurement value and a fresh measurement value, as disclosed in Sibert ‘966. A motivation for doing so would be to condition shared key generation on successful comparison of stored and fresh measurement values, because doing so would ensure that the storage device establishes encrypted communication channels only with applications whose integrity has been continuously maintained since the time of registration, thereby preventing data leakage to applications that have been modified or compromised after initial registration (see Sibert ‘966, ¶¶37-38, 50).
As per claim 16: Duval ‘894 discloses:
An electronic system, comprising: a host processor; a host attestation module; and a storage device (a computing system 100 comprising a host system 120 having a processing device 118, and a memory sub-system 110 having a controller 115 with a security manager 113, where the security manager 113 is configured to generate a certificate for authenticating the computing system 100 [Duval ‘894, ¶¶12, 18, 21-22, 25, 42; Figs.1, 3-4]),
the host processor configured to execute an application, (the processing device 118 of the host system 120 is configured to execute instructions, including an application program, and the host system 120 sends commands or requests to the memory sub-system 110 for desired access to the memory devices 130 [Duval ‘894, ¶¶30-31, 39, 42, 45]);
the host attestation module configured to the storage device configured to generate a device public key and a device private key based on a device CDI (the memory device 130 stores a unique device secret and, following algorithms defined by DICE, generates a device ID private key 160 and a device ID public key 162 based on a combination of the unique device secret and other data, including a cryptographic measure of the boot loader and identifiers of components, which constitutes a device compound device identifier [Duval ‘894, ¶¶12-13, 15, 21-22, 59; Figs.3-4]),
As stated above, Duval ‘894 does not explicitly disclose the limitations “... the host processor configured to ... generate an application public key and an application private key based on an application ID ... the host attestation module configured to generate a host public key and a host private key based on a host CDI (Compound Device Identifier), generate an application certificate by using the host private key, and send a request of registering the application based on a result of verifying the application certificate in response to the request of accessing the storage device ... generate a host certificate by using the device private key, and register information of the application based on a result of verifying the host certificate and the application certificate in response to the request of registering the application.”
Ruan ‘361, however, discloses:
…
... the host attestation module configured to generate a host public key and a host private key based on a host CDI (Compound Device Identifier) (DICE generates an asymmetric key pair, such as an ECDSA private key and corresponding public key, from a Compound Device Identifier (CDI), where the CDI is derived from a Trusted Compute Base Component Identifier and a unique device secret, and where a certificate is generated based on the derived key pair [Ruan ‘361, ¶¶42, 45, 49, 52-53; Figs.2A-2B, 3]),
Duval ‘894 and Ruan ‘361 are analogous art because they are from the same field of endeavor, namely that of DICE-based authentication using cryptographic keys derived from device identifiers. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 and Ruan ‘361 before them, to modify the system in Duval ‘894 to include the teachings of Ruan ‘361, namely to implement a DICE-based key generation process on the host system of Duval ‘894, as disclosed in Ruan ‘361, where the host system derives a host public key and a host private key from a host CDI. A motivation for doing so would be to provide a FIPS-compliant DICE certificate chain architecture that generates asymmetric key pairs from compound device identifiers, thereby enabling secure attestation of each layer of the system (see Ruan ‘361, ¶¶15, 34, 50).
As stated above, Duval ‘894 in view of Ruan ‘361 does not explicitly disclose the limitations “... the host processor configured to ... generate an application public key and an application private key based on an application ID ... the host attestation module configured to ... generate an application certificate by using the host private key, and send a request of registering the application based on a result of verifying the application certificate in response to the request of accessing the storage device ... the storage device configured to ... generate a host certificate by using the device private key, and register information of the application based on a result of verifying the host certificate and the application certificate in response to the request of registering the application.”
Scarlata ‘359, however, discloses:
…
... the host attestation module configured to ... (a quoting enclave 255 is configured to measure or assess an application and its application enclave 235, sign the measurement with an attestation key, and provide the signed quote to a backend service for verification; the backend service verifies the authenticity of the quote based on the signature included in the quote and, upon verifying the characteristics of the application enclave, grants or denies service [Scarlata ‘359, ¶¶30, 32; Figs.2, 4])
... the storage device configured to ... (the attestation service verifies the authenticity of the quote based on the signature included in the quote signed by the attestation key, and upon further verifying the characteristics of the application enclave included in the quote, the attestation service communicates the results of the attestation to the backend service, which may grant or deny service based on the results [Scarlata ‘359, ¶¶32, 34]) ...
Duval ‘894 (modified by Ruan ‘361) and Scarlata ‘359 are analogous art because they are from the same field of endeavor, namely that of platform attestation and authentication using cryptographic keys. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361) and Scarlata ‘359 before them, to modify the system in Duval ‘894 (modified by Ruan ‘361) to include the teachings of Scarlata ‘359, namely to implement a quoting enclave, as disclosed in Scarlata ‘359, within the host system of Duval ‘894, where the quoting enclave serves as a host attestation module that measures an application, signs the measurement with an attestation key, and provides the signed attestation data to the storage device for verification, and where the storage device registers application information based on the verification result. A motivation for doing so would be to enable the host system to attest to the authenticity and security of applications running on the host, such that the storage device can verify the trustworthiness of the application prior to granting access (see Scarlata ‘359, ¶¶29-30, 32).
As stated above, Duval ‘894 in view of Ruan ‘361 and Scarlata ‘359 does not explicitly disclose the limitations “... the host processor configured to ... generate an application public key and an application private key based on an application ID ... the host attestation module configured to ... generate an application certificate by using the host private key ... the storage device configured to ... generate a host certificate by using the device private key, and ... verifying the host certificate and the application certificate ...”.
Sibert ‘966, however, discloses:
... the host processor configured to ... generate an application public key and an application private key based on an application ID (during enrollment, SEP 130 derives a public key pair having a public key and a private key corresponding to application key 132, where the derived keys are unique to an application 122 on device 100, and where the key derivation is based on metadata 230 including an application identifier 232 that uniquely identifies the application [Sibert ‘966, ¶¶27, 33, 35; Figs.2A-2C])
... the host attestation module configured to ... generate an application certificate by using the host private key (SEP 130 generates a key certificate 246 that includes the public key of the public key pair and a signature generated with the private key, where the certificate may further include signed hash values and application identifier, and where SEP 130 acts as a certificate authority [Sibert ‘966, ¶¶27, 35])
...
Duval ‘894 (modified by Ruan ‘361 and Scarlata ‘359) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application integrity attestation using cryptographic keys. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361 and Scarlata ‘359) and Sibert ‘966 before them, to modify the system in Duval ‘894 (modified by Ruan ‘361 and Scarlata ‘359) to include the teachings of Sibert ‘966, namely to implement the application key generation process of Sibert ‘966 within the host processor of Duval ‘894, where the host processor generates an application public key and an application private key based on an application identifier; and further to implement the certificate generation process of Sibert ‘966 within the host attestation module of Duval ‘894, where the host attestation module generates an application certificate including the application public key signed with a host private key. A motivation for doing so would be to enable per-application key derivation and certificate generation that allows a remote system to verify the integrity and identity of the specific application requesting access (see Sibert ‘966, ¶¶27-28, 33).
As stated above, Duval ‘894 in view of Ruan ‘361, Scarlata ‘359, and Sibert ‘966 does not explicitly disclose the limitations “... the storage device configured to ... generate a host certificate by using the device private key, and ... verifying the host certificate and the application certificate ...”.
Paatero ‘700, however, discloses:
... the storage device configured to ... generate a host certificate by using the device private key (a wireless device 36, having a private key within its WIM module 38, signs a user generated certificate of a personal computer 10 using the private key of the wireless device, where the personal computer generates its own public-private key pair and places the public key in a user generated certificate, and the wireless device signs the user generated certificate with its private key [Paatero ‘700, ¶¶6, 8, 27-28, 42; Figs.2a-2b, 5]), and ... verifying the host certificate and the application certificate (the third party is able to verify the identity of the user of the second system by the authenticated identity of the user of the first system through the signed user generated certificate, and the user generated certificate is authenticated by signing with the private key of the first system [Paatero ‘700, ¶¶7-8, 27]) ...
Duval ‘894 (modified by Ruan ‘361, Scarlata ‘359, and Sibert ‘966) and Paatero ‘700 are analogous art because they are from the same field of endeavor, namely that of authentication using public key infrastructure and certificate-based identity verification. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361, Scarlata ‘359, and Sibert ‘966) and Paatero ‘700 before them, to modify the system in Duval ‘894 (modified by Ruan ‘361, Scarlata ‘359, and Sibert ‘966) to include the teachings of Paatero ‘700, namely to implement a cross-signing mechanism, as disclosed in Paatero ‘700, where the storage device of Duval ‘894 signs a host certificate using the device private key, thereby certifying the host’s public key, and where the storage device verifies both the host certificate and the application certificate prior to registering the application. A motivation for doing so would be to allow one device to establish an authenticated identity on behalf of another device by signing a certificate with a trusted private key, thereby enabling mutual authentication between the storage device and the host device without requiring an external certification authority (see Paatero ‘700, ¶¶6, 8, 27).
As per claim 17: Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata ‘359, and further in view of Sibert ‘966 discloses all limitations of claim 16, as stated above, from which claim 17 is dependent upon. Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata ‘359 does not explicitly disclose the limitations of claim 17. Sibert ‘966, however discloses:
wherein the host attestation module is configured to generate a first nonce in response to the request of accessing the storage device (during a usage exchange, application 122 receives a challenge 252, which may include random data or some other value supplied in order to prevent a potential replay attack [Sibert ‘966, ¶¶36-37; Fig.2A]), receive an application signature generated by signing the first nonce with the application private key from the host processor (application 122 conveys the challenge 252 in a request 124, and SEP 130 uses the application key 132 to generate a digital signature from challenge 252 and provides the signature as attestation 134 [Sibert ‘966, ¶36; Fig.2A]), and compare a second nonce generated by decrypting the application signature with the application public key and the first nonce (remote server 150 verifies attestation 134 using key certificate 246, which includes the public key of the public key pair, where the verification confirms that the digital signature was generated using the corresponding private key, thereby confirming the identity of the application [Sibert ‘966, ¶¶27-28, 36; Figs.2A-2C]).
Duval ‘894 (modified by Ruan ‘361, Scarlata ‘359, and Paatero ‘700) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application integrity attestation using cryptographic keys. For the reasons stated in claim 16, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361, Scarlata ‘359, and Paatero ‘700) and Sibert ‘966 before them, to modify the system in Duval ‘894 (modified by Ruan ‘361, Scarlata ‘359, and Paatero ‘700) to include the teachings of Sibert ‘966.
As per claim 18: Duval ‘894 in view of Ruan ‘361, Scarlata ‘359, Sibert ‘966, and Paatero ‘700 discloses all limitations of claim 16, as stated above, from which claim 18 is dependent upon. Duval ‘894 in view of Ruan ‘361, and further in view of Paatero ‘700, and further in view of Scarlata ‘359 does not explicitly disclose the limitations of claim 18. Sibert ‘966, however discloses:
wherein the application certificate includes a first measurement value of the application (application certificate 234 includes one or more signed hash values 236 generated by applying a hash function to program instructions 210 for a valid copy of application 122 [Sibert ‘966, ¶¶33, 35; Fig.2A]), and the host attestation module is configured to generate a second measurement value of the application in response to the request of accessing the storage device (in response to receiving an enrollment request 242 including metadata 230, SEP 130 reads program instructions and/or data 220 to generate one or more hash values [Sibert ‘966, ¶35; Fig.2A]), and send the request of registering the application based on the first measurement value and the second measurement value included in the application certificate (the generated hash values are compared against the signed hash values 236 included in the application certificate 234, and if the verification is successful, SEP 130 generates a public key pair and returns a corresponding key certificate 246 [Sibert ‘966, ¶¶33, 35; Fig.2A]).
Duval ‘894 (modified by Ruan ‘361, Scarlata ‘359, and Paatero ‘700) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application integrity attestation using cryptographic keys. For the reasons stated in claim 16, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Ruan ‘361, Scarlata ‘359, and Paatero ‘700) and Sibert ‘966 before them, to modify the system in Duval ‘894 (modified by Ruan ‘361, Scarlata ‘359, and Paatero ‘700) to include the teachings of Sibert ‘966.
As per claim 19: Duval ‘894 in view of Ruan ‘361, Scarlata ‘359, Sibert ‘966, and Paatero ‘700 discloses all limitations of claim 16, as stated above, from which claim 19 is dependent upon. Furthermore, Duval ‘894 discloses:
wherein the storage device is configured to decrypt a device signature included in the host certificate with the device public key in response to the request of registering the application (the server 201 determines whether the certificate 165 is valid by decrypting the digital signature 169 using the device ID public key 162 corresponding to the device ID private key 160 used to sign the certificate 165 [Duval ‘894, ¶¶65, 69; Fig.4]), and register information of the application based on a result of decrypting a host signature included in the application certificate with the host public key (when the certificate is authenticated by decrypting the digital signature using the corresponding public key, the endpoint 205 can register its identity with the server 201, where the registration operation includes the storing of the public key to indicate that the endpoint is an authorized user [Duval ‘894, ¶¶69-70; Fig.4]).
As per claim 20: Duval ‘894 in view of Ruan ‘361, Scarlata ‘359, Sibert ‘966, and Paatero ‘700 discloses all limitations of claims 16 and 19, as stated above, from which claim 20 is dependent upon. Furthermore, Duval ‘894 discloses:
wherein the storage device is configured to generate a token by using the device private key (the memory device 130 generates a certificate 165 containing a digital signature 169 signed using the device ID private key 160, where the certificate 165 includes the alias public key 163 and the current monotonic counter value 168 [Duval ‘894, ¶¶15, 59-60, 65; Figs.3-4]), and the host processor is configured to access the storage device by using the token (the certificate 165 is communicated for authentication, and when the certificate is authenticated, the endpoint 205 is permitted to operate and receive services; further, the alias private key 161 available at runtime on the endpoint 205 may be used to sign content that may be verified by the server, thereby enabling authenticated access [Duval ‘894, ¶¶46, 74, 76-77; Fig.4]).
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Duval ‘894 in view of Scarlata ‘359.
As per claim 12: Duval ‘894 discloses:
A storage device, comprising: a nonvolatile memory device configured to store data (a memory sub-system 110 comprising memory devices 130, where the memory devices 130 comprise non-volatile memory devices, such as NAND type flash memory, configured to store data [Duval ‘894, ¶¶11, 33-35; Fig.1]); and
a storage controller configured to receive a request of accessing data from a host processor executing an application of a host device, the request requesting data (a memory sub-system controller 115 configured to receive commands or operations from a host system 120 for desired access to memory devices 130, where the host system 120 includes a processing device 118 configured to execute instructions including software applications [Duval ‘894, ¶¶31, 36, 39, 42; Figs.1-2]),
As stated above, while the memory sub-system controller 115 of Duval ‘894 receives commands from the host system 120 for data access, Duval ‘894 does not explicitly disclose the limitations “... send a request of attesting the application to a host attestation module of the host device, the request of attesting the application requesting attestation of the application, and send the data to the host processor based on a result of verifying application attestation data received from the host attestation module,” as recited in claim 12.
Scarlata ‘359, however, discloses:
... a storage controller configured to ... send a request of attesting the application to a host attestation module of the host device, the request of attesting the application requesting attestation of the application (a backend service 140 requiring that applications attest to their authenticity prior to providing service, where a quoting enclave 255 on the host platform measures or assesses the application and signs the measurement with an attestation key, and where the signed quote is communicated to the backend service for attestation of the authenticity of the application [Scarlata ‘359, ¶¶29-30, 32; Figs.2-4]), and
send the data to the host processor based on a result of verifying application attestation data received from the host attestation module (upon verifying the authenticity of the quote and further verifying the characteristics of the application enclave included in the quote, the backend service provides a level of service or grants/denies service entirely based on whether the application is protected by a trustworthy application enclave [Scarlata ‘359, ¶32; Fig.4]).
Duval ‘894 and Scarlata ‘359 are analogous art because they are from the same field of endeavor, namely that of authentication and attestation in computing systems. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 and Scarlata ‘359 before them, to modify the memory sub-system in Duval ‘894 to include the teachings of Scarlata ‘359, namely to implement the memory sub-system controller 115 of Duval ‘894 to require application attestation from a host-side attestation module, such as the quoting enclave 255 of Scarlata ‘359, prior to granting data access, and to verify the received attestation data before providing the requested data to the host processor. A motivation for doing so would be to guard against insecure, malicious, and faulty transactions by verifying that the application requesting data access is a legitimate instance of the application and not malware (see Scarlata ‘359, ¶¶29, 32).
As per claim 13: Duval ‘894 in view of Scarlata ‘359 discloses all limitations of claim 12, as stated above, from which claim 13 is dependent upon. Duval ‘894 does not explicitly disclose the limitations of claim 13. Scarlata ‘359, however, discloses:
wherein the storage controller is configured to verify the host attestation module based on a result of decrypting a host signature included in the application attestation data with a host public key (the attestation service verifies the authenticity of the quote based on the signature included in the quote, where the signature is signed by the attestation key provided by the attestation key provisioning service, and where the attestation service receives attestation key certificates from the attestation key provisioning service to verify the authenticity of the quote [Scarlata ‘359, ¶32; Fig.4]).
Duval ‘894 and Scarlata ‘359 are analogous art because they are from the same field of endeavor, namely that of authentication and attestation in computing systems. For the reasons stated in claim 12, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 and Scarlata ‘359 before them, to modify the method in Duval ‘894 to include the teachings of Scarlata ‘359.
Claims 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Duval ‘894 in view of Scarlata ‘359, and further in view of Sibert ‘966.
As per claim 14: Duval ‘894 in view of Scarlata ‘359 discloses all limitations of claims 12-13, as stated above, from which claim 14 is dependent upon. Duval ‘894 does not explicitly disclose the limitations of claim 14. Scarlata ‘359, however, discloses:
wherein the storage controller is configured to (the quoting enclave 255 measures or assesses the application 230 and/or the corresponding application enclave 235 and signs the measurement with the attestation key [Scarlata ‘359, ¶¶30, 32; Figs.2-4]) and a second measurement value included in the application attestation data (the quote containing data includes the measurement of the application, where the attestation service verifies the characteristics of the application enclave included in the quote [Scarlata ‘359, ¶32; Fig.4]) from among measurement values of registered applications (the attestation key provisioning service maintains device certificates that map devices to corresponding certificates, and the attestation service receives attestation key certificates and revocation lists to verify the authenticity of the quote [Scarlata ‘359, ¶32; Fig.4]).
Duval ‘894 and Scarlata ‘359 are analogous art because they are from the same field of endeavor, namely that of authentication and attestation in computing systems. For the reasons stated in claim 12, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 and Scarlata ‘359 before them, to modify the method in Duval ‘894 to include the teachings of Scarlata ‘359.
As stated above, Duval ‘894 in view of Scarlata ‘359 does not explicitly disclose the limitation “... generate a shared key based on a first measurement value ... and a second measurement value ...,” as recited in claim 14.
Sibert ‘966, however, discloses:
... wherein the storage controller is configured to generate a shared key based on a first measurement value corresponding to the application ... and a second measurement value included in the application attestation data ... (an application generated key 222 is used to establish a secure exchange 254 with the remote server 150, such as using key 222 in an elliptic-curve Diffie-Hellman (ECDH) exchange to establish a shared key, where the shared key is established in connection with an attestation process that includes verification of hash values 236 generated from program instructions 210 of the application [Sibert ‘966, ¶¶33, 35, 38; Fig.2C]).
Duval ‘894 (modified by Scarlata ‘359) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application integrity verification and attestation in computing systems. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Scarlata ‘359) and Sibert ‘966 before them, to modify the method in Duval ‘894 (modified by Scarlata ‘359) to include the teachings of Sibert ‘966, namely to implement the attestation verification process of Duval ‘894 (modified by Scarlata ‘359) to further generate a shared key for secure data communication with the application, such as using an ECDH exchange as disclosed in Sibert ‘966, where the shared key is generated in connection with verified application measurement values. A motivation for doing so would be to establish a secure communication channel between the application and the service based on verified application integrity, thereby ensuring that only a verified application can decrypt and access the communicated data (see Sibert ‘966, ¶¶20, 38).
As per claim 15: Duval ‘894 in view of Scarlata ‘359, and further in view of Sibert ‘966 discloses all limitations of claims 12-14, as stated above, from which claim 15 is dependent upon. Duval ‘894 in view of Scarlata ‘359 does not explicitly disclose the limitations of claim 15. Sibert ‘966, however, discloses:
wherein the storage controller is configured to send an encryption key generated by encrypting the shared key with an application public key to the host processor (the remote server 150 establishes a secure exchange 254 with the application 122 using an application generated key 222 in an elliptic-curve Diffie-Hellman (ECDH) exchange to establish a shared key, where the application generated key 222 comprises a public key certified by SEP 130 via key certificate 226, and where the shared key is established using the application’s public key for secure communication between the remote server and the application [Sibert ‘966, ¶¶35, 38; Fig.2C]).
Duval ‘894 (modified by Scarlata ‘359) and Sibert ‘966 are analogous art because they are from the same field of endeavor, namely that of application integrity verification and attestation in computing systems. For the reasons stated in claim 14, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Duval ‘894 (modified by Scarlata ‘359) and Sibert ‘966 before them, to modify the method in Duval ‘894 (modified by Scarlata ‘359) to include the teachings of Sibert ‘966.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Brannon, US 20140258711 A1: Application specific certificate deployment may be provided. An application may generate a security certificate comprising a public key and a first private key. The public key may be stored in a shared segment of a memory store, from where it may be retrieved and signed.
Duval, US 20220038266 A1: The host device may also be programmed to receive from a first assembler secure appliance, first trace data based at least in part on the subscriber software and generate trace-derived data using the first trace data and the memory system identification key.
Caceres et al., US 20200021445 A1: A device receives, from an application, a request to access an attestation key stored in a secure element of the device. The device obtains an attestation policy, by which to verify an identity of the application. The device examines an application file to determine whether it satisfies the attestation policy.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAN L KONG whose telephone number is (571)272-2646. The examiner can normally be reached Monday-Thursday 9:00am-7:00pm EST.
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, JUNG (JAY) KIM can be reached on (571)272-3804. 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.
/ALAN L KONG/
Examiner, Art Unit 2494
/JUNG W KIM/Supervisory Patent Examiner, Art Unit 2494