Chips and methods for verification and debugging

Abstract

The present invention provides a chip and method for verification and debugging. The method runs secure boot firmware to execute a secure boot process to verify whether a debug function firmware program in a signed program stored in an external storage device can be executed. After successfully verifying the signed program, the debug function firmware program is run to execute the debug user authentication algorithm in the signed program, thereby initiating the debug user authentication process. After verifying that the debug user of an external debugging tool connected to the chip is a legitimate debug user, the debugging tool is allowed to use the debugging functions in the chip according to its permissions. The present invention prevents unauthenticated and unauthorized external debugging tools from arbitrarily accessing the chip and obtaining valuable assets on the chip.

Description

Technical Field

[0001] The present invention relates to a chip and method capable of authenticating and debugging a user, and in particular to a chip and method for verification and debugging. Background Art

[0002] In a chip with a microprocessor, the software programs it executes are relatively complex and require a large amount of storage space. Therefore, the software or firmware programs to be executed are generally not stored on the chip. Instead, they rely on external storage devices outside the chip to store the software or firmware programs required by the chip. Therefore, such chips usually do not have large-capacity (more than a thousand bytes) non-volatile memory (NVM) units, but only a few small-capacity (less than a thousand bytes) NVM units. These small-capacity (less than a thousand bytes) NVM units are used to store settings related to chip characteristics. Due to cost considerations or other factors, these small-capacity (less than a thousand bytes) NVM units are usually one-time program NVM units, such as read-only memory (ROM) units.

[0003] During chip development, especially when developing low-level software or firmware, external debugging tools are often required. Therefore, chips must typically be equipped with at least one debugging function. These debugging functions allow external debugging tools to access chip resources or control the chip's processor. However, once a chip enters the development phase, valuable assets may be present. To protect these assets, permission management for these debugging functions becomes crucial. Summary of the Invention

[0004] Embodiments of the present invention provide a chip and method for authenticating debugging users and debugging tools for debugging firmware programs external to a chip. The chip or method can manage the debugging functions of a chip that cannot store debugging software programs or debugging firmware programs, thereby preventing unauthenticated and unauthorized external debugging users from arbitrarily accessing the chip and obtaining valuable assets on the chip through debugging tools.

[0005] An embodiment of the present invention provides a chip capable of authenticating an external debugging function firmware program and a debugging user of the chip, comprising: a non-volatile memory storing secure boot firmware, a secure boot public key, and a debugging function preset value; a debugging function control component comprising at least one debugging function and a placeholder for occupying at least one debugging function status value, wherein the initial value of the debugging function status value occupied by the placeholder is the debugging function preset value; a volatile memory; and at least one processor configured to run the secure boot firmware to verify a signed program stored in an external storage device according to the secure boot public key, and after successfully verifying the signed program, run the debugging function firmware program of the signed program to verify whether the debugging user of the external debugging tool connected to the chip is a legitimate debugging user through the debugging user authentication algorithm of the signed program, wherein the debugging function can be used by the legitimate debugging user.

[0006] Optionally, the signed program further includes a debugging user and corresponding debugging function permissions, so that the legitimate debugging user can use the debugging function according to his / her permissions.

[0007] Optionally, the chip further includes a debug port, an external boot channel, a debug authentication channel and a debug channel, wherein the debug port is a channel for communicating with the debug tool through the debug channel, the debug authentication channel is a channel for the debug user of the debug tool to authenticate with the chip, and the external boot channel is a channel for communicating between the chip and the external storage device.

[0008] Optionally, the debugging function state value is changed by running the debugging function firmware program, so as to allow the legitimate debugging user to use the debugging function.

[0009] Optionally, the debugging function is a function of the debugging tool to access system memory space.

[0010] Optionally, the debugging function is a function of the debugging tool causing the processor to enter a debugging state to suspend operation.

[0011] Optionally, the debugging function is a function of the debugging tool to record the process of the processor executing the program.

[0012] Optionally, the external storage device further stores a program signature, and the processor uses the secure boot public key to check the program signature to verify the signed program.

[0013] Optionally, the debugging user inputs an authentication request, and the processor authenticates whether the debugging user is a legitimate debugging user according to a password or a key in the authentication request.

[0014] An embodiment of the present invention provides a method for authenticating a chip's external debugging function firmware program and debugging user, comprising: running secure boot firmware to verify a signed program stored in an external storage device based on a secure boot public key, wherein the secure boot public key is used to proofread the program signature of the external storage device to verify the signed program; and after successfully verifying the signed program, running the debugging function firmware program of the signed program to verify whether a debugging user of an external debugging tool connected to the chip is a legitimate debugging user through a debugging user authentication algorithm of the signed program, wherein whether the debugging user is a legitimate debugging user is authenticated based on a password or key in an authentication request input by the debugging user, and the debugging function of the chip can be used by the legitimate debugging user.

[0015] In summary, the chip and method for authenticating external debugging firmware and debugging tools provided by the embodiments of the present invention can prevent unauthenticated and unauthorized external debugging tools from arbitrarily accessing the chip and obtaining valuable assets on the chip.

[0016] To further understand the technology, means and effects of the present invention, reference may be made to the following detailed description and accompanying drawings, which may provide a thorough and specific understanding of the purposes, features and concepts of the present invention. However, the following detailed description and accompanying drawings are intended only to provide a reference and illustration of the implementation of the present invention and are not intended to limit the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings are provided to help those skilled in the art to which the present invention pertains to further understanding of the present invention and are incorporated into and constitute a part of the specification of the present invention. The accompanying drawings illustrate exemplary embodiments of the present invention and, together with the specification of the present invention, are used to explain the principles of the present invention.

[0018] Figure 1 It is a system block diagram of a chip capable of authenticating a chip external debugging function firmware program and a debugging tool for debugging a user according to an embodiment of the present invention.

[0019] Figure 2 This is a flowchart of secure booting of a chip according to an embodiment of the present invention.

[0020] Figure 3 This is a flow chart of a chip authenticating a debugging user of a debugging tool according to an embodiment of the present invention. DETAILED DESCRIPTION

[0021] Reference will now be made in detail to exemplary embodiments of the present invention, which are illustrated in the accompanying drawings. Wherever possible, identical reference numerals will be used throughout the drawings and the description to designate identical or similar components. The exemplary embodiments are merely one example of how the present invention may be implemented, and the various examples described below are not intended to limit the present invention.

[0022] Embodiments of the present invention provide a chip and method for authenticating debug users of external chip debug firmware and debugging tools. The chip includes at least one processor, volatile memory, non-volatile memory, a debug port, and a debug function control component. The non-volatile memory may include several small-capacity (less than a thousand bytes) non-volatile memory cells to respectively store secure boot firmware, a secure boot public key, and debug function default values. The debug function control component includes at least one debug function and a placeholder, and the placeholder holds a debug function status value.

[0023] When a debugging tool is connected to the chip through a debugging channel and a port, and an external storage device is connected to the chip through an external boot channel, the secure boot firmware in the non-volatile memory will be executed by the processor to authenticate the signed program stored in the external storage device using the secure boot public key, thereby determining whether the processor can run the debugging function firmware program in the loaded signed program. The signed program stores the debugging user authentication algorithm, the debugging function firmware program and the debugging user and the corresponding debugging function permissions.

[0024] Next, through the debug user authentication algorithm, the debug user of the debug tool can be verified to see if it is a legitimate debug user. After successful verification, the debug function control component will be set according to the debug user and the corresponding debug function permissions based on the debug tool's user type and permissions, allowing the debug tool to control the debug function control component in the chip according to its debug user type and permissions, thereby running the debug functions that are allowed to be controlled.

[0025] In short, the chip and method for authenticating the debugging user of the external debugging function firmware program and debugging tool provided by the embodiment of the present invention mainly perform signature verification on the debugging function firmware program of the external storage device through secure boot, and after the verification is successful, further verify whether the debugging user of the debugging tool is a legitimate debugging user through the debugging user authentication algorithm. In fact, the authority and number of times that a legitimate debugging user can use the debugging function control component can be managed through the debugging user and the corresponding debugging function authority. Therefore, the chip and method for authenticating the debugging user of the external debugging function firmware program and debugging tool provided by the embodiment of the present invention can prevent unauthenticated and unauthorized external debugging tools from arbitrarily accessing the chip and obtaining valuable assets on the chip.

[0026] After explaining the inventive concept of the present invention, the details of the chip and method for debugging the user of the external debugging function firmware program and debugging tool provided by the embodiment of the present invention are further explained. First, please refer to Figure 1 , Figure 1 This is a system block diagram of a chip capable of authenticating users of external chip debug firmware and debugging tools according to an embodiment of the present invention. Chip 10 includes at least one processor 101, non-volatile memory 102, a debug function control component 103, a debug port 104, and volatile memory 105. The debug function control component 103 is electrically connected to the processor 101, non-volatile memory 102, and debug port 104. Chip 10 also includes an external boot channel, a debug channel, and a port. The external boot channel serves as a communication channel between chip 10 and an external storage device 11, the debug channel serves as a communication channel between the debug port 104 of chip 10 and a debugging tool 12, and the port serves as a communication channel for chip 10 to authenticate the debugging tool 12.

[0027] The processor 101 is used to execute programs to control the chip 10. Specifically, the processor 101 can access the placeholder 1031 of the debug function control component 103, the non-volatile memory 102, and the volatile memory 105, and can access the external storage device 11 via an established external boot channel. The processor 101 can load a signed program 111 stored in the external storage device 11 through the external boot channel, execute the secure boot firmware 1021 stored in the non-volatile memory 102, and execute the debug function firmware program 1112 and the debug user authentication algorithm 1111 of the signed program 111.

[0028] Please note that although the embodiment of the present invention uses a single processor 101 disposed on chip 10 as an example, in reality, chip 10 is not limited to a single processor 101, and may be provided with more than one processor 101. For example, chip 10 may have two processors, and the tasks or functions executed by the two processors may be the same or different. In addition, the external boot channel may utilize one of the interfaces such as USB, SD card, eMMC, NAND Flash, SPI Flash, etc., and does not need to be directly addressed by processor 101, but it is necessary for processor 101 to access data in external storage device 11 through this interface.

[0029] The non-volatile memory 102 stores secure boot firmware 1021, a secure boot public key 1022, and a debug function default value 1023. The secure boot firmware 1021 can be executed by the processor 101 to perform a secure boot. The secure boot public key 102 is a public key used to authenticate an external debug function firmware program during a secure boot. The debug function default value 1023 is a status default value of the debug functions 1032 to 1034, and in one embodiment, at least 1 bit of the debug function default value 1023 can be used to encode the status default value of the debug functions 1032 to 1034. For example, "0" indicates that the debug functions 1032 to 1034 are all turned on, and "1" indicates that the debug functions 1032 to 1034 are all turned off. In other embodiments, a 3-bit debug function default value 1023 can also be used to encode the status default values ​​of the debug functions 1032 to 1034 respectively. The non-volatile memory unit in the non-volatile memory 102 for storing any one of the secure boot firmware 1021 , the secure boot public key 102 , and the debug function default value 1023 may be a one-time programmable non-volatile memory unit.

[0030] Incidentally, secure boot is mainly used to verify the integrity and authenticity of the signed program 111. The secure boot method uses a pair of public and private keys of the public key cryptography system to generate a program signature 112 by encrypting the signed program 111 or the hash value of the signed program 111 using the private key, among which RSA, ECDSA, and EdDSA are common encryption methods. In addition, the holder of the secure boot public key 1022 can use the secure boot public key 1022 to proofread the program signature 112 to verify whether the signed program 111 is provided by a certain owner. This mechanism can be used to bind the chip 10 to the signed program 111 outside of it, so that the chip 10 will only execute the verified and legal signed program 111. Each time the processor 101 loads a signed program 111 from the external storage device 11 , the processor 101 uses the secure boot public key 1022 to perform signature verification on the signed program 111 input from the external. Only signed programs 111 that pass the verification can be run on the chip 10 .

