WO2018090818A1

WO2018090818A1 - Version check method, apparatus and terminal device

Info

Publication number: WO2018090818A1
Application number: PCT/CN2017/108532
Authority: WO
Inventors: 陈溪; 许世峰; 钱建英
Original assignee: 华为技术有限公司
Priority date: 2016-11-15
Filing date: 2017-10-31
Publication date: 2018-05-24
Also published as: CN106650460B; CN106650460A

Abstract

A version check method, apparatus and terminal device, used for preventing an attacker from using versions having security vulnerabilities to carry out security attacks so as to improve system security. In the method, a version number of each version has a corresponding check bit, and forbidden information and available information of a version are indicated by means of the bits; when acquiring a first version, a check bit corresponding to a version number is first determined according to the version number of the version; if the check bit corresponding to the version number of the version is a first numerical value, the version is determined to be forbidden and the check has not passed; and if the check bit corresponding to the version number of the version is a second numerical value, then the version is determined to be available and the check has passed. By means of said method, a security check may be conducted on the versions, and versions which do not pass the check may not be used, thus an attacker may be prevented from using versions having security vulnerabilities to carry out security attacks.

Description

Version verification method, device and terminal device

This application claims priority to Chinese Patent Application No. 201611005776.8, filed on November 15, 2016, the entire disclosure of which is hereby incorporated by reference. In this application.

Technical field

The present invention relates to the field of computers, and in particular, to a version verification method, apparatus, and terminal device.

Background technique

System security is a set of hardware and software solutions to support secure boot and to ensure that the system runs in a trusted environment. The system security solution based on the ARM architecture is usually a combination of Secure Boot and Trust Zone technologies. SecureBoot is the basis of system security and is responsible for the initialization process of the entire security system. According to the credible integrity theory, the safe start of the system is the trusted root of the entire system security, and only the security of the system startup can ensure the security of other components of the system.

When the system is safely started, the system adopts a step-by-step authentication signature, and the subsequent process is guided after the authentication is passed. Usually the security version of the digest signature and code is stored off-chip (usually Flash), the system is first started by the on-chip Boot, after the off-chip startup code signature authentication verification is passed, switch to the off-chip startup code execution, and guide the subsequent startup program. .

If the off-chip security version has a security vulnerability, you need to upgrade. If the version of the security vulnerability is VerX, the upgrade version is VerY, and the security vulnerability exists in VerX. After the upgrade, the attacker can also roll back the version to VerX and use the vulnerability. A security attack is performed, so there is a system security risk.

Summary of the invention

The embodiment of the invention provides a version verification method, device and terminal device, which can prevent an attacker from using a version with a security vulnerability to perform a security attack and improve system security.

The embodiment of the present invention is applicable to a scenario in which a software version is verified by security. The software may be an operating system or an application on the system.

In a first aspect, an embodiment of the present invention provides a version verification method, where the method includes:

In a scenario where the operating system or the application needs to be safely started or upgraded, the processor obtains the version information of the first version, where the version information includes the version number of the first version, where the version number is used to identify the first version; The version number of a version determines a parity bit corresponding to the version number of the first version; if the parity bit corresponding to the version number of the first version is the first value, it is determined that the first version is disabled, and the first version is verified. If the verification bit corresponding to the version number of the first version is the second value, it is determined that the first version is available, and the first version is verified.

Optionally, the first version is a target version of the system or application to be started by the processor, or the second version is a target version of the system or application to be upgraded by the processor.

The version number of each version in the embodiment of the present invention has a corresponding check bit, and the bit is used to indicate the version of the version and the available information. After obtaining a version, the version can be verified by security. The verified version is unusable, so it can prevent an attacker from using a version with a security vulnerability for security attacks.

In conjunction with the first aspect, in a first possible implementation manner of the first aspect, the method further includes:

When it is confirmed that a certain version has a security vulnerability, the processor receives an indication that the second version is disabled, and the indication that the second version is disabled includes a version number of the second version; and the version number of the second version is determined according to the version number of the second version. a parity bit; the parity bit corresponding to the version number of the second version is the first value.

Therefore, the verification bit information can be updated according to the version of the security information (bugList), and the bit corresponding to the version of the security vulnerability is set to be disabled in time, thereby ensuring that the version with the security vulnerability cannot be used, preventing the attacker from using A version of the security vulnerability is used for security attacks.

