Chip DEBUG device and method

Abstract

The invention relates to the field of chip verification, in particular to a chip DEBUG device and method. An identity authentication mechanism is introduced in the DEBUG process of the chip, when remote DEBUG debugging or firmware upgrading is carried out on a PC end, firstly, identity authentication is carried out on a GDB end and an OPENOCD Server end, connection is established, secondly, identity authentication is carried out on the OPENOCD Server end and a DM module of the chip, connection is established through a JTAG, in this way, a safe DEBUG access of the chip is achieved, and the safety of the chip is improved. And the IP of the chip and the stored sensitive data are protected. The chip is internally provided with the DM module, the identity authentication module is added on the basis of the DM module, and a real debugging channel can be established only after authentication is passed, so that the legality of JTAG access is ensured through the mode. According to the method, the security of chip DEBUG and firmware mass production upgrading is greatly improved, and the method has a wide application prospect in the field of information security.

Description

Technical Field

[0001] The present invention relates to the field of chip verification, and in particular to a chip DEBUG device and method. Background Art

[0002] There are many angles and methods for chip debugging, involving software and hardware tools such as GDB, OPENOCD, Adapter, and JTAG, DM and other modules inside the chip. Among them, the JTAG interface of the chip can not only be used for DEBUG debugging, but also for upgrading firmware, reading FLASH, etc. While the JTAG interface brings convenience, it also has security risks, because illegal visitors can read sensitive information stored in the chip and FLASH through the JTAG interface. Usually, after the DEBUG is completed, when the chip is officially mass-produced, the JTAG debugging interface is usually closed considering the security risks brought by the JTAG interface. However, even if the JTAG interface is closed, it can still be opened by configuring registers, etc., which poses a security risk. At the same time, after the JTAG interface is closed, it brings inconvenience to subsequent DEBUG debugging and firmware upgrades. Summary of the invention

[0003] The technical problem to be solved by the present invention is to provide a chip DEBUG device and method, which introduces an identity authentication mechanism in the chip DEBUG process. When the PC performs remote DEBUG debugging or upgrades the firmware, first the GDB end (remote PC) and the OPENOCD Server end (local PC) perform identity authentication and establish a connection. Then the OPENOCD Server end and the DM module of the chip perform identity authentication and establish a connection through JTAG. In this way, a chip security DEBUG path is realized, and the chip IP and stored sensitive data are protected.

[0004] In order to solve the technical problem, the technical solution adopted by the present invention is: a chip DEBUG device, including a remote PC, a local PC and a development board equipped with a chip to be tested, the remote PC runs GDB software, the local PC runs OpenOCD, and OpenOCD is used as GDB Server, used for receiving GDB instructions and converting them into JTAG instructions and sending them to the development board. The development board is equipped with a DTM module, a DMI module, a DM module and a chip to be tested. The DTM module receives instructions from the local PC and sends the instructions to the DM module through the DMI module. The DM module is connected to the chip to be tested. The remote PC end is equipped with a first identity authentication module, the local PC end is equipped with a second identity authentication module, and the development board is equipped with an authorization management module. The first identity authentication module and the second identity authentication module cooperate to realize the identity authentication of the remote PC and the local PC. After the authentication is passed, a data ciphertext channel is established between the remote PC and the local PC to realize data encryption transmission. The second identity authentication module and the authorization management module cooperate to realize the identity authentication of the local PC and the DM module on the development board. After the authentication is passed, the DM module has the right to access the resources on the chip to be tested. OpenOCD sends debugging instructions to the DM module and returns the debugging results to the local PC to realize the debugging of the chip to be tested.

[0005] Furthermore, the first identity authentication module implements the security authentication process of the remote PC and the local PC as follows: S11. First, configure the GDB Server and IP. This device runs OpenOCD on the local PC as the GDBServer. After OpenOCD is started, the listening port is opened and the remote PC initiates a connection request. S12, start the GDB of the remote PC and establish a connection with the local PC; S13, the remote PC generates a group of messages MSG1, and the first identity authentication module performs a hash operation on the message MSG1 to generate MSG1 ” , using the private key PRIKEY1 in the first identity authentication module to authenticate MSG1 ” Sign and generate signature value R1; S14, the remote PC sends the signature value R1 and the message MSG1 to the local PC, and the local PC uses the public key PUBKEY1 from the second identity authentication module to verify the signature. If the verification is successful, it indicates that the visitor from the GDB module is legal. If the verification fails, it indicates that the visitor from the GDB module is illegal. The public key PUBKEY1 and the private key PRIKEY1 are a pair of asymmetric keys. S15. After the local PC passes the signature verification, the second identity authentication module generates a set of random numbers as the session key SK, and encrypts SK with the public key PUBKEY1 and sends it to the remote PC. After receiving it, the remote PC decrypts SK with the private key PRIKEY1. Both parties encrypt the exchanged data with SK and establish a data ciphertext channel.

[0006] Furthermore, the second identity authentication module and the authorization management module implement the identity authentication process between the local PC and the DM module on the development board as follows: S21, the local PC generates a group of messages MSG2 and sends it to the second ID card authentication module, and the second ID card authentication module performs a hash operation on the message MSG2 to generate MSG2 ” , using the asymmetric private key PRIKEY2 in the second identity authentication module to authenticate MSG2 ” Sign and generate signature value R2; S22, the local PC will MSG2 ” And the signature value R2 is sent to the authorization management module on the development board; S23, the authorization management module receives MSG2 ” And the signature value R2, the data is verified by the internally stored asymmetric public key PUBKEY2, and the verification result is fed back to the DM module. After the verification is passed, the DM module has the right to access the resources on the chip under test; if the verification fails, the DM module cannot access the resources on the chip; the public key PUBKEY2 and the private key PRIKEY2 are a pair of asymmetric keys; S24. After the signature verification is passed, OpenOCD sends a debugging command to the DM module to obtain the debugging result.

[0007] Furthermore, an authentication data register is provided in the DM module, and the register is connected to the authorization management module through a serial interface. When the identity card verification information of the second identity authentication module is not received, the Authbusy status position of the authentication data register is 1. When the identity card verification information of the second identity authentication module is received, the DM module sets the Authbusy position of the authentication data register to 0. When Authbusy is set to 0, the authentication data register is communicated with the authorization management module by reading or writing; After receiving the authentication request from the DM module, the authorization management module obtains the public key PUBKEY2 from the FLASH in the chip. This public key and the private key PRIKEY2 in UKEY2 are the same asymmetric key pair. The authentication information written by the authorization management module to the DM module is MSG2. ”And the signature value R2, the signature is verified by the chip's built-in algorithm core ECC cryptographic algorithm. After the signature verification passes, the result is returned to the DM module, and the Authenticated bit in the DM module status register is set to 1, which means that the DM module can access all resources in the chip.

[0008] Furthermore, the local PC is connected to the development board through an Adapter, one end of the Adapter is connected to the USB interface of the local PC, and the other end is connected to the JTAG port in the development board. The USB instructions or data of OpenOCD are converted into instructions of the JTAG protocol specification through the Adapter.

[0009] Furthermore, the message MSG1 or the message MSG2 is generated by calling the security interface of OPENSSL, and the public key PUBKEY1 is called to verify the signature by calling the security interface of OPENSSL.

[0010] The present invention also discloses a chip DEBUG method. The method is provided with a first identity authentication module on a remote PC end, a second identity card authentication module on a local PC end, and an authorization management module on a development board. The first identity authentication module and the second identity card authentication module cooperate to realize identity authentication between the remote PC and the local PC. After the authentication is passed, a data ciphertext channel is established between the remote PC and the local PC to realize data encryption transmission. The second identity authentication module and the authorization management module cooperate to realize identity authentication between the local PC and a DM module on the development board. After the authentication is passed, the DM module has the right to access resources on the chip to be tested. OpenOCD sends a debugging instruction to the DM module and returns the debugging result to the local PC to realize debugging of the chip to be tested.

[0011] Furthermore, the first identity authentication module implements the security authentication process of the remote PC and the local PC as follows: S11. First, configure the GDB Server and IP. This device runs OpenOCD on the local PC as the GDBServer. After OpenOCD is started, the listening port is opened and the remote PC initiates a connection request. S12, start the GDB of the remote PC and establish a connection with the local PC; S13, the remote PC generates a group of messages MSG1, and the first identity authentication module performs a hash operation on the message MSG1 to generate MSG1 ” , using the private key PRIKEY1 in the first identity authentication module to authenticate MSG1 ” Sign and generate signature value R1; S14, the remote PC sends the signature value R1 and the message MSG1 to the local PC, and the local PC uses the public key PUBKEY1 from the second identity authentication module to verify the signature. If the verification is successful, it indicates that the visitor from the GDB module is legal. If the verification fails, it indicates that the visitor from the GDB module is illegal. The public key PUBKEY1 and the private key PRIKEY1 are a pair of asymmetric keys. S15. After the local PC passes the signature verification, the second identity authentication module generates a set of random numbers as the session key SK, and encrypts SK with the public key PUBKEY1 and sends it to the remote PC. After receiving it, the remote PC decrypts SK with the private key PRIKEY1. Both parties encrypt the exchanged data with SK and establish a data ciphertext channel.

[0012] Furthermore, the second identity authentication module and the authorization management module implement the identity authentication process between the local PC and the DM module on the development board as follows: S21, the local PC generates a group of messages MSG2 and sends it to the second ID card authentication module, and the second ID card authentication module performs a hash operation on the message MSG2 to generate MSG2 ” , using the asymmetric private key PRIKEY2 in the second identity authentication module to authenticate MSG2 ” Sign and generate signature value R2; S22, the local PC will MSG2 ” And the signature value R2 is sent to the authorization management module on the development board; S23, the authorization management module receives MSG2 ” And the signature value R2, the data is verified by the internally stored asymmetric public key PUBKEY2, and the verification result is fed back to the DM module. After the verification is passed, the DM module has the right to access the resources on the chip under test; if the verification fails, the DM module cannot access the resources on the chip; the public key PUBKEY2 and the private key PRIKEY2 are a pair of asymmetric keys; S24. After the signature verification is passed, OpenOCD sends a debugging command to the DM module to obtain the debugging result.

[0013] Furthermore, an authentication data register is provided in the DM module, and the register is connected to the authorization management module through a serial interface. When the identity card verification information of the second identity authentication module is not received, the Authbusy status position of the authentication data register is 1. When the identity card verification information of the second identity authentication module is received, the DM module sets the Authbusy position of the authentication data register to 0. When Authbusy is set to 0, the authentication data register is communicated with the authorization management module by reading or writing; After receiving the authentication request from the DM module, the authorization management module obtains the public key PUBKEY2 from the FLASH in the chip. This public key and the private key PRIKEY2 in UKEY2 are the same asymmetric key pair. The authentication information written by the authorization management module to the DM module is MSG2. ” And the signature value R2, the signature is verified by the chip's built-in algorithm core ECC cryptographic algorithm. After the signature verification passes, the result is returned to the DM module, and the Authenticated bit in the DM module status register is set to 1, which means that the DM module can access all resources in the chip.

[0014] Beneficial effects of the present invention: The present invention introduces a security authentication mechanism in the chip DEBUG process, specifically, the security authentication of the GDB end and the GDB SERVER end, the identity authentication of the GDB SERVER end and the chip debugging module, and the security authentication mechanism inside the chip. Through the above authentication process, the backdoor security vulnerability of the chip can be avoided, the chip remote DEBUG method is realized, the security of chip remote debugging and firmware upgrade is improved, and it has broad application prospects in the field of security applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is a schematic diagram of the chip DEBUG architecture of the present invention; Figure 2 This is a schematic diagram of the security authentication process of the GDB side and the GDB SERVER side; Figure 3 Schematic diagram of the authentication process between OpenOCD and the chip's debugging module. DETAILED DESCRIPTION

[0016] The present invention will be further described below in conjunction with the accompanying drawings and specific implementations.

[0017] Example 1 First, some English abbreviations appearing in the present invention are explained: DEBUG: debugging, troubleshooting.

[0018] DM: Debug Manager, debugging management module.

[0019] GDB: GNU symbolic debugger, a program code debugging tool under Linux system.

[0020] OpenOCD: Open-On-Chip-Debug, an open source chip debugging tool.

[0021] This embodiment discloses a chip DEBUG device, such as Figure 1As shown, it includes a remote PC, a local PC, and a development board equipped with a chip to be tested. The remote PC runs GDB software, and the local PC runs OpenOCD. OpenOCD acts as a GDBServer, provides LIBUSB driver, drives the JTAG adapter and ID card verification module, and runs OpenOCD tool software, which receives GDB instructions and converts them into JTAG instructions and sends them to the development board. Specifically, the local PC and the development board are connected through an Adapter adapter, one end of the Adapter adapter is connected to the USB interface of the local PC, and the other end is connected to the JTAG port in the development board. The USB instructions or data of OpenOCD are converted into instructions of the JTAG protocol specification through the Adapter adapter.

[0022] The development board is equipped with a DTM module (Debug transmission control module), a DMI module (Debug interface module), a DM module (Debug management module) and a chip to be tested. The DTM module receives instructions from the local PC and sends the instructions to the DM module through the DMI module. The DM module is connected to the chip to be tested. The DM module controls the CPU Core, reads registers, accesses memory and FLASH storage space internally, and is connected to the JTAG controller externally. The interface of the JTAG controller is connected to the PAD module of the chip.

[0023] The remote PC is provided with a first identity authentication module UKEY1, the local PC is provided with a second identity card authentication module UKEY2, and the development board is provided with an authorization management module AM. The first identity authentication module UKEY1 and the second identity card authentication module UKEY2 cooperate to realize the identity authentication between the remote PC and the local PC. After the authentication is passed, a data ciphertext channel is established between the remote PC and the local PC to realize data encryption transmission. The second identity authentication module UKEY2 and the authorization management module AM ​​cooperate to realize the identity authentication between the local PC and the DM module on the development board. After the authentication is passed, the DM module has the right to access the resources on the chip to be tested. OpenOCD sends debugging instructions to the DM module and returns the debugging results to the local PC to realize debugging of the chip to be tested.

[0024] When debugging a chip, GDB transfers the debugging code or command to the SoC on the development board for execution. First, GDB and OpenOCD authenticate each other via TCP. After authentication, GDB and OpenOCD are successfully connected, a negotiation key is generated, and the data link is encrypted. GDB sends the debugging code or command, which OpenOCD receives and decrypts and parses. It then translates it into a target platform DEBUG protocol command based on the target type, adapter model, and protocol used, and calls the underlying USB driver to send it to the JTAG adapter. OpenOCD and the DM module of the development board must first be authenticated. After authentication, OpenOCD can normally interact with the DM module through the JTAG interface of the adapter to access other modules.

[0025] In the internal architecture of the chip, in order to protect the chip intellectual property rights and internal sensitive data, this method introduces a security authentication control register and an authorization management module AM, which locks the access to the debugging module by default, and only allows visitors who have passed the identity authentication to unlock the DM module. It also provides a secure identity authentication mechanism. When the value of the security authentication control register is 0, the DM module is in a locked state and is not allowed to access other modules of the hardware platform. When the identity authentication is passed, the value of the security authentication control register is 1. At this time, the DM module can interact with other modules and access hardware resources. In order to support identity authentication, the internal architecture of the chip sets an authentication data register for the 32-bit serial port connected to the authentication module. When the debugger initiates an authentication request, the debugger can communicate with the identity authentication module by reading or writing this register.

