WO2020001111A1 - Procédé de vérification de signature pour le téléchargement de micrologiciel, procédé de publication de micrologiciel, terminal mobile et serveur - Google Patents

Procédé de vérification de signature pour le téléchargement de micrologiciel, procédé de publication de micrologiciel, terminal mobile et serveur Download PDF

Info

Publication number
WO2020001111A1
WO2020001111A1 PCT/CN2019/081043 CN2019081043W WO2020001111A1 WO 2020001111 A1 WO2020001111 A1 WO 2020001111A1 CN 2019081043 W CN2019081043 W CN 2019081043W WO 2020001111 A1 WO2020001111 A1 WO 2020001111A1
Authority
WO
WIPO (PCT)
Prior art keywords
firmware
sub
mobile terminal
downloaded
download
Prior art date
Application number
PCT/CN2019/081043
Other languages
English (en)
Chinese (zh)
Inventor
李泽锦
Original Assignee
百富计算机技术（深圳）有限公司
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 百富计算机技术（深圳）有限公司 filed Critical 百富计算机技术（深圳）有限公司
Publication of WO2020001111A1 publication Critical patent/WO2020001111A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]

Definitions

  • the present application belongs to the technical field of data processing, and in particular, relates to a method for checking and downloading firmware, a method for issuing firmware, a mobile terminal, and a server.
  • Firmware refers to the device "driver" stored in the device. Through the firmware, the operating system can implement the operation of a specific machine according to the standard device driver.
  • the native Android system does not verify the download of the system.img firmware package, but as security requirements become higher and higher, many devices (such as POS machines) require that each firmware download of the device must have security, so Need to add a security check function for each firmware.
  • the system.img firmware is generally signed as a whole, and then downloaded to the random storage memory (RAM) of the mobile terminal for signature verification and written into flash after the signature verification is passed.
  • RAM random storage memory
  • the system.img firmware is very large, which makes it impossible to download the system.img firmware to the random storage memory at one time, and it is not possible to write the flash after the system.img firmware is downloaded and checked. , There will be security risks in the process of downloading and checking the firmware.
  • embodiments of the present application provide a method for checking and downloading firmware, a method for issuing firmware, a mobile terminal, a server, and a computer-readable storage medium, so as to solve the problem of potential security risks in the current process of checking and downloading firmware.
  • a first aspect of the embodiments of the present application provides a method for checking and downloading firmware, which is applied to a mobile terminal.
  • the method includes:
  • a second aspect of the embodiments of the present application provides a method for publishing firmware, which is applied to a server.
  • the method for publishing includes:
  • the maximum random storage memory is smaller than the size of the firmware, splitting the firmware into at least two sub-firmwares that are not larger than the maximum random storage memory, and sending the sub-firmware to the mobile terminal;
  • a third aspect of the embodiments of the present application provides a mobile terminal including a memory, a processor, and a computer program stored in the memory and executable on the processor.
  • the processor executes the computer program, Implement the steps of the method provided by the first aspect of the embodiments of the present application.
  • a fourth aspect of the embodiments of the present application provides a server, including a memory, a processor, and a computer program stored in the memory and executable on the processor.
  • the processor is implemented when the processor executes the computer program. Steps of the method provided by the second aspect of the embodiments of the present application.
  • a fifth aspect of the embodiments of the present application provides a computer-readable storage medium.
  • the computer-readable storage medium stores a computer program, and the computer program is implemented by one or more processors to implement the first embodiment of the present application. Steps of the method provided by the aspect or steps of the method provided by the second aspect.
  • the server where the firmware is located may split the firmware into multiple sub-firmwares.
  • the mobile terminal downloads the firmware to be downloaded from the server side, it may download the sub-firmware of the firmware to be downloaded, and After the download is complete, verify and sign the currently downloaded sub-firmware. Only after the current sub-firmware has successfully verified the signature, the sub-firmware that has been successfully verified and signed will be burned; if the current sub-firmware fails to verify the signature, the current verification is prohibited The sub-firmware that failed to sign is burned, and downloading of other sub-firmwares in the firmware to be downloaded is stopped. Since the firmware to be downloaded is divided into multiple sub-firmwares, the sub-firmware can be downloaded into the random storage memory.
  • the sub-firmware after downloading a sub-firmware, the sub-firmware can be verified and signed. If the signature verification is successful, the random firmware can be downloaded. Burn the sub-firmware in the storage memory, and then continue downloading other sub-firmware, so that you can ensure that the sub-firmware is downloaded to the random storage memory first, and only after the verification is passed, the firmware is verified.
  • FIG. 1 is a schematic flowchart of an implementation method of a firmware download check and verification method according to an embodiment of the present application
  • FIG. 2 is a schematic flowchart of an implementation method of a firmware release method provided by an embodiment of the present application
  • FIG. 3 is a schematic flowchart of an implementation of another method for downloading and checking signatures of firmware provided by an embodiment of the present application
  • FIG. 4 is a schematic block diagram of a mobile terminal according to an embodiment of the present application.
  • FIG. 5 is a schematic block diagram of a server according to an embodiment of the present application.
  • FIG. 6 is a schematic block diagram of another mobile terminal according to an embodiment of the present application.
  • FIG. 7 is a schematic block diagram of another server according to an embodiment of the present application.
  • the term “if” can be construed as “when” or “once” or “in response to a determination” or “in response to a detection” depending on the context .
  • the phrase “if determined” or “if [the described condition or event] is detected” may be interpreted, depending on the context, to mean “once determined” or “in response to the determination” or “once [the condition or event described ] “Or” In response to [Description of condition or event] detected ".
  • the mobile terminal may be a mobile terminal based on the android system.
  • the PCI security requires that the Android system.img needs to be checked for download, that is, the firmware system.img is successfully checked before being allowed to be written to the flash. Then, as the android system is continuously upgraded, the system.img firmware is also constantly increasing. At this time, a problem will occur.
  • random storage memory random (access memory, RAM) is small, at this time, the system.img firmware cannot be downloaded to the RAM at one time, which means that it is not allowed to write to the flash memory after all verification is passed, only a part can be downloaded and written to the flash memory Part of it is written into the flash memory and then verified after all downloading. In this way, if the signature is illegal, but the image file has been written to the flash memory, the original system has already been destroyed at this time, so there is a security risk.
  • FIG. 1 is a schematic flowchart of an implementation method of a firmware download check and verification method provided by an embodiment of the present application, which is applied to a mobile terminal side. As shown in the figure, the method may include the following steps:
  • Step S101 Download the sub-firmware of the firmware to be downloaded from a preset server, where the sub-firmware is obtained after the firmware to be downloaded is split.
  • the server may split the firmware into multiple sub-firmwares in advance, and the size of the sub-firmware may be set.
  • the sub-firmware may be split into multiple sub-firmwares not larger than 500M.
  • the server may store these sub-firmwares in the server. In the memory, and the sub-firmware of the firmware to be downloaded is independently signed.
  • the mobile terminal downloads the firmware to be downloaded from the server, it needs to download multiple sub-firmwares after the firmware to be downloaded is split.
  • the function of splitting the firmware into multiple sub-firmwares and signing each sub-firmware can be set for the server, and the firmware can also be split into multiple sub-firmwares by offline devices (for example, a computer for developers) and signed Upload it to the server for storage. There is no restriction here.
  • step S102 after the download of each sub-firmware is completed, a verification signature is performed on the sub-firmware that is currently downloaded.
  • the download when downloading the sub-firmware of the firmware to be downloaded, the download can be performed one by one. Since the sub-firmware is independently signed, after the download of one sub-firmware is completed, the sub-firmware when the download is currently completed is verified and signed. After the verification signature is passed, other sub-firmwares of the firmware to be downloaded may continue to be downloaded.
  • step S103 if the current sub-firmware has successfully verified the signature, the sub-firmware that is currently verified and signed is burned.
  • the sub-firmware that is currently verified and signed may be burned, and the burning operation may be written into the flash memory.
  • firmware to be downloaded is divided into three sub-firmwares, namely sub-firmware A, sub-firmware B, and sub-firmware C.
  • step S104 if the current sub-firmware fails to verify the signature, the sub-firmware that currently fails to verify the signature is prohibited from burning, and downloading of other sub-firmwares in the firmware to be downloaded is stopped.
  • the current sub-firmware fails to verify the signature, it indicates that the current sub-firmware is an illegal signature.
  • the illegally signed sub-firmware may cause security risks to the system. In this case, it is necessary to prohibit the sub-firmware that fails to verify the signature.
  • Programming that is, prohibiting the sub-firmware that fails the current verification from being written to the flash memory, and stopping the download operation of other sub-firmware that is not downloaded in the firmware to be downloaded.
  • the sub-firmware can be downloaded into the random storage memory. Therefore, after downloading a sub-firmware, the sub-firmware can be verified and signed. If the signature verification is successful, the random firmware can be downloaded. Burn the sub-firmware in the storage memory, and then continue downloading other sub-firmware, so that you can ensure that the sub-firmware is downloaded to the random storage memory first, and only after the verification is passed, the firmware is verified.
  • FIG. 1 is described from the side of the mobile terminal, and the sub-firmware of the firmware to be downloaded may be split and stored in the server in advance.
  • the server may also download the firmware according to the firmware to be downloaded.
  • the random storage memory of the mobile terminal is split.
  • FIG. 2 and FIG. 3 respectively describe the embodiment of the present application from the server side and the mobile terminal side.
  • FIG. 2 is a schematic flowchart of a firmware distribution method provided by an embodiment of the present application, and is applied to a server side. As shown in the figure, the method may include the following steps:
  • Step S201 Receive a firmware download request sent by a mobile terminal, where the download request includes a maximum random storage memory of the mobile terminal.
  • the firmware stored on the server side may be a firmware package that has not been split.
  • the firmware download request sent by the mobile terminal includes the firmware to be downloaded.
  • the name of the mobile device, and the maximum random storage memory of the mobile terminal currently the maximum usable space of RAM.
  • Step S202 Determine whether the maximum random storage memory is smaller than the size of the firmware.
  • Step S203 if the maximum random storage memory is smaller than the size of the firmware, split the firmware into at least two sub-firmwares that are not larger than the maximum random storage memory, and send the sub-firmware to the Mobile terminal.
  • the maximum random storage memory is smaller than the size of the firmware, it means that the mobile terminal cannot download the firmware to be downloaded to the current usable space of the random storage space at one time, and the to-be-downloaded
  • the firmware is split into at least two sub-firmwares that are not larger than the maximum random storage memory.
  • the sub-firmware after the split includes header information, which includes: the size of the sub-firmware, the serial number of the sub-firmware, and the download address of the sub-firmware; the download address can download the offset.
  • the server may send the sub-firmware to the mobile terminal according to the serial number of the split sub-firmware. Or wait for the mobile terminal to download sequentially according to the serial number of the split sub-firmware.
  • each sub-firmware needs to be independently signed. That is, each sub-firmware is individually signed.
  • Step S204 If the maximum random storage memory is greater than or equal to the size of the firmware, send the firmware to the mobile terminal.
  • the mobile terminal can download the firmware to be downloaded to the current usable space of the random storage space at one time. At this time, the server One side does not need to split the download firmware.
  • FIG. 3 is a schematic flowchart of a method for verifying firmware download provided by an embodiment of the present application, and is applied to a mobile terminal side. As shown in the figure, the method may include the following steps:
  • Step S301 Send the download request of the firmware to be downloaded to a preset server, where the download request includes: a maximum random storage memory supported by the mobile terminal.
  • a mobile terminal when a mobile terminal needs to download firmware, it first sends the download request of the firmware to be downloaded to a preset server.
  • a preset server In order to ensure that the server side splits the firmware to be downloaded into multiple sub-firmwares, each sub-firmware The sizes are smaller than the maximum capacity allowed in the random storage memory of the mobile terminal, and the maximum random storage memory supported by the mobile terminal can be sent at the same time as the download request is sent.
  • the server After the server receives the download request, it can split the firmware to be downloaded into at least two sub-firmwares, and sign each sub-firmware separately. Therefore, the download request is used to instruct the server to split the stored firmware into at least two sub-firmwares and sign each sub-firmware separately.
  • the process of splitting the sub-firmware by the server is: according to the maximum random storage memory supported by the mobile terminal, to be downloaded
  • the firmware is split into at least two sub-firmwares that are not larger than the maximum random storage memory. Therefore, the download request is further used to instruct the server to split the firmware to be downloaded into at least two sub-firmwares that are not larger than the maximum random storage memory according to the maximum random storage memory supported by the mobile terminal.
  • the sub-firmware includes header information, and the header information includes: a size of the sub-firmware, a serial number of the sub-firmware, and a download address of the sub-firmware.
  • step S302 the sub-firmware to be downloaded from the preset server is sequentially downloaded from the download address of the sub-firmware to the random storage memory of the mobile terminal according to the serial number of the sub-firmware.
  • the mobile terminal can download the split sub-firmware from the server.
  • the download process needs to be sequentially downloaded according to the serial number of the sub-firmware. For example, if the serial number is 1-5, The serial numbers of 1-5 are downloaded in order from low to high. Since the header information of each sub-firmware also includes the download address of the sub-firmware, according to the serial number of the sub-firmware, it is sequentially downloaded from the download address of the sub-firmware.
  • the sub-firmware of the firmware to be downloaded is stored in a random storage memory of the mobile terminal.
  • step S303 after the download of each sub-firmware is completed, a verification signature is performed on the sub-firmware that is currently downloaded.
  • step S304 if the current sub-firmware has successfully verified the signature, the sub-firmware that is currently verified and signed is burned.
  • step S305 if the current sub-firmware fails to verify the signature, the sub-firmware that fails the current verification and signature is prohibited from being burned, and downloading of other sub-firmwares in the firmware to be downloaded is stopped.
  • steps S303 to S305 reference may be made to the description of steps S102 to S104, and details are not described herein again.
  • FIG. 4 is a schematic block diagram of a mobile terminal according to an embodiment of the present application. For ease of description, only a part related to the embodiment of the present application is shown.
  • the mobile terminal 4 may be a software unit, a hardware unit, or a combination of software and hardware in a mobile terminal such as a mobile phone or a tablet computer, or may be integrated into the mobile terminal such as a mobile phone or tablet computer as an independent pendant.
  • the mobile terminal 4 includes:
  • a download module 41 configured to download sub-firmware to be downloaded from a preset server, where the sub-firmware is obtained after the firmware to be downloaded is split;
  • the signature verification module 42 is configured to verify and sign the currently downloaded sub-firmware after each sub-firmware download is completed;
  • the burning module 43 is configured to burn the sub-firmware whose current verification and signature is successful if the current sub-firmware has successfully verified the signature;
  • the prohibition module 44 is configured to prohibit the sub-firmware whose current verification signature fails to be burned if the current sub-firmware verification signature fails, and stop downloading other sub-firmwares in the firmware to be downloaded.
  • the sub-firmware of the firmware to be downloaded is independently signed.
  • the sub-firmware includes header information, and the header information includes: a size of the sub-firmware, a serial number of the sub-firmware, and a download address of the sub-firmware;
  • the download module 41 is further configured to:
  • the mobile terminal 4 further includes:
  • a requesting module 45 is configured to send a download request of the firmware to be downloaded to the preset server before downloading the sub-firmware of the firmware to be downloaded from a preset server, where the download request is used to instruct the server to store the firmware After the firmware is split into at least two sub-firmwares, each sub-firmware is signed separately.
  • the download request includes: a maximum random storage memory supported by the mobile terminal;
  • the download request is used to instruct the server to split the firmware to be downloaded into at least two sub-firmwares that are not larger than the maximum random storage memory according to the maximum random storage memory supported by the mobile terminal.
  • FIG. 5 is a schematic block diagram of a server provided by an embodiment of the present application. For ease of description, only a part related to the embodiment of the present application is shown.
  • the server 5 may be a software unit, a hardware unit, or a combination of hardware and software, which is built into a server such as a server, or may be integrated into the server such as the server as an independent pendant.
  • the server 5 includes:
  • the receiving module 51 is configured to receive a firmware download request sent by a mobile terminal, where the download request includes a maximum random storage memory of the mobile terminal;
  • a determining module 52 configured to determine whether the maximum random storage memory is smaller than the size of the firmware
  • a splitting module 53 configured to split the firmware into at least two sub-firmwares that are not larger than the maximum random storage memory if the maximum random storage memory is smaller than the size of the firmware, and split the sub-firmware Sending to the mobile terminal;
  • a sending module 54 is configured to send the firmware to the mobile terminal if the maximum random storage memory is greater than or equal to the size of the firmware.
  • the server 5 further includes:
  • a signature module configured to sign each sub-firmware of the firmware separately before sending the sub-firmware to the mobile terminal
  • the sub-firmware includes header information, and the header information includes: a size of the sub-firmware, a serial number of the sub-firmware, and a download address of the sub-firmware.
  • FIG. 6 is a schematic block diagram of a mobile terminal according to another embodiment of the present application.
  • the mobile terminal 6 of this embodiment includes one or more processors 60, a memory 61, and a computer program 62 stored in the memory 61 and executable on the processor 60.
  • the processor 60 executes the computer program 62
  • the steps in the embodiment of the control method of each camera described above are implemented, for example, steps S101 to S104 shown in FIG.
  • the processor 60 executes the computer program 62
  • the functions of each module / unit in the above-mentioned embodiment of the mobile terminal are implemented, for example, the functions of modules 41 to 44 shown in FIG. 4.
  • the computer program 62 may be divided into one or more modules / units, and the one or more modules / units are stored in the memory 61 and executed by the processor 60 to complete This application.
  • the one or more modules / units may be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program 62 in the mobile terminal 6.
  • the computer program 62 may be divided into a download module, a signature verification module, a burning module, and a prohibition module.
  • the download module is configured to download the sub-firmware of the firmware to be downloaded from a preset server, where the sub-firmware is obtained after the firmware to be downloaded is split;
  • the signature verification module is configured to verify and sign the currently downloaded sub-firmware after each sub-firmware download is completed;
  • the burning module is used for burning the sub-firmware whose current verification and signature is successful if the current sub-firmware's verification signature is successful;
  • the forbidden module is configured to, if the current sub-firmware fails to verify and sign the signature, prohibit the sub-firmware that fails to verify the signature from being burned, and stop downloading other sub-firmwares in the firmware to be downloaded.
  • the mobile terminal includes, but is not limited to, a processor 60 and a memory 61.
  • FIG. 6 is only an example of the mobile terminal 6 and does not constitute a limitation on the mobile terminal 6. It may include more or fewer components than shown in the figure, or combine some components, or different Components, for example, the mobile terminal may further include an input device, an output device, a network access device, a bus, and the like.
  • the processor 60 may be a central processing unit (Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (Application Specific Integrated Circuits) Specific Integrated Circuit (ASIC), off-the-shelf Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • CPU Central Processing Unit
  • DSP Digital Signal Processor
  • ASIC Application Specific Integrated Circuits
  • FPGA off-the-shelf Programmable Gate Array
  • a general-purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
  • the memory 61 may be an internal storage unit of the mobile terminal 6, such as a hard disk or a memory of the mobile terminal 6.
  • the memory 61 may also be an external storage device of the mobile terminal 6, such as a plug-in hard disk, a smart media card (SMC), and a secure digital (SD) provided on the mobile terminal 6. Flash card () and so on.
  • the memory 61 may further include both an internal storage unit of the mobile terminal 6 and an external storage device.
  • the memory 61 is configured to store the computer program and other programs and data required by the mobile terminal.
  • the memory 61 may also be used to temporarily store data that has been output or is to be output.
  • FIG. 7 is a schematic block diagram of a server according to another embodiment of the present application.
  • the server 7 of this embodiment includes one or more processors 70, a memory 71, and a computer program 72 stored in the memory 71 and executable on the processor 70.
  • the processor 70 executes the computer program 72
  • the steps in the embodiment of the control method for each camera are implemented, for example, steps S201 to S204 shown in FIG.
  • the processor 70 executes the computer program 72
  • the functions of each module / unit in the foregoing server embodiment are implemented, for example, the functions of modules 51 to 54 shown in FIG. 5.
  • the computer program 72 may be divided into one or more modules / units, and the one or more modules / units are stored in the memory 71 and executed by the processor 70 to complete This application.
  • the one or more modules / units may be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program 72 in the server 7.
  • the computer program 72 may be divided into a receiving module, a determining module, a splitting module, and a sending module.
  • the receiving module is configured to receive a firmware download request sent by a mobile terminal, where the download request includes a maximum random storage memory of the mobile terminal;
  • the determining module is configured to determine whether the maximum random storage memory is smaller than the size of the firmware
  • the splitting module is configured to split the firmware into at least two sub-firmwares that are not larger than the maximum random storage memory if the maximum random storage memory is smaller than the size of the firmware, and divide the sub-firmware Sending the firmware to the mobile terminal;
  • the sending module is configured to send the firmware to the mobile terminal if the maximum random storage memory is greater than or equal to the size of the firmware.
  • the server 7 may also be similar to the mobile terminal 6 shown in FIG. 6 and may include, but is not limited to, a processor and a memory. Those skilled in the art can understand that FIG. 7 is only an example of the server, and does not constitute a limitation on the server 7. It may include more or fewer components than shown in the figure, or combine some components, or different components, such as
  • the mobile terminal may further include an input device, an output device, a network access device, a bus, and the like.
  • the disclosed mobile terminal, server, and method may be implemented in other ways.
  • the mobile terminal or server embodiments described above are only schematic.
  • the division of the modules or units is only a logical function division.
  • components can be combined or integrated into another system, or some features can be ignored or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, which may be electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objective of the solution of this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each of the units may exist separately physically, or two or more units may be integrated into one unit.
  • the above integrated unit may be implemented in the form of hardware or in the form of software functional unit.
  • the integrated module / unit When the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the method of the above embodiment, and can also be completed by a computer program instructing related hardware.
  • the computer program can be stored in a computer-readable storage medium.
  • the computer When the program is executed by a processor, the steps of the foregoing method embodiments can be implemented.
  • the computer program includes computer program code, and the computer program code may be in a source code form, an object code form, an executable file, or some intermediate form.
  • the computer-readable medium may include: any entity or device capable of carrying the computer program code, a recording medium, a U disk, a mobile hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signals, telecommunication signals, and software distribution media.
  • ROM Read-Only Memory
  • RAM Random Access Memory
  • electric carrier signals telecommunication signals
  • software distribution media any entity or device capable of carrying the computer program code
  • a recording medium a U disk, a mobile hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signals, telecommunication signals, and software distribution media.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un procédé de vérification de signature pour le téléchargement d'un micrologiciel, un procédé de publication de micrologiciel, un terminal mobile, un serveur et un support de stockage lisible par ordinateur, qui sont applicables au domaine technique du traitement de données. Le procédé de vérification de signature pour le téléchargement d'un micrologiciel consiste à : télécharger, à partir d'un serveur prédéfini, un sous-micrologiciel de micrologiciel à télécharger, ledit sous-micrologiciel étant obtenu après la division du micrologiciel à télécharger (S101) ; après que chaque sous-micrologiciel a été téléchargé, effectuer une vérification de signature sur le sous-micrologiciel qui vient d'être téléchargé (S102) ; si la vérification de signature du sous-micrologiciel actuel est réussie, graver le sous-micrologiciel actuel dont la vérification de signature est réussie (S103) ; et si la vérification de signature du sous-micrologiciel actuel n'est pas réussie, interdire la gravure du sous-micrologiciel actuel dont la vérification de signature n'est pas réussie, et arrêter le téléchargement d'autres sous-micrologiciels dans le micrologiciel à télécharger (S104). Le procédé décrit peut résoudre le problème de risques de sécurité présents dans des processus de vérification de signature actuels pour télécharger un micrologiciel.
PCT/CN2019/081043 2018-06-26 2019-04-02 Procédé de vérification de signature pour le téléchargement de micrologiciel, procédé de publication de micrologiciel, terminal mobile et serveur WO2020001111A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810671878.6A CN108920962B (zh) 2018-06-26 2018-06-26 固件下载验签方法、固件发布方法、移动终端及服务器
CN201810671878.6 2018-06-26

Publications (1)

Publication Number Publication Date
WO2020001111A1 true WO2020001111A1 (fr) 2020-01-02

Family

ID=64422617

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/081043 WO2020001111A1 (fr) 2018-06-26 2019-04-02 Procédé de vérification de signature pour le téléchargement de micrologiciel, procédé de publication de micrologiciel, terminal mobile et serveur

Country Status (2)

Country Link
CN (1) CN108920962B (fr)
WO (1) WO2020001111A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108920962B (zh) * 2018-06-26 2020-06-26 百富计算机技术（深圳）有限公司 固件下载验签方法、固件发布方法、移动终端及服务器
CN113239361A (zh) * 2021-05-06 2021-08-10 国家计算机网络与信息安全管理中心 一种固件安全检测方法、装置、设备及存储介质
CN114726884B (zh) * 2022-06-06 2022-09-27 深圳市佑荣信息科技有限公司 一种金融级文件安全存储方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103166759A (zh) * 2011-12-15 2013-06-19 通用汽车环球科技运作有限责任公司 使用诊断链路连接器（dlc）和onstar系统的用于安全固件下载的方法和装置
US20150121070A1 (en) * 2013-10-28 2015-04-30 Disney Enterprises, Inc. Firmware security
CN108108193A (zh) * 2016-11-24 2018-06-01 厦门脉视数字技术有限公司 一种安全易用的固件升级方法及系统
CN108920962A (zh) * 2018-06-26 2018-11-30 百富计算机技术（深圳）有限公司 固件下载验签方法、固件发布方法、移动终端及服务器

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101373440B (zh) * 2008-10-09 2011-12-28 飞天诚信科技股份有限公司 一种固件升级数据处理方法和装置
CN101515967B (zh) * 2009-03-18 2012-10-10 中兴通讯股份有限公司 一种终端固件空中下载装置及方法
CN101694622A (zh) * 2009-09-29 2010-04-14 中兴通讯股份有限公司 一种多设备组合装置的固件远程升级方法及系统
CN104506515A (zh) * 2014-12-17 2015-04-08 北京极科极客科技有限公司 一种固件的保护方法和保护装置
CN107194242B (zh) * 2017-03-30 2019-11-08 百富计算机技术（深圳）有限公司 固件升级方法和装置
CN108021410A (zh) * 2017-12-06 2018-05-11 九阳股份有限公司 一种智能家电设备的固件升级方法及系统
CN108196863A (zh) * 2018-01-15 2018-06-22 深圳市共进电子股份有限公司 一种固件的升级方法、装置、终端及存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103166759A (zh) * 2011-12-15 2013-06-19 通用汽车环球科技运作有限责任公司 使用诊断链路连接器（dlc）和onstar系统的用于安全固件下载的方法和装置
US20150121070A1 (en) * 2013-10-28 2015-04-30 Disney Enterprises, Inc. Firmware security
CN108108193A (zh) * 2016-11-24 2018-06-01 厦门脉视数字技术有限公司 一种安全易用的固件升级方法及系统
CN108920962A (zh) * 2018-06-26 2018-11-30 百富计算机技术（深圳）有限公司 固件下载验签方法、固件发布方法、移动终端及服务器

Also Published As

Publication number Publication date
CN108920962A (zh) 2018-11-30
CN108920962B (zh) 2020-06-26

Similar Documents

Publication Publication Date Title
US11221838B2 (en) Hot update method, operating system, terminal device, system, and computer-readable storage medium for a system process
US20150220326A1 (en) Mobile Terminal and Software Upgrade Method Thereof
CN108427649B (zh) Usb接口的接入管理方法、终端设备、系统及存储介质
US10726130B2 (en) Method and device for verifying upgrade of diagnosis connector of diagnostic equipment, and diagnosis connector
WO2020001112A1 (fr) Procédé d'application pour plateforme prenant en charge de multiples types de dispositifs, et terminal mobile
WO2020001111A1 (fr) Procédé de vérification de signature pour le téléchargement de micrologiciel, procédé de publication de micrologiciel, terminal mobile et serveur
EP2958017A1 (fr) Systèmes et procédés informatisés pour installer un logiciel amélioré sur des dispositifs électroniques
US10235048B2 (en) Data processing method and smart device
CN107844306B (zh) 应用程序的修复方法、装置、存储介质及终端
CN111694589B (zh) 升级包生成方法、装置、服务器及计算机可读存储介质
CN111125725A (zh) 一种镜像校验的加解密方法、设备及介质
TW202044022A (zh) 更新信號技術
CN107766064A (zh) 组件升级的方法及装置
CN113541966A (zh) 权限管理方法、装置、电子设备及存储介质
US20200050433A1 (en) Method for programming and terminal device
US20070288664A1 (en) Apparatus and method of securely moving security data
KR102116096B1 (ko) 다중시스템 및 이의 부팅 방법
CN112000382A (zh) 一种Linux系统启动方法、装置及可读存储介质
CN107528713B (zh) 一种数据转移sdk的升级方法及装置
US12067121B2 (en) Trusted boot method and apparatus, electronic device, and readable storage medium
WO2020088516A1 (fr) Procédé d'authentification de sécurité de micrologiciel, dispositif et terminal de paiement
US10521150B2 (en) Data processing method and device for nonvolatile memory and storage medium
CN107368337B (zh) 应用下载方法、装置及终端设备
WO2020113421A1 (fr) Procédé de montage d'un système de fichiers, dispositif terminal et support de stockage
CN107506386B (zh) 一种基于nas的数据聚合方法、装置、终端设备和存储介质

Legal Events

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

Ref document number: 19827007

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19827007

Country of ref document: EP

Kind code of ref document: A1