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 .
Response to Amendment
Objection to Abstract is overcome by amendment.
The 112(b) rejection of claim 1 is overcome by amendment.
The 112(b) rejection of claim 9 is overcome by amendment.
Response to Arguments
Applicant's arguments filed 11/25/2024 have been fully considered but they are not persuasive with regard to claims 13-20. However, upon further consideration, a new ground(s) of rejection is made in view of Smith (US 20080126779 A1) in view of Konetski et al. (US 10846408 B2), Pappachan et al. (US 20170024570 A1) and Nalawadi et al. (US 20050055588 A1).
Applicant argues on pg. 8 of remarks regarding claim 13:
The Office Action does not specifically identify where the cited references disclose or suggest the targeted verification of the RBE, BUP, and PMC regions. Pappachan et al. discusses a general framework for remote attestation of hardware, firmware, and software but does not specifically disclose or suggest verifying the ME firmware, let alone the specific RBE, BUP, and PMC regions. Similarly, Nalawadi et al. is focused on local verification of power management code, such as ACPI, within a secure environment and provides no teaching or suggestion regarding the ME firmware or the transmission of hash values to another IHS for verification. Thus, the combination of Pappachan et al. and Nalawadi et al. does not disclose all elements of Claim 13.
Applicant similarly applies the same argument to claims 1 and 17 on pg. 10 of remarks.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “verifying the RBE, BUP, and PMC regions of the ME firmware”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Notably, the claim does not recite that the RBE, BUP and PMC regions of non-volatile memory are “of” the ME firmware. Instead, the claim recites:
calculate a hash value based upon contents of a Read-Only Memory (ROM) Boot Extension (RBE) area, a Bringup (BUP) area, and a Power Management Controller (PMC) area of a flash memory used by a Manageability Engine (ME) coupled to a processor of the IHS;
The claims make no recitation that each of the regions belong to, or are a part of the Manageability Engine firmware code. Instead, these regions are firmware code stored in flash memory in claims 13 and 17 or non-volatile memory as in claim 1, and separately, the flash or non-volatile memory is used by the Manageability Engine. The specificity Applicant argues is claimed is recited nowhere in the claims.
Pappachan discloses:
[0028] “In some embodiments, the security engine 138 may be embodied as a manageability engine, an out-of-band processor, a Trusted Platform Module (TPM), or other security engine device or collection of devices.”
[0045] “The attestation information may be collected by a trusted system agent such as the security engine 138 that loads the firmware code into the I/O controllers 144 (e.g., the security engine 138 BUP and RBE firmware on Intel® platforms). In block 414, the computing device 100 verifies the attestation information for the firmware. The computing device 100 may verify, for example, the cryptographic hash of the firmware code and ensure that the code was signed by a trusted entity (e.g., a processor manufacturer such as Intel® or a manufacturer of the computing device 100), verify the security version number, or verify other information associated with the firmware code.”
Par. [0045] explicitly states, “The attestation information may be collected by a trusted system agent such as the security engine 138 that loads the firmware code into the I/O controllers 144 (e.g., the security engine 138 BUP and RBE firmware on Intel® platforms).” Which establishes that the BUP and RBE are portions of firmware. Then further states, “The computing device 100 may verify, for example, the cryptographic hash of the firmware code and ensure that the code was signed by a trusted entity…” Therefore, Pappachan at least explicitly teaches “obtain, by an Operating System (OS) agent, a measurement of contents of a selected area of a Non-Volatile Memory (NVM) used by a Trusted Execution Environment (TEE) coupled to the processor, wherein the selected area comprises at least one of: a Read-Only Memory (ROM) Boot Extension (RBE) area, a Bringup (BUP) area ” recited in claim 1, “calculate a hash value based upon contents of a Read-Only Memory (ROM) Boot Extension (RBE) area, a Bringup (BUP) area, ” recited in claim 13, and “receiving a hash value calculated by an Information Handling System (IHS) based upon contents of a Read-Only Memory (ROM) Boot Extension (RBE) area, a Bringup (BUP) area, ” recited in claim 17. Thus, at least Pappachan in combination with Smith and Kotenski disclose claims 1, 13 and 17 under the BRI of the claims.
Nalawadi discloses:
[0040] “If it is determined that the power management code is needed, at block 502, processing logic performs an authentication on the power management code to determine whether the power management code is trusted. According to one embodiment, the power management code is needed when the corresponding application or driver is capable of handling the power management events, such as, for example, the suspend/resume or wake-on-ring events. In one embodiment, processing logic authenticates the power management code using a pair of private and public keys, similar to the private and public PGP (Pretty Good Privacy) key pair via a variety of encryption techniques, including the hash operations, such as SHA-1 (RFC 3174) or MD-5 (e.g., RFC 1321) hash function, or other encryption algorithms, such as, for example, the RSA encryption mechanisms available from RSA Security, Inc. Other processes, such as a checksum process of the code image, may be performed as a part of the authentication.”; [0044] “In one embodiment, exemplary power management code 601 is an ACPI compatible code, which may include, among others, a header 602, a public key 603, a signature block 604, a ACM (ACPI code module) body 606, and some other scratch spaces 605. ACPI code 601 may be stored in a ROM, such as ROM 107 of data processing system 100 shown in FIG. 1. Alternatively, ACPI code 601 may be stored in a nonvolatile RAM, such as nonvolatile RAM 106.”
As above, Nalawadi explicitly discloses verifying the “power management code” is trusted by calculating a hash and verifying in a trusted environment. Therefore, Nalawadi at least teaches “obtain, by an Operating System (OS) agent, a measurement of contents of a selected area of a Non-Volatile Memory (NVM) used by a Trusted Execution Environment (TEE) coupled to the processor, wherein the selected area comprises at least one of: a Power Management Controller (PMC) area” recited in claim 1, “calculate a hash value based upon contents of a Read-Only Memory (ROM) Boot Extension (RBE) area, a Bringup (BUP) area, and a Power Management Controller (PMC) area of a flash memory used by a Manageability Engine (ME) coupled to a processor of the IHS” recited in claim 13, and “receiving a hash value calculated by an Information Handling System (IHS) based upon contents of ” recited in claim 17. Thus, at least Nalawadi in combination with Smith and Kotenski under disclose claims 1, 13 and 17 the BRI of the claims and further, Nalawadi in combination with Smith, Kotenski and Pappachan.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007).
As stated in MPEP 2143.01, “Obviousness can be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so. In re Kahn, 441 F.3d 977, 986, 78 USPQ2d 1329, 1335 (Fed. Cir. 2006) (discussing rationale underlying the motivation-suggestion-teaching test as a guard against using hindsight in an obviousness analysis). Axonics, Inc. v. Medtronic, Inc., 73 F.4th 950, 957-58, 2023 USPQ2d 795 (Fed. Cir. 2023) (the court found an erroneous framing of the motivation inquiry led to an incorrect conclusion of nonobviousness). A "motivation to combine may be found explicitly or implicitly in market forces; design incentives; the ‘interrelated teachings of multiple patents’; ‘any need or problem known in the field of endeavor at the time of invention and addressed by the patent’; and the background knowledge, creativity, and common sense of the person of ordinary skill." Zup v. Nash Mfg., 896 F.3d 1365, 1371, 127 USPQ2d 1423, 1427 (Fed. Cir. 2018) (quoting Plantronics, Inc. v. Aliph, Inc., 724 F.3d 1343, 1354 [107 USPQ2d 1706] (Fed. Cir. 2013) (citing Perfect Web Techs., Inc. v. InfoUSA, Inc., 587 F.3d 1324, 1328 [92 USPQ2d 1849] (Fed. Cir. 2009) (quoting KSR, 550 U.S. at 418-21)). See MPEP § 2143 regarding the need to provide a reasoned explanation even in situations involving common sense or ordinary ingenuity. See also MPEP § 2144.05, subsection II, B.”
The prior art references under scrutiny are generally directed to verifying hashes measured or calculated from portions of non-volatile or flash memory in a secure or trusted environment, it would be obvious to one of ordinary skill in the art to combine the references to achieve the claimed limitations. The scope of the claims overlap with the combination of prior art of record and therefore are rejected as under 35 U.S.C. 103.
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “another IHS configured to perform integrity verification of the TEE…” at the OS agent from the another IHS, in claim 1.
Because this claim limitation(s) is being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it is being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 1, 2, and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Smith (US 20080126779 A1) in view of Konetski et al. (US 10846408 B2), Pappachan et al. (US 20170024570 A1) and Nalawadi et al. (US 20050055588 A1).
Regarding claim 1, Smith discloses An Information Handling System (IHS), comprising: (Smith, Fig. 1 #100)
a processor; and (Smith, Fig. 1 #106)
a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution, cause the IHS to: (Smith, Fig. 1 #114)
obtain, by an Operating System (OS) agent (Smith, Fig. 2-5), a measurement of contents of a selected area of a Non-Volatile Memory (NVM) (Smith, Fig. 1 #134) used by a Trusted Execution Environment (TEE) (Smith, Fig. 1 #102) coupled to the processor, (Smith, [0033] “The ME 102 invokes the TPM 104 to measure a hash value of the CRTM 132 and verify that CRTM hash value with a hash value stored in secure memory (external to the TPM 104 or within the TPM 104) before allowing any code to be executed by the processor 108.”)
Smith fails to explicitly disclose wherein the selected area comprises at least one of: a Read-Only Memory (ROM) Boot Extension (RBE) area, a Bringup (BUP) area, and a Power Management Controller (PMC) area;
transmit the measurement from the OS agent to another IHS configured to perform integrity verification of the TEE based, at least in part, upon the measurement; and receive, at the OS agent from the other IHS, an indication of a result of the integrity verification.
However, Konetski teaches transmit the measurement from the OS agent to another IHS configured to perform integrity verification of the TEE based, at least in part, upon the measurement; and (Konetski, Cl. 8 ln. 40-61, “Also as described in addition detail below, the initial and ongoing verification of the integrity of the platform 205 and/or the secured virtual environment 230 may be implemented via a remote, trusted attestation service 245 that verifies the integrity of certain hardware and/or software components of platform 205, thus providing assurance that the platform 205 has not been compromised.”)
receive, at the OS agent from the other IHS, an indication of a result of the integrity verification. (Konetski, Cl. 8 ln. 40-61, “The trusted attestation service 245 may verify the hardware integrity of platform 205 via out-of-band communications with the trusted platform resource 210 and secured communications with a trusted agent 215 operating on platform 205, thus protecting the enterprise data 240 without reliance on the installed operating system 225.”)
Examiner notes, the “agent” of Applicant’s claimed invention is limited to the set of instructions illustrated in Fig. 3 #304, and described at par. [0063]-[0066] of the instant application. Thus, the OS agent merely comprises a set of instructions for performing the functions claimed.
Konetski is directed to remotely configuring a secured virtual environment on an Information Handling System (IHS). Konetski discloses integrity verification of hardware and/or software of an IHS via remote attestation, which includes sending a hash to a remote verifier and receiving the result.
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith to incorporate the teachings of Konetski to include transmitting the measurement from the OS agent to another IHS configured to perform integrity verification of the TEE based, at least in part, upon the measurement; and receiving, at the OS agent from the other IHS, an indication of a result of the integrity verification. Such modification(s) would be motivated to detect and mitigate the effects of an employee accessing business data from an IHS that has been compromised. (Konetski, Cl. 1 ln. 9-31)
Pappachan discloses obtain, by an Operating System (OS) agent (Pappachan, #138), a measurement of contents of a selected area of a Non-Volatile Memory (NVM) (Pappachan, #134) used by a Trusted Execution Environment (TEE) (Pappachan, [0026] “The data storage device 134 may be embodied as any type of device or devices configured for short-term or long-term storage of data such as, for example, memory devices and circuits, memory cards, hard disk drives, solid-state drives, or other data storage devices. In some embodiments, the data storage device 134 may be used to store the contents of one or more secure enclaves. When stored by the data storage device 134, the contents of the secure enclave may be encrypted to prevent unauthorized access.”) wherein the selected area comprises at least one of: a Read-Only Memory (ROM) Boot Extension (RBE) area, a Bringup (BUP) area, and (Pappachan, [0028] “In some embodiments, the security engine 138 may be embodied as a manageability engine, an out-of-band processor, a Trusted Platform Module (TPM), or other security engine device or collection of devices.”; [0045] “The attestation information may be collected by a trusted system agent such as the security engine 138 that loads the firmware code into the I/O controllers 144 (e.g., the security engine 138 BUP and RBE firmware on Intel® platforms). In block 414, the computing device 100 verifies the attestation information for the firmware. The computing device 100 may verify, for example, the cryptographic hash of the firmware code and ensure that the code was signed by a trusted entity (e.g., a processor manufacturer such as Intel® or a manufacturer of the computing device 100), verify the security version number, or verify other information associated with the firmware code.”)
transmit the measurement from the OS agent to another IHS configured to perform integrity verification of the TEE based, at least in part, upon the measurement; and receive, at the OS agent from the other IHS, an indication of a result of the integrity verification. (Pappachan, [0035] “For example, the software attestation information may include one or more secure enclave reports, which are each indicative of a cryptographic measurement of a trusted software component. The software attestation module 206 is further configured to verify the software attestation information. The software attestation module 206 may be configured to verify the software attestation information locally, or to submit the software attestation information to a remote verification service. In some embodiments, those functions may be performed by one or more sub-modules, such as a local verifier 208 and/or a remote verifier 210.”)
Pappachan is directed to attestation and verification of trusted I/O. Pappachan discloses taking cryptographic measurements (hashes) of the contents of firmware code stored in memory for verification and attestation that the contents are trusted. Pappachan explicitly makes reference to verifying the contents of a BUP and RBE firmware code using this process, including a remote verifier, which is broadly the same concept as the claimed invention. Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Konetski to incorporate the teachings of Pappachan to include the above limitations. Such modification(s) would be motivated to provide confidentiality, integrity, and replay-protection to the secure enclave data while the data is resident in the platform memory and thus provides protection against both software and hardware attacks. (Pappachan, [0003])
The combination of Smith, Konetski and Pappachan fail to explicitly disclose obtain, by an Operating System (OS) agent, a measurement of contents of a selected area of a Non-Volatile Memory (NVM) used by a Trusted Execution Environment (TEE) wherein the selected area comprises a Power Management Controller (PMC) area;
However, Nalawadi teaches obtain, by an Operating System (OS) agent, a measurement of contents of a selected area of a Non-Volatile Memory (NVM) used by a Trusted Execution Environment (TEE) wherein the selected area comprises a Power Management Controller (PMC) area; (Nalawadi, [0040] “If it is determined that the power management code is needed, at block 502, processing logic performs an authentication on the power management code to determine whether the power management code is trusted. According to one embodiment, the power management code is needed when the corresponding application or driver is capable of handling the power management events, such as, for example, the suspend/resume or wake-on-ring events. In one embodiment, processing logic authenticates the power management code using a pair of private and public keys, similar to the private and public PGP (Pretty Good Privacy) key pair via a variety of encryption techniques, including the hash operations, such as SHA-1 (RFC 3174) or MD-5 (e.g., RFC 1321) hash function, or other encryption algorithms, such as, for example, the RSA encryption mechanisms available from RSA Security, Inc. Other processes, such as a checksum process of the code image, may be performed as a part of the authentication.”; [0044] “In one embodiment, exemplary power management code 601 is an ACPI compatible code, which may include, among others, a header 602, a public key 603, a signature block 604, a ACM (ACPI code module) body 606, and some other scratch spaces 605. ACPI code 601 may be stored in a ROM, such as ROM 107 of data processing system 100 shown in FIG. 1. Alternatively, ACPI code 601 may be stored in a nonvolatile RAM, such as nonvolatile RAM 106.”)
Nalawadi is directed to loading and unloading power management code in a secure environment. Nalawadi describes verifying the integrity/authenticity of power management code, which is drawn to the Power Management Controller area, using a hash-based verification method. Both are directed to verifying integrity of firmware code to ensure that it is trusted for use in a secure environment (TEE or ME).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Konetski and Pappachan to incorporate the teachings of Nalawadi to include calculate a hash value based upon contents of… a Power Management Controller (PMC) area of a flash memory used by a Manageability Engine (ME) coupled to a processor of the IHS. Such modification(s) would be motivated to allow power management features to be loaded and unloaded dynamically as a trusted module. (Nalawadi, [0003])
Regarding claim 2, Smith in view of Konetski and Pappachan and Nalawadi disclose The IHS of claim 1, wherein the TEE comprises at least one of: a Manageability Engine (ME), (Smith, Fig. 1 #102, [0013] “FIG. 1 is a block diagram of an example system 100 for performing a secure boot, including a manageability engine (ME) 102 capable of invoking services (e.g., cryptographic processes) of a TPM 104.”) a Platform Security Processor (PSP), or an Embedded Controller (EC).
The limitation, “at least one of” requires that only one of the listed components be present. Therefore, the prior art need only teach one of the listed requirements to meet the claim.
Regarding claim 11, Smith in view of Konetski and Pappachan and Nalawadi disclose The IHS of claim 1, wherein the selected area is identified, at least in part, via application of a parser to TEE instructions obtained by an Original Equipment Manufacturer (OEM) of the IHS from a manufacturer of the TEE. (Smith, [0033] “The ME 102 invokes the TPM 104 to measure a hash value of the CRTM 132 and verify that CRTM hash value with a hash value stored in secure memory (external to the TPM 104 or within the TPM 104) before allowing any code to be executed by the processor 108.”)
The “parser” may be any means of identifying a “selected area” so long as it is applied to the “TEE instructions”.
Claims 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over Smith in view of Konetski, Pappachan and Nalawadi as applied to claim 1 above, and further in view of Held et al. (US 20130013905 A1).
Regarding claim 4, Smith in view of Konetski and Pappachan and Nalawadi disclose The IHS of claim 1, wherein the program instructions, upon execution, further cause the IHS to receive, at the OS agent from an Original Equipment Manufacturer (OEM) of the IHS, an indication of an address range of the selected area. (Held, Fig. 4 #410, [0041] “Operation 410 includes determining whether there is a firmware interface table (FIT) with a signed manifest and an OEM BIOS block in flash memory”)
Regarding claim 5, Smith in view of Konetski and Pappachan and Nalawadi and Held disclose The IHS of claim 4, wherein address range of the selected area is specific to at least one of: a model number, a serial number, or a service tag of the IHS. (Held, [0022] “At least a portion of processor non-volatile memory 123 may be accessible via one or more model specific registers (MSRs) 132, 133… Advantageously, configuring the BIOS_VERIFICATION MSR as an ephemeral MSR 133 allows a BIOS vendor to update the BIOS during an operational life of the computing platform.”)
Claims 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Smith in view of Konetski, Pappachan and Nalawadi as applied to claim 1 above, and further in view of Silveira et al. (US 20220179959 A1).
Regarding claim 6, Smith in view of Konetski, Pappachan and Nalawadi disclose The IHS of claim 1, but fail to explicitly teach wherein the program instructions, upon execution, further cause the IHS to receive, at the OS agent from an Original Equipment Manufacturer (OEM) of the IHS, an indication of a type of the measurement.
However, Silveira teaches wherein the program instructions, upon execution, further cause the IHS to receive, at the OS agent from an Original Equipment Manufacturer (OEM) of the IHS, an indication of a type of the measurement. (Silveira, [0043] “In accordance with example implementations, in response to an attestation request from a remote verifier 195, the TPM 150 may sign the PCR memory content to form an authenticated digest that is sent to the verifier 195, along with the data representing the current version of the workload integrity log 137.”)
It should be noted, an “indication” is broad, and may include any message or signal received by the IHS relating to the integrity measurement.
Silveira is directed to measuring integrity of memory through a remote attestation. Specifically, Silveira discloses calculating a hash of integrity measurements and storing them in a PCR, which is then used by a verifier to determine the integrity of the measurement. Smith, similarly discloses such integrity measurements but lacks the implementation of remote attestation. Konetski also lacks the explicit disclosure of an indication received from the remote verifier.
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Konetski, Pappachan and Nalawadi to incorporate the teachings of Silveira to include wherein the program instructions, upon execution, further cause the IHS to receive, at the OS agent from an Original Equipment Manufacturer (OEM) of the IHS, an indication of a type of the measurement. Such modification(s) would be motivated to determine that the computer platform is trustworthy. (Silveira, [0014])
Regarding claim 7, Smith in view of Konetski, Pappachan, Nalawadi and Silveira disclose The IHS of claim 6, wherein the type of the measurement comprises a hash value calculated based upon of at least a portion of the contents. (Silveira, [0038] “As mentioned above, a signed digest of the hashes 153 may be used by a remote verifier 195 to prove that the logged integrity measurements are authentic (i.e., used to prove that the logged integrity measurements have not been subject to tampering or otherwise compromised).”)
Claims 8-10 are rejected under 35 U.S.C. 103 as being unpatentable over Smith in view of Konetski, Pappachan, Nalawadi and Silveira as applied to claim 7 above, and further in view of Held et al. (US 20130013905 A1).
Regarding claim 8, Smith in view of Konetski, Pappachan, Nalawadi and Silveira The IHS of claim 7, but fail to explicitly teach wherein to perform the integrity verification, the other IHS is configured to compare the hash value against a reference hash value calculated based upon TEE instructions provided to the OEM by a manufacturer of the TEE.
However, Held teaches wherein to perform the integrity verification, the other IHS is configured to compare the hash value against a reference hash value calculated based upon TEE instructions provided to the OEM by a manufacturer of the TEE. (Held, [0042] “If there is not a firmware interface table (FIT) with a signed manifest or there is not an OEM BIOS block in flash memory, operation 415 may be performed. Operation 415 includes setting an immutable model specific register (NOT_SIGNED_MSR) and/or halting the processor subsystem. If there is a FIT with a signed manifest and an OEM BIOS block in flash memory, operation 420 may be performed. Operation 420 includes reading the signed manifest and associated OEM UEFI BIOS firmware volume. Operation 420 may further include verifying the signed manifest (digital signature) with a remote certificate authority (CA). For example, verifying the signed manifest may be performed OOB using the microprocessor subsystem 112 and manageability engine firmware 138.”; [0045] “The initialization firmware may then verify OEM BIOS and/or enable interconnect fabric (e.g. QPI) and system memory as described herein during sub-phase 506.”)
Held is directed to BIOS flash attack protection and notification. Specifically, Held discloses a system that verifies BIOS/Firmware via a remote verification. Held also discloses that the installed BIOS/Firmware is verified before boot, and that the BIOS/Firmware is stored in a ROM. Held also discloses the updates are specific to the model, which is identified in a “Model Specific Register”.
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Konetski, Pappachan, Nalawadi and Silveira to incorporate the teachings of Held to include wherein the selected area comprises at least one of: a Read-Only Memory (ROM) Boot Extension (RBE) area, a Bringup (BUP) area, or a Power Management Controller (PMC) area. Such modification(s) would be motivated to detect compromised firmware. (Held, [0004])
Regarding claim 9, Smith in view of Konetski, Pappachan, Nalawadi, Silveira and Held disclose The IHS of claim 8, wherein the TEE instructions are delivered to the TEE in combination with a Basic/Input Output System (BIOS) update produced by the OEM, and wherein the parser is applied to the BIOS update to identify the TEE instructions. (Held, [0029] “Turning again to FIG. 1, microprocessor subsystem 112 may include an embedded microprocessor 140, cache memory 142 and non-volatile memory (ROM) 144. The microprocessor subsystem 112 is configured to execute manageability engine firmware 138 stored in flash memory 114. In this embodiment, the microprocessor subsystem 112 is coupled to the processor complex 102 via the Platform Controller Hub (PCH) 106 and to the network 120 and remote agent 118 via the network port 116. The microprocessor subsystem 112 is configured to provide out-of-band communication. The out-of-band communication may be between microprocessor subsystem 112 and processor complex 102 and/or between system 100 and remote agent 118. For example, if verification of BIOS 134 fails, the microprocessor subsystem 112 (and manageability engine firmware 138) may be configured to communicate OOB with remote agent 118 to retrieve an updated, verified BIOS from remote agent 118. Advantageously, this may allow remotely updating and/or authenticating the BIOS stored in a flash memory that has been attacked without requiring actual on-site physical access to the flash memory 114.”)
Examiner notes, the limitation “the TEE instructions” are interpreted as any software instructions executed by the TEE, which also includes the firmware or BIOS that is to be updated. The limitation, “the parser is applied to the BIOS update to identify the TEE instructions” is interpreted as any means of identifying the TEE instructions. This may include verification of the BIOS update via instructions or a hardware component. It is not recited what component is performing the function of the “parser”. It is further noted, the claim does not specify whether the claimed limitations occur during runtime or boot, or any mode of operation of the IHS.
Regarding claim 10, Smith in view of Konetski, Silveira and Held disclose The IHS of claim 8, wherein the TEE instructions are delivered to the TEE in combination with the BIOS update as a single binary file. (Held, [0036] “Operation 370 may include updating the initialization firmware and/or BIOS via Out Of Band (OOB) communications. For example, the microprocessor subsystem 112 of FIG. 1 may be configured to communicate over network 120 to remote agent 118 via OOB communication to retrieve an updated, uncompromised BIOS”)
The limitation “as a single binary file” may be attributed to both the “TEE instructions” in combination with the “BIOS update”, or just the “BIOS update” under the BRI. Furthermore, “a single binary file” merely indicates “a” piece of data, as it is understood in the art, data is stored in binary.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Smith in view of Konetski, Pappachan, Nalawadi as applied to claim 1 above, and further in view of Wentz et al. (WO 2020223588 A1).
Regarding claim 12, Smith in view of Konetski, Pappachan, Nalawadi disclose The IHS of claim 1, but fail to explicitly disclose wherein the program instructions, upon execution, further cause the IHS to transmit the indication to a remote service configured to perform a security score assessment of the IHS based, at least in part, upon the indication.
However, Wentz teaches wherein the program instructions, upon execution, further cause the IHS to transmit the indication to a remote service configured to perform a security score assessment of the IHS based, at least in part, upon the indication. (Wentz, [0090] “Still referring to FIG. 3, systems and methods as described herein may involve computation, calculation, assessment, assignment, or use of a confidence level associated with one or more processes, devices, or data, including without limitation one or more processes, appraisals, and/or cryptographic evaluators as described herein. Confidence level, as used herein, is an element of data expressing a degree to which the safety, security, or authenticity of a process, device, or datum may be relied upon. As used herein, a confidence level may include a numerical score;”; [0096] “Still referring to FIG. 1, revocation list 144 may be updated continuously and/or periodically; for instance, when any cryptographic evaluator 112 and/or authenticating device 104 determines that a requesting device 140 and/or a set of devices associated with an identifier, credential, and/or verification datum as described in this disclosure, has performed a malicious or suspicious activity, failed to meet a threshold for confidence level, or the like, such cryptographic evaluator 112 and/or authenticating device 104 may post such a conclusion, and/or the credential, verification datum, and/or a device identifier to revocation list 144. Posting may include posting to a sub-list 148 associated with the relevant device or set of devices as described above.”)
The recited limitation is not necessarily linked to the remote verification method claimed previously by Applicant, but includes it in the “program instructions”. Therefore, any prior art that discloses determining a security score via a remote service meets the claim.
Wentz is directed to authenticating devices in a distributed ledger. Specifically, Wents discloses a remote verification process, including determining confidence level of a device via a numerical score.
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Konetski, Pappachan, Nalawadi to incorporate the teachings of Wentz to include wherein the program instructions, upon execution, further cause the IHS to transmit the indication to a remote service configured to perform a security score assessment of the IHS based, at least in part, upon the indication. Such modification(s) would be motivated to determine the safety, security or authenticity of a device. (Wentz, [0090])
Claim(s) 13-14 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Pappachan et al. (US 20170024570 A1) in view of Nalawadi et al. (US 20050055588 A1).
Regarding claim 13, Pappachan discloses A memory storage device having program instructions stored thereon that, upon execution by an Information Handling System (IHS), cause the IHS to: (Pappachan, Fig. 1 #134)
calculate a hash value based upon contents of a Read-Only Memory (ROM) Boot Extension (RBE) area, a Bringup (BUP) area… of a flash memory used by a Manageability Engine (ME) coupled to a processor of the IHS (Pappachan, [0028] “In some embodiments, the security engine 138 may be embodied as a manageability engine, an out-of-band processor, a Trusted Platform Module (TPM), or other security engine device or collection of devices.”; [0045] “The attestation information may be collected by a trusted system agent such as the security engine 138 that loads the firmware code into the I/O controllers 144 (e.g., the security engine 138 BUP and RBE firmware on Intel® platforms). In block 414, the computing device 100 verifies the attestation information for the firmware. The computing device 100 may verify, for example, the cryptographic hash of the firmware code and ensure that the code was signed by a trusted entity (e.g., a processor manufacturer such as Intel® or a manufacturer of the computing device 100), verify the security version number, or verify other information associated with the firmware code.”)
transmit the hash value to another IHS configured to perform integrity verification of the ME based, at least in part, upon the hash value; and receive, from the other IHS, an indication of a result of the integrity verification. (Pappachan, [0035] “For example, the software attestation information may include one or more secure enclave reports, which are each indicative of a cryptographic measurement of a trusted software component. The software attestation module 206 is further configured to verify the software attestation information. The software attestation module 206 may be configured to verify the software attestation information locally, or to submit the software attestation information to a remote verification service. In some embodiments, those functions may be performed by one or more sub-modules, such as a local verifier 208 and/or a remote verifier 210.”)
Pappachan fails to explicitly disclose calculate a hash value based upon contents of… a Power Management Controller (PMC) area of a flash memory used by a Manageability Engine (ME) coupled to a processor of the HIS.
However, Nalawadi teaches calculate a hash value based upon contents of… a Power Management Controller (PMC) area of a flash memory used by a Manageability Engine (ME) coupled to a processor of the IHS; (Nalawadi, [0040] “If it is determined that the power management code is needed, at block 502, processing logic performs an authentication on the power management code to determine whether the power management code is trusted. According to one embodiment, the power management code is needed when the corresponding application or driver is capable of handling the power management events, such as, for example, the suspend/resume or wake-on-ring events. In one embodiment, processing logic authenticates the power management code using a pair of private and public keys, similar to the private and public PGP (Pretty Good Privacy) key pair via a variety of encryption techniques, including the hash operations, such as SHA-1 (RFC 3174) or MD-5 (e.g., RFC 1321) hash function, or other encryption algorithms, such as, for example, the RSA encryption mechanisms available from RSA Security, Inc. Other processes, such as a checksum process of the code image, may be performed as a part of the authentication.”; [0044] “In one embodiment, exemplary power management code 601 is an ACPI compatible code, which may include, among others, a header 602, a public key 603, a signature block 604, a ACM (ACPI code module) body 606, and some other scratch spaces 605. ACPI code 601 may be stored in a ROM, such as ROM 107 of data processing system 100 shown in FIG. 1. Alternatively, ACPI code 601 may be stored in a nonvolatile RAM, such as nonvolatile RAM 106.”)
Nalawadi is directed to loading and unloading power management code in a secure environment. Nalawadi describes verifying the integrity/authenticity of power management code, which is drawn to the Power Management Controller area, using a hash-based verification method. Both are directed to verifying integrity of firmware code to ensure that it is trusted for use in a secure environment (TEE or ME).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Pappachan to incorporate the teachings of Nalawadi to include calculate a hash value based upon contents of… a Power Management Controller (PMC) area of a flash memory used by a Manageability Engine (ME) coupled to a processor of the IHS. Such modification(s) would be motivated to allow power management features to be loaded and unloaded dynamically as a trusted module. (Nalawadi, [0003])
Regarding claim 17, Pappachan discloses A method, comprising:
receiving a hash value calculated by an Information Handling System (IHS) based upon contents of a Read-Only Memory (ROM) Boot Extension (RBE) area, a Bringup (BUP) area… of a flash memory used by a Manageability Engine (ME) coupled to the IHS; (Pappachan, [0028] “In some embodiments, the security engine 138 may be embodied as a manageability engine, an out-of-band processor, a Trusted Platform Module (TPM), or other security engine device or collection of devices.”; [0045] “The attestation information may be collected by a trusted system agent such as the security engine 138 that loads the firmware code into the I/O controllers 144 (e.g., the security engine 138 BUP and RBE firmware on Intel® platforms). In block 414, the computing device 100 verifies the attestation information for the firmware. The computing device 100 may verify, for example, the cryptographic hash of the firmware code and ensure that the code was signed by a trusted entity (e.g., a processor manufacturer such as Intel® or a manufacturer of the computing device 100), verify the security version number, or verify other information associated with the firmware code.”)
performing an integrity verification of the ME based, at least in part, upon a comparison between the hash value and a reference hash value; and (Pappachan, [0045] “The computing device 100 may verify, for example, the cryptographic hash of the firmware code and ensure that the code was signed by a trusted entity (e.g., a processor manufacturer such as Intel? or a manufacturer of the computing device 100), verify the security version number, or verify other information associated with the firmware code.”)
transmitting an indication of a result of the integrity verification to the IHS. (Pappachan, [0035] “For example, the software attestation information may include one or more secure enclave reports, which are each indicative of a cryptographic measurement of a trusted software component. The software attestation module 206 is further configured to verify the software attestation information. The software attestation module 206 may be configured to verify the software attestation information locally, or to submit the software attestation information to a remote verification service. In some embodiments, those functions may be performed by one or more sub-modules, such as a local verifier 208 and/or a remote verifier 210.”)
Pappachan fails to explicitly disclose a hash value calculated by an Information Handling System (IHS) based upon contents of… a Power Management Controller (PMC) area of a flash memory used by a Manageability Engine (ME) coupled to the IHS;
However, Nalawadi teaches a hash value calculated by an Information Handling System (IHS) based upon contents of… a Power Management Controller (PMC) area of a flash memory used by a Manageability Engine (ME) coupled to the IHS; (Nalawadi, [0040] “If it is determined that the power management code is needed, at block 502, processing logic performs an authentication on the power management code to determine whether the power management code is trusted. According to one embodiment, the power management code is needed when the corresponding application or driver is capable of handling the power management events, such as, for example, the suspend/resume or wake-on-ring events. In one embodiment, processing logic authenticates the power management code using a pair of private and public keys, similar to the private and public PGP (Pretty Good Privacy) key pair via a variety of encryption techniques, including the hash operations, such as SHA-1 (RFC 3174) or MD-5 (e.g., RFC 1321) hash function, or other encryption algorithms, such as, for example, the RSA encryption mechanisms available from RSA Security, Inc. Other processes, such as a checksum process of the code image, may be performed as a part of the authentication.”; [0044] “In one embodiment, exemplary power management code 601 is an ACPI compatible code, which may include, among others, a header 602, a public key 603, a signature block 604, a ACM (ACPI code module) body 606, and some other scratch spaces 605. ACPI code 601 may be stored in a ROM, such as ROM 107 of data processing system 100 shown in FIG. 1. Alternatively, ACPI code 601 may be stored in a nonvolatile RAM, such as nonvolatile RAM 106.”)
performing an integrity verification of the ME based, at least in part, upon a comparison between the hash value and a reference hash value; and (Nalawadi, [0049] “If the public key hash stored in the hardware matches the computed hash of the public key in the module, at block 703, processing logic performs another hash operation via a hash function (e.g., SHA-1 or MD-5 hash function) on at least a portion of the power management code, such as header 602 of ACPI code 601 shown in FIG. 6, to generate a first module hash result (e.g., hash result 609). At block 704, processing logic decrypts a second portion of the power management code (e.g., signature block 604 of ACPI code 601 shown in FIG. 6) to recover a second module hash result. Processing logic then compares the first and second module hash results to determine whether they are matched. If the first and second module hash results are matched, at block 705, processing logic indicates that the respective power management code has been successfully authenticated.”)
Nalawadi is directed to loading and unloading power management code in a secure environment. Nalawadi describes verifying the integrity/authenticity of power management code, which is drawn to the Power Management Controller area, using a hash-based verification method. Both