WO2017188995A1 - Product verification - Google Patents

Product verification 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
Application number
PCT/US2016/030136
Other languages
French (fr)
Inventor
Sung Oh
Barry L. Goodwin
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/en
Publication of WO2017188995A1 publication Critical patent/WO2017188995A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44Program or device authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51Monitoring 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575Secure 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

In examples, techniques are disclosed for product verification of a computing device including calculating a first indicator as a function of software module prior to the software module being stored on the computing device, calculating a second indicator as a function of the software module as stored on the computing device, and comparing the second indicator to the first indicator.

Description

PRODUCT VERIFICATION
BACKGROUND
[0001] During the manufacture and/or shipping of computing devices, the software (e.g., firmware, embedded software, etc.) on the computing device 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. Unfortunately, detection of compromise of a computing device may be problematic. A need exists to improved detection of compromise of a computing device product that contains firmware and/or embedded software and has been compromised during the manufacturing process or while in route to the customer, for example. Conventional solutions to provide physical security control of product packaging such as tamper proof tape may not address the manufacturing process or logistics operations.
BRIEF DESCRIPTION OF THE DRAWINGS
[0002] Certain exemplary embodiments are described in the following detailed description and in reference to the drawings, in which:
[0003] FIG. 1 is a block diagram of system having a server for product verification in relation to a manufacturer in accordance with examples;
[0004] FIG. 2 is a block diagram of system having a server for product verification in relation to a customer site in accordance with examples;
[0005] FIG. 3 is a block diagram of a method of product verification in relation to a manufacturer in accordance with examples;
[0006] FIG. 4 is a block diagram of a method of product verification in relation to a customer site in accordance with examples; and
[0007] 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. DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS
[0008] 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"
interchangeably, and with the understanding that such will include computer readable instructions.
[0009] As for product verification of the software module, or of the computing device having the software module, 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.
[0010] The computing device having the software module (e.g., if not compromised) 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.
[0011] 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.
[0012] In sum, computing devices having firmware and/or embedded software modules may be compromised during manufacture or while in route to the customer. In response, 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
firmware/software. 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.
[0013] A particular example includes a Product Firmware Recipe
Authentication Process (PF-RAP) which may be a hash generation and verification process for firmware and embedded software on products (software, computing devices, etc.). During the manufacturing process, 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. Once the product is at the customer site, 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.
[0014] During the manufacturing process, 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. As mentioned, once the product is at the customer site, 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.
[0015] 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. In some examples, market share and revenue could be increased through reduced cyber risks product. In certain embodiments, 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.
[0016] Continuing with the particular example, some of the various interacting entities are discussed. Such entities may include: (1 ) software development organization; (2) the PF-RAP center; (3) the manufacturer; and (4) the customer, etc.
[0017] 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
development to the PF-RAP server. As indicated, 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).
[0018] 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.
[0019] With respect to the manufacturer or production, 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).
During production, 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.
[0020] As for the customer experience, the customer may receive a product from the manufacturer or factory. In particular examples, 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.
[0021] 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.
[0022] 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.
[0023] 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. As alluded to above, the software 1 12 is software module including computer readable instructions.
[0024] 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.
[0025] 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).
[0026] In examples, 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.
[0027] 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.
[0028] In examples, 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.
[0029] Moreover, 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).
Furthermore, as indicated, 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.
[0030] FIG. 2 is an exemplary system 200 having the server 102 for product verification in relation to a customer 202 site. In examples, 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.
[0031] 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. Indeed, 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.
[0032] If the third indicator does not equal the first indicator in the
comparison by the server 102, such may be an indication 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.
[0033] Lastly, with respect to FIGS. 1 and 2, as indicated, the first, second, and third indicators, may be numerical values, alphanumeric, and so on.
Indeed, 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. Moreover, the function may be a hash function. Indeed, 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.
[0034] FIG. 3 is an exemplary method 300 of product verification in relation to a manufacturer. At block 302, software (software module) is created or generated, such as by a developer or supplier. 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.
[0035] At block 304, a first indicator (e.g., numerical value, alphanumeric, hash value, etc.) as a function of the software as generated is calculated, via a processor, prior to the software being stored on the computing device. At block 306, 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.
[0036] At block 308, 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.
[0037] At block 310, 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
compromise, 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
manufacture of the computing device. In response in examples of this compromise, 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.
[0038] In certain examples, the first indicator may be a first hash value, and the second indicator may be a second hash value. Indeed, the first and second indicators may be calculated using a hash function.
[0039] Moreover, again, 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. In fact, 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.
[0040] FIG. 4 is an exemplary method 400 of product verification in relation to a customer site. In some examples, 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. At block 402, 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.
[0041] At block 404, 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.
[0042] With respect to FIGS. 3 and 4, 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. Moreover, 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.
[0043] 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.
Furthermore, 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
instructions) that directs a processor or controller in performing product verification, including product verification of software, and/or of a computing device having the software (e.g., firmware, embedded software, etc.). 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.
[0044] 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. Moreover, 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.
[0045] The second indicator is calculated as a function of the product information with the software as stored on the computing device at a
manufacturer site and prior to shipment of the computing device to a customer. Further, 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.
[0046] While the present techniques may be susceptible to various modifications and alternative forms, the exemplary examples discussed above have been shown only by way of example. It is to be understood that the technique is not intended to be limited to the particular examples disclosed herein. Indeed, the present techniques include all alternatives, modifications, and equivalents falling within the true spirit and scope of the appended claims.

Claims