With reference to the first aspect, or the first possible implementation manner of the first aspect, in the second possible implementation manner of the first aspect, the verification of the version number (including the first version number and the second version number) The bits are stored in a first field of the electronic fuse metal fuse eFuse, each bit in the first field being used to indicate whether a version is disabled.

Optionally, the first value of the parity bit is 1, and the second value of the second parity bit is 0.

Optionally, the first field may be an NV_BITMAP_E field in the eFuse. When a bit in the field is 1, the version number corresponding to the bit is disabled. When a bit in the field is 0, When it is, it indicates that the version number corresponding to the bit is available.

In this way, eFuse's one-time fusing feature can be utilized. If a version has a security hole, the corresponding bit of the version is set to 1 and then it can no longer be rolled back to the version, thus ensuring the version is started or upgraded. safety.

With reference to the first aspect or the first possible implementation manner of the first aspect, in a third possible implementation manner of the first aspect, the verification bit corresponding to the version number (including the first version number and the second version number) The bits are stored in the second field of the Flash Flash, and each bit in the second field is used to indicate whether a version is disabled.

Optionally, in a possible implementation, the first value of the parity bit is 1, and the second value of the second parity bit is 0.

Optionally, in another possible implementation, the first value of the parity bit is 0, and the second value of the second parity bit is 1.

If stored in this way, the stored content needs to be protected by the secret key, and the verification bit is allowed to be updated after the signature is authenticated.

With reference to any possible implementation of the first aspect, in a fourth possible implementation manner of the first aspect, the method further includes: performing signature verification on the version information of the first version; The step of determining the parity bit corresponding to the version number of the first version according to the version number of the first version is performed. To prevent the version from being tampered with, you can perform security check on the version at the time of startup or upgrade to improve security.

With reference to any possible implementation of the first aspect, in a fifth possible implementation manner of the first aspect, the embodiment of the present invention may be applied to verifying the version when the version is upgraded, and obtaining the first The version information includes: receiving the first version upgrade indication, and obtaining the version information of the first version according to the upgrade instruction; the method further includes: if the verification fails, the upgrade is not performed to the first version; if the verification is passed, the upgrade is performed. To the first version.

Optionally, receiving the first version upgrade indication may be: receiving an indication of upgrading the operating system version, or receiving an indication of upgrading the application version.

With reference to any possible implementation of the first aspect, in a sixth possible implementation manner of the first aspect, the embodiment of the present invention may be applied to verifying the version when the version is upgraded, and obtaining the first Version version information package And receiving the startup instruction of the first version, and obtaining the version information of the first version according to the startup instruction; the method further includes: when the first version verification fails, the first version is not started; when the first version is verified When the first version is started.

Optionally, receiving the startup indication for starting the first version may be: receiving an indication to start an operating system version, or receiving an indication to start an application version.

In a second aspect, an embodiment of the present invention provides a version verification apparatus, which specifically implements a function corresponding to the version verification method provided by the foregoing first aspect. The functions may be implemented by hardware or by executing corresponding software programs through hardware. The hardware and software include one or more unit modules corresponding to the functions described above, which may be software and/or hardware.

In a possible design, the device comprises:

a version information obtaining module, configured to obtain version information of the first version, the version information includes a version number of the first version, and a version verification module, configured to determine, according to the version number of the first version, a version corresponding to the version number of the first version If the check bit corresponding to the version number of the first version is the first value, it is determined that the first version is disabled, the first version check fails, and the check bit corresponding to the version number of the first version The bit is the second value, it is determined that the first version is available, and the first version is verified.

In conjunction with the second aspect, in a first possible implementation of the second aspect, the apparatus further includes:

a receiving module, configured to receive an indication that the second version is disabled, and a version number of the second version is included in the indication of disabling the second version; a parity bit updating module, configured to determine a version number of the second version according to the version number of the second version Corresponding check bits, the check bit position corresponding to the version number of the second version is the first value.

With reference to any possible implementation of the second aspect, in a second possible implementation manner of the second aspect, the verification bit corresponding to the version number of the first version is stored in the first part of the electronic fuse metal fuse eFuse In the field, each bit in the first field is used to indicate whether a version is disabled.

With reference to any possible implementation of the second aspect, in a third possible implementation manner of the second aspect, the verification bit corresponding to the version number of the first version is stored in the second field of the flash memory, Each bit in the two fields is used to indicate whether a version is disabled.

With reference to any possible implementation of the second aspect, in a fourth possible implementation of the second aspect, the apparatus further includes: a signature authentication module, configured to perform signature verification on the version information of the first version, when When the signature authentication is passed, the version verification module performs the step of determining the parity bit corresponding to the version number of the first version according to the version number of the first version.

