Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim status: claims 1-30 are pending in this Office Action.
DETAILED ACTION
Response to Arguments
Prior Art Reiection:
Applicant's arguments to the amendments of claim 1 have been fully considered but they are deemed not persuasive.
In response to the argument, please see the new mapping in below.
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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1,148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under pre- AIA 35 U.S.C. 103(a) 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.
Claims 1-3, 6, 8-13, 16, 18-23, 26, 28-30 are rejected under 35 U.S.C. 103 as being unpatentable over Ali (US20180330095), in view of Zhang (US20210081536).
Regarding to claim 1:
Ali teaches A method for image authentication for secure boot, the method comprising ([0002] authentication checking, in SoCs, such as during boot and fail-safe image update):
obtaining an expected tag image comprising an expected tag corresponding to an image to be loaded into memory (fig. 2, 205-230 [0039] the firmware images for the SoC 100 to include in the signed image of hashes. [0041] At 230, the computing device appends the signature to the image of the hashes to build the signed image of hashes. [0011] storing a plurality of executable images; storing, as separate from the plurality of executable images, a signed image of hashes comprising a plurality of hashes corresponding to the plurality of executable images and a first signature. Note: build the signed image is obtaining an expected tag image)
loading, by a memory controller of a system on a chip (SoC), the expected tag into a first memory region associated with a hardware implemented hardware memory authenticator of the memory controller, ([0043] At 305, a bootloader of the SoC 100 (e.g., BL1a) loads the signed image of hashes (e.g., IMG 162) for processing by the SoC 100 (e.g., CPUSS 105). At 310, the SoC 100, in a secure mode of operation, determines if an authentication of the IMG 162 passes based on the signature included in the IMG 162. For example, the SoC 100 may utilize an authentication algorithm (e.g., based on a root certificate at the SoC 100) to determine if the IMG 162 is authenticated. If at 310, the authentication passes, at 315, the hashes of individual firmware images in the IMG 162 are cached in a secure memory (e.g., SRAM, DRAM, etc.) at the SoC 100. Note: SoC 100 is a memory controller; cached the hashes of individual firmware images in a secure memory (e.g., SRAM, DRAM, etc.) is loading the expected tag into a first memory region; authentication algorithm of SoC100 is a hardware memory authenticator of the memory controller. See Spec [0044] the hardware memory authenticator 204 is any hardware, software, firmware, or any combination thereof that is configured to perform various tasks relating to access of a memory device (e.g., the memory device 206)); wherein the hardware memory authenticator comprises a portion of the memory controller for calculating tags ([0043] the signed image of hashes … the SoC 100 may utilize an authentication algorithm (e.g., based on a root certificate at the SoC 100) to determine if the IMG 162 is authenticated. [0051] loads the firmware image (e.g., segments of the firmware image) … At 424, the SoC 100 determines if the hash for each segment of the firmware image as computed by the SoC 100 matches the corresponding hash for the firmware image. Note: determines the hash (signed image) of segments is calculating tags. Also see [0038] Fig. 2 … operations 200 may be performed … by a SoC such as SoC 100. [0039] computes a hash (e.g., based on the firmware image, based on meta-data of the firmware image, etc.) for each of the firmware images to be included in the signed image of hashes)
loading, by the memory controller, the image into a second memory region (Fig.5, 505 [0055] At 505, the SoC stores (e.g., in DRAM, SRAM, on-chip, off-chip, etc.) a plurality of executable images (e.g., firmware images). [0011] storing, as separate from the plurality of executable images, a signed image of hashes comprising a plurality of hashes corresponding to the plurality of executable images and a first signature);
providing an authentication indication to the hardware memory authenticator, wherein the authentication indication triggers the hardware memory authenticator to authenticate the image (Fig. 3, 325-335. [0044] If at 325, the SoC 100 determines the IMG 162 is authenticated, the operations continue to 335. [0045] Continuing at 335, the boot process continues for each of the firmware images of the SoC 100, such as described with respect to FIG. 4, [0046] FIG. 4 illustrates exemplary operations 400 for performing an integrity check and authentication of firmware images at a SoC using a signed image of hashes. Note: It’s implied that there must be some kind of indication trigger the operations in Fig. 3, 325-335 and Fig. 4, such as an indication that the boot process is to continue. See Zhang teaches more clearly in below);
reading a portion of the image while the portion of the image is loading into the second memory region ([0039] the firmware images for the SoC 100 to include in the signed image of hashes. Fig. 4, 402-408. [0047] At 402, a bootloader of the SoC 100 (e.g., BL1a) loads metadata (e.g., hash table, etc.) of a firmware image (“loading firmware image” - see fig.4). At 404, in a secure mode of operation, the SoC 100 (e.g., CPUSS 105) stores the meta data of the firmware image in secure memory (e.g., SRAM, DRAM, etc.). [0048] determines the signed image of hashes was authenticated, and the hash for the firmware image is included in the signed image of hashes, operations 400 continue to 408. At 408, the SoC 100 calculates a hash of the firmware image (e.g., of meta data of the firmware image. Note: determines the signed image of hashes was authenticated and/or calculates a hash of the firmware image is reading a portion of the image; steps 402-408 is reading a portion of the image while the image is loading into the second memory region);
generating, by the hardware memory authenticator, an authentication tag corresponding to the portion of the image, wherein portions of the authentication tag are generated while corresponding portions of the image are loading into the second memory region (Fig.4 402-408 [0047] At 402, a bootloader of the SoC 100 (e.g., BL1a) loads metadata (e.g., hash table, etc.) of a firmware image (“loading firmware image” - see fig.4). At 404, in a secure mode of operation, the SoC 100 (e.g., CPUSS 105) stores the meta data of the firmware image in secure memory (e.g., SRAM, DRAM, etc.). [0048] determines the signed image of hashes was authenticated, and the hash for the firmware image is included in the signed image of hashes, operations 400 continue to 408. At 408, the SoC 100 calculates a hash of the firmware image (e.g., of meta data of the firmware image. [0031] one or more hashes of the firmware image (e.g., a hash for each segment of multiple segments of the firmware image). Further, each firmware image with data corresponding to one or more hashes includes a signature and/or certificate … used for authentication [0043] the SoC 100 may utilize an authentication algorithm. Note: calculates a hash (was authenticated) of the firmware image is generating an authentication tag; signature and/or certificate (used for authentication) are portions of the authentication tag; segments or metadata of the firmware image are portions of the image; steps 402-408 is generating an authentication tag while the image is loading into the second memory region); and
performing a comparison of the authentication tag and the expected tag to obtain an authentication result, wherein, the authentication result is a successful match, and the portion of the image is authenticated (Fig. 4, 410-430 “hash match?”. [0048] At 410, the SoC 100 determines if the hash calculated by SoC 100 matches the hash for the firmware image included in the signed image of hashes. If the SoC 100 determines at 410 the hashes match, the authentication passes, and the operations 400 continue to 412 where the results of the authentication passing are stored in return variables. [0050] If at 418, the SoC 100 determines the firmware image is authenticated, the operations continue to 422. [0051] At 422, the bootloader of the SoC 100 loads the firmware image. [0052] 430, where the firmware image is executed and boot continues)
Ali teaches providing an authentication indication to the hardware memory authenticator, wherein the authentication indication triggers the hardware memory authenticator to authenticate the image but it is not clearly.
Zhang teaches more clearly providing an authentication indication to the hardware memory authenticator, wherein the authentication indication triggers the hardware memory authenticator to authenticate the image ([0096] configured to program/store the application configuration into one of configuration image sectors 452 or 454, to set a pre-authentication bit for the appropriate image … validating the locked PLD manifest. [0157] a secure boot process 1400 for secure PLD 410. [0158-0159] a logic device retrieves a pre-authentication status associated with a configuration image for a secure PLD … perform pre-authentication process 1120 associated with the configuration image for secure PLD 410 to determine the pre-authentication status associated with the configuration image retrieved in block 1410
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to take the teachings of Zhang and apply them on the teachings of Ali to further implement providing an authentication indication to the hardware memory authenticator, wherein the authentication indication triggers the hardware memory authenticator to authenticate the image. One would be motivated to do so because in order to improve better system and method to set a pre-authentication bit for the appropriate image to reboot (Zhang, [0096]).
Regarding to claim 2:
Ali teaches The method of claim 1, wherein the expected tag image is authenticated prior to loading the expected tag (Fig.3, 310-315 wherein step 310 is the expected tag image is authenticated; step 315 is loading the expected tag. [0043] At 310, the SoC 100, in a secure mode of operation, determines if an authentication of the IMG 162 passes based on the signature included in the IMG 162 … If at 310, the authentication passes, at 315, the hashes of individual firmware images in the IMG 162 are cached in a secure memory (e.g., SRAM, DRAM, etc.) at the SoC 100)
Regarding to claim 3:
Ali teaches The method of claim 1, wherein the expected tag image further comprises a plurality of additional expected tags, and wherein each of the plurality of additional expected tags corresponds to a separate one of a plurality of images ([0037] the IMG 162 is authenticated based on the signature associated with the IMG 162 and the one or more overall hashes for the IMG 162. The individual hashes in the IMG 162 are then used to perform integrity checks and secure boot checks of the individual firmware images … hashes for firmware images from different sources (e.g., OEM, vendors, etc.), for example having different root certificates and signatures, may be included in different IMG 162.
Regarding to claim 8:
Ali teaches The method of claim 1, wherein the expected tag image is a signed image (fig.2, 230. [0041] At 230, the computing device appends the signature to the image of the hashes to build the signed image of hashes).
Regarding to claim 9:
Ali teaches The method of claim 1,
Ali does not explicitly disclose wherein providing the authentication indication to the hardware memory authenticator comprises setting a bit associated with the hardware memory authenticator to a value that indicates that the hardware memory authenticator is to authenticate the image
Zhang teaches wherein providing the authentication indication to the hardware memory authenticator comprises setting a bit associated with the hardware memory authenticator to a value that indicates that the hardware memory authenticator is to authenticate the image (Zhang [0163] authenticate the update configuration image using the new keys, and to store the update configuration image in one of configuration image sectors 452 or 454 (and including setting the authentication bit to indicate the stored update configuration image is bootable) .
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to take the teachings of Zhang and apply them on the teachings of Ali to further implement wherein providing the authentication indication to the hardware memory authenticator comprises setting a bit associated with the hardware memory authenticator to a value that indicates that the hardware memory authenticator is to authenticate the image. One would be motivated to do so because in order to improve better system and method to set a pre-authentication bit for the appropriate image to reboot (Zhang, [0096]).
Regarding to claim 10:
Ali teaches The method of claim 1, wherein, after the image is authenticated, the image is available to be executed on a computing device (fig. 4, 418-430. [0052] If at 418, the SoC 100 determines the firmware image is authenticated, [0052] 430, where the firmware image is executed and boot continues)
Regarding to claims 11, 21:
[Rejection rationale for claim 1 is applicable].
Regarding to claims 12, 22:
[Rejection rationale for claim 2 is applicable].
Regarding to claims 13, 23:
[Rejection rationale for claim 3 is applicable].
Regarding to claims 16, 26:
[Rejection rationale for claim 6 is applicable].
Regarding to claims 18, 28:
[Rejection rationale for claim 8 is applicable].
Regarding to claims 19, 29:
[Rejection rationale for claim 9 is applicable].
Regarding to claims 20, 30:
[Rejection rationale for claim 10 is applicable].
Claims 4-5, 14-15, 24-25 are rejected under 35 U.S.C. 103 as being unpatentable over Ali (US20180330095), in view of Zhang (US20210081536), further in view of Singhal (US20180091315A1)
Regarding to claim 4:
Ali-Zhang teaches The method of claim 1,
Ali-Zhang does not explicitly teach wherein, the hardware memory authenticator is disactivated during loading of the expected tag into the first memory region or during loading of the image into the second memory region.
Singhal teaches wherein, the hardware memory authenticator is disactivated during loading of the expected tag into the first memory region or during loading of the image into the second memory region ([0029] secure operation of the computing device can be provided through use of multiple boot-loaders by the computing device. For example, a primary boot loader (PBL) of the computing device is stored in an immutable on-chip read-only-memory [0048-0049] PBL iterates to the next OEM_PK_HASHn value from the fuse ROM. The process continues until PBL either finds a match (in which case secure boot continues) … to ensure that updates of the memory elements (e.g., the elements 310a-n, and the revocation list 320) cannot be performed during runtime … an update-block register may be used to inhibit updating operations of the write restricted memory during runtime … FIG. 3A is shown, which includes a “sticky” (update-block) register 330 (marked in FIG. 3B as “SW_ROT_STICKY_BIT”). When set to a value (e.g., ‘1’, ON, or some other pre-determined value) indicating that updates to the write-restricted memory 300 (and thus to the elements 310a-n and the revocation list 320) are blocked (or that the memory elements 310a-n and the revocation list 320 are locked), the computing device (e.g., the device 200 of FIG. 2) is prevented/inhibited from performing updates to the restricted memory 300. Note: PBL secure boot continues is during loading of the expected tag; inhibit updating operations of the write restricted memory during runtime is the hardware memory authenticator is disactivated)
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to take the teachings of Singhal and apply them on the teachings of Ali-Zhang to further implement the hardware memory authenticator is disactivated during loading of the expected tag into the first memory region or during loading of the image into the second memory region. One would be motivated to do so because in order to improve better system and method to provide PBL iterates to the next OEM_PK_HASHn value from the fuse ROM. The process continues until PBL either finds a match (in which case secure boot continues) and ensure that updates of the memory elements cannot be performed during runtime (Singhal, [0048-0049]).
Regarding to claims 14, 24:
[Rejection rationale for claim 4 is applicable].
Regarding to claim 5:
Ali-Zhang teaches The method of claim 1,
Ali-Zhang does not explicitly teach discarding, after performing the comparison, the expected tag from the first memory region.
Kwon teaches further comprising discarding after performing the comparison, the expected tag from the first memory region (Kwon, fig.5, S15-S50 where S15 is comparison. [0072] determine whether the first public keys 236 and 246 need to be revoked in response to the reception of the second firmware image 302 (S15). [0080] delete the previous first boot signature 256 written in the second area 250 of the first memory (S50).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to take the teachings of Kwon and apply them on the teachings of Ali-Zhang to further implement discarding, after performing the comparison, the expected tag from the first memory region. One would be motivated to do so because in order to improve better system and method to delete the previous first boot signature (Kwon, [0080]).
Regarding to claims 15, 25:
[Rejection rationale for claim 5 is applicable].
Claims 7, 17, and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Ali (US20180330095), in view of Zhang (US20210081536), further in view of Singhal (US20180091315)
Regarding to claim 7:
Ali-Zhang teaches The method of claim 1,
Ali-Zhang does not explicitly disclose rebooting a sub-system of a computing device; and using, after the rebooting, a second expected tag from the expected tag image to authenticate an image corresponding to the sub-system.
Singhal teaches further comprising: rebooting a sub-system of a computing device; and using, after the rebooting, a second expected tag from the expected tag image to authenticate an image corresponding to the sub-system ([0057] the computing device may be configured to replace the new certificate data … the new firmware signed with a new set of keys. Upon installation of the new firmware on the computing device's memory (e.g., to the non-volatile storage 266), the new root-of-trust image content is deleted, and a reboot of the computing device is triggered to boot with the new firmware that is authenticated with the new certificate chain)
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to take the teachings of Singhal and apply them on the teachings of Ali-Zhang to further implement rebooting a sub-system of a computing device; and using, after the rebooting, a second expected tag from the expected tag image to authenticate an image corresponding to the sub-system. One would be motivated to do so because in order to improve better system and method to replace the new certificate data, the new firmware signed with a new set of keys. Upon installation of the new firmware on the computing device's memory (e.g., to the non-volatile storage), the new root-of-trust image content is deleted, and a reboot of the computing device is triggered to boot with the new firmware that is authenticated with the new certificate chain (Singhal, [0057]).
Regarding to claims 17, 27:
[Rejection rationale for claim 7 is applicable].
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action.
This action is a final rejection and is intended to close the prosecution of this application. Applicant’s reply under 37 CFR 1.113 to this action is limited either to an appeal to the Patent Trial and Appeal Board or to an amendment complying with the requirements set forth below.
If applicant should desire to appeal any rejection made by the examiner, a Notice of Appeal must be filed within the period for reply identifying the rejected claim or claims appealed. The Notice of Appeal must be accompanied by the required appeal fee.
If applicant should desire to file an amendment, entry of a proposed amendment after final rejection cannot be made as a matter of right unless it merely cancels claims or complies with a formal requirement made earlier. Amendments touching the merits of the application which otherwise might not be proper may be admitted upon a showing a good and sufficient reasons why they are necessary and why they were not presented earlier.
A reply under 37 CFR 1.113 to a final rejection must include the appeal from, or cancellation of, each rejected claim. The filing of an amendment after final rejection, whether or not it is entered, does not stop the running of the statutory period for reply to the final rejection unless the examiner holds the claims to be in condition for allowance. Accordingly, if a Notice of Appeal has not been filed properly within the period for reply, or any extension of this period obtained under either 37 CFR 1.136(a) or (b), the application will become abandoned.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HIEN DOAN whose telephone number is 571 272-4317. The examiner can normally be reached on Monday-Thursday and biweekly Friday 9am-6pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, VIVEK SRIVASTAVA can be reached on (571)272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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.
/HIEN V DOAN/Examiner, Art Unit 2449
/VIVEK SRIVASTAVA/Supervisory Patent Examiner, Art Unit 2449