A method for updating a system version, an electronic device, and a storage medium.

Abstract

A system version update method, electronic device, and storage medium are disclosed, relating to the field of terminal technology. The method includes: verifying an upgrade flag, wherein the upgrade flag is signed using an encryption algorithm; if the verification passes, allowing the system version to be upgraded or rolled back; if the verification fails, processing each version number in the version list obtained during system version update using an HMAC algorithm to obtain an HMAC set, wherein the version list includes the version number of the updated version and the version numbers of each earlier version of the updated version, and the key used in the HMAC algorithm is generated by the electronic device and uniquely corresponds to the electronic device; when the HMAC set includes a first HMAC, upgrading to the updated version is allowed, wherein the first HMAC is the HMAC corresponding to the version number of the current system version; otherwise, updating the system version is not allowed. This method improves the system version rollback prevention capability and reduces the risk of information leakage and unauthorized use of the electronic device.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a method for updating a system version, an electronic device, and a storage medium. Background Technology

[0002] Flashing refers to modifying or replacing some of the original language, images, ringtones, software, and operating system settings on an electronic device using certain methods. Flashing can update or restore the system version of an electronic device. Locking refers to disabling an electronic device in the event of loss, theft, or unauthorized use, thereby preventing information leakage and unauthorized use.

[0003] Currently, it is possible to revert the system version of an electronic device by flashing the firmware, for example, flashing from version 2 back to an earlier version 1. Since the reverted version 1 may not support locking, the flashed electronic device can no longer be locked, which means that the electronic device still has the risk of information leakage and unauthorized use. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a system version update method, an electronic device, and a storage medium, which enhances the system version's ability to prevent rollback, thereby reducing the risk of information leakage and unauthorized use of the electronic device.

[0005] Firstly, this application provides a method for updating a system version, applied to an electronic device, specifically including: verifying an upgrade flag, wherein the upgrade flag is signed using an encryption algorithm; when the verification passes, allowing the system version to be upgraded or rolled back; when the verification fails, processing each version number in the version list obtained during the system version update using the Key Hash Message Authentication Code (HMAC) algorithm to obtain an HMAC set, wherein the version list includes the version number of the updated version and the version numbers of each earlier version of the updated version, and the key used by the HMAC algorithm is generated by the electronic device and uniquely corresponds to the electronic device; when it is determined that the HMAC set includes a first HMAC, allowing the system version to be upgraded to the updated version, wherein the first HMAC is the HMAC corresponding to the version number of the current system version stored on the electronic device; otherwise, not allowing the system version to be updated.

[0006] Using the solution provided in this application, during system updates via flashing, an additional verification step for the upgrade flag is added. This ensures that even if the first HMAC set stored on the electronic device is deleted, the device will not automatically allow a system version update due to a misinterpretation that this is the first system write. In this solution, the electronic device needs to verify the upgrade flag first during flashing. This upgrade flag is signed using an encryption algorithm. Because the key used in the encryption algorithm has access restrictions, tamper resistance is improved. When the user passes the upgrade flag verification, the user can upgrade or revert to the system version as needed.

[0007] When a user fails the upgrade flag verification, an HMAC verification is also required. HMAC verification needs to determine whether the HMAC set includes the first HMAC stored locally on the electronic device. The HMAC set includes the HMAC corresponding to the upgraded version of the electronic device, as well as the HMACs corresponding to each earlier version of the upgraded version; the first HMAC is the HMAC corresponding to the earlier version of the electronic device. If it is included, the system update is determined to be an upgrade update, and the system upgrade is allowed. If it is not included, the system update is determined to be a downgrade update, i.e., a system version rollback is performed, and the system upgrade is not allowed. In this application, the HMAC corresponding to each version number is generated based on a hash algorithm using a key and the version number. The key is generated by the electronic device, and each electronic device generates a different key, which cannot be obtained externally, making it impossible for external entities to generate the correct HMAC corresponding to the version number. Therefore, it is impossible to pass HMAC verification by replacing or modifying the first HMAC stored on the electronic device, and since the key uniquely corresponds to the electronic device, migrating the first HMAC of other electronic devices will also fail HMAC verification.

[0008] In summary, the solution provided in this application improves the system version's ability to prevent rollback, thereby reducing the risk of information leakage and unauthorized use of electronic devices.

[0009] In one possible implementation, the upgrade flag is signed using an RSA encryption algorithm, which employs a first hash algorithm. The verification of the upgrade flag specifically includes: when the upgrade flag is obtained, decrypting the upgrade flag using the public key of the RSA encryption algorithm to obtain a first hash value; processing the original upgrade flag using the first hash algorithm to obtain a second hash value, wherein the original upgrade flag was not signed using the RSA encryption algorithm; if the first hash value and the second hash value are the same, the upgrade flag verification is determined to be successful; otherwise, the upgrade flag verification is determined to be unsuccessful.

[0010] One possible implementation includes: when the upgrade flag is not obtained, determining that the upgrade flag verification has failed.

[0011] In one possible implementation, after the verification passes, the method further includes: upgrading or reverting the system version to the first version, processing the version number of the first version using the HMAC algorithm to obtain the HMAC corresponding to the version number of the first version; and updating the first HMAC to the HMAC corresponding to the version number of the first version.

[0012] In one possible implementation, after updating the first HMAC to the HMAC corresponding to the version number of the first version, the method further includes: deleting the upgrade flag on the electronic device.

[0013] Removing the upgrade flag from electronic devices frees up storage space and prevents the upgrade flag from being accessed externally.