With reference to any possible implementation of the second aspect, in a fifth possible implementation manner of the second aspect, the version information obtaining module is configured to receive an upgrade indication, and obtain version information of the first version according to the upgrade indication. The device further includes: an upgrade module, configured to not upgrade to the first version when the verification fails, and upgrade to the first version if the verification passes.

With reference to any possible implementation of the second aspect, in a second possible implementation manner of the second aspect, the version information acquiring module is configured to receive a startup indication for starting the first version, and obtain the first according to the startup indication. Version version information; the device further includes: a security startup module, configured to not start the first version when the first version verification fails, and start the first version when the first version verification passes.

In a third aspect, an embodiment of the present invention further provides a chip for executing program code to perform all or part of the steps of the version verification method of the first aspect.

Optionally, the chip comprises an electronic fuse metal fuse eFuse, wherein the eFuse stores a version check bit, and each bit is used to indicate whether a version is disabled.

Optionally, the chip is a system level chip SOC.

In a fourth aspect, an embodiment of the present invention further provides a terminal device, where the terminal device includes: a transceiver, a processor, and a memory connected to each other; the memory is configured to store the program code, and the processor calls the program code in the memory to execute All or part of the steps in the first aspect:

Obtaining version information of the first version, the version information includes a version number of the first version; determining a parity bit corresponding to the version number of the first version according to the version number of the first version; and verifying the version number corresponding to the version of the first version If the bit is the first value, it is determined that the first version is disabled, the first version verification is not passed; if the verification bit corresponding to the version number of the first version is the second value, determining that the first version is available, first The version verification passed.

In a fifth aspect, the embodiment of the present invention further provides a computer storage medium, where the medium stores an application program, and the program includes some or all of the steps in the version verification method of the first aspect.

It can be seen from the above technical solutions that the embodiments of the present invention have the following advantages:

In the embodiment of the present invention, the version number of each version has a corresponding check bit, and the bit is used to indicate the version disable and available information. When a version (first version) is obtained, the version number of the version is first obtained. Determining a parity bit corresponding to the version number. If the parity bit corresponding to the version number of the version is the first value, determining that the version is disabled, the verification fails, and if the version number of the version corresponds to the verification If the bit is the second value, it is determined that the version is available and the check is passed. According to the embodiment of the present invention, after obtaining a certain version, the version can be verified by security, and the version that has not been verified cannot be used, thereby preventing an attacker from using a version with a security vulnerability for security attacks.

DRAWINGS

1 is a schematic diagram of a signature verification process related to system security startup in an embodiment of the present invention;

2 is a flowchart of a version verification method according to an embodiment of the present invention;

FIG. 3 is a schematic diagram of performing verification by using eFuse to store version verification information according to an embodiment of the present invention; FIG.

4 is another flowchart of a version verification method according to an embodiment of the present invention;

FIG. 5 is a structural diagram of a function module of a version verification apparatus according to an embodiment of the present invention; FIG.

FIG. 6 is a schematic structural diagram of hardware of a terminal device according to an embodiment of the present invention.

detailed description

In order to make the technical solutions and the beneficial effects of the present invention more clear, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to The invention is defined.

In addition, the version verification method in the embodiment of the present invention is applicable to various terminal devices with a central processing unit (CPU) and an application, including a computing device, an in-vehicle device, a wearable device, and various forms. User Equipment (UE), Mobile Station (MS), Terminal, Terminal Equipment, etc.

The embodiment of the present invention is applicable to a scenario in which software can be upgraded, and a software version of the software is verified in the terminal device with multiple software versions. The software may be an operating system or an application on the system. For example: system security boot of ARM architecture, version verification of scenarios such as secure startup of an application. The embodiment of the invention is described by taking the system security startup as an example.

The version verification method in the embodiment of the present invention is described with reference to FIG. 1, and the execution body of the method is a processor (CPU).

101. Obtain version information of the first version, where the version information includes a version number of the first version;

You can obtain the versions and scenarios of the version, including the version to be upgraded when the system version needs to be upgraded. You need to obtain the version to be started when you start the system. When you install the new version, you also get the version to be installed. version of.

The first version in the embodiment of the present invention is only a specific version, and the “first” is used to distinguish similar objects, and is not used to describe a specific order or order.

When the version is upgraded, the processor receives the upgrade indication, and obtains version information of the version to be upgraded (the first version) according to the upgrade instruction.

