Library file encryption method, decryption method and encryption device

Abstract

The present application discloses a library file encryption method, a library file decryption method, and a library file encryption device. The method encrypts a library file using a public key to form an encrypted library file; obtains the application's call information for the encrypted library file and generates interface information; saves the encrypted library file and the interface information into a firmware file respectively; and burns the firmware file into a readable and writable memory inside or external to the SoC chip, so that when the firmware file is loaded into the random access memory inside or external to the SoC chip, the encrypted library file is decrypted using a private key to obtain the decrypted library file. While allowing the external release of library files, the present application prevents the contents of the library files from being leaked. It can not only ensure the convenience and efficiency of secondary development using library files, but also improve the security of library files.

Description

Technical Field

[0001] The present application relates to the field of embedded technology, and in particular to a library file encryption method, a library file decryption method, and a library file encryption device. Background Art

[0002] There are many solutions for software protection, which can be divided into encryption of software running on a computer according to their application scenarios. For example, Chinese patent CN103425911A involves using an encryption device to encrypt software running on a computer.

[0003] Another application scenario involves protecting applications running in embedded systems. In the current embedded market, some important framework programs or core algorithm programs are released as library files to prevent the leakage of core algorithms or key parameters and protect intellectual property. For example, the voice wake-up function of Espressif's ESP32 chip is released as a standard static library in the .a file format. Compared to directly releasing source code, releasing standard library files can provide a certain degree of confidentiality. However, users can still analyze the algorithms and parameters contained in standard library files through disassembly, and some decompilation techniques can even directly translate library files into higher-level languages ​​such as C. Therefore, simply releasing library files without the source files still fails to protect core algorithms and parameters.

[0004] One way to protect programs in embedded systems is to encrypt the entire Flash memory of the firmware, including the library files. For example, the Espressif ESP32 Flash Encryption Guide (this technical document was published on July 27, 2017 and can be downloaded from the following URL: https: / / www.espressif.com / sites / default / files / documentation / esp32_flash_encryption_guide_cn.pdf), the Flash encryption mechanism includes storing the encryption key in an area inside the chip that cannot be read or written by software. The user burns the plaintext data into the chip to start the encryption function, and the boot loader encrypts the data in the original Flash location when it is first started. However, this overall encryption of the Flash requires the user to burn the library file into the chip in the form of plaintext data, so there is a possibility that the library file has been leaked before it is linked into the firmware, and the library file cannot be protected. Chinese patent CN112948893A also provides a similar method for encrypting the firmware as a whole. In addition, Chinese patent CN105683990B discloses a method for protecting dynamic libraries relative to static analysis tools. When someone who attempts to maliciously attack the program destroys a part of the application responsible for decrypting and loading the dynamic library, modifies and loads the decrypted dynamic library file, then the application has no choice but to be executed. In order to overcome this problem, the patent stores the dynamic library to be protected, which is responsible for the core functions of the program and needs to be protected, in the security dynamic library responsible for security, and the encryption key is stored in the security dynamic library for decryption.

[0005] Another method is software shell technology, which directly injects a piece of binary code into the target executable file ELF (Executable and Linkable Format), then changes the program's entry address to the address of the inserted binary code, and then jumps to the program's original entry address to execute the actual program part. The injected binary code is the core of this method, generally containing a decryption or decompression program, instruction code and some anti-dynamic tracking code. This method can effectively prevent static analysis, but its anti-dynamic tracking ability is average. Chinese patents CN102136053A and CN105825087A all use shell technology. This encryption method is mainly performed on the target executable file, which is quite different from directly encrypting the library file. Similarly, Chinese patent CN112989291A discloses a dynamic link library file decryption method, encryption method, and decryption device. The main method is that the encryption device adds a first target section in ELF format to the dynamic link library file and encrypts the first target section to obtain a second target section. As a result, the target dynamic link library file generated based on the second target section is an incomplete library file, which makes it impossible for static analysis and cracking tools such as IDA to open it or report an error when opened, thereby improving the security of the target dynamic link library file. This method obtains the first target and second target sections by adding the contents of the library file to prevent decompilation.

[0006] Another commonly used encryption method is to use an additional encryption chip. For example, Chinese patents CN101211396A and CN103198242A both disclose methods of using chip encryption, the main purpose of which is to prevent the program in the main chip from being copied. Both patents include a main chip and an encryption chip. In order to prevent the encryption function of the encryption chip from being leaked, the main chip and the encryption chip are paired to identify the library file of the encryption function. Similarly, Chinese patent CN102289625A integrates an encryption and decryption device inside the memory chip. The communication data between the memory chip and the main controller needs to be encrypted or decrypted by the encryption and decryption device. Similar prior art includes Chinese patent CN106372464A, which uses an additional encryption IC integrated circuit to generate a random number key to implement usage restrictions on static library files.

[0007] The above-mentioned method has been widely used, but it also has some problems. Currently, the consumer electronics industry largely adopts a multi-party collaborative model. For example, chip manufacturers provide chips with specific functions and library files that implement these functions. Algorithm manufacturers then conduct secondary development based on the chip manufacturer's library files. Ultimately, the application manufacturer obtains firmware, including the library files, from the algorithm manufacturer and burns this firmware into the chip received from the chip manufacturer to create the final electronic product. If the firmware is encrypted as a whole, the library files may be leaked before they are linked into the firmware, thus providing no protection for the library files. If software packaging is used, a customized and complex decryption method is required. Furthermore, the use of encryption chips will increase costs.

[0008] It should be understood that the technical problems listed above are only examples and not limitations of the present invention, and the present invention is not limited to technical solutions that solve all of the above technical problems at the same time. The technical solution of the present invention can be implemented to solve one or more of the above or other technical problems. Summary of the Invention

[0009] To solve the above and other problems, this application provides a library file encryption method, comprising the following steps:

[0010] Use the public key to encrypt the library file to form an encrypted library file;

[0011] Obtaining the application's call information on the encryption library file and generating interface information;

[0012] Saving the encrypted library file and the interface information into firmware files respectively;

[0013] Burning the firmware file into a readable and writable memory inside or external to the SoC chip, so that when the firmware file is loaded into the random access memory inside or external to the SoC chip, the encrypted library file is decrypted using the private key to obtain the decrypted library file;

[0014] The private key is stored in a read-only memory of the SoC chip, and the private key matches the public key.

[0015] Optionally, the library file is a static library file, wherein the static library file is a collection of one or more target files, and the target files are obtained by compiling source code files.

[0016] Optionally, the read-only memory of the SoC chip further stores a boot program, and the boot program is used to guide the firmware file to be loaded into the random access memory.

[0017] Optionally, the boot program is further configured to link the decrypted library file into the application according to the interface information.

[0018] Optionally, the library file is a dynamic library file.

[0019] Optionally, after obtaining the decrypted library file, the method further includes:

[0020] The application program is directly linked to the decrypted library file.

[0021] Optionally, the public key and the private key are obtained based on an asymmetric encryption algorithm, and the public key and the private key have a unique corresponding relationship.

[0022] Optionally, the asymmetric encryption algorithm is an RSA encryption algorithm or an ED25519 encryption algorithm.

[0023] The present application also provides a library file decryption method, which uses a private key to decrypt an encrypted library file, wherein the encrypted library file is obtained according to any of the above-mentioned library file encryption methods.

[0024] The present application also provides a library file encryption device, the device comprising:

[0025] A readable and writable memory for storing a firmware file, wherein the firmware file includes an encrypted library file and interface information, the interface information recording information of an application calling the encrypted library file, and the encrypted library file is a file obtained by encrypting the library file using a public key;

[0026] a read-only memory for storing a private key, the private key matching the public key;

[0027] and a processor, wherein the processor is configured to decrypt the encrypted library file using the private key when loading the firmware file into a random access memory inside or external to the SoC chip to obtain a decrypted library file.

[0028] Optionally, the read-only memory is further used to store a boot program, and the boot program is used to guide the firmware file to be loaded into the random access memory when the encrypted library file is a static library file.

[0029] Optionally, the boot program is further configured to link the decrypted library file into the application according to the interface information.

[0030] Optionally, the read-only memory is a ROM memory, an OTP memory or an eFuse memory.

[0031] The library file encryption method provided by this application physically burns the decryption key into the chip instead of storing the encryption key in another dynamic library file, eliminating the need to set up a security dynamic library. Furthermore, this application does not require changing the contents of the library file, but rather encrypts the entire firmware containing the library file, reducing the complexity of decryption. Furthermore, the library file of this application is encrypted before being loaded into the chip, and then loaded into the chip, rather than being compiled and executed within the chip. This eliminates the need for coordination between the main chip and the encryption chip, or between the storage chip and the main controller, and decryption of the encrypted library file can be completed on a single chip executing the program. This allows the release of library files while preventing the contents of the library files from being leaked. This ensures the convenience and efficiency of secondary development using library files while also improving the security of the library files. Furthermore, this application also provides a library file decryption method and a library file encryption device with the above-mentioned technical effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Hereinafter, the present application will be further explained based on embodiments with reference to the accompanying drawings.