[0026] In this embodiment, the authentication method of the GDB end and the GDB Server end is mainly implemented through the identity authentication module and the security mechanism of OPENSSL, such as Figure 2 As shown, the first identity authentication module implements the security authentication process of the remote PC and the local PC as follows: S11. First, configure the GDB Server and IP (10.0.0.64). In this method, the OpenOCD tool is used. After OpenOCD is started, it is configured to listen to port 8888 and wait for the remote debugging host GDB to initiate a connection request. S12. Start the GDB on the remote PC and establish a connection with the Server (OpenOCD) through the "targetremote 10.0.0.64:8888" command; S13, the remote PC calls the security interface of OPENSSL to generate a group of messages MSG1, and the first identity authentication module performs a hash operation on the message MSG1 to generate MSG1 ”, using the private key PRIKEY1 in the first identity authentication module to authenticate MSG1 ” Sign and generate signature value R1; S14, the remote PC sends the signature value R1 and the message MSG1 to the local PC, and the local PC calls the security interface of OPENSSL and uses the public key PUBKEY1 from the second identity authentication module to verify the signature. If the signature verification passes, it indicates that the visitor from the GDB module is legal. If the signature verification fails, it indicates that the visitor from the GDB module is illegal; the public key PUBKEY1 and the private key PRIKEY1 are a pair of asymmetric keys; S15. After the local PC passes the signature verification, the second identity authentication module generates a set of random numbers as the session key SK, and encrypts SK with the public key PUBKEY1 and sends it to the remote PC. After receiving it, the remote PC decrypts SK with the private key PRIKEY1. Both parties encrypt the exchanged data with SK and establish a data ciphertext channel.

[0027] In this embodiment, OpenOCD interacts with the chip as a server and directly accesses the chip through JTAG, which is a direct bridge between GDB and the chip. Figure 3 As shown, the second identity authentication module and the authorization management module implement the identity authentication process between the local PC and the DM module on the development board as follows: S21, the local PC generates a group of messages MSG2 through the OPENSSL interface and sends it to the second ID card authentication module, and the second ID card authentication module performs a hash operation on the message MSG2 to generate MSG2 ” , using the asymmetric private key PRIKEY2 in the second identity authentication module to authenticate MSG2 ” Sign and generate signature value R2; S22, the local PC will MSG2 ” The signature value R2 is converted into JTAG protocol through the USB interface by the Adapter and sent to the authorization management module on the development board; S23, the authorization management module receives MSG2 ” And the signature value R2, the data is verified by the internally stored asymmetric public key PUBKEY2, and the verification result is fed back to the DM module. After the verification is passed, the DM module has the right to access the resources on the chip under test; if the verification fails, the DM module cannot access the resources on the chip; the public key PUBKEY2 and the private key PRIKEY2 are a pair of asymmetric keys; S24. After the signature verification is passed, OpenOCD sends a debugging command to the DM module to obtain the debugging result.

[0028] In this embodiment, an authentication data register is provided in the DM module, and the register is connected to the authorization management module through a 32-bit serial interface. When the identity card verification information of the second identity authentication module is not received, the Authbusy status position of the authentication data register is 1. When the identity card verification information of the second identity authentication module is received, the DM module sets the Authbusy position of the authentication data register to 0. When Authbusy is set to 0, the debugger can communicate with the authorization management module by reading or writing this register; After receiving the authentication request from the DM module, the authorization management module obtains the public key PUBKEY2 from the FLASH in the chip. This public key and the private key PRIKEY2 in UKEY2 are the same asymmetric key pair. The authentication information written by the authorization management module to the DM module is MSG2. ” And the signature value R2, the signature is verified by the chip's built-in algorithm core ECC cryptographic algorithm. After the signature verification passes, the result is returned to the DM module, and the Authenticated bit in the security authentication control register is set to 1, which means that the DM module can access all resources in the chip.

[0029] Example 2 This embodiment discloses a chip DEBUG method, which is implemented based on the chip DEBUG device described in Embodiment 1, including security authentication of the GDB end and the GDB SERVER end, identity authentication of the GDB SERVER end and the chip debugging module, and a security authentication mechanism inside the chip. The security authentication process of each part is as follows: The first identity authentication module implements the security authentication process of the remote PC and the local PC as follows: S11. First, configure the GDB Server and IP. This device runs OpenOCD on the local PC as the GDBServer. After OpenOCD is started, the listening port is opened and the remote PC initiates a connection request. S12, start the GDB of the remote PC and establish a connection with the local PC; S13, the remote PC generates a group of messages MSG1, and the first identity authentication module performs a hash operation on the message MSG1 to generate MSG1 ” , using the private key PRIKEY1 in the first identity authentication module to authenticate MSG1 ” Sign and generate signature value R1; S14, the remote PC sends the signature value R1 and the message MSG1 to the local PC, and the local PC uses the public key PUBKEY1 from the second identity authentication module to verify the signature. If the verification is successful, it indicates that the visitor from the GDB module is legal. If the verification fails, it indicates that the visitor from the GDB module is illegal. The public key PUBKEY1 and the private key PRIKEY1 are a pair of asymmetric keys. S15. After the local PC passes the signature verification, the second identity authentication module generates a set of random numbers as the session key SK, and encrypts SK with the public key PUBKEY1 and sends it to the remote PC. After receiving it, the remote PC decrypts SK with the private key PRIKEY1. Both parties encrypt the exchanged data with SK and establish a data ciphertext channel.

[0030] The second identity authentication module and the authorization management module implement the identity authentication process between the local PC and the DM module on the development board as follows: S21, the local PC generates a group of messages MSG2 and sends it to the second ID card authentication module, and the second ID card authentication module performs a hash operation on the message MSG2 to generate MSG2 ” , using the asymmetric private key PRIKEY2 in the second identity authentication module to authenticate MSG2 ” Sign and generate signature value R2; S22, the local PC will MSG2 ” And the signature value R2 is sent to the authorization management module on the development board; S23, the authorization management module receives MSG2 ” And the signature value R2, the data is verified by the internally stored asymmetric public key PUBKEY2, and the verification result is fed back to the DM module. After the verification is passed, the DM module has the right to access the resources on the chip under test; if the verification fails, the DM module cannot access the resources on the chip; the public key PUBKEY2 and the private key PRIKEY2 are a pair of asymmetric keys; S24. After the signature verification is passed, OpenOCD sends a debugging command to the DM module to obtain the debugging result.

[0031] The DM module is provided with an authentication data register, which is connected to the authorization management module through a serial interface. When the identity card verification information of the second identity authentication module is not received, the Authbusy status position of the authentication data register is 1. When the identity card verification information of the second identity authentication module is received, the DM module sets the authentication data register Authbusy position to 0. When Authbusy is set to 0, it communicates with the authorization management module by reading or writing the authentication data register. After receiving the identity authentication request of the DM module, the authorization management module obtains the public key PUBKEY2 from the FLASH in the chip. This public key and the private key PRIKEY2 in UKEY2 are the same asymmetric key pair. The identity authentication information written by the authorization management module to the DM module is MSG2. ” And the signature value R2, the signature is verified by the chip's built-in algorithm core ECC cryptographic algorithm. After the signature verification passes, the result is returned to the DM module, and the Authenticated bit in the DM module status register is set to 1, which means that the DM module can access all resources in the chip.

[0032] The above description is only the basic principle and preferred embodiments of the present invention. Improvements and substitutions made by those skilled in the art based on the present invention belong to the protection scope of the present invention.

Claims

1. A chip DEBUG device, comprising a remote PC, a local PC and a development board equipped with a chip to be tested, wherein GDB software runs on the remote PC, and OpenOCD runs on the local PC. OpenOCD serves as a GDB Server, and is used to receive GDB instructions and convert them into JTAG instructions and send them to the development board. The development board is provided with a DTM module, a DMI module, a DM module and a chip to be tested. The DTM module receives instructions from the local PC and sends the instructions to the DM module through the DMI module. The DM module is connected to the chip to be tested, and is characterized in that: The remote PC is provided with a first identity authentication module, the local PC is provided with a second identity card authentication module, and the development board is provided with an authorization management module. The first identity authentication module and the second identity card authentication module cooperate to realize the identity authentication of the remote PC and the local PC. After the authentication is passed, a data ciphertext channel is established between the remote PC and the local PC to realize data encryption transmission. The second identity authentication module and the authorization management module cooperate to realize the identity authentication of the local PC and the DM module on the development board. After the authentication is passed, the DM module has the right to access the resources on the chip to be tested. OpenOCD sends debugging instructions to the DM module and returns the debugging results to the local PC to realize the debugging of the chip to be tested.

