Circuit architecture of an MCU debug port protection mechanism and its implementation method

Abstract

The present invention discloses a circuit architecture and an implementation method for an MCU debug port protection mechanism. The circuit architecture includes a debug access port and a debug authentication module. The debug access port includes a register access path, several AP paths with independent lock / unlock control, and a lock control unit, where the lock control unit is used to connect to several of the AP paths with independent lock / unlock control respectively. The debug authentication module includes a register interface for reading and writing access to the register access path, a main state machine for managing the unlocking process of each AP path according to the register configuration information, a mailbox information generation unit for generating a challenge request command and a response verification command in a predetermined format and sending them to the password service engine under the management of the main state machine according to the register configuration information, and an AP lock control status unit connected to the lock control unit of the debug access port for controlling the unlocking status of each AP path under the management of the main state machine.

Description

Technical Field

[0001] The present invention belongs to the field of chip design, and particularly relates to access protection and permission management for debugging interfaces in MCU chips. A hardware circuit architecture and a scheme implementation process are proposed, specifically a circuit architecture of an MCU debugging port protection mechanism and its implementation method. Background Art

[0002] An MCU (Microcontroller Unit), also known as a single-chip microcomputer, is a system-on-chip that includes circuits such as a CPU (Central Processing Unit), communication peripherals, memory, I / O, ADC, sensors, etc. It can implement relatively complex human-computer interaction, motor control, sensor monitoring, etc. functions; and with the continuous development of microelectronics technology and computer technology, the functions and performance of MCUs have also been continuously improved, with higher working frequencies, more cores and pins, and richer functions. This has also made MCUs more and more widely used in consumer electronics, industrial electronics, and automotive electronics fields.

[0003] As MCUs are increasingly applied to important and critical fields, higher security requirements are also put forward for MCUs. Developers and users of MCU products hope to protect the MCU hardware from being illegally stolen and software data from being illegally accessed. Standards and regulations for electrical and electronic architecture information security have also begun to be continuously improved. For example, the industrial network security standard IEC62443-4-1 and the automotive network security standard ISO21434.

[0004] To achieve the information security protection of MCUs, the HSM (Hardware Security Module) scheme is adopted. The HSM constructs a security subsystem to provide functions such as secure boot, secure storage, secure services, and secure access for the entire MCU. The HSM performs strict permission management on the interfaces of the MCU to protect the MCU from being illegally accessed. One very important interface is the JTAG debugging interface.

[0005] The debugging interface plays an important role in the development and debugging of MCU-based products. The debugging interfaces here include JTAG, SWD, UART, etc. Considering that the JTAG protocol is widely used, JTAG will be the main description object below.

[0006] The key information inside the MCU can be easily obtained through the JTAG interface, and the operating status of the MCU can be monitored. In particular, the modern and perfect debug mechanism provides a high degree of visibility of the kernel, thus accelerating product development and quickly locating problems. While the JTAG interface provides convenience, it also exposes security risks, providing convenience for attackers with malicious access. Attackers can use the JTAG interface to obtain intellectual property information such as internal code and data of the MCU, and even tamper with the internal firmware of the MCU through the JTAG interface and run illegal programs, all of which will cause serious consequences.

[0007] In response to the security vulnerabilities and the risk of intellectual property leakage brought by the possible illegal abuse of the JTAG interface to the product, many manufacturers will increase restrictions on the permissions of the JTAG. Currently, the main practices are as follows:

[0008] 1. Based on the OTP programming mechanism

[0009] OTP is a non-volatile memory inside the MCU with the property of one-time programming. After programming, it cannot be reprogrammed. Using this feature, the OTP content that controls the JTAG enable can be modified in the last stage of MCU product production to permanently block the debug port.

[0010] 2. Based on the fixed key mechanism

[0011] The fixed password lock is a mechanism that uses the internal circuit and non-volatile storage area of the MCU to implement key programming, locking, key comparison, and unlocking. The fixed key value is programmed for locking in the last stage of MCU product production, and the user unlocks it by inputting the corresponding key.

[0012] 3. Based on the cryptographic authentication mechanism

[0013] The authentication mechanism is implemented through a Challenge-Response handshake method. Before locking the JTAG, the user needs to store the key used for unlocking in the MCU. When unlocking, the user usually applies for random number-related information, that is, Challenge, from the MCU through the communication interface. Then the user signs and encrypts the Challenge with the unlocking key and inputs the encrypted value into the MCU, which is the Response. The application program in the MCU uses the stored key to verify the signature of the encrypted value using the same protocol. If the signature verification passes, the JTAG is enabled.

[0014] The disadvantages of Solution 1 and Solution 2 are poor flexibility, easy leakage of secrets, and easy to be cracked. They are no longer applicable to MCU products that implement important functions and have high security requirements. Solution 3, with its cryptography-based confidentiality mechanism, is being increasingly applied. For example, in the ARM architecture, a set of Authentication signals are provided to restrict the Debug function, and users are allowed to drive these signals through their own "Authentication Module". It is recommended to use a cryptography-based Challenge-Response mechanism for management. The ARM core technical documentation states: "ARM recommends using a Challenge-Response mechanism based on an on-chip random number generator or a device-unique hardware key."

[0015] A typical type of MCU product adopting Solution 3 usually has encryption and decryption modules (such as AES, Hash) and a random number generator (TRNG) inside. Some MCU products will adopt the HSM module (Hardware Security Module) solution. The HSM combines the above encryption modules, TRNG, and a security core to form a "security island" that is securely isolated from the application core, providing functions such as key management, random number generation, and encryption and decryption services. The application core uses an inter-core communication module (Mail Box) to communicate with the HSM to achieve various cryptography service applications.

[0016] The HSM solution, like the combination solution of independent encryption and decryption modules and TRNG modules, can also implement the method described in this patent. For the sake of simplicity and unified description, the above two solutions are hereinafter referred to as the cryptographic service engine.

[0017] The main implementation process of the current Solution 3 is as follows:

[0018] 1. The initiator transmits the Debug unlock request information to the MCU application core through the peripheral communication module, and the application core application initiates a Challenge generation request to the cryptographic service engine;

[0019] 2. After receiving the Challenge generation request, the cryptographic service engine runs the random number generation and assembles the random number and other information into Challenge information and returns it to the application core;

[0020] 3. The application core application returns the Challenge information to the initiator through the communication peripheral. The initiator needs to encrypt the received Challenge information using the key according to the agreed protocol to generate a message digest;

[0021] 4. The initiator transmits the Response unlocking verification information to the MCU application core through the peripheral communication module, and the application core application program initiates a Response verification request to the password service engine;

[0022] 5. The password service engine receives the Response verification request. The password service engine runs the same protocol, encrypts the Challenge information using the corresponding key, compares the generated message digest with the received Response information. If they are consistent, the MCU JTAG is unlocked; otherwise, it remains locked, and status information can be optionally fed back.

[0023] Based on the foregoing analysis, the cryptographic authentication mechanism in Solution 3 is more suitable for high-value and high-security requirement MCU application scenarios compared to Solution 1 and Solution 2. Correspondingly, it requires additional use of certain software and hardware resources.

[0024] The existing implementation solutions still have the following defects and deficiencies:

[0025] 1. It requires additional occupation of the MCU communication interface and the corresponding application program space

[0026] According to the description of the implementation process of Solution 3 above, in the JTAG unlocking process, the initiator communicates with the MCU through communication peripheral modules such as CAN and UART. The MCU needs to add an application program based on this peripheral for the authentication process, specifically for JTAG unlocking applications. Therefore, it will occupy the precious peripheral, pin resources and program storage space of the MCU, which is uneconomical or even unacceptable for resource-sensitive MCU products.

[0027] 2. It depends on the operation of the MCU application core

[0028] According to the description of the implementation process of Solution 3 above, it is required that the MCU application core be in the running state to run the application program for the authentication process. However, in actual situations, the application core may not be able to run due to various complex reasons. For example, the application program firmware fails to start, the application program falls into an infinite loop, hardware circuit failures, etc. In this scenario, the JTAG cannot be unlocked, which will limit or even block the analysis of problems.

[0029] 3. It lacks the management function for different permission levels of multiple cores

[0030] The existing implementation schemes do not currently consider the scenario where different cores of a multi-core MCU have separate JTAG access permission management. Usually, the unlocking / locking of JTAG is directly achieved by controlling the enabling / disabling of the ports or pins where JTAG is located. In this scheme, after JTAG is locked, all cores cannot access through JTAG. After JTAG is unlocked, JTAG can access all kernel information. This is not friendly to the development of large MCU products. For example, in some products, different cores of the MCU run different types of application programs. For instance, application core 0 runs security functions, and application core 1 runs non-security functions. The developers of application core 1 do not want other developers to be able to access the internal information of application core 0. Summary of the Invention

[0031] The object of the present invention is to address the problems existing in the prior art and provide a circuit architecture and its implementation method for an MCU debug port protection mechanism. Without additionally occupying the MCU communication interface, without relying on the operation of the MCU application core, and satisfying the multi-core different privilege level management, a cryptographic authentication mechanism for high-value and high-security requirement MCU application scenarios is realized.

[0032] According to one aspect of the specification of the present invention, a circuit architecture for an MCU debug port protection mechanism is provided, including: a debug access port and a debug authentication module;

[0033] The debug access port includes a register access path, several AP paths with independent unlocking / locking control, and a lock control unit, and the lock control unit is used to be respectively connected with several AP paths with independent unlocking / locking control;

[0034] The debug authentication module includes a register interface for reading and writing access to the register access path; a main state machine for managing the unlocking process of each AP path according to the register configuration information; a mailbox information generation unit for generating a challenge request command and a response verification command in a predetermined format and sending them to the cryptographic service engine under the management of the main state machine according to the register configuration information; an AP lock control status unit connected to the lock control unit of the debug access port for controlling the unlocking status of each AP path under the management of the main state machine.

[0035] As a further technical solution, the memory space includes:

[0036] An AP channel selection configuration register for selecting which AP path to unlock;

[0037] A challenge-response protocol related configuration register for selecting the algorithm to be used;

[0038] A challenge-response protocol related data register for storing the required challenge information to be read and the required response information to be written;

[0039] Command Initiation Control Register, which is used to initiate a challenge request command and an authentication response command;

[0040] Command Completion Status Register, which is used for the command completion status.

[0041] As a further technical solution, the debugging authentication module communicates with the password service engine in hardware.

[0042] As a further technical solution, the debugging authentication module is connected to a hardware communication interface, and the hardware communication interface is connected to the password service engine through a bus.

[0043] According to one aspect of the specification of the present invention, there is provided a method for implementing an MCU debugging port protection mechanism, which is implemented by using the described circuit architecture. The method includes:

[0044] Receiving an enabled challenge request command, where the configuration information of the challenge request command includes the AP channel to be unlocked and the algorithm type used in the challenge-response protocol;

[0045] In response to the challenge request command, generating and initiating a challenge request Mailbox command according to the configuration information;

[0046] When the challenge request Mailbox command is completed and successful, obtaining the challenge information generated by the password service engine and storing it in the register interface;

[0047] Receiving an enabled authentication response command, which is generated by encrypting the generated challenge information using a pre-agreed algorithm and key;

[0048] In response to the authentication response command, generating and initiating an authentication response Mailbox command according to the configuration information;

[0049] When the authentication response Mailbox command is completed and successful, updating the lock state of the corresponding AP to unlock the corresponding AP path.

[0050] As a further technical solution, the method further includes: when the challenge request Mailbox command is completed but fails, automatically updating the command completion status register and outputting that the challenge request command fails.

[0051] As a further technical solution, the method further includes: when the authentication response Mailbox command is completed but fails, automatically updating the command completion status register and outputting that the authentication response command fails.

[0052] Compared with the prior art, the beneficial effects of the present invention are:

[0053] 1. The present invention utilizes the characteristics of the Debug Access Port (DAP) circuit, and multiplexes the JTAG interface as the communication interface for the cryptographic authentication mechanism scheme, without occupying additional peripheral and pin resources of the MCU.

[0054] 2. The implementation of the Challenge-Response protocol in the present invention is completed by the hardware of the Authentication Debug Module (ADM) module, without the participation of the MCU application core, saving the application program space and reducing the unlocking condition requirements.

[0055] 3. The Authentication Debug Module (ADM) module in the present invention realizes independent permission management for different AP channels, meeting the flexible debug permission management requirements at the MCU product level. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Figure 1 FIG. is an application schematic diagram of the circuit architecture of an MCU debug port protection mechanism provided by an embodiment of the present invention.

[0057] Figure 2 FIG. is a schematic diagram of the ADM module architecture provided by an embodiment of the present invention.

[0058] Figure 3 FIG. is a schematic diagram of the authentication and unlocking process based on the ADM module provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0059] It should be noted that:

[0060] The Debug Access Port (DAP) refers to the port used for debugging and accessing the internal resources of the system in the present invention.

[0061] The Authentication Debug Module (ADM) refers to the circuit unit that realizes the permission control of other AP channels in the DAP and the generation and communication of the Challenge-Response protocol Mailbox command in the present invention.

[0062] The Challenge-Response mechanism can be regarded as a cryptographic-based authentication mechanism in the present invention.

[0063] The Mailbox module (mailbox information interaction unit) can be regarded as a hardware interface connecting the ADM module and the cryptographic service engine in the present invention. The Mailbox command can be regarded as a pre-agreed communication protocol, which is essentially a set of bus signals. The purpose is to transmit information to the cryptographic service engine, including the service request command type, the key ID used, the algorithm type used, the AP channel information to be unlocked, etc. These information will be used as parameters in the challenge-response mechanism. For example, the algorithm type determines whether the calculation of the random number signature verification value in the response phase is based on AES-CMAC or HMAC based on a hash function, etc.

[0064] Next, the technical solutions of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of the present invention.

[0065] The embodiment of the present invention provides a circuit architecture for an MCU debug port protection mechanism, including: a debug access port (hereinafter referred to as the DAP module) and a debug authentication module (hereinafter referred to as the ADM module).

[0066] As a preferred embodiment, as Figure 1 shown, in the circuit architecture of the MCU debug port protection mechanism provided by the embodiment of the present invention, the DAP module is connected to the host computer, the ADM module, and the MCU to be debugged. The ADM module is also connected to the cryptographic service engine through the Mailbox and the system bus.

[0067] The DAP module is used to debug and access system internal resources and is composed of two parts: DP and AP. DP is physically connected to the outside world through the JTAG Port, and then converts the data received from the JTAG port into an access to the internal AP. The AP then converts it into a bus access in the form of an address mapping.

[0068] In the embodiment of the present invention, for the DAP module, an additional ADM_AP path is added. This ADM_AP path is specifically used for JTAG to access the ADM module registers, that is, this ADM_AP path can and can only be used for accessing the ADM module registers. Except for this ADM_AP path without permission control, other AP paths have independent locking / unlocking controls, enabling and disabling controls, and the control signals are managed by the ADM module.

[0069] In the embodiment of the present invention, for the ADM module, it mainly realizes the above-mentioned permission control of other AP paths, and the generation and communication of the Challenge-Response protocol Mailbox commands.

[0070] As shown Figure 2 in the figure, the ADM module includes a register interface (ADM_AP Reg Interface), a main state machine (FSM), a mailbox information generation unit (Mailbox CMD Generate), and an AP lock control status unit (AP Lock ControlStatus).

[0071] The register interface (ADM_AP Reg Interface) is a register space that can only be read and written by ADM_AP. Specifically, it includes:

[0072] AP channel selection configuration register: Select which AP path to unlock;

[0073] Challenge-Response protocol related configuration register: Select which algorithm to use, such as AES-128 CMAC, ECDSA, etc.;

[0074] Challenge-Response protocol related data register: Used to store the required Challenge information to be read and the required Response information to be written;

[0075] Command initiation control register: Initiate Challenge request command and initiate Response verification command;

[0076] Command completion status register: Command completion status, such as command completion flag, command success or failure flag.

[0077] The function of the mailbox information generation unit (Mailbox CMD Generate) is: under the management of the FSM, according to the register configuration information, generate corresponding Challenge request commands and Response verification commands according to the Mailbox command format requirements. This circuit unit communicates directly with the password service engine Mailbox.

[0078] The AP lock control status unit (AP Lock Control Status) is mainly used for the unlocking status control logic of each AP path. Under the management of the FSM, if the authentication process is completed and successful, the corresponding AP path unlocking is enabled. This circuit unit is directly connected to the lock control unit in the DAP module.

[0079] The FSM is the main state machine of the ADM module, responsible for managing the implementation of the entire unlocking process according to the above register configuration information.

[0080] When implementing the unlocking workflow based on the aforementioned ADM module executing the Challenge-Response protocol, the user can use the PC-side host computer software to access the ADM module registers through the JTAG interface, configure the corresponding command register to initiate the Challenge request service; the ADM module generates a Mailbox command according to the configuration information in hardware, configures the corresponding register of the Mailbox by hardware, and transfers the request information to the HSM; the ADM module monitors the register on the password service engine side of the Mailbox, and maps the output result and status information of the Challenge request to the ADM module register area for the host computer to read; the host computer reads the Challenge information of the ADM module and calculates the Response information, writes the Response information into the ADM module register area, then configures the corresponding command register to initiate the Response verification request; the ADM module generates a Mailbox command according to the configuration information, configures the corresponding register of the Mailbox by hardware, transfers the request information to the password service engine, and waits for and receives the operation result of the password service engine, and the ADM module unlocks the control lock of the corresponding AP path according to the operation result.

[0081] In the embodiment of the present invention, the application core of the MCU does not need to participate in the authentication and unlocking process. Here, the application core refers to the main CPU of the MCU running the user application program.

[0082] In the embodiment of the present invention, the password service engine is a security subsystem and the main module for implementing security services. The Mailbox module of the password service engine is the main communication interface for implementing security services. In the embodiment of the present invention, there is hardware communication between the ADM module and the Mailbox of the password service engine.

[0083] In the embodiment of the present invention, the JTAG unlocking requester can use the software host computer to implement the authentication and unlocking process. Compared with the existing implementation solutions that require dedicated hardware devices to communicate through peripheral modules, the embodiment of the present invention only needs to use the host computer software based on JTAG, reducing the complexity of the device.

[0084] Based on the circuit architecture of the aforementioned MCU debug port protection mechanism, the present invention also provides a method for implementing the MCU debug port protection mechanism, which mainly includes the operation process of the host computer as the initiator of the whole process and the execution process of the ADM state machine. Among them, the execution process inside the hardware security module HSM is not the focus of the present invention and will not be elaborated here.

[0085] As Figure 3 shown, the method for implementing the MCU debug port protection mechanism specifically includes:

[0086] Step 1, the host computer initiates a Challenge request.

[0087] The host computer first configures the AP channel to be unlocked and the algorithm type used in the Challenge-Response protocol through ADM_AP. Then, it configures the ADM command initiation control register to enable the Challenge request command.

[0088] Step 2, ADM generates a Challenge request Mailbox command.

[0089] The ADM module automatically generates and initiates a Mailbox command according to the configuration information. The internal state machine waits and checks the execution status of the Mailbox command. If the command is completed but fails, ADM automatically updates the command completion status register, indicating that the Challenge command fails for the host computer to query. The host computer can check whether there is a configuration error based on this information and re-initiate the Challenge request. If the command is completed and successful, ADM automatically stores the Challenge information generated by the password service engine in the register space for the host computer to read.

[0090] Step 3, the host computer calculates the Response information.

[0091] After the host computer software reads the Challenge information from the ADM module, it performs an encryption operation using the agreed algorithm and the corresponding key to generate the Response information.

[0092] Step 4, the host computer initiates Response verification.

[0093] The host computer writes the calculated Response information into the ADM register. Then, it configures the ADM command initiation control register to enable the Response verification command.

[0094] Step 5, ADM generates a Response verification Mailbox command.

[0095] The ADM module automatically generates and initiates a Mailbox command according to the configuration information. The internal state machine waits and checks the execution status of the Mailbox command. If the command is completed but fails, ADM automatically updates the command completion status register, indicating that the Response command fails for the host computer to query. The host computer can analyze the failure reason based on this information, such as possible incorrect permissions or Response comparison errors. If the command is completed and successful, ADM will update the lock status of the corresponding AP to unlock the corresponding AP path; after unlocking, the user can access the system resources of this AP path through JTAG.

[0096] In summary of the above embodiments, in view of the defects and deficiencies of the existing implementation solutions, namely the need to additionally occupy the MCU communication interface, the corresponding application program space, the operation depending on the MCU application core, and the lack of the multi-core different permission level management function, the present invention proposes a hardware circuit structure dedicated to the JTAG unlocking function and a corresponding working process solution. It uses the JTAG interface to directly communicate with the HSM, without additionally occupying the extra pins of the MCU, and completes the complete Challenge-Response authentication process with the HSM by hardware, without the operation and participation of the application core. Further, the hardware adds independent access control for each AP at the DAP end to achieve fine control of different cores with different permission levels.

[0097] Although the embodiments of the present invention have been shown and described, those of ordinary skill in the art can understand that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A circuit architecture of an MCU debug port protection mechanism, characterized in that Based on a cryptographic authentication mechanism for high-value and high-security demand MCU application scenarios without relying on the operation of the MCU application core and capable of meeting the management of different privilege levels of multiple cores, the circuit architecture includes: a debug access port and a debug authentication module; the debug access port is connected to a host computer, a debug authentication module, and the MCU to be debugged, and the debug authentication module is also connected to a cryptographic service engine through a Mailbox and a system bus; The debug access port includes a register access path, several AP paths with independent lock / unlock control, and a lock control unit. The lock control unit is used to connect to several of the AP paths with independent lock / unlock control respectively. The register access path is dedicated to JTAG access to debug the authentication module registers; The debug authentication module includes a register interface for reading and writing access through the register access path; a main state machine for managing the unlocking process of each AP path according to the register configuration information; a mailbox information generation unit for generating a challenge request command and a response verification command in a predetermined format and sending them to the cryptographic service engine under the management of the main state machine according to the register configuration information; an AP lock control state unit connected to the lock control unit of the debug access port for controlling the unlocking state of each AP path under the management of the main state machine.

2. The circuit architecture of an MCU debug port protection mechanism according to claim 1, characterized in that The register interface includes: An AP channel selection configuration register for selecting which AP path to unlock; A challenge-response protocol related configuration register for selecting the algorithm to be used; A challenge-response protocol related data register for storing the challenge information to be read and the response information to be written; A command initiation control register for initiating a challenge request command and a response verification command; A command completion status register for the command completion status.

3. The circuit architecture of an MCU debug port protection mechanism according to claim 1, characterized in that There is hardware communication between the debug authentication module and the cryptographic service engine.

4. The circuit architecture of an MCU debug port protection mechanism according to claim 3, characterized in that The debug authentication module is connected to a hardware communication interface, and the hardware communication interface is connected to the cryptographic service engine through a bus.

5. A method for implementing an MCU debug port protection mechanism, which is implemented by using the circuit architecture described in any one of claims 1-4, characterized in that, The method includes: Receiving an enabled challenge request command, and the configuration information of the challenge request command includes the AP channel to be unlocked and the algorithm type used by the challenge-response protocol; In response to the challenge request command, generating and initiating a challenge request Mailbox command according to the configuration information; When the challenge request Mailbox command is completed and successful, obtaining the challenge information generated by the cryptographic service engine and storing it in the register interface; Receiving an enabled response verification command, which is generated by encrypting the generated challenge information using a pre-agreed algorithm and key; In response to the response verification command, generating and initiating a response verification Mailbox command according to the configuration information; When the response verification Mailbox command is completed and successful, updating the lock state of the corresponding AP to unlock the corresponding AP path.

6. The implementation method of an MCU debug port protection mechanism according to claim 5, characterized in that, The method further includes: when the challenge request Mailbox command is completed but fails, automatically updating the command completion status register and outputting that the challenge request command fails.

7. The implementation method of an MCU debug port protection mechanism according to claim 5, characterized in that The method further includes: when the response verification Mailbox command is completed but fails, automatically updating the command completion status register and outputting that the response verification command fails.

Images