[0033] Figure 1 A flowchart schematically illustrates a specific implementation of the library file encryption method provided by the present application;

[0034] Figure 2 A flowchart schematically illustrating another specific implementation of the library file encryption method provided by the present application;

[0035] Figure 3 Schematically illustrates the encryption process diagram in the method provided by this application;

[0036] Figure 4 Schematically illustrates a firmware file diagram in the method provided by this application;

[0037] Figure 5 Schematically illustrates the decryption and decompression process in the method provided by this application;

[0038] Figure 6 Schematically illustrates a schematic diagram of the implementation process of the method provided in the specific scenario provided by this application;

[0039] Figure 7 A flowchart schematically illustrates a specific implementation of the library file encryption method provided by the present application;

[0040] Figure 8 The structural diagram of the library file encryption device provided by this application is schematically shown. DETAILED DESCRIPTION

[0041] The method and apparatus of the present application will be described in detail below with reference to the accompanying drawings and specific implementations. It should be understood that the embodiments shown in the accompanying drawings and described below are merely illustrative and not intended to limit the present application.

[0042] Figure 1 A flowchart showing a specific implementation of the library file encryption method provided by this application is shown. Figure 1 , the method comprises the following steps:

[0043] S101: Encrypt the library file using the public key to form an encrypted library file.

[0044] It is understood that the public key in this application can be pre-generated. Specifically, a pair of public and private keys can be obtained using an asymmetric encryption algorithm, with a unique correspondence between the two. The library file is encrypted based on the generated public key to generate an encrypted library file.

[0045] In the embodiments of the present application, the library file can be a static library file or a dynamic library file, which does not affect the implementation of the present application.

[0046] S102: Obtain the application's call information for the encryption library file and generate interface information.

[0047] The interface information is the interface of the function to be called by the application. It is understood that a library file may contain multiple functions, but the application may only use some of these functions during execution. The compiler can generate the interface information, for example, in a txt file, based on the application's calls to the functions in the library file.

[0048] S103: Save the encryption library file and the interface information into firmware files respectively.

[0049] The encrypted library file and the interface information are saved as independent parts in the firmware file. Of course, in addition to the encrypted library file and the interface information, the firmware file may also include other information, which is not limited here.

[0050] S104: Burn the firmware file into the internal or external readable and writable memory of the SoC chip, so that when the firmware file is loaded into the internal or external random access memory of the SoC chip, the encrypted library file is decrypted using the private key to obtain the decrypted library file.

[0051] In this step, the readable and writable memory may specifically be a flash memory (Flash) or an electrically erasable programmable read-only memory (EEROM).

[0052] The private key is stored in a read-only memory of the SoC chip, and the private key matches the public key. The read-only memory may be a ROM memory, an OTP memory, or an eFuse memory.

[0053] When the application is executed, the application stored in Flash is loaded into the random access memory (RAM), and the firmware file is also loaded into the RAM. During the loading process, the encrypted library file is decrypted using the private key to obtain the decrypted library file. It is understood that the decryption process can be performed simultaneously with the loading process.

[0054] As a specific embodiment, the public key and the private key are obtained based on an asymmetric encryption algorithm, and the public key and the private key have a unique correspondence. Specifically, the asymmetric encryption algorithm can be an RSA encryption algorithm or an ED25519 encryption algorithm. Of course, other encryption algorithms can also be used, which are not limited here.

[0055] Compared with the existing technology of storing the protected dynamic library responsible for the core functions of the program and requiring protection in the security dynamic library responsible for security, the library file encryption method provided in this application physically burns the decryption key into the chip instead of storing the encryption key in another dynamic library file, eliminating the need to set up a security dynamic library.

[0056] Compared with the existing encryption method using software packing technology, this application does not need to change the content of the library file, but encrypts the firmware where the library file is located as a whole, and reduces the complexity of decryption.

[0057] In addition, compared with the existing encryption scheme using an additional encryption chip, the library file of the present application is encrypted before being loaded into the chip, and then loaded into the chip, rather than being compiled and executed inside the chip. There is no need for cooperation between the main chip and the encryption chip or between the storage chip and the main controller. The decryption of the encrypted library file can be completed only on a single chip that executes the program.

[0058] In summary, the method provided by this application allows the external release of library files while preventing the leakage of the contents of the library files. This ensures the convenience and efficiency of secondary development using library files while improving the security of the library files.

[0059] Figure 2 A flowchart illustrating another specific embodiment of the library file encryption method provided by this application is provided. In this specific embodiment, the library file is a static library file, wherein the static library file is a collection of one or more target files obtained by compiling source code files. The method includes the following steps:

[0060] S201: Encrypt the library file using the public key to form an encrypted library file.

[0061] As a specific implementation method, the static library file is a collection of multiple target files, such as Figure 3 The encryption process diagram of the method provided in this application is shown as follows: wherein the target file is obtained by compiling the source code file.

[0062] S202: Obtain the application's call information on the encryption library file and generate interface information.

[0063] S203: Save the encryption library file and the interface information into firmware files respectively.

[0064] After obtaining the encrypted library file and interface information, the encrypted library file and interface information can be saved as independent parts in the firmware file, such as Figure 4 The firmware file diagram in the method provided in this application is shown.

[0065] S204: Burn the firmware file into an internal or external readable and writable memory of the SoC chip.

[0066] Specifically, the firmware file may be burned into the internal or external Flash of the SoC chip, and of course may be other readable and writable memories, which are not limited here.

[0067] S205: When the boot program is used to load the firmware file into the internal or external random access memory of the SoC chip, the encrypted library file is decrypted using a private key to obtain a decrypted library file.

[0068] The read-only memory of the SoC chip also stores a boot program, which can also be solidified on the read-only memory.

[0069] S206: The boot program links the decrypted library file to the application according to the interface information.

[0070] At startup, the boot program loads the contents stored in the read-write memory into the random access memory. When processing the library file, the private key solidified in the read-only memory is used to decrypt the encrypted library file, and then decompress it to obtain all the target files. At the same time, the boot program acts as a linker, analyzing the target file and interface information, and adding the obtained .text (code segment), .data (data segment) and .bss (symbol segment) to the application in the random access memory to obtain a complete main program, thereby running the entire system. Figure 5 The decryption and decompression process in the method provided in this application is shown in the schematic diagram.

[0071] Reference Figure 6 The present application provides a schematic diagram of the implementation of the method under the specific scenario. In combination with the specific scenario, the implementation process of the method provided by the present application can be specifically as follows: the chip manufacturer generates a public key and a private key for asymmetric encryption at the beginning of the chip design, and solidifies the private key into the read-only memory of the chip. After solidification, the archive can be destroyed to prevent the private key from being leaked. The public key is released to algorithm manufacturers and other manufacturers who need to release library files. The application manufacturer obtains the encrypted library file from the algorithm manufacturer, and burns it as a firmware file into the chip obtained by the chip manufacturer to form a product. During the loading process, the chip boot program can use the solidified private key for decryption and link the library file to the application.

[0072] Figure 7 A flowchart showing another specific implementation of the library file encryption method provided in this application is shown. In this specific implementation, the library file is a dynamic library file.

[0073] S701: Encrypt the library file using the public key to form an encrypted library file.

[0074] S702: Obtain the application's call information for the encryption library file and generate interface information.

[0075] S703: Save the encryption library file and the interface information into firmware files respectively.

[0076] S704: Burn the firmware file into the internal or external readable and writable memory of the SoC chip.

[0077] S705: When the firmware file is loaded into the internal or external random access memory of the SoC chip, the encrypted library file is decrypted using the private key to obtain the decrypted library file.

[0078] S706: The application program is directly linked to the decrypted library file.

[0079] For dynamic library files, after the library file is encrypted, you only need to package the application with the encrypted library file. After the encrypted library file is decrypted and the decrypted library file is obtained, the application can directly link with the decrypted library file without the need for a bootloader.

[0080] For dynamic library files, the library file encryption method provided in this application can have higher operating efficiency.

[0081] The present application also provides a library file decryption method, which uses a private key to decrypt an encrypted library file, wherein the encrypted library file is obtained according to any of the above-mentioned library file encryption methods.

[0082] It can be understood that the library file decryption provided in this application corresponds to the above-mentioned library file encryption. Its specific implementation method can refer to the above content and will not be repeated here.

[0083] This application also provides a library file encryption device, such as Figure 8 As shown in the structural diagram of the library file encryption device provided in this application, the library file encryption device includes:

[0084] A read-write memory 801 is used to store firmware files, wherein the firmware files include an encrypted library file and interface information, the interface information records the application's call information for the encrypted library file, and the encrypted library file is a file obtained by encrypting the library file using a public key;

[0085] a read-only memory 802 for storing a private key, the private key matching the public key;

[0086] The processor 803 and the external interface 804 are used to decrypt the encrypted library file using the private key when loading the firmware file into the internal or external random access memory 805 of the SoC chip to obtain the decrypted library file.

[0087] Optionally, the read-only memory 802 is further used to store a boot program, and the boot program is used to guide the firmware file to be loaded onto the random access memory 805 when the encrypted library file is a static library file.

[0088] Optionally, the boot program is further configured to link the decrypted library file into the application according to the interface information.

[0089] Optionally, the read-only memory 802 is a ROM memory, an OTP memory or an eFuse memory.

[0090] It can be understood that the library file encryption device provided in this application corresponds to the above-mentioned library file encryption method. Its specific implementation method can refer to the above content and will not be repeated here.

[0091] The encrypted library file of this application is then loaded into the chip, rather than compiled and executed internally. This eliminates the need for coordination between the main chip and the encryption chip, or between the storage chip and the main controller. Decryption of the encrypted library file can be completed solely on the single chip that executes the program. This allows for external release of the library file while preventing the contents of the library file from being leaked. This ensures the convenience and efficiency of secondary development using the library file while also improving the security of the library file.

[0092] Although various embodiments of various aspects of the present application have been described for the purposes of this disclosure, it should not be understood that the teachings of this disclosure are limited to these embodiments. Features disclosed in a specific embodiment are not limited to that embodiment, but can be combined with features disclosed in different embodiments. For example, one or more features and / or operations of the method according to the present application described in one embodiment may also be applied individually, in combination or as a whole in another embodiment. It should be understood by those skilled in the art that there are possible more optional implementations and variations, and various changes and modifications may be made to the above-mentioned system without departing from the scope defined by the claims of this application.

Claims

1. A library file encryption method, characterized in that: The following steps are involved: Use the public key to encrypt the library file to form an encrypted library file; Obtaining the application's call information on the encryption library file and generating interface information; Saving the encrypted library file and the interface information into firmware files respectively; Burning the firmware file into a readable and writable memory inside or external to the SoC chip, so that when the firmware file is loaded into the random access memory inside or external to the SoC chip, the encrypted library file is decrypted using the private key to obtain the decrypted library file; The private key is stored in a read-only memory of the SoC chip, and the private key matches the public key.

2. A library file encryption method according to claim 1, characterized in that: The library file is a static library file, wherein the static library file is a collection of one or more target files, and the target files are obtained by compiling source code files.

3. A library file encryption method according to claim 2, characterized in that: The read-only memory of the SoC chip also stores a boot program, and the boot program is used to guide the firmware file to be loaded into the random access memory.

4. A library file encryption method according to claim 3, characterized in that: The boot program is further configured to link the decrypted library file to the application program according to the interface information.

5. A library file encryption method according to claim 1, characterized in that: The library file is a dynamic library file.

6. A library file encryption method according to claim 5, characterized in that: After obtaining the decrypted library file, the following steps are also included: The application program is directly linked to the decrypted library file.

7. A library file encryption method according to any one of claims 1 to 6, characterized in that: The public key and the private key are obtained based on an asymmetric encryption algorithm, and the public key and the private key have a unique corresponding relationship.

8. A library file encryption method according to claim 7, characterized in that: The asymmetric encryption algorithm is the RSA encryption algorithm or the ED25519 encryption algorithm.

9. A library file decryption method, characterized in that: A private key is used to decrypt an encrypted library file, wherein the encrypted library file is obtained according to a library file encryption method according to any one of claims 1 to 8.

10. A library file encryption device, characterized in that: The device comprises: A read-write memory, configured to store a firmware file burned thereon, wherein the firmware file includes an encrypted library file and interface information, the interface information recording information of an application calling the encrypted library file, the encrypted library file being a file obtained by encrypting the library file using a public key, wherein the read-write memory is an internal or external read-write memory of the SoC chip; a read-only memory, configured to store a private key, the private key matching the public key, wherein the read-only memory is a read-only memory of the SoC chip; and a processor, wherein the processor is configured to decrypt the encrypted library file using the private key when loading the firmware file into a random access memory inside or external to the SoC chip to obtain a decrypted library file.

11. A library file encryption device according to claim 10, characterized in that: The read-only memory is further used to store a boot program, and the boot program is used to guide the firmware file to be loaded onto the random access memory when the encrypted library file is a static library file.

12. A library file encryption device according to claim 11, characterized in that: The boot program is further configured to link the decrypted library file into the application program according to the interface information.

13. A library file encryption device according to claim 10, characterized in that: The read-only memory is a ROM memory, an OTP memory or an eFuse memory.

Images