CN111813614B

CN111813614B - Debugging processing method and device and debugging processing system

Info

Publication number: CN111813614B
Application number: CN202010916598.4A
Authority: CN
Inventors: 于永庆
Original assignee: Hubei Xinqing Technology Co ltd
Current assignee: Hubei Xinqing Technology Co ltd
Priority date: 2020-09-03
Filing date: 2020-09-03
Publication date: 2020-12-15
Anticipated expiration: 2040-09-03
Also published as: CN111813614A

Abstract

The invention provides a debugging processing method, a debugging processing device and a debugging processing system, wherein the debugging processing system comprises: a server side, an equipment side and a tool side; the tool end is used for: sending a Debug request to the server, receiving a signed Debug command sent by the server, and sending the signed Debug command to the equipment; the server is used for: receiving a Debug request sent by the tool end; verifying the debugging authority of the user identity information for the Debug command; if the debugging authority is verified to be legal, signing the Debug command to obtain a signed Debug command, and sending the signed Debug command to the tool end; the equipment end is used for: receiving a signed Debug command sent by a tool terminal; and verifying the signed Debug command by using a built-in public key, and opening a target debugging module corresponding to the Debug command according to the Debug command after the verification is passed.

Description

Debugging processing method and device and debugging processing system

Technical Field

The present invention relates to the field of chip debugging, and in particular, to a debugging processing method, device and debugging processing system.

Background

With the development of informatization in depth, the integration complexity of chips is higher and higher, and chip architectures such as SMP (symmetric multi-processing) and AMP (amplifier) are very common; the high complexity of the chip introduces more uncertainties to the system, a Debug function needs to be configured for the chip, and further, an authentication mechanism for security protection needs to be provided for the implementation of the Debug function due to the requirement of security protection.

In the prior art, a password can be pre-established in advance in a chip, and after a user inputs the password, a Debug function can be started through the authentication of the password. However, the authentication process is implemented only based on the password in the device, and is easy to crack and has poor security.

Disclosure of Invention

The invention provides a debugging processing method, a debugging processing device and a debugging processing system, which aim to solve the problems that the existing authentication mechanism of security protection is easy to crack and the security is poor.

According to a first aspect of the present invention, a debugging processing method applied to a server is provided, including:

receiving a Debug request sent by a tool end, wherein the Debug request comprises user identity information and a Debug command;

verifying the debugging authority of the user identity information for the Debug command;

if the debugging authority is verified to be legal, signing the Debug command to obtain a signed Debug command, and sending the signed Debug command to a tool end, so that the device end verifies the signed Debug command by using a built-in public key after the tool end sends the signed Debug command to the device end.

Optionally, signing the Debug command to obtain a signed Debug command includes:

and signing the Debug command by using a debugging private key stored in the HSM to obtain the signed Debug command, wherein the debugging private key is matched with a public key built in the equipment terminal.

Optionally, the user identity information includes a user name and a password;

before verifying the debugging authority of the user identity information for the Debug command, the method further includes:

and verifying that the user name is matched with the password.

According to a second aspect of the present invention, there is provided a debugging processing method applied to a device side, including:

receiving a signed Debug command sent by a tool terminal; the signed debugging command is obtained by signing the Debug command after the server side verifies that the debugging authority of the user identity information aiming at the Debug command is legal;

and verifying the signed Debug command by using a built-in public key, and opening a target debugging module corresponding to the Debug command according to the Debug command after the verification is passed.

Optionally, the hash value of the public key is fixed in the OTP of the device side.

Optionally, the debugging processing method applied to the device side further includes:

reading the current Debug state of the equipment end;

and when the current Debug state is an off and unlocked state, triggering a secure Debug function in response to the triggering operation of a triggering component of the equipment end, wherein the equipment end receives and verifies the signed Debug command only after the secure Debug function is triggered.

Optionally, after reading the current Debug state of the device side, the method further includes:

if the current Debug state is an open state, determining that the equipment end can be directly debugged;

and if the current Debug state is the closed and locked state, determining that the equipment end cannot be debugged.

According to a third aspect of the present invention, there is provided a debugging processing method applied to a tool side, including:

sending a Debug request to a server, wherein the Debug request comprises user identity information and a Debug command;

receiving a signed Debug command sent by the server; the signed debugging command is obtained by signing the Debug command after the server side verifies that the user identity information aims at the legal debugging authority of the Debug command;

and sending the signed Debug command to an equipment end, so that the equipment end verifies the signed Debug command by using a built-in public key.

Optionally, before sending the Debug request to the server, the method further includes:

acquiring the user identity information input by a user;

and generating the Debug command according to a target debugging module, wherein the target debugging module is selected from a plurality of debugging modules.

According to a fourth aspect of the present invention, there is provided a debugging processing apparatus applied to a server, including:

the system comprises a server receiving unit, a debugging unit and a debugging unit, wherein the server receiving unit is used for receiving a Debug request sent by a tool end, and the Debug request comprises user identity information and a Debug command;

the server side verification unit is used for verifying the debugging authority of the user identity information aiming at the Debug command;

and the signature and sending unit is used for signing the Debug command to obtain a signed Debug command if the debugging permission is verified to be legal, and sending the signed Debug command to the tool end, so that the device end verifies the signed Debug command by using a built-in public key after the tool end sends the signed Debug command to the device end.

According to a fifth aspect of the present invention, there is provided a debugging processing apparatus applied to a device side, including:

