Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is in response to Application with case number 18/422,691, filed on 1/25/2024 in which claims 1-20 are presented for examination.
Status of Claims
Claims 1-20 are pending, of which claims 1, 11 and 16 are in independent form.
Specification
The examiner notes that the Specification does not include any URL links and Trademark terms requiring capitalization.
The examiner notes that the abstract is in narrative form and is limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. In addition, the examiner notes that the abstract is not using legal phraseology often used in patent claims.
IDS
References cited in the IDS filed on 2/23/2024 have been considered by the examiner.
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) 1-4, 7-8, 11-18, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kashid et al. (US 2021/0377020 A1) hereinafter Kashid, in view of Sell et al. (US 2015/0095661 A1) hereinafter Sell.
As to claim 1, Kashid teaches a security apparatus (see Secure Enclave 112 in Fig. 3) comprising:
a security processor (e.g., cryptographic module 345 in Fig. 3) to control access to an encryption key in a memory region (see Key Cache 150 in Fig. 3) protected by the security apparatus (see para. [0049] “Key cache 150, in the illustrated embodiment, maintains mappings between tenant IDs 384-388 and key IDs 352-356 in table 380 and mappings between key IDs 352-356 and key material 392-396 in table 390. For example, in FIG. 3, table 380 maps tenant A to key 1, tenant K to key 2, and tenant C to key 3. Similarly, table 390 maps key 1 to key 1 material, key 2 to key 2 material, and key 3 to key 3 material. Note that table 380 is stored within a first portion of key cache 150, while table 390 is stored in a second portion of key cache 150.”; It is noted that the key in the Key Cache 150 is protected by the access control using the identifier of the requestor and a mapping table linking the identifier and the key identifiers and ultimate locations of the key referenced by the key identifiers.).
Kashid does not explicitly teach but Sell teaches the following limitations -
a memory region controller (see Sell, Fig. 2, memory management unit 111 and/or memory controller 113) to: receive a request for the encryption key from an encryption engine (e.g. memory controller in para. [0047]) associated with a management controller (see Sell, para. [0023] It is noted that the controller managing system address space for the system memory to provide data isolation and privacy through system address aliasing.; see para. [0037]; It is noted that key spaces are defined for system address paces 112 and that memory controller 110 uses a unique encryption key for each key space.; see para. [0039] It is noted that each unique process is assigned a unique isolated memory region associated with a corresponding unique encryption key where the process is mapped to a aliased system address called a key space and each requested access operation is handled with different encryption key.; see para. [0047] “…The memory controller accesses a unique encryption key for the key space at step 714…”) , the request being based on a memory alias provided from the management controller to the encryption engine (see para. [0046] “……At step 708, the MMU maps one or more virtual addresses of the request to an aliased system address space…Moreover, the MMU may utilize page tables or other techniques to determine a process and key space corresponding to a memory request…”), wherein the management controller (e.g., MMU) is to invoke the encryption engine (e.g. memory controller) to encrypt data using the encryption key (see para. [0047] “The memory controller accesses a unique encryption key for the key space at step 714 and encrypts or decrypts the data for the memory request using the unique encryption key for the key space.”), and based on the request (e.g., based on the attributes of the requesting process identity and the memory operation access data), provide the encryption key to the encryption engine (see para. [0047] “The memory controller accesses a unique encryption key for the key space at step 714 and encrypts or decrypts the data for the memory request using the unique encryption key for the key space.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Kashid and Sell before him or her, to modify the scheme of Kashid by including Sell. The suggestion/motivation for doing so would have been to provide data and code isolation, privacy, integrity, and virtualization for the system address spaces associated with requesting application/processes by providing address aliasing and unique key based encryption in different aliased address spaces, as briefly discussed in Sell, para. [0007]-[0009].
As to claim 11, Kashid teaches an encryption apparatus (see Secure Enclave 112 in Fig. 3) comprising: a memory (see Fig. 1, Key Cache 150); and
a controller (e.g., cryptographic module 345 in Fig. 3) to: receive a memory alias for an encryption key in a memory location in a security enclave (see Secure Enclave 112 in Fig. 3; see para. [0049] “Key cache 150, in the illustrated embodiment, maintains mappings between tenant IDs 384-388 and key IDs 352-356 in table 380 and mappings between key IDs 352-356 and key material 392-396 in table 390. For example, in FIG. 3, table 380 maps tenant A to key 1, tenant K to key 2, and tenant C to key 3. Similarly, table 390 maps key 1 to key 1 material, key 2 to key 2 material, and key 3 to key 3 material. It is noted that table 380 is stored within a first portion of key cache 150, while table 390 is stored in a second portion of key cache 150.”; It is noted that the key in the Key Cache 150 is protected by the access control using the identifier of the requestor and a mapping table linking the identifier and the key identifiers and ultimate locations of the key referenced by the key identifiers.; see para. [0070] and Fig. 4, step 420 “Access, using an identifier associated with the particular account, a key cache stored in a secure enclave of a memory of the computing system to determine at least one private key associated with the request, where the key cache stores private keys of a key management system (KMS) for a plurality of accounts.”; The examiner views the requestor identifying information, which indirectly is indicative of the private key in the key cache, as equivalent to the instant application’s memory alias.); receive, based on the memory alias, the encryption key from the security enclave (see Fig. 4, step 4 “Access, using an identifier associated with the particular account, a key cache stored in a secure enclave of a memory of the computing system to determine at least one private key associated with the request, where the key cache stores private keys of a key management system (KMS) for a plurality of accounts.”); store the encryption key in the memory of the encryption apparatus (see para. Fig. 4, step 430, and [0072] and [0073]; It is noted that the private key received from the key cache 150 is stored temporarily in the cryptographic module 345 memory while it’s finishing the cryptographic operation.).
Kashid does not explicitly teach but Sell teaches encrypt data using the encryption key based on invocation of the encryption apparatus by a management controller as part of a security operation performed by the management controller (see Sell, para. [0023] It is noted that the controller managing system address space for the system memory to provide data isolation and privacy through system address aliasing.; see para. [0037]; It is noted that key spaces are defined for system address paces 112 and that memory controller 110 uses a unique encryption key for each key space.; see para. [0039] It is noted that each unique process is assigned a unique isolated memory region associated with a corresponding unique encryption key where the process is mapped to a aliased system address called a key space and each requested access operation is handled with different encryption key.; see para. [0047] “…The memory controller accesses a unique encryption key for the key space at step 714…”; see para. [0047] “The memory controller accesses a unique encryption key for the key space at step 714 and encrypts or decrypts the data for the memory request using the unique encryption key for the key space.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Kashid and Sell before him or her, to modify the scheme of Kashid by including Sell. The suggestion/motivation for doing so would have been to provide data and code isolation, privacy, integrity, and virtualization for the system address spaces associated with requesting application/processes by providing address aliasing and unique key based encryption in different aliased address spaces, as briefly discussed in Sell, para. [0007]-[0009].
As to claim 16, claim 16 includes similar limitations as claim 11, and thus claim 11 is rejected under the same rationale as in claim 11.
As to claim 2, in view of claim 1, Kashid teaches wherein the memory region is inside the security apparatus (see Fig. 1, key cache 150 inside secure enclave 112).
As to claim 3, in view of claim 1, Kashid teaches the security apparatus of claim 1, further comprising: an access enable indicator associated with a memory location in the memory region, the memory location to store the encryption key, wherein the security processor is to control access to the encryption key in the memory region by setting a value of the access enable indicator (see para. [0043] “In some situations, the requestor may be authenticated (e.g., via certificate) before it may retrieve the encryption key for a particular tenant from the key cache or the KMS. Storage of private keys for a plurality of tenants in a key cache that is implemented within a secure enclave may advantageously prevent attackers from gaining access to tenants' private data. For example, the disclosed techniques may prevent attackers from obtaining tenants' private keys via privilege escalation, attempting to swap keys to disc, capturing a memory dump, etc.”; It is noted that depending on whether the requestor is authenticated or not, the decision to gain access to the memory location associated with a key address corresponding to the requestor is decided.).
As to claim 4, in view of claim 3, Kashid teaches wherein the access enable indicator when set to a first value disables access to the memory location, and the access enable indicator when set to a different second value enables access to the memory location (see para. [0043]; e.g., first value is a binary number indicative of unauthenticated and the second value is a binary number indicative of authenticated.; It is noted that depending on whether the requestor is authenticated or not, the decision to gain access to the memory location associated with a key address corresponding to the requestor is denied.).
As to claim 7, in view of claim 3, Kashid teaches wherein the memory region comprises a plurality of memory locations to store respective encryption keys including the encryption key associated with the management controller (see Fig. 3, Key 1 352, Key 2 354, Key 3 356).
As to claim 8, in view of claim 7, Kashid teaches comprising: a plurality of access enable indicators associated with respective memory locations of the plurality of memory locations, wherein the security processor is to control access to the plurality of memory locations by setting respective values of the plurality of access enable indicators (see para. [0043]; e.g., first value is a binary number indicative of unauthenticated and the second value is a binary number indicative of authenticated.; It is noted that depending on whether the requestor is authenticated or not, the decision to gain access to the memory location associated with a key address corresponding to the requestor is decided.).
As to claim 12, in view of claim 11, Sell teaches wherein the memory location in the security enclave that contains the encryption key is inaccessible to a processor of the management controller (see para. [0040] “In this manner, a process that attempts to access the physical address space associated with another process will not be able to decrypt the data. For example, if GPU process 228 is compromised and is used to access the aliased address space of CPU process 224, the data will be decrypted using key 1. Because the data was encrypted using key 0, however, the GPU process cannot gain access to the unencrypted data even if it gains access to the aliased address space.”)
As to claim 13, in view of claim 11, Kashid teaches wherein the controller is to: determine a location identifier of the memory location based on the memory alias; and use the location identifier to fetch the encryption key from the memory location in the security enclave (see para. [0049] “Key cache 150, in the illustrated embodiment, maintains mappings between tenant IDs 384-388 and key IDs 352-356 in table 380 and mappings between key IDs 352-356 and key material 392-396 in table 390. For example, in FIG. 3, table 380 maps tenant A to key 1, tenant K to key 2, and tenant C to key 3. Similarly, table 390 maps key 1 to key 1 material, key 2 to key 2 material, and key 3 to key 3 material. It is noted that table 380 is stored within a first portion of key cache 150, while table 390 is stored in a second portion of key cache 150.”; It is noted that the key in the Key Cache 150 is protected by the access control using the identifier of the requestor and a mapping table linking the identifier and the key identifiers and ultimate locations of the key referenced by the key identifiers.; see para. [0070] and Fig. 4, step 420 “Access, using an identifier associated with the particular account, a key cache stored in a secure enclave of a memory of the computing system to determine at least one private key associated with the request, where the key cache stores private keys of a key management system (KMS) for a plurality of accounts.”; The examiner views the requestor identifying information, which indirectly is indicative of the private key in the key cache, as equivalent to the instant application’s memory alias.)
As to claim 14, in view of claim 13, Kashid teaches wherein the controller is to: determine the location identifier of the memory location by extracting the location identifier from the memory alias (see para. [0049] “Key cache 150, in the illustrated embodiment, maintains mappings between tenant IDs 384-388 and key IDs 352-356 in table 380 and mappings between key IDs 352-356 and key material 392-396 in table 390. For example, in FIG. 3, table 380 maps tenant A to key 1, tenant K to key 2, and tenant C to key 3. Similarly, table 390 maps key 1 to key 1 material, key 2 to key 2 material, and key 3 to key 3 material. It is noted that table 380 is stored within a first portion of key cache 150, while table 390 is stored in a second portion of key cache 150.”; It is noted that the key in the Key Cache 150 is protected by the access control using the identifier of the requestor and a mapping table linking the identifier and the key identifiers and ultimate locations of the key referenced by the key identifiers.; see para. [0070] and Fig. 4, step 420 “Access, using an identifier associated with the particular account, a key cache stored in a secure enclave of a memory of the computing system to determine at least one private key associated with the request, where the key cache stores private keys of a key management system (KMS) for a plurality of accounts.”; The examiner views the requestor identifying information, which indirectly is indicative of the private key in the key cache, as equivalent to the instant application’s memory alias.)
As to claim 15, in view of claim 13, Kashid teaches wherein the controller is to: determine the location identifier of the memory location by: extracting a key identifier of the encryption key from the memory alias, and accessing mapping information that maps the key identifier to the location identifier (see para. [0049] “Key cache 150, in the illustrated embodiment, maintains mappings between tenant IDs 384-388 and key IDs 352-356 in table 380 and mappings between key IDs 352-356 and key material 392-396 in table 390. For example, in FIG. 3, table 380 maps tenant A to key 1, tenant K to key 2, and tenant C to key 3. Similarly, table 390 maps key 1 to key 1 material, key 2 to key 2 material, and key 3 to key 3 material. It is noted that table 380 is stored within a first portion of key cache 150, while table 390 is stored in a second portion of key cache 150.”; It is noted that the key in the Key Cache 150 is protected by the access control using the identifier of the requestor and a mapping table linking the identifier and the key identifiers and ultimate locations of the key referenced by the key identifiers.; see para. [0070] and Fig. 4, step 420 “Access, using an identifier associated with the particular account, a key cache stored in a secure enclave of a memory of the computing system to determine at least one private key associated with the request, where the key cache stores private keys of a key management system (KMS) for a plurality of accounts.”; The examiner views the requestor identifying information, which indirectly is indicative of the private key in the key cache, as equivalent to the instant application’s memory alias.).
As to claim 17, in view of claim 16, Sell teaches wherein the key data received at the encryption engine from the memory location in the security enclave comprises an encryption key that is accessible by the encryption engine but inaccessible to the processor of the management controller (see para. [0040] “In this manner, a process that attempts to access the physical address space associated with another process will not be able to decrypt the data. For example, if GPU process 228 is compromised and is used to access the aliased address space of CPU process 224, the data will be decrypted using key 1. Because the data was encrypted using key 0, however, the GPU process cannot gain access to the unencrypted data even if it gains access to the aliased address space.”)
As to claim18, in view of claim 17, Kashid teaches wherein the key data from the security enclave comprises the encryption key responsive to the security enclave enabling access to the memory location (see para. [0043] “In some situations, the requestor may be authenticated (e.g., via certificate) before it may retrieve the encryption key for a particular tenant from the key cache or the KMS. Storage of private keys for a plurality of tenants in a key cache that is implemented within a secure enclave may advantageously prevent attackers from gaining access to tenants' private data. For example, the disclosed techniques may prevent attackers from obtaining tenants' private keys via privilege escalation, attempting to swap keys to disc, capturing a memory dump, etc.”; It is noted that depending on whether the requestor is authenticated or not, the decision to gain access to the memory location associated with a key address corresponding to the requestor is decided.).
As to claim 20, in view of claim 16, Sell teaches wherein the encryption engine performs the data encryption on behalf of the management controller responsive to being invoked by the management controller (see Sell, para. [0023] It is noted that the controller managing system address space for the system memory to provide data isolation and privacy through system address aliasing.; see para. [0037]; It is noted that key spaces are defined for system address paces 112 and that memory controller 110 uses a unique encryption key for each key space.; see para. [0039] It is noted that each unique process is assigned a unique isolated memory region associated with a corresponding unique encryption key where the process is mapped to a aliased system address called a key space and each requested access operation is handled with different encryption key.; see para. [0047] “…The memory controller accesses a unique encryption key for the key space at step 714…”; see para. [0047] “The memory controller accesses a unique encryption key for the key space at step 714 and encrypts or decrypts the data for the memory request using the unique encryption key for the key space.”)
Claim(s) 5-6, 9-10, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kashid et al. (US 2021/0377020 A1) hereinafter Kashid, in view of Sell, and further in view of Benhammadi (US 2023/0244413 A1).
As to claim 5, in view of claim 4, the combination of Kashid and Sell does not explicitly teach but Benhammadi teaches wherein the security processor is to write an invalid key value to the memory location in the memory region in conjunction with setting the access enable indicator to the first value, and wherein the security processor is to write a valid key value to the memory location in the memory region in conjunction with setting the access enable indicator to the second value (see para. [0058] and [0059] “[0058] According to an embodiment, a countermeasure executed in case of detection of a suspicious event includes loading default values into at least one of registers 132 to replace the data values. The default values, for example, correspond to values ensuring a secure boot or operation of circuit 102. As an example, the default values enable restricting access to non-volatile memory 104. [0059] According to an embodiment, another countermeasure executed in case of detection of a suspicious event includes replacing the value of the cipher key HW KEY stored in area 122 with a dummy value. Cipher key HW KEY will then be impossible to use since its value will not enable to perform the deciphering of the concerned data.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Kashid, Sell and Benhammadi before him or her, to modify the scheme of Kashid and Sell by including Benhammadi. The suggestion/motivation for doing so would have been to protect the security of the content a non-volatile memory by performing countermeasures upon receiving indication of the detection of a suspicious event, as briefly mentioned in Benhammadi, para. [0008]-[0015].
As to claim 6, in view of claim 5, Benhammadi teaches wherein the encryption engine is provided with the invalid key value in response to the request when the access enable indicator is set to the first value (see para. [0058]-[0059]; It is noted that upon detection of suspicious event(s) (i.e. access enable indicator set to first value), the dummy value replaces the key value in a memory region of non-volatile memory.), and wherein the encryption engine is provided with the valid key value in response to the request when the access enable indicator is set to the second value (see para. [0058]-[0059]; It is noted that upon indication of no suspicious event(s) (i.e. access enable indicator set to second value), the key value in a memory region of non-volatile memory becomes accessible.)
As to claim 9, in view of claim 1, the combination of Kashid and Sell does not explicitly teach but Benhammadi teaches wherein the security processor is to: write the encryption key to a memory location in the memory region, and after writing the encryption key to the memory region, lock the memory location to prevent a modification of the encryption key (see para. [0067]-[0068]; It is noted that lock or unlock of non-volatile memory 104 is performed to render accessible or inaccessible to writing a region of memory in an attempt to protect the content of key(s)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Kashid, Sell and Benhammadi before him or her, to modify the scheme of Kashid and Sell by including Benhammadi. The suggestion/motivation for doing so would have been to protect the security of the content a non-volatile memory by performing countermeasures upon receiving indication of the detection of a suspicious event, as briefly mentioned in Benhammadi, para. [0008]-[0015].
As to claim 10, in view of claim 1, the combination of Kashid and Sell does not explicitly teach but Benhammadi teaches wherein the security processor is to: detect that the management controller is compromised; and based on detecting that the management controller is compromised, write an invalid key value to the memory region to prevent use of the encryption key (see para. [0058] and [0059] “[0058] According to an embodiment, a countermeasure executed in case of detection of a suspicious event includes loading default values into at least one of registers 132 to replace the data values. The default values, for example, correspond to values ensuring a secure boot or operation of circuit 102. As an example, the default values enable restricting access to non-volatile memory 104. [0059] According to an embodiment, another countermeasure executed in case of detection of a suspicious event includes replacing the value of the cipher key HW KEY stored in area 122 with a dummy value. Cipher key HW KEY will then be impossible to use since its value will not enable to perform the deciphering of the concerned data.”; The examiner considers detection of compromise of a computer controller as a detection of suspicious event.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Kashid, Sell and Benhammadi before him or her, to modify the scheme of Kashid and Sell by including Benhammadi. The suggestion/motivation for doing so would have been to protect the security of the content a non-volatile memory by performing countermeasures upon receiving indication of the detection of a suspicious event, as briefly mentioned in Benhammadi, para. [0008]-[0015].
As to claim 19, in view of claim 18, the combination of Kashid and Sell does not explicitly teach but Benhammadi teaches wherein the key data received at the encryption engine from the memory location in the security enclave comprises an invalid value responsive to disabling access to the memory location (see para. [0058] and [0059] “[0058] According to an embodiment, a countermeasure executed in case of detection of a suspicious event includes loading default values into at least one of registers 132 to replace the data values. The default values, for example, correspond to values ensuring a secure boot or operation of circuit 102. As an example, the default values enable restricting access to non-volatile memory 104. [0059] According to an embodiment, another countermeasure executed in case of detection of a suspicious event includes replacing the value of the cipher key HW KEY stored in area 122 with a dummy value. Cipher key HW KEY will then be impossible to use since its value will not enable to perform the deciphering of the concerned data.”; The examiner considers detection of compromise of a computer controller as a detection of suspicious event.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Kashid, Sell and Benhammadi before him or her, to modify the scheme of Kashid and Sell by including Benhammadi. The suggestion/motivation for doing so would have been to protect the security of the content a non-volatile memory by performing countermeasures upon receiving indication of the detection of a suspicious event, as briefly mentioned in Benhammadi, para. [0008]-[0015].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HEE K SONG whose telephone number is (571)270-3260. The examiner can normally be reached on M-F 9:00 am – 5:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Eleni Shiferaw can be reached on (571)272-3867 . The fax phone number for the organization where this application or proceeding is assigned is 571-273-7291.
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). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HEE K SONG/PRIMARY Examiner, Art Unit 2497