[0031] Volatile memory 105 is used to store data read from external storage device 11, such as debug firmware 1112 in signed program 111 that has passed secure boot verification. Volatile memory 105 can be directly addressed by processor 101, and processor 101 can execute debug firmware 1112 stored in volatile memory 105. Furthermore, the external port is a communication channel between the debug tool 12 and the debug firmware 1112 stored in chip 10. The external port can use one of the interfaces, such as UART, SWD, SPI, and USB. The debug port 104 provides a debug channel for the debug tool 12 of a verified legitimate debugging user to access the various debug functions 1032-1034 in chip 10. The debug channel can use one of the interfaces, such as JTAG and SWD, and may be one or more physical entries. Furthermore, the debug channel used by the external port and the corresponding debug port 104 can be the same communication channel (i.e., the external port and the debug channel share the same communication channel).

[0032] The debug function control component 103 includes a placeholder 1031 and a plurality of debug functions 1032-1034. Whether the debug functions 1032-1034 are accessible is controlled by the debug function control component 103. Specifically, the debug function control component 103 is used to control whether the debug functions 1032-1034 are accessible by the external debug tool 12. The debug functions 1032-1034 are functions required by the debug tool 12 to debug the chip 10, such as, but not limited to: (1) the debug tool 12 accesses the system memory space; (2) the debug tool 12 causes the processor 101 to enter the debug state, and when the processor 101 enters the debug state, it halts the execution (Halt); and the debug tool 12 records the process of the processor 101 executing the program (Tracing code).

[0033] Debug function control component 103 provides an interface for processor 101 to access debug functions 1032-1034, achieving hardware-software collaboration. The running debug function firmware program 1112 can access the placeholders in debug function control component 103 through this interface to enable or disable debug functions 1032-1034 that are preset to the off state. Placeholders 1031 are hardware devices, and debug function states include, but are not limited to, two states: off and on. This means that debug function state values ​​are not necessarily binary values ​​of "0" or "1."

[0034] When debug function control component 103 sets debug function 1032 to the enabled state, debug function 1032 is enabled, and debug tool 12 can access debug function 1032 in chip 10. When debug function control component 103 sets debug function 1034 to the disabled state, debug function 1034 is disabled, and debug tool 12 cannot access debug function 1034 in chip 10. However, debug function firmware 1112 can change debug functions 1032-1034 from the disabled state to the enabled state by setting the debug function status value of placeholder 1031. The default state of debug functions 1032-1034 is set to the enabled state or disabled state based on the debug function default value stored in non-volatile memory 102. When the default debugging state of the debugging functions 1032-1034 is on, the debugging functions 1032-1034 are accessible to the debugging tool 12 without going through an authentication process. However, generally, the default debugging state of the debugging functions 1032-1034 is off, and whether the debugging functions 1032-1034 can be turned on is determined by the debugging user type and permissions of the debugging tool 12.

[0035] External storage device 11 stores programs and data for verifying the debugging user of debugging tool 12, and includes at least a signed program 111 and a program signature 112. Signed program 111 includes a debugging function firmware program 1112, a debugging user authentication algorithm 1111, and a debugging user and corresponding debugging function permissions 1113. Debugging function firmware program 1112 includes functions for accessing the debugging function control component 103 of chip 10 and establishing a port to receive command input from debugging tool 12. Program signature 112 is a digital signature generated using a public-private key encryption system. Specifically, program signature 112 is a digital signature generated based on debugging function firmware program 1112 using a private key paired with secure boot public key 1022. In one embodiment, program signature 112 is generated by encrypting the debugging function firmware program 1112 itself or its hash value using the private key.

[0036] The debug user authentication algorithm 1111 uses a cryptographic authentication method to verify whether the debug user of the debug tool 12 is a legitimate debug user, such as a password comparison method or a public key authentication method, but the present invention is not limited thereto. If the authentication fails, the chip 10 will not allow the debug tool 12 to operate the debug function control component 103. If the authentication succeeds, the chip 10, through the debug function firmware program, configures the debug function control component 103 based on the debug user type and permissions of the debug tool 12, so that the debug user can operate the debug functions 1032-1034 for which their permissions are permitted through the debug tool 12. Furthermore, the debug user and corresponding debug function permissions 1113 can record the debug user type and permissions of the debug tool 12, that is, record the debug users corresponding to different user passwords and the permissions that each debug user is allowed to operate the debug functions 1032-1034.

[0037] When the processor 101 of the chip 10 runs the secure boot firmware 1021, the signed program 111 and the program signature 112 are loaded from the external storage device 11 into the volatile memory 105. During the secure boot process, in order to ensure the security of the secure boot process, the debugging function of the debugging tool 12 that accesses the memory space will be forcibly set to the closed state, the debugging function of the debugging tool 12 that causes the processor 101 that executes the secure boot to enter the debugging state will be forcibly set to the closed state, and the debugging function of the debugging tool 12 that records the execution process of the program by the processor 101 that executes the secure boot will be forcibly set to the closed state. Furthermore, after the secure boot is successfully completed and the secure boot is terminated, the debugging function that was forcibly set to the closed state will no longer be forcibly set to the closed state, and it will be in the open state or closed state according to its debugging function state.

[0038] Next, please refer to Figure 1 and Figure 2 , Figure 2This is a flowchart of secure booting of a chip according to an embodiment of the present invention, and the detailed process of secure booting is described as follows. First, in step S21, an external boot channel is created using the corresponding interface. Then, in step S22, the external storage device 11 is searched to see whether it has a signed program 111 and a program signature 112 saved. In step S23, it is determined whether the signed program 111 and the program signature 112 exist. If the signed program 111 and the program signature 112 exist, step S24 is executed; otherwise, the secure boot process is terminated. In step S24, the signed program 111 and the program signature 112 are loaded from the external storage device 11 to the chip 10. Then, in step S25, the secure boot public key 1022 is used to verify the signed program 111. In step S26, it is determined whether the signed program 111 and the program signature 112 have passed the verification. If the signed program 111 and the program signature 112 have passed the verification, step S27 is executed; otherwise, the secure boot process is terminated. In step S27 , the chip 10 runs the debug function firmware program 1112 in the signed program 111 .

[0039] After the secure boot process is completed, the debug user authentication process is performed by running the debug function firmware program 1112 on the chip 10, and the debug user authentication process is used to enable the chip 10 to verify whether the debug user who intends to debug is a legitimate debug user. Figure 1 and Figure 3 , Figure 3 This is a flowchart of the chip authenticating the chip external debugging function firmware program and debugging tool according to an embodiment of the present invention. In step S31, the corresponding interface is used to create a port. Then, in step S32, wait for external input. In step S33, determine whether there is an authentication request input from the outside, for example, inputting the password or key of the debugging user. If there is an authentication request input from the outside, execute step S34, otherwise, execute step S32. In step S35, execute the debugging user authentication algorithm to determine whether the debugging user of the debugging tool 12 is a legitimate debugging user based on the authentication request input from the outside. If it is verified to be a legitimate debugging user, then execute step S36, otherwise, end the debugging user authentication process and report a verification error. In step S36, the debugging user type and authority are determined according to the debugging user and the corresponding debugging function authority 1113 to turn on the corresponding debugging functions 1032~1034 in the debugging function control component 103 to the on state.

[0040] Next, please continue to refer to Figure 1In one implementation, at least one processor 101 may be two processors, namely a Cortex-A35 processor and a Cortex-M4 processor of the ARM architecture. The Cortex-A35 processor serves as the core processor of chip 10, while the Cortex-M4 processor does not participate in the debugging authentication function. Non-volatile memory 102 may be a one-time programmable read-only memory. The debug channel uses an SWD interface, and the port uses a UART interface. Debug functions 1032-1034 respectively control the use of MEM-AP hardware by an external debugger (MEM-AP is a device commonly used in the ARM architecture to allow the debugger 12 to access the memory space of chip 10), control the debugger 12's ability to enter the Cortex-A35 processor into a debug state, and control the debugger 12's ability to enter the Cortex-M4 processor into a debug state. External storage device 11 may be flash memory, and volatile memory 105 may be static random access memory (SRAM).

[0041] In this implementation, one debugging user is defined, and a legitimate debugging user can use the three debugging functions 1032 to 1034. When the operation starts, the Cortex-A35 processor executes the secure boot firmware 1021 stored in the non-volatile memory 102 to perform the aforementioned secure boot process. The signed program 111 and the program signature 112 are stored in an external storage device 11 outside the chip 10. The external storage device 11 communicates with the chip 10 using the SPI protocol. The Cortex-A35 processor in the chip 10 reads the signed program 111 and the program signature 112 from the external storage device 11 through the SPI interface, places them in the volatile memory 105, and executes the verification procedure of the secure boot process.

