[go: up one dir, main page]

WO2017188995A1 - Vérification de produit - Google Patents

Vérification de produit Download PDF

Info

Publication number
WO2017188995A1
WO2017188995A1 PCT/US2016/030136 US2016030136W WO2017188995A1 WO 2017188995 A1 WO2017188995 A1 WO 2017188995A1 US 2016030136 W US2016030136 W US 2016030136W WO 2017188995 A1 WO2017188995 A1 WO 2017188995A1
Authority
WO
WIPO (PCT)
Prior art keywords
indicator
computing device
software module
software
customer
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.)
Ceased
Application number
PCT/US2016/030136
Other languages
English (en)
Inventor
Sung Oh
Barry L. Goodwin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Priority to PCT/US2016/030136 priority Critical patent/WO2017188995A1/fr
Publication of WO2017188995A1 publication Critical patent/WO2017188995A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/575—Secure boot

Definitions

  • the software e.g., firmware, embedded software, etc.
  • the software may be compromised such as altered by unauthorized entities or individuals. Indeed, the software may be unscrupulously amended, and also undesired or unauthorized software added to the computing device in addition to the software intended by the supplier, and so forth.
  • the product received by the customer may be compromised.
  • detection of compromise of a computing device may be problematic.
  • Conventional solutions to provide physical security control of product packaging such as tamper proof tape may not address the manufacturing process or logistics operations.
  • FIG. 1 is a block diagram of system having a server for product verification in relation to a manufacturer in accordance with examples
  • FIG. 2 is a block diagram of system having a server for product verification in relation to a customer site in accordance with examples
  • FIG. 3 is a block diagram of a method of product verification in relation to a manufacturer in accordance with examples
  • FIG. 4 is a block diagram of a method of product verification in relation to a customer site in accordance with examples.
  • FIG. 5 is a block diagram showing a tangible, non-transitory, computer-readable medium that stores code configured to direct a processor to perform product verification in accordance with examples.
  • Examples of the present techniques are directed to generating software for a computing device, and to product verification of the software and the computing device.
  • the software may be generally including a software module(s) and may generally computer readable instructions. This discussion may use "software,” “software module,” and “software modules”
  • a first indicator may be calculated as a function of the software module as generated and prior to the software module being installed on the computing device.
  • a second indicator may be calculated as a function of the software module as installed on the computing device (e.g., with the software module as stored on the computing device at a manufacturer site). The second indicator may be compared to the first indicator. If the indicators are equal, then the computing may be fit to ship to the customer. On the other hand, if the second indicator is not equal to the first indicator, such may be an indication that the software module was compromised during the fabrication of the computing device at the manufacturer.
  • the computing device having the software module may be shipped from the manufacturer to the customer.
  • a third indicator may be calculated as a function of the software module as stored on the computing device as received by the customer.
  • the third indicator may be compared to the first indicator. If the third indicator is not equal to the first indicator, such may be an indication that the computing device and/or software module was compromised while the computing device was in transit from the manufacturer to the customer, for example. Conversely, if the third indicator is equal to the first indicator, such may be an indication that the computing device (and software module) is fit to use by the customer.
  • the indicators may be hash values calculated via a secure hash function and based on product information of the software module.
  • the product information may include product type, product number, software module revision indicator, customer name, customer order number, and the like.
  • computing devices having firmware and/or embedded software modules may be compromised during manufacture or while in route to the customer.
  • the present techniques provide for a hash generation and verification process for firmware and embedded software modules on computing devices.
  • a first hash value based on the
  • firmware/software module is calculated during development of the
  • a second hash value based on the firmware/software module as stored on the computing device is calculated during the manufacture of the computing device. The computing device is shipped to the customer if the second hash value is equal to the first hash value.
  • a third hash value is calculated based on the firmware/software stored on the computing device as received by the customer. The customer may be notified that the computing device is acceptable to use if the third hash value is equal to the first hash value.
  • a particular example includes a Product Firmware Recipe
  • PF-RAP Authentication Process
  • PF-RAP may be a hash generation and verification process for firmware and embedded software on products (software, computing devices, etc.).
  • a hash may be generated based on product type, product number, firmware revision, embedded software revision, and so on. This hash may be compared to a hash based on development originated data for the same configuration. The product may not be allowed to ship from the manufacturer to the customer unless the hash files are a match.
  • a third hash may be generated and compared to the development originated data. If there is a mismatch, the product may not be allowed to be used by the customer until the mismatch is resolved.
  • a hash may be generated based on product type, product number, firmware revision, and embedded software revision.
  • a Secure Hash Algorithm (SHA) function may be used to generate a hash file.
  • This hash file may be sent to the secured PF-RAP web server, where this hash file may be compared to a hash generated by same SHA function by development for the same configuration. If the hash is matched, a message may be sent to manufacturing authorizing the shipment of this product to the customer. Again, generally, a product may not be allowed to ship from the manufacturer to the customer unless hash files are a match.
  • a third hash may be generated when the system is first powered up, for example.
  • This hash may be sent to same secured PF-RAP web server, where this hash may be compared to the hash generated by the same SHA function by development organization for the same configuration. If the hash is matched, a message may be sent to the product system at the customer authorizing the use of product. However, as indicated, a product may not be allowed to be used by customer until any mismatch is resolved.
  • Advantages may include to protect the supplier or generator of the software from delivering compromised products to customer.
  • Implementation may demonstrate to customers that the software developer and supplier is serious about protecting their customers from cyber risks such as malware, rootkit, and the like.
  • market share and revenue could be increased through reduced cyber risks product.
  • the technique can be employed for products containing firmware and/or embedded software, such products as storage, servers, network, and so forth. The technique may facilitate use of the technique by both internal and external manufacturing organizations.
  • Such entities may include: (1 ) software development organization; (2) the PF-RAP center; (3) the manufacturer; and (4) the customer, etc.
  • the initial product development of the software by the development organization may include a validation of the product in creating individual product's firmware and embedded software's hash file using a PF-RAP client application.
  • Product information and the hash file may be sent from
  • the product information may include product type, product number, firmware revision, firmware hash file, embedded software revision, embedded software file has file, and other information.
  • the firmware and/or embedded software may be released from development to production (the fabricator or manufacturer).
  • the PF-RAP center may collect product firmware and embedded software hash file from development.
  • the software hash file (including for individual product firmware, embedded software, etc.) may be stored as a hash file with read only attribute, for example.
  • An individual product's hash file (e.g., to use in comparison for production process) may be available to a secure web site with read only attribute, for instance.
  • the PF-RAP center may collect a product's firmware, embedded software, and system information bundle of hash file from production process (if matches).
  • the PF-RAP center may store a product's firmware, embedded software, system's information bundle of hash file. This product's bundle hash file may be available (e.g., to use in comparison for customer) to a secure web site with read only attribute.
  • the product or computing device having the software product may be built and tested, and including installing the software (e.g., firmware and embedded software).
  • the software e.g., firmware and embedded software
  • a product's firmware and embedded software signature file may be created using an PF-RAP client.
  • a comparison may be made between the manufacturer firmware and embedded software against PF-RAP database signature files using PF-RAP client. If the hash values do not match, notification may be provided to the development organization and/or the manufacturer, and production support staff waits for corrective action. If the hash values do match, a bundle of hash file (including firmwares, embedded softwares, and system information) may be created by the manufacturer using a PF-RAP client, for later comparison to customer information. The product may be sent to the customer.
  • the customer may receive a product from the manufacturer or factory.
  • the customer may power-on the system and automatically trigger PF-RAP client as part of initial system boot process.
  • a run-time bundle of hash file (including firmwares, embedded softwares, and system information) may be created using an PF- RAP client.
  • the product's hash value may be compared with factory originated hash value via secure web site using PF-RAP client, for instance. If the hash values match, the system may continue booting the remainder of the boot process with default operating system, and with completing operating system boot such as Windows, Linux, etc. If the hash values do not match, a message may be displayed, such as "please contact customer service," and the system does not proceed to the remainder of the boot process.
  • FIG. 1 is an example system 100 having a computing system (server 102) for product verification in relation to at least a manufacturer.
  • the server 102 has product verification code 104 (e.g., instructions, logic, etc.) stored in memory 106 and executable by a processor 108. Further, the memory 106 or other memory may store one or more indicators 1 10 (e.g., hash values) calculated via the product verification code 104, as discussed below.
  • product verification code 104 e.g., instructions, logic, etc.
  • the memory 106 or other memory may store one or more indicators 1 10 (e.g., hash values) calculated via the product verification code 104, as discussed below.
  • the memory 106 may include nonvolatile memory and volatile memory.
  • the processor 108 may be more than one processor 108, and each processor 108 may have more than one core.
  • the processor 108 as a hardware processor may be a central processing unit (CPU), a microprocessor, a controller, and so forth.
  • the product verification code 104 when executed by the processor 108 may provide for the server 102 to verify a product such as software 1 12 and/or a computing device having the software 1 12.
  • the software 1 12 is software module including computer readable instructions.
  • the illustrated embodiment depicts software 1 12 which may be generated by a supplier or development organization and stored in a memory 1 14 device, for example.
  • the software 1 12 may be supplied to a fabricator or manufacturer 1 16 which installs the software 1 12 on a computing device 1 18.
  • the software 1 12 and/or the computing device 1 18 may be specific to a particular customer in some examples.
  • the product verification code 104 may be executed by the processor 108 to: (1 ) calculate a first indicator as a function of product information of the software 1 12 prior to the software 1 12 being stored on the computing device 1 18; (2) calculate a second indicator 1 10 as a function of the product information of the software 1 12 with the software 1 12 as stored on the computing device 1 18; and (3) compare the first indicator to the second indicator 1 10 for product verification such as product verification of the computing device 1 18 and/or software 1 12 at the manufacturer 1 16 site (e.g., when the manufacturer is ready to ship the computing device 1 18 to a customer).
  • the second indicator equaling the first indicator may indicate that the software 1 12 was not compromised at the manufacturer 1 16 site. If so, the manufacturer 1 16 may ship the computing device 1 18 having the software 1 12 to the customer. On the other hand, the second indicator not equaling the first indicator may generally indicate that the software 1 12 has been compromised at the manufacturer 1 16 site. Therefore, if compromised, the manufacturer 1 16 may not ship the computing device 1 18 to the customer in examples.
  • the software 1 12 may be firmware or embedded software, or both, on the computing device 1 18.
  • the product information used to calculate the first and second indicators (and subsequent indicators) may be product type, product number, software firmware revision (e.g., a revision number or version), and other information.
  • the software revision may be a firmware revision, an embedded software revision, and the like.
  • the product type and product number may refer to the software 1 12 and/or the computing device 1 18 as products, and may be specific to a particular customer.
  • the product information for calculating the first indicator may be provided to the server 102 by the supplier (developer) or generator of the software 1 12, e.g., with the software 1 12 as stored in the memory 1 14 device and prior to download or transfer of the software 1 12 to the manufacturer 1 16 to be installed on a computing device 1 18.
  • the product information for calculating the second indicator may be provided to the server 102 from the manufacturer 1 16, such as when fabrication of the computing device 1 18 is complete and being tested, and is ready to be shipped to the customer.
  • the manufacturer 1 12 may be given a product-verification client application to facilitate communication with (and provision of product information to) the server 102.
  • the product verification code 104 on the server 102 may include a secure hash function to calculate the indicators 1 10. Therefore, the first indicator may be a first hash value, and the second indicator may be a second hash value.
  • the first and second indicators 1 10 (e.g., hash values) may be stored by the server 102 in the memory 106 (or other memory).
  • the second indicator may be calculated based on the product information with the software 1 12 as stored on the computing device 1 18 at the manufacturer 1 16 site and prior to shipment of the computing device 1 18 to a customer.
  • FIG. 2 is an exemplary system 200 having the server 102 for product verification in relation to a customer 202 site.
  • the server 102 may be used for product verification both in relation to a manufacturer 1 16 (FIG. 1 ) and relation to a customer 202.
  • the code 104 may be executable by the processor 108 for the server 102 to: (1 ) calculate a third indicator as a function of the product information of the software 1 12 with the software as stored on the computing device 1 18 as received by the customer 202; (2) retain the third indicator (e.g., a hash value) in the memory 106; and (3) compare the third indicator to the first indicator. This comparison may be for product verification of the computing device 1 18 and software 1 12 as received by the customer 202 prior to the customer 202 placing the computing device 1 18 into full operation.
  • the customer 202 may provide to the server 102 the product information of the computing device 1 18 and software 1 12, for the computing device 1 18 as received by the customer 202.
  • the customer 202 may be given a product-verification client application to facilitate communication with (and provision of product information to) the server 102.
  • the client application may be utilized for the computing device 1 18 at the customer 202 site to communicate product information to the server 102 when the computing device 1 18 being initially booted at the customer 202 site.
  • the server 102 may compare the server 102 to determine whether the computing device 1 18 and/or software 1 12 was compromised while in transit to the customer 1 12, for example. If so compromised, the computing device 1 18 may halt the boot, for example, and display a notification not to use the computing device 1 18. Other forms of notification are applicable. If the third indicator equals the first indicator, the computing device 1 18 may complete the initial boot as normal.
  • first, second, and third indicators may be numerical values, alphanumeric, and so on.
  • the code 104 may include a function that converts the aforementioned product information to the indicators (e.g., numeric or alphanumeric values).
  • the product information input to the function may be numbers and/or text, etc.
  • the function may provide for a mathematical transformation or a set of mathematical transformations.
  • the function may be a hash function.
  • the code 104 may include (or have access to) a cryptographic hash function (hashing algorithm). Therefore, the indicators may be hash values (output of the hash function).
  • the values returned by a hash function may be called hash values, hash codes, hash sums, or simply hashes, and the like. Other terms for the output may include digest or tag, and so on.
  • the product information as input to the hash function may be numbers and/or text, etc.
  • FIG. 3 is an exemplary method 300 of product verification in relation to a manufacturer.
  • software software module
  • the software may be intended as firmware and/or embedded software for a computing device, and may be intended for a particular customer.
  • the software and/or the computing device may be specific to a particular customer in some examples.
  • the software may be downloaded or otherwise transferred to a fabricator or manufacturer for installation of the software on the computing device such as in the fabrication or assembly of the computing device, and ultimately for the computing device having the software to be shipped to a customer.
  • a first indicator e.g., numerical value, alphanumeric, hash value, etc.
  • the software is provided to a manufacturer for installation of the software on a computing device, and ultimately for shipment of the computing having the software to a customer.
  • the software may include firmware or embedded software, or both.
  • a second indicator as a function of the software as stored on the computing device is calculated via the processor.
  • the first and second indicators may be calculated based on product information of the software.
  • the software product information may include product type, product number, firmware revision version, embedded software revision version, customer identification, customer order number or identifier, and so on.
  • the second indicator may be calculated in response to the manufacturer testing and/or when the manufacturer is ready to ship the computing device to a customer.
  • the product information for calculating the second indicator may be provided from the manufacturer, such as via a client application.
  • the second indicator is compared, via the processor, to the first indicator. If the first and second indicators are equal, such may be an indication that the software was not compromised during the manufacture of the computing device. In response in examples of this situation with no
  • the manufacturer will ship the computing device having the software to the customer. Conversely, if the first and second indicators are not equal, such may indicate the software was compromised during the
  • the manufacturer will not ship the computing device having the software to the customer. Indeed, the manufacturer may be notified not to ship the computing device to the customer.
  • the first indicator may be a first hash value
  • the second indicator may be a second hash value.
  • the first and second indicators may be calculated using a hash function.
  • the second indicator may be calculated as a function of the software as stored on the computing device at a manufacturer site and prior to shipment of the computing device to a customer.
  • the first indicator and second indicator may be calculated as a function of product information of the software, and wherein the second indicator is calculated as a function of product information (e.g., a software revision version, customer identification, etc.) of the software as store on the computing device at a manufacturing site and prior to shipment to a customer.
  • FIG. 4 is an exemplary method 400 of product verification in relation to a customer site.
  • the method 400 may operate in conjunction with the method 300 of FIG. 3.
  • the method may include shipping the computing device (having the software or software module) to the customer in response to the second indicator equaling the first indicator.
  • a third indicator is calculated, via the processor, as a function of the software (software module) as stored on the computing device as received by the customer.
  • the third indicator may be a hash value calculate with a same hash function used to calculate the first and second indicators.
  • the third indicator is compared, via the processor, to the first indicator. The comparison may occur during customer boot of the computing device. If the third indicator is equal to the first indicator, the customer may proceed with use of the computing device (and software), as indicated in block 406. In contrast, if the third indicator does not equal the first indicator, the customer may be notified to not use the computing device, as indicated in block 408.
  • the indicators (first, second, third) calculated may be numerical values or alphanumeric.
  • a function may be employed to convert the product information to the indicators.
  • the indicators as calculated may be hash values (digest, hash function output, etc.). If so, the first indicator may be a first hash value, the second indicator may be a second hash value, and the third indicator is a third hash value.
  • the product information of the software module as input to the cryptographic hash function may be text or numbers, and so on.
  • FIG. 5 is a block diagram showing a tangible, non-transitory, computer-readable medium that stores code configured to direct a processor to perform product verification.
  • the computer-readable medium is referred to by the reference number 500.
  • the computer-readable medium 500 can include RAM, a hard disk drive, an array of hard disk drives, an optical drive, an array of optical drives, a non-volatile memory, a flash drive, a digital versatile disk (DVD), or a compact disk (CD), among others.
  • the computer-readable medium 500 may be accessed by a processor 502 over a computer bus 504.
  • the computer-readable medium 500 may include code configured to perform the methods and techniques described herein.
  • the various software components discussed herein may be stored on the computer-readable medium 500.
  • a portion 506 of the computer-readable medium 700 can include product verification code, which may be executable code (machine readable
  • the computer readable medium 500 may be the memory 106 in the server 102 of FIGS. 1 and 2, for example.
  • the computer readable medium 500 may include the code 104 of FIGS. 1 and 2, for instance.
  • An example includes a tangible, non-transitory, computer-readable medium having instructions for product verification, the instructions direct a processor to: (1 ) calculate a first indicator as a function of product information of software (software module) prior to the software being stored on a computing device; (2) calculate a second indicator as a function of the product information of the software with the software as stored on the computing device; and (3) compare the first indicator to the second indicator.
  • the software may be firmware or embedded software, or both.
  • the code in portion 506 may include a hash function (e.g., cryptographic hash function) to calculate the first and second indicators. Therefore, the indicators as calculated may be hash values (digest, hash function output, etc.). If so, the first indicator may be a first hash value, and the second indicator may be a second hash value.
  • the product information of the software module as input to the cryptographic hash function may be text or numbers, and so on.
  • the second indicator is calculated as a function of the product information with the software as stored on the computing device at a
  • the instructions may direct the processor to: (1 ) calculate a third indicator as a function of the product information of the software with the software as stored on the computing device as received by the customer; and (2) compare the third indicator to the first indicator.
  • the third indicator may also be a hash value as calculated via the hash function.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Dans des exemples, l'invention concerne des techniques de vérification de produit d'un dispositif informatique consistant à : calculer un premier indicateur en fonction d'un module logiciel avant que celui-ci ne soit stocké sur le dispositif informatique ; calculer un second indicateur en fonction du module logiciel tel qu'il est stocké sur le dispositif informatique ; et comparer le second indicateur au premier indicateur.
PCT/US2016/030136 2016-04-29 2016-04-29 Vérification de produit Ceased WO2017188995A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2016/030136 WO2017188995A1 (fr) 2016-04-29 2016-04-29 Vérification de produit

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2016/030136 WO2017188995A1 (fr) 2016-04-29 2016-04-29 Vérification de produit

Publications (1)

Publication Number Publication Date
WO2017188995A1 true WO2017188995A1 (fr) 2017-11-02

Family

ID=60159970

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/030136 Ceased WO2017188995A1 (fr) 2016-04-29 2016-04-29 Vérification de produit

Country Status (1)

Country Link
WO (1) WO2017188995A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030126504A1 (en) * 2001-09-06 2003-07-03 Fintan Ryan Method for checking a computer system configuration
US20090187772A1 (en) * 2008-01-18 2009-07-23 Microsoft Corporation Tamper evidence per device protected identity
US20110227729A1 (en) * 2010-03-18 2011-09-22 United Parcel Service Of America, Inc. Systems and methods for a secure shipping label
US20120084608A1 (en) * 2010-10-05 2012-04-05 Michael Pasternak Mechanism for Performing Verification of Template Integrity of Monitoring Templates Used for Customized Monitoring of System Activities
EP2557522A2 (fr) * 2011-08-04 2013-02-13 The Boeing Company Validation de partie logicielle utilisant des valeurs de hachage

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030126504A1 (en) * 2001-09-06 2003-07-03 Fintan Ryan Method for checking a computer system configuration
US20090187772A1 (en) * 2008-01-18 2009-07-23 Microsoft Corporation Tamper evidence per device protected identity
US20110227729A1 (en) * 2010-03-18 2011-09-22 United Parcel Service Of America, Inc. Systems and methods for a secure shipping label
US20120084608A1 (en) * 2010-10-05 2012-04-05 Michael Pasternak Mechanism for Performing Verification of Template Integrity of Monitoring Templates Used for Customized Monitoring of System Activities
EP2557522A2 (fr) * 2011-08-04 2013-02-13 The Boeing Company Validation de partie logicielle utilisant des valeurs de hachage

Similar Documents

Publication Publication Date Title
US11256799B2 (en) Device lifecycle distributed ledger
US11093258B2 (en) Method for trusted booting of PLC based on measurement mechanism
US11579893B2 (en) Systems and methods for separate storage and use of system BIOS components
CN111538517B (zh) 一种服务器固件升级方法、系统及电子设备和存储介质
CN101174292B (zh) 用于可靠操作系统引导的方法
US7917762B2 (en) Secure execution environment by preventing execution of unauthorized boot loaders
TWI522838B (zh) 組配系統之技術
US11030347B2 (en) Protect computing device using hash based on power event
US9990255B2 (en) Repairing compromised system data in a non-volatile memory
US9940146B2 (en) Controlling the configuration of computer systems
CN101174291A (zh) 用于可靠操作系统引导的系统和方法
CN103793654A (zh) 服务器主动管理技术协助的安全引导
US20080222732A1 (en) Computer manufacturer and software installation detection
US20160162686A1 (en) Method for verifying integrity of dynamic code using hash background of the invention
US9858421B2 (en) Systems and methods for detecting hardware tampering of information handling system hardware
US9928367B2 (en) Runtime verification
US9659171B2 (en) Systems and methods for detecting tampering of an information handling system
US10489137B1 (en) Software verification system and methods
US10095855B2 (en) Computer system and operating method therefor
CN107077342B (zh) 固件模块运行权限
US20250061204A1 (en) Computing device quarantine action system
WO2017188995A1 (fr) Vérification de produit
US11481497B2 (en) Systems and methods for hardware attestation in an information handling system
CN115935373A (zh) 用于保护操作系统内核的方法和装置
CN118202351A (zh) 自动分析软件镜像漏洞的可利用性

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16900729

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 16900729

Country of ref document: EP

Kind code of ref document: A1