DETAILED ACTION
This office action is in response to the application filed on 05/01/2025. Claim(s) 1-20 is/are pending and are examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. 10-2024-0110292, filed on 09/10/2024.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 05/01/2025 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim(s) 12-17 is/are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention. The specification states clearly in at least ¶ 68, “the second cryptographic circuit 324 may generate a decoding code from the components of the security message SM, excluding the authentication code AC, using the shared key SK.” Which goes against the claimed limitation, “wherein the determining, by the second security processor, that the security message has been tampered with comprises: generating a decoding code from the command using the authentication code and the shared key”.
The dependent claims included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. Therefore, they are rejected based on the same rationale as applied to their parent claims above.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 1-18 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 6, 11, 13–16, and 18 all claim, “Determine that the security message has been tampered with”. The specification consistently describes determining “whether” the message has been tampered with. The claim language may be interpreted as only covering the case where tampering is confirmed, not the general determination process. Dependent claims then refer to actions “based on determining that the [message] has not been tampered with,” this leaves an indefinite opening on the completeness of the determination step.
Claim 12 claims: “generating a decoding code from the command using the authentication code and the shared key.” However, the specification (¶ [0068], [0176]) describes generating the decoding code from the command (or message components excluding the claimed authentication code) using only the shared key, not using the authentication code as an input. This appears to be a discrepancy between the claimed limitation and the applicant’s specification.
Claim 5 recites the limitation "is configured to transmit a third security request and data" in line 2 and “a second IP block” in line 4. The claimed “a third request” implies there are previously a first and second request, however, these were not recited in parent claims of claim 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 6 recites the limitation "is configured to transmit a fourth security request and data" in line 2. The claimed “a fourth request” implies there are previously a first through third request, however, these were not recited in parent claims of claim 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 8 recites the limitation "is configured to transmit a fifth security request and data" in line 2. The claimed “a fifth request” implies there are previously a first through fourth request, however, these were not recited in parent claims of claim 6. There is insufficient antecedent basis for this limitation in the claim.
Claim 16 recites the limitation “transmitting a fourth security message” in line 2. The claimed “a fourth request” implies there are previously a first through third request, however, these were not recited in parent claims of claim 13. There is insufficient antecedent basis for this limitation in the claim.
The dependent claims included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. Therefore, they are rejected based on the same rationale as applied to their parent claims above.
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-2, 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chandra (US 2023/0315913 A1 ), hereinafter Chandra in view of Patel(US 2022/0417005 A1), hereinafter Patel.
Regarding Claim(s) 1 Chandra teaches:
A semiconductor system comprising: (Chandra ¶ 27 teaches, implement multi-chip module (MCM) systems using configurable/programmable logic components, such as components of one or more programmable logic devices (PLDs).)
a first die comprising a first security processor and an application processor, the first security processor being configured to store a shared key; and (Chandra ¶ 115 teaches, The die 1010 includes a secure interface, a processor (e.g., RISC-V-based processor), a cryptographic block, and configuration engine (e.g., including factory public key and factory-AES key(s) or other data to support other encryption and/or authentication technologies such as ECDSA). (i.e., security processor) The die includes a main root of trust (MRoT), a user/customer control PLD, a customer application public key, and may include bulk encryption key(s) such as an AES key. ¶ 117 teaches The die may include/implement an embedded security block (e.g., also referred to as a security engine) to provide a hard IP resource configured to provide various security functions for use by PLD fabric. (i.e., application processor))
a second die connected to the first die through a first channel and comprising a second security processor configured to store the shared key, (Chandra ¶ 119 teaches, The die 1015 (i.e., second die) may create a private key from a TRNG (e.g., the TRNG) and derive public keys. As an example, a shared secret AES key (e.g., 128 bit AES key) and nonce (e.g., initial 128-bit nonce) may be used. The embedded security block (e.g., implemented by the die) may be used to drive the shared secret AES key and nonce from the private key created by the die and the public key of the BMC.)
wherein the application processor is configured to transmit a security request to the first security processor in response to a request for a security-required operation of the second die, (Chandra ¶ 59 teaches, The security engine may be implemented as a hard IP resource configured to provide various security functions for use by the PLD fabric and/or configuration engine. ¶ 117 teaches, The secure interface may be used to facilitate intra-chip communication between components of the die 1010 and inter-chip communication (e.g., according to an I.sup.2C protocol and/or other inter-chip communication protocol) between the die 1010 and the die 1015.)
Chandra does not appear to explicitly teach but in related art:
wherein the first security processor is configured to, in response to the security request:
generate an authentication code based on the shared key; and (Patel ¶ 36 teaches, the receiving chiplet uses the cryptographic engine in its circuitry to decrypt the message (and optionally checks the integrity of the message by verifying the tag (e.g., message authentication code (MAC)). (i.e., authentication code))
transmit a security message to the second security processor through the first channel, the security message comprising a command corresponding to the security-required operation of the second die and the authentication code, and (Patel ¶ 36 teaches, the receiving chiplet uses the cryptographic engine in its circuitry to decrypt the message (and optionally checks the integrity of the message by verifying the tag (e.g., message authentication code (MAC)).)
wherein the second security processor is configured to determine that the security message has been tampered with, using the authentication code and the shared key. (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Chandra with Patel, to modify the system for multi-chip security with the chiplet verification method of Patel. The motivation to do so, Patel ¶ 34, provide resilience against a splicing of a (e.g., malicious) chiplet into a genuine package.
Regarding Claim(s) 2 Chandra in view of Patel teaches:
The semiconductor system of claim 1, (Chandra in view of Patel teaches the parent claim above.)
wherein the first security processor comprises a first cryptographic circuit configured to generate the authentication code from the command using the shared key, (Patel ¶ 36 teaches, each die (e.g., chiplet) includes circuitry (e.g., a die-to-die communication circuit) that provides: (i) an encryption engine which encrypts (and/or decrypts) (and optionally integrity protects) messages going out of the chiplet, and/or (ii) a key derivation function (KDF) that derives a secret based on the random number programmed in the netlist into a die identification (ID) value for a die, e.g., a chiplet ID value for a chiplet. In certain embodiments (e.g., for SoC data), the receiving chiplet uses the cryptographic engine in its circuitry to decrypt the message (and optionally checks the integrity of the message by verifying the tag (e.g., message authentication code (MAC)).)
wherein the second security processor comprises a second cryptographic circuit configured to generate a decoding code from the command transmitted through the security message using the shared key, and (Patel ¶ 36 teaches, (i) an encryption engine which encrypts (and/or decrypts) (and optionally integrity protects) messages going out of the chiplet)
wherein the second security processor is configured to determine that the security message has not been tampered with, based on the decoding code matching the authentication code. (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
The motive given in Claim 1 is equally applicable to the above claim.
Regarding Claim(s) 6 Chandra in view of Patel teaches:
The semiconductor system of claim 1, (Chandra in view of Patel teaches the parent claim above.)
wherein the application processor is configured to transmit a fourth security request to the first security processor in response to a fourth operation request for verifying the second die, (Chandra ¶ 59 teaches, The security engine may be implemented as a hard IP resource configured to provide various security functions for use by the PLD fabric and/or configuration engine. ¶ 117 teaches, The secure interface may be used to facilitate intra-chip communication between components of the die 1010 and inter-chip communication (e.g., according to an I.sup.2C protocol and/or other inter-chip communication protocol) between the die 1010 and the die 1015.)
wherein the first security processor is configured to transmit a fourth security message to the second security processor in response to the fourth security request, the fourth security message comprising a fourth command corresponding to the fourth operation request, an identifier, and the authentication code, and (Patel ¶ 36 teaches, (i) an encryption engine which encrypts (and/or decrypts) (and optionally integrity protects) messages going out of the chiplet, and/or (ii) a key derivation function (KDF) that derives a secret based on the random number programmed in the netlist into a die identification (ID) value for a die, e.g., a chiplet ID value for a chiplet. (i.e., id) In certain embodiments (e.g., for SoC data), the receiving chiplet uses the cryptographic engine in its circuitry to decrypt the message (and optionally checks the integrity of the message by verifying the tag (e.g., message authentication code (MAC)).)
wherein the second security processor is configured to determine that the fourth security message has been tampered with, using the authentication code and the shared key. (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
Claim(s) 3 and 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chandra in view of Patel as applied to claim 2 above, and further in view of Arora (US 2026/0004005 A1), hereinafter Arora.
Regarding Claim(s) 3 Chandra in view of Patel teaches:
The semiconductor system of claim 2, (Chandra in view of Patel teaches the parent limitation above.)
wherein the application processor is configured to transmit a first security request to the first security processor in response to a first operation request for a first operation (Chandra ¶ 59 teaches, The security engine may be implemented as a hard IP resource configured to provide various security functions for use by the PLD fabric and/or configuration engine. ¶ 117 teaches, The secure interface may be used to facilitate intra-chip communication between components of the die 1010 and inter-chip communication (e.g., according to an I.sup.2C protocol and/or other inter-chip communication protocol) between the die 1010 and the die 1015.)
wherein the first security processor is configured to transmit a first security message to the second security processor in response to the first security request, (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
the first security message comprising a first command corresponding to the first operation, first specific information corresponding to the first IP block, and the authentication code, and
wherein the second security processor is configured to: (Patel ¶ 36 teaches, (i) an encryption engine which encrypts (and/or decrypts) (and optionally integrity protects) messages going out of the chiplet, and/or (ii) a key derivation function (KDF) that derives a secret based on the random number programmed in the netlist into a die identification (ID) value for a die, e.g., a chiplet ID value for a chiplet. (i.e., first IP block) In certain embodiments (e.g., for SoC data), the receiving chiplet uses the cryptographic engine in its circuitry to decrypt the message (and optionally checks the integrity of the message by verifying the tag (e.g., message authentication code (MAC)).)
determine that the first security message has been tampered with, using the authentication code and the shared key, and
based on determining that the first security message has not been tampered with, set the security level of the first IP block to a first security level based on the first command. (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
Chandra in view of Patel does not appear to explicitly teach but in related art:
to set a security level of a first intellectual property (IP) block included in the second die, (Arora ¶ 38 teaches, S-RoT circuit assigns IP cores to the different trust levels shown as TL0 and TL1 within secondary chiplet.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Chandra in view of Patel with Arora, to modify the system for multi-chip security of Chandra with the chiplet verification method of Patel with the setting of trust level of IP cores of Arora. The motivation to do so, Arora ¶ 58, prevents potential attacks or other unanticipated transactions.
Regarding Claim(s) 18 Chandra teaches:
A system-on-chip (SoC) comprising a plurality of dies connected to each other through a substrate, the SoC comprising: (Chandra ¶ 113 teaches, The multi-chip module system 1005 provides a module with multiple die, including die 1010 and die 1015 that are communicatively coupled and mounted in the module according to any of a variety of technologies (e.g., integrated multi-chip package). The multi-chip module system 1005 may include a substrate on which both the die 1010 and die 1015 are placed, with routing for communication channels defined in or on the substrate)
a first die comprising a first security processor and an application processor, the first security processor being configured to store a shared key; and (Chandra ¶ 115 teaches, The die 1010 includes a secure interface, a processor (e.g., RISC-V-based processor), a cryptographic block, and configuration engine (e.g., including factory public key and factory-AES key(s) or other data to support other encryption and/or authentication technologies such as ECDSA). (i.e., security processor) The die includes a main root of trust (MRoT), a user/customer control PLD, a customer application public key, and may include bulk encryption key(s) such as an AES key. ¶ 117 teaches The die may include/implement an embedded security block (e.g., also referred to as a security engine) to provide a hard IP resource configured to provide various security functions for use by PLD fabric. (i.e., application processor))
a second die connected to the first die through a first channel and comprising a second security processor configured to store the shared key, (Chandra ¶ 119 teaches, The die 1015 (i.e., second die) may create a private key from a TRNG (e.g., the TRNG) and derive public keys. As an example, a shared secret AES key (e.g., 128 bit AES key) and nonce (e.g., initial 128-bit nonce) may be used. The embedded security block (e.g., implemented by the die) may be used to drive the shared secret AES key and nonce from the private key created by the die and the public key of the BMC.)
Chandra does not appear to explicitly teach but in related art:
wherein the first security processor is configured to, in response to the first security request:
generate an authentication code based on the shared key; (Patel ¶ 36 teaches, (i) an encryption engine which encrypts (and/or decrypts) (and optionally integrity protects) messages going out of the chiplet, and/or (ii) a key derivation function (KDF) that derives a secret based on the random number programmed in the netlist into a die identification (ID) value for a die, e.g., a chiplet ID value for a chiplet. (i.e., first IP block) In certain embodiments (e.g., for SoC data), the receiving chiplet uses the cryptographic engine in its circuitry to decrypt the message (and optionally checks the integrity of the message by verifying the tag (e.g., message authentication code (MAC)).)
generate a first security message comprising a first command corresponding to the first operation and the authentication code; and (Patel ¶ 36 teaches, (i) an encryption engine which encrypts (and/or decrypts) (and optionally integrity protects) messages going out of the chiplet, and/or (ii) a key derivation function (KDF) that derives a secret based on the random number programmed in the netlist into a die identification (ID) value for a die, e.g., a chiplet ID value for a chiplet. (i.e., first IP block) In certain embodiments (e.g., for SoC data), the receiving chiplet uses the cryptographic engine in its circuitry to decrypt the message (and optionally checks the integrity of the message by verifying the tag (e.g., message authentication code (MAC)).)
transmit the first security message to the second security processor through the first channel, and
wherein the second security processor is configured to determine that the first security message has been tampered with, using the authentication code and the shared key. (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Chandra with Patel, to modify the system for multi-chip security with the chiplet verification method of Patel. The motivation to do so, Patel ¶ 34, provide resilience against a splicing of a (e.g., malicious) chiplet into a genuine package.
Chandra in view of Patel does not appear to explicitly teach but in related art:
wherein the application processor is configured to transmit a first security request to the first security processor in response to a first operation request for a first operation to set a security level of a first intellectual property (IP) block included in the second die, (Arora ¶ 38 teaches, each of IP cores and is assigned to a particular trust level by the RoT circuit local to the respective IP core. For example, P-RoT circuit assigns IP cores to the different trust levels shown as TL0, TL1, TL3, and TL4 within primary chiplet)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Chandra in view of Patel with Arora, to modify the system for multi-chip security of Chandra with the chiplet verification method of Patel with the setting of trust level of IP cores of Arora. The motivation to do so, Arora ¶ 58, prevents potential attacks or other unanticipated transactions.
Regarding Claim(s) 19 Chandra-Patel-Arora teaches:
The SoC of claim 18, (Chandra-Patel-Arora teaches the parent claim above.) wherein the first security processor comprises a first cryptographic circuit configured to generate the authentication code from the first command using the shared key, (Patel ¶ 36 teaches, (i) an encryption engine which encrypts (and/or decrypts) (and optionally integrity protects) messages going out of the chiplet, and/or (ii) a key derivation function (KDF) that derives a secret based on the random number programmed in the netlist into a die identification (ID) value for a die, e.g., a chiplet ID value for a chiplet. In certain embodiments (e.g., for SoC data), the receiving chiplet uses the cryptographic engine in its circuitry to decrypt the message (and optionally checks the integrity of the message by verifying the tag (e.g., message authentication code (MAC)).)
wherein the second security processor comprises a second cryptographic circuit configured to generate a decoding code from the first command included in the first security message using the shared key, and (Chandra ¶ 149 teaches, If there is a command or other situation where such configuration data is indicated for use, then the authentication and integrity checks must again be performed. ¶ 151 teaches, Such data can include a keyed HMAC of a bitstream, for example. While an unkeyed hash can provide indicia of bitstream integrity, a keyed HMAC, such as keying the hash with the private key of the source, provides authentication given that secure PLD can use the public key of the source to authenticate. It may also be the case that a shared secret key can be used to key the hash.)
wherein the second security processor is configured to determine that the security message has not been tampered with, based on the decoding code matching the authentication code. (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
The motive given in Claim 18 is equally applicable to the above claim.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chandra-Patel-Arora as applied to claim 3 above, and further in view of Ochotta (US 2025/0156585 A1), hereinafter Ochotta.
Regarding Claim(s) 4 Chandra-Patel-Arora teaches:
The semiconductor system of claim 3, (Chandra-Patel-Arora teaches the parent claim above.)
wherein the first security processor is configured to transmit a second security message to the second security processor in response to the second security request, (Chandra ¶ 59 teaches, The security engine may be implemented as a hard IP resource configured to provide various security functions for use by the PLD fabric and/or configuration engine. ¶ 117 teaches, The secure interface may be used to facilitate intra-chip communication between components of the die 1010 and inter-chip communication (e.g., according to an I.sup.2C protocol and/or other inter-chip communication protocol) between the die 1010 and the die 1015.) the second security message comprising a second command corresponding to the second operation, the first specific information, and the authentication code, and (Patel ¶ 36 teaches, (i) an encryption engine which encrypts (and/or decrypts) (and optionally integrity protects) messages going out of the chiplet, and/or (ii) a key derivation function (KDF) that derives a secret based on the random number programmed in the netlist into a die identification (ID) value for a die, e.g., a chiplet ID value for a chiplet. (i.e., first IP block) In certain embodiments (e.g., for SoC data), the receiving chiplet uses the cryptographic engine in its circuitry to decrypt the message (and optionally checks the integrity of the message by verifying the tag (e.g., message authentication code (MAC)).)
wherein the second security processor is configured to:
determine that the second security message has been tampered with, using the authentication code and the shared key, and (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
based on determining that the second security message has not been tampered with (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
Chandra-Patel-Arora does not appear to explicitly teach but in related art:
wherein the application processor is configured to transmit a second security request to the first security processor in response to a second operation request for a second operation to generate a security key for the first IP block, (Ochotta ¶ 4 teaches, generating, by the computer hardware, a plurality of enhanced sub-blocks by encrypting each sub-block of the plurality of sub-blocks with a different key of a plurality of keys corresponding to a plurality of Intellectual Property (IP) cores within the circuit design.)
generate the security key for the first IP block through the second cryptographic circuit based on the second command. (Ochotta ¶ 4 teaches, generating, by the computer hardware, a plurality of enhanced sub-blocks by encrypting each sub-block of the plurality of sub-blocks with a different key of a plurality of keys corresponding to a plurality of Intellectual Property (IP) cores within the circuit design.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Chandra-Patel-Arora with Ochotta, to modify the system for multi-chip security of Chandra with the chiplet verification method of Patel with the setting of trust level of IP cores of Arora with the keys for IP cores of Ochotta. The motivation to do so, Ochotta ¶ 31, for protecting circuit designs for integrated circuits.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chandra in view of Patel as applied to claim 2 above, and further in view of Ochotta.
Regarding Claim(s) 5 Chandra in view of Patel teaches:
The semiconductor system of claim 2 (Chandra in view of Patel teaches the parent claim above.)
wherein the first security processor is configured to transmit a third security message to the second security processor in response to the third security request, the third security message comprising a third command corresponding to the third operation, second specific information corresponding to the second IP block, the data, and the authentication code, and (Patel ¶ 36 teaches, (i) an encryption engine which encrypts (and/or decrypts) (and optionally integrity protects) messages going out of the chiplet, and/or (ii) a key derivation function (KDF) that derives a secret based on the random number programmed in the netlist into a die identification (ID) value for a die, e.g., a chiplet ID value for a chiplet. (i.e., third IP block) In certain embodiments (e.g., for SoC data), the receiving chiplet uses the cryptographic engine in its circuitry to decrypt the message (and optionally checks the integrity of the message by verifying the tag (e.g., message authentication code (MAC)).)
wherein the second security processor is configured to:
determine that the third security message has been tampered with, using the authentication code and the shared key, and(Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
based on determining that the third security message has not been tampered with, transmit the data to the second IP block based on the third command. (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
Chandra in view of Patel does not appear to explicitly teach but in related art:
wherein the application processor is configured to transmit a third security request and data to the first security processor in response to a third operation request for a third operation to transmit data to a second IP block included in the second die, (Ochotta ¶ 4 teaches, generating, by the computer hardware, a plurality of enhanced sub-blocks by encrypting each sub-block of the plurality of sub-blocks with a different key of a plurality of keys corresponding to a plurality of Intellectual Property (IP) cores within the circuit design.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Chandra in view of Patel with Ochotta, to modify the system for multi-chip security of Chandra with the chiplet verification method of Patel with the keys for IP cores of Ochotta. The motivation to do so, Ochotta ¶ 31, for protecting circuit designs for integrated circuits.
Claim(s) 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Patel, and further in view of Chandra.
Regarding Claim(s) 11 Patel teaches:
A method for verifying security, the method comprising: (Patel ¶ 34 teaches, secure data transmission across unsecure links within a package, ensure that the secrets embedded in the chip are not readable by a third-party foundry, provide resilience against a splicing of a (e.g., malicious) chiplet into a genuine package (e.g., the set of chiplets that were intended to be used in the package), and provide a mechanism (e.g., to software) to ensure that code is executing on a genuine package.)
generating an authentication code, based on a prestored shared key, by a first security processor included in a first die (Patel ¶ 36 teaches, (i) an encryption engine which encrypts (and/or decrypts) (and optionally integrity protects) messages going out of the chiplet, (i.e., prestored key) and/or (ii) a key derivation function (KDF) that derives a secret based on the random number programmed in the netlist into a die identification (ID) value for a die, e.g., a chiplet ID value for a chiplet. (i.e., id) In certain embodiments (e.g., for SoC data), the receiving chiplet uses the cryptographic engine in its circuitry to decrypt the message (and optionally checks the integrity of the message by verifying the tag (e.g., message authentication code (MAC)).)
the security message comprising a command corresponding to the security-required operation and the authentication code; (Patel ¶ 53 teaches, generate a tag (e.g., MAC) for the encrypted data at (i.e., security message), and send the encrypted data and associated tag over the link at, and if integrity is not enabled, send the encrypted data over the link at.)
determining, by the second security processor, that the security message has been tampered with, using a prestored shared key and the authentication code; and
based on determining that the security message has not been tempered with, performing, by the second security processor, the security-required operation based on the command. (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
Patel does not appear to explicitly teach but in related art:
in response to the first die receiving an operation request for a security-required operation of a second die; (Chandra ¶ 59 teaches, The security engine may be implemented as a hard IP resource configured to provide various security functions for use by the PLD fabric and/or configuration engine. ¶ 117 teaches, The secure interface may be used to facilitate intra-chip communication between components of the die 1010 and inter-chip communication (e.g., according to an I.sup.2C protocol and/or other inter-chip communication protocol) between the die 1010 and the die 1015.)
transmitting, by the first security processor, a security message to a second security processor included in the second die through a first channel, (Chandra ¶ 103 teaches, the PLD fabric may be configured to set or update the device keys lock status to allow write and/or erase access to the device keys sector and/or UFM sector, to download/receive new keys through a secure channel (e.g., established by PLD fabric over programmable I/O),)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Patel with Chandra, to modify chiplet verification method of Patel with the system for multi-chip security of Chandra. The motivation to do so, Chandra ¶ 32, allow for significant improvements in performance (e.g., timing performance) and space utilization.
Regarding Claim(s) 12 Patel in view of Chandra teaches:
The method of claim 11, wherein the determining, by the second security processor, that the security message has been tampered with comprises: (Patel in view of Chandra teaches the parent claim above.)
generating a decoding code from the command using the authentication code and the shared key; (Chandra ¶ 149 teaches, If there is a command or other situation where such configuration data is indicated for use, then the authentication and integrity checks must again be performed. ¶ 151 teaches, Such data can include a keyed HMAC of a bitstream, for example. While an unkeyed hash can provide indicia of bitstream integrity, a keyed HMAC, such as keying the hash with the private key of the source, provides authentication given that secure PLD can use the public key of the source to authenticate. It may also be the case that a shared secret key can be used to key the hash.) and
determining that the security message has not been tampered with, in response to the decoding code matching the authentication code. (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
The motive given in Claim 11 is equally applicable to the above claim.
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Patel in view of Chandra as applied to claim 12 above, and further in view of Arora and in even further view of Ochotta.
Regarding Claim(s) 13 Patel in view of Chandra teaches:
The method of claim 12, further comprising: (Patel in view of Chandra teaches the parent claim above.)
transmitting a first security message to the second security processor in response to a first operation request for a first operation (Chandra ¶ 59 teaches, The security engine may be implemented as a hard IP resource configured to provide various security functions for use by the PLD fabric and/or configuration engine. ¶ 117 teaches, The secure interface may be used to facilitate intra-chip communication between components of the die 1010 and inter-chip communication (e.g., according to an I.sup.2C protocol and/or other inter-chip communication protocol) between the die 1010 and the die 1015.)
the first security message comprising a first command corresponding to the first operation, first specific information corresponding to the first IP block, and the authentication code; (Patel ¶ 36 teaches, (i) an encryption engine which encrypts (and/or decrypts) (and optionally integrity protects) messages going out of the chiplet, and/or (ii) a key derivation function (KDF) that derives a secret based on the random number programmed in the netlist into a die identification (ID) value for a die, e.g., a chiplet ID value for a chiplet. (i.e., first IP block) In certain embodiments (e.g., for SoC data), the receiving chiplet uses the cryptographic engine in its circuitry to decrypt the message (and optionally checks the integrity of the message by verifying the tag (e.g., message authentication code (MAC)).)
determining, by the second security processor, that the first security message has been tampered with, using the authentication code and the shared key; and (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
Patel in view of Chandra does not appear to explicitly teach but in related art:
to set a security level of a first intellectual property (IP) block included in the second die, (Arora ¶ 38 teaches, each of IP cores and is assigned to a particular trust level by the RoT circuit local to the respective IP core. For example, P-RoT circuit assigns IP cores to the different trust levels shown as TL0, TL1, TL3, and TL4 within primary chiplet)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Patel in view of Chandra with Arora, to modify the chiplet verification method of Patel with the system for multi-chip security of Chandra with the setting of trust level of IP cores of Arora. The motivation to do so, Arora ¶ 58, prevents potential attacks or other unanticipated transactions.
Patel-Chandra-Arora does not appear to explicitly teach but in related art:
based on determining that the first security message has not been tampered with, generating a security key for the first IP block based on the first command. (Ochotta ¶ 4 teaches, generating, by the computer hardware, a plurality of enhanced sub-blocks by encrypting each sub-block of the plurality of sub-blocks with a different key of a plurality of keys corresponding to a plurality of Intellectual Property (IP) cores within the circuit design.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Patel-Chandra-Arora with Ochotta, to modify the chiplet verification method of Patel with the system for multi-chip security of Chandra with the setting of trust level of IP cores of Arora with the keys for IP cores of Ochotta. The motivation to do so, Ochotta ¶ 31, for protecting circuit designs for integrated circuits.
Regarding Claim(s) 14 Patel-Chandra-Arora-Ochotta teaches:
The method of claim 13, further comprising: (Patel-Chandra-Arora-Ochotta teaches the parent claim above.)
transmitting a second security message to the second security processor in response to a second request for a second operation to generate a security key for the first IP block, (Ochotta ¶ 4 teaches, generating, by the computer hardware, a plurality of enhanced sub-blocks by encrypting each sub-block of the plurality of sub-blocks with a different key of a plurality of keys corresponding to a plurality of Intellectual Property (IP) cores within the circuit design.)
the second
security message comprising a second command corresponding to the second operation, the first specific information, and the authentication code; (Patel ¶ 36 teaches, (i) an encryption engine which encrypts (and/or decrypts) (and optionally integrity protects) messages going out of the chiplet, and/or (ii) a key derivation function (KDF) that derives a secret based on the random number programmed in the netlist into a die identification (ID) value for a die, e.g., a chiplet ID value for a chiplet. (i.e., first IP block) In certain embodiments (e.g., for SoC data), the receiving chiplet uses the cryptographic engine in its circuitry to decrypt the message (and optionally checks the integrity of the message by verifying the tag (e.g., message authentication code (MAC)).)
determining, by the second security processor, that the second security message has been tampered with, using the authentication code and the shared key; and (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
based on determining that the second security message has not been tampered with, generating a security key for the first IP block through a cryptographic circuit based on the second command. (Ochotta ¶ 4 teaches, generating, by the computer hardware, a plurality of enhanced sub-blocks by encrypting each sub-block of the plurality of sub-blocks with a different key of a plurality of keys corresponding to a plurality of Intellectual Property (IP) cores within the circuit design.)
The motive given in Claim 13 is equally applicable to the above claim.
Regarding Claim(s) 15 Patel-Chandra-Arora-Ochotta teaches:
The method of claim 14, further comprising: (Patel-Chandra-Arora-Ochotta teaches the parent claim above.)
transmitting a third security message to the second security processor in response to a third request for a third operation to transmit data (Chandra ¶ 59 teaches, The security engine may be implemented as a hard IP resource configured to provide various security functions for use by the PLD fabric and/or configuration engine. ¶ 117 teaches, The secure interface may be used to facilitate intra-chip communication between components of the die 1010 and inter-chip communication (e.g., according to an I.sup.2C protocol and/or other inter-chip communication protocol) between the die 1010 and the die 1015.)
to a second IP block included in the second die, (Ochotta ¶ 4 teaches, generating, by the computer hardware, a plurality of enhanced sub-blocks by encrypting each sub-block of the plurality of sub-blocks with a different key of a plurality of keys corresponding to a plurality of Intellectual Property (IP) cores within the circuit design.)the third security message comprising a third command corresponding to the third operation, second specific information corresponding to the second IP block, the data, and the authentication code; (Patel ¶ 36 teaches, (i) an encryption engine which encrypts (and/or decrypts) (and optionally integrity protects) messages going out of the chiplet, and/or (ii) a key derivation function (KDF) that derives a secret based on the random number programmed in the netlist into a die identification (ID) value for a die, e.g., a chiplet ID value for a chiplet. (i.e., first IP block) In certain embodiments (e.g., for SoC data), the receiving chiplet uses the cryptographic engine in its circuitry to decrypt the message (and optionally checks the integrity of the message by verifying the tag (e.g., message authentication code (MAC)).)
determining, by the second security processor, that the third security message has been tampered with, using the authentication code and the shared key; and (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
based on determining that the third security message has not been tampered with, transmitting the data to the second IP block based on the third command. (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
The motive given in Claim 13 is equally applicable to the above claim.
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chandra-Patel-Arora as applied to claim 18 above, and further in view of Chang (US 9,122,879 B2), hereinafter Chang.
Regarding Claim(s) 20 Chandra-Patel-Arora teaches:
The SoC of claim 18, wherein the second security processor is configured to: (Chandra-Patel-Arora)
set a security level of the first IP block to a first security level (Arora ¶ 38 teaches, each of IP cores and is assigned to a particular trust level by the RoT circuit local to the respective IP core. For example, P-RoT circuit assigns IP cores to the different trust levels shown as TL0, TL1, TL3, and TL4 within primary chiplet) in response to determining that the first security message has not been tampered with; and (Patel ¶ 53 teaches, if integrity is enabled, verify the received tag (e.g., MAC) for the encrypted data is correct, and if the tag is not verified, (i.e., tampered with) cause a corresponding action (e.g., security exception, log failure, and/or alert system software) at, and if the tag is verified, send the decrypted data to the intended receiver with the receiving die.)
transmit result data to the application processor through the first channel, the result data comprising information indicating that the security level of the first IP block is the first security level. (Chang claim 14 teaches the concept, identify device authentication information indicating a device security level of the device by using the secure operating system, encrypt the device authentication information by using the secure operating system, control the communication unit to transmit the encrypted device authentication information to a server that provides the secure content and to receive an authentication result from the server)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Chandra-Patel-Arora with Chang, to modify the system for multi-chip security of Chandra with the chiplet verification method of Patel with the setting of trust level of IP cores of Arora with the reply containing a security level of Chang. The motivation to do so constitutes applying a known technique of replying to a security message to known devices and/or methods for multi-chip security ready for improvement to yield predictable results of alerting the system of the security level of the chips within it.
Allowable Subject Matter
Claim(s) 7-10 and 16-17 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. In addition, they would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2024/0039701 A1 - CONFIDENTIAL COMPUTING IN HETEROGENEOUS COMPUTE ENVIRONMENT INCLUDING NETWORK-CONNECTED HARDWARE ACCELERATOR
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB BENEDICT KNACKSTEDT whose telephone number is (703)756-5608. The examiner can normally be reached Monday-Friday 8:00 am - 5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Linglan Edwards can be reached on (571) 270-5440. 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.
/J.B.K./Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights