Anti-attack method based on FPGA

Abstract

An anti-attack method based on an FPGA comprises the steps that EDA software generates an FPGA configuration file according to codes of a circuit designed by a user, and the FPGA configuration file is stored in a Flash chip; a multi-start identifier is set in the Flash chip; the FPGA is powered on, the multiple start identifiers set in the Flash chip are read, and the original code stream is read according to the multiple start identifiers for configuration; fPGA configuration is completed, and a secret key corresponding to a user design circuit is programmed to a battery backup random access memory through an internal debugging interface; and the FPGA sends reset to the control configurator through an internal debugging interface, reads the multi-start identifier in the Flash chip again, and reads the update code stream for configuration according to the multi-start identifier to realize circuit design by a user. According to the method, multiple times of active configuration are carried out on the FPGA by utilizing the multiple starting functions in the active mode, so that the risk that the FPGA is attacked in the configuration process is reduced, and the function of safely starting the FPGA to operate a user design circuit is realized.

Description

Technical Field

[0001] The present invention belongs to the field of FPGA technology, and in particular relates to an anti-attack method based on FPGA. Background Art

[0002] With the widespread use of FPGAs in fields such as AI, communications, medical devices, and edge computing, the demand for FPGA security is increasing. To load a design into an FPGA for execution, a "bitstream" containing all the FPGA design information is configured into the FPGA. This bitstream is automatically generated by the FPGA design software, so encrypting the bitstream and converting it into ciphertext improves security. The key is written to the FPGA configuration controller via an external debug interface. Therefore, if an external debug interface is left in the system, attackers can arbitrarily update the key or download other bitstreams, or directly analyze information through the external debug interface, resulting in lower security. Summary of the Invention

[0003] This application provides an FPGA-based anti-attack method that uses the multi-start function in active mode to actively configure the FPGA multiple times, reducing the risk of the FPGA being attacked during the configuration process and realizing the function of securely starting the FPGA to run the user-designed circuit.

[0004] This invention aims to solve the problem of multiple active configurations after FPGA power-up when no external debugging interface is available. It can automatically burn keys and load encrypted code streams to configure the FPGA in batches, increasing the difficulty of attack through code stream encryption. It offers flexible key management, ease of use, and greatly improved security during the configuration process, making it highly practical.

[0005] Other purposes and advantages of the present invention can be further understood from the technical features disclosed in the present invention.

[0006] To achieve one, part, or all of the above purposes or other purposes, the present invention provides an FPGA-based anti-attack method.

[0007] An FPGA-based anti-attack method, comprising: Step S1: The EDA software generates an FPGA configuration file based on the user's circuit design code and stores it in the Flash chip. The configuration file includes an unencrypted original code stream and an encrypted update code stream. Step S2: Setting a multi-boot identifier in the Flash chip; Step S3: The FPGA is powered on, and the multi-boot identifier set in the Flash chip is read, and the original bit stream is read according to the multi-boot identifier for configuration; Step S4: FPGA configuration is completed, and the secret key corresponding to the user-designed circuit is burned into the battery-backed random access memory through the internal debug interface; Step S5: FPGA sends a reset to the control configurator through the internal debug interface, reads the multi-boot identifier in the Flash chip again, reads the update code stream according to the multi-boot identifier, and performs configuration to implement the user-designed circuit.

[0008] The specific process of step S3 includes: After the FPGA is powered on, the multi-boot identifier set in the Flash chip is read, the address of the update code stream is read according to the multi-boot identifier, and the update code stream is loaded through the address for configuration. The update code stream requires an encryption key, and the configuration fails. The original code stream is read according to the multi-boot identifier in the Flash chip for configuration, and the configuration is successful.

[0009] The step S3 further includes: The FPGA configuration of the updated code stream fails, and the FPGA falls back to loading and reading the original code stream from the Flash chip. The original code stream is not encrypted, and the configuration is successful.

[0010] The specific process of step S5 includes: The FPGA sends a reset to the control configurator through the internal debug interface. After the reset is released, the secret key stored in the battery backup random access memory is read, and the multi-boot identifier in the Flash chip is reloaded to identify the address of the update code stream. The update code stream is loaded through the address and the secret key for configuration.

[0011] Call the FPGA internal debug interface primitive to generate a non-encrypted FPGA configuration file, that is, a non-encrypted original code stream.

[0012] The EDA software generates an encrypted FPGA configuration file based on the code of the user-designed circuit and the secret key set by the user, that is, an update code stream encrypted with the secret key.

[0013] The key value is unreadable and is updated continuously by repeated writing.

[0014] The multi-boot identifier is placed in the first address of the Flash chip.

[0015] Before configuring the code stream files encrypted with different secret keys, the corresponding secret keys are automatically updated to the battery backup random access memory through the internal debugging interface.

[0016] The multi-boot identifier, the unencrypted original code stream and the encrypted update code stream stored in the Flash chip can be burned offline or updated remotely.

[0017] Compared with the prior art, the beneficial effects of the present invention mainly include: This application provides an FPGA-based anti-attack method that uses the multi-start function in active mode to actively configure the FPGA multiple times, reducing the risk of the FPGA being attacked during the configuration process and realizing the function of securely starting the FPGA to run the user-designed circuit.

[0018] In order to make the above and other objects, features and advantages of the present invention more clearly understood, preferred embodiments are given below with reference to the accompanying drawings for detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the specific embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0020] Figure 1 A flowchart of an FPGA-based anti-attack method provided in an embodiment of the present application.

[0021] Figure 2 This is a schematic diagram of the original code stream configuration provided in an embodiment of the present application.

[0022] Figure 3 This is a schematic diagram of the updated code stream configuration provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] The foregoing and other technical aspects, features, and functions of the present invention are clearly presented in the following detailed description of a preferred embodiment with reference to the accompanying drawings. Directional terms such as up, down, left, right, front, and back, used in the following embodiments, are intended solely to refer to the directions in the accompanying drawings. Therefore, the directional terms used are for illustrative purposes only and are not intended to limit the present invention.

[0024] The following detailed description of the various embodiments of the present application is provided in conjunction with the accompanying drawings. However, those skilled in the art will appreciate that many technical details are provided in the various embodiments of the present application to facilitate a better understanding of the present application. However, the technical solutions claimed in the present application can be implemented without these technical details and without the various variations and modifications based on the following embodiments.

[0025] Example: like Figure 1 As shown, an FPGA-based anti-attack method includes: Step S1: The EDA software generates an FPGA configuration file based on the user's circuit design code and stores it in the Flash chip. The configuration file includes an unencrypted original code stream and an encrypted update code stream. Step S2: Setting a multi-boot identifier in the Flash chip; Step S3: After the FPGA is powered on, it reads the multi-boot identifier set in the Flash chip (the multi-boot identifier is placed in the first address of the Flash chip), reads the address of the update code stream based on the multi-boot identifier, and loads the update code stream through the address for configuration. The update code stream requires an encryption key. At this time, the FPGA cannot obtain the encryption key designed by the user, and the configuration fails. The multi-boot identifier in the Flash chip is read to obtain the original code stream for configuration. The original code stream is not encrypted, and the configuration is successful. Step S4: FPGA configuration is completed, and the secret key corresponding to the user-designed circuit is burned into the battery-backed random access memory through the internal debug interface; Step S5: The FPGA sends a reset to the control configurator through the internal debug interface. After the reset is released, the secret key stored in the battery backup random access memory is read, and the multi-boot identifier in the Flash chip is read again. The address of the update code stream is obtained according to the multi-boot identifier, and the update code stream is loaded through the address and secret key for configuration to implement the user-designed circuit.

[0026] Specifically, the user code calls the internal debug interface primitive and the user logic controls the write key, as shown above. Figure 1 As shown in the FPGA. FPGA synthesis and implementation software synthesizes the circuit code written by the user to generate a non-encrypted configuration file (i.e., the original code stream); The user prepares the functional circuit that needs to be implemented, as shown above Figure 2 As shown in the FPGA, the key is set. The FPGA synthesis and implementation software generates an encrypted configuration file (i.e., updates the code stream) based on the user-written circuit code and the key set by the user. Store the generated code stream in Flash and set the synchronization header in Flash to indicate multi-boot; After power-on, the FPGA will first read the multi-boot synchronization header from address 0 of the Flash; After identifying the synchronization header, the FPGA will jump to the specified address in the Flash and read the updated bitstream to configure itself. At this time, because the FPGA does not have the key, the configuration cannot be successful and it will fall back to reading the original bitstream from the Flash. The original bitstream is an unencrypted bitstream, and the FPGA configuration is successful. At this point, the circuit function running on the FPGA writes the key into the BBRAM through the internal debug interface. After the key is burned, a reset is automatically sent through the internal debug interface; After the FPGA control configurator receives the reset release, the configuration system will read the data from the flash at address 0 and repeat the above steps; The FPGA configuration register contains the correct key, the bit stream configuration is updated successfully, and the functions required by the user are running.

[0027] like Figure 2 As shown, multiple code streams and multi-boot identifiers are stored in the Flash. One is the unencrypted code stream (i.e., the original code stream) generated by the circuit that calls the internal debug interface primitive to write the BBRAM key. like Figure 2 As shown, the first address of the Flash chip is 0x000000, and the Flash chip stores the multi-boot identifier, Golden_xx configuration code stream, and Update_xx configuration code stream; The FPGA chip is equipped with Golden and control configurators, and the Flash chip stores the corresponding Golden_xx configuration code stream.

[0028] like Figure 3 As shown, one is the code stream encrypted with a key and generated by the circuit synthesis of the function that the user actually wants to implement (i.e., the update code stream); like Figure 3 As shown, the first address of the Flash chip is 0x000000, and the Flash chip stores the multi-boot identifier, Golden_xx configuration code stream, and Update_xx configuration code stream; The FPGA chip is equipped with an Update and control configurator, and the Flash chip stores the corresponding Update_xx configuration code stream.

[0029] After powering on, the FPGA first loads the multiboot identifier from flash memory. After identifying the address of the update codestream, it jumps to the specified address to load the update codestream. Because it lacks the decryption key, configuration fails, and the FPGA falls back to loading the original codestream. After successfully loading the original codestream, the codestream function writes the user-defined key to BBRAM or efuse via the internal debug interface. The key value is not readable and can only be updated repeatedly. After writing the key, the internal debug interface sends a reset to the FPGA's control configurator. After the reset is released, the FPGA's configuration system first reads the key from BBRAM, then reloads the multiboot identifier from flash memory. After identifying the address of the update codestream, it jumps to the specified address to load the encrypted update codestream. At this point, the FPGA already has the key, so the update codestream is successfully loaded and configured, and the user's desired function begins to run.

[0030] like Figure 2As shown, the FPGA internal debugging interface primitive is called to generate a non-encrypted FPGA configuration file, that is, a non-encrypted original code stream.

[0031] like Figure 3 As shown, the EDA software generates an encrypted FPGA configuration file based on the code of the user-designed circuit and the secret key set by the user, that is, an update code stream encrypted with the secret key.

[0032] The FPGA in this application needs to update circuit functions and run update code streams encrypted with different keys. It can burn multiple boot identifiers, unencrypted original code streams, and encrypted update code streams stored in the Flash chip offline or remotely update them. When no external debugging interface is left, the user circuit internal debugging interface can update the key, which can prevent external attacks or tampering with functions through the debugging interface.

[0033] This application utilizes the multi-start function in the FPGA active configuration mode to enable the FPGA to perform multiple active configurations, implement key updates, and ultimately load the encrypted code stream of the functional circuit that the user needs to implement; during the configuration process, the user's actual function will not be executed even if the updated code stream or the original code stream file is tampered with; before configuring code stream files encrypted with different secret keys, the corresponding key update is automatically burned into the battery-backed random access memory through the internal debugging interface.

[0034] The user of this application can encrypt the code stream. During configuration, the system automatically burns the key and loads the encrypted code stream. When N such systems need to burn the key, only the original code stream needs to be stored in the flash, and batch automatic burning of bbram or efuse keys can be achieved. It is also possible to continuously replace the FPGA chip to achieve batch automatic burning of efuse keys.

[0035] This application provides an FPGA-based anti-attack method that uses the multi-start function in active mode to actively configure the FPGA multiple times, reducing the risk of the FPGA being attacked during the configuration process and realizing the function of securely starting the FPGA to run the user-designed circuit.

[0036] In order to facilitate the description of the present invention, some common English nouns or letters are used for illustrative reference only and are not intended to be restrictive or specific. The scope of protection of the present invention should not be limited by their possible Chinese translations or specific letters.

[0037] It should also be noted that, in this article, relational terms such as "first" and "second" are merely used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations.

Claims

1. An anti-attack method based on FPGA, characterized in that: include: Step S1: The EDA software generates an FPGA configuration file based on the user's circuit design code and stores it in the Flash chip. The configuration file includes an unencrypted original code stream and an encrypted update code stream. Step S2: Setting a multi-boot identifier in the Flash chip; Step S3: The FPGA is powered on, and the multi-boot identifier set in the Flash chip is read, and the original bit stream is read according to the multi-boot identifier for configuration; Step S4: FPGA configuration is completed, and the secret key corresponding to the user-designed circuit is burned into the battery-backed random access memory through the internal debug interface; Step S5: FPGA sends a reset to the control configurator through the internal debug interface, reads the multi-boot identifier in the Flash chip again, reads the update code stream according to the multi-boot identifier, and performs configuration to implement the user-designed circuit.

2. The FPGA-based anti-attack method according to claim 1, wherein: The specific process of step S3 includes: After the FPGA is powered on, the multi-boot identifier set in the Flash chip is read, the address of the update code stream is read according to the multi-boot identifier, and the update code stream is loaded through the address for configuration. The update code stream requires an encryption key, and the configuration fails. The original code stream is read according to the multi-boot identifier in the Flash chip for configuration, and the configuration is successful.

3. The FPGA-based anti-attack method according to claim 2, wherein: The step S3 further comprises: The FPGA configuration of the updated code stream fails, and the FPGA falls back to loading and reading the original code stream from the Flash chip. The original code stream is not encrypted, and the configuration is successful.

4. The FPGA-based anti-attack method according to claim 1, wherein: The specific process of step S5 includes: The FPGA sends a reset to the control configurator through the internal debug interface. After the reset is released, the secret key stored in the battery backup random access memory is read, and the multi-boot identifier in the Flash chip is reloaded to identify the address of the update code stream. The update code stream is loaded through the address and the secret key for configuration.

5. The FPGA-based anti-attack method according to claim 1, wherein: Call the FPGA internal debug interface primitive to generate a non-encrypted FPGA configuration file, that is, a non-encrypted original code stream.

6. The FPGA-based anti-attack method according to claim 1, characterized in that: The EDA software generates an encrypted FPGA configuration file based on the code of the user-designed circuit and the secret key set by the user, that is, an update code stream encrypted with the secret key.

7. The FPGA-based anti-attack method according to claim 6, characterized in that: The key value is unreadable and is updated continuously by repeated writing.

8. The FPGA-based anti-attack method according to claim 1, wherein: The multi-boot identifier is placed in the first address of the Flash chip.

9. The FPGA-based anti-attack method according to claim 1, wherein: Before configuring the code stream files encrypted with different secret keys, the corresponding secret keys are automatically updated to the battery backup random access memory through the internal debugging interface.

10. The FPGA-based anti-attack method according to claim 9, characterized in that: The multi-boot identifier, the unencrypted original code stream and the encrypted update code stream stored in the Flash chip can be burned offline or updated remotely.

Images