the equipment end receiving unit is used for receiving the signed Debug command sent by the server end; the signed debugging command is obtained by signing the Debug command after the server side verifies that the user identity information aims at the legal debugging authority of the Debug command;

and the equipment side verification unit is used for verifying the signed Debug command by using a built-in public key and opening a target debugging module corresponding to the Debug command according to the Debug command after the verification is passed.

According to a sixth aspect of the present invention, there is provided a debugging processing apparatus applied to a tool side, including:

the system comprises a first sending unit, a debugging unit and a control unit, wherein the first sending unit is used for sending a Debug request to a server side, and the Debug request comprises user identity information and a Debug command;

the tool end receiving unit is used for receiving the signed Debug command sent by the server end; the signed debugging command is obtained by signing the Debug command after the server side verifies that the user identity information aims at the legal debugging authority of the Debug command;

and the second sending unit is used for sending the signed Debug command to the equipment end so that the equipment end verifies the signed Debug command by using a built-in public key.

According to a seventh aspect of the present invention, there is provided a debugging processing system comprising: a server side, an equipment side and a tool side;

the tool end is used for:

sending a Debug request to the server, wherein the Debug request comprises user identity information and a Debug command;

receiving a signed Debug command sent by the server side, and sending the signed Debug command to the equipment side;

the server is used for:

receiving the Debug request sent by the tool end;

if the debugging authority is verified to be legal, signing the Debug command to obtain a signed Debug command, and sending the signed Debug command to the tool end;

the equipment end is used for:

receiving the signed Debug command sent by the server

According to an eighth aspect of the present invention, there is provided an electronic device, comprising a processor and a memory,

the memory is used for storing codes;

the processor is configured to execute the code in the memory to implement the methods according to the first aspect, the second aspect, the third aspect and their alternatives.

According to a ninth aspect of the present invention there is provided a storage medium having stored thereon a computer program for execution by a processor to perform the method of the first, second, third or alternative aspects.

In the debugging processing method, the debugging processing device and the debugging processing system provided by the invention, the validity of the user identity information aiming at the Debug command can be verified by using the server side, so that the validity of the debugging authority can be further ensured. In addition, the verification in the invention does not only depend on the information in the equipment terminal any more, and various user information does not need to be stored in the equipment terminal, so that the safety problem cannot be caused even if the equipment terminal is cracked, and the safety is further improved.

Compared with the scheme of partially utilizing the digital certificate to realize the authentication, the method has the advantages of simple operation, quick and concise realization process and the like.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to these drawings without creative efforts.

Fig. 1 is a first flowchart illustrating a debugging processing method applied to a server according to an embodiment of the present invention;

FIG. 2 is a flowchart illustrating a second exemplary debugging method applied to a server according to an embodiment of the present invention;

fig. 3 is a first flowchart illustrating a debugging processing method applied to a device side according to an embodiment of the present invention;

fig. 4 is a flowchart illustrating a second debugging processing method applied to the device side according to an embodiment of the present invention;

fig. 5 is a third schematic flowchart of a debugging processing method applied to the device side in an embodiment of the present invention;

FIG. 6 is a diagram illustrating a software architecture of a device side according to an embodiment of the present invention;

FIG. 7 is a first flowchart illustrating a debugging processing method applied to a tool end according to an embodiment of the present invention;

FIG. 8 is a flowchart illustrating a second exemplary debugging processing method applied to a tool end according to an embodiment of the present invention;

FIG. 9 is a diagram illustrating the configuration of a Debug command in accordance with an embodiment of the present invention;

FIG. 10 is a first schematic diagram illustrating an interaction flow of a processing system capable of implementing debugging according to an embodiment of the present invention;

FIG. 11 is a diagram illustrating an interaction flow of a processing system capable of performing debugging according to an embodiment of the present invention;

FIG. 12 is a block diagram illustrating an embodiment of a processing system capable of performing debugging;

FIG. 13 is a block diagram illustrating a second embodiment of a processing system capable of performing debugging;

FIG. 14 is a block diagram of a debugging processing device applied to a server according to an embodiment of the present invention;

fig. 15 is a schematic diagram of units of a debugging processing apparatus applied to a device in an embodiment of the present invention;

FIG. 16 is a block diagram of a debugging processing device applied to a tool end according to an embodiment of the present invention;

fig. 17 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The terms "first," "second," "third," "fourth," and the like in the description and in the claims, as well as in the drawings, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the invention described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

The technical solution of the present invention will be described in detail below with specific examples. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments.

Referring to fig. 1 and fig. 2, a debugging processing method applied to a server includes:

s101: receiving a Debug request sent by a tool terminal, wherein the Debug request comprises user identity information and a Debug command;

s102: verifying the debugging authority of the user identity information for the Debug command;

s103: whether the debugging permission is verified to be legal or not;

if the result of step S103 is yes, the following steps may be implemented:

s104: signing the Debug command to obtain a signed debugging command;

s105: sending the signed Debug command to a tool end;

through the process of step S105, after the tool end sends the signed Debug command to the device end, the device end can verify the signed Debug command by using the built-in public key.

In an example of step S102, the server may store which debugging commands for which the user identity information has legal debugging permissions (which may be understood as permission assignment information), and further directly verify whether the debugging permissions of the user identity information for the debugging commands themselves are legal based on the permission assignment information.