[0014] In one possible implementation, after determining that the HMAC set includes a first HMAC, the method further includes: upgrading the system version to a second version; processing the version number of the second version using the HMAC algorithm to obtain the HMAC corresponding to the version number of the second version; and updating the first HMAC to the HMAC corresponding to the version number of the second version.

[0015] In one possible implementation, when the current system version is a production test version, the first HMAC stored in the electronic device is empty data. When the verification passes, the method further includes: updating the system version to a third version; processing the version number of the third version using the HMAC algorithm to obtain the HMAC corresponding to the version number of the third version; and writing the HMAC corresponding to the version number of the third version into the data storage area as the first HMAC of the electronic device.

[0016] This implementation method enables the initial system update of electronic devices.

[0017] In one possible implementation, after writing the HMAC corresponding to the version number of the third version to the data storage area, the method further includes:

[0018] Remove the upgrade flag from the electronic device.

[0019] In one possible implementation, the current system version is the fourth version. When the verification passes, or when it is determined that the HMAC set includes the first HMAC, the method further includes: updating the system version to the fourth version; processing the version number of the fourth version using the HMAC algorithm to obtain the HMAC corresponding to the version number of the fourth version; and updating the first HMAC to the HMAC corresponding to the version number of the fourth version.

[0020] In this implementation, no version upgrade or rollback is performed. Instead, the current version of the system is reinstalled on the electronic device to repair or restore the system.

[0021] Secondly, this application also provides an electronic device for running a program that, when running, implements the system version update method described in the first aspect and any implementation thereof.

[0022] The electronic device can be a mobile phone, tablet computer, computer with wireless transceiver function, augmented reality (AR) terminal device, virtual reality (VR) terminal device, mixed reality (MR) terminal device, extended reality (XR) terminal device, etc., and the embodiments of this application do not specifically limit it.

[0023] Thirdly, this application also provides a storage medium storing a computer program thereon, which, when executed by a processor, implements the system version update method described in the above implementation. Attached Figure Description

[0024] Figure 1 This application provides a schematic diagram of the scenario.

[0025] Figure 2 A flowchart illustrating a system version update method provided in this application embodiment;

[0026] Figure 3 A flowchart illustrating another system version update method provided in this application embodiment;

[0027] Figure 4 A flowchart illustrating another system version update method provided in this application embodiment;

[0028] Figure 5 A flowchart illustrating another system version update method provided in this application embodiment;

[0029] Figure 6A flowchart illustrating another system version update method provided in this application embodiment;

[0030] Figure 7 A schematic diagram of an electronic device provided in an embodiment of this application;

[0031] Figure 8 A software architecture diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0032] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number or order of the indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0033] In the following description, "updating" of the system version means that the system version loaded on the electronic device is different from the previous version of the electronic device; "upgrading" of the system version means that the system version loaded on the electronic device is an upgraded version of the previous version of the electronic device; "downgrading" of the system version means that the system version loaded on the electronic device is a downgraded version of the previous version of the electronic device, that is, version rollback is achieved.

[0034] To enable those skilled in the art to better understand the solution of this application, the application scenario of the technical solution of this application will be described first below.

[0035] See Figure 1 This figure is a schematic diagram of the scenario provided in this application.

[0036] In one possible application scenario, when a user purchases an electronic device on installment, the user typically pays a certain percentage upfront and the remaining amount in installments. The electronic device has the ability to lock; once the user defaults on payment, the electronic device is locked, preventing the defaulting user from using other functions.

[0037] In another possible implementation, the electronic device may store important information or data, and the device can only be used by users with authorized access. If an unauthorized user is detected holding the electronic device, it can be locked to prevent unauthorized use.

[0038] In another possible implementation, if an electronic device is lost or stolen, its locking capability is relied upon to secure it and prevent information leakage.

[0039] However, the current implementation of the device lock function is affected by the operating system version of the electronic device. For example, older system versions may not support device lock, or they may contain vulnerabilities that allow the device to unlock. Users may be able to unlock their devices by flashing the firmware to revert to an older system version. Figure 1 As shown, when the system version is 3.0, the electronic device is locked. If the system version of the electronic device is reverted to version 2.0, which does not support locking, by flashing the firmware, the electronic device can be used normally.

[0040] To avoid the above situations, electronic devices need to have strong system version rollback prevention capabilities. However, current electronic devices have poor system version rollback prevention capabilities, posing a high risk of information leakage and unauthorized use.

[0041] To address the aforementioned technical problems, this application provides a system version update method, an electronic device, and a storage medium. To overcome these vulnerabilities, the inventive concept of this application lies in two aspects: firstly, by adding a verification step, it prevents arbitrary version updates from being performed directly, requiring verification first; secondly, it improves the relevant algorithms for version number verification, providing integrity protection so that external sources cannot generate correct data to replace data in the data storage area.

[0042] Specifically, when updating the system via flashing, the upgrade flag must first be verified. This upgrade flag is signed using an encryption algorithm and bound to the electronic device, ensuring its uniqueness and tamper-proof nature. The key used for the encryption algorithm has access restrictions. When the user passes the upgrade flag verification, they are allowed to update the system version as needed, such as upgrading or reverting.

[0043] When a user fails the upgrade flag verification, version number verification is also required. In this application, version number verification is performed using a keyed-hash message authentication code (HMAC) verification. During HMAC verification, an HMAC set is first generated. This set includes the HMAC corresponding to the upgraded version of the electronic device, as well as the HMACs corresponding to each earlier version of the upgraded version. The electronic device's data storage area includes a first HMAC, which is the HMAC corresponding to the version number of the earlier version of the electronic device. Then, it is determined whether the first HMAC is included in the HMAC set. If it is, the system update is determined to be an upgrade update, and the system upgrade is allowed. If it is not, the system update is determined to be a downgrade update, i.e., a system version rollback is performed, and the system upgrade is not allowed.

[0044] In this application, the HMAC corresponding to each version number is generated based on a hash algorithm using a key and the version number. The key is generated by the electronic device, and each electronic device generates a different key, which cannot be obtained externally, preventing the generation of the correct HMAC for the version number. Therefore, it is impossible to pass HMAC verification by replacing or modifying the first HMAC stored in the electronic device. Furthermore, since the key uniquely corresponds to the electronic device, directly transplanting the first HMAC from other electronic devices will also fail HMAC verification.

[0045] In summary, this solution significantly improves the system's ability to prevent rollback, thereby reducing the risk of information leakage and unauthorized use of electronic devices.

[0046] The method for updating the system version provided in this application is explained in detail below with reference to the accompanying drawings.

[0047] See Figure 2 The figure is a flowchart of a system version update method provided in an embodiment of this application.

[0048] The method includes the following steps:

[0049] S21: Start flashing the firmware.

[0050] Currently, common flashing methods include secure digital (SD) card flashing, OTG (On-The-Go) flashing, and Over-the-Air (OTA) flashing.

[0051] When flashing an SD card, the flashing file is stored on the SD card. After inserting the SD card into the electronic device, the flashing process is triggered on the electronic device.

[0052] OTG technology allows for data transfer between devices without a host, such as data transfer between electronic devices and USB flash drives. When flashing a device using OTG, the flashing file is typically stored on a USB flash drive. An OTG adapter that supports OTG technology is used to connect the USB flash drive to the electronic device, and the flashing process is then triggered on the electronic device.

[0053] OTA flashing, also known as OTA upgrade, can be completed using Wi-Fi or mobile networks, essentially using an over-the-air wireless network for the upgrade.

[0054] This application does not limit the specific flashing method. The above two flashing methods are merely examples and do not constitute a limitation on the technical solution of this application.

[0055] S22: Determine whether the upgrade flag verification has passed.

[0056] When an electronic device is flashed, the first step is to verify the upgrade flag.

[0057] In one possible implementation, when an electronic device is flashed, it can log in to a server via the network, obtain an upgrade flag from the server, and then verify the upgrade flag.

[0058] In another possible implementation, when the electronic device is being flashed, it can also establish a connection with other external electronic devices, such as a personal computer (PC). The PC obtains the upgrade flag from the service area and writes the upgrade flag to the electronic device, so that the electronic device can verify the upgrade flag.

[0059] In this embodiment, the upgrade flag is data uniquely associated with each electronic device and signed using an encryption algorithm. The encryption algorithm used for the upgrade flag can be either a symmetric encryption algorithm or an asymmetric encryption algorithm.

[0060] In one possible implementation, the encryption algorithm is a symmetric encryption algorithm. In this case, the encryption key can be stored on the server of the electronic device, which external users do not have access to, and the upgraded flag after signing cannot be tampered with. The symmetric encryption algorithm can be DES, 3DES, AES, DESX, Blowfish, RC4, RC5, or RC6, etc., and this application does not specifically limit it.

[0061] In another possible implementation, the encryption algorithm can be an asymmetric encryption algorithm, such as RSA, DSA, or ECC. When using an asymmetric encryption algorithm, the private key is stored on the electronic device's server, which external users do not have access to, and the signed upgrade flag cannot be tampered with.

[0062] This will be illustrated by taking the example of an electronic device manufacturer using the RSA asymmetric encryption algorithm to sign the original upgrade flag to obtain the upgrade flag.

[0063] The manufacturer first generates a key pair, namely a public key and a private key. The public key can be made public, but the private key is not. The private key can be stored on the manufacturer's server.

[0064] The following describes the key generation process for the RSA algorithm.

[0065] Determine the first prime number p and the second prime number q, where p and q are not equal. The first prime number p and the second prime number q cannot be too small, otherwise the key will be easy to crack.

[0066] Determine N: N = pq.

[0067] Determine L: L is the least common multiple of p-1 and q-1.

[0068] Determine E: E must satisfy two conditions: E is a number greater than 1 and less than L, and the greatest common divisor of E and L is 1.

[0069] Determine D: D satisfies 1 < D < L, and (DE) mod L = 1.

[0070] At this time, (N, E) is the public key, and (N, D) is the private key.

[0071] When signing the original upgrade flag, first use the hash algorithm to process the original upgrade flag once to obtain a string hash value, and then use the private key to encrypt this string hash value to obtain a signature.

[0072] The string hash value n can be encrypted into c through the following formula:

[0073] c = n E mod N (1)

[0074] The higher c in formula (1) is also the upgrade flag. When the manufacturer of the electronic device, or the R & D researchers authorized by the manufacturer, the device maintenance personnel authorized by the manufacturer, etc. perform flashing on the electronic device, the upgrade flag and the original upgrade flag will be transmitted to the electronic device together.

[0075] When the electronic device performs signature verification, first use the public key to decrypt the signature, and decrypt c to obtain the hash value a. Specifically, refer to the following formula:

[0076] a = c D mod N (2)

[0077] Then the electronic device performs a hash processing on the original upgrade flag once with the same hash algorithm as the manufacturer to obtain another hash value b. The electronic device compares whether a and b are the same. If they are the same, it can be determined that the object providing the upgrade flag and the original upgrade flag has passed the verification of the upgrade flag, and S24 is executed, that is, allowing the system of the electronic device to be updated to any version.

[0078] For users not authorized by the manufacturer, even if they obtain the original upgrade flag of the electronic device, due to lack of access rights to the private key, they cannot use the private key to sign the original upgrade flag, which makes it impossible for external users to forge a signed upgrade flag for the electronic device. When the electronic device performs upgrade flag verification, it is found that no valid upgrade flag is obtained at this time, that is, the upgrade flag is empty, resulting in the failure of the upgrade flag verification. At this time, S23 is executed.

[0079] In another possible implementation, although the user performing the flashing is authorized by the manufacturer, a discrepancy occurs between 'a' and 'b' during the verification process. This could be due to the user providing an incorrect upgrade flag and / or the original upgrade flag. In this case, the electronic device determines that the upgrade flag verification has failed and executes S23. Furthermore, if the original upgrade flag is not obtained, the verification will also fail because signature verification cannot be completed.

[0080] In this embodiment, each electronic device has a unique upgrade identifier, so copying the upgrade identifier of other electronic devices will not pass the upgrade identifier verification. In one possible implementation, the upgrade identifier may carry the electronic device's serial number (SN) information.

[0081] S23: Determine whether the HMAC set includes the first HMAC.

[0082] In this embodiment, the version number of each version is converted into a keyed-hash message authentication code (HMAC). When performing HMAC calculation on the version number, a hash algorithm is used, taking the key and version number as input, to output the corresponding HMAC. The specific principle can be found in the following formula:

[0083]

[0084] In equation (3), H is the cryptographic hash function; K is the key; m is the version number; K' is another secret key derived from the original key K (if K is shorter than the input block size of the hash function, it is padded with zeros to the right; if it is longer than the input block size, K is hashed); || represents concatenation; ⊕ represents XOR; opad is external padding; ipad is internal padding.

[0085] The specific process of processing the version number using HMAC operation is as follows:

[0086] 1. Add zeros to the key K or hash the key K to create a string of length B. For example, if the length of K is 20 bytes and B = 64 bytes, then 44 zero bytes (0x00) will be added after K; if the length of K is 120 bytes and B = 64 bytes, then hashing K will produce a 64-byte string.

[0087] 2. Perform an XOR operation between the string of length B generated in step 1 and the iPad to obtain the first result string.

[0088] 3. Fill the version number into the first result string and obtain the first data stream.

[0089] 4. Process the first data stream using a cryptographic hash function.

[0090] 5. Perform an XOR operation between the B-length string generated in step 1 and opad to obtain the second result string.

[0091] 6. Then fill the result of processing 4 into the second result string obtained in 5 to obtain the second data stream.

[0092] 7. Process the second data stream generated in step 6 using a cryptographic hash function, and output the final result.

[0093] The HMAC algorithm described above can be used to convert a version number into a corresponding HMAC.

[0094] The HMAC processing described above requires a key K. In this embodiment, the key K is generated by the electronic device and cannot be obtained externally. Furthermore, the key K is uniquely associated with the electronic device itself, and different electronic devices generate different keys K.

[0095] The data storage area of ​​the electronic device stores a first HMAC, which is the HMAC corresponding to the version number of an earlier version of the electronic device.

[0096] For example, if the current system version of an electronic device is version 2, and the version number of version 2 is version 2, then the first HMAC stored on the electronic device is the HMAC corresponding to version 2.

[0097] When verifying the version number, an external provider needs to provide a list of flashing versions corresponding to this flashing process. This list, also simply called the version list, includes the upgrade version number and the version numbers preceding it. The upgrade version number is the version number of the system updated on the electronic device through flashing. For example, if flashing replaces the system from version 2 to version 3, the upgrade version number is the version number of version 3, i.e., the third version number. The version numbers preceding the third version number are the first and second version numbers. The first version number is the version number of the first version, and the second version number is the version number of the second version.

[0098] At this point, the flashing version list includes version number 1, version number 2, and version number 3.

[0099] In this embodiment of the application, the HMAC set includes the HMAC corresponding to the upgraded version of the electronic device, and the HMAC corresponding to each earlier version of the upgraded version.

[0100] The electronic device performs HMAC calculations on each version number included in the flashing version list to obtain the HMAC corresponding to the first version number, the second version number, and the third version number.

[0101] The electronic device then determines whether the HMAC set includes the first HMAC. Since the HMAC set includes the first HMAC in the example above, it indicates that the flashing is a version upgrade, allowing the system to be updated via flashing, and executes S24.

[0102] In another possible implementation, for example, if the upgrade version is the first version, then the flashing version list only includes the first version number, and the HMAC set only includes the HMAC corresponding to the first version number. At this time, the electronic device determines that the HMAC set does not include the HMAC corresponding to the second version number, and determines that the flashing is a version rollback. Therefore, it does not allow system updates through flashing and executes S27.

[0103] It is understood that in this embodiment of the application, the HMAC corresponding to the upgraded version is also the first HMAC stored locally on the electronic device, indicating that there is no version upgrade or rollback at this time, but rather an update to the same version.

[0104] For example, flashing a firmware update an electronic device from version 2 to version 2. This method is generally used to repair or restore the system of an electronic device. In this case, the HMAC set includes the HMAC corresponding to the first version number and the HMAC corresponding to the second version number. The first HMAC is the HMAC corresponding to the second version number, which satisfies the condition for allowing firmware flashing.

[0105] S24: Perform a system update.

[0106] Performing a system update, which means being able to perform the flashing process normally, involves updating the system version.

[0107] S25: After processing the upgrade version number using the HMAC algorithm, store the processing result in the data storage area.

[0108] The HMAC algorithm is used to process the upgrade version number to obtain the HMAC corresponding to the upgrade version number, and the HMAC corresponding to the upgrade version number is stored in the data storage area. That is, the first HMAC in the data storage area is updated in a timely manner so that the electronic device cannot roll back the version in the future.

[0109] Continuing with the example of an electronic device upgrading from version two to version three, the electronic device then uses the HMAC algorithm to process the version number to obtain the HMAC corresponding to the version number, and stores the HMAC in the data storage area. At this time, the first HMAC of the electronic device is updated from the HMAC corresponding to the version number two to the HMAC corresponding to the version number three.

[0110] S26: Remove the upgrade flag.

[0111] In other words, deleting the upgrade flag provided to the electronic device by the external party during this flashing process frees up storage space and prevents the upgrade flag from being obtained by external parties.

[0112] S27: System updates are not allowed.

[0113] At this point, the electronic device does not allow system updates, making it impossible to complete the subsequent flashing process.

[0114] It is understood that the above steps are divided for ease of explanation only and do not constitute a limitation on the technical solution of this application. In actual application, the order of the above steps can be adjusted. For example, if the electronic device is not written with the upgrade flag during the verification in S22, S26 can be omitted.

[0115] In summary, the solution provided in this application first verifies the upgrade flag during flashing, ensuring that even clearing the data storage area prevents direct updates to any version. If the upgrade flag verification fails, it checks if the HMAC set includes the first HMAC. If it does, the system update is determined to be an upgrade, and the system upgrade is allowed. Since the HMAC key is generated by the electronic device, and each device generates a different key that cannot be obtained externally, it is impossible for external entities to pass HMAC verification by replacing or modifying the first HMAC stored on the electronic device. Furthermore, because the key uniquely corresponds to the electronic device, directly porting the first HMAC of another electronic device will also fail HMAC verification. Therefore, the solution in this application significantly improves the system version rollback prevention capability, thereby reducing the risk of information leakage and unauthorized use of electronic devices.

[0116] The following explanation will be based on specific application scenarios.

[0117] The following section will first introduce how to implement the first system update during the manufacturing process of electronic devices.

[0118] See Figure 3 The figure is a flowchart of another system version update method provided in the embodiments of this application.

[0119] The electronic device is currently running a production test version of the system. The upgraded version of the electronic device is version two, and the version number of version two is version number two. The method includes the following steps:

[0120] S31: Start flashing the firmware.

[0121] This application does not limit the specific flashing method. The above two flashing methods are merely examples and do not constitute a limitation on the technical solution of this application.

[0122] S32: The PC writes an upgrade flag to the electronic device.

[0123] In this embodiment, the example is taken when an electronic device is flashed, triggering an upgrade flag verification, and the upgrade flag is written by a PC. In this scenario, the PC user is either a user of the device manufacturer or an authorized user of the manufacturer. This PC can obtain the upgrade flag from the service area and write the upgrade flag to the electronic device.

[0124] In one possible implementation, the upgrade flag can be written as data to a designated file in the data storage area.

[0125] In another possible implementation, the upgrade flag is carried in a file and that file is stored in a data storage area.

[0126] When an electronic device is flashed, it can also log in to the server via the network, obtain the upgrade flag from the server, and then verify the upgrade flag.

[0127] S33: The upgrade flag has been verified.

[0128] Because an upgrade flag with a correct private key was written to the electronic device in this scenario, the electronic device can pass the signature verification normally.

[0129] S34: Electronic devices are undergoing system updates.

[0130] At this point, the electronic device can normally perform the flashing process and update the system version.

[0131] S35: The electronic device uses the HMAC algorithm to process the second version number and stores the processing result in the data storage area.

[0132] At this point, the electronic device uses the HMAC algorithm to process the second version number, obtains the HMAC corresponding to the second version number, and updates the data storage area. Before the update, the first HMAC stored in the data storage area is empty data; after the update, the first HMAC stored in the data storage area is the HMAC corresponding to the second version number.

[0133] S36: Remove upgrade flag from electronic device.

[0134] Removing the upgrade flag from electronic devices frees up storage space and prevents the upgrade flag from being accessed externally.

[0135] In summary, by using the method provided in the embodiments of this application, when an electronic device undergoes its first system update, since the person performing the system update has the permission to access the upgrade flag and can write the correct upgrade flag to the electronic device, the electronic device can be updated to any version.

[0136] The following explains how to prevent the phone version from rolling back when the upgrade verification fails.

[0137] See Figure 4 The figure is a flowchart of another system version update method provided in the embodiments of this application.

[0138] The electronic device is currently running system version 3, and the version number of version 3 is version 3; the upgraded version of the electronic device is version 2, and the version number of version 2 is version 2. The method includes the following steps:

[0139] S41: Start flashing the firmware.

[0140] S42: It has been determined that the current upgrade flag verification has failed.

[0141] When the electronic device detects that no upgrade flag has been written, i.e., the upgrade flag is empty, it determines that the current upgrade flag verification has failed; or when the electronic device performs signature verification on the upgrade flag and finds a data error, it determines that the current upgrade flag verification has failed, and then performs HMAC verification.

[0142] S43: Determine the HMAC set based on the second version's flashing version list.

[0143] The current upgrade version is version 2. The flashing version list for version 2 includes version 1 and version 2. The HMAC algorithm is used to process the version 1 and version 2 to obtain an HMAC set. The HMAC set includes the HMAC corresponding to both version 1 and version 2.

[0144] S44: Determine that the HMAC set does not include the first HMAC stored by the electronic device at this time.

[0145] The electronic device is currently running version 3, and the first HMAC stored in the electronic device's data storage area is the HMAC corresponding to version 3.

[0146] Comparing the HMAC set with the first HMAC, it was found that the first HMAC was not included in the HMAC set, which means that this flashing was to roll back the system version.

[0147] S45: System updates are not allowed.

[0148] At this point, the electronic device does not allow system updates, making it impossible to complete the subsequent flashing process.

[0149] It is understood that the above steps are divided for ease of explanation only and do not constitute a limitation on the technical solution of this application. In actual application, the order of the above steps can be adjusted. For example, when the electronic device is written with the upgrade flag during verification in S42, although the verification of the upgrade flag fails, a step to delete the upgrade flag can be added after S45.

[0150] In summary, by using the method provided in this application embodiment and performing HMAC verification, it is possible to identify that the upgraded version flashed by the user has regressed compared to the current running version of the electronic device, thereby preventing system updates. Furthermore, the HMAC key is generated by the electronic device, and each electronic device generates a different key that cannot be obtained externally. This prevents external parties from passing HMAC verification by replacing or modifying the first HMAC stored in the electronic device. Since the key uniquely corresponds to the electronic device, directly transplanting the first HMAC of other electronic devices will also fail HMAC verification, thus enabling the electronic device to prevent system version rollback.

[0151] The following explains how to allow phone version rollback when the upgrade verification passes.

[0152] See Figure 5 The figure is a flowchart of another system version update method provided in the embodiments of this application.

[0153] Taking the current system version 3 of the electronic device as an example, where the version number of version 3 is 3, and the upgraded version of the electronic device is version 2, where the version number of version 2 is 2, the method includes the following steps:

[0154] S51: Start flashing the firmware.

[0155] S52: The PC writes an upgrade flag to the electronic device.

[0156] In this embodiment, the example is taken when an electronic device is flashed, triggering an upgrade flag verification, and the upgrade flag is written by a PC. In this scenario, the PC user is either a user of the device manufacturer or an authorized user of the manufacturer. This PC can obtain the upgrade flag from the service area and write the upgrade flag to the electronic device.

[0157] In one possible implementation, the upgrade flag can be written as data to a designated file in the data storage area.

[0158] In another possible implementation, the upgrade flag is carried in a file and that file is stored in a data storage area.

[0159] When an electronic device is flashed, it can also log in to the server via the network, obtain the upgrade flag from the server, and then verify the upgrade flag.

[0160] S53: The upgrade flag has been verified.

[0161] Because an upgrade flag with a correct private key was written to the electronic device in this scenario, the electronic device can pass the signature verification normally.

[0162] S54: The electronic device reverts the system to version 2.

[0163] S55: Obtain the HMAC corresponding to the second version number and update the data storage area.

[0164] At this point, the electronic device uses the HMAC algorithm to process the second version number, obtains the HMAC corresponding to the second version number, and updates the data storage area. Before the update, the first HMAC stored in the data storage area is the HMAC corresponding to the third version number; after the update, the first HMAC stored in the data storage area is the HMAC corresponding to the second version number.

[0165] S56: Remove upgrade flag from electronic device.

[0166] Removing the upgrade flag from electronic devices frees up storage space and prevents the upgrade flag from being accessed externally.

[0167] In summary, the solution provided in this application allows electronic devices to revert to a different system version after the upgrade flag verification is successful. This reversion enables the repair and restoration of the electronic device. For example, if poor compatibility between the electronic device and the new version leads to a decline in user experience, a version rollback can restore the device to a more compatible system. Furthermore, this version rollback requires verification of the upgrade flag, necessitating that the personnel performing the flashing process possess system rollback authorization. This is typically the device manufacturer, or authorized R&D personnel or maintenance personnel authorized by the manufacturer, thus preventing information leakage and unauthorized use of the electronic device.

[0168] The following explains how to implement a mobile phone version upgrade when the upgrade verification fails.

[0169] Taking the current system version of the electronic device as version two, the version number of version two as version two, and the upgraded version of the electronic device as version three, the version number of version three as version three, as an example, the following steps are included:

[0170] See Figure 6 The figure is a flowchart of another system version update method provided in the embodiment of this application.

[0171] S61: Start flashing the firmware.

[0172] S62: It has been determined that the current upgrade flag verification has failed.

[0173] When the electronic device detects that no upgrade flag has been written, i.e., the upgrade flag is empty, it determines that the current upgrade flag verification has failed; or when the electronic device performs signature verification on the upgrade flag and finds a data error, it determines that the current upgrade flag verification has failed, and then performs HMAC verification.

[0174] S63: Determine the HMAC set based on the third version's flashing version list.

[0175] The third version flashing version list includes version 1, version 2, and version 3. The HMAC algorithm is used to process the version 1, version 2, and version 3 to obtain an HMAC set. The HMAC set includes the HMAC corresponding to version 1, version 2, and version 3.

[0176] S64: Determine the first HMAC stored in the electronic device in the HMAC set at this time.

[0177] The electronic device is currently running version 2, and the first HMAC stored in the electronic device's data storage area is the HMAC corresponding to the version 2 number.

[0178] Comparing the HMAC set with the first HMAC, it was found that the HMAC set included the first HMAC, which indicates that the flashing was for the purpose of upgrading the system version.

[0179] S65: Electronic devices are allowed to update the system.

[0180] At this point, the electronic device undergoes a system update, completing the subsequent flashing process.

[0181] S66: Electronic device upgrade flag removed.

[0182] Removing the upgrade flag from electronic devices frees up storage space and prevents the upgrade flag from being accessed externally.

[0183] It is understood that the above steps are divided for ease of explanation only and do not constitute a limitation on the technical solution of this application. In actual application, the order of the above steps can be adjusted. For example, if the electronic device is not written with the upgrade flag during the verification in S62, S66 can be omitted.

[0184] In summary, the solution provided in this application allows electronic devices to perform normal system upgrades by performing HMAC verification when the upgrade flag verification fails. Since the upgraded high version is compatible with the low version's locking capability, the upgraded electronic device can lock normally to prevent information leakage and unauthorized use of the electronic device.

[0185] Based on the system version update method provided in the above embodiments, this application also provides an electronic device, which will be described in detail below with reference to the accompanying drawings.

[0186] See Figure 7 This figure is a schematic diagram of an electronic device provided in an embodiment of this application.

[0187] Electronic device 70 may include: processor 701, memory 702 and bus 703.

[0188] The processor 701 and the memory 702 communicate with each other via the bus 703.

[0189] Processor 701 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). Different processing units may be independent devices or integrated into one or more processors. Processor 701 may also include memory for storing instructions and data. In some embodiments, the memory in processor 701 is a cache memory. This memory can store instructions or data that processor 701 has just used or is reusing. If processor 701 needs to reuse an instruction or data, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of processor 701, and thus improves system efficiency.

[0190] The memory 702 can be used to store computer executable program code, which includes instructions. The memory 702 may include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function, etc. The data storage area may store data created during the use of the electronic device, etc. In this embodiment, the first HMAC is stored in the data storage area. The data storage area is also used to store the upgrade flag file or upgrade flag data written to the electronic device during upgrade flag verification.

[0191] Furthermore, memory 702 may include high-speed random access memory and may also include non-volatile memory. Processor 701 executes the system version update method in the above embodiments by running instructions stored in memory 702 and / or instructions stored in memory disposed in the processor.

[0192] It is understood that the structure illustrated in the embodiments of the present invention does not constitute a specific limitation on the electronic device 70. In other embodiments of this application, the electronic device 70 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements.

[0193] The software architecture of electronic devices is described below.

[0194] See Figure 8 This figure is a software architecture diagram of the electronic device provided in an embodiment of this application.

[0195] Mobile electronic devices running operating systems (OS) such as Android and iOS operate in an environment called a Rich Execution Environment (REE). Electronic devices also include a Trusted Execution Environment (TEE). A TEE is an independent execution environment that runs alongside the REE, possessing its own execution space and a higher level of security. The operating system running within a TEE environment is called a TEE OS.

[0196] For operating systems running in an REE environment, taking the layered architecture of Android as an example, the software is divided into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system, from top to bottom, consists of the application layer, application framework layer, Android runtime and system libraries, Hardware Abstraction Layer (HAL), and kernel layer.

[0197] The application layer can include a series of application packages, such as camera, gallery, and calendar applications. The application layer can also include a flashing app, which allows users to initiate the flashing process for their electronic devices, thereby triggering the verification of the upgrade flag.

[0198] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications within the application layer. The application framework layer includes predefined functions. It may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0199] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0200] The core library consists of two parts: one part contains the functionalities that the Java language needs to call, and the other part is the Android core library. The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0201] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0202] The Hardware Abstraction Layer (HAL) is a routine package in the software layer. It is an interface layer located between the operating system kernel and the hardware circuitry. Its purpose is to abstract the hardware and simulate the details of a specific system platform so that programs can directly access hardware resources.

[0203] In one possible implementation, the hardware abstraction layer is an Original Equipment Manufacturer (OEM) module included in the module. The oeminfo storage file in the OEM module can store the HMAC corresponding to the earlier version number of the electronic device.

[0204] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0205] In this embodiment of the application, the TEE OS running in the TEE environment mainly includes a key derivation module, a secure storage module, an HMAC conversion module, and an HMAC interface.

[0206] The key derivation module is used to generate the key K for HMAC operations. The key K is uniquely associated with the electronic device itself, and different electronic devices generate different keys K.

[0207] The secure storage module is used to store the key K. Due to the high security of the TEE environment, it can ensure that the key K generated locally by the electronic device cannot be obtained from the outside.

[0208] The HMAC conversion module allows users to convert version numbers to their corresponding HMAC addresses.

[0209] The HMAC interface is used to output the HMAC obtained by the HMAC conversion module, that is, to output the HMAC to the REE environment.

[0210] Specifically, during HMAC verification, an external source needs to provide a list of flashing versions corresponding to this flashing process. This list includes the upgrade version number and the version number preceding the upgrade. The HMAC conversion module calls the key K in the secure storage module and, based on the HMAC algorithm, converts each version number in the flashing version list into its corresponding HMAC, thus obtaining an HMAC set. The HMAC interface outputs this HMAC set, which is then compared with the first HMAC set in the REE environment to determine whether the HMAC verification passes.

[0211] After the system update is complete, the HMAC conversion module calls the key K in the secure storage module, processes the upgrade version number according to the HMAC algorithm, and obtains the HMAC corresponding to the upgrade version number. The HMAC interface outputs the HMAC corresponding to the upgrade version number, updating the HMAC stored in the OEM module in the REE environment, so that the first HMAC of the electronic device is updated to the HMAC corresponding to the upgrade version number.

[0212] For a detailed explanation of the system version update method, please refer to the above method embodiments. This application embodiment will not repeat the details here.

[0213] In summary, the electronic device provided in this application first verifies the upgrade flag during the flashing process. This upgrade flag is signed using an encryption algorithm and bound to the electronic device, ensuring its uniqueness and tamper-proof nature. The key used in the encryption algorithm has access restrictions; when the user passes the upgrade flag verification, the user is allowed to update the system version as needed, such as upgrading or reverting.

[0214] When a user fails the upgrade flag verification, version number verification is also required. In this application, version number verification is performed using HMAC verification. The key used for HMAC verification is generated and stored in the TEE OS of the electronic device. Each electronic device generates a different key, which cannot be obtained externally, providing high security. Furthermore, an HMAC set is generated in the TEE OS, including the HMAC corresponding to the upgraded version of the electronic device, as well as the HMACs corresponding to each earlier version of the upgraded version. The data storage area of ​​the electronic device includes a first HMAC, which is the HMAC corresponding to the version number of the earlier version of the electronic device. Then, it is determined whether the first HMAC is included in the HMAC set. If it is included, the system update is determined to be an upgrade update, and the system upgrade is allowed. If it is not included, the system update is determined to be a downgrade update, i.e., a system version rollback is performed, and the system upgrade is not allowed.

[0215] Since the key cannot be obtained from outside, the correct version number corresponding to the HMAC cannot be generated. It is impossible to pass the HMAC verification by replacing or modifying the first HMAC stored in the electronic device. Furthermore, since the key is uniquely associated with the electronic device, directly transplanting the first HMAC of other electronic devices will also fail the HMAC verification.

[0216] In summary, this solution significantly improves the system's ability to prevent rollback, thereby reducing the risk of information leakage and unauthorized use of electronic devices.

[0217] This application also provides a storage medium storing a program that, when executed by a processor, implements the system version update method described above.

[0218] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically-erasable programmable read-only memory (EEPROM), flash memory, or other memory technologies.

[0219] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0220] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for updating a system version, characterized in that, Applied to electronic devices, the method includes: The upgrade flag is verified, and the upgrade flag is signed using an encryption algorithm; When the verification passes, the system version can be upgraded or rolled back. When the verification fails, the HMAC algorithm is used to process each version number in the version list obtained during the system version update to obtain an HMAC set. The version list includes the version number of the updated version and the version numbers of each earlier version of the updated version. The key used by the HMAC algorithm is generated by the electronic device and is uniquely associated with the electronic device. When it is determined that the HMAC set includes a first HMAC, the system version is allowed to be upgraded to the updated version, where the first HMAC is the HMAC corresponding to the version number of the current system version stored on the electronic device; otherwise, the system version is not allowed to be updated.

2. The method according to claim 1, characterized in that, The upgrade flag is signed using an RSA encryption algorithm, which employs a first hash algorithm. Verification of the upgrade flag specifically includes: When the upgrade flag is obtained, the upgrade flag is decrypted using the public key of the RSA encryption algorithm to obtain the first hash value; The original upgrade flag is processed using the first hash algorithm to obtain a second hash value, wherein the original upgrade flag is not signed using the RSA encryption algorithm. If the first hash value is the same as the second hash value, the upgrade flag verification is determined to be successful; otherwise, the upgrade flag verification is determined to be unsuccessful.

3. The method according to claim 2, characterized in that, The verification of the upgrade flag specifically includes: If the upgrade flag is not obtained, it is determined that the upgrade flag verification failed.

4. The method according to claim 2, characterized in that, After the verification passes, the method further includes: Upgrade the system version or revert to the first version. The HMAC algorithm is used to process the version number of the first version to obtain the HMAC corresponding to the version number of the first version. Update the first HMAC to the HMAC corresponding to the version number of the first version.

5. The method according to claim 4, characterized in that, After updating the first HMAC to the HMAC corresponding to the version number of the first version, the method further includes: Remove the upgrade flag from the electronic device.

6. The method according to claim 2, characterized in that, After determining that the HMAC set includes the first HMAC, the method further includes: Upgrade the system version to version 2; The version number of the second version is processed using the HMAC algorithm to obtain the HMAC corresponding to the version number of the second version. Update the first HMAC to the HMAC corresponding to the version number of the second version.

7. The method according to claim 2, characterized in that, When the current system version is a production test version, the first HMAC stored in the electronic device is empty data. When the verification passes, the method further includes: Update the system version to version 3; The HMAC algorithm is used to process the version number of the third version to obtain the HMAC corresponding to the version number of the third version. Write the HMAC corresponding to the version number of the third version to the data storage area as the first HMAC of the electronic device.

8. The method according to claim 7, characterized in that, After writing the HMAC corresponding to the version number of the third version to the data storage area, the method further includes: Remove the upgrade flag from the electronic device.

9. The method according to claim 1, characterized in that, The current system version is version 4. When the verification passes, or when it is determined that the HMAC set includes the first HMAC, the method further includes: Update the system version to the fourth version mentioned above; The HMAC algorithm is used to process the version number of the fourth version to obtain the HMAC corresponding to the version number of the fourth version. Update the first HMAC to the HMAC corresponding to the version number of the fourth version.

10. An electronic device, characterized in that, The electronic device is used to run a program, which, when running, executes the system version update method according to any one of claims 1-9.

11. A storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the method for updating the system version as described in any one of claims 1 to 9.

Images