DETAILED ACTION
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 .
Herein after “it would have been obvious” should be read as “it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention”.
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 is/are rejected under 35 U.S.C. 103 as being unpatentable over Haridas et al PN 2017/0359171 in view of Sayyed et al PN 2023/0021213.
In regards to claim 1: Haridas et al teaches method for securely rotating (rollover [0029] “At least one key revocation list (KRL) can be included with a bootloader to handle situations like lost, expired, or broken HSMs that are controlled by humans at software manufacturing or production sites. The architecture also provides an ability to limit the number of keys revoked and an ability to rollover a secondary key to allow an empty KRL.”) a plurality of keys [0070] “In the following discussion, two web services are related to the use of secure boot keys. A sign serve service (SSS) is the front-end for HSM-stored secondary secret keys and offers functions for partition signing (DataSigner), KRL signing (KRLSigner), and tertiary public key signing (KeySigner). Also, a key management service (KMS) denotes a service that offers functions for tertiary key management, such as inserting new TPKs, revoking existing TPKs, or listing all TPKs. To support the use of key revocation lists, the key management service has a function (GetKRL) that returns the latest key revocation list. The sign server service and the key management service could be provided by any suitable devices, such as by using one or more computing devices (which could have the architecture shown in FIG. 2, although certain components in FIG. 2 may be excluded if not needed). These services could be provided within a system being secured (such as the system 100) or outside of the system being secured”), the method comprising: controlling, by a signing server (dedicated sign server [0029] “The HSM could be accessed using a dedicated sign server. Kernel and user space applications can be signed using tertiary keys, such as those located on other HSMs locally available for individuals at different software manufacturing or production sites. At least one key revocation list (KRL) can be included with a bootloader to handle situations like lost, expired, or broken HSMs that are controlled by humans at software manufacturing or production sites. The architecture also provides an ability to limit the number of keys revoked and an ability to rollover a secondary key to allow an empty KRL”), a first key pair ([0065] “A tertiary key pair includes a tertiary public key (TPK) and a tertiary secret key (TSK). The tertiary secret key is used to sign all product partitions except the bootloader itself. The tertiary secret key is also used to sign a firmware package that includes the bootloader and other partitions”) of the plurality of boot keys (boot keys), wherein the first key pair includes a first public verification key (public key) and a first private signing key (secret key); generating, by the signing server, a first signature by using the first private signing key ([0074] “This could include, for example, the processor 202 of the build machine 302 calling the DataSigner function of the sign server service 304, which returns the signature of the first-stage bootloader (denoted fsbl.sig) generated using the secondary secret key. The second bootloader partition is signed at step 320. This could include, for example, the processor 202 of the build machine 302 calling the DataSigner function of the sign server service 304, which returns the signature of the second-stage bootloader (denoted ssbl.sig) generated using the secondary secret key“) and a first firmware image [0117] “Note that once the bootloader with the new secondary public key is flashed to a device, the device boot process cannot verify any package containing a TPK.sig signature signed by the old secondary secret key. As a result, the firmware package with the updated bootloader signed by the new secondary secret key contains all freshly-signed firmware images for that device”); booting, by a bootloader (Abstract “A method includes securely booting a device using a bootloader, where the bootloader is digitally signed using a first cryptographic key associated with the bootloader. The method also includes executing one or more kernel or user applications using the device, where the one or more kernel or user applications are digitally signed using one or more second cryptographic keys associated with the one or more kernel or user applications. In addition, the method includes using an in-band channel to update or replace the first cryptographic key“) of an electric device, the electric device to run the first firmware image by using the electric device's first key pair ([0115] “As shown in FIG. 11, a new secondary key pair is generated at step 1102. This could include, for example, the processor 202 of the build machine 302 interacting with the key management service 306 to generate a new secondary key pair (SSK2/SPK2)” ); and rotating , by the bootloader of the electric device ([0030] “These approaches also support a technique to revoke tertiary keys and limit the KRL size by allowing a bootloader key rollover capability“), the first key pair of the plurality of boot keys. Haridas et al teaches a rollover of keys and the existence of boot keys but the rollover is not expressly of the boot keys. Sayyed et al teaches ([0087] “The customization packet may include the customization payload, as well as a header with platform-specific information. The payload may include the Secure Boot keys that will be inserted into (or replace) the certificates and/or hashes in specific Secure Boot variables such as PK, KEK, dB, and dBx” [0083] “Modified variables (platform key (PK), key exchange key (KEK), dB, dBx))” a platform key is a hardware key.). It would have been obvious to replace/rotate/rollover the boot keys with hardware/platform keys because this would have provided for updating not only the intermediate keys but also the boot level keys.
Claim(s) 3-4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Haridas et al PN 2017/0359171 in view of Sayyed et al PN 2023/0021213 as applied to claim 1 above, and further in view of Lee et al PN 2014/0164753.
In regards to claims 3, 4: Haridas et al teaches storing the keys, bootloader and firmware image [0063] “ For the first-stage bootloader, its authentication certificate can be denoted as FSBL.AC, its primary public key can be denoted as FSBL.PPK and can be stored in FSBL.AC, and its SPK.sig signature can be denoted as FSBL.SPK.sig. Similar nomenclature can be used for the second-stage bootloader” [0102] “However the images in the firmware package 500 are verified, the images can be stored on the device once verified”). Haridas et al teaches the secure boot mode verifying authentication code message/packet for the public key ([0077] “As described later, verification of the package authentication certificate 504 can be performed by a package verifier application that uses a trusted value of the primary public key. By relying on the primary public key”). Sayyed et al teaches using a platform/hardware key. Haridas et al teaches verifying a signature ([0094] “ If so, the primary public key is used to verify the signature of the secondary public key in the package authentication certificate at step 706.”). While Haridas et al teaches the secure boot mode verifies multiple parameters, Haridas et al never expressly states the verifying the device is set to a secure boot mode. Lee et al teaches ([0091] “After that, the CPU 130 determines whether a secure boot mode is set or not (S635)”). It would have been obvious to determine/verity that a secure boot mode is set because this would have allowed for operating in both secure and unsecure modes. Haridas et al teaches loading the firmware image.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Haridas et al PN 2017/0359171 in view of Sayyed et al PN 2023/0021213 as applied to claim above, and further in view of Morav et al PN 2022/0382911.
In regards to claim 7: Haridas et al teaches generating a new key ([0115] “As shown in FIG. 11, a new secondary key pair is generated at step 1102. This could include, for example, the processor 202 of the build machine 302 interacting with the key management service 306 to generate a new secondary key pair (SSK2/SPK2)”). Sayyed et al teaches replacing a boot key with a new key using the platform/hardware key. Neither teaches the hardware key being embedded during wafer fabrication. Morav et al teaches ([0026] “Memory 24 contains a hardware key 26, which is programmed into the memory or designed into the logic during fabrication of wafer 32 for use as a global secret in subsequent programming stages, as described below”). It would have been obvious to program/embed the hardware key during fabrication because this is how platform/hardware keys are produced.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Haridas et al PN 2017/0359171 in view of Sayyed et al PN 2023/0021213 and Lee et al PN 2014/0164753 as applied to claim 3 above, and further in view of Fan et al PN 2020/0387613.
In regards to claim 8: Haridas et al states the key is generated ([0115] “As shown in FIG. 11, a new secondary key pair is generated at step 1102. This could include, for example, the processor 202 of the build machine 302 interacting with the key management service 306 to generate a new secondary key pair (SSK2/SPK2)”). Haridas et al also states ([0086] “The memory 210 may represent a random access memory or any other suitable volatile or non-volatile storage device(s)”). Haridas et al also states ([0063] “To build the chain of trust, a hash of the primary public key could be burned into the device itself, such as by using effuse technology, during manufacturing. The hash could be denoted as eFUSE.PPKhash”). Burning is a read/ write once memory as opposed to a read/writable memory. Fan et al teaches ([0038] “ After the boot apparatus 10 receives the boot key, the boot code and the original signature, the processor 16 writes the original signature and the boot key into the secure area 142 in the storage device 14, and writes the boot code into the boot partition 144 in the storage device 14”). It would have been obvious to have the generated key be written into a writable memory because this would have prevented having to regenerate the boot key every time it is needed.
Allowable Subject Matter
Claims 2, 5-6, 9-11 are 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.
Claims 12-20 allowed.
In regards to claim 2, 12: Haridas et al teaches plural signatures but not expressly the claimed relationships with the different keys and a “second firmware image”.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Deymonnaz et al PN 2018/0198629 teaches rotating keys however is silent upon a signing server
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL R MYERS whose telephone number is (571)272-3639. The examiner can normally be reached telework M-F start 7-8 leave 4-5.
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, Jaweed Abbaszadeh can be reached at 571-270-1640. 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.
/Paul R. MYERS/Primary Examiner, Art Unit 2176
Prosecution Insights