US20230004648A1 - Firmware Integrity Check Using Silver Measurements - Google Patents
Firmware Integrity Check Using Silver Measurements Download PDFInfo
- Publication number
- US20230004648A1 US20230004648A1 US17/941,945 US202217941945A US2023004648A1 US 20230004648 A1 US20230004648 A1 US 20230004648A1 US 202217941945 A US202217941945 A US 202217941945A US 2023004648 A1 US2023004648 A1 US 2023004648A1
- Authority
- US
- United States
- Prior art keywords
- firmware
- measurement
- measurements
- electronic devices
- processor
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000005259 measurement Methods 0.000 title claims abstract description 154
- BQCADISMDOOEFD-UHFFFAOYSA-N Silver Chemical compound [Ag] BQCADISMDOOEFD-UHFFFAOYSA-N 0.000 title claims description 48
- 229910052709 silver Inorganic materials 0.000 title claims description 48
- 239000004332 silver Substances 0.000 title claims description 48
- 238000000034 method Methods 0.000 claims description 51
- 230000015654 memory Effects 0.000 claims description 40
- 239000003795 chemical substances by application Substances 0.000 claims description 17
- 230000009471 action Effects 0.000 claims description 6
- 230000001052 transient effect Effects 0.000 claims description 5
- 230000002085 persistent effect Effects 0.000 claims 2
- 230000008569 process Effects 0.000 description 29
- 230000002688 persistence Effects 0.000 description 11
- 230000006870 function Effects 0.000 description 9
- 238000004891 communication Methods 0.000 description 8
- 230000008859 change Effects 0.000 description 7
- 230000001010 compromised effect Effects 0.000 description 7
- 230000008901 benefit Effects 0.000 description 4
- QZXCCPZJCKEPSA-UHFFFAOYSA-N chlorfenac Chemical compound OC(=O)CC1=C(Cl)C=CC(Cl)=C1Cl QZXCCPZJCKEPSA-UHFFFAOYSA-N 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 239000000470 constituent Substances 0.000 description 2
- 238000013479 data entry Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000003752 polymerase chain reaction Methods 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- KJLPSBMDOIVXSN-UHFFFAOYSA-N 4-[4-[2-[4-(3,4-dicarboxyphenoxy)phenyl]propan-2-yl]phenoxy]phthalic acid Chemical compound C=1C=C(OC=2C=C(C(C(O)=O)=CC=2)C(O)=O)C=CC=1C(C)(C)C(C=C1)=CC=C1OC1=CC=C(C(O)=O)C(C(O)=O)=C1 KJLPSBMDOIVXSN-UHFFFAOYSA-N 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 235000021168 barbecue Nutrition 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000001902 propagating effect Effects 0.000 description 1
- 238000005067 remediation Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/577—Assessing vulnerabilities and evaluating computer system security
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
- G06F21/73—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information by creating or determining hardware identification, e.g. serial numbers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
- G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/12—Detection or prevention of fraud
Definitions
- the present disclosure relates to the protection of electronic devices from firmware attacks, and in particular relates to automatically deriving benchmark measurements with which to compare firmware measurements.
- BIOS Basic Input/Output System
- PC Personal Computer
- firmware measurements of the firmware are made regularly and compared with prior firmware measurements and/or silver measurements.
- Silver measurements which are reputation based measurements, are derived from a set of identical firmware measurements obtained from multiple devices having the same make, model and firmware version number.
- the comparison of firmware measurements enables additional reporting to users and IT administrators, to alert them about firmware changes.
- the firmware integrity status may be reported, for example, on a data and device security console for a group of managed endpoints. Real-time alerts can be sent to the IT administrators and end users when firmware updates are detected on their endpoints. Alerts about firmware changes, which may be potential attacks on the firmware, can be given automatically.
- An advantage of the invention is that the integrity of the firmware of a device can be checked without having to obtain a golden measurement from the manufacturer, or without manually or otherwise making a golden measurement.
- the applications that perform the firmware checks do not need to be manually or automatically updated with golden measurements. Instead, the invention detects changes across multiple devices and automatically determines whether the changes are genuine or suspect.
- Another advantage is that firmware roll-backs can be detected and reported.
- the embodiments disclosed herein each provide one or more of the above advantages.
- a method for protecting electronic devices comprising: receiving, by a server from each of a first threshold number of electronic devices, an identically performed firmware measurement, wherein said devices have an identical make, an identical model and a firmware with an identical version number; determining, by the server, that at least a second threshold number of the received firmware measurements are identical; defining, by the server, one of said identical firmware measurements to be a silver measurement; receiving, by a processor, from a further electronic device having the identical make, identical model and firmware with the identical version number, a further identically performed firmware measurement; and comparing the further firmware measurement with the silver measurement.
- a system for protecting electronic devices comprising a server; a processor in the server; and a non-transient computer readable memory in the server that stores instructions, which, when executed by the processor, cause the server to: receive from each of a first threshold number of electronic devices, an identically performed firmware measurement, wherein said devices have an identical make, an identical model and a firmware with an identical version number; determine that at least a second threshold number of the received firmware measurements are identical; define one of said identical firmware measurements to be a silver measurement; receive, from a further electronic device having the identical make, identical model and identical firmware version, a further identically performed firmware measurement; and compare the further firmware measurement with the silver measurement.
- Non-transient computer readable medium that stores instructions, which, when executed by a processor, cause the processor to: receive from each of a first threshold number of electronic devices, an identically performed firmware measurement, wherein said devices have an identical make, an identical model and a firmware with an identical version number; determine that at least a second threshold number of the received firmware measurements are identical; define one of said identical firmware measurements to be a silver measurement; receive, from a further electronic device having the identical make, identical model and identical firmware version, a further identically performed firmware measurement; and compare the further firmware measurement with the silver measurement.
- FIG. 1 is a schematic diagram of an overview of the process for checking firmware, according to an embodiment of the present invention.
- FIG. 2 is a schematic diagram of a system for firmware integrity checking, according to an embodiment of the present invention.
- FIG. 3 is a flowchart of a process for providing a device's firmware data to a server, carried out by a firmware integrity check application installed in the device, according to an embodiment of the present invention.
- FIG. 4 is a flowchart of a process for checking the integrity of the firmware of a device, carried out by a backend server of the system according to an embodiment of the present invention.
- FIG. 5 is a flowchart of a process for automatically deriving silver measurements, carried out by the server of the system according to an embodiment of the present invention.
- Non-limiting examples of a device include a laptop, cell phone, personal digital assistant, smart phone, memory stick, personal media device, gaming device, personal computer, tablet computer, electronic book, camera with a network interface, and netbook.
- Most devices protected by the invention will be mobile devices, but static devices, such as desktop computers, projectors, televisions, photocopiers and household appliances may also be protected.
- Many other kinds of electronic devices may be included, such as hi-fi equipment, cameras, bicycles, cars, barbecues and toys, if they include non-volatile memory and a BIOS or equivalent device firmware.
- Devices are configured to communicate with a remote server, and they may initiate the communications and/or the communications may be initiated by the server. Communications may be via Wi-Fi, SMS, cellular data or satellite, for example, or may use another communications protocol. While the invention is often explained in relation to laptops, it is to be understood that it applies equally to other electronic and computing devices.
- ACPI Advanced Configuration and Power Interface
- ACPI specifies how a computer's basic input/output system, operating system, and peripheral devices communicate with each other regarding power usage.
- ACPI defines tables that provide the interface between an ACPI-compliant operating system and system firmware. The tables allow for the description of system hardware in a platform-independent manner, and are presented as either fixed-formatted data structures or in AML (ACPI Machine Language).
- API Application Program Interface
- BIOS Basic Input/Output System. This performs a power-on self-test of the hardware during the booting process of an electronic device, initializes the hardware, and provides runtime services for operating systems and programs. BIOS is an example of device firmware.
- CHIPSEC A framework for analyzing the security of PC platforms including hardware, system firmware (BIOS/UEFI), and platform components. It includes a security test suite, tools for accessing various low level interfaces, and forensic capabilities.
- Computer readable medium A computer memory or memories of one or more different types, each capable of storing computer readable instructions and/or computer readable data.
- FIC Firmware Integrity Check
- Firmware Programming instructions that provide control, monitoring and data manipulation for electronic devices.
- Firmware is typically stored in non-volatile memory components such as ROM (Read-only Memory), EPROM (Electronically programmable ROM), or flash memory in the device.
- Firmware such as the ROM BIOS of a personal computer may contain only elementary basic functions of the computer and may provide services to higher-level software. Changing the firmware of a device may occasionally be done during its lifetime, for example for updating the firmware, fixing bugs or adding features.
- Firmware may employ settings that are stored within the firmware or elsewhere in the non-volatile memory in the device.
- firmware means device firmware such as BIOS, UEFI or similar, unless specifically stated otherwise.
- Golden Measurement In assessing the firmware measurements of devices, a measurement assessment authority (MAA) references a set of characteristics. These characteristics come in two varieties: (1) endpoint attributes and measurements of BIOS code provided and vouched for, using certificates, by the Original Equipment Manufacturer (OEM), Value Added Reseller (VAR), or an Independent Software Vendor (ISV); and (2) measurements of configuration settings either gathered by the user/administrator of the endpoint during initial provisioning of the endpoint or by the MAA. The assemblage of ideal measurement characteristics is referred to as a golden measurement.
- OEM Original Equipment Manufacturer
- VAR Value Added Reseller
- ISV Independent Software Vendor
- Hash A hash function is any function that can be used to map data of arbitrary size to data of fixed size.
- the values returned by a hash function are called hash values, hash codes, digests, hash sums, or simply hashes.
- NVRAM Non-Volatile Random Access Memory
- PCR Platform Configuration Register, a storage register that is used to hold a value that summarizes all the measurement results that were presented to it and the order in which those values were presented to it.
- the PCR is hosted by the TPM (Trusted Platform Module).
- TPM Trusted Platform Module
- This term may be used to refer to a single computer processor or multiple computer processors.
- RAM Random Access Memory
- Roll-Back The change of software or firmware present on a device from its present version to an older version.
- Rootkit A collection of computer software programs, typically malicious, designed to enable unauthorized access to a computer or areas of its software that would not otherwise be allowed, and/or to mask its existence or the existence of other malicious software.
- Silver measurement A reference measurement of firmware that is derived from multiple identical measurements of different copies of the same piece of firmware present on different devices of the same make and model.
- a silver measurement covers firmware code (i.e. computer readable instructions) but excludes firmware settings, since the latter can be intentionally changed.
- SMM System Management Mode, an operating mode of a device in which all normal execution, including the operating system, is suspended and separate, special software, which is usually part of the firmware or a hardware-assisted debugger, is executed with high privileges.
- TCG Trusted Computing Group, a group formed to implement trusted computing concepts across personal computers.
- TCPA Trusted Computing Platform Alliance, the former name of the Trusted Computing Group
- TPM Trusted Platform Module, a dedicated microcontroller designed to secure hardware by integrating cryptographic keys into devices.
- the TPM hosts the above-mentioned PCRs.
- the TPM specification was written by the TCG.
- UEFI Unified Extensible Firmware Interface, a specification that defines a software interface between an operating system and platform firmware.
- the UEFI is stored as firmware in non-volatile memory.
- step 2 hashes of newly updated firmware are obtained from multiple devices.
- step 4 the hashes are analyzed in order to derive a silver measurement of the newly updated firmware.
- the particular value of the hash is deemed to be a silver measurement of the particular make, model and firmware version.
- step 6 the firmware of further devices is measured to provide hashes, each of which is compared to the silver measurement corresponding to the device's particular make, model and firmware version. If the comparison results in a match, then those devices with a match can be considered to have firmware that is not compromised. The devices that do not have a match can be considered to have their firmware compromised.
- FIG. 2 A symbolic block diagram of an exemplary embodiment of the system 10 for checking the firmware integrity of a device 20 is shown in FIG. 2 .
- the device 20 typically includes a display 22 , one or more processors 24 and non-volatile memory 26 , which may be split into two or more constituent memories.
- the device 20 also includes further, volatile memory 28 , such as RAM.
- the device 20 may also include a hard disk drive (HDD) 29 , solid state drive or other long-term storage.
- HDD hard disk drive
- firmware 30 Present in the non-volatile memory 26 (e.g. NVRAM) of the device 20 is firmware 30 , which may be any type of device firmware such as BIOS, UEFI or firmware that performs comparable functions to BIOS or UEFI.
- the firmware 30 may be divided into multiple volumes, and includes both code and data. Each volume may store data, code, or both data and code.
- the non-volatile memory 26 also includes an identification 36 of the device 20 , an information module 32 and a persistence module 34 .
- the persistence module 34 is normally located inside the firmware 30 .
- the non-volatile memory 26 may store several firmware images of different kinds as well as other non-firmware data.
- the information in module 32 saved in non-volatile memory 26 includes, for example, non-volatile BIOS settings, such as overclock settings, persistence activation state, enable/disable Secure Boot, and many other static BIOS settings.
- the information module 32 may not necessarily be a single or specifically defined module, but may include a collection of unrelated registers or other data storage areas, for example, which are collectively referred to herein as an information module for convenience.
- Dynamic information such as whether USB devices are attached to the device 20 , is kept by the BIOS in memory 28 .
- the log (TCPA table), along with other ACPI tables, are produced dynamically by firmware 30 and also stored in memory 28 .
- the FIC application 40 is maintained in the volatile memory 28 by the OS agent 41 .
- the OS agent 41 does not itself include any applications, such as the FIC application, but exists to maintain a communication link to the server 60 .
- the server 60 transfers the FIC application 40 and other applications as necessary to the device through the OS agent's communication channel with the server.
- the persistence module 34 ensures that the OS agent 41 is present in an uncompromised state in the volatile memory 28 of the device 20 , or elsewhere in the device. If the OS agent 41 is not present in the device 20 or is found to be compromised upon boot, the persistence module 34 , which includes a mini-agent embedded in it, restores the OS agent directly from flash memory or any other storage within the device, without any internet connection to the device. It is also possible, in other embodiments, for the persistence module to reload the OS agent 41 across the internet, if the persistence module has internet connectivity.
- the FIC application 40 is responsible for calculating a measurement of the firmware 30 , which may be a hash 42 .
- the persistence module 34 is measured along with the rest of the firmware 30 because the persistence module is part of the firmware.
- the FIC application 40 stores the hash 42 as a hash 42 A in the HDD 29 or equivalent storage using the OS's cryptographic API.
- the FIC application 40 can make use of functions of the operating system 44 to read the contents of the non-volatile memory 26 , to change settings in it and to write data to it. Versions of the firmware 30 can be read using OS interfaces such as WMI, or they can be discovered in a more direct way using the FIC application 40 , and then stored in the information module 32 .
- Firmware version numbers may include numerical digits, letters and/or other characters or symbols.
- the FIC application 40 can periodically measure the firmware 30 and compare the measurements with previously stored results that have been stored in the HDD 29 .
- the volatile memory 28 may contain ACPI tables that contain a measurement log, which can be verified with TPM PCR registers.
- UEFI firmware may create the ACPI tables. The log can be checked with prior logs and/or silver measurements.
- the UEFI firmware volumes can be copied from non-volatile memory 26 by the FIC application 40 , parsed, and measured as a whole as opposed to the TPM-based method.
- Firmware volumes are located in non-volatile memory 26 and mapped at a specific location in CPU (central processing unit) address space, so the FIC application 40 can, via an OS device driver, map and copy firmware volumes from non-volatile memory address space into the main memory 28 .
- an immutable BIOS boot block stores measurements in PCRs on the TPM.
- a PCR register in the TPM is combined with a nonce and signed by a TPM-resident key to create a report on the BIOS code present at boot time.
- the measurement as a whole can either be done in conjunction with the TPM-based method or on its own if there is no TPM, or if the BIOS does not generate the TCPA table.
- This may require a kernel driver to directly access the memory 26 and ACPI tables in the information module 32 .
- ACPI tables can be accessed via an OS API, however, use of a kernel driver is not obligatory. In LinuxTM systems the ACPI tables are mapped in a virtual file system.
- a kernel driver would be necessary in other situations, such as reading BIOS from flash, reading SPI controller registers, etc. Other, known types of measurement may also be used.
- the FIC application 40 can periodically read the non-volatile memory 26 , which includes e.g. flash regions and controller lock registers, in a way similar to that performed by the CHIPSEC utility, and report/alert if any region of the flash is unlocked. This requires a kernel driver to access the physical hardware registers.
- the device 20 is connected via communications link 52 and the internet 38 or other network to a server 60 , which is connected to the internet via link 62 .
- Further devices 20 A, 20 B which are similar in function to device 20 , for which the firmware is to be monitored, are connected to the server 60 via the internet 38 and links 58 , 59 respectively.
- the server includes one or more processors 64 , user interface 66 and one or more memories 68 .
- the memory 68 stores one or more programs 70 for interacting with the devices 20 , 20 A, 20 B and storing information related to their firmware in database 72 .
- the database 72 includes data entries 74 that relate identifications of specific devices 20 , 20 A, 20 B to their firmware, for example using firmware hashes.
- data entry 74 includes a copy 36 A of the device identification 36 stored in relation to a copy 42 B of the hash 42 of the firmware 30 .
- the database 72 also includes entries 76 that relate device makes, models and their firmware versions (M-M-F) to silver measurements (S #) of the corresponding firmware.
- a database 72 includes the type of the flash controller and flash part of the device so that the FIC application 40 knows how to access the flash lock registers on different platforms. Over time, additional functionality can be added to the database.
- a web front-end 80 which is a further computing device, is connected to the server 60 via communications link 82 and the internet 38 .
- Alerts indicating a change in the firmware 30 of device 20 are presented as popup messages 86 on the display 84 of the web front-end 80 , which can also trigger emails or other messages to IT administrators.
- the system 10 can also alert the end user directly with a popup message 90 or lock the display 22 of the device 20 , depending on the particular policy selected.
- step 100 the FIC application 40 is initialized, which is achieved by loading, installing and running it in the device 20 , under control of the persistence module 34 .
- the FIC application 40 receives a policy from the backend, i.e. the server 60 .
- the policy includes instructions for the FIC application 40 as to which parts of the firmware 30 to measure, how to measure them and how often to measure them, etc.
- the server 60 sends the policy and commands to the device 20 , and the device sends data to the server.
- the server informs the FIC application 40 on the device 20 whether its measurements are OK or not. However, this status information may be intentionally withheld from a compromised device if it is desired that the server continue to monitor the compromised device, while keeping a user of the device unaware that the status has been determined.
- the application 40 gathers, from the device, the device's BIOS version, the date and time of its build, and its size. It also calculates a hash 42 of the firmware 30 , or a different hash for each volume of the firmware. Optionally, it gathers the I/O ports to enable/disable SMM and other parameters including published ACPI, SMBIOS, and/or other standard interfaces.
- step 115 If, in step 115 , there is no information previously saved on the device by the FIC application (i.e. firmware version, firmware date, firmware time and/or firmware hash) with the policy relating to the specific device, then the application 40 proceeds to step 118 .
- step 118 the gathered information and hashes from step 110 are securely saved locally and sent to the server 60 in step 120 .
- the FIC application 40 runs for the first time it takes the baseline measurement, saves it securely on the device 20 , and sends to the server 60 .
- the FIC application next runs, it can then compare a new measurement with the saved baseline measurement, and, if different, send the new measurement to the server if instructed to do so by to the policy.
- the device may receive an acknowledgment from the server if the measurement is acceptable, for example if it corresponds to a silver measurement.
- the optional message back from the server may be a command to take a security action, if the measurement does not equal a corresponding silver measurement. The process then ends in step 122 .
- step 115 if the specific device information (i.e. firmware version, firmware date, firmware time and/or firmware hash) has been previously gathered from the device 20 under control of the policy, which informs the FIC application 40 where to get the device specific information, then the process moves to step 125 .
- the FIC application 40 determines whether the BIOS has been updated. This is done by comparing the current data obtained in step 110 with the previous data stored earlier in step 118 . For example, this is achieved by comparing the current BIOS version number with the prior BIOS version number; the current BIOS build date with the prior BIOS build date; and/or the current BIOS size with the prior BIOS size.
- step 140 the FIC application 40 generates an alert and the new information is sent to the server in step 145 , after which the process ends in step 150 .
- the device may receive an acknowledgment from the server or a security instruction before the process ends.
- the alert is displayed as a popup or message 90 on the display 22 of the device 20 , e.g. “Your device firmware was upgraded from version x to y; if you did not authorize the upgrade, shutdown the computer and contact your administrator. Unauthorized firmware change may be a sign of a hacker attack.”
- step 125 the FIC application 40 determines that the BIOS has not been updated, then the process moves to step 130 , in which the FIC application compares the current hashes with the prior hashes. If, in step 135 , the BIOS has been changed, then, in step 140 , the FIC application generates an alert and the new information is sent to the server in step 145 , after which the process ends in step 150 . In conjunction with the alert, the process may lock the device or permit restricted use only of it until the change in the BIOS has been verified to be legitimate. As above, the alert is displayed as a popup or message 90 on the display 22 of the device 20 .
- step 135 If, in step 135 , the BIOS has not been changed, which is determined by the current hash being equal to the prior hash, then the process permits normal or continued and unhindered operation of the device in step 148 , and then ends in step 150 .
- step 145 may be performed after step 148 even if there are no changes to the BIOS, i.e. the data would be sent again even if it has not changed.
- the process can be repeated on every boot of the device or periodically, randomly or from time to time, starting from step 105 in which the information is received from the server.
- the FIC feature for the device 20 is enabled, for example by an administrator setting a flag in server 60 that indicates that the feature should be present on the device.
- the server reads the flag and instructs the OS agent to initialize the FIC application 40 .
- step 205 the server 60 receives the BIOS version, build date and time, BIOS size and hashes of the firmware volumes from the FIC application 40 for the first time. This is achieved as a result of the FIC application 40 performing step 120 of FIG. 3 .
- the server 60 stores the received information (i.e. BIOS version, build date and time, BIOS size and hashes of the firmware volumes) in the database 72 , in a record 74 that links it to an identification 36 of the device.
- the received information i.e. BIOS version, build date and time, BIOS size and hashes of the firmware volumes
- step 220 the server 60 receives updated information including the current firmware measurement for the device, as a result of the FIC application 40 performing step 145 of FIG. 3 .
- step 225 the server 60 generates an acknowledgment that indicates that information has been received.
- step 230 the server determines whether the BIOS firmware has been updated to a later version, for example by comparing the currently received firmware version number with a previously received firmware version number from the same device. If it has, then, in step 235 , the server determines whether a silver measurement is available. If a silver measurement is available, then, in step 245 , the server performs a silver measurement check. This is done by comparing the current firmware measurement with the silver measurement and determining whether there is a difference between the two.
- step 250 If, in step 250 , the result of the check is OK, i.e. there is no difference between the current firmware measurement and the silver measurement, then the new information and optionally the OK status are stored in record 74 in the database 72 , in step 240 .
- the status indicates that at the date and time of the check, the firmware 30 is OK.
- a message may be sent back to the device to inform it that the update in its firmware is legitimate and that it may continue with its normal and unhindered operation. If the result of the silver measurement check is not OK in step 250 , a security violation alert is generated in step 270 .
- step 235 if a silver measurement is not yet available, then the new information is stored in step 240 in the database 72 as record 74 , or as an addition to record 74 .
- the server determines, in step 260 whether the BIOS has been rolled back to a prior version.
- the server identifies a roll-back of the BIOS by determining that the currently received firmware version number is earlier than the previously stored firmware version number from the same device. If the firmware has been rolled back, then, in step 270 the server generates a security violation alert. If the BIOS has not been rolled back to a prior version, then the server determines, in step 265 , whether the hashes of the firmware volumes have been changed. If they have been changed, then, in step 270 , the server generates a security violation alert.
- step 145 the server determines whether a later BIOS version is available in step 290 . If there is not a new BIOS available, the process ends at step 280 . If a new BIOS is available, i.e. the current firmware is out of date, then a notification is sent to the IT administrator and/or the user of the device 20 in step 295 , after which the process ends in step 280 .
- the server can also check whether it is aware of a newer version of the firmware 30 , and, if so, sends an alert to the user that a BIOS update is available, and to the IT administrator that the device 20 still uses an older BIOS.
- alerts may also be communicated from the server 60 to the device 20 for display on the display of the device, or to trigger a security response in the device such as a lock-down.
- the server may send a message to the device to instruct it to freeze, to delete data therefrom, to transmit data to the server, to reduce its functionality, or to transmit its location such that it can be tracked. Other security measures are also possible.
- the process ends in step 280 . The process is then repeated from step 220 as and when it receives new data from the device.
- the OS agent 41 of the device 20 will either disable the FIC application 40 if it is present in the device or refrain from enabling it if it is absent from the device.
- the measurements may include a permissible range of allowed data and/or settings if the measurement checks can allow for it.
- step 300 the FIC feature is enabled on multiple devices having the same make, model and firmware version.
- step 305 the server receives the BIOS information for the multiple devices, including the build date, time and size, and hashes of the firmware volumes. The hashes must all be calculated in the same way in order to provide consistent results.
- step 310 the server determines whether the number of devices for which the BIOS information has been received is above a first threshold number. If the number of devices does not meet the first threshold, the server proceeds to wait, and then later receives BIOS information from more devices, by returning to step 305 .
- the first threshold number of devices may be equal to 10.
- the first threshold may be different, configurable and/or adjustable, either manually or automatically, and the actual value may be based on statistical data.
- the server determines, in step 315 , whether the number of devices that have identical information is above another, second threshold (which may either be the same number as the first threshold or a lower number).
- This second threshold may be 9, for example, which, if the first threshold is 10, would indicate with a relatively high probability that these 9 devices are uncompromised.
- the 1 device out of the 10, which has different information, may likewise be considered to be compromised with a relatively high probability. If the number of devices with identical measurements is not equal to or above the second threshold, then the process reverts to step 305 to receive BIOS information from more devices.
- step 315 the number of devices that report identical BIOS information is equal to or above the second threshold
- step 320 the hash of the reported identical BIOS information is set as the silver measurement for the specific make, model and firmware version of the device.
- step 325 the silver measurement (S #) is stored in the database 72 in a record 76 that links to the specific make, model and firmware version (M-M-F) of the device.
- S # the silver measurement
- M-M-F firmware version
- the server can look at new firmware, analyze it, and automatically determine whether it is genuine or suspect without having to compare it with a pre-existing benchmark. Once the new firmware is determined to be genuine, it is defined as a silver measurement. The silver measurement can then be used as a benchmark for checking the firmware of further devices.
- step 110 may simply be a repeat of existing information, but received at a later time or date, which would indicate that the firmware 30 has not changed.
- the device itself may not detect the change in the firmware, but leave the detection of change to the server 60 to perform.
- Thresholds in the determination of the silver measurement may be different depending on the identity of the devices that initially contact the server with an updated firmware version. Lower thresholds may be used if the measurements are coming from devices that are, or become, known to be less susceptible to firmware attacks than other devices. The thresholds may be different depending on make, model, number of identified firmware attacks, location of the devices, owner of the devices, configuration of the devices, etc. The thresholds may also vary with time.
- the silver measurement may include a firmware version number and firmware date and time.
- An intermediate embodiment may further include one or more of the actual firmware volume measurements.
- An advanced embodiment may ultimately completely satisfy the NIST guidelines referred to above. Another possible variation is to include measurements of the firmware settings and to discover which combinations are disallowed by the customers.
- Functions described as being performed by one server may be divided between separate servers, and functions described as being performed on multiple servers may be combined on the same server. Intermediate servers may also be employed in the system.
- Steps in the flowcharts may be performed in a different order to that illustrated, or they may be combined where shown separately. Steps may be omitted and others added, and steps from different flowcharts may be interchanged, all without departing from the scope of the invention. Components shown herein may be divided into constituent components or be combined with each other.
- the persistence module is a form of firmware, but not considered to be device firmware.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Stored Programmes (AREA)
Abstract
Description
- The present disclosure relates to the protection of electronic devices from firmware attacks, and in particular relates to automatically deriving benchmark measurements with which to compare firmware measurements.
- There are increasing attacks on the BIOS (Basic Input/Output System) in electronic computing devices, such as the implanting of rootkits in the BIOS. If the BIOS on a PC (Personal Computer) endpoint is compromised with a rootkit, there is no convenient or automated way at any given point of time to check its integrity and perform remediation. Nevertheless, one way to check integrity of the firmware is to compare a measurement of it with a golden measurement obtained from the manufacturer, but this is not always possible or desirable. Firmware checking applications that use golden measurements must be updated with new golden measurements at the same time that the firmware is updated, otherwise legitimate firmware changes will be unnecessarily and widely reported as suspect. Golden measurements must be made in exactly the same way as the firmware measurements that are compared with the golden measurements. The National Institute of Standards and Technology (NIST) has published a conceptual draft relating to BIOS integrity, entitled “BIOS Integrity Measurement Guidelines” (Publication number 800-155). However, the extent of its implementation is unknown as of the time of writing.
- In order to recognize attacks on a device's firmware, measurements of the firmware are made regularly and compared with prior firmware measurements and/or silver measurements. Silver measurements, which are reputation based measurements, are derived from a set of identical firmware measurements obtained from multiple devices having the same make, model and firmware version number. The comparison of firmware measurements enables additional reporting to users and IT administrators, to alert them about firmware changes. The firmware integrity status may be reported, for example, on a data and device security console for a group of managed endpoints. Real-time alerts can be sent to the IT administrators and end users when firmware updates are detected on their endpoints. Alerts about firmware changes, which may be potential attacks on the firmware, can be given automatically.
- An advantage of the invention is that the integrity of the firmware of a device can be checked without having to obtain a golden measurement from the manufacturer, or without manually or otherwise making a golden measurement. The applications that perform the firmware checks do not need to be manually or automatically updated with golden measurements. Instead, the invention detects changes across multiple devices and automatically determines whether the changes are genuine or suspect. Another advantage is that firmware roll-backs can be detected and reported. The embodiments disclosed herein each provide one or more of the above advantages.
- Disclosed herein is a method for protecting electronic devices comprising: receiving, by a server from each of a first threshold number of electronic devices, an identically performed firmware measurement, wherein said devices have an identical make, an identical model and a firmware with an identical version number; determining, by the server, that at least a second threshold number of the received firmware measurements are identical; defining, by the server, one of said identical firmware measurements to be a silver measurement; receiving, by a processor, from a further electronic device having the identical make, identical model and firmware with the identical version number, a further identically performed firmware measurement; and comparing the further firmware measurement with the silver measurement.
- Also disclosed herein is a system for protecting electronic devices comprising a server; a processor in the server; and a non-transient computer readable memory in the server that stores instructions, which, when executed by the processor, cause the server to: receive from each of a first threshold number of electronic devices, an identically performed firmware measurement, wherein said devices have an identical make, an identical model and a firmware with an identical version number; determine that at least a second threshold number of the received firmware measurements are identical; define one of said identical firmware measurements to be a silver measurement; receive, from a further electronic device having the identical make, identical model and identical firmware version, a further identically performed firmware measurement; and compare the further firmware measurement with the silver measurement.
- Still further disclosed herein is a non-transient computer readable medium that stores instructions, which, when executed by a processor, cause the processor to: receive from each of a first threshold number of electronic devices, an identically performed firmware measurement, wherein said devices have an identical make, an identical model and a firmware with an identical version number; determine that at least a second threshold number of the received firmware measurements are identical; define one of said identical firmware measurements to be a silver measurement; receive, from a further electronic device having the identical make, identical model and identical firmware version, a further identically performed firmware measurement; and compare the further firmware measurement with the silver measurement.
- This summary is not an extensive overview intended to delineate the scope of the subject matter that is described and claimed herein. The summary presents aspects of the subject matter in a simplified form to provide a basic understanding thereof, as a prelude to the detailed description that is presented below. Neither this summary, the drawings nor the following detailed description purport to define or limit the invention; the invention is defined only by the claims.
-
FIG. 1 is a schematic diagram of an overview of the process for checking firmware, according to an embodiment of the present invention. -
FIG. 2 is a schematic diagram of a system for firmware integrity checking, according to an embodiment of the present invention. -
FIG. 3 is a flowchart of a process for providing a device's firmware data to a server, carried out by a firmware integrity check application installed in the device, according to an embodiment of the present invention. -
FIG. 4 is a flowchart of a process for checking the integrity of the firmware of a device, carried out by a backend server of the system according to an embodiment of the present invention. -
FIG. 5 is a flowchart of a process for automatically deriving silver measurements, carried out by the server of the system according to an embodiment of the present invention. - Device: This is any electronic device or any computing device to be protected, which includes non-volatile memory and a BIOS or its equivalent device firmware stored in the non-volatile memory. Non-limiting examples of a device include a laptop, cell phone, personal digital assistant, smart phone, memory stick, personal media device, gaming device, personal computer, tablet computer, electronic book, camera with a network interface, and netbook. Most devices protected by the invention will be mobile devices, but static devices, such as desktop computers, projectors, televisions, photocopiers and household appliances may also be protected. Many other kinds of electronic devices may be included, such as hi-fi equipment, cameras, bicycles, cars, barbecues and toys, if they include non-volatile memory and a BIOS or equivalent device firmware. Devices are configured to communicate with a remote server, and they may initiate the communications and/or the communications may be initiated by the server. Communications may be via Wi-Fi, SMS, cellular data or satellite, for example, or may use another communications protocol. While the invention is often explained in relation to laptops, it is to be understood that it applies equally to other electronic and computing devices.
- ACPI: Advanced Configuration and Power Interface, an industry specification for the efficient handling of power consumption in desktop and mobile computers. ACPI specifies how a computer's basic input/output system, operating system, and peripheral devices communicate with each other regarding power usage. ACPI defines tables that provide the interface between an ACPI-compliant operating system and system firmware. The tables allow for the description of system hardware in a platform-independent manner, and are presented as either fixed-formatted data structures or in AML (ACPI Machine Language).
- API: Application Program Interface
- BIOS: Basic Input/Output System. This performs a power-on self-test of the hardware during the booting process of an electronic device, initializes the hardware, and provides runtime services for operating systems and programs. BIOS is an example of device firmware.
- CHIPSEC: A framework for analyzing the security of PC platforms including hardware, system firmware (BIOS/UEFI), and platform components. It includes a security test suite, tools for accessing various low level interfaces, and forensic capabilities.
- Computer readable medium: A computer memory or memories of one or more different types, each capable of storing computer readable instructions and/or computer readable data.
- FIC: Firmware Integrity Check, a process of the present invention in which the current firmware measurement of a device is checked against a prior firmware measurement and/or a silver measurement.
- Firmware: Programming instructions that provide control, monitoring and data manipulation for electronic devices. Firmware is typically stored in non-volatile memory components such as ROM (Read-only Memory), EPROM (Electronically programmable ROM), or flash memory in the device. Firmware such as the ROM BIOS of a personal computer may contain only elementary basic functions of the computer and may provide services to higher-level software. Changing the firmware of a device may occasionally be done during its lifetime, for example for updating the firmware, fixing bugs or adding features. Firmware may employ settings that are stored within the firmware or elsewhere in the non-volatile memory in the device. When used herein, the term “firmware” means device firmware such as BIOS, UEFI or similar, unless specifically stated otherwise.
- Golden Measurement: In assessing the firmware measurements of devices, a measurement assessment authority (MAA) references a set of characteristics. These characteristics come in two varieties: (1) endpoint attributes and measurements of BIOS code provided and vouched for, using certificates, by the Original Equipment Manufacturer (OEM), Value Added Reseller (VAR), or an Independent Software Vendor (ISV); and (2) measurements of configuration settings either gathered by the user/administrator of the endpoint during initial provisioning of the endpoint or by the MAA. The assemblage of ideal measurement characteristics is referred to as a golden measurement.
- Hash: A hash function is any function that can be used to map data of arbitrary size to data of fixed size. The values returned by a hash function are called hash values, hash codes, digests, hash sums, or simply hashes.
- NIST: National Institute of Standards and Technology
- NVRAM: Non-Volatile Random Access Memory
- OEM: Original Equipment Manufacturer
- OS: Operating System
- PCR: Platform Configuration Register, a storage register that is used to hold a value that summarizes all the measurement results that were presented to it and the order in which those values were presented to it. The PCR is hosted by the TPM (Trusted Platform Module). The PCR has two advantages: an indefinite number of results can be stored in a single register, and no measurement results need to be discarded to make room for new measurement results.
- Processor: This term may be used to refer to a single computer processor or multiple computer processors.
- RAM: Random Access Memory
- Roll-Back: The change of software or firmware present on a device from its present version to an older version.
- Rootkit: A collection of computer software programs, typically malicious, designed to enable unauthorized access to a computer or areas of its software that would not otherwise be allowed, and/or to mask its existence or the existence of other malicious software.
- Silver measurement: A reference measurement of firmware that is derived from multiple identical measurements of different copies of the same piece of firmware present on different devices of the same make and model. A silver measurement covers firmware code (i.e. computer readable instructions) but excludes firmware settings, since the latter can be intentionally changed.
- SMM: System Management Mode, an operating mode of a device in which all normal execution, including the operating system, is suspended and separate, special software, which is usually part of the firmware or a hardware-assisted debugger, is executed with high privileges.
- SPI: Serial Peripheral Interface
- TCG: Trusted Computing Group, a group formed to implement trusted computing concepts across personal computers.
- TCPA: Trusted Computing Platform Alliance, the former name of the Trusted Computing Group
- TPM: Trusted Platform Module, a dedicated microcontroller designed to secure hardware by integrating cryptographic keys into devices. The TPM hosts the above-mentioned PCRs. The TPM specification was written by the TCG.
- UEFI: Unified Extensible Firmware Interface, a specification that defines a software interface between an operating system and platform firmware. The UEFI is stored as firmware in non-volatile memory.
- WMI: Windows Management Instrumentation
- Referring to
FIG. 1 , a brief overview of the process for checking the integrity of firmware is shown. Instep 2, hashes of newly updated firmware are obtained from multiple devices. Instep 4, the hashes are analyzed in order to derive a silver measurement of the newly updated firmware. In particular, when multiple devices of the same make, model and firmware version have hashes that are the same, then the particular value of the hash is deemed to be a silver measurement of the particular make, model and firmware version. Instep 6, the firmware of further devices is measured to provide hashes, each of which is compared to the silver measurement corresponding to the device's particular make, model and firmware version. If the comparison results in a match, then those devices with a match can be considered to have firmware that is not compromised. The devices that do not have a match can be considered to have their firmware compromised. - A symbolic block diagram of an exemplary embodiment of the
system 10 for checking the firmware integrity of adevice 20 is shown inFIG. 2 . Thedevice 20 typically includes adisplay 22, one ormore processors 24 andnon-volatile memory 26, which may be split into two or more constituent memories. Thedevice 20 also includes further,volatile memory 28, such as RAM. Thedevice 20 may also include a hard disk drive (HDD) 29, solid state drive or other long-term storage. - Present in the non-volatile memory 26 (e.g. NVRAM) of the
device 20 isfirmware 30, which may be any type of device firmware such as BIOS, UEFI or firmware that performs comparable functions to BIOS or UEFI. Thefirmware 30 may be divided into multiple volumes, and includes both code and data. Each volume may store data, code, or both data and code. Thenon-volatile memory 26 also includes anidentification 36 of thedevice 20, aninformation module 32 and apersistence module 34. Thepersistence module 34 is normally located inside thefirmware 30. Thenon-volatile memory 26 may store several firmware images of different kinds as well as other non-firmware data. The information inmodule 32 saved innon-volatile memory 26 includes, for example, non-volatile BIOS settings, such as overclock settings, persistence activation state, enable/disable Secure Boot, and many other static BIOS settings. Theinformation module 32 may not necessarily be a single or specifically defined module, but may include a collection of unrelated registers or other data storage areas, for example, which are collectively referred to herein as an information module for convenience. Dynamic information such as whether USB devices are attached to thedevice 20, is kept by the BIOS inmemory 28. Also, the log (TCPA table), along with other ACPI tables, are produced dynamically byfirmware 30 and also stored inmemory 28. - The
FIC application 40 is maintained in thevolatile memory 28 by theOS agent 41. TheOS agent 41 does not itself include any applications, such as the FIC application, but exists to maintain a communication link to theserver 60. Theserver 60 transfers theFIC application 40 and other applications as necessary to the device through the OS agent's communication channel with the server. Thepersistence module 34 ensures that theOS agent 41 is present in an uncompromised state in thevolatile memory 28 of thedevice 20, or elsewhere in the device. If theOS agent 41 is not present in thedevice 20 or is found to be compromised upon boot, thepersistence module 34, which includes a mini-agent embedded in it, restores the OS agent directly from flash memory or any other storage within the device, without any internet connection to the device. It is also possible, in other embodiments, for the persistence module to reload theOS agent 41 across the internet, if the persistence module has internet connectivity. - The
FIC application 40 is responsible for calculating a measurement of thefirmware 30, which may be ahash 42. WhenFIC application 40 performs its measurements, thepersistence module 34 is measured along with the rest of thefirmware 30 because the persistence module is part of the firmware. TheFIC application 40 stores thehash 42 as ahash 42A in theHDD 29 or equivalent storage using the OS's cryptographic API. TheFIC application 40 can make use of functions of theoperating system 44 to read the contents of thenon-volatile memory 26, to change settings in it and to write data to it. Versions of thefirmware 30 can be read using OS interfaces such as WMI, or they can be discovered in a more direct way using theFIC application 40, and then stored in theinformation module 32. Firmware version numbers may include numerical digits, letters and/or other characters or symbols. - After the device has booted, the
FIC application 40 can periodically measure thefirmware 30 and compare the measurements with previously stored results that have been stored in theHDD 29. Thevolatile memory 28 may contain ACPI tables that contain a measurement log, which can be verified with TPM PCR registers. UEFI firmware may create the ACPI tables. The log can be checked with prior logs and/or silver measurements. The UEFI firmware volumes can be copied fromnon-volatile memory 26 by theFIC application 40, parsed, and measured as a whole as opposed to the TPM-based method. Firmware volumes are located innon-volatile memory 26 and mapped at a specific location in CPU (central processing unit) address space, so theFIC application 40 can, via an OS device driver, map and copy firmware volumes from non-volatile memory address space into themain memory 28. - In the TPM-based method, an immutable BIOS boot block stores measurements in PCRs on the TPM. A PCR register in the TPM is combined with a nonce and signed by a TPM-resident key to create a report on the BIOS code present at boot time. The measurement as a whole can either be done in conjunction with the TPM-based method or on its own if there is no TPM, or if the BIOS does not generate the TCPA table. This may require a kernel driver to directly access the
memory 26 and ACPI tables in theinformation module 32. As ACPI tables can be accessed via an OS API, however, use of a kernel driver is not obligatory. In Linux™ systems the ACPI tables are mapped in a virtual file system. A kernel driver would be necessary in other situations, such as reading BIOS from flash, reading SPI controller registers, etc. Other, known types of measurement may also be used. - As a separate check, the
FIC application 40 can periodically read thenon-volatile memory 26, which includes e.g. flash regions and controller lock registers, in a way similar to that performed by the CHIPSEC utility, and report/alert if any region of the flash is unlocked. This requires a kernel driver to access the physical hardware registers. - The
device 20 is connected via communications link 52 and theinternet 38 or other network to aserver 60, which is connected to the internet vialink 62.Further devices device 20, for which the firmware is to be monitored, are connected to theserver 60 via theinternet 38 andlinks more processors 64,user interface 66 and one ormore memories 68. Thememory 68 stores one ormore programs 70 for interacting with thedevices database 72. In particular, thedatabase 72 includesdata entries 74 that relate identifications ofspecific devices data entry 74 includes acopy 36A of thedevice identification 36 stored in relation to acopy 42B of thehash 42 of thefirmware 30. Thedatabase 72 also includesentries 76 that relate device makes, models and their firmware versions (M-M-F) to silver measurements (S #) of the corresponding firmware. Adatabase 72 includes the type of the flash controller and flash part of the device so that theFIC application 40 knows how to access the flash lock registers on different platforms. Over time, additional functionality can be added to the database. - A web front-
end 80, which is a further computing device, is connected to theserver 60 via communications link 82 and theinternet 38. Alerts indicating a change in thefirmware 30 ofdevice 20 are presented aspopup messages 86 on thedisplay 84 of the web front-end 80, which can also trigger emails or other messages to IT administrators. Thesystem 10 can also alert the end user directly with apopup message 90 or lock thedisplay 22 of thedevice 20, depending on the particular policy selected. - Referring to
FIG. 3 , a flowchart is shown of an exemplary process undertaken by theFIC application 40 in adevice 20 in which the firmware is BIOS. Instep 100, theFIC application 40 is initialized, which is achieved by loading, installing and running it in thedevice 20, under control of thepersistence module 34. - In
step 105, theFIC application 40 receives a policy from the backend, i.e. theserver 60. The policy includes instructions for theFIC application 40 as to which parts of thefirmware 30 to measure, how to measure them and how often to measure them, etc. Theserver 60 sends the policy and commands to thedevice 20, and the device sends data to the server. In some embodiments, the server informs theFIC application 40 on thedevice 20 whether its measurements are OK or not. However, this status information may be intentionally withheld from a compromised device if it is desired that the server continue to monitor the compromised device, while keeping a user of the device unaware that the status has been determined. - In
step 110, theapplication 40 gathers, from the device, the device's BIOS version, the date and time of its build, and its size. It also calculates ahash 42 of thefirmware 30, or a different hash for each volume of the firmware. Optionally, it gathers the I/O ports to enable/disable SMM and other parameters including published ACPI, SMBIOS, and/or other standard interfaces. - If, in
step 115, there is no information previously saved on the device by the FIC application (i.e. firmware version, firmware date, firmware time and/or firmware hash) with the policy relating to the specific device, then theapplication 40 proceeds to step 118. Instep 118, the gathered information and hashes fromstep 110 are securely saved locally and sent to theserver 60 instep 120. When theFIC application 40 runs for the first time it takes the baseline measurement, saves it securely on thedevice 20, and sends to theserver 60. When the FIC application next runs, it can then compare a new measurement with the saved baseline measurement, and, if different, send the new measurement to the server if instructed to do so by to the policy. Optionally, instep 121, the device may receive an acknowledgment from the server if the measurement is acceptable, for example if it corresponds to a silver measurement. Alternately, the optional message back from the server may be a command to take a security action, if the measurement does not equal a corresponding silver measurement. The process then ends instep 122. - Referring back to step 115, if the specific device information (i.e. firmware version, firmware date, firmware time and/or firmware hash) has been previously gathered from the
device 20 under control of the policy, which informs theFIC application 40 where to get the device specific information, then the process moves to step 125. Instep 125, theFIC application 40 determines whether the BIOS has been updated. This is done by comparing the current data obtained instep 110 with the previous data stored earlier instep 118. For example, this is achieved by comparing the current BIOS version number with the prior BIOS version number; the current BIOS build date with the prior BIOS build date; and/or the current BIOS size with the prior BIOS size. If the BIOS has been updated, then, instep 140, theFIC application 40 generates an alert and the new information is sent to the server instep 145, after which the process ends instep 150. Optionally, the device may receive an acknowledgment from the server or a security instruction before the process ends. The alert is displayed as a popup ormessage 90 on thedisplay 22 of thedevice 20, e.g. “Your device firmware was upgraded from version x to y; if you did not authorize the upgrade, shutdown the computer and contact your administrator. Unauthorized firmware change may be a sign of a hacker attack.” - If, in
step 125, theFIC application 40 determines that the BIOS has not been updated, then the process moves to step 130, in which the FIC application compares the current hashes with the prior hashes. If, instep 135, the BIOS has been changed, then, instep 140, the FIC application generates an alert and the new information is sent to the server instep 145, after which the process ends instep 150. In conjunction with the alert, the process may lock the device or permit restricted use only of it until the change in the BIOS has been verified to be legitimate. As above, the alert is displayed as a popup ormessage 90 on thedisplay 22 of thedevice 20. If, instep 135, the BIOS has not been changed, which is determined by the current hash being equal to the prior hash, then the process permits normal or continued and unhindered operation of the device instep 148, and then ends instep 150. In another embodiment, step 145 may be performed afterstep 148 even if there are no changes to the BIOS, i.e. the data would be sent again even if it has not changed. - The process can be repeated on every boot of the device or periodically, randomly or from time to time, starting from
step 105 in which the information is received from the server. - Referring to
FIG. 4 , instep 200, the FIC feature for thedevice 20 is enabled, for example by an administrator setting a flag inserver 60 that indicates that the feature should be present on the device. When theOS agent 41 indevice 20 communicates with theserver 60, the server reads the flag and instructs the OS agent to initialize theFIC application 40. - In
step 205, theserver 60 receives the BIOS version, build date and time, BIOS size and hashes of the firmware volumes from theFIC application 40 for the first time. This is achieved as a result of theFIC application 40 performingstep 120 ofFIG. 3 . - In
step 210, theserver 60 stores the received information (i.e. BIOS version, build date and time, BIOS size and hashes of the firmware volumes) in thedatabase 72, in arecord 74 that links it to anidentification 36 of the device. - In
step 220, theserver 60 receives updated information including the current firmware measurement for the device, as a result of theFIC application 40 performingstep 145 ofFIG. 3 . Instep 225, theserver 60 generates an acknowledgment that indicates that information has been received. Instep 230, the server determines whether the BIOS firmware has been updated to a later version, for example by comparing the currently received firmware version number with a previously received firmware version number from the same device. If it has, then, instep 235, the server determines whether a silver measurement is available. If a silver measurement is available, then, instep 245, the server performs a silver measurement check. This is done by comparing the current firmware measurement with the silver measurement and determining whether there is a difference between the two. If, instep 250, the result of the check is OK, i.e. there is no difference between the current firmware measurement and the silver measurement, then the new information and optionally the OK status are stored inrecord 74 in thedatabase 72, instep 240. The status indicates that at the date and time of the check, thefirmware 30 is OK. As well, a message may be sent back to the device to inform it that the update in its firmware is legitimate and that it may continue with its normal and unhindered operation. If the result of the silver measurement check is not OK instep 250, a security violation alert is generated instep 270. - Returning to step 235, if a silver measurement is not yet available, then the new information is stored in
step 240 in thedatabase 72 asrecord 74, or as an addition torecord 74. - Returning to step 230, if the server determines that the BIOS has not been updated to a later version, the server then determines, in
step 260 whether the BIOS has been rolled back to a prior version. The server identifies a roll-back of the BIOS by determining that the currently received firmware version number is earlier than the previously stored firmware version number from the same device. If the firmware has been rolled back, then, instep 270 the server generates a security violation alert. If the BIOS has not been rolled back to a prior version, then the server determines, instep 265, whether the hashes of the firmware volumes have been changed. If they have been changed, then, instep 270, the server generates a security violation alert. If the hashes have not changed, as would be the case ifstep 145 is performed followingstep 148, the server determines whether a later BIOS version is available instep 290. If there is not a new BIOS available, the process ends atstep 280. If a new BIOS is available, i.e. the current firmware is out of date, then a notification is sent to the IT administrator and/or the user of thedevice 20 instep 295, after which the process ends instep 280. The server can also check whether it is aware of a newer version of thefirmware 30, and, if so, sends an alert to the user that a BIOS update is available, and to the IT administrator that thedevice 20 still uses an older BIOS. - After each security violation alert in
step 270, the parameters that caused the alert are displayed on theuser interface 66 of the server and/or as a pop-up 86 or other message on a web front-end computer 80 instep 275. In some embodiments, alerts may also be communicated from theserver 60 to thedevice 20 for display on the display of the device, or to trigger a security response in the device such as a lock-down. After generation of a security violation alert instep 270, the server may send a message to the device to instruct it to freeze, to delete data therefrom, to transmit data to the server, to reduce its functionality, or to transmit its location such that it can be tracked. Other security measures are also possible. Following this, the process ends instep 280. The process is then repeated fromstep 220 as and when it receives new data from the device. - If the flag in the
server 60 for the FIC feature is not set, then theOS agent 41 of thedevice 20 will either disable theFIC application 40 if it is present in the device or refrain from enabling it if it is absent from the device. - When measuring the firmware, care should be taken to measure the code rather than the data, otherwise the measurements may become meaningless. However, it is conceivable that the measurements may include a permissible range of allowed data and/or settings if the measurement checks can allow for it.
- Referring to
FIG. 5 , an exemplary process for deriving a silver measurement is shown. Instep 300, the FIC feature is enabled on multiple devices having the same make, model and firmware version. Instep 305, the server receives the BIOS information for the multiple devices, including the build date, time and size, and hashes of the firmware volumes. The hashes must all be calculated in the same way in order to provide consistent results. Instep 310, the server determines whether the number of devices for which the BIOS information has been received is above a first threshold number. If the number of devices does not meet the first threshold, the server proceeds to wait, and then later receives BIOS information from more devices, by returning to step 305. - As an example, the first threshold number of devices may be equal to 10. However, in other embodiments the first threshold may be different, configurable and/or adjustable, either manually or automatically, and the actual value may be based on statistical data.
- Once the first threshold has been reached, the server determines, in
step 315, whether the number of devices that have identical information is above another, second threshold (which may either be the same number as the first threshold or a lower number). This second threshold may be 9, for example, which, if the first threshold is 10, would indicate with a relatively high probability that these 9 devices are uncompromised. The 1 device out of the 10, which has different information, may likewise be considered to be compromised with a relatively high probability. If the number of devices with identical measurements is not equal to or above the second threshold, then the process reverts to step 305 to receive BIOS information from more devices. - If, in
step 315, the number of devices that report identical BIOS information is equal to or above the second threshold, then, instep 320, the hash of the reported identical BIOS information is set as the silver measurement for the specific make, model and firmware version of the device. Instep 325, the silver measurement (S #) is stored in thedatabase 72 in arecord 76 that links to the specific make, model and firmware version (M-M-F) of the device. The process ends instep 335, and may be repeated for other makes, models and/or firmware versions of devices that are to have their firmware integrity checked. - The result is that the server can look at new firmware, analyze it, and automatically determine whether it is genuine or suspect without having to compare it with a pre-existing benchmark. Once the new firmware is determined to be genuine, it is defined as a silver measurement. The silver measurement can then be used as a benchmark for checking the firmware of further devices.
- Note that the information obtained in step 110 (
FIG. 3 ) may simply be a repeat of existing information, but received at a later time or date, which would indicate that thefirmware 30 has not changed. In some embodiments, the device itself may not detect the change in the firmware, but leave the detection of change to theserver 60 to perform. - Thresholds in the determination of the silver measurement may be different depending on the identity of the devices that initially contact the server with an updated firmware version. Lower thresholds may be used if the measurements are coming from devices that are, or become, known to be less susceptible to firmware attacks than other devices. The thresholds may be different depending on make, model, number of identified firmware attacks, location of the devices, owner of the devices, configuration of the devices, etc. The thresholds may also vary with time.
- In a basic embodiment, the silver measurement may include a firmware version number and firmware date and time. An intermediate embodiment may further include one or more of the actual firmware volume measurements. An advanced embodiment may ultimately completely satisfy the NIST guidelines referred to above. Another possible variation is to include measurements of the firmware settings and to discover which combinations are disallowed by the customers.
- Functions described as being performed by one server may be divided between separate servers, and functions described as being performed on multiple servers may be combined on the same server. Intermediate servers may also be employed in the system.
- Steps in the flowcharts may be performed in a different order to that illustrated, or they may be combined where shown separately. Steps may be omitted and others added, and steps from different flowcharts may be interchanged, all without departing from the scope of the invention. Components shown herein may be divided into constituent components or be combined with each other.
- While the invention has been described predominantly with respect to BIOS, it applies equally to UEFI and other types of firmware.
- In other embodiments, the persistence module is a form of firmware, but not considered to be device firmware.
- In general, unless otherwise indicated, singular elements may be in the plural and vice versa with no loss of generality. Drawings are not to scale or in proportion.
- The detailed descriptions within are presented largely in terms of methods or processes, symbolic representations of operations, functionalities and features of the invention. These method descriptions and representations are the means used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. A software implemented method or process is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. These steps involve physical manipulations of physical quantities. Often, but not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It will be further appreciated that the line between hardware, software and firmware is not always sharp, it being understood by those skilled in the art that software implemented processes may be embodied in hardware, firmware, or software, in the form of coded instructions such as in microcode and/or in stored programming instructions. Computer readable memory or media described herein are all non-transitory in that they store computer readable instructions and/or computer readable data either permanently or temporarily. A medium that can only support a propagating signal without storing it is considered to be transitory.
- The present description includes the best presently contemplated mode of carrying out the subject matter disclosed and claimed herein. The description is made for the purpose of illustrating the general principles of the subject matter and not be taken in a limiting sense; the subject matter can find utility in a variety of implementations without departing from the scope of the disclosure made, as will be apparent to those of skill in the art from an understanding of the principles that underlie the subject matter.
Claims (19)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/941,945 US20230004648A1 (en) | 2017-08-22 | 2022-09-09 | Firmware Integrity Check Using Silver Measurements |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201762548815P | 2017-08-22 | 2017-08-22 | |
PCT/CA2018/050443 WO2019036795A1 (en) | 2017-08-22 | 2018-04-10 | Firmware integrity check using silver measurements |
US202016639876A | 2020-02-18 | 2020-02-18 | |
US17/941,945 US20230004648A1 (en) | 2017-08-22 | 2022-09-09 | Firmware Integrity Check Using Silver Measurements |
Related Parent Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CA2018/050443 Continuation WO2019036795A1 (en) | 2017-08-22 | 2018-04-10 | Firmware integrity check using silver measurements |
US16/639,876 Continuation US11443041B2 (en) | 2017-08-22 | 2018-04-10 | Firmware integrity check using silver measurements |
Publications (1)
Publication Number | Publication Date |
---|---|
US20230004648A1 true US20230004648A1 (en) | 2023-01-05 |
Family
ID=65438257
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/639,876 Active US11443041B2 (en) | 2017-08-22 | 2018-04-10 | Firmware integrity check using silver measurements |
US17/941,945 Pending US20230004648A1 (en) | 2017-08-22 | 2022-09-09 | Firmware Integrity Check Using Silver Measurements |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/639,876 Active US11443041B2 (en) | 2017-08-22 | 2018-04-10 | Firmware integrity check using silver measurements |
Country Status (5)
Country | Link |
---|---|
US (2) | US11443041B2 (en) |
EP (1) | EP3673401A4 (en) |
AU (1) | AU2018321586B2 (en) |
CA (1) | CA3071288C (en) |
WO (1) | WO2019036795A1 (en) |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11138315B2 (en) * | 2018-01-17 | 2021-10-05 | Hewlett Packard Enterprise Development Lp | Data structure measurement comparison |
US11797684B2 (en) * | 2018-08-28 | 2023-10-24 | Eclypsium, Inc. | Methods and systems for hardware and firmware security monitoring |
US11017090B2 (en) * | 2018-12-17 | 2021-05-25 | Hewlett Packard Enterprise Development Lp | Verification of a state of a platform |
US11360784B2 (en) | 2019-09-10 | 2022-06-14 | Hewlett Packard Enterprise Development Lp | Integrity manifest certificate |
US11080039B2 (en) * | 2019-11-25 | 2021-08-03 | Micron Technology, Inc. | Resilient software updates in secure storage devices |
US11281472B2 (en) * | 2020-02-03 | 2022-03-22 | Dell Products L.P. | System and method for securing compromised information handling systems |
CN111352785B (en) * | 2020-03-05 | 2022-12-20 | 苏州浪潮智能科技有限公司 | Detection method and system for non-version-number firmware of storage server |
US20240045946A1 (en) * | 2020-12-11 | 2024-02-08 | Hewlett-Packard Development Company, L.P. | Devices for verifying the integrity of software |
WO2023188231A1 (en) * | 2022-03-31 | 2023-10-05 | 日本電気株式会社 | Network monitoring system, network monitoring method, and recording medium |
US20240028734A1 (en) * | 2022-07-21 | 2024-01-25 | Dell Products L.P. | Automated update of a customized secure boot policy |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013036223A1 (en) * | 2011-09-07 | 2013-03-14 | Intel Corporation | Verifying firmware integrity of a device |
US20140109076A1 (en) * | 2012-10-16 | 2014-04-17 | Pieter-Jan Boone | Secure, non-disruptive firmware updating |
US20150161616A1 (en) * | 2013-12-09 | 2015-06-11 | CrowdCare Corporation | System and Method of Creating and Using a Reference Device Profile |
US20180018208A1 (en) * | 2016-07-12 | 2018-01-18 | Infineon Technologies Ag | Diverse integrated processing using processors and diverse firmware |
US20180314507A1 (en) * | 2017-04-27 | 2018-11-01 | Quanta Computer Inc. | Automatic firmware and custom setting provision for server device |
US20180330093A1 (en) * | 2017-05-12 | 2018-11-15 | Hewlett Packard Enterprise Development Lp | Performing an action based on a pre-boot measurement of a firmware image |
Family Cites Families (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1429224A1 (en) | 2002-12-10 | 2004-06-16 | Texas Instruments Incorporated | Firmware run-time authentication |
US7159144B2 (en) * | 2003-06-20 | 2007-01-02 | Broadcom Corporation | Firmware code profiling |
US20050132177A1 (en) | 2003-12-12 | 2005-06-16 | International Business Machines Corporation | Detecting modifications made to code placed in memory by the POST BIOS |
US7725703B2 (en) | 2005-01-07 | 2010-05-25 | Microsoft Corporation | Systems and methods for securely booting a computer with a trusted processing module |
US7907531B2 (en) | 2005-06-13 | 2011-03-15 | Qualcomm Incorporated | Apparatus and methods for managing firmware verification on a wireless device |
US7870394B2 (en) * | 2006-05-26 | 2011-01-11 | Symantec Corporation | Method and system to scan firmware for malware |
US7613872B2 (en) | 2006-11-28 | 2009-11-03 | International Business Machines Corporation | Providing core root of trust measurement (CRTM) for systems using a backup copy of basic input/output system (BIOS) |
KR20080090939A (en) * | 2007-04-06 | 2008-10-09 | 삼성전자주식회사 | Method for generating firmware update file and for updating firmware by using the firmware update file and apparatus thereof |
US9053323B2 (en) * | 2007-04-13 | 2015-06-09 | Hewlett-Packard Development Company, L.P. | Trusted component update system and method |
KR101427646B1 (en) | 2007-05-14 | 2014-09-23 | 삼성전자주식회사 | Method and apparatus for checking integrity of firmware |
US8555049B2 (en) | 2007-10-05 | 2013-10-08 | Panasonic Corporation | Secure boot terminal, secure boot method, secure boot program, recording medium, and integrated circuit |
US8898477B2 (en) * | 2007-11-12 | 2014-11-25 | Gemalto Inc. | System and method for secure firmware update of a secure token having a flash memory controller and a smart card |
US20090172639A1 (en) | 2007-12-27 | 2009-07-02 | Mahesh Natu | Firmware integrity verification |
DE102008011925B4 (en) | 2008-02-29 | 2018-03-15 | Globalfoundries Inc. | Safe initialization of computer systems |
CN101247416A (en) | 2008-03-25 | 2008-08-20 | 中兴通讯股份有限公司 | Firmware downloading method, preprocessing method and integrality verification method based on OTA |
JP2011526113A (en) | 2008-06-27 | 2011-09-29 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | Apparatus, system, and method for verifying authenticity, integrity, and / or physical state of an item |
WO2011009051A1 (en) | 2009-07-16 | 2011-01-20 | Assa Abloy Ab | Blind verification of computer firmware |
US8869264B2 (en) | 2010-10-01 | 2014-10-21 | International Business Machines Corporation | Attesting a component of a system during a boot process |
US8856771B2 (en) | 2011-08-19 | 2014-10-07 | International Business Machines Corporation | Protection for unauthorized firmware and software upgrades to consumer electronic devices |
US9262637B2 (en) | 2012-03-29 | 2016-02-16 | Cisco Technology, Inc. | System and method for verifying integrity of platform object using locally stored measurement |
US8850588B2 (en) | 2012-05-01 | 2014-09-30 | Taasera, Inc. | Systems and methods for providing mobile security based on dynamic attestation |
US9910659B2 (en) * | 2012-11-07 | 2018-03-06 | Qualcomm Incorporated | Methods for providing anti-rollback protection of a firmware version in a device which has no internal non-volatile memory |
US9471536B1 (en) | 2012-12-06 | 2016-10-18 | Amazon Technologies, Inc. | Automated firmware settings management |
US9870474B2 (en) | 2013-04-08 | 2018-01-16 | Insyde Software Corp. | Detection of secure variable alteration in a computing device equipped with unified extensible firmware interface (UEFI)-compliant firmware |
EP3061030A4 (en) * | 2013-10-24 | 2017-04-19 | McAfee, Inc. | Agent assisted malicious application blocking in a network environment |
US9753796B2 (en) * | 2013-12-06 | 2017-09-05 | Lookout, Inc. | Distributed monitoring, evaluation, and response for multiple devices |
US9317691B2 (en) | 2014-05-08 | 2016-04-19 | Dell Products L.P. | Pre-boot software verification |
US10395032B2 (en) | 2014-10-03 | 2019-08-27 | Nokomis, Inc. | Detection of malicious software, firmware, IP cores and circuitry via unintended emissions |
WO2016015049A2 (en) * | 2014-07-25 | 2016-01-28 | Trenchware, Inc. | Detection and remediation of malware within firmware of devices |
-
2018
- 2018-04-10 AU AU2018321586A patent/AU2018321586B2/en active Active
- 2018-04-10 CA CA3071288A patent/CA3071288C/en active Active
- 2018-04-10 US US16/639,876 patent/US11443041B2/en active Active
- 2018-04-10 WO PCT/CA2018/050443 patent/WO2019036795A1/en unknown
- 2018-04-10 EP EP18847963.8A patent/EP3673401A4/en active Pending
-
2022
- 2022-09-09 US US17/941,945 patent/US20230004648A1/en active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013036223A1 (en) * | 2011-09-07 | 2013-03-14 | Intel Corporation | Verifying firmware integrity of a device |
US20140109076A1 (en) * | 2012-10-16 | 2014-04-17 | Pieter-Jan Boone | Secure, non-disruptive firmware updating |
US20150161616A1 (en) * | 2013-12-09 | 2015-06-11 | CrowdCare Corporation | System and Method of Creating and Using a Reference Device Profile |
US20180018208A1 (en) * | 2016-07-12 | 2018-01-18 | Infineon Technologies Ag | Diverse integrated processing using processors and diverse firmware |
US20180314507A1 (en) * | 2017-04-27 | 2018-11-01 | Quanta Computer Inc. | Automatic firmware and custom setting provision for server device |
US20180330093A1 (en) * | 2017-05-12 | 2018-11-15 | Hewlett Packard Enterprise Development Lp | Performing an action based on a pre-boot measurement of a firmware image |
Also Published As
Publication number | Publication date |
---|---|
CA3071288C (en) | 2021-03-09 |
US11443041B2 (en) | 2022-09-13 |
EP3673401A1 (en) | 2020-07-01 |
EP3673401A4 (en) | 2021-04-14 |
AU2018321586A1 (en) | 2020-01-30 |
AU2018321586B2 (en) | 2023-03-09 |
CA3071288A1 (en) | 2019-02-28 |
US20200364340A1 (en) | 2020-11-19 |
WO2019036795A1 (en) | 2019-02-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20230004648A1 (en) | Firmware Integrity Check Using Silver Measurements | |
US20200302057A1 (en) | Verifying controller code | |
CN108027860B (en) | Hardening event counter for anomaly detection | |
Xu et al. | Dominance as a new trusted computing primitive for the internet of things | |
US20200272739A1 (en) | Performing an action based on a pre-boot measurement of a firmware image | |
US10474819B2 (en) | Methods and systems for maintaining a sandbox for use in malware detection | |
US8028172B2 (en) | Systems and methods for updating a secure boot process on a computer with a hardware security module | |
US8490189B2 (en) | Using chipset-based protected firmware for host software tamper detection and protection | |
KR101458780B1 (en) | Providing a multi-phase lockstep integrity reporting mechanism | |
Han et al. | A bad dream: Subverting trusted platform module while you are sleeping | |
US9607156B2 (en) | System and method for patching a device through exploitation | |
KR101402542B1 (en) | Persistent security system and method | |
US9349009B2 (en) | Method and apparatus for firmware based system security, integrity, and restoration | |
US8819330B1 (en) | System and method for updating a locally stored recovery image | |
US9245122B1 (en) | Anti-malware support for firmware | |
KR20150134679A (en) | Analysis system and method for patch file | |
CN104850792A (en) | Establishment method and apparatus of trust chain of server | |
CN108292342B (en) | Notification of intrusions into firmware | |
US8838952B2 (en) | Information processing apparatus with secure boot capability capable of verification of configuration change | |
US9779248B1 (en) | Protection of secured boot secrets for operating system reboot | |
CN110245495A (en) | BIOS method of calibration, configuration method, equipment and system | |
US20170300692A1 (en) | Hardware Hardened Advanced Threat Protection | |
US20200244461A1 (en) | Data Processing Method and Apparatus | |
CN110363011B (en) | Method and apparatus for verifying security of UEFI-based BIOS | |
US20180226136A1 (en) | System management mode test operations |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
AS | Assignment |
Owner name: ARES CAPITAL CORPORATION, AS COLLATERAL AGENT, NEW YORK Free format text: SECURITY INTEREST;ASSIGNORS:ABSOLUTE SOFTWARE CORPORATION;MOBILE SONIC, INC.;REEL/FRAME:064434/0284 Effective date: 20230727 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |