Remote FOTA security upgrading method for terminal equipment

Abstract

The invention provides a remote FOTA security upgrading method for terminal equipment, and relates to the technical field of Internet of Things. The method comprises the following steps: signing program files of a plurality of to-be-upgraded modules, and sequentially generating upgrading sub-packages from the program files according to a preset format; combining the sub upgrade packages to generate a total upgrade package, and uploading the total upgrade package to a cloud server; if the cloud server judges that upgrading is needed, according to basic information reported by the terminal equipment and the sub-upgrading packet header, encrypting each sub-upgrading packet body data in the total upgrading packet, generating an encrypted total upgrading packet, and issuing a URL address of the encrypted total upgrading packet to the terminal equipment; the terminal equipment decrypts the encrypted total upgrade package according to the basic information of the terminal equipment and the sub-upgrade packet header, and restores the encrypted total upgrade package into an original upgrade package of each to-be-upgraded module; and after the to-be-upgraded modules are upgraded in sequence, reporting an upgrade result of the cloud server. According to the method, one-time downloading and one-time upgrading can be achieved, and the upgrading efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Things, in particular to a terminal device remote FOTA security upgrade method. BACKGROUND

[0002] With the development of Internet of Things technology, most cars are equipped with a remote communication module to realize functions such as remote FOTA (Firmware Over-The-Air) upgrade through mobile wireless networks. In actual use, it is often necessary to add new functions to the device or repair software problems, while ensuring the safety of the upgrade, and often choosing to download the FOTA upgrade package through network encryption to complete the upgrade and update of the device software.

[0003] Since an embedded device is usually composed of multiple modules, it generally includes an MCU module and an MPU module, and even more modules, and the MPU module includes multiple subparts such as an SDK (Software Development Kit) and an APP (application program), and the upgrade often needs to be completed by different modules multiple times, which can easily cause version mismatch of multiple modules, thereby causing problems such as function failure, long upgrade period, and high risk. SUMMARY

[0004] The purpose of the present application is to provide a terminal device remote FOTA security upgrade method, which can improve the upgrade efficiency and security.

[0005] The present application provides a terminal device remote FOTA security upgrade method, which includes: S1, generating program files of multiple to-be-upgraded modules of a terminal device, and uploading each program file to an internal server; S2, signing each uploaded program file based on a preset signature algorithm, and generating sub-upgrade packages in a preset format in sequence according to each program file; S3, writing a key for verifying the signature of the sub-upgrade package into the terminal device through a PC production line encryption tool; S4, combining each sub-upgrade package to generate a total upgrade package, and uploading the total upgrade package to a cloud server; S5, starting the terminal device after power-on, and after successful dialing and registration to the network, connecting to the cloud server through encryption, and reporting basic information of the terminal device to the cloud server; S6, judging whether the terminal device needs to be upgraded according to the basic information reported by the terminal device; S7, if the cloud server judges that it is necessary to upgrade, generating an encrypted total upgrade package according to the basic information reported by the terminal device and the encryption of each sub-upgrade package body data in the total upgrade package, and delivering a URL address of the encrypted total upgrade package to the terminal device; otherwise, no upgrade is needed, and the upgrade ends; S8, the terminal device downloads the encrypted total upgrade package to an upgrade package storage area according to the URL address, and after the downloading is completed, performs integrity checking on the entire encrypted total upgrade package, reports a checking failure result to the cloud server if the checking fails, and reports a downloading success to the cloud server if the checking succeeds; S9, the terminal device decrypts the encrypted total upgrade package according to the basic information and the sub-upgrade package header, and restores it into original upgrade packages of each module to be upgraded; S10, after the decryption and restoration of each upgrade package of the module to be upgraded are completed, a device upgrade flag bit is set to 1, and upgrade preparation is started; meanwhile, the multiple program files decrypted are verified and upgraded in turn using the key written in step S3. S11, after each module to be upgraded is upgraded in turn, an upgrade result is reported to the cloud server, and the device upgrade flag bit is set to 0.

[0006] In a possible implementation manner, a field exists in the header of each sub-upgrade package to indicate whether the upgrade of the next sub-upgrade package is continued when the decryption, checking or upgrade of the sub-upgrade package fails.

[0007] In a possible implementation manner, the total upgrade package is composed of a total upgrade package header and a total upgrade package body. The total upgrade package header includes at least one of the following fields: an upgrade package structure version number, a total upgrade package header length, a total upgrade package header check code, a number of sub-upgrade packages, a total upgrade package body check code and a total upgrade package body length. The total upgrade package body includes at least one of the following fields: a sub-upgrade package header length, a sub-upgrade package header check code, a sub-upgrade package ID, a sub-upgrade package skip flag bit, a sub-upgrade package type, a sub-upgrade package signature check type, a sub-upgrade package encryption algorithm, an encryption KEY seed, a hardware version number, a current software version number, a target software version number, a sub-upgrade package body size and sub-upgrade package body data.

[0008] In a possible implementation manner, the basic information of the terminal device includes a software version number, a hardware version number and a device serial number.

[0009] In a possible implementation manner, in step S8, the SHA algorithm or the MD5 algorithm is used for integrity checking.

[0010] In a possible implementation manner, the method further includes: If the decryption, verification or upgrade of a module fails, it is judged whether there is a field of continuing the upgrade of the next program file in the header of the upgrade package of the module, if yes, the next module is continued to upgrade, otherwise, the upgrade ends and the version is rolled back, and the upgrade failure is reported to the cloud server.

[0011] In a possible implementation, the method further includes: If a power-off restart occurs during the upgrade process, the terminal device judges that the upgrade flag bit is 1, and then reads data from the upgrade package storage area to rewrite the program.

[0012] In a possible implementation, the signature algorithm adopts an asymmetric signature algorithm or a symmetric signature algorithm.

[0013] Compared with the prior art, the terminal device remote FOTA secure upgrade method provided by the application combines each sub-upgrade package to generate a total upgrade package, and the terminal device performs multiple module upgrades based on the total upgrade package, so that "one-time download and one-time upgrade" can be achieved, the problem of too long time and complex logic caused by multiple upgrades of different modules is solved, and the uncertainty problem caused by possible mismatch of multiple module versions is solved, the upgrade security is met, and the upgrade efficiency is improved. BRIEF DESCRIPTION OF DRAWINGS

[0014] Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The accompanying drawings are included to provide a description of the preferred embodiments and are not intended to limit the scope of the present application. Moreover, the same reference numerals are used throughout the same figures. In the drawings: Figure 1 A flowchart of a terminal device remote FOTA secure upgrade method provided by an embodiment of the application is shown; Figure 2 A flowchart of a terminal device "one-time download and one-time upgrade" secure FOTA upgrade provided by an embodiment of the application is shown; Figure 3 A schematic diagram of an electronic device provided by an embodiment of the application is shown. DETAILED DESCRIPTION

[0015] Exemplary embodiments of the present disclosure will be described in greater detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that the present disclosure can be more thoroughly understood and the scope of the present disclosure can be accurately conveyed to those skilled in the art.

[0016] It should be noted that the technical terms or scientific terms used in the present application should be the general meanings understood by the skilled in the art, unless otherwise specified.

[0017] In addition, the terms "first" and "second" and the like are used to distinguish different objects, rather than to describe a particular order. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device including a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed or optionally further includes other steps or units inherent to such processes, methods, products or devices.

[0018] Reference is made to Figure 1 , Figure 1 is a flowchart of a terminal device remote FOTA security upgrade method provided by an embodiment of the present application, comprising the following steps: S1, generating program files of a plurality of to-be-upgraded modules of a terminal device, and uploading each of the program files to an internal server; The developer compiles bin program files of the to-be-upgraded modules on the corresponding embedded development platform, the to-be-upgraded modules including MCU, MPU-SDK, MPU-APP, etc., and uploads the generated bin program files to the internal server.

[0019] The internal server refers to an internal LAN server, and the embedded development platform is in the internal LAN.

[0020] S2, the internal server signs each of the uploaded program files based on a preset signature algorithm, and generates sub-upgrade packages in sequence according to a preset format. Each of the sub-upgrade packages has a field in the package header indicating whether to continue the upgrade of the next sub-upgrade package when the sub-upgrade package fails in decryption, verification or upgrade.

[0021] The signature algorithm uses an asymmetric signature algorithm (such as RSA / ECDSA, etc.) or a symmetric signature algorithm (such as CMAC / HMAC, etc.).

[0022] In order to ensure the integrity, authenticity and security of the upgrade package, the upgrade package needs to be signed. If an asymmetric signature algorithm is selected, an asymmetric public key and a private key pair RSA4096 is generated by the internal server, and the private key is encrypted and stored in the internal server. The internal server uses the private key to sign the firmware program bin file of the uploaded upgrade package file to generate a bin1 file. The bin1 file is a total upgrade package composed of multiple sub-upgrade packages, including a total upgrade package header, a sub-upgrade package header (such as sub-upgrade package length, a value signed by a private key or a symmetric key signature, etc.) and a sub-upgrade package body (program).

[0023] If a symmetric signature algorithm is selected, a symmetric key CMAC-AES-128 is randomly generated by the development platform and stored in the internal server. The internal server uses the symmetric key to sign the firmware program bin file of the uploaded upgrade package file to generate a bin1 file. At the same time, the file header structure data of the corresponding signature algorithm is added to the header of the entire upgrade package. Each module can use an asymmetric signature algorithm or a symmetric signature algorithm, which are independent of each other.

[0024] S3, the key for verifying the signature of the sub-upgrade package is written into the terminal device through the PC production line encryption tool; S4, the internal server combines each of the sub-upgrade packages to generate a total upgrade package, and uploads the total upgrade package to a cloud server; Specifically, the total upgrade package bin1 file with the signature and the added upgrade package header attribute is uploaded to the cloud server TSP.

[0025] As shown in Table 1, the total upgrade package is composed of a total upgrade package header and a total upgrade package body. As shown in Table 1, the total upgrade package header is composed of a plurality of fields such as "upgrade package structure version number", "total upgrade package header length", "total upgrade package header check code", "number of sub-upgrade packages", "total upgrade package body check code" and "total upgrade package body length".

[0026] The default value of "upgrade package structure version number" is 0xAA55. When the subsequent upgrade package body needs to be changed, the corresponding structure can be adapted and expanded by modifying this field.

[0027] The "total upgrade package header length" is the length of the combined total upgrade package header part. This field can be used for subsequent new header attribute extension and compatibility according to the length.

[0028] The "total upgrade package header check code" is the check code of the subsequent total upgrade package header (not included), which uses CRC16 check. The "number of upgrade packages" is the total number of the plurality of sub-upgrade packages to be upgraded, that is, the number of program files of the plurality of modules.

[0029] The "total upgrade package body check code" is a check code of original data of the upgrade package body, and the SHA256 check integrity algorithm is currently used.

[0030] The "total upgrade package length" is the total length (after encryption) of the total upgrade package body.

[0031] As shown in Table 1, the total upgrade package body is composed of a "sub-upgrade package header length", a "sub-upgrade package header check code", a "sub-upgrade package ID", a "sub-upgrade package skip flag", a "sub-upgrade package type", a "sub-upgrade package signature check type", a "sub-upgrade package encryption algorithm", an "encryption KEY seed", a "hardware version number", a "current software version number", a "target software version number", a "sub-upgrade package body size", and a "sub-upgrade package body data", and the like.

[0032] The "sub-upgrade package header length" is the length of the sub-upgrade package header part, and this field can be used for subsequent extension and compatibility of the added header attribute according to the length.

[0033] The "sub-upgrade package header check code" is a check value of the sub-upgrade package header.

[0034] The "sub-upgrade package ID" starts from 0 to the total number of sub-upgrade packages - 1.

[0035] The "sub-upgrade package skip flag" is used to determine whether there is a dependency on other modules when the current sub-upgrade package processing is abnormal. If there is no dependency, the value can be set to 0 by choosing to skip, and if there is a dependency, the value must be 1. That is, during the upgrade process of the module, if the decryption, check, or upgrade of the sub-upgrade package fails, the "sub-upgrade package skip flag" field in the sub-upgrade package header is judged. If the value of this field is 1, it indicates that there is no dependency relationship between multiple modules, and the sub-upgrade package is skipped to continue upgrading the next sub-upgrade package. If the corresponding field is 0, the upgrade needs to be ended and the version needs to be rolled back, and the upgrade failure needs to be reported.

[0036] The "sub-upgrade package type" refers to the program package type of multiple modules, such as MPU-APP whole package, MPU-APP difference, MPU-SDK whole package, MPU-SDK difference, MCU upgrade package, MPU-APP and SDK combination type, and the like.

[0037] The "sub-upgrade package body signature check type" indicates that the upgrade package body data is signed / verified using the RSA4096 public key or using the CMAC-AES-128 method.

[0038] The "sub-upgrade package body encryption algorithm" indicates that the encryption algorithm used by the upgrade package is AES128 or AES256, and the like.

[0039] The "encryption KEY seed" is randomly generated by the cloud server and used for generating an upgrade package body encryption key. The cloud server uses the device version number, device SN and the encryption KEY seed to generate an AES symmetric key, and then uses the key to encrypt the sub-upgrade package body and writes the unique KEY seed in the sub-upgrade package header. The terminal receives the upgrade package and also acquires the encryption KEY seed, and uses the same method to generate a symmetric key to decrypt the sub-upgrade package body data, ensuring that the device has one key.

[0040] The "hardware version number" is the hardware version number of the module.

[0041] The "current software version number" is the software version number (after encryption) of the module, which is used for comparing version numbers and differential upgrading as a basic version number. The version number rule is consistent with the terminal device rule, and the version number is encrypted for information security.

[0042] The "target software version number" is the target version number (after encryption) of the module, which is mainly used for differential upgrading. The version number rule is consistent with the terminal device rule, and the version number is encrypted for information security.

[0043] The "sub-upgrade package body data length" refers to the data length of the sub-upgrade package body. The actual upgrade package sent to the terminal is the encrypted sub-upgrade package body length.

[0044] The "sub-upgrade package body data" is encrypted data generated by using the device basic information (version number, SN) and the encryption KEY seed.

[0045]

[0046] Table 1 S5, the terminal device is powered on and starts, and after dialing successfully registers to the network, it is connected to the cloud server through encryption, and the basic information of the terminal device is reported to the cloud server; Specifically, the device is powered on and starts, and after dialing successfully registers to the network, it is connected to the cloud server TSP through TLS1.2, and the basic information of the device is reported to the cloud server TSP. The TLS (Transport Layer Security, Transport Layer Security) is used to establish an encrypted connection with the Internet of Vehicles cloud server to ensure the confidentiality, integrity and identity legality of vehicle data in the transmission process.

[0047] The basic information of the terminal device includes: software version number, hardware version number and device serial number (SN).

[0048] S6, the cloud server judges whether the terminal device needs to be upgraded according to the basic information reported by the terminal device; Specifically, from the perspective of information security, the cloud server TSP judges the version number reported by the device, and only when the version number is lower than the version number of the upgrade package to be upgraded, the upgrade task can be issued.

[0049] S7, if the cloud server judges that the upgrade is needed, the basic information reported by the terminal device and the encryption of each sub-upgrade package body data in the total upgrade package are used to generate an encrypted total upgrade package, and the URL address of the encrypted total upgrade package is issued to the terminal device; otherwise, no upgrade is needed, and the upgrade ends. Specifically, if the cloud server judges that the upgrade is needed, the upgrade package body is encrypted using the symmetric key generated according to the basic information reported by the device and the "encryption KEY seed", a bin2 file is regenerated, the size of the encrypted sub-upgrade package is calculated, and the "sub-upgrade package size" field in the header of each sub-upgrade package is modified, i.e. the length of the encrypted sub-upgrade package data. The "total upgrade package body length" is also modified, i.e. the length of all combined upgrade packages after encryption. After the modification is completed, the URL address of the bin2 file is issued to the terminal.

[0050] S8, the terminal device downloads the encrypted total upgrade package to the upgrade package storage area according to the URL address, and after the download is completed, the entire encrypted total upgrade package is first subjected to integrity check, if the check fails, the check failure result is reported to the cloud server, and if the check succeeds, the download success is reported to the cloud server. Specifically, SHA algorithm or MD5 algorithm can be used for integrity check.

[0051] Specifically, the terminal device downloads the upgrade package bin2 to the upgrade package storage area, and after the download is completed, the entire upgrade package bin2 is first subjected to integrity check (SHA / MD5, etc.), if the check fails, the check failure result is reported to the cloud server, and if the check succeeds, the download success is reported to the cloud server.

[0052] S9, the terminal device decrypts the encrypted total upgrade package according to its basic information and the sub-upgrade package header to restore the original upgrade package of each module to be upgraded. Specifically, the terminal device generates an AES-128 symmetric key using the internal basic information (software and hardware version number, device SN, etc.) and the "encryption KEY seed" in the sub-upgrade package header, so that the key is consistent with the key encrypted by the cloud server, and the same AES-128 key is used to decrypt the upgrade package bin2 to restore each original upgrade package bin file.

[0053] In this step, the terminal device uses the internal basic information and the "encryption KEY seed" in the sub-upgrade package header to generate a symmetric key. In this way, the SN of each terminal device and the "encryption KEY seed" of its corresponding module upgrade package are different, and the encryption key of each device is completely inconsistent. The generated unique symmetric key (one machine one key) is used to decrypt the upgrade package bin2 to restore the original upgrade package of each module.

[0054] S10, after completing the decryption and restoration of each module upgrade package to be upgraded, the device upgrade flag bit is set to 1, and the upgrade preparation is started; at the same time, the decrypted multiple program files are sequentially subjected to each program file signature verification and upgrade using the key written in step S3. Specifically, after completing the decryption and restoration of each sub-upgrade package in step S9, the device upgrade flag bit is 1, and the upgrade preparation is started. At the same time, the multiple program files in the entire combined upgrade package body are sequentially subjected to single upgrade program file signature verification (using the signature verification key written in step S3) and upgrade. In this way, "one download, one upgrade" is achieved, and all modules that need to be upgraded in the terminal device can be completed, avoiding the problem of long upgrade time or version mismatch causing other problems, and improving the upgrade efficiency.

[0055] S11, after the upgrade of each module to be upgraded is sequentially completed, the upgrade result is reported to the cloud server, and the device upgrade flag bit is set to 0.

[0056] In some embodiments, the above terminal device remote FOTA secure upgrade method provided by the application further includes the step of: if the decryption, verification, or upgrade of a module fails, determining whether there is a field for continuing the upgrade of the next program file in the upgrade package header of the module, if there is, continuing to upgrade the next module; otherwise, ending the upgrade and rolling back the version, and reporting the upgrade failure to the cloud server.

[0057] Specifically, if the decryption, verification, or upgrade of a module fails during the upgrade, the "sub-upgrade package skip flag bit" field in the header of the bin2 file is determined. If the corresponding field is 1, it indicates that there is no dependency between multiple files, and the upgrade is continued. If the corresponding field is 0, the upgrade is ended and the version is rolled back, and the upgrade failure is reported.

[0058] In some embodiments, the above terminal device remote FOTA secure upgrade method provided by the application further includes the step of: if a power failure restart occurs during the upgrade, the terminal device determines that the upgrade flag bit is 1, and then reads the data from the upgrade package storage area and flashes the program again.

[0059] As described above, the upgrade package is signed by using a signature algorithm during the whole FOTA upgrade process, the signature key is stored in the device in an encrypted manner to ensure the security of the key, and the downloaded upgrade package generates an AES128 symmetric key according to the basic information (SN+version number) of different devices and the KEY seed, so as to encrypt the upgrade package in a one-device-one-key manner, improve the difficulty of cracking the upgrade package, and increase the security of the upgrade package.

[0060] Therefore, by using the application, "one-time download and one-time upgrade" can be achieved, all modules that need to be upgraded in the terminal device can be completed, the problem of long upgrade time or other problems caused by version mismatch is avoided, the upgrade efficiency is improved, and the upgrade process is also more secure by using the signature verification and one-device-one-key mode. The combined upgrade file structure is more suitable for embedded terminal devices with less resources, systems without file decompression interfaces or command lines, or bare machines.

[0061] For ease of understanding, the application also provides a flowchart of the "one-time download and one-time upgrade" secure FOTA upgrade of a terminal device as shown in Figure 2

[0062] Compared with the prior art, the terminal device remote FOTA secure upgrade method provided by the application combines each sub-upgrade package to generate a total upgrade package, the terminal device performs multiple module upgrades based on the total upgrade package, "one-time download and one-time upgrade" can be achieved, the problem of long upgrade time and complex logic caused by multiple upgrades of different modules and the uncertain problem caused by version mismatch of multiple modules is solved, the upgrade security is met, and the upgrade efficiency is improved.

[0063] The application embodiment also provides an electronic device corresponding to the method provided in the foregoing embodiments, which can be a cloud server used to perform the corresponding steps in the terminal device remote FOTA secure upgrade method.

[0064] Please refer to Figure 3 which shows a schematic diagram of an electronic device provided by some embodiments of the application. As shown in Figure 3 The electronic device 20 includes a processor 200, a memory 201, a bus 202, and a communication interface 203, the processor 200, the communication interface 203, and the memory 201 are connected through the bus 202; the memory 201 stores a computer program that can run on the processor 200, and the processor 200 executes the corresponding steps in the terminal device remote FOTA secure upgrade method provided in any one of the foregoing embodiments of the application when running the computer program.

[0065] ​The memory 201 can include a high-speed random access memory (RAM) and can also include a non-volatile memory such as at least one disk memory. The communication connection between the system network element and at least one other network element is realized through at least one communication interface 203 (which can be wired or wireless), and the Internet, a wide area network, a local network, a metropolitan area network, etc. can be used.

[0066] The bus 202 can be an ISA bus, a PCI bus, an EISA bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. The memory 201 is used to store programs, and the processor 200 executes the programs after receiving execution instructions. The terminal device remote FOTA secure upgrade method disclosed in any of the embodiments of the present application can be applied to the processor 200 or implemented by the processor 200.

[0067] The processor 200 can be an integrated circuit chip with signal processing capability. In the implementation process, each step of the above method can be completed by integrated logic circuits or instructions in the form of software in the processor 200. The processor 200 described above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a ready-to-program gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. Each method, step and logic block disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in combination with the embodiments of the present application can be directly embodied as a hardware coding processor for execution, or a combination of hardware and software modules in the coding processor for execution. The software module can be located in a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium in the art. The storage medium is located in the memory 201, and the processor 200 reads the information in the memory 201 and combines the hardware to complete the steps of the above method.

[0068] The electronic device provided by the embodiments of the present application and the terminal device remote FOTA secure upgrade method provided by the embodiments of the present application have the same beneficial effects as the methods they use, run or implement.

[0069] The embodiment of the present application further provides a computer readable storage medium corresponding to the terminal device remote FOTA security upgrade method provided by the foregoing embodiment, and a computer program (i.e., a program product) is stored on the computer readable storage medium. When the computer program is run by a processor, the terminal device remote FOTA security upgrade method provided by any of the foregoing embodiments is executed.

[0070] It should be noted that examples of the computer readable storage medium can further include, but are not limited to, a phase change memory (PRAM), a static random access memory (SRAM), a dynamic random access memory (DRAM), other types of random access memory (RAM), a read only memory (ROM), an electrically erasable programmable read only memory (EEPROM), a flash memory, or other optical or magnetic storage media, which are not listed one by one here.

[0071] The computer readable storage medium provided by the foregoing embodiment of the present application has the same beneficial effects as the method adopted, run or implemented by the application program stored in the computer readable storage medium, and is based on the same inventive concept as the terminal device remote FOTA security upgrade method provided by the embodiment of the present application.

[0072] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, but not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application, and they should be covered in the scope of the claims and the specification of the present application.

Claims

1. A terminal device remote FOTA secure upgrade method, characterized in that, The method comprises the following steps: S1, generating program files of a plurality of to-be-upgraded modules of a terminal device, and uploading each program file to an internal server; S2, signing each uploaded program file based on a preset signature algorithm, and generating sub-upgrade packages in sequence according to a preset format; S3, writing a key for verifying the sub-upgrade packages into the terminal device through a PC production line encryption tool; S4, combining each sub-upgrade package to generate a total upgrade package, and uploading the total upgrade package to a cloud server; S5, powering on the terminal device, and after dialing and successfully registering to a network, connecting to the cloud server through encryption, and reporting basic information of the terminal device to the cloud server; S6, judging whether the terminal device needs to be upgraded according to the basic information reported by the terminal device; S7, if the cloud server judges that the terminal device needs to be upgraded, encrypting each sub-upgrade package body data in the total upgrade package according to the basic information reported by the terminal device and a sub-upgrade package header, generating an encrypted total upgrade package, and sending a URL address of the encrypted total upgrade package to the terminal device; otherwise, no upgrade is needed, and the upgrade ends; S8, downloading the encrypted total upgrade package to an upgrade package storage area according to the URL address, and after the downloading is completed, performing integrity check on the entire encrypted total upgrade package, reporting a check failure result to the cloud server if the check fails, and reporting a download success to the cloud server if the check succeeds; S9, decrypting the encrypted total upgrade package according to the basic information of the terminal device and the sub-upgrade package header to restore each original upgrade package of the to-be-upgraded modules; S10, after the decryption and restoration of each to-be-upgraded module upgrade package are completed, setting a device upgrade flag bit to 1 to start upgrade preparation, and using the key written in step S3 to perform signature verification and upgrade on each program file in sequence; S11, after each to-be-upgraded module is upgraded in sequence, reporting an upgrade result to the cloud server, and setting the device upgrade flag bit to 0.

2. The method of claim 1, wherein the terminal device remote FOTA secure upgrade method is characterized by, The header of each sub-upgrade package has a field indicating whether to continue the upgrade of the next sub-upgrade package when the decryption, check or upgrade of the sub-upgrade package fails.

3. The terminal device remote FOTA security upgrade method according to claim 1, characterized in that: The total upgrade package comprises a total upgrade package header and a total upgrade package body; The total upgrade package header comprises at least one of the following fields: an upgrade package structure version number, a total upgrade package header length, a total upgrade package header check code, a number of sub-upgrade packages, a total upgrade package body check code and a total upgrade package body length; The total upgrade package body comprises at least one of the following fields: a sub-upgrade package header length, a sub-upgrade package header check code, a sub-upgrade package ID, a sub-upgrade package skip flag bit, a sub-upgrade package type, a sub-upgrade package signature check type, a sub-upgrade package encryption algorithm, an encryption KEY seed, a hardware version number, a current software version number, a target software version number, a sub-upgrade package body size and sub-upgrade package body data.

4. The method of claim 1, wherein the terminal device remote FOTA secure upgrade method is characterized by, The basic information of the terminal device comprises a software version number, a hardware version number and a device serial number.

5. The method of claim 1, wherein the terminal device remote FOTA secure upgrade method is characterized by, In step S8, the SHA algorithm or the MD5 algorithm is used for integrity check.

6. The method of claim 2, wherein the terminal device remotely FOTA security upgrade method is characterized by, The method further comprises: If the decryption, checking or upgrading of a module fails, it is judged whether there is a field for continuing the upgrading of the next program file in the upgrade package header of the module; if there is, the next module is continued to be upgraded; otherwise, the upgrading ends, the version is rolled back, and the upgrading failure is reported to the cloud server.

7. The method of claim 3, wherein the terminal device remotely FOTA security upgrade method is characterized by, The method further includes: If a power-off restart occurs during the upgrading, the terminal device judges that the upgrading flag bit is 1, and then reads data from the upgrade package storage area to rewrite the program.

8. The method of claim 1, wherein the terminal device remote FOTA secure upgrade method is characterized by, The signature algorithm adopts an asymmetric signature algorithm or a symmetric signature algorithm.

Images