2. The chip DEBUG device according to claim 1, characterized in that: The first identity authentication module implements the security authentication process of the remote PC and the local PC as follows: S11. First, configure the GDB Server and IP. This device runs OpenOCD on the local PC as the GDB Server. After OpenOCD is started, the listening port is opened and the remote PC initiates a connection request. S12, start the GDB of the remote PC and establish a connection with the local PC; S13, the remote PC generates a group of messages MSG1, and the first identity authentication module performs a hash operation on the message MSG1 to generate MSG1 ” , using the private key PRIKEY1 in the first identity authentication module to authenticate MSG1 ” Sign and generate signature value R1; S14, the remote PC sends the signature value R1 and the message MSG1 to the local PC, and the local PC uses the public key PUBKEY1 from the second identity authentication module to verify the signature. If the verification is successful, it indicates that the visitor from the GDB module is legal. If the verification fails, it indicates that the visitor from the GDB module is illegal. The public key PUBKEY1 and the private key PRIKEY1 are a pair of asymmetric keys. S15. After the local PC passes the signature verification, the second identity authentication module generates a set of random numbers as the session key SK, and encrypts SK with the public key PUBKEY1 and sends it to the remote PC. After receiving it, the remote PC decrypts SK with the private key PRIKEY1. Both parties encrypt the exchanged data with SK and establish a data ciphertext channel.

3. The chip DEBUG device according to claim 1, characterized in that: The second identity authentication module and the authorization management module implement the identity authentication process between the local PC and the DM module on the development board as follows: S21, the local PC generates a group of messages MSG2 and sends it to the second ID card authentication module, and the second ID card authentication module performs a hash operation on the message MSG2 to generate MSG2 ” , using the asymmetric private key PRIKEY2 in the second identity authentication module to authenticate MSG2 ” Sign and generate signature value R2; S22, the local PC will MSG2 ” And the signature value R2 is sent to the authorization management module on the development board; S23, the authorization management module receives MSG2 ” And the signature value R2, the data is verified by the internally stored asymmetric public key PUBKEY2, and the verification result is fed back to the DM module. After the verification is passed, the DM module has the right to access the resources on the chip under test; if the verification fails, the DM module cannot access the resources on the chip; the public key PUBKEY2 and the private key PRIKEY2 are a pair of asymmetric keys; S24. After the signature verification is passed, OpenOCD sends a debugging command to the DM module to obtain the debugging result.

4. The chip DEBUG device according to claim 3, characterized in that: The DM module is provided with an authentication data register, which is connected to the authorization management module through a serial interface. When the identity card verification information of the second identity authentication module is not received, the Authbusy status position of the authentication data register is 1. When the identity card verification information of the second identity authentication module is received, the DM module sets the Authbusy position of the authentication data register to 0. When Authbusy is set to 0, the DM module communicates with the authorization management module by reading or writing the authentication data register; After receiving the authentication request from the DM module, the authorization management module obtains the public key PUBKEY2 from the FLASH in the chip. This public key and the private key PRIKEY2 in UKEY2 are the same asymmetric key pair. The authentication information written by the authorization management module to the DM module is MSG2. ” And the signature value R2, the signature is verified by the chip's built-in algorithm core ECC cryptographic algorithm. After the signature verification passes, the result is returned to the DM module, and the Authenticated bit in the DM module status register is set to 1, which means that the DM module can access all resources in the chip.

5. The chip DEBUG device according to any one of claims 1 to 4, characterized in that: The local PC and the development board are connected through an Adapter. One end of the Adapter is connected to the USB interface of the local PC, and the other end is connected to the JTAG port in the development board. The Adapter converts the USB instructions or data of OpenOCD into instructions of the JTAG protocol specification.

6. The chip DEBUG device according to claim 2 or 3, characterized in that: Generate message MSG1 or message MSG2 by calling the security interface of OPENSSL, and call the public key PUBKEY1 for signature verification by calling the security interface of OPENSSL.

