Method and system for authentication authorization unlocking of a debug interface
By introducing the PB covert channel and the improved XTEA cryptographic hardware state machine into the RISC-V debug interface, the vulnerability of the debug interface to attacks in integrated circuit hardware security is solved, achieving highly secure chip debug access control and preventing key leakage and physical attacks.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANDONG UNIV
- Filing Date
- 2026-05-09
- Publication Date
- 2026-06-05
AI Technical Summary
In the existing technology, the debugging interface in the field of integrated circuit hardware security and chip debugging is vulnerable to fuzzing and side-channel analysis attacks, leading to key leakage and denial-of-service vulnerabilities. Existing authentication request interfaces are exposed and difficult to defend against high-level physical attacks.
It adopts a dual hardware gateway architecture based on PB covert channel sequence detection and improved XTEA cryptographic security authentication. Through non-intrusive multi-level security defense logic, it uses the covert channel in the RISC-V specification and hardware TRNG to generate dynamic challenge codes, build a dedicated hardwired path, bypass the system data bus to obtain an unclonable hardware ID as the root key, and achieve constant-time secure operation.
It effectively defends against fuzz testing and denial-of-service attacks, cuts off illegal interaction channels, prevents key leakage, enhances security against physical attacks, reduces system wiring complexity and area overhead, and achieves high-security debugging access control.
Smart Images
Figure CN122153883A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of debugging and authentication technology, and in particular relates to a method and system for authentication, authorization and unlocking of debugging interfaces. Background Technology
[0002] In the field of integrated circuit hardware security and chip debugging, in order to prevent malicious attackers from using the underlying physical debugging interface to obtain sensitive chip data or tamper with firmware, existing technologies usually introduce an authentication mechanism in the on-chip debug module (DM).
[0003] However, the authentication request interface of existing technologies is in a "publicly exposed" state. Any external device physically connected to the JTAG port can send signature verification requests to it, allowing malicious attackers to use automated tools to continuously and frequently inject massive amounts of junk data into the authentication data register (i.e., fuzzing attacks). This not only consumes a large amount of computing power of the chip's built-in ECC algorithm core, but may even cause the internal security state machine to overload and crash, leading to denial-of-service (DoS) vulnerabilities.
[0004] Furthermore, existing technologies directly call the built-in general-purpose ECC cryptographic algorithm core for signature verification. In modern high-level physical attacks, attackers often use high-precision oscilloscopes to collect power consumption fluctuations or timing differences during the chip's cryptographic operations to deduce the key. The verification process of existing technologies has a significant risk of key leakage when faced with power consumption analysis or timing side-channel analysis. Summary of the Invention
[0005] To overcome the shortcomings of the prior art, this invention provides an authentication, authorization, and unlocking method and system for the debug interface. Through a dual hardware gateway architecture based on sequence detection and cryptographic security authentication using a PB covert channel, non-intrusive multi-level security defense logic is deeply embedded in the debug module interface (DMI) bus path without violating the RISC-V standard debugging specifications. This effectively overcomes the defects of the prior art architecture, such as strong invasiveness and easy key leakage.
[0006] To achieve the above objectives, one or more embodiments of the present invention provide the following technical solutions: The first aspect of this invention provides an authentication, authorization, and unlocking method for a debugging interface.
[0007] The authentication, authorization, and unlocking method for the debug interface includes the following steps: Obtain the knock instruction sequence written to the program buffer by the debugger via the DMI interface; When the knock command sequence matches the standard command sequence, the target chip is switched from a fully locked state to a partially unlocked state. Generate random numbers, obtain the encryption operation results of the debugging end based on the random numbers, the preset root key and the target chip ID information, and simultaneously use the same encryption operation method to calculate the expected hardware value in parallel; When the encryption calculation result at the debugging end matches the expected hardware value, the target chip is switched from a semi-unlocked state to a fully unlocked state, completing the authentication and unlocking of the DMI interface and entering the target chip debugging phase.
[0008] A second aspect of the present invention provides an authentication, authorization, and unlocking system for a debugging interface.
[0009] The authentication, authorization, and unlocking system for the debugging interface includes: The knock instruction acquisition module is configured to: acquire the knock instruction sequence written to the program buffer by the debug terminal through the DMI interface; The first matching module is configured to switch the target chip from a fully locked state to a partially unlocked state when the knock command sequence matches the standard command sequence. The encryption operation module is configured to: generate random numbers, obtain the encryption operation results from the debugging end based on the random numbers, the preset root key and the target chip ID information, and simultaneously calculate the expected hardware value in parallel using the same encryption operation method; The second matching module is configured to: when the encryption calculation result of the debugging end matches the expected value of the hardware, change the target chip from a half-unlocked state to a fully unlocked state, complete the authentication and unlocking of the DMI interface, and enter the target chip debugging stage.
[0010] The above one or more technical solutions have the following beneficial effects: This invention provides a method and system for authenticating and unlocking a debug interface. Through a dual hardware gateway architecture based on sequence detection and cryptographic security authentication using a PB covert channel, it cleverly utilizes the fault-tolerant feature of the RISC-V specification, which ignores PB writes by default in the unauthenticated state, thus creating a covert channel for PB. In the locked state, the underlying cryptographic engine is in deep sleep, responding no to conventional authentication probes; it is only awakened when a specific "knock sequence" is captured. This mechanism completely cuts off the attacker's illegal interaction with the cryptographic engine, providing physical immunity to fuzzing and denial-of-service attacks.
[0011] This invention constructs a dedicated hardwired path within the state machine, directly reading the unclonable Hardware_ID from the underlying eFuse / OTP array as the root key. This ciphertext acquisition path completely bypasses the system data bus and software-addressable memory space, ensuring that even under the most sophisticated firmware privilege escalation attacks, the underlying key cannot be obtained through bus sniffing or out-of-bounds access.
[0012] This invention first utilizes hardware TRNG to generate dynamic challenge codes, ensuring the uniqueness of session ciphertext to defend against replay attacks. The improved XTEA encryption engine maintains an absolutely constant hardware cycle consumption for encryption iterations regardless of changes in input data during encryption calculations. This completely severs the physical correlation between algorithm execution time and key data, preventing attackers from deducing the hardware key through power consumption or timing side-channel analysis, thus greatly enhancing the security level against physical attacks.
[0013] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description
[0014] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.
[0015] Figure 1 This is a flowchart of the method in Example 1.
[0016] Figure 2 This is a transition diagram of the three progressive isolation states in Example 1.
[0017] Figure 3 This is a system structure diagram of Example 2. Detailed Implementation
[0018] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.
[0019] It should be noted that the terminology used herein is for the purpose of describing particular implementations only and is not intended to limit the exemplary implementations of the present invention.
[0020] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.
[0021] Terminology Explanation: DM: On-chip debug module; RISC-V: An open-source instruction set architecture based on the principles of Reduced Instruction Set Computing (RISC); SoC: System on Chip; FLASH: Flash memory; DoS: Denial of Service attack; Fuzzing: Fuzzing attack; ECC: Elliptic Curve Cryptography; RTL: Register Transfer Level; eFuse / OTP: Electronic fuse / One-time programmable memory; Hardware_ID: A unique physical identifier for hardware; TRNG: True Random Number Generator; DMI: Debug Module Interface; PB: Program Buffer; authdata: Authentication data register; dmstatus: Debug module status register; Feistel: A classic cryptographic network architecture.
[0022] Example 1 To address the security vulnerabilities of existing RISC-V on-chip debug interfaces, which are susceptible to physical attacks such as fuzzing and side-channel analysis due to their static exposure, this embodiment proposes an authentication, authorization, and unlocking method for the debug interface. A dual hardware authentication scheme is designed based on a PB covert channel and a constant-time state machine. Without violating the RISC-V standard debug specifications, this embodiment deeply embeds non-intrusive, multi-level security defense logic within the debug module interface (DMI) bus path.
[0023] In addition to the first layer of defense, this embodiment pioneers a covert channel activation technique based on the Program Buffer (PB). It uses a specific instruction sequence to stealthily sniff out legitimate PB write operations; only matching a specific standard instruction sequence can wake up the underlying authentication engine, thus naturally immunizing against brute-force scans of cryptographic interfaces. In terms of the second layer of defense, this embodiment addresses the physical leakage defects of traditional algorithms by designing an improved XTEA cryptographic hardware state machine. This engine not only deeply integrates a true random number generator with a physically isolated chip-specific identifier (Hardware_ID) to completely resist replay attacks, but also strictly locks the clock tick of the encryption iteration at the microarchitecture level, achieving constant-time secure computation to defend against timing side-channel attacks.
[0024] The first layer of defense mechanism mentioned above is mainly used to solve the technical problem that the authentication interface is statically exposed in the existing technology and is extremely vulnerable to fuzz testing and DoS attacks; while the second layer of defense mechanism is mainly used to solve the technical problem that the existing technology lacks a low-level defense mechanism against side-channel attacks on cryptographic operations and does not perform specific security hardening on the underlying hardware execution logic.
[0025] Specifically, such as Figure 1As shown, the authentication, authorization, and unlocking method for the debugging interface provided in this embodiment includes the following steps: Obtain the knock instruction sequence written to the program buffer by the debugger via the DMI interface; When the knock command sequence matches the standard command sequence, the target chip is switched from a fully locked state to a partially unlocked state. Generate random numbers, obtain the encryption operation results of the debugging end based on the random numbers, the preset root key and the target chip ID information, and simultaneously use the same encryption operation method to calculate the expected hardware value in parallel; When the encryption calculation result at the debugging end matches the expected hardware value, the target chip is switched from a semi-unlocked state to a fully unlocked state, completing the authentication and unlocking of the DMI interface and entering the target chip debugging phase.
[0026] In this embodiment, the aforementioned program buffer (PB) needs to be allocated in advance for writing and retrieving the knock instruction sequence.
[0027] It can be understood that the target chip mentioned in this embodiment is the chip that the debugging end needs to debug. After executing the authentication, authorization and unlocking method of the debugging interface in this embodiment, if the authentication and unlocking of the DMI interface can be completed, the debugging phase of the target chip will be entered next; if the authentication and unlocking of the DMI interface cannot be completed, the DMI interface will still be locked and the target chip cannot be debugged.
[0028] Existing authentication interfaces are statically exposed, making them highly vulnerable to automated brute-force attacks. This embodiment constructs a covert channel, providing physical immunity to fuzzing and DoS attacks. This embodiment cleverly utilizes the fault-tolerance feature of the RISC-V specification, which ignores PB writes by default in the unauthenticated state, transforming PB into a covert channel. In the locked state, the underlying cryptographic engine is in deep sleep, responding no to conventional authentication probes; it is only awakened when a specific "knock sequence" is captured. This mechanism completely cuts off the attacker's illegal interaction with the cryptographic engine, providing physical immunity to fuzzing and denial-of-service attacks.
[0029] This embodiment designs a dual hardware authentication scheme based on PB covert channel and constant-time state machine. Based on dual hardware gateway architecture, this embodiment strictly and smoothly divides the physical debugging permission of the target chip into three progressive isolation states: fully locked / compliant sleep state, half unlocked / challenge ready state, and fully unlocked state. While ensuring extremely low bus invasiveness, it achieves the highest level of debugging access control for the chip.
[0030] For ease of description in the following text, the fully locked / compliant dormant state will be referred to as Level 0, the partially unlocked / challenge-ready state as Level 1, and the fully unlocked state as Level 2.
[0031] The three states will now be explained in detail: (1) Level 0: Level 0 corresponds to the fully locked state, which is the default state after the chip is reset.
[0032] In this state, the gateway's hardware firewall strictly adheres to the RISC-V specification, blocking access to core resources. Simultaneously, it maintains open read / write permissions for specific registers such as authdata and dmstatus, in accordance with regulations.
[0033] However, in this embodiment, the underlying XTEA cryptographic hardware state machine is in sleep mode, and the debugger cannot obtain the random challenge value from authdata. Therefore, in this embodiment, the fully locked state can also be called the compliant sleep state.
[0034] (2) Level 1: When the bypass sequence detector in the gateway successfully captures a sequence match targeting PB, the XTEA cryptographic hardware state machine is awakened. At this time, the read and write behavior of the authdata register is dynamically mapped to the internal cryptographic engine, and then a random challenge value (random number) is written to authdata through the pseudo-random number generator, officially initiating the challenge-response handshake.
[0035] Once the pseudo-random number generator generates a random challenge value (random number) and writes it into authdata, the random challenge value is in a ready state. Therefore, the semi-unlocked state in this embodiment can also be called the challenge ready state.
[0036] (3) Level 2: By using the XTEA cryptographic hardware state machine to achieve cryptographic signature verification, the hardware firewall completely removes the address mask, enters a fully unlocked state, and restores full debugging capabilities.
[0037] Figure 2 The diagram shown represents the transition between three progressive isolation states provided in this embodiment. Figure 2In Level 0 (fully locked state), the XTEA cryptographic hardware state machine is locked, and the debugger cannot obtain the challenge value (random number). When the knock instruction sequence matches the standard instruction sequence, the knock instruction sequence authentication is successful, and the target chip is changed from a fully locked state to a partially unlocked state. In Level 1 (partially unlocked state), the XTEA cryptographic hardware state machine is unlocked, and the debugger obtains the challenge value (random number). When the encryption operation result of the debugger matches the expected value of the hardware, the password verification is successful, and the target chip is changed from a partially unlocked state to a fully unlocked state. In Level 2 (fully unlocked state), all permissions of the DM are granted.
[0038] The following section will explain in detail the specific implementation of this embodiment, taking into account the three progressive isolation states mentioned above.
[0039] In this embodiment, under Level 0 state, the debug interface grants write access to the program buffer. Only when an external debugger continuously writes a "specific pseudo-instruction sequence" that perfectly matches the preset characteristics into the PB range will the security state machine be activated from the fully locked state to the Level 1 semi-unlocked state, thus enabling the next step of authentication.
[0040] In the Level 1 semi-unlocked state, the authentication process employs a two-way dynamic challenge-response protocol. This protocol consists of four strict time-series phases: The first stage is the challenge generation phase. The debugger initiates a read operation on authdata, triggering an internal linear feedback shift register based on primitive polynomials to latch the current state, generate a random challenge code (random number), and return it through the bus. The next step is the response computation phase, where the debugger performs encryption operations on the host side using the preset root key, the acquired random challenge code (random number), and the target chip's ID information; Next is the response submission phase, where the debugger writes the calculated response value (the result of the encryption operation on the debugger end) into the authdata register; Finally, in the hardware verification phase, the host response (the encrypted calculation result from the debugger) is compared with the expected hardware value. If they match, the bus isolation is released; otherwise, it enters a fully locked state.
[0041] The aforementioned hardware expectations are calculated using an internal engine.
[0042] In the aforementioned response calculation phase, addressing the adaptability issues of traditional symmetric encryption algorithms in embedded resource-constrained scenarios and the risk of batch cracking faced by unified key management, this embodiment proposes an improved XTEA encryption engine based on physical feature binding. The XTEA algorithm, based on the Feistel network architecture, achieves data obfuscation and diffusion through a mixture of XOR, shift, and addition operations, exhibiting extremely high hardware implementation efficiency.
[0043] In existing technologies, the authorization management module needs to dynamically retrieve the public key from the chip's internal FLASH memory during signature verification. Since FLASH is typically mounted on the system data bus, this "cross-bus key reading" exposes the root of trust to the chip's public data path. If the chip's operating system is subjected to privilege escalation attacks, malicious firmware can easily intercept or even tamper with the key data stored in the FLASH through bus sniffing or illegal addressing, causing the underlying hardware defense system to be completely compromised from the software perspective.
[0044] This embodiment constructs a dedicated hardwired path within the state machine, directly reading the unclonable Hardware_ID from the underlying eFuse / OTP array as the root key. This ciphertext acquisition path completely bypasses the system data bus and software-addressable memory space. Even if the system suffers the most advanced firmware privilege escalation attack, it cannot obtain the underlying key through bus sniffing or out-of-bounds access, achieving absolute physical isolation of the root of trust and effectively blocking system bus acquisition.
[0045] Specifically, to address the serious physical exposure risk of the aforementioned root of trust (key) acquisition path and to endow the algorithm with anti-cloning properties, this embodiment innovatively reconstructs the iterative logic of the standard XTEA algorithm, introducing a chip-specific physical identifier as a perturbation factor for the operation. The improved iterative operation logic is described as follows:
[0046]
[0047] In the formula, i represents the iteration round of the state machine, i∈[1, N], where N is the fixed total number of iteration rounds of the encryption algorithm (N=32). This represents the state value of the internal accumulator after the i-th iteration, and its initial value. ; δ represents the internal accumulator state value after the (i-1)th iteration calculation; δ represents the golden ratio constant, used to ensure the nonlinear perturbation of each round of encryption; This represents the private hardware root key of the target chip (mapped from Hardware_ID). This represents the response data state after the i-th iteration calculation, and its initial input... The dynamic random challenge code generated by TRNG in the security authentication module, and the final output The authentication credentials returned to the host in the response; This represents the response data state after the (i-1)th iteration calculation; Represents the module in hardware operations Arithmetic addition; This indicates a bitwise XOR logic operation; This represents the shift and scramble round functions within the improved XTEA.
[0048] The Hardware_ID comes from the one-time programmable memory at the top level of the SoC or the processor's hardware identifier register. This identifier is obtained directly through a dedicated hardware path, thereby achieving complete isolation from the system software bus in terms of physical topology and avoiding the risk of tampering at the software level.
[0049] Based on this hardware fingerprint binding mechanism, the algorithm logic in this embodiment establishes a strong mapping relationship between the validity of the key and the physical entity of the chip. Even if an attacker intercepts the global root key, the response value they construct will fail hardware verification due to the lack of the target chip's unique physical fingerprint parameters, thus establishing a security protection boundary based on the uniqueness and non-cloning nature of the hardware entity.
[0050] Furthermore, existing technologies require an additional authorization management module beyond the standard DM module, and a dedicated internal serial interface for cross-module communication. This loosely coupled external design not only increases the chip's wiring complexity and area overhead, but also severely disrupts the original bus topology of the RISC-V debug standard, making it difficult to port and reuse this solution as a standard IP with high versatility. This embodiment deeply integrates the security authentication module into the standard DMI (Debug Module Interface) bus data path as a transparent gateway, and uses a reuse mechanism based on existing standard registers for secure interaction between low-level identifiers and challenge-response data, thereby completely eliminating the dependence on non-standard external physical connections or dedicated cross-module serial interfaces.
[0051] This tightly coupled, inline architecture design not only enables cycle-level physical interception of illegal access requests at the hardware level, but also perfectly implements high-level security authentication functions without any intrusion into the existing RISC-V debug bus topology or modification of the upper-layer standard debug toolchain. Compared to the external solutions of existing technologies, this embodiment greatly reduces system routing complexity and additional area overhead, enabling this secure debug architecture to be used as a highly standardized, lightweight IP with high versatility for porting and reuse in various RISC-V SoCs.
[0052] Example 2 This embodiment discloses an authentication, authorization, and unlocking system for the debugging interface.
[0053] The authentication, authorization, and unlocking system for the debugging interface includes: The knock instruction acquisition module is configured to: acquire the knock instruction sequence written to the program buffer by the debug terminal through the DMI interface; The first matching module is configured to switch the target chip from a fully locked state to a partially unlocked state when the knock command sequence matches the standard command sequence. The encryption operation module is configured to: generate random numbers, obtain the encryption operation results from the debugging end based on the random numbers, the preset root key and the target chip ID information, and simultaneously calculate the expected hardware value in parallel using the same encryption operation method; The second matching module is configured to: when the encryption calculation result of the debugging end matches the expected value of the hardware, change the target chip from a half-unlocked state to a fully unlocked state, complete the authentication and unlocking of the DMI interface, and enter the target chip debugging stage.
[0054] like Figure 3 The diagram shown is a schematic representation of the system structure in this embodiment. Figure 3 The diagram illustrates the data interaction process of the various execution entities corresponding to the knock instruction acquisition module, the first matching module, the encryption calculation module, and the second matching module in this embodiment. Furthermore, Figure 3 It also includes the DM internal Program Buffer, DMI interface, DM internal registers (accessible portion), and other DM internal registers (protected).
[0055] Specifically, in this embodiment, the execution entities corresponding to the knock instruction acquisition module, the first matching module, the encryption calculation module, and the second matching module include a PB detector, a pseudo-random number generator, and a finite state machine. Wherein: debugger( Figure 3 (Not shown in the image) The knock instruction sequence is written to the program buffer (internal to the DM) via the DMI interface, corresponding to... Figure 3 Write progbuf between the DMI interface and the DM's internal Program Buffer; A bypass sequence detector, namely the PB detector, is set up in parallel with the DMI bus. The PB detector is used to obtain the knock instruction sequence written to the program buffer by the debug end through the DMI interface and compare it with the standard instruction sequence. When the knock instruction sequence matches the standard instruction sequence, an unlock instruction is sent to the pseudo-random number generator to unlock the pseudo-random number generator. The target chip is then converted from a fully locked state to a half-unlocked state through a finite state machine. Next, the pseudo-random number generator generates a 32-bit challenge code (random number) and writes it to the authdata register in the DM internal register (accessible part); The debugger obtains a 32-bit challenge code (random number) from the authdata register via the DMI bus. The debugger performs encryption operations based on the random number, the preset root key, and the target chip ID information to obtain the encryption result. The debugger writes the calculated encryption result into the authdata register; The finite state machine obtains the encryption operation result from the authdata register and synchronously calculates the expected hardware value using the same encryption method. It compares the encryption operation result with the expected hardware value. When the encryption operation result at the debugging end matches the expected hardware value, the target chip is switched from a half-unlocked state to a fully unlocked state.
[0056] The aforementioned finite state machine is used for computational control. When executing computational logic, it needs to obtain a pre-stored key and target chip ID information, where the target chip ID information is obtained directly through a dedicated hardware path.
[0057] Figure 3 In addition to the authdata register, the DM internal registers (accessible portion) also include other registers, such as the dmstatus register and the dmcontrol register.
[0058] In addition, the finite state machine sends signals to other protected registers within the DM, such as the dmstatus register, to indicate whether the verification has passed. Specifically, this includes auth_passed_o and busy_o. Sending auth_passed_o indicates that the verification has passed; sending busy_o indicates that the verification is in progress.
[0059] Those skilled in the art will understand that the modules or steps of the present invention described above can be implemented using general-purpose computer devices. Optionally, they can be implemented using computer-executable program code, thereby allowing them to be stored in a storage device for execution by a computer device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. The present invention is not limited to any particular combination of hardware and software.
[0060] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.
Claims
1. A method for authenticating, authorizing, and unlocking a debugging interface, characterized in that, Includes the following steps: Obtain the knock instruction sequence written to the program buffer by the debugger via the DMI interface; When the knock command sequence matches the standard command sequence, the target chip is switched from a fully locked state to a partially unlocked state. Generate random numbers, obtain the encryption operation results of the debugging end based on the random numbers, the preset root key and the target chip ID information, and simultaneously use the same encryption operation method to calculate the expected hardware value in parallel; When the encryption calculation result at the debugging end matches the expected hardware value, the target chip is switched from a semi-unlocked state to a fully unlocked state, completing the authentication and unlocking of the DMI interface and entering the target chip debugging phase.
2. The authentication, authorization, and unlocking method for the debugging interface as described in claim 1, characterized in that, The physical debugging permissions of the target chip are pre-defined into three progressive isolation states: fully locked, partially unlocked, and fully unlocked. The default state after the target chip is reset is set to fully locked.
3. The authentication, authorization, and unlocking method for the debugging interface as described in claim 1, characterized in that, A program buffer is pre-set. When the target chip is in a fully locked state, write access to the program buffer is granted, allowing the debugger to write knock instruction sequences to the program buffer through the DMI interface.
4. The authentication, authorization, and unlocking method for the debugging interface as described in claim 1, characterized in that, After the target chip enters a semi-unlocked state: The debugging end first initiates a read operation on the internal register of DM, which in turn triggers the pseudo-random number generator to generate random numbers; The random number is written to the internal register of DM and returned to the debug terminal through the DMI interface.
5. The authentication, authorization, and unlocking method for the debugging interface as described in claim 1, characterized in that, The encryption calculation result of the debugging terminal is calculated in the following way: ； ； In the formula, i represents the iteration round of the state machine, i∈[1, N], where N is the fixed total number of iteration rounds of the encryption algorithm; This represents the state value of the internal accumulator after the i-th iteration calculation; The internal accumulator state value is represented by δ after the (i-1)th iteration calculation; δ represents the golden ratio constant. This represents the private hardware root key at the target chip's underlying layer; This represents the response data state after the i-th iteration calculation; This represents the response data state after the (i-1)th iteration calculation; Represents the module in hardware operations Arithmetic addition; This indicates a bitwise XOR logic operation; This represents the shift and scramble wheel functions within the improved XTEA.
6. The authentication, authorization, and unlocking method for the debugging interface as described in claim 1, characterized in that, The target chip ID information is obtained directly through a dedicated hardware path, thereby achieving complete isolation from the software bus in terms of physical topology.
7. The authentication, authorization, and unlocking method for the debugging interface as described in claim 1, characterized in that, With the target chip fully unlocked, the hardware firewall completely removes the address mask, restoring full chip debugging capabilities.
8. The authentication, authorization, and unlocking method for the debugging interface as described in claim 2, characterized in that, When the physical debugging permissions of the target chip are fully locked, the debugging end cannot obtain random numbers.
9. The authentication, authorization, and unlocking method for the debugging interface as described in claim 1, characterized in that, The knocking instruction sequence is a preset pseudo-instruction sequence.
10. An authentication, authorization, and unlocking system for a debugging interface, characterized in that, include: The knock instruction acquisition module is configured to: acquire the knock instruction sequence written to the program buffer by the debug terminal through the DMI interface; The first matching module is configured to switch the target chip from a fully locked state to a partially unlocked state when the knock command sequence matches the standard command sequence. The encryption operation module is configured to: generate random numbers, obtain the encryption operation results from the debugging end based on the random numbers, the preset root key and the target chip ID information, and simultaneously calculate the expected hardware value in parallel using the same encryption operation method; The second matching module is configured to: when the encryption calculation result of the debugging end matches the expected value of the hardware, change the target chip from a half-unlocked state to a fully unlocked state, complete the authentication and unlocking of the DMI interface, and enter the target chip debugging stage.