Electronic device and its MCU firmware protection method

Abstract

The present invention relates to an electronic device and an MCU firmware protection method. The MCU firmware protection method includes: in the production test stage of the electronic device, receiving the firmware ciphertext sent by the production test tool and storing it in the FLASH. Wherein, the production test tool uses the ID of the MCU as the key to encrypt the key code and / or key data of the MCU firmware to generate the firmware ciphertext; in the usage stage of the electronic device, if it is necessary to run the key code or use the key data, then use its own ID as the key to decrypt the firmware ciphertext stored in the FLASH to obtain the key code or the key data, and run the key code or use the key data. Implementing the technical solution of the present invention not only ensures the normal operation of the MCU of this electronic device, but also prevents crackers from directly copying the MCU firmware.

Description

Technical Field

[0001] The present invention relates to the field of data security, and in particular to an electronic device and an MCU firmware protection method thereof. Background Art

[0002] For the protection of MCU firmware, multi-level protection is often adopted: the first level is read protection, that is, to prevent others from reading; the second level is code-level protection, that is, even if others read the program of this MCU, they cannot copy it to another MCU for normal execution. Currently, the mainstream method of code-level protection is: when running, compare the unique ID of the MCU (for example, the 96-bit unique ID of STM32), and if it is not the ID of the MCU itself, it will not execute. Although this method can play a certain protective role, for high-value MCU firmware, it is still very easy to be cracked by disassembly. For example, for the ARM instruction set, the disassembly code position for comparing the unique ID can be found, and then the 4-bit condition code can be modified to "AL, unconditional execution" to achieve cracking. Therefore, the security is still not high. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide an MCU firmware protection method for an electronic device in view of the defect of low security of existing MCU firmware.

[0004] The technical solution adopted by the present invention to solve its technical problems is: to construct an MCU firmware protection method for an electronic device, including:

[0005] Step S10. In the production test stage of the electronic device, receive the firmware ciphertext sent by the production test tool and store it in the FLASH, where the production test tool encrypts the key code and / or key data of the MCU firmware with the ID of the MCU to generate the firmware ciphertext;

[0006] Step S20. In the usage stage of the electronic device, if it is necessary to run the key code or use the key data, decrypt the firmware ciphertext stored in the FLASH with its own ID as the key to obtain the key code or the key data, and run the key code or use the key data.

[0007] Preferably, in step S20, after obtaining the key code or the key data, it further includes:

[0008] Store the key code or the key data in the RAM.

[0009] Preferably, the storing the key code or the key data in the RAM includes:

[0010] Randomly select a storage address in the RAM, and store the key code or the key data at the storage address.

[0011] Preferably, the step S20 includes:

[0012] Step S21. If it is necessary to run the key code or use the key data, determine whether the decrypted key code or key data is stored in the RAM. If so, execute step S22; if not, execute step S23;

[0013] Step S22. Directly run the key code stored in the RAM or use the key data, and then execute step S24;

[0014] Step S23. Use its own ID as the key to decrypt the firmware ciphertext stored in the FLASH to obtain the key code or the key data, store it in the RAM, and moreover, run the key code or use the key data;

[0015] Step S24. Update the current running times of the key code or the current usage times of the key data, and determine whether the current running times or the current usage times reach the preset number of times value. If so, execute step S25; if not, end;

[0016] Step S25. Clear the decrypted key code or key data stored in the RAM.

[0017] Preferably, the step S10 includes:

[0018] Step S11. Receive the ID reading instruction sent by the production test tool;

[0019] Step S12. Send the ID of the MCU to the production test tool, so that the production test tool uses the ID of the MCU as the key to encrypt the key code and / or key data of the MCU firmware to generate the firmware ciphertext;

[0020] Step S13. Receive the firmware ciphertext sent by the production test tool and store it in the FLASH.

[0021] Preferably, in the production test stage of the electronic device, the production test tool generates the firmware ciphertext in the following manner:

[0022] Use the ID of the MCU as the key and use the XOR algorithm to encrypt at least a part of the key code and / or key data to generate the firmware ciphertext;

[0023] During the usage stage of the electronic device, the MCU obtains the key code or the key data through the following method:

[0024] Using its own ID as the key, decrypt at least a part of the firmware ciphertext using the XOR algorithm to obtain the key code or the key data.

[0025] Preferably, during the production test stage of the electronic device, the production test tool generates the firmware ciphertext through the following method:

[0026] Using the ID of the MCU as the key, encrypt at least a part of the key code and / or key data using the XOR algorithm to obtain the first intermediate data;

[0027] Perform FEC encoding on the first intermediate data to obtain the second intermediate data;

[0028] Generate random data, and fill the random data into the second intermediate data according to a preset rule to generate the firmware ciphertext;

[0029] During the usage stage of the electronic device, the MCU obtains the key code or the key data through the following method:

[0030] Select the random data from the firmware ciphertext according to a preset rule, and discard the random data to obtain the second intermediate data;

[0031] Perform FEC decoding on the second intermediate data to obtain the first intermediate data;

[0032] Using its own ID as the key, decrypt a part of the first intermediate data using the XOR algorithm to obtain the key code or the key data.

[0033] Preferably, the performing FEC encoding on the first intermediate data to obtain the second intermediate data includes:

[0034] Perform FEC encoding on the first intermediate data to obtain the encoded data, where the data length of the encoded data is m;

[0035] Randomly select n bits of data from the m bits of data of the encoded data, and replace them with random numbers to obtain the second intermediate data, where n < m - l, and l is the data length of the key code and / or key data.

[0036] The present invention also constructs an electronic device, including an MCU and a FLASH, where,

[0037] The FLASH is used to store the firmware ciphertext, where the firmware ciphertext is generated by a production test tool encrypting the critical code and / or critical data of the MCU firmware with the ID of the MCU during the production test phase of the electronic device;

[0038] The MCU is used to, during the usage phase of the electronic device, if it is necessary to run the critical code or use the critical data, decrypt the firmware ciphertext stored in the FLASH with its own ID as the key to obtain the critical code or the critical data, and then run the critical code or use the critical data.

[0039] Preferably, it further includes a RAM, and,

[0040] The MCU is used to, after obtaining the critical code or the critical data, randomly select a storage address in the RAM and store the critical code or the critical data at the storage address.

[0041] In the technical solution provided by the present invention, the firmware ciphertext is stored in the FLASH, and this firmware ciphertext is generated by a production test tool encrypting the critical code and / or critical data of the MCU firmware with the ID of the MCU during the production test phase of the electronic device. During the usage phase of the electronic device, the MCU decrypts the firmware ciphertext stored in the FLASH with its own ID as the key only when it is necessary to run the critical code or use the critical data, so as to obtain the required critical code or critical data, and then run the critical code or use the critical data. In this way, even if a cracker obtains the data (firmware ciphertext) stored in the FLASH, since decrypting the firmware ciphertext requires the ID of the original MCU and the cracker does not know the ID of the original MCU and also does not know the decryption algorithm, it is still impossible to perform disassembly, and thus impossible to copy the MCU firmware. Therefore, it not only ensures the normal operation of the MCU of this electronic device, but also prevents the cracker from directly copying the MCU firmware. Description of the Drawings

[0042] In order to more clearly illustrate the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings. In the drawings:

[0043] Figure 1 It is the flowchart of the first embodiment of the method for protecting the MCU firmware of the electronic device of the present invention. Detailed Embodiments

[0044] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0045] Figure 1 FIG. 4 is a flowchart of the first embodiment of the MCU firmware protection method of the electronic device of the present invention. The MCU firmware protection method includes:

[0046] Step S10. In the production test stage of the electronic device, receive the firmware ciphertext sent by the production test tool and store it in the FLASH. Wherein, the production test tool encrypts the key code and / or key data of the MCU firmware with the ID of the MCU to generate the firmware ciphertext;

[0047] In this step, it should be noted that the production of the firmware part of the electronic device is divided into two stages: First, the mass production firmware burning stage; Second, the production test stage.

[0048] In the mass production firmware burning stage, in order to support the parallel burning of a large number of firmwares during mass production, there is no unique ID distinction, and the firmware burned into each MCU is exactly the same. At the same time, this also makes it more convenient to manage the firmware. Because in the production of electronic devices now, the outsourcing mode is often adopted, and research and development are separated from production, and the firmware may be leaked by the factory. After the mass production firmware is burned in, the MCU firmware is incomplete and still lacks some key data and key code. At this time, the MCU can only run some ordinary functions, such as the testing of each component.

[0049] In the production test stage, each function of the electronic device needs to be tested one by one. In addition to verifying the functions, encrypted key data and key code will also be generated and written based on the unique ID of the MCU. Specifically, when the production test tool encrypts the key code and some key data, it uses the unique ID of the MCU as the KEY. Among them, the key code is "position-independent code (PIC)"; the key data is some necessary data required for normal operation. For example, some constant values used by the firmware. Specifically, it can be multiple private keys generated by using the corresponding algorithm (such as the Hash algorithm) based on the unique ID of the MCU. These key data will be used by the MCU firmware in some scenarios, so the MCU needs to be able to decrypt it. In this way, since the key code and / or key data of the MCU firmware are supplemented in the production test stage, the firmware becomes a complete and encrypted firmware.

[0050] Step S20. During the usage stage of the electronic device, if it is necessary to run the critical code or use the critical data, use its own ID as the key to decrypt the firmware ciphertext stored in the FLASH to obtain the critical code or the critical data, and then run the critical code or use the critical data.

[0051] In this step, for the MCU of this electronic device, since it knows the key (the ID of the MCU) and the decryption algorithm, it can normally decrypt the encrypted MCU firmware (including critical code and / or critical data) during operation and load and execute it. For an illegal cracker, even if it reads the data stored in the FLASH (firmware ciphertext), since decrypting this firmware ciphertext requires the original MCU's ID, and it doesn't know the original MCU's ID and the decryption algorithm, it still can't disassemble it, so it can't directly copy the MCU firmware. In this way, it not only ensures the normal operation of the MCU of this electronic device but also prevents the cracker from directly copying the product firmware.

[0052] Further, in an optional embodiment, in step S20, after obtaining the critical code or the critical data, it further includes: storing the critical code or the critical data in the RAM. In this embodiment, when the MCU first needs to run the critical code or use the critical data, it can use its own ID as the key to decrypt the firmware ciphertext stored in the FLASH to obtain the required critical code or critical data, and then run the critical code or use the critical data. When the MCU needs to run the critical code or use the critical data again, it can directly run the critical code stored in the RAM or use the critical data. In this way, since the RAM has the characteristic that data is lost after power-off, the illegal cracker can't read the data in the RAM, so the security of the critical code and / or critical data is ensured. At the same time, during subsequent operations, since the critical code in the RAM can be directly executed or the critical data in the RAM can be directly used without decrypting and executing separately each time, the operation efficiency is also ensured.

[0053] Further, in an optional embodiment, in step S20, when storing the decrypted critical code or critical data, a storage address can be randomly selected in the RAM, and the critical code or critical data is stored at this storage address. In this way, since the decrypted critical code (PIC code can be executed at any position) or critical data is stored at a random RAM address, the security of the critical code and / or critical data can be further improved.

[0054] Further, in an optional embodiment, step S20 includes:

[0055] Step S21. If it is necessary to run the key code or use the key data, determine whether the decrypted key code or key data is stored in the RAM. If so, execute Step S22; if not, execute Step S23;

[0056] Step S22. Directly run the key code stored in the RAM or use the key data, and then execute Step S24;

[0057] Step S23. Use its own ID as the key to decrypt the firmware ciphertext stored in the FLASH to obtain the key code or key data, store it in the RAM, and moreover, run the key code or use the key data;

[0058] Step S24. Update the current running times of the key code or the current usage times of the key data, and determine whether the current running times or the current usage times reach the preset number of times. If so, execute Step S25; if not, end, where the initial value of the current running times of the key code or the current usage times of the key data is 0;

[0059] Step S25. Clear the decrypted key code or key data stored in the RAM.

[0060] In this embodiment, the decrypted key code or key data stored in the RAM is automatically cleared after running a certain number of times, and is decrypted and loaded into the RAM again when it is needed to run next time. Therefore, the best balance can be achieved between the security and the running efficiency of the key code and / or key data.

[0061] Further, in an alternative embodiment, Step S10 includes:

[0062] Step S11. Receive the ID reading instruction sent by the production test tool;

[0063] Step S12. Send the ID of the MCU to the production test tool, so that the production test tool uses the ID of the MCU as the key to encrypt the key code and / or key data of the MCU firmware to generate the firmware ciphertext;

[0064] Step S13. Receive the firmware ciphertext sent by the production test tool and store it in the FLASH.

[0065] In this embodiment, during the production test phase, the communication process between the production test tool and the electronic device is as follows: the production test tool issues an ID reading instruction; the electronic device returns the unique ID of the MCU; the production test tool uses the ID of the MCU as the key to encrypt the key code and some key data of the MCU firmware and writes them into the FLASH.

[0066] Further, in an alternative embodiment, during the production test phase of the electronic device, the production test tool generates the firmware ciphertext in the following manner: using the ID of the MCU as the key, encrypting at least a part of the critical code and / or critical data using the XOR algorithm to generate the firmware ciphertext. During the usage phase of the electronic device, the MCU obtains the critical code or the critical data in the following manner: using its own ID as the key, decrypting at least a part of the firmware ciphertext using the XOR algorithm to obtain the critical code or the critical data. In this embodiment, both the production test tool and the MCU use the XOR algorithm to encrypt and decrypt the critical code or critical data.

[0067] Further, in an alternative embodiment, during the production test phase of the electronic device, the production test tool generates the firmware ciphertext in the following manner:

[0068] Using the ID of the MCU as the key, encrypting at least a part of the critical code and / or critical data using the XOR algorithm to obtain the first intermediate data;

[0069] Performing FEC encoding on the first intermediate data to obtain the second intermediate data;

[0070] Generating random data and filling the random data into the second intermediate data according to a preset rule to generate the firmware ciphertext;

[0071] During the usage phase of the electronic device, the MCU obtains the critical code or the critical data in the following manner:

[0072] Selecting the random data from the firmware ciphertext according to a preset rule and discarding the random data to obtain the second intermediate data;

[0073] Performing FEC decoding on the second intermediate data to obtain the first intermediate data;

[0074] Using its own ID as the key, decrypting a part of the first intermediate data using the XOR algorithm to obtain the critical code or the critical data.

[0075] In this embodiment, when encrypting critical code and / or critical data, first use the XOR algorithm to encrypt at least a part of the critical code and / or critical data, and then, based on the protection mechanism of random numbers, add random data to the data after FEC encoding as the final ciphertext. Correspondingly, when decrypting the critical code and / or critical data, first select and discard the random data therein, then perform FEC decoding, and finally use the XOR algorithm to decrypt to obtain the required critical code and / or critical data. This method increases the difficulty of cracking and greatly improves the security of the algorithm, especially suitable for MCUs with limited computing power.

[0076] Further, performing FEC encoding on the first intermediate data to obtain second intermediate data includes:

[0077] Performing FEC encoding on the first intermediate data to obtain encoded data, where the data length of the encoded data is m;

[0078] Randomly select n bits of data from the m bits of data of the encoded data and replace them with random numbers to obtain second intermediate data, where n < m - l, and l is the data length of the critical code and / or critical data.

[0079] In this embodiment, after performing FEC encoding (such as using Reed - solomon encoding), the obtained encoded data can be marked as M, and its data bit length is denoted as m. Then, the data length c of the redundant data in the encoded data M is: c = m - l. The data bit length that the redundant data can correct errors is denoted as n. Obviously, n < c. Therefore, n bits of data can be randomly selected from the total m bits of the encoded M data and replaced with random numbers. Moreover, during decoding, since FEC can correct n bits of data, the first intermediate data can be directly obtained. Therefore, the security of the critical code or critical data can be further improved.

[0080] The present invention also constructs an electronic device, which includes an MCU and a FLASH. The FLASH is used to store the firmware ciphertext, where the firmware ciphertext is generated by encrypting the critical code and / or critical data of the MCU firmware with the ID of the MCU as the key during the production test stage of the electronic device; the MCU is used to decrypt the firmware ciphertext stored in the FLASH with its own ID as the key to obtain the critical code or the critical data and run the critical code or use the critical data when the critical code or the critical data needs to be run or used during the use stage of the electronic device.

[0081] Further, the electronic device of the present invention further includes a RAM, and the MCU is configured to randomly select a storage address in the RAM after obtaining the key code or the key data, and store the key code or the key data in the storage address.

[0082] Further, the MCU is further configured to clear the decrypted key code or key data stored in the RAM when it is determined that the current running times of the key code or the current usage times of the key data reach a preset number of times.

[0083] The foregoing are only preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included within the scope of the claims of the present invention.

Claims

1. A method for protecting the MCU firmware of an electronic device, characterized in that, it includes: Step S10. During the production stage of the electronic device, receive the burning of the mass-produced firmware; During the production test stage of the electronic device, receive the firmware ciphertext sent by the production test tool and store it in the FLASH. Among them, the production test tool uses the ID of the MCU as the key to encrypt the key code and / or key data of the MCU firmware to generate the firmware ciphertext; Step S20. During the usage stage of the electronic device, if it is necessary to run the key code or use the key data, decrypt the firmware ciphertext stored in the FLASH with its own ID as the key to obtain the key code or the key data, store the key code or the key data in the RAM, and run the key code or use the key data; if it is necessary to run the key code or use the key data again, directly run the key code stored in the RAM or use the key data; During the production test stage of the electronic device, the production test tool generates the firmware ciphertext through the following method: Use the ID of the MCU as the key and use the XOR algorithm to encrypt at least a part of the key code and / or key data to obtain the first intermediate data; Perform FEC encoding on the first intermediate data to obtain the second intermediate data; Generate random data and fill the random data into the second intermediate data according to a preset rule to generate the firmware ciphertext; During the usage stage of the electronic device, the MCU obtains the key code or the key data through the following method: Select the random data from the firmware ciphertext according to a preset rule and discard the random data to obtain the second intermediate data; Perform FEC decoding on the second intermediate data to obtain the first intermediate data; Use the ID of itself as the key and use the XOR algorithm to decrypt a part of the first intermediate data to obtain the key code or the key data.

2. The method for protecting the MCU firmware of an electronic device according to claim 1, characterized in that, The storing the key code or the key data in the RAM includes: Randomly select a storage address in the RAM and store the key code or the key data at the storage address.

3. The method for protecting the MCU firmware of an electronic device according to claim 1, characterized in that, The step S20 includes: Step S21. If it is necessary to run the key code or use the key data, judge whether the decrypted key code or key data is stored in the RAM. If so, execute step S22; if not, execute step S23; Step S22. Directly run the key code stored in the RAM or use the key data, and then execute step S24; Step S23. Use its own ID as the key to decrypt the firmware ciphertext stored in the FLASH to obtain the key code or the key data, store it in the RAM, and moreover, run the key code or use the key data; Step S24. Update the current running times of the key code or the current usage times of the key data, and determine whether the current running times or the current usage times reach the preset number of times. If so, execute Step S25; if not, end; Step S25. Clear the decrypted key code or key data stored in the RAM.

4. The MCU firmware protection method for an electronic device according to any one of claims 1-3, characterized in that, the Step S10 includes: Step S11. Receive an ID reading instruction sent by the production test tool; Step S12. Send the ID of the MCU to the production test tool, so that the production test tool uses the ID of the MCU as the key to encrypt the key code and / or key data of the MCU firmware to generate the firmware ciphertext; Step S13. Receive the firmware ciphertext sent by the production test tool and store it in the FLASH.

5. The MCU firmware protection method for an electronic device according to claim 1, characterized in that, the performing FEC encoding on the first intermediate data to obtain second intermediate data includes: Performing FEC encoding on the first intermediate data to obtain encoded data, where the data length of the encoded data is m; Randomly select n bits of data from the m bits of data of the encoded data and replace them with random numbers to obtain second intermediate data, where n < m - l, and l is the data length of the key code and / or key data.

6. An electronic device, characterized in that, it includes an MCU and a FLASH, where, the FLASH is used to store the mass-produced firmware and the firmware ciphertext, where the mass-produced firmware is burned in during the production stage of the electronic device; the firmware ciphertext is generated by the production test tool using the ID of the MCU as the key to encrypt the key code and / or key data of the MCU firmware during the production test stage of the electronic device; the MCU is used to, during the usage stage of the electronic device, if it is necessary to run the key code or use the key data, use its own ID as the key to decrypt the firmware ciphertext stored in the FLASH to obtain the key code or the key data, store the key code or the key data in the RAM, and run the key code or use the key data; if it is necessary to run the key code or use the key data again, directly run the key code stored in the RAM or use the key data; During the production test stage of the electronic device, the production test tool generates the firmware ciphertext in the following manner: Using the ID of the MCU as the key, use the XOR algorithm to encrypt at least a part of the key code and / or key data to obtain first intermediate data; Perform FEC encoding on the first intermediate data to obtain second intermediate data; Generate random data and fill the random data into the second intermediate data according to a preset rule to generate a firmware ciphertext; During the usage stage of the electronic device, the MCU obtains the key code or the key data in the following manner: Select the random data from the firmware ciphertext according to a preset rule and discard the random data to obtain second intermediate data; Perform FEC decoding on the second intermediate data to obtain first intermediate data; Use the XOR algorithm to decrypt a part of the first intermediate data with its own ID as the key to obtain the key code or the key data.

7. The electronic device according to claim 6, wherein, it further includes a RAM, and, the MCU is configured to, after obtaining the key code or the key data, randomly select a storage address in the RAM and store the key code or the key data at the storage address.

Images