7. A chip debugging method, characterized in that: The method is provided with a first identity authentication module on the remote PC end, a second identity card authentication module on the local PC end, and an authorization management module on the development board. The first identity authentication module and the second identity card authentication module cooperate to realize the identity authentication between the remote PC and the local PC. After the authentication is passed, a data ciphertext channel is established between the remote PC and the local PC to realize data encryption transmission. The second identity authentication module and the authorization management module cooperate to realize the identity authentication between the local PC and the DM module on the development board. After the authentication is passed, the DM module has the right to access the resources on the chip to be tested. OpenOCD sends a debugging instruction to the DM module and returns the debugging result to the local PC to realize the debugging of the chip to be tested.

8. The chip debugging method according to claim 7, characterized in that: The first identity authentication module implements the security authentication process of the remote PC and the local PC as follows: S11. First, configure the GDB Server and IP. This device runs OpenOCD on the local PC as the GDB Server. After OpenOCD is started, the listening port is opened and the remote PC initiates a connection request. S12, start the GDB of the remote PC and establish a connection with the local PC; S13, the remote PC generates a group of messages MSG1, and the first identity authentication module performs a hash operation on the message MSG1 to generate MSG1 ” , using the private key PRIKEY1 in the first identity authentication module to authenticate MSG1 ” Sign and generate signature value R1; S14, the remote PC sends the signature value R1 and the message MSG1 to the local PC, and the local PC uses the public key PUBKEY1 from the second identity authentication module to verify the signature. If the verification is successful, it indicates that the visitor from the GDB module is legal. If the verification fails, it indicates that the visitor from the GDB module is illegal. The public key PUBKEY1 and the private key PRIKEY1 are a pair of asymmetric keys. S15. After the local PC passes the signature verification, the second identity authentication module generates a set of random numbers as the session key SK, and encrypts SK with the public key PUBKEY1 and sends it to the remote PC. After receiving it, the remote PC decrypts SK with the private key PRIKEY1. Both parties encrypt the exchanged data with SK and establish a data ciphertext channel.

9. The chip debugging method according to claim 7, characterized in that: The second identity authentication module and the authorization management module implement the identity authentication process between the local PC and the DM module on the development board as follows: S21, the local PC generates a group of messages MSG2 and sends it to the second ID card authentication module, and the second ID card authentication module performs a hash operation on the message MSG2 to generate MSG2 ” , using the asymmetric private key PRIKEY2 in the second identity authentication module to authenticate MSG2 ” Sign and generate signature value R2; S22, the local PC will MSG2 ” And the signature value R2 is sent to the authorization management module on the development board; S23, the authorization management module receives MSG2 ” And the signature value R2, the data is verified by the internally stored asymmetric public key PUBKEY2, and the verification result is fed back to the DM module. After the verification is passed, the DM module has the right to access the resources on the chip under test; if the verification fails, the DM module cannot access the resources on the chip; the public key PUBKEY2 and the private key PRIKEY2 are a pair of asymmetric keys; S24. After the signature verification is passed, OpenOCD sends a debugging command to the DM module to obtain the debugging result.

10. The chip debugging method according to claim 9, characterized in that: The DM module is provided with an authentication data register, which is connected to the authorization management module through a serial interface. When the identity card verification information of the second identity authentication module is not received, the Authbusy status position of the authentication data register is 1. When the identity card verification information of the second identity authentication module is received, the DM module sets the Authbusy position of the authentication data register to 0. When Authbusy is set to 0, the DM module communicates with the authorization management module by reading or writing the authentication data register; After receiving the authentication request from the DM module, the authorization management module obtains the public key PUBKEY2 from the FLASH in the chip. This public key and the private key PRIKEY2 in UKEY2 are the same asymmetric key pair. The authentication information written by the authorization management module to the DM module is MSG2. ” And the signature value R2, the signature is verified by the chip's built-in algorithm core ECC cryptographic algorithm. After the signature verification passes, the result is returned to the DM module, and the Authenticated bit in the DM module status register is set to 1, which means that the DM module can access all resources in the chip.

Images