Alternatively, when the booting is safely started, or a certain version (ie, the first version) is safely started after the upgrade, the processor receives the startup instruction for starting the version, and then obtains the version information of the version to be started according to the startup instruction.

The version information includes the version number and the program startup code of the version.

102. Determine, according to the version number of the first version, a parity bit corresponding to the version number of the first version.

After obtaining the version information of the first version, the version is security checked to determine whether the version is a usable version.

The version number of each version has a corresponding check bit, which indicates the version of the disable and available information by the check bit.

When the verification bit corresponding to a version number is the first value, indicating that the version corresponding to the version number is disabled, and when the verification bit corresponding to the version number is the second value, indicating that the version number corresponds to The version is available.

The parity bit can be stored in an electronic fuse (eFuse) or in an off-chip memory (such as Flash). When stored in off-chip memory, it needs to be protected by a key. Update.

1, stored in eFuse

In System-on-a-Chip (SOC), eFuse is an important non-volatile memory unit consisting of a fuse structure that can be programmed and stored on the chip by a fuse. The eFuse module has a one-time blown feature: the default stored bits in eFuse are 0, and the required bits can be changed from 0 to 1 by programming. Once set, it cannot be changed to 0. Using the one-time blown feature of eFuse, a first field is added to the eFuse of the SoC, and each bit in the field is used to indicate whether a version is available (ie, is disabled).

Optionally, the first field may be an NV_BITMAP_E field.

In the eFuse, the first value in the parity bit has a value of 1, and the second value in the parity bit has a value of 0, that is, a certain bit in the first field in the eFuse. When the bit is 1, it indicates that the version corresponding to the bit has been disabled. When a bit is 0, it indicates that the version corresponding to the bit is available.

As shown in Figure 2, the version information of the system off-chip boot code version is stored in Flash: version 0 (Ver0). The CPU stores an on-chip boot loader (Boot), and includes an eFuse module. The bit 0 of the version 0 in the NV_BITMAP_E field of the eFuse module is 0, indicating that version 0 is available.

Suppose there are 16 versions of the off-chip startup code and 32 bits in the NV_BITMAP_E field. The 0th to 15th bits are used to indicate whether the version 0 to the version 15 are available. The correspondence between the bit and the version number can be as shown in Figure 3. Shown. Bit 0 is 1 to indicate that version 0 (Ver0) is disabled; Bit 1 is 0 to indicate that version 1 (Ver1) is available; ... Bit 16 is 0 to indicate that version 16 (Ver16) is available.

When the version security check is performed, the check bit corresponding to the version number of the first version is determined according to the version number of the first version, and whether the version number is available according to whether the bit corresponding to the version number is 0 or 1 is used.

2, stored in off-chip memory

Taking the off-chip memory as an example of Flash, the parity bit is stored in the off-chip Flash, and a second field is added in the Flash, and each bit in the field is used to indicate whether a version is available (that is, whether it is disabled). .

Optionally, in the Flash, the first value in the parity bit is 1, and the second value in the parity bit is 0, that is, the first field in eFuse When a certain bit is 1, it indicates that the version corresponding to the bit has been disabled. When a certain bit is 0, it indicates that the version corresponding to the bit is available.

Optionally, in the Flash, the value of the first value is 0, indicating that the version corresponding to the bit has been disabled, and the value of the second value is 1, indicating that the version corresponding to the bit is available.

Further, in order to ensure security, the second field is signed with a private key, and when the security startup is verified, the second field in the Flash needs to be read, or when the second field in the Flash needs to be updated, the public key is used first. The authentication signature is allowed to read or update the parity bit if the signature authentication is passed.

The mapping relationship between the check bits in the Flash and the version number of the version of the off-chip boot code is the same as that in FIG. 2, and details are not described herein.

103. If the parity bit corresponding to the version number of the first version is the first value, it is determined that the first version is disabled, and the first version verification fails.

Obtaining that when the verification bit corresponding to the version number of the first version is the first value from the first field of the eFuse or the parity bit in the second field of the off-chip memory according to the version number of the first version, If the version is not available, that is, it is disabled, the first version verification will not pass.

If the first version is not verified when the first version is started, it indicates that there is a security problem in the version, and the version is not allowed to be started.

If the first version is not verified when you upgrade to the first version, it indicates that there is a security problem in the version, and you are not allowed to upgrade to the version.

104. If the parity bit corresponding to the version number of the first version is the second value, it is determined that the first version is available, and the first version is verified.

The parity bit in the first field of the eFuse or the second field of the off-chip memory according to the version number of the first version If the verification bit corresponding to the version number of the first version is determined to be the second value, it is known that the version is available, and the first version is verified.

If the first version is verified when the first version is started, it indicates that there is no security problem in the version, and the version is allowed to be started.

If the first version is verified when you upgrade to the first version, it means that there is no security problem in the version, and you are allowed to upgrade to the version.

The following describes the process of verifying the bit position of a version with a security problem.

When a version (the second version) has a security vulnerability, the processor receives an indication that the second version is disabled, and the disable indication includes a version number of the second version, and the processor determines the version of the second version according to the version number. The parity bit corresponding to the number is the first bit, and the bit is originally the second value. At this time, the bit position is the first value, for example, when the second value is 0 and the first value is 1. Set this bit from 0 to 1. To indicate that the second version is not available, that is, it has been disabled, subsequent upgrades are not allowed to be upgraded to the version, or the version is not allowed to be started.

An application scenario is to upgrade to a new version when a vulnerability is found in a version. At this time, in the upgrade, the verification bit position corresponding to the version number of the vulnerable version is required to be the first value, and the version to be upgraded is subjected to the version verification in the embodiment shown in FIG. 1. Optionally, the version verification in the embodiment shown in FIG. 1 is not performed during the upgrade. After the version is upgraded, when the version is started, the version in the embodiment shown in FIG. 1 is performed on the version. Version verification.

For example, the Ver1 version has a security vulnerability and Ver1 is upgraded to Ver2. If the eFuse is used to store the parity bit, after the Ver2 upgrade is started, the NV_BITMAP_E is updated, and the bit corresponding to the unusable version Ver1 is set. Then the version of Ver1 with security vulnerabilities can no longer pass the version verification. Other versions of Ver0 and Ver2 without security vulnerabilities can still pass the version verification.

In the embodiment of the present invention, the version number of each version has a corresponding check bit, and the version disable and available information is indicated by the bit. When obtaining a version, the verification bit corresponding to the version number is first determined according to the version number of the version. If the verification bit corresponding to the version number of the version is the first value, it is determined that the version is disabled. If the verification fails, the version is not allowed to be upgraded or started. If the verification bit corresponding to the version number of the version is the second value, it is determined that the version is available. If the verification is passed, the version is allowed to be upgraded or started. According to the embodiment of the present invention, after obtaining a certain version, the version can be verified by security, and the version that has not been verified cannot be used, thereby preventing an attacker from using a version with a security vulnerability for security attacks.

In addition, the verification bit information can be updated according to the version of the security information (bugList), and the bit corresponding to the version of the security vulnerability is set to be disabled in time, thereby ensuring that the version with the security vulnerability cannot be used, preventing the attacker from using A version of the security vulnerability is used for security attacks.

On the other hand, each version of the embodiment of the present invention corresponds to one parity bit. Other versions before the disabled version can be used if there is no security vulnerability. If the current version cannot be started for some reason, Start the previous version as a backup version. Therefore, the integrity of the solution can be improved.

Further, in the actual application, when a version is obtained, the version information of the version needs to be signed and authenticated. When the signature authentication is passed, the steps 102 to 104 in the embodiment shown in FIG. 1 are performed.

Referring to Figure 4, the signature authentication process is described below.

The system startup code (the startup code corresponding to a certain version of the system, System Code) needs to be signed and verified first to ensure that the system startup code has not been tampered with. FIG. 1 is a schematic diagram of a signature verification process related to system security startup. The schematic diagram shown in FIG. 1 uses an eFuse module to store keys and other security-related content.

The principle of signature authentication may be: using a RSA asymmetric encryption algorithm, using a private key signature, and a public key authentication signature authentication mechanism to construct a securely initiated trust chain.

The chip vendor randomly generates an asymmetric key pair, and burns the public key hash value and the private key index into Efuse. The public key is written to the specified location of the flash, and the device vendor uses a one-way hash function: a hash function pair. The system startup code generates a message digest, and then encrypts the message digest using the Efuse private key, that is, digital signature. The signed message digest is put together with the system startup code and written to the off-chip memory. The off-chip memory is usually FLASH, for example, The non-Volatile Random Access Memory (NVRAM) is shown in FIG. 4. The public-private key pair is generated internally by the chip, is invisible to the programming and verification process, and is not backed up.

When booting securely, the system is started by the on-chip Boot. The on-chip Boot ROM contains the minimum system initialization and signature authentication security check procedure. The Hash value is generated for the public key in Flash and the trusted public key root of Efuse (Root Of Trust). Public Key, ROTPK) The trusted public key root is the SHA256 Hash value of the EK public key (N, e) used for secure boot to ensure that the public key used for the verification signature is uniquely specified. If passed, the Hash digest value is generated for the off-chip system startup code, and the original Hash digest value is obtained by using the public key authentication signature. After verifying the two digest values, it is known whether the system startup code has been tampered with, whether it is expected or not. Authorized code. After the off-chip system startup code signature authentication verification is passed, switch to the off-chip system startup code execution to guide the subsequent startup program.

Therefore, when the system performs a secure startup, the system startup code needs to be signed and authenticated. After the signature authentication is passed, it is confirmed that the system startup code has not been tampered with, and then the version verification in the embodiment shown in FIG. 1 is performed to determine the version. Whether the system startup code is available or not, is allowed to start when the version is available. This makes it possible to ensure the security at the start of the program.

The above is a description of the version verification method in the embodiment of the present invention. The version verification apparatus in the embodiment of the present invention is described below.

With reference to FIG. 5, the version verification apparatus in the embodiment of the present invention includes:

The version information obtaining module 501 is configured to obtain version information of the first version, where the version information includes a version number of the first version;

The version verification module 502 is configured to determine, according to the version number of the first version, a parity bit corresponding to the version number of the first version, and if the verification bit corresponding to the version number of the first version is the first value, determine the first A version is disabled, the first version check fails, and if the check bit corresponding to the version number of the first version is the second value, it is determined that the first version is available, and the first version is verified.

In some specific implementations, the apparatus further includes:

The receiving module 503 is configured to receive an indication that the second version is disabled, and the version that disables the second version includes a version number of the second version. The check digit update module 504 is configured to determine the second version according to the version number of the second version. The parity bit corresponding to the version number, and the parity bit corresponding to the version number of the second version is the first value.

In some implementations, the verification bit corresponding to the version number is stored in a first field of the electronic fuse metal fuse eFuse, and each bit in the first field is used to indicate whether a version is disabled.

In some implementations, the verification bit corresponding to the version number is stored in a second field of the flash memory, and each bit in the second field is used to indicate whether a version is disabled.

In some implementations, the device further includes: a signature authentication module 505, configured to perform signature verification on the version information of the first version, and when the signature authentication is passed, the version verification module 502 executes the version number according to the first version. The step of determining the parity bit corresponding to the version number of the first version.

In some implementations, the version information obtaining module 501 is configured to receive an upgrade indication, and obtain version information of the first version according to the upgrade instruction. The device further includes: an upgrade module 506, configured to: when the verification fails, Upgrade to the first version; if the verification passes, upgrade to the first version.

In some specific implementations, the version information obtaining module 501 is configured to receive a startup indication for starting the first version, and obtain version information of the first version according to the startup indication. The device further includes: a security startup module 507, configured to be used by When the version verification fails, the first version is not started. When the first version is verified, the first version is started.

For the information exchange between the modules in the above-mentioned version verification device, refer to the description in the embodiment of the above-mentioned version verification method (the embodiment corresponding to FIG. 1 to FIG. 4), and details are not described herein again.

Optionally, the functions implemented in the foregoing version verification method may be implemented by an application-specific integrated circuit (ASIC: ASIC) or a programmable logic device (English: programmable logic device, PLD for short). . The PLD may be a complex programmable logic device (CPLD), an FPGA, a general array logic (GAL), or any combination thereof.

In addition, an embodiment of the present invention further provides a chip for executing program code to perform all or part of the steps of the foregoing version verification method embodiment.

The chip includes an electronic fuse metal fuse eFuse in which a version check bit is stored, each bit being used to indicate whether a version is disabled.

In addition, the embodiment of the present invention further provides a terminal device, which may exist in the form of a user equipment (for example, a mobile phone). The terminal device may also include a handheld device, an in-vehicle device, a wearable device, a computing device, and various forms of user devices. The handheld device can be any terminal device including a mobile phone, a tablet computer, a PDA (Personal Digital Assistant), and the like.

The terminal device in the embodiment of the present invention will be described below by taking a mobile phone as an example.