The server also can store user identity information and has legal debugging permission (which can be understood as permission distribution information) for which debugging modules (debugging resource groups), thereby being capable of granting debugging permission of different debugging modules in the same equipment for different users, avoiding integral authorization, having high flexibility, being suitable for equipment debugging personnel of various levels, being beneficial to fine control of the equipment debugging personnel, improving the debugging safety, for example, the higher the level of the debugging personnel is, the stronger the privacy of the debugging resource groups which can be debugged is. At this time:

in another example of step S102, the received Debug command may carry information (e.g., module identification information) related to the target Debug module, that is, the Debug command is used to instruct to Debug the target Debug resource group in the device side, and further, based on the authority allocation information, whether the Debug authority of the user identity information for the target Debug resource group is legal or not may be verified, so as to indirectly verify whether the authority of the user identity information for the Debug command is legal or not.

In another example of step S102, after determining the corresponding target Debug resource group according to the Debug command, it may be verified whether the debugging permission of the user identity information for the target Debug resource group is legal based on the permission allocation information, so as to indirectly verify whether the permission of the user identity information for the Debug command is legal.

The user identity information in step S101 may be any information capable of representing the user identity, for example, may include a user name and a password, and further, for example, may include at least one of fingerprint information, a face image, iris information, and the like, and may also include a mobile phone number, a mailbox, and the like.

In one embodiment, referring to fig. 2, if the user identity information includes a user name and a password, before step S102, the method may further include:

s106: and verifying that the user name is matched with the password.

For example, a preset matching relationship between the user name and the password may be stored in the server, and further, it may be verified whether the user name and the password therein are the same as the preset matching relationship stored in the server with respect to the user identity information.

In the above scheme, the user identity is verified, and in other schemes, the user identity can be verified by whether the fingerprint information, the face image, the iris information, the mobile phone number, the mailbox and the like are matched.

In the scheme, the user identity verification (which can also be understood as the verification of the access authority) can be realized, and further, the verification of the access authority, the verification of the debugging authority and the verification of the signature can realize triple verification, thereby effectively ensuring the validity and the safety of debugging.

Since the embodiment of the invention mainly aims to explain the process of safety debugging (namely safety Debug) based on the server side, the equipment side and the tool side, the debugging permission can be understood as the safety debugging permission. In the actual application process, the tool side may not implement debugging based on the server side, for example: direct commissioning, which can be distinguished from secure commissioning understanding, can be achieved based on communication between the tool side and the device side.

In order to verify the access authority, the server may be configured to maintain the access authority of each registered user (e.g., the above-mentioned preset matching relationship that may store the user name and the password), and further, may ensure that each user has an individual security debugging authority.

In one embodiment, referring to fig. 2, step S104 may include:

s1041: and signing the Debug command by using a debugging private key stored in the HSM to obtain the signed Debug command, wherein the debugging private key is matched with a public key built in the equipment terminal.

The HSM, specifically a Hardware Security Module, may be understood as a Hardware Security Module, and further, the debug private key stored in the HSM may not be derivable, and further, only can be accessed through a private instruction.

In steps S102, S103, and S106, the server confirms the request from the tool (specifically, the secure Debug management tool therein), and further, may generate a signature command through the HSM, and send a response (for example, a signed Debug command) to the tool (specifically, the secure Debug management tool therein).

Referring to fig. 3 to fig. 6, the debugging processing method applied to the device side includes:

s201: receiving a signed Debug command sent by a server through a tool end;

the signed debugging command is obtained by signing the Debug command after the server side verifies that the user identity information is legal for the debugging authority of the Debug command, and the description of the steps S102 to S104 can be correspondingly referred to;

s202: and verifying the signed Debug command by using a built-in public key, and opening a target debugging module corresponding to the Debug command according to the Debug command after the verification is passed.

The above technical features, technical terms and technical effects can be understood by referring to the method embodiments mentioned above, and repeated details are not repeated.

In one embodiment, the hash value of the public key may be fixed in the OTP at the device side. The OTP, specifically One Time Programmable, can be understood to characterize a One Time Programmable memory device.

The device side can be configured with various Debug states, which can include the following basic states:

an Open state (i.e., Open state), a closed state (i.e., Close state), a locked state (i.e., Lock state), and an unlocked state (i.e., Unlock state).

The above characteristics of the basic states can be understood as:

if the device side is in a locked state (namely, a Lock state), the secure Debug function can never be started;

the Open state (i.e., Open state) may transition to the closed state (i.e., Close state);

the Open state (i.e., Open state) may be converted to the locked state (i.e., Lock state);

the closed state (i.e., Close state) may transition to the locked state (i.e., Lock state).

Further, the device-side configurable Debug state may also include a combination state formed based on the above basic state combination, for example:

a state in which an unlocked state (i.e., Unlock state) coexists with an Open state (i.e., Open state), which may be characterized as an Open and unlocked state;

the unlocked state (i.e., Unlock state) is a state that coexists with the closed state (i.e., Close state), which may be characterized as the closed and unlocked state.

For ease of understanding, the following table shows four basic states and their corresponding english representations of the description information:

Status	Description
		Open	Debug function normal
Close	Debug function close; if in un-lock state, the debug function can be open again by authenticating debug certificate
		Lock	If in lock state, the debug function is never open.
UnLock	If in close state, debug function can be open again by authenticating debug certificate

in addition, the characteristics and contents of the Debug status can be referred to above and are not limited to the above examples.

In one embodiment, before the authentication of the Debug is started (for example, before the secure Debug function of the device is triggered, it may also be understood that the trigger component referred to later is triggered), the current Debug state of the device may be read and determined.

Specifically, referring to fig. 4, the method for debugging and processing applied to the device side may further include:

s203: reading the current Debug state of the equipment end;

s204: whether the current Debug state is a closed and unlocked state;

if the result of step S204 is yes, step S205 may be implemented: and triggering a safety Debug function in response to the triggering operation of the triggering component of the equipment terminal.

The secure Debug function can be understood as: and the equipment end can receive and verify the signed Debug command only after the security Debug function is triggered. In a further aspect, it is also understood that: only after the secure Debug function is triggered, the tool end is triggered (for example, triggered by a response returned after the device end performs step S205) to generate an interactive interface, so that the tool end can implement the processing of steps S304 and S305, etc., which are referred to later, based on the interactive interface.

The triggering component may be, for example, a key shown in fig. 12, which may be a physical key or a virtual key, and in other examples, the triggering component may also be a knob, a sliding key, and the like without being limited to a key.

In the case where steps S201 and S202 need to be performed, steps S203 to S205 referred to above may be performed before step S201.

In one embodiment, referring to fig. 5, after step S203, the method may further include:

s207: whether the current Debug state is an open state;

if the result of step S207 is yes, step S208 may be implemented: and determining that the equipment end can be directly debugged by the tool end.

At this time, it can be understood that a process of direct debugging may be implemented, and further, the tool side may directly perform debugging on the device side (for example, directly send a corresponding debugging command to implement debugging), without implementing a process of secure debugging.

If the result of step S207 is no, the method may further include:

s209: whether the current Debug state is a closed and locked state;

if the result of step S209 is yes, step S210 may be implemented: determining that the equipment end cannot be debugged;

if the result of the step S209 is negative, the steps S204 and S205 may be implemented, so as to implement the process of security debugging, i.e. open the Debug function through the authentication mechanism.

In the specific implementation process, after the device side establishes communication with the tool side (specifically, the secure Debug management tool therein), the device side can send a request and receive a response; the Debug flag or status register is then read and detected to see if the secure Debug function (which may correspond to the relevant contents of steps S203 to S209) is triggered. Meanwhile, the device side can also read device data, such as a chip identifier (e.g., chip ID) and a core identifier (e.g., core ID) of the device side.

The security Debug management tool can be understood by referring to fig. 13.

In a specific implementation process, at any time before step S201, the public key to be used may be compared with a digest (HASH) value of the public key solidified in the OTP, so as to verify the validity of the secure Debug public key.

In addition, in order to further improve the security, a disposable random number can be randomly generated and used for preventing the server side from being attacked again. For example, the generated random number may be uploaded to the server via the tool, the server may perform signature based on the private key and the random number when performing the signature of step S104, and correspondingly, the device may perform verification based on the random number and the public key when performing the verification of step S202.

Referring to fig. 6, the software architecture of the device is divided into four layers, which are from bottom to top: hardware layer, driver layer, HAL layer and application layer.

Wherein the HAL is specifically Hardware interaction Layer, and the HAL Layer can be understood as a Hardware Abstraction Layer.

The hardware layer may include, for example, a Cortex-M0 core, a JTAG (Joint Test Action Group) communication protocol module, a cryptographic engine, and an OTP, the driver layer may include, for example, a UART (Universal Asynchronous Receiver/Transmitter) driver and a cryptographic engine driver, and the HAL layer may include, for example, a UART library and a cryptographic library that can be called.

The JTAG communication protocol module can also be characterized as JTAG wire protocol;

the encryption Engine can also be characterized as a Crypto Engine; correspondingly, the encryption Engine Driver can also be characterized as a Crypto Engine Driver; the encryption vault may also be characterized as Crypto Lib;

the UART Driver can also be characterized as UART Driver; correspondingly, the UART library may also be characterized as UART Lib.

The architecture is based on a Coretex-M0 and a FreeRTOS system, and can perform Debug control and command downloading functions through a UART channel; identity authentication function is provided through Cryptodriver and Cryptolib based on CryptoEngine. The OTP solidifies the secure Debug public key HASH value and the current Debug status of the chip.

Referring to fig. 7 to 9, the debugging processing method applied to the tool end includes:

s301: sending a Debug request to a server, wherein the Debug request comprises user identity information and a Debug command;

s302: receiving a signed Debug command sent by the server; the signed debugging command is obtained by signing the Debug command after the server side verifies that the user identity information aims at the legal debugging authority of the Debug command;

s303: sending the signed Debug command to a device side, and further enabling: the device side can verify the signed Debug command by using a built-in public key.

In one embodiment, before step S301, the method may further include:

s304: acquiring the user identity information input by a user;

s305: providing a plurality of debugging resource groups in the equipment end for a user, and acquiring a target debugging resource group determined by the user from the plurality of debugging resource groups; and generating a debugging command according to the target debugging resource group.

For step S304, an interactive interface may be provided at the tool end, for example, and the user inputs user identity information (also understood as user credentials), and step S304 may be generated in response to a signal returned to the tool end after step S205 is implemented.

For step S305, the tool end may determine all debug resource groups in the device by obtaining the chip identifier of the device, and display a selection interface for the user to select, where the selection interface includes the debug resource groups. Then, when the user selects the target debugging resource group to be debugged from the debugging resource groups, the tool end can assemble the target debugging resource group into a debugging command. By the method, a professional debugger is not required to compile the debugging command, and a common person can directly implement the compiling of the debugging command through simple selection operation of the selection interface on the test tool, so that the debugging personnel threshold is favorably reduced, and the debugging cost is reduced.

Before step S304, initiating communication may be further included, so as to establish communication between the tool side and the device side (for example, the secure Debug proxy module therein), and after establishing communication, a secure Debug initiation request may be sent to the device side (for example, the secure Debug proxy module therein), and a response may be received from the device side (for example, the secure Debug proxy module therein), so as to establish communication between the secure Debug management tool and the secure Debug proxy module.

The secure Debug agent module, the secure Debug management tool, and the like can be understood with reference to fig. 13.

In the interactive interface, a debugging list can be displayed externally, wherein each available debugging module can be configured, and through human-computer interaction, a target debugging module (which can also be understood as a target Debug resource group) can be selected and a 32-bit debugging command (i.e. a Debug command) is generated.

In the specific implementation process, different Debug resource groups are defined by the chip at the device end according to different application scenarios and operation roles, wherein the different Debug resource groups can also be understood as different debugging modules. The chip provides different Debug resource groups by defining different Debug commands. The following table defines different Debug Resource groups (Debug Resource items):

Debug Resource Item	definition of
		AP (A processor) secure passive debug Invasive A nuclear debugging)	Debugging A core in a secure environment mode in an intrusive mode, e.g. in TrustZone Cortex A76 on-processor application
AP(A Processor) secure non-invasive debug (secure non-intrusive A core debug)	Debugging core A in a non-intrusive mode in a safe environment mode, for example, in a TrustZone environment, without interrupting Cortex Application program on A76 processor, monitoring its performance through debugging port
		AP(A Processor) non-secure invasive debug (non-safety-invasive A Nuclear debug)	Debugging the core A in an invasive mode in a non-secure environment mode, for example, in a linux or Android environment JTAG debug application on Cortex A76 processor
AP(A Processor) non-secure non-invasive debug (non-safety non-invasive A nuclear debug)	Debugging A core in a non-invasive mode in a non-secure environment mode, such as Linux or Android environment without hitting Breaking an application on a Cortex A76 processor and monitoring its performance through a debug port
		CP (C processor) secure passive debug Intrusive C core debug)	Debugging the C core in a secure environment mode in an intrusive mode, for example, in a TrustZone environment, debugging by JTAG Cortex A55 on-processor application
CP(C Processor) secure non-invasive debug (secure non-intrusive C core debug)	Debugging core A in a non-intrusive mode in a safe environment mode, for example, in a TrustZone environment, without interrupting Cortex Application program on A55 processor, monitoring its performance through debugging port
		CP(C Processor) non-secure invasive debug (non-safety intrusive C nuclear debugging)	Debugging A-core in an intrusive mode in an unsecure environment mode, e.g. debugging Cortex in an AGL environment using JTAG Application program on A55 processor
CP(C Processor) non-secure non-invasive debug (non-safety non-invasive C core debug)	Debugging A core in a non-invasive mode in a non-secure environment mode, for example, in an AGL environment, without interrupting Cortex A55 Application program on processor, monitoring its performance through debugging port
		RP (R processor) innovative debug (intrusive R core) Debugging)	Debugging an R-core in an intrusive mode, e.g. debugging an application on a Cortex R52 processor using JTAG
RP (R processor) non-invasive debug (non-invasive) Debugging of formula R nucleus	Debugging the R-core in a non-intrusive manner, such as debugging an application on a Cortex R52 processor in an uninterrupted manner, monitoring its performance through ports
		MP (M processor) debug enable/disable (M core debug) Test enable/disable)	Debug switch for turning on/off M-core processor
DSP debug enable/disable (DSP debug enable/disable)	Turning on or off a debug switch of a Digital Signal Processor (DSP)
		NPU 0 debug enable/disable (neural network processor 0) Enable/disable)	Debug switch for turning on or off NPU (Neural network Processor) 0
NPU 1 debug enable/disable (neural network processor 1) Enable/disable)	Debug switch for turning on or off NPU 1
		EV6X debug enable/disable (EV 6X processor enable @ Failure)	Debug switch to turn on or off EV6X processor

The secure Environment mode is to provide a secure and reliable execution Environment for a program with a higher user security level, such as a TEE (trusted execution Environment), by using hardware isolation and software control measures, where a payment program, an encryption and decryption operation program, and the like, all need to be run in the secure Environment mode. The non-secure environment mode refers to a common environment without security protection, for example, common applications, such as games, which do not relate to sensitive data in the Linux system or the Android system, are all run in the non-secure environment mode.

The definition of the above resource group can be understood as being formed based on the architecture shown in fig. 13.

In a specific example, the Debug command may be bitmap data, where the bitmap data defines a set of Debug resources divided in the chip. Each Debug resource group has a unique bit number. In the tool side (specifically, the secure Debug management tool therein), all selectable Debug resource groups (i.e., Debug modules) are recorded and assembled into a 32-bit integer Debug command.

The maximum Debug resource number supported by the system may be, for example, 31. in the server (which may also be understood as a secure Debug background management server, for example), each Debug resource group has independent rights to each user. Each user has an independent username and password for logging into the server. The server compares whether the debugging command received from the Debug management tool is matched with the authority distributed to the user by the debugging module so as to determine whether to grant the request of the safe debugging (namely whether to sign and return the signed debugging command).

Based on the command configuration diagram shown in fig. 9, if a security intrusive Debug function (i.e., an a core secure inbound Debug) needs to be opened for an a core (i.e., the core-a core shown in fig. 13), only the following Debug command needs to be sent:

0x00000001。

in summary, in the debugging processing method provided in the embodiment of the present invention, the server may be used to verify the validity of the user identity information for the Debug command, so as to ensure the validity of the current debugging permission, and meanwhile, the public key built in the device side is used to verify the signed Debug command returned by the server, and through two times of verification, the security and validity of the current debugging may be effectively ensured. In addition, the verification in the embodiment of the invention does not only depend on the information in the equipment terminal any more, and various user information does not need to be stored in the equipment terminal, so that the safety problem cannot be caused even if the equipment terminal is cracked, and the safety is further improved. Compared with the scheme of partially utilizing the digital certificate to realize the authentication, the embodiment of the invention also has the positive effects of simple operation, quick and simple realization process and the like.

Referring to fig. 10 to fig. 13, an embodiment of the present invention further provides a debugging processing system capable of implementing debugging, including: a server 403, a device 401, and a tool 402.

The tool end 402 is configured to implement the process of the debugging processing method applied to the tool end according to the above alternative, the server end 403 is configured to implement the process of the debugging processing method applied to the tool end according to the above alternative, and the device end 401 is configured to implement the process of the debugging processing method applied to the device end according to the above alternative.

Referring to fig. 10, the server 403 may perform the processing steps S101 to S105, the device 401 may perform the processing steps S201 and S202, and the tool 402 may perform the processing steps S301 to S303.

In a further alternative, the server 403 may further implement the processing procedure of step S106, the tool 402 may further implement the processing procedures of steps S304 and S305, and the device may further implement the processing procedures of steps S203 to S205.

In addition to the contents shown in fig. 10 and 11, the technical features, technical effects, and the like of the debugging processing system can be understood with reference to the embodiments shown in fig. 1 to 9, and the repetitive contents will not be described again.

Referring to fig. 13, the device 401 may include an embedded system, a system host, a secure Debug agent module, and an OTP. The Security embedded system may be a Security Enclave embedded system, and may include a Cortex-M0 core, an encryption engine, an SRAM, and a DCU, for example; the System Host can be characterized as a Host System, and can specifically include a Cortex-A core, a Cortex-R core, a Cortex-M core, a DSP and a memory module.

The encryption engine therein may be understood with reference to the foregoing description, i.e., may be characterized as: crypto Engine.

The SRAM is particularly Static Random-Access Memory, which can be understood as Static Random Access Memory;

the storage module may be specifically System Memories and Resources.

It can be seen that the processing system capable of implementing debugging provides an authentication architecture for secure Debug, which includes three parts in total: a Debug background management server (namely a server), a security Debug management tool in a tool end and a security Debug agent module. The Debug background management server is responsible for user management, authorization management of Debug resources and command signature management. The security Debug management tool is responsible for establishing a trusted channel between the security Debug agent module and the Debug background management server; the safe Debug management tool establishes a safe trusted channel between the SSL network security protocol and the Debug background management server, and establishes a trusted channel between the UART transmission protocol and the safe Debug agent module. And the safety Debug agent module is responsible for verifying the legality of the signature command and the legality of the public key, and opening Debug resources of corresponding levels according to the command content of the Debug.

The security Debug Agent module can also be characterized as a security Debug Agent; the security Debug management tool can also be characterized as a security Debug tool.

In a specific example, an implementation process of the debugging processing system that can be implemented will be described below with reference to fig. 12 and fig. 10 and 11, which can be understood as a subsequent process in the case where the determination in step S204 is yes:

corresponding to (1) in fig. 12, and step S205, the user may trigger the secure Debug function by pressing a key (i.e., button) on the device;

corresponding to (2) in fig. 12, the user may start the secure Debug management tool, and query the device data and Debug status from the secure Debug proxy module;

corresponding to (3) in fig. 12, and step S304, the user may input a user name and a password in the secure Debug management tool;

corresponding to (4) in fig. 12, the user selects a target Debug module from the module list that can be obtained, and a Debug command can be generated correspondingly;

corresponding to (5) in fig. 12, and step S301, the secure Debug management tool sends a Debug request (including a user name/password and a Debug command of the selected target Debug module) to the secure Debug backend management server (i.e., server)

Corresponding to (6) in fig. 12, and steps S102, S103 and S104, the secure Debug backend management server verifies the user name and password, detects the legitimacy of the authority of the selected target Debug module, and then signs the Debug request (e.g., the Debug command therein) through the HSM;

corresponding to (7) in fig. 12, and steps S201 and S303, the secure Debug management tool sends the signed Debug request to the secure Debug proxy module;

corresponding to (8) in fig. 12, and step S202, the secure Debug agent module verifies the validity of the signature;

corresponding to (9) in fig. 12, the secure Debug proxy module calls an implementation function of the user to perform an operation of reopening the Debug function.

Referring to fig. 14, an embodiment of the present invention provides a debugging processing apparatus 500 applied to a server, including:

a server receiving unit 501, configured to receive a Debug request sent by a tool, where the Debug request includes user identity information and a Debug command;

a server verification unit 502, configured to verify a debugging permission of the user identity information for the Debug command;

a signature and sending unit 503, configured to sign the Debug command to obtain a signed Debug command if the Debug right is verified to be legal, and send the signed Debug command to a tool end, so that after the tool end sends the signed Debug command to an equipment end, the equipment end can verify the signed Debug command by using a built-in public key.