[0042] After the secure boot process authenticates the signed program 111 correctly, the Cortex-A35 processor will load and execute the debug function firmware program 1112 of the signed program 111. After the debug function firmware program 1112 is executed, the aforementioned debug user authentication process will be executed. In this implementation, the default values ​​of the debug authentication function are all 1, so the debug user of the debugger 12 cannot use any debug function before being authenticated. The debug function firmware program 1112 uses the UART communication protocol to communicate with the debugger 12, so the debug user can use the UART communication protocol to issue an authentication request and enter a password for comparison. Once the comparison is correct, the debug function firmware program 1112 will enable the above three debug functions for the debugger 12 to access.

[0043] In summary, compared to prior art, the chip and method provided by the embodiments of the present invention, which can authenticate debug users of external chip debug firmware and debugging tools, utilize a secure boot process to prevent unauthenticated debug firmware from being executed within the chip. Furthermore, the chip and method provided by the embodiments of the present invention utilize debug users and corresponding debug function permissions to manage the permissions and frequency of use of debug control components by legitimate debug users.

[0044] It should be understood that the examples and embodiments described herein are for illustrative purposes only and that various modifications or changes will be suggested to those skilled in the art in view of the foregoing and are to be included within the spirit and scope of the present invention and the scope of the appended claims.

Claims

1. A chip for verification and debugging, characterized in that: The chip includes: Non-volatile memory, which stores secure boot firmware, secure boot public keys, and debug function presets; a debug function control component, comprising at least one debug function and a placeholder for holding at least one debug function status value, wherein an initial value of the debug function status value held by the placeholder is the debug function preset value, and wherein the debug function status value is determined according to a debug user type and permissions of an external debug tool connected to the chip; Volatile memory; and at least one processor configured to run the secure boot firmware to verify a signed program stored in an external storage device based on the secure boot public key, and after successfully verifying the signed program, run a debugging function firmware program of the signed program to verify whether the debugging user of the debugging tool is a legitimate debugging user using a debugging user authentication algorithm of the signed program, wherein the debugging function is available to the legitimate debugging user; The signed program further includes a debugging user and corresponding debugging function permissions, so that the legitimate debugging user can use the debugging function according to his / her permissions.

2. The chip according to claim 1, wherein: It further includes a debug port, an external boot channel, a debug authentication channel, and a debug channel, wherein the debug port is a channel for communicating with the debug tool through the debug channel, the debug authentication channel is a channel for the debug user of the debug tool to authenticate with the chip, and the external boot channel is a channel for communicating between the chip and the external storage device.

3. The chip according to claim 1, wherein: The debugging function state value is changed by running the debugging function firmware program, so that the legitimate debugging user can use the debugging function.

4. The chip according to claim 1, wherein The debugging function is a function for the debugging tool to access the system memory space.

5. The chip according to claim 1, wherein: The debugging function is a function in which the debugging tool causes the processor to enter a debugging state to suspend operation.

6. The chip according to claim 1, wherein: The debugging function is a function of the debugging tool to record the process of the processor executing the program.

7. The chip according to claim 1, wherein: The external storage device further stores a program signature, and the processor uses the secure boot public key to check the program signature to verify the signed program.

8. The chip according to claim 1, wherein: The debugging user inputs an authentication request, and the processor authenticates whether the debugging user is a legitimate debugging user according to a password or a key in the authentication request.

9. A method for verification and debugging, characterized in that: The method comprises: Running the secure boot firmware to verify a signed program stored in an external storage device based on a secure boot public key, wherein the secure boot public key is used to check a signature of a program in the external storage device to verify the signed program; and After successfully verifying the signed program, the debug function firmware of the signed program is run to verify whether the debug user of the external debug tool connected to the chip is a legitimate debug user through the debug user authentication algorithm of the signed program. The debug user is authenticated as a legitimate debug user based on a password or key entered in an authentication request by the debug user, and the debug function of the chip is available for use by the legitimate debug user. The status value of the debug function is determined based on the debug user type and permissions of the debug tool. The signed program further includes the debug user and the corresponding debug function permissions, so that the legitimate debug user can use the debug function according to his or her permissions.

Images