FIG. 6 is a block diagram showing a partial structure of a mobile phone related to a user equipment provided by an embodiment of the present invention. Referring to FIG. 6, the mobile phone includes: a radio frequency (RF) circuit 610, a memory 620, an input unit 630, a display unit 640, a sensor 650, an audio circuit 660, a wireless fidelity (WiFi) module 670, and a processor 680. And power supply 690 and other components. The radio frequency circuit 610 and the WiFi module 670 are transceivers. It will be understood by those skilled in the art that the structure of the handset shown in FIG. 6 does not constitute a limitation to the handset, and may include more or less components than those illustrated, or some components may be combined, or different components may be arranged.

The following describes the components of the mobile phone in detail with reference to FIG. 6:

The memory 620 can be used to store software programs and modules, and the processor 680 executes various functional applications and data processing of the mobile phone by running software programs and modules stored in the memory 620. The memory 620 can mainly include a storage program area and a storage data area, wherein the storage program area can store an operating system, an application required for at least one function. Programs (such as sound playback function, image playback function, etc.); the storage data area can store data (such as audio data, phone book, etc.) created according to the use of the mobile phone. Moreover, memory 620 can include high speed random access memory, and can also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.

Specifically, the application stored in the memory 620 includes some or all of the steps in the methods corresponding to the foregoing FIG. 1 to FIG. 4 when executed. The memory 620 stores information such as the version number information, the program startup code corresponding to the version, and the like.

The input unit 630 can be configured to receive input numeric or character information and to generate key signal inputs related to user settings and function controls of the handset. Specifically, the input unit 630 may include a touch panel 631 and other input devices 632. The touch panel 631, also referred to as a touch screen, can collect touch operations on or near the user (such as the user using a finger, a stylus, or the like on the touch panel 631 or near the touch panel 631. Operation), and drive the corresponding connecting device according to a preset program. Optionally, the touch panel 631 can include two parts: a touch detection device and a touch controller. Wherein, the touch detection device detects the touch orientation of the user, and detects a signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts the touch information into contact coordinates, and sends the touch information. The processor 680 is provided and can receive commands from the processor 680 and execute them. In addition, the touch panel 631 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic waves. In addition to the touch panel 631, the input unit 630 may also include other input devices 632. In particular, other input devices 632 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control buttons, switch buttons, etc.), trackballs, mice, joysticks, and the like.

The display unit 640 can be used to display information input by the user or information provided to the user. The display unit 640 can include a display panel 641. Alternatively, the display panel 641 can be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like. Further, the touch panel 631 can cover the display panel 641. When the touch panel 631 detects a touch operation on or near it, the touch panel 631 transmits to the processor 680 to determine the type of the touch event, and then the processor 680 according to the touch event. The type provides a corresponding visual output on display panel 641. Although in FIG. 6, the touch panel 631 and the display panel 641 are two independent components to implement the input and input functions of the mobile phone, in some embodiments, the touch panel 631 may be integrated with the display panel 641. Realize the input and output functions of the phone.

The processor 680 is the control center of the handset, and connects various portions of the entire handset using various interfaces and lines, by executing or executing software programs and/or modules stored in the memory 620, and invoking data stored in the memory 620, executing The phone's various functions and processing data, so that the overall monitoring of the phone. Optionally, the processor 680 may include one or more processing units; preferably, the processor 680 may integrate an application processor and a modem processor, where the application processor mainly processes an operating system, a user interface, an application, and the like. The modem processor primarily handles wireless communications. It will be appreciated that the above described modem processor may also not be integrated into the processor 680.

Specifically, the processor 680 in the embodiment of the present invention is configured to execute an application in the memory 620 to perform some or all of the steps performed by the processor in the embodiment of FIG. 1 to FIG.

The mobile phone may further include at least one type of sensor 650 and a power source 690. Although not shown, the mobile phone may further include a camera, a Bluetooth module, and the like, and details are not described herein.

In addition, an embodiment of the present invention further provides a computer storage medium, where the medium stores an application program, and the program Execution includes some or all of the steps in the above version verification method.

A person skilled in the art can clearly understand that for the convenience and brevity of the description, the specific working process of the system, the device and the unit described above can refer to the corresponding process in the foregoing method embodiment, and details are not described herein again.

In the several embodiments provided by the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the device embodiments described above are merely illustrative. For example, the division of the unit is only a logical function division. In actual implementation, there may be another division manner, for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be in an electrical, mechanical or other form.

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 to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a standalone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention, which is essential or contributes to the prior art, or all or part of the technical solution, may be embodied in the form of a software product stored in a storage medium. A number of instructions are included to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like. .