Optionally, the signature sending unit 503 is specifically configured to:

Optionally, the user identity information includes a user name and a password;

the debugging processing device 500 applied to the server further includes: and the user name and password verification unit is used for verifying that the user name is matched with the password.

Referring to fig. 15, an embodiment of the present invention provides a debugging processing apparatus applied to a device side, including:

the device side receiving unit 601 is configured to receive a signed Debug command sent by a server side (via a tool side); the signed debugging command is obtained by signing the Debug command after the server side verifies that the user identity information aims at the legal debugging authority of the Debug command;

and the device side verification unit 602 is configured to verify the signed Debug command by using a built-in public key, and open a target Debug module corresponding to the Debug command according to the Debug command after the verification is passed.

The HASH value of the public key is fixed in the OTP of the device side.

Optionally, the debugging processing apparatus 600 applied to the device side further includes:

the state reading unit is used for reading the current Debug state of the equipment end;

and the triggering unit is used for responding to the triggering operation of the triggering component of the equipment end when the current Debug state is the closed and unlocked state, and triggering the safety Debug function, wherein the equipment end can receive and verify the signed Debug command only after the safety Debug function is triggered.

a direct debugging determination unit, configured to determine that the device end can be directly debugged by the tool end if the current Debug state is an open state;

and the non-debuggable determining unit is used for determining that the equipment end cannot be debugged if the current Debug state is the closed and locked state.

Referring to fig. 16, an embodiment of the invention provides a debugging processing apparatus 700 applied to a tool end, including:

a first sending unit 701, configured to send a Debug request to a server, where the Debug request includes user identity information and a Debug command;

a tool side receiving unit 702, configured to receive a signed Debug command sent by the server side; the signed debugging command is obtained by signing the Debug command after the server side verifies that the user identity information aims at the legal debugging authority of the Debug command;

a second sending unit 703, configured to send the signed Debug command to a device side, so that: the device side can verify the signed Debug command by using a built-in public key.

Optionally, the debugging processing apparatus 700 further includes:

the user identity acquisition module is used for acquiring the user identity information input by the user;

and the command generation module is used for generating the Debug command according to a target debugging module, and the target debugging module is selected from a plurality of debugging modules.

In summary, in the debugging processing apparatus provided in the embodiment of the present invention, the server may be used to verify the validity of the user identity information for the Debug command, so as to ensure the validity of the current debugging permission, and meanwhile, the public key built in the device side is used to verify the signed Debug command returned by the server, and through two times of verification, the security and validity of the current debugging may be effectively ensured. In addition, the verification in the embodiment of the invention does not only depend on the information in the equipment terminal any more, and various user information does not need to be stored in the equipment terminal, so that the safety problem cannot be caused even if the equipment terminal is cracked, and the safety is further improved. Compared with the scheme of partially utilizing the digital certificate to realize the authentication, the embodiment of the invention also has the positive effects of simple operation, quick and simple realization process and the like.

Fig. 17 is a schematic structural diagram of an electronic device in an embodiment of the invention.

Referring to fig. 17, an electronic device 80 is provided, which includes:

a processor 81; and the number of the first and second groups,

a memory 82 for storing executable instructions of the processor;

wherein the processor 81 is configured to perform the above-mentioned method via execution of the executable instructions.

The processor 81 can communicate with the memory 82 via a bus 83.

Embodiments of the present invention also provide a computer-readable storage medium, on which a computer program is stored, which when executed by a processor implements the above-mentioned method.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solution of the present invention, and not to limit the same; while the invention has been described in detail and with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A debugging processing method applied to a server side is characterized by comprising the following steps:

receiving a debugging request sent by a tool end, wherein the debugging request comprises user identity information and a debugging command, the debugging command is used for indicating a target debugging resource group in an equipment end to be debugged, the target debugging resource group is selected from a plurality of debugging resource groups in the equipment end, and the user identity information is used for representing user identity;

verifying the debugging authority of the user identity information aiming at the target debugging resource group in the debugging command;

if the debugging authority is verified to be legal, signing the debugging command to obtain a signed debugging command, and sending the signed debugging command to a tool end, so that after the tool end sends the signed debugging command to the equipment end, the equipment end verifies the signed debugging command by using a public key of an OTP (one time programmable) in the equipment end, and the OTP is a one-time programmable memory device.

2. The debugging processing method applied to the server according to claim 1, wherein signing the debugging command to obtain a signed debugging command comprises:

and signing the debugging command by using a debugging private key stored in the HSM hardware security module to obtain the signed debugging command.

3. The debugging processing method applied to the server according to claim 1 or 2, wherein the user identity information comprises a user name and a password;

before verifying the debugging authority of the user identity information for the debugging command, the method further comprises the following steps:

and verifying that the user name is matched with the password.

4. A debugging processing method applied to a device side is characterized by comprising the following steps:

receiving a signed debugging command sent by a tool end, wherein the debugging command is used for indicating a target debugging resource group in an equipment end to be debugged, the target debugging resource group is selected from a plurality of debugging resource groups in the equipment end, the signed debugging command is obtained by signing the debugging command after a service end verifies that user identity information aims at that the debugging authority of the target debugging resource group in the debugging command is legal, and the user identity information is used for representing user identity;

verifying the signed debugging command by using a public key of the OTP arranged in the equipment end, and opening the target debugging resource group according to the debugging command after the verification is passed.

