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 .
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-8, 10-12, 13-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over KOTESHWARA [20240160749], in view of Waltermann [20060020810].
As to claim 1,
KOTESHWARA [20240160749] teaches a method of operation of a baseboard management controller (BMC), comprising:
holding a host computer [003: “firmware for a Host Processor/Platform Controller Hub (PCH) ”] in a reset state by asserting a reset signal to the host computer [0032: “Upon powering up the system 300, the RoT CPLD/FPGA 304 boots first and then holds the BMC or Host 208 in a reset state. ”- to place into reset state it has to provide signal or command.];
accessing at least a part of a BIOS image of the host computer from a storage device shared between the BMC [0034: “an 8 Gbit (1G×8) DDR3-SDRAM chip is connected to an Intel MAX 10 CPLD, providing total 1 GB firmware capacity shared by the PCH and BMC.”] and the host computer while the host computer is held in the reset state, [0032: “Using the management network 212, the cloud management sends BMC or Host firmware images directly to the DRAM 312 attached to the RoT CPLD/FPGA 304. In particular embodiments, the RoT CPLD/FPGA 304 performs cryptographic checks on the firmware before storing it in the DRAM 312. In particular embodiments, the RoT CPLD/FPGA 304 includes a processor 308 (e.g., a hard or soft processor) and cryptographic module 310 for performing the cryptographic checks and for storing cryptographic keys. ”];
validating at least the part of the BIOS image [0032: “In particular embodiments, the RoT CPLD/FPGA 304 includes a processor 308 (e.g., a hard or soft processor) and cryptographic module 310 for performing the cryptographic checks and for storing cryptographic keys. The BMC or Host 208 is then allowed to boot by accessing the firmware images stored in DRAM 312 via the emulated flash interface 306.”] ; and
releasing the reset signal to enable the host computer to start a boot process upon successful validation of at least the part of the BIOS image [0037: “the host 404 are then allowed to boot using the images stored on the DRAM 408. ”- when the booting process is in reset and booting image is performed cryptographic verification, it should release signal to enable host computer to start].
But Koteshwara teaches cryptographic validation which uses keys but do not explicitly teach wherein the BIOS image is protected based on a private key of a public key / private key pair
However, Waltermann [20060020810] teaches the BIOS image is protected based on a private key of a public key / private key pair and validating at least the part of the BIOS image based on a public key of the public key / private key pair [0033: “The signature authentication cycle is a process including a step of utilizing a one-way hash algorithm to generate a hash of BIOS 12. Utilizing a public key (typically provided with the software installation package) the pre-stored private key encrypted BIOS hash 65 is decrypted and the resulting decrypted hash is compared to the generated BIOS hash to authenticate the signature. ”- validation is performed and 0037: “the signature authentication performed by system authentication module 68 in cooperation with initial system file 82, or an equivalent operating system load module, fundamentally involves comparing a newly generated hash of BIOS 12 with the decrypted hash resulting from performing a public key decryption of the pre-stored, private key encrypted BIOS hash 65 and using the comparison to determine signature validity (step 134). ” and 0038: “Responsive to a determination that the digital signature is valid for the to-be-loaded operating system 14, i.e., the decrypted pre-stored BIOS hash matches the generated BIOS hash, system authentication module 68 sends a load/install authorization message to initial system file 82, or an equivalent operating system load module, enabling the software load/install process to continue as shown at steps 130 ”]
It would have been obvious to person of ordinary skill in the art before the effective filing date of the claimed invention to combine teaching of Koteshwara and Waltermann because both are directed toward validating BIOS. Furthermore, Waltermann improves upon Koteshwara by being able to private and pubic key to encrypt and decrypt the BIOS such that the data becomes more authenticity and integrity.
As to claim 2,
Koteshwara teaches the at least the part of the BIOS image is the full BIOS image, wherein the public key is stored in a BMC firmware image of the BMC [0031: “The immutable firmware image 152 includes minimal firmware used during initial boot to retrieve a complete firmware image using the management network 212” and see, Waltermann 0041: “Public key 85 is preferably stored together with decryption module 86 in association with the software installation package (FIG. 2A embodiment) or operating system recovery package (FIG. 2B embodiment). In an alternate embodiment, public key 85 is stored within the host data processing system such as within a flash memory device”- Both can be combined to provide secure booting by securely validating].
As to claim 3,
Waltermann teaches the validating the at least the part of the BIOS image comprises: decrypting the BIOS image using the public key; and comparing a first hash value calculated from the decrypted BIOS image with a second hash value stored in the BIOS image [0008: “the installation program includes or is provided with a public key decryption algorithm utilized during the authentication process for decrypting a digital signature in the form of a pre-stored, private key encrypted hash of the system BIOS. The installation program further includes a hash algorithm corresponding to the hash algorithm used to produce the digital signature for generating a hash of the system BIOS. The installation program then compares the decrypted BIOS hash with the generated BIOS hash to authenticate the system, which is utilized to determine whether to continue or terminate the software load or installation process.”].
As claim 4,
Koteshwara teach the BIOS image is stored in a Serial Peripheral Interface (SPI) storage device [0043:” In an embodiment, downloading the firmware image further comprises storing the firmware image in a temporary memory. In an embodiment, storage of the firmware image is provided using an emulated flash interface. In an embodiment, the emulated flash interface is compatible with a serial peripheral interface (SPI) flash module.”]
As to claim 5,
Koteshwara teach the at least the part of the BIOS image is an initial boot block (IBB) of the BIOS image [0040: “The method further includes booting 506 the networked device using the temporary firmware image. In an embodiment, first instructions are executed by the networked device from the basic firmware image such that initial boot of the networked device is performed using the immutable firmware image. In an embodiment, a firmware image required for a complete boot of the networked device is downloaded from a cloud server controller.”].
As to claim 6,
Waltermann teaches the validating the at least the part of the BIOS image comprises: deriving the public key from public key components stored in the IBB; generating a hash of the derived public key; and comparing the generated hash with a hash of the public key stored in a BMC firmware image of the BMC [0008: “The installation program further includes a hash algorithm corresponding to the hash algorithm used to produce the digital signature for generating a hash of the system BIOS. The installation program then compares the decrypted BIOS hash with the generated BIOS hash to authenticate the system, which is utilized to determine whether to continue or terminate the software load or installation process.”].
As to claim 7,
Koteshwara teach comprising: allowing code from the IBB to validate a remaining part of the BIOS image during the boot process of the host computer [0032; “Upon powering up the system 300, the RoT CPLD/FPGA 304 boots first and then hold the BMC or Host 208 in a reset state. Using the management network 212, the cloud management sends BMC or Host firmware images directly to the DRAM 312 attached to the RoT CPLD/FPGA 304. In particular embodiments, the RoT CPLD/FPGA 304 performs cryptographic checks on the firmware before storing it in the DRAM 312”].
As to claim 8,
Waltermann teaches validate the remaining part of the BIOS image, the method further comprises: verifying a signature of the remaining part of the BIOS image using the public key derived from public key components stored in the IBB [0037: “the signature authentication performed by system authentication module 68 in cooperation with initial system file 82, or an equivalent operating system load module, fundamentally involves comparing a newly generated hash of BIOS 12 with the decrypted hash resulting from performing a public key decryption of the pre-stored, private key encrypted BIOS hash 65 and using the comparison to determine signature validity (step 134). ”].
As to claim 10,
Waltermann teaches to validate the remaining part of the BIOS image, the method further comprises: comparing a hash of a manifest table in the BIOS image with a stored hash in the BIOS image [0042: “Compare module 96 includes circuit and/or program module means for receiving and comparing decrypted BIOS hash 88 with locally generated BIOS hash 94 (step 151). The process ends as shown at steps 152 and 154 with system authentication module 68 sending a validity result message or command to the associated load/install application. Specifically, responsive to compare module 96 finding a match, system authentication module 68 delivers a load/install enable message or command to the associated load/install module 66 to commence or continue the loading process”].
As to claim 11,
Waltermann teaches when the validation of the remaining part of the BIOS image fails, the method further comprises: receiving, at the BMC, a notification of the validation failure; and preventing the host computer from booting [0038: “Responsive to a determination that the digital signature is valid for the to-be-loaded operating system 14, i.e., the decrypted pre-stored BIOS hash matches the generated BIOS hash, system authentication module 68 sends a load/install authorization message to initial system file 82, or an equivalent operating system load module, enabling the software load/install process to continue as shown at steps 130. Otherwise, as depicted at step 136, if the digital signature is determined by system authentication module 68 not to be valid, the load process is halted and the process ends at step 138. ”].
As to claim 12,
Koteshwara teach 12. The method of claim 1, further comprising: verifying BMC firmware by a Hardware Root of Trust (HROT) engine before the validating the at least the part of the BIOS image [0031; “In one embodiment, the emulated flash module 302 is implemented on a Complex Programmable Logic Device or Field Programmable Gate Array (CPLD/FPGA) which is termed as the Root-of-Trust (RoT) CPLD/FPGA 304. The RoT CPLD/FPGA 304 has sufficient security measures such that it is trusted and functions as the first device to boot in a system.”. Also see 0032].
As to claim 13-19,
Combination of Koteshwara and Waltermann teach this claim according to the reasoning set forth in claim 1-7 supra.
As to claim 20,
Combination of Koteshwara and Waltermann teach this claim according to the reasoning set forth in claim 1 supra.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over KOTESHWARA [20240160749], in view of Waltermann [20060020810], further in view of Kawazu [20220137953]
As to claim 9,
Combination of Koteshwara and Waltermann teach validating BIOS.
But Combination of Koteshwara and Waltermann do not explicitly teach the signature is an Elliptic Curve Digital Signature Algorithm (ECDSA) signature.
However, Kawazu [20220137953] teaches the falsification detection unit 351 verifies whether the BIOS 360 is falsified using a first signature value 402 stored in the first SPI flash memory 213. The first signature value 402 will be described below with reference to FIG. 4. Examples employable as the signature verification method include a signature verification algorithm using the Rivest-Shamir-Adleman (RSA) public key cryptography and an Elliptic Curve Digital Signature Algorithm (ECDSA) signature verification algorithm using the elliptic-curve public key cryptography, which are known techniques. The public key used to verify the signature may be stored in the ROM included in the embedded controller 212 or may be stored in the first SPI flash memory 213 or the second SPI flash memory 214. The falsification detection unit 351 has also a function of verifying whether the BIOS golden copy 403 is falsified using a second signature value 405 stored in the second SPI flash memory 214
It would have been obvious to person of ordinary skill in the art before the effective filing date of the claimed invention to combine teaching of Combination of Koteshwara and Waltermann and Kawazu because all are directed toward BIOS verification. Furthermore, Kawazu improves upon Combination of Koteshwara and Waltermann by being able to use ECDSA signature to verify BIOS in order to provide enhanced efficiency in verification.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mihm et al [20190042752] teaches [0035: “The example host communicator 250 monitors the host processor 105 to identify when a host initialization (e.g., a boot process) is occurring. In some examples, the example host communicator 250 initiates a restart of the host processor 105, thereby triggering the initialization…upon detection of the host initialization, alerts the firmware memory interface 240, to enable the firmware memory interface 240 to set a flag in the firmware memory 107 to halt the boot process. However, the processor 105 may be instructed to halt the boot process in any other fashion ”] [0073: “an occurrence of a boot process of a host processor, halt the boot process of the host processor, access the firmware image from the baseboard management memory,” ]0073: “validate the firmware image, ” [0073: “in response to determining that the firmware image is valid, write the firmware image to a firmware memory, and enable the host processor to continue the boot process using the firmware image stored in the firmware memory. ”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KESHAB R PANDEY whose telephone number is (571)270-0176. The examiner can normally be reached Monday-Friday 9:00-5:00(ET).
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.
/KESHAB R PANDEY/ Primary Examiner, Art Unit 2176