The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to be limiting; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art will understand that The technical solutions described in the embodiments are modified, or the equivalents of the technical features are replaced by the equivalents of the technical solutions of the embodiments of the present invention.

Claims

A version verification method, comprising:

Obtaining version information of the first version, where the version information includes a version number of the first version;

Determining, according to the version number of the first version, a parity bit corresponding to the version number of the first version;

If the verification bit corresponding to the version number of the first version is the first value, determining that the first version is disabled, and the first version verification fails;

If the parity bit corresponding to the version number of the first version is the second value, it is determined that the first version is available, and the first version is verified.
The method of claim 1 further comprising:

Receiving an indication that the second version is disabled, the indication of disabling the second version includes a version number of the second version;

Determining, according to the version number of the second version, a parity bit corresponding to the version number of the second version;

The check bit position corresponding to the version number of the second version is the first value.
The method of claim 1 wherein

The parity bit corresponding to the version number of the first version is stored in a first field of the electronic fuse metal fuse eFuse, and each bit in the first field is used to indicate whether a version is disabled.
The method of claim 1 wherein

The parity bit corresponding to the version number of the first version is stored in a second field of the flash memory, and each bit in the second field is used to indicate whether a version is disabled.
The method according to any one of claims 1 to 4, further comprising:

Performing signature verification on the version information of the first version;

When the signature authentication is passed, the step of determining the parity bit corresponding to the version number of the first version according to the version number of the first version is performed.
The method according to any one of claims 1 to 4, wherein the obtaining the version information of the first version comprises:

Receiving an upgrade indication, and obtaining version information of the first version according to the upgrade indication;

The method further includes:

If the verification fails, the upgrade to the first version is not performed;

If the verification passes, upgrade to the first version.
The method according to any one of claims 1 to 4, wherein the obtaining the version information of the first version comprises:

Receiving a startup indication for starting the first version, and acquiring version information of the first version according to the startup indication;

The method further includes:

When the first version verification fails, the first version is not started;

The first version is launched when the first version verification passes.
A version verification device, comprising:

a version information obtaining module, configured to obtain version information of the first version, where the version information includes a version number of the first version;

a version verification module, configured to determine, according to the version number of the first version, a parity bit corresponding to the version number of the first version, where the verification bit corresponding to the version number of the first version is the first a value, determining that the first version is disabled, the first version verification is not passed, and if the verification bit corresponding to the version number of the first version is a second value, determining that the first version is available The first version is verified to pass.
The device according to claim 8, wherein the device further comprises:

a receiving module, configured to receive an indication that the second version is disabled, where the indication of disabling the second version includes a version number of the second version;

a check bit updating module, configured to determine, according to the version number of the second version, a parity bit corresponding to the version number of the second version, and the check bit position corresponding to the version number of the second version is Said the first value.
The device of claim 8 wherein:

The parity bit corresponding to the version number of the first version is stored in a first field of the electronic fuse metal fuse eFuse, and each bit in the first field is used to indicate whether a version is disabled.
The device of claim 8 wherein:

The parity bit corresponding to the version number of the first version is stored in a second field of the flash memory, and each bit in the second field is used to indicate whether a version is disabled.
The device according to any one of claims 8 to 11, wherein the device further comprises:

a signature authentication module, configured to perform signature verification on the version information of the first version. When the signature authentication is passed, the version verification module performs the determining the first version according to the version number of the first version. The step of verifying the bit corresponding to the version number.
Apparatus according to any one of claims 8 to 11 wherein:

The version information obtaining module is configured to receive an upgrade instruction, and obtain version information of the first version according to the upgrade instruction.

The device also includes:

The upgrade module is configured not to upgrade to the first version when the verification fails, and to upgrade to the first version if the verification is passed.
Apparatus according to any one of claims 8 to 11 wherein:

The version information obtaining module is configured to receive a startup instruction for starting the first version, and obtain version information of the first version according to the startup indication.

The device also includes:

The security startup module is configured to not start the first version when the first version verification fails, and start the first version when the first version verification passes.
A terminal device, comprising: a transceiver, a processor and a memory connected to each other;

The memory is for storing program code, and the processor calls the program code in the memory to perform the following operations:

Obtaining version information of the first version, where the version information includes a version number of the first version; determining, according to the version number of the first version, a parity bit corresponding to the version number of the first version; The version number of the first version If the check bit is the first value, it is determined that the first version is disabled, the first version check fails; if the check bit corresponding to the version number of the first version is the second value And determining that the first version is available, and the first version is verified.