5. The debugging processing method applied to the device end according to claim 4, wherein the hash value of the public key is fixed in the OTP.

6. The debugging processing method applied to the equipment side according to claim 4 or 5, further comprising:

reading the current debugging state of the equipment end;

and if the current debugging state is a closed and unlocked state, triggering a safety debugging function in response to the triggering control of a triggering part of the equipment end, wherein the equipment end receives and verifies the signed debugging command only after the safety debugging function is triggered.

7. The debugging processing method applied to the device side according to claim 6, further comprising, after reading the current debugging state of the device side:

if the current debugging state is an open state, determining that the equipment end can be directly debugged;

and if the current debugging state is a closed and locked state, determining that the equipment end cannot be debugged.

8. A debugging processing method applied to a tool end is characterized by comprising the following steps:

sending a debugging request to a server, wherein the debugging request comprises user identity information and a debugging command, the debugging command is used for indicating a target debugging resource group in an equipment end to be debugged, the target debugging resource group is selected from a plurality of debugging resource groups in the equipment end, and the user identity information is used for representing user identity;

receiving a signed debugging command sent by the server, wherein the signed debugging command is obtained by signing the debugging command after the server verifies that the debugging authority of user identity information aiming at the target debugging resource group in the debugging command is legal;

and sending the signed debugging command to the equipment end so that the equipment end verifies the signed debugging command by using a public key of an OTP (one time programmable) arranged in the equipment end, wherein the OTP is a one-time programmable memory device.

9. The debugging processing method of the tool end according to claim 8, before sending the debugging request to the server end, further comprising:

acquiring the user identity information input by a user;

providing a plurality of debugging resource groups in the equipment end for a user, and acquiring a target debugging resource group determined by the user from the plurality of debugging resource groups; and generating a debugging command according to the target debugging resource group.

10. A debugging processing device applied to a server side is characterized by comprising:

the system comprises a server receiving unit, a debugging unit and a debugging unit, wherein the server receiving unit is used for receiving a debugging request sent by a tool end, the debugging request comprises user identity information and a debugging command, the debugging command is used for indicating a target debugging resource group in an equipment end to be debugged, the target debugging resource group is selected from a plurality of debugging resource groups in the equipment end, and the user identity information is used for representing the identity of a user;

the server side verification unit is used for verifying the debugging authority of the user identity information aiming at the debugging command;

and the signature and sending unit is used for signing the debugging command to obtain a signed debugging command and sending the signed debugging command to the tool end if the debugging authority is verified to be legal, so that after the tool end sends the signed debugging command to the equipment end, the equipment end verifies the signed debugging command by using a public key of the OTP arranged in the equipment end, and the OTP is a one-time programmable memory device.

11. A debugging processing device applied to an equipment side is characterized by comprising:

the device end receiving unit is used for receiving a signed debugging command sent by a tool end, wherein the debugging command is used for indicating a target debugging resource group in the device end to be debugged, and the target debugging resource group is selected from a plurality of debugging resource groups in the device end; the signed debugging command is obtained by signing the debugging command after a server side verifies that the debugging authority of user identity information aiming at the target debugging resource group in the debugging command is legal, wherein the user identity information is used for representing the identity of a user;

and the equipment end verification unit is used for verifying the signed debugging command by using a public key of the OTP arranged in the equipment end, and opening the target debugging resource group according to the debugging command after the verification is passed, wherein the OTP is a one-time programmable memory device.

12. A debugging processing device applied to a tool end is characterized by comprising:

the debugging device comprises a first sending unit, a second sending unit and a third sending unit, wherein the first sending unit is used for sending a debugging request to a server, the debugging request comprises user identity information and a debugging command, the debugging command is used for indicating a target debugging resource group in a device end to be debugged, the target debugging resource group is selected from a plurality of debugging resource groups in the device end, and the user identity information is used for representing user identity;

the tool end receiving unit is used for receiving the signed debugging command sent by the server end; the signed debugging command is obtained by signing the debugging command after the server side verifies that the debugging authority of the user identity information aiming at the target debugging resource group in the debugging command is legal;

and the second sending unit is used for sending the signed debugging command to the equipment end so that the equipment end verifies the signed debugging command by using a public key of an OTP (one time programmable) in the equipment end, wherein the OTP is a one-time programmable memory device.

13. A debugging processing system, comprising: a server side, an equipment side and a tool side;

the tool end is used for:

sending a debugging request to the server, wherein the debugging request comprises user identity information and a debugging command, the debugging command is used for indicating a target debugging resource group in the equipment end to be debugged, the target debugging resource group is selected from a plurality of debugging resource groups in the equipment end, and the user identity information is used for representing the user identity;

receiving a signed debugging command sent by the server side, and sending the signed debugging command to the equipment side;

the server is used for:

receiving the debugging request sent by the tool terminal;

if the debugging authority is verified to be legal, signing the debugging command to obtain a signed debugging command, and sending the signed debugging command to the tool end;

the equipment end is used for:

receiving the signed debugging command sent by the tool terminal;

verifying the signed debugging command by using a public key of the OTP arranged in the equipment end, and opening the target debugging resource group according to the debugging command after the verification is passed, wherein the OTP is a one-time programmable memory device.

14. An electronic device, comprising a processor and a memory,

the memory is used for storing codes;

the processor configured to execute the code in the memory to implement the method of any one of claims 1 to 9.

15. A storage medium having stored thereon a computer program for execution by a processor to perform the method of any of claims 1 to 9.