CLAIMS What is claimed is:
1 . A method of product verification, comprising:
generating software module for a computing device;
calculating, via a processor, a first indicator as a function of the software module as generated and prior to the software module being stored on the computing device;
calculating, via the processor, a second indicator as a function of the software module as stored on the computing device; and
comparing, via the processor, the first indicator to the second indicator.
2. The method of claim 1 , wherein the software module comprises computer readable instructions associated with firmware or embedded software, or both, wherein the first indicator is a first hash value, and wherein the second indicator is a second hash value.
3. The method of claim 1 , wherein the first indicator comprises a first indicator or is a first alphanumerical indication, wherein the second indicator comprises a second indicator or is a second alphanumeric indication, and wherein the second indicator is calculated as a function of the software module as stored on the computing device at a manufacturer site and prior to shipment of the computing device to a customer.
4. The method of claim 3, comprising:
shipping the computing device to the customer in response to the second indicator equaling the first indicator;
calculating, via the processor, a third indicator as a function of the software module as stored on the computing device as received by the customer; and
comparing, via the processor, the third indicator to the first indicator.
5. The method of claim 1 , wherein the first indicator and second indicator are calculated as a function of product information of the software module, and wherein the second indicator is calculated as a function of the product information of the software module as store on the computing device at a manufacturing site and prior to shipment to a customer.
6. The method of claim 5, wherein the product information comprises a revision version of the software module.
7. A computer system for product verification, comprising:
a processor; and
memory comprising computer readable instructions for product verification of a computing device having a software module, the computer readable instructions executable by the processor for the computer system to:
calculate a first indicator as a function of product
information of the software module prior to the software module being stored on the computing device;
calculate a second indicator as a function of the product information of the software module with the software module as stored on the computing device; and compare the second indicator to the first indicator.
8. The computer system of claim 7, wherein the computer system is a server, wherein the software module comprises computer readable instructions associated with a firmware or embedded software module of the computing device, or both, wherein the first indicator comprises a first hash value, and wherein the second indicator comprises a second hash value.
9. The computer system of claim 7, wherein the second indicator is calculated as a function of the product information with the software module as stored on the computing device at a manufacturer site and prior to shipment of the computing device to a customer.
10. The computer system of claim 9, wherein the computer readable instructions are executable by the processor for the computer system to:
calculate a third indicator as a function of the product information of the software module with the software module as stored on the computing device as received by the customer; and
compare the third indicator to the first indicator.
1 1 . The computer system of claim 7, wherein the product information comprises a software module revision of the software module.
12. A tangible, non-transitory, computer-readable medium comprising computer readable instructions for product verification, the instructions direct a processor to:
calculate a first indicator as a function of product information of software module prior to the software module being stored on a computing device;
calculate a second indicator as a function of the product information of the software module with the software module as stored on the computing device; and
compare the second indicator to the first indicator.
13. The computer-readable medium of claim 12, wherein the software module comprises computer readable instructions associated with firmware or embedded software of the computing device, or both, wherein the first indicator comprises a first hash value, and wherein the second indicator comprises a second hash value.
14. The computer-readable medium of claim 12, wherein the second indicator is calculated as a function of the product information with the software module as stored on the computing device at a manufacturer site and prior to shipment of the computing device to a customer.
15. The computer-readable medium of claim 14, wherein the instructions direct the processor to:
calculate a third indicator as a function of the product information of the software module with the software module as stored on the computing device as received by the customer; and
compare the third indicator to the first indicator.
PCT/US2016/030136 2016-04-29 2016-04-29 Product verification WO2017188995A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2016/030136 WO2017188995A1 (en) 2016-04-29 2016-04-29 Product verification

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2016/030136 WO2017188995A1 (en) 2016-04-29 2016-04-29 Product verification

Publications (1)

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

Family

ID=60159970

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/030136 WO2017188995A1 (en) 2016-04-29 2016-04-29 Product verification

Country Status (1)

Country Link
WO (1) WO2017188995A1 (en)

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 (en) * 2011-08-04 2013-02-13 The Boeing Company Software part validation using hash values

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 (en) * 2011-08-04 2013-02-13 The Boeing Company Software part validation using hash values

Similar Documents

Publication Publication Date Title
US11256799B2 (en) Device lifecycle distributed ledger
US7917762B2 (en) Secure execution environment by preventing execution of unauthorized boot loaders
CN105122214B (en) Reparation to the system data damaged in nonvolatile memory
US11579893B2 (en) Systems and methods for separate storage and use of system BIOS components
US11030347B2 (en) Protect computing device using hash based on power event
US8060812B2 (en) Methods, systems, and computer program products for class verification
CN105683910B (en) System and method for updating the system-level service in read-only system image
US9858421B2 (en) Systems and methods for detecting hardware tampering of information handling system hardware
US20080222732A1 (en) Computer manufacturer and software installation detection
US9940146B2 (en) Controlling the configuration of computer systems
US20160162686A1 (en) Method for verifying integrity of dynamic code using hash background of the invention
US20210248239A1 (en) Verification of a provisioned state of a platform
US20170053116A1 (en) Systems and methods for detecting tampering of an information handling system
US9928367B2 (en) Runtime verification
CN107077342B (en) Firmware module operation authority
US10489137B1 (en) Software verification system and methods
US10095855B2 (en) Computer system and operating method therefor
WO2017188995A1 (en) Product verification
CN115935373A (en) Method and apparatus for protecting operating system kernel
CN116842517A (en) Trusted verification method and device
CN111143887B (en) Safety control method, processor, integrated device and computer equipment
US20230297682A1 (en) Computing device quarantine action system
CN112560047B (en) Android platform firmware degradation prevention method and storage medium thereof
IE84949B1 (en) Secure electronic delivery seal for information handling system

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