JP2022107344A - Device, debugging instrument, secure component, debugging system, and debugging method - Google Patents

Abstract

To provide a device, debugging instrument, secure component, debugging system and debugging method, which minimize the chances of a third party maliciously using debugging functions.SOLUTION: A device provided herein has a debugging target and comprises a device-side secure component with an authentication unit configured to perform mutual authentication with an instrument-side secure component of a debugging instrument for debugging the debugging target. Upon successful mutual authentication by the authentication unit, the device-side secure component exchanges debugging signals with the instrument-side secure component.SELECTED DRAWING: Figure 1

Description

The present invention relates to devices, debugging equipment, secure components, debugging systems and debugging methods.

In recent years, remote debugging has become the mainstream of debugging in embedded device development. In remote debugging, for example, a dedicated circuit for a debugging function is mounted inside a device to be debugged, and debug signals are exchanged with an external development PC via a debug probe.

Further, in Patent Document 1, an embedded device is incorporated and a target machine on which a process to be debugged is started and a host machine used by a developer for debugging operations are connected via a communication line such as a network or a serial cable. A debug support device that is connected and realizes remote debugging is disclosed.

Japanese Unexamined Patent Publication No. 2012-79130

In remote debugging of embedded devices, it is still possible to send and receive plaintext debug signals from an unspecified number of development PCs. Therefore, a debug signal can be easily sent to the embedded device from a third party, and there is a risk that the software in the embedded device may be illegally read or tampered with by analysis as well as unauthorized remote control of the embedded device. ..

In addition, embedded devices have a built-in debug function, so unless the debug function is disabled or the debug PIN is physically or logically crushed, the device will be exposed to attacks that abuse the debug function even after shipment. there is a possibility. On the other hand, embedded devices generally lack a UI (user interface), so the debug function is highly useful for operation verification and failure analysis, but the debug function is not sufficiently disabled. , It is often a security vulnerability.

The present invention has been made in view of such circumstances, and provides a device, a debugging device, a secure component, a debugging system, and a debugging method capable of minimizing the possibility of misuse of the debugging function by a third party. The purpose is.

The device according to the embodiment of the present invention is a device having a debug target, and is a device-side secure having an authentication unit that performs mutual authentication with a device-side secure component provided in the debug device for debugging the debug target. The device-side secure component includes a component, and when mutual authentication is successful in the authentication unit, the device-side secure component sends and receives a debug signal to and from the device-side secure component.

The debug device according to the embodiment of the present invention is a debug device for debugging a debug target, and is a device side having an authentication unit that performs mutual authentication with a device-side secure component provided in the device having the debug target. The device-side secure component includes a secure component, and when the mutual authentication is successful in the authentication unit, the device-side secure component sends and receives a debug signal to and from the device-side secure component.

The secure component according to the embodiment of the present invention is a secure component mounted on a device having a debug target, and mutually authenticates with the secure component on the device side provided in the debug device for debugging the debug target. It is provided with an authentication unit to perform, and when mutual authentication is successful in the authentication unit, a debug signal is exchanged with the secure component on the device side.

The secure component according to the embodiment of the present invention is a secure component mounted on a debugging device for debugging a debug target, and mutually authenticates with the device-side secure component provided in the device having the debug target. It is provided with an authentication unit to perform, and when mutual authentication is successful in the authentication unit, a debug signal is exchanged with the secure component on the device side.

The debug system according to the embodiment of the present invention is a debug system including a device having a debug target and a debug device for debugging the debug target, and the device is a device side provided in the debug device. The debug device is provided with a device-side secure component having a device-side authentication unit that performs mutual authentication with the secure component, and the debug device is a device-side secure component having a device-side authentication unit that performs mutual authentication with the device-side secure component provided in the device. When mutual authentication is successful in each of the device-side authentication unit and the device-side authentication unit, a debug signal is exchanged between the device-side secure component and the device-side secure component.

In the debugging method according to the embodiment of the present invention, the device-side secure component mounted on the device having the debug target performs mutual authentication with the device-side secure component mounted on the debug device for debugging the debug target. The device-side secure component performs mutual authentication with the device-side secure component, and if each of the mutual authentications is successful, a debug signal is exchanged between the device-side secure component and the device-side secure component.

According to the present invention, the possibility of misuse of the debugging function by a third party can be minimized.

It is a schematic diagram which shows an example of the structure of the debug system of 1st Embodiment. It is a schematic diagram which shows an example of the process flow of a debug start instruction. It is a schematic diagram which shows an example of the processing flow of the cryptographic communication path establishment between a secure component and a CPU / SoC to be debugged. It is a schematic diagram which shows an example of the processing flow of mutual authentication between secure components. It is a schematic diagram which shows an example of the processing flow of the plaintext communication between a probe and a device. It is a schematic diagram which shows an example of the processing flow of the encrypted communication between a probe and a device. It is a schematic diagram which shows an example of the process flow of user authentication of a probe. It is a schematic diagram which shows an example of the process flow of user authentication of a device. It is a schematic diagram which shows an example of the processing flow of the debug function operation on the probe side via a secret communication path. It is a schematic diagram which shows an example of the processing flow of the debug function operation on the device side via a secret communication path. It is a schematic diagram which shows an example of the structure of the debug system of 2nd Embodiment. It is a schematic diagram which shows an example of the structure of the debug system of 3rd Embodiment. It is a schematic diagram which shows an example of the processing flow of the encrypted communication between a probe and a device in the case of 3rd Embodiment. It is a schematic diagram which shows an example of the processing flow of mutual authentication between secure components in the case of 4th Embodiment. It is a schematic diagram which shows an example of the processing flow of the encrypted communication between the probe of 4th Embodiment and the CPU / SoC to be debugged.

(First Embodiment)
Hereinafter, the present invention will be described with reference to the drawings showing the embodiments thereof. FIG. 1 is a schematic diagram showing an example of the configuration of the debug system of the first embodiment. The debug system includes a device 50 having a debug target and a probe 30 as a debug device. The debug system may further include an embedded development PC 20 and a debug environment management server 10.

The device 50 is a device that is a target of embedded development. The device 50 includes a CPU / SoC60 to be debugged, a debug I / F51, and a secure component 70. The debug I / F 51 is an interface for contacting the probe 30, and for example, an interface such as JTAG (Joint Test Action Group) / SWD (Serial Wire Debug) can be used.

The debug target CPU / SoC 60 is a CPU or SoC (System on chip) that runs a debug target program 61 (also referred to as a “debug target”) on the device 50. The debug target program 61 is a program running on the debug target CPU / SoC60. The debug target CPU / SoC 60 includes a debug function 62 in the CPU / SoC in addition to the above-mentioned debug target program 61.

The debug function 62 in the CPU / SoC is a debugger implemented inside the debug target CPU / SoC, and controls operations such as acquiring the state of the debug target program 61 and stopping at a breakpoint. The CPU / SoC debug function 62 includes an encryption function 63 and a key sharing function 64.

The encryption function 63 is a function for decrypting an encrypted operation instruction (debug signal), encrypting an instruction result (debug signal), and the like. In the present specification, the debug signal is a signal related to debugging, and is a signal transmitted and received between the probe 30 and the device 50.

The key sharing function 64 is a function for sharing a key with the secure component 70. Further, the debug function 62 in the CPU / SoC holds a CA public key, a certificate, and the like in order to realize the function. The CA public key and certificate are the public key and certificate of the CA (Certificate Authority) that created the public key certificate, and are used to prove the validity of the device-side public key. In this embodiment, the public key of the manufacturer of the secure component 70 and the certificate certifying the manufacturer are used.

The secure component 70 has hardware or software tamper resistance, and is a component for protecting confidential information such as a private key. The secure component 70 may be implemented by either a hardware implementation (for example, a secure element, a TPM (Trusted Platform Module), etc.) or a software implementation (trusted execution environment, etc.). The secure component 70 includes an encryption function 71, a mutual authentication function 72, a user authentication function 73, a secret communication function 74, an authentication permission list 75, and the like.

The encryption function 71 is a function for performing encrypted communication with the secure component 40 in the probe 30. The mutual authentication function 72 is a function for performing mutual authentication with the secure component 40 in the probe 30. The user authentication function 73 is a function for personally authenticating a user by a PIN or the like. The secret communication function 74 is a function for opening a secret communication path with the debug environment management server 10. The authentication permission list 75 is a list of individual IDs to which the secure component 70 permits mutual authentication. When performing mutual authentication, the secure component 70 permits authentication only when the secure component of the authentication partner is registered in the authentication authorization list 75.

The secure component 70 holds secret information such as a device-side private key, a device-side public key and certificate, a CA public key and certificate, personal authentication information, a secret communication channel key, and a session key in order to realize the function. The device-side private key is a private key used in the mutual authentication function 72. The device-side public key and certificate are a certificate of the public key used in the mutual authentication function 72, the individual ID of the secure component 70, and the device-side public key. In this embodiment, it is a certificate in which the manufacturer of the secure component is CA. The CA public key and certificate are the CA public key and certificate that created the probe side public key certificate, and are used to prove the validity of the probe side public key. The personal authentication information is used in the user authentication function 73 and is information for confirming the legitimacy of the user. For example, a PIN can be used. The secret communication path key is used by the secret communication function 74 and is a key for performing secret communication with the debug environment management server 10. Although not shown, the session key is a key that is temporarily generated when performing encrypted communication with the secure component 40 in the probe 30.

The probe 30 is a device for connecting to the device 50 to send and receive debug signals in order to perform debugging by the embedded device development PC 20. The probe 30 includes a PC-side debugger I / F31, a debug I / F32, and a secure component 40.

The PC-side debugger I / F31 is an interface for connecting to the embedded device development PC 20, and for example, USB or the like can be used. The debug I / F 32 is an interface for connecting to the device 50, and for example, an interface such as JTAG (Joint Test Action Group) / SWD (Serial Wire Debug) can be used.

The secure component 40 has hardware or software tamper resistance, and is a component for protecting confidential information such as a private key. The secure component 40 may be implemented by either a hardware implementation (for example, a secure element, a TPM (Trusted Platform Module), etc.) or a software implementation (trusted execution environment, etc.). The secure component 40 has the same configuration as the secure component 70, and includes an encryption function 43, a mutual authentication function 44, a user authentication function 42, a secret communication function 41, an authentication permission list 45, and the like.

The encryption function 43 is a function for performing encrypted communication with the secure component 70 in the device 50. The mutual authentication function 44 is a function for performing mutual authentication with the secure component 70 in the device 50. The user authentication function 42 is a function for personally authenticating a user by a PIN or the like. The secret communication function 41 is a function for opening a secret communication path with the debug environment management server 10. The authentication permission list 45 is a list of individual IDs to which the secure component 40 permits mutual authentication. When performing mutual authentication, the secure component 40 permits authentication only when the secure component of the authentication partner is registered in the authentication permission list 45.

The secure component 40 holds secret information such as a probe-side private key, a probe-side public key and certificate, a CA public key and certificate, personal authentication information, a secret channel key, and a session key in order to realize the function. The probe-side private key is a private key used in the mutual authentication function 44. The probe-side public key and certificate are a certificate of the public key used in the mutual authentication function 44, the individual ID of the secure component 40, and the probe-side public key. In this embodiment, it is a certificate in which the manufacturer of the secure component is CA. The CA public key and certificate are the CA public key and certificate that created the device-side public key certificate, and are used to prove the validity of the device-side public key. The personal authentication information is used in the user authentication function 42 and is information for confirming the legitimacy of the user. For example, a PIN can be used. The secret communication path key is used by the secret communication function 41 and is a key for performing secret communication with the debug environment management server 10. Although not shown, the session key is a key that is temporarily generated when performing encrypted communication with the secure component 70 in the device 50.

The embedded device development PC 20 is a PC (personal computer) used by a programmer or the like to perform various operations (for example, coding, testing, debugging, etc.) in embedded development. The embedded device development PC20 is an IDE (Integrated Development Environment).
), A debug operation environment 21 such as CLI (Command Line Interface), a PC-side debugger 22, and a debug probe I / F23 having an interface function with the probe 30.

The debug environment management server 10 includes a secret communication function 11 and manages secret information held by the secure components 40 and 70.

Next, the processing of the debug system of the present embodiment will be described.

FIG. 2 is a schematic diagram showing an example of the processing flow of the debug start instruction. The debug start timing can be set as appropriate, but for example, the programmer can enable the debug function and perform debugging by transmitting the debug start to the tool. Hereinafter, each process in the figure will be described as # 1 to # 4.

# 1 (Instruction to start debugging by the programmer): The programmer instructs the debug operation environment 21 operating on the embedded device development PC 20 to start debugging.

# 2 (Send debug start instruction to probe): The debug operation environment 21 transmits a debug start instruction to the probe 30.

# 3 (Send debug start instruction to device): The probe 30 transmits a debug start instruction to the device 50 via the debug I / F32.

# 4 (Send debug start instruction to debug target CPU / SoC): The device 50 transmits the received debug start instruction to the debug target CPU / SoC 60.

When the secure component 70 on the device side and the CPU / SoC60 to be debugged are mounted as separate semiconductor chips on the same board, a malicious attacker interferes with the inter-chip wiring (for example, wiring probing, disconnection, etc.). ), It may be possible to intercept the signal between both chips or perform debugging by bypassing the secure component. In this embodiment, as shown below, an encrypted communication path is established between the secure component 70 on the device side and the CPU / SoC60 to be debugged prior to the start of debugging by the probe 30.

FIG. 3 is a schematic diagram showing an example of a processing flow for establishing an encrypted communication path between the secure component 70 and the CPU / SoC60 to be debugged. Hereinafter, each process in the figure will be described as # 1 to # 6.

# 1 (Start of key sharing procedure by debug target CPU / SoC): The debug target CPU / SoC 60 makes an authentication request to the secure component 70.

# 2 (output of public key and certificate): The secure component 70 transmits the device-side public key and certificate held by itself to the CPU / SoC60 to be debugged.

# 3 (Verification of public key and certificate): The debuggee CPU / SoC60 verifies the received device-side public key and certificate. Specifically, the debug target CPU / SoC60 verifies the public key signature in the device-side certificate by using the CA public key held by itself. If the verification fails here, it is regarded as an invalid device-side public key and certificate, and the process ends. If the verification is successful, the secure component 70 that has sent the device-side public key and certificate proceeds with the process as being reliable.

# 4 (Random number generation and return): The debuggee CPU / SoC60 generates a random number by itself (or using a random number generator or the like), and encrypts the generated encrypted random number with the public key of the secure component 70 to secure it. Return to component 70.

# 5 (Generation of session key on the secure component side): The secure component 70 decrypts the received encrypted random number with its own private key, and generates a CPU / SoC session key from the random number obtained by the decryption. The secure component 70 notifies the debug target CPU / SoC 60 that the decryption of the encrypted random number and the generation of the CPU / SoC session key have been completed normally.

# 6 (Completion of key sharing with CPU / SoC side): When the debug target CPU / SoC 60 receives a normal end notification from the secure component 70, it generates a CPU / SoC session key from a random number generated by itself. The generated CPU / SoC session key is the same as the CPU / SoC session key generated by the secure component 70. After that, the debug target CPU / SoC 60 performs encrypted communication with the secure component 70 using the generated CPU / SoC session key.

In the above example, key sharing is performed using one-way authentication, but the algorithm used for key sharing is not limited to the above example. When the secure component 70 on the device side and the debug target CPU / SoC60 are mounted as the same semiconductor chip (for example, when the secure component 70 is built in the debug target CPU / SoC60), a malicious attack Since the person cannot interfere with the inter-chip wiring, it is not necessary to establish the encrypted communication path illustrated in FIG.

By the process illustrated in FIG. 3, the secure component 70 and the CPU / SoC60 to be debugged are tightly coupled in terms of security in the device 50. The process of confirming that the secure component 70 on the device side and the secure component 40 on the probe side are a combination in which debugging is permitted will be described below.

FIG. 4 is a schematic diagram showing an example of the processing flow of mutual authentication between secure components. Hereinafter, each process in the figure will be described as # 1 to # 9.

# 1 (Sending probe authentication information and probe side public key and certificate): The probe side secure component 40 generates authentication information using the probe side private key held by itself, and the probe side public key and certificate. The authentication information generated together with is sent to the secure component 70 on the device side. Here, the authentication information may be any content that can confirm that the authentication partner (in this case, the secure component 40 on the probe side) holds the private key. For example, the probe ID: Probe-0001 is the secret on the probe side. A key-encrypted one can be used. Further, a random number element may be included in the authentication information for the probe session key generation described later.

# 2 (Public key and certificate verification): The device-side secure component 70 verifies the received probe-side public key and certificate. Specifically, the secure component 70 verifies the public key signature in the probe-side certificate by using the CA public key held by itself. If the verification fails here, it is regarded as an invalid probe-side public key and certificate, and the process ends. If the verification is successful, the secure component 40 that has sent the probe-side public key and the certificate proceeds with the process as being reliable.

# 3 (Confirmation of authentication permission list): The secure component 70 confirms whether the probe ID stored in the probe-side certificate is specified in the authentication permission list 75 held by itself. If the probe ID does not exist in the authentication permission list 75, it is regarded as an unauthorized probe, and the process ends.

# 4 (Verification of probe authentication information): The secure component 70 decrypts the authentication information received from the secure component 40 using the probe-side public key, and determines the predetermined information (here, the probe specified in the certificate). Verify that it is ID). If the verification fails, the process ends here.

# 5 (Sending device authentication information and device side public key and certificate): The device side secure component 70 generates authentication information using the device side private key held by itself, and the device side public key and certificate. The authentication information generated together with is sent to the secure component 40 on the probe side. Here, the authentication information may be any content that can confirm that the authentication partner (in this case, the secure component 70 on the device side) holds the private key. For example, the device ID: Device-0001 is kept secret on the device side. A key-encrypted one can be used. Further, a random number element may be included in the authentication information for the probe session key generation described later.

# 6 (Public key and certificate verification): The probe-side secure component 40 verifies the received device-side public key and certificate. Specifically, the secure component 40 verifies the public key signature in the device-side certificate by using the CA public key held by itself. If the verification fails here, it is regarded as an invalid device-side public key and certificate, and the process ends. If the verification is successful, the secure component 70 that has sent the device-side public key and certificate proceeds with the process as being reliable.

# 7 (Confirmation of authentication permission list): The secure component 40 confirms whether the device ID stored in the device-side certificate is specified in the authentication permission list 45 held by itself. If the device ID does not exist in the authentication permission list 45, it is regarded as an unauthorized probe, and the process ends.

# 8 (Verification of device authentication information): The secure component 40 decrypts the authentication information received from the secure component 70 using the device-side public key, and determines the predetermined information (here, the device specified in the certificate). Verify that it is ID). If the verification fails, the process ends here.

# 9 (Generation of probe session key): The secure component 40 and the secure component 70 each generate and hold the same probe session key based on the exchanged random number elements.

As described above, the device 50 having the debug target program 61 (debug target) has a mutual authentication function 72 (authentication) that performs mutual authentication with the secure component 40 provided in the probe 30 (debug device) for debugging the debug target. A secure component 70 having a part) is provided, and when the mutual authentication function 72 succeeds in mutual authentication, the secure component 70 sends and receives a debug signal to and from the secure component 40.

Further, the probe 30 (debug device) for debugging the debug target program 61 (debug target) has a mutual authentication function 44 (authentication unit) that performs mutual authentication with the secure component 70 provided in the device 50 having the debug target. The secure component 40 includes the secure component 40, and when the mutual authentication function 44 succeeds in mutual authentication, the secure component 40 sends and receives a debug signal to and from the secure component 70.

The secure component 40 mounted on the probe 30 (debug device) has a mutual authentication function 44 (authentication unit) that performs mutual authentication with the secure component 70 provided in the device 50 having a debug target, and is mutually authenticated by the mutual authentication function 44. If the authentication is successful, a debug signal is exchanged with the secure component 70.

Further, the secure component 70 mounted on the device 50 having the debug target program 61 (debug target) performs mutual authentication with the secure component 40 provided in the probe 30 (debug device) for debugging the debug target program 61. It is equipped with a mutual authentication function 44 (authentication unit), and when mutual authentication is successful with the mutual authentication function 44, a debug signal is exchanged with the secure component 40.

In a debugging system or a debugging method including a device 50 having a debug target program 61 (debug target) and a probe 30 (authentication device) for debugging the debug target program 61, the device 50 is a secure device provided in the probe 30. A secure component 70 having a mutual authentication function 72 (device side authentication unit) that performs mutual authentication with the component 40 is provided, and the probe 30 has a mutual authentication function 44 (device side) that performs mutual authentication with the secure component 70 provided in the device 50. A secure component 40 having an authentication unit) is provided, and when mutual authentication is successful in each of the mutual authentication functions 72 and 44, a debug signal is exchanged between the secure component 70 and the secure component 40.

As described above, a probe capable of debugging the device 50 by performing mutual authentication between the device 50 and the probe 30 and confirming that the combination of the device 50 and the probe 30 is valid before debugging. 30 can be physically limited, and the possibility of misuse of the debugging function by a third party can be minimized.

The mutual authentication algorithm is not limited to the above example, and a suitable algorithm can be adopted. However, in confirming the validity of the probe 30 (secure component 40) and the device 50 (secure component 70), As mentioned above, it is desirable to apply an asymmetric key algorithm that uses two sets of keys, a public key and a private key.

By the process illustrated in FIG. 4, mutual authentication between the device 50 and the probe 30 was successful, and it was confirmed that the combination was valid for each other. Therefore, the security policy for communication between the device 50 and the probe 30 Depending on the situation, plaintext communication may be performed in this state for debugging. In the following, debugging using plaintext communication will be described.

FIG. 5 is a schematic diagram showing an example of a processing flow of plaintext communication between the probe 30 and the device 50. Hereinafter, each process in the figure will be described as # 1 to # 12.

# 1 (Debug operation): The programmer gives a debug operation instruction to the debug operation environment 21.

# 2 (Send operation instruction to probe): The debug operation environment 21 transmits an operation instruction to the probe 30.

# 3 (Send operation instruction to device): The probe 30 transmits an operation instruction to the device 50 via the debug I / F32. The device 50 inputs the received operation instruction to the secure component 70.

# 4 (encrypted transmission by the device-side secure component): The secure component 70 encrypts the received operation instruction with the CPU / SoC session key, and transmits the encrypted operation instruction to the debug function 62 in the CPU / SoC.

# 5 (Decrypt operation instruction on the CPU / SoC side): The debug function 62 in the CPU / SoC decodes the received encryption operation instruction with the CPU / SoC session key to obtain the operation instruction.

# 6 (Operate the debug target program): The debug function 62 in the CPU / SoC operates the debug target CPU / SoC 60 with the instructed content, operates the debug target program 61, or acquires information.

# 7 (returns the instruction result): The CPU / SoC debug function 62 receives the instruction result of the above-mentioned # 6 process.

# 8 (encrypted transmission by the CPU / SoC side): The CPU / SoC internal debug function 62 encrypts the received instruction result with the CPU / SoC session key, and transmits the encrypted instruction result to the secure component 70.

# 9 (Decryption by the device-side secure component): The secure component 70 decrypts the received encryption instruction result with the CPU / SoC session key, and obtains the instruction result.

# 10 (Returning the instruction result to the probe): The device 50 acquires the instruction result from the secure component 70 and returns it to the probe 30.

# 11 (Returning the instruction result to the embedded device development PC): The probe 30 returns the instruction result received from the device 50 to the embedded device development PC 20.

# 12 (Display instruction result): The embedded device development PC 20 reflects the instruction result received from the probe 30 in the debug operation environment 21 and shows it to the programmer.

Instead of the plaintext communication as described above, as shown below, the communication content between the probe 30 and the device 50 can be concealed and protected.

FIG. 6 is a schematic diagram showing an example of a processing flow of encrypted communication between the probe 30 and the device 50. Hereinafter, each process in the figure will be described as # 1 to # 18.

# 1 (Debug operation): The programmer gives a debug operation instruction to the debug operation environment 21.

# 2 (Send operation instruction to probe): The debug operation environment 21 transmits an operation instruction to the probe 30.

# 3 (Output operation instruction to the secure component): The probe 30 outputs the received operation instruction to the secure component 40.

# 4 (encryption of operation instruction): The secure component 40 uses its own probe session key to encrypt the acquired operation instruction.

# 5 (Transmission of encryption operation instruction): The probe 30 transmits an encrypted operation instruction to the device 50 via the debug I / F 32. The device 50 transmits the received encryption operation instruction to the secure component 70.

# 6 (Decryption by the device-side secure component): The secure component 70 decrypts the received encryption operation instruction with the probe session key held by itself.

# 7 (Transmit re-encryption): The secure component 70 re-encrypts the decrypted operation instruction with the CPU / SoC session key, and transmits the encryption operation instruction to the debug function 62 in the CPU / SoC.

# 8 (decrypt operation instruction on the CPU / SoC side): The debug function 62 in the CPU / SoC decodes the received encryption operation instruction with the CPU / SoC session key, and obtains the operation instruction.

# 9 (Operate the debug target program): The debug function 62 in the CPU / SoC operates the debug target CPU / SoC 60 with the instructed content, operates the debug target program 61, or acquires information.

# 10 (Receive instruction result): The debug function 62 in the CPU / SoC receives the instruction result of the above-mentioned # 6 process.

# 11 (encryption and transmission by the CPU / SoC side): The CPU / SoC internal debug function 62 encrypts the received instruction result with the CPU / SoC session key, and transmits the encryption instruction result to the secure component 70.

# 12 (Decryption by the device-side secure component): The secure component 70 decrypts the received encryption instruction result with the CPU / SoC session key, and obtains the instruction result.

# 13 (re-encryption): The secure component 70 re-encrypts the decrypted instruction result with the probe session key.

# 14 (Returning the instruction result to the probe): The device 50 acquires the encrypted instruction result from the secure component 70 and returns it to the probe 30.

# 15 (Transfer to secure component): The probe 30 transmits the instruction result received from the device 50 to the secure component 40.

# 16 (Decryption of operation instruction): The secure component 40 decodes the received instruction result with the probe session key.

# 17 (Returning the instruction result to the embedded device development PC): The probe 30 returns the instruction result received from the secure component 40 to the embedded device development PC 20.

# 18 (Display instruction result): The embedded device development PC 20 reflects the instruction result received from the probe 30 in the debug operation environment 21 and shows it to the programmer.

As described above, the secure component 70 includes an encryption function 71 (encryption unit, decryption unit), and the encryption function 71 sends a message to the secure component 40 when mutual authentication is successful with the mutual authentication function 72. The encryption function 71 encrypts the debug signal to be used, and when the mutual authentication function 72 succeeds in mutual authentication, the encryption function 71 decrypts the encrypted debug signal acquired from the secure component 40.

Further, the secure component 40 includes an encryption function 43 (encryption unit, decryption unit), and the encryption function 43 sends a debug signal to the secure component 70 when mutual authentication is successful with the mutual authentication function 44. The encryption function 43 decrypts the encrypted debug signal acquired from the secure component 70 when the mutual authentication is successful in the mutual authentication function 44.

In this way, the secure components 40 and 70 directly encrypt the debug communication between the device 50 and the probe 30, and the encrypted communication is realized by exchanging and exchanging with the other secure component to support the encrypted communication. Even for older devices that are not, secure components can provide cryptographic means in the form of mediating protocols.

Prior to using the debug function, the secure component 40 in the probe 30 authenticates the user (programmer, maintenance operator, etc.), and only a legitimate user can use the debug function. The user authentication will be described below.

FIG. 7 is a schematic diagram showing an example of the processing flow of user authentication of the probe 30. Hereinafter, among the users, a programmer will be taken as an example, and each process in the figure will be described as # 1 to # 6. The same applies to the authentication of other users such as maintenance operators.

# 1 (Debug operation): The programmer gives a debug operation instruction to the debug operation environment 21.

# 2 (Probe authentication status confirmation): The debug operation environment 21 inquires of the probe 30 whether the debug operation is possible (whether the user authentication is completed), and obtains that the state is before the authentication is performed. Show to the programmer.

# 3 (input of user authentication information): The programmer inputs personal authentication information into the debug operation environment 21. As the personal authentication information, for example, information such as PIN (personal identification number) can be used, but the personal identification information is not limited to this, and biometric information such as fingerprints and palm prints and authentication information generated by a security token can be used. It may be property information.

# 4 (Transmission of user authentication information): The debug operation environment 21 transmits personal authentication information to the probe 30. The probe 30 transmits personal authentication information to the internal secure component 40.

# 5 (Verification of user authentication information): The secure component 40 collates the received personal authentication information with the personal authentication information held by itself.

# 6 (Transmission of authentication result): The secure component 40 returns the authentication result to the embedded device development PC 20 via the probe 30. At this time, if the authentication is successful, the function of the probe 30 is unlocked so that the debug function can be used. If the authentication is not successful, the function of the probe 30 is left unlocked so that the debug function cannot be used.

In the above example, the user authentication is performed on the probe 30 side, but the debug function may be locked or unlocked by performing user authentication on the device 50 side as described below.

FIG. 8 is a schematic diagram showing an example of the processing flow of user authentication of the device 50. Hereinafter, each process in the figure will be described as # 1 to # 6.

# 1 (Debug operation): The programmer gives a debug operation instruction to the debug operation environment 21.

# 2 (Probe authentication status confirmation): The debug operation environment 21 inquires whether the debug operation can be performed on the device 50 via the probe 30 (whether the user authentication is completed), and is in the state before the authentication is performed. Get a certain point and show it to the programmer.

# 3 (input of user authentication information): The programmer inputs preset personal authentication information into the debug operation environment 21.

# 4 (Transmission of user authentication information): The debug operation environment 21 transmits personal authentication information to the device 50 via the probe 30. The device 50 transmits personal authentication information to the internal secure component 70.

# 5 (Verification of user authentication information): The secure component 70 collates the received personal authentication information with the personal authentication information held by itself.

# 6 (Transmission of authentication result): The secure component 70 returns the authentication result to the embedded device development PC 20 via the probe 30. At this time, if the authentication is successful, the function of the device 50 is unlocked so that the debug function can be used. If the authentication is not successful, the function of the device 50 is left unlocked so that the debug function cannot be used.

As described above, the secure component 70 has a user authentication function 73 (acquisition unit) that acquires personal authentication information (user authentication information) and a user authentication function 73 that performs personal authentication based on the acquired personal authentication information. (User authentication unit) is provided, and when personal authentication is successful with the user authentication function 73, a debug signal can be sent and received.

In addition, the secure component 40 has a user authentication function 42 (acquisition unit) that acquires personal authentication information (user authentication information) and a user authentication function 42 (user) that performs personal authentication based on the acquired personal authentication information. It is equipped with an authentication unit), and when personal authentication is successful with the user authentication function 42, it is possible to send and receive a debug signal.

With the above configuration, a secure debugging environment that is robust in terms of security can be realized by appropriately authenticating the probe 30, the device 50, and the user with the secure components 40 and 70. On the other hand, there are cases where the embedded device development environment lacks flexibility, such as debugging cannot be performed on devices that are not linked by the authentication permission list or the like. In the following, an example of imparting flexibility by updating the confidential information inside the secure component via a secret communication path that the secure component can open independently of the external server will be described.

FIG. 9 is a schematic diagram showing an example of a processing flow of the debug function operation on the probe side via the secret communication path. In the example of FIG. 9, after sharing the key information between the debug environment management server 10 and the secure component 40, both parties open a secret communication path such as TLS (Transport Layer Security), and the opened secret communication path is used. The debug environment management server 10 updates the confidential information inside the secure component 40 via the system. Hereinafter, each process in the figure will be described as # 1 to # 2.

# 1 (Open secret communication path): The debug environment management server 10 communicates with the secret communication function 41 of the secure component 40, and opens a secret communication path using the secret communication path key shared by both parties.

# 2 (Update of secure component information): The debug environment management server 10 updates the information (for example, secret information) in the secure component 40 via the established secret communication path.

Depending on the information to be updated, the function of the probe 30 can be enabled / disabled, or the combination with the device can be changed. For example, when the personal authentication information is to be updated, the individual who can use the probe 30 can be changed. In this case, the authentication information type (PIN, biometric authentication, owner authentication, etc.) that can be used for the authentication of the probe 30 is changed.

When the authentication permission list 45 is to be updated, the device that can be debugged by the probe 30 can be changed. Further, if the probe-side private key, the probe-side public key, and the certificate are to be renewed, the key can be renewed when the probe-side key becomes obsolete or leaked. As a result, the key in the probe 30 can be revoked, the debug function of the probe 30 can be invalidated, and vice versa.

In the above example, the probe 30 and the debug environment management server 10 are connected via the embedded device development PC 20, but the probe 30 and the secure component 40 have a function capable of communicating by themselves (for example,). Communication may be performed independently (for example, when an IP address is assigned). Further, the information timing in the secure component 40 can be set as appropriate. For example, the user may request the start of the update process as needed, or the user may automatically update at the required timing. ..

In the above example, the debug function operation is executed on the probe 30, but it may be executed on the device 50 as follows.

FIG. 10 is a schematic diagram showing an example of the processing flow of the debug function operation on the device side via the secret communication path. In the example of FIG. 10, after sharing the key information between the debug environment management server 10 and the secure component 70 on the device 50 side, both parties open a secret communication path such as TLS and go through the opened secret communication path. Then, the debug environment management server 10 updates the confidential information inside the secure component 70. Hereinafter, each process in the figure will be described as # 1 to # 2.

# 1 (Open secret communication path): The debug environment management server 10 communicates with the secret communication function 74 of the secure component 70, and opens a secret communication path using the secret communication path key shared by both parties.

# 2 (Update of secure component information): The debug environment management server 10 updates the information (for example, secret information) in the secure component 70 via the established secret communication path.

The debug function on the device 50 side can be changed depending on the information to be updated. For example, when the personal authentication information is to be updated, the individual who can debug the device 50 can be changed. In this case, the authentication information type (PIN, biometric authentication, owner authentication, etc.) that can be used for authentication of the device 50 is changed.

When the authentication permission list 75 is to be updated, the probe that can debug the device 50 can be changed. Further, if the device-side private key, the device-side public key, and the certificate are to be renewed, the key can be renewed when the device-side key becomes obsolete or leaked. As a result, the key in the device 50 can be revoked, the debug function of the device 50 can be disabled, and vice versa.

As described above, the secure component 70 is located between the inside (storage unit) of the secure component 70 that stores confidential information including information related to mutual authentication with the secure component 40 and the debug environment management server 10 (external device). It is equipped with a secret communication function 74 (opening unit) that opens a secret communication path, and can update the secret information stored inside the secure component 70 via the secret communication path opened by the secret communication function 74.

Further, the secure component 40 is a secret communication path between the inside (storage unit) of the secure component 40 that stores confidential information including information related to mutual authentication with the secure component 70 and the debug environment management server 10 (external device). The secret communication function 41 (opening unit) is provided, and the secret information stored inside the secure component 40 can be updated via the secret communication path opened by the secret communication function 41.

In this way, the secure component 70 mounted on the device 50 and the internal state of the secure component 40 mounted on the probe 30 such as the debug function and the mutual authentication key are independently hidden communication paths of the secure components 40 and 70. Since it can be changed via, in order to strongly protect the device 50, the debugging function of the device 50 can be completely disabled, or the legitimate combination of the device 50 and the probe 30 can be dynamically changed, and the probe can be changed. 30 can be effectively used.

Secure components 40, 70 may be configured with either a secure element, a trusted platform module (TPM), or a trusted execution environment.

By storing information related to debugging (for example, a key required for mutual authentication) in a secure component, it is possible to prevent misuse of the debugging function by a third party using key leakage by analysis of the device 50 or probe 30. Further, by individualizing the keys, it is possible to deal with the compromise of the device 50 and the probe 30. In addition, if a secure element having tamper resistance is used, the debug function can be effectively used for operation and maintenance purposes without making the debug function vulnerable for a long period of time even after being shipped to the market.

(Second Embodiment)
FIG. 11 is a schematic diagram showing an example of the configuration of the debug system of the second embodiment. In the first embodiment, the probe 30 and the embedded device development PC 20 are separate devices (devices), but the configuration is not limited to this. In the second embodiment, the embedded device development PC 20 may have a built-in function of the probe 30, and the embedded device development PC 20 may function as a probe.

As shown in FIG. 11, the embedded device development PC 20 includes a debug operation environment 21, a debugger 22 on the PC side, a debugger-device I / F25 having an interface function with the device 50, and a secure component 40. The difference from the embedded device development PC20 illustrated in FIG. 1 is that it includes a secure component 40 and a debugger-device I / F25, and does not include a debug probe I / F23. Since the functions and processes of the debug operation environment 21, the PC-side debugger 22, and the secure component 40 are the same as those in the first embodiment, the description thereof will be omitted.

Further, the device 50 is the same as that of the first embodiment except that the debug I / F51 is provided with the PC-CPU / SoC debug I / F52 instead of the debug I / F51. The embedded device development PC 20 and the device 50 can be accessed via a general-purpose port such as USB.

(Third Embodiment)
FIG. 12 is a schematic diagram showing an example of the configuration of the debug system of the third embodiment. In the first embodiment, the debug target CPU / SoC60 and the secure component 70 in the device 50 are mounted as separate semiconductor chips, but the present invention is not limited to this. The third embodiment shows a configuration in which the secure component 70 is built in the CPU / SoC60 to be debugged. When the secure component 70 exists inside the debug target CPU / SoC60, since both are physically integrated, the need to encrypt the communication between the two can be reduced. Therefore, it is also possible to carry out communication between the debug function 62 in the CPU / SoC and the secure component 70 in plain text. In this case, during the debugging operation, the encryption processing between the debug function 62 in the CPU / SoC and the secure component 70 becomes unnecessary, and the processing speed can be increased. Hereinafter, the encrypted communication between the probe 30 and the device 50 will be described.

FIG. 13 is a schematic diagram showing an example of a processing flow of encrypted communication between the probe 30 and the device 50 in the case of the third embodiment. Hereinafter, each process in the figure will be described as # 1 to # 14.

# 1 (Debug operation): The programmer gives a debug operation instruction to the debug operation environment 21.

# 2 (Send operation instruction to probe): The debug operation environment 21 transmits an operation instruction to the probe 30.

# 3 (Output operation instruction to the secure component): The probe 30 outputs the received operation instruction to the secure component 40.

# 4 (encryption of operation instruction): The secure component 40 uses its own probe session key to encrypt the acquired operation instruction.

# 5 (Transmission of encryption operation instruction): The probe 30 transmits an encrypted operation instruction to the device 50 via the debug I / F 32. The device 50 transmits the received encryption operation instruction to the secure component 70.

# 6 (Decryption by the device-side secure component): The secure component 70 decrypts the received encryption operation instruction with the probe session key held by itself.

# 7 (Operate the debug target program): The secure component 70 sends the decoded operation instruction to the CPU / SoC in the debug target CPU / SoC 60 via the debug function 62 in the CPU / SoC, and operates the CPU / SoC. As a result, the debug target program 61 can be operated or information can be acquired.

# 8 (returns the instruction result): The secure component 70 receives the instruction result of the above-mentioned processing in # 7 via the debug function 62 in the CPU / SoC.

# 9 (encrypt the instruction result): The secure component 70 encrypts the received instruction result with the probe session key.

# 10 (Returning the instruction result to the probe): The device 50 acquires the encrypted instruction result from the secure component 70 and returns it to the probe 30.

# 11 (Returning the instruction result to the secure component): The probe 30 transmits the instruction result received from the device 50 to the secure component 40.

# 12 (Decryption of operation instruction): The secure component 40 decodes the received instruction result with the probe session key.

# 13 (Returning the instruction result to the embedded device development PC): The probe 30 returns the instruction result received from the secure component 40 to the embedded device development PC 20.

# 14 (Display instruction result): The embedded device development PC 20 reflects the instruction result received from the probe 30 in the debug operation environment 21 and shows it to the programmer.

It is also possible to protect the communication between the debug function 62 in the CPU / SoC and the secure component 70 by encryption, and the encryption can prevent, for example, a side channel attack.

(Fourth Embodiment)
In each of the above-described embodiments, the secure components 40 and 70 perform encryption / decryption in the encrypted communication between the probe 30 or the embedded device development PC 20 and the device 50, but real-time performance is required in the debug environment. Often done. Depending on the processing power of the secure components 40 and 70, the encryption / decryption by the secure components 40 and 70 may become a time bottleneck of the debugging work. In the fourth embodiment, the secure components 40 and 70 perform only mutual authentication, and the agreed probe session key is externally output to the probe 30 or the embedded device development PC 20 and the debug target CPU / SoC60, respectively, and then directly encrypted by both. The configuration for decoding is shown.

FIG. 14 is a schematic diagram showing an example of a processing flow of mutual authentication between secure components in the case of the fourth embodiment. Hereinafter, each process in the figure will be described as # 1 to # 9. Here, the debugging system of the first embodiment will be used for description.

# 1 (Sending probe authentication information and probe side public key and certificate): The probe side secure component 40 generates authentication information using the probe side private key held by itself, and the probe side public key and certificate. The authentication information generated together with is sent to the secure component 70 on the device side. Here, the authentication information may be any content that can confirm that the authentication partner (in this case, the secure component 40 on the probe side) holds the private key. For example, the probe ID: Probe-0001 is the secret on the probe side. A key-encrypted one can be used. Further, a random number element may be included in the authentication information for the probe session key generation described later.

# 2 (Public key and certificate verification): The device-side secure component 70 verifies the received probe-side public key and certificate. Specifically, the secure component 70 verifies the public key signature in the probe-side certificate by using the CA public key held by itself. If the verification fails here, it is regarded as an invalid probe-side public key and certificate, and the process ends. If the verification is successful, the secure component 40 that has sent the probe-side public key and the certificate proceeds with the process as being reliable.

# 3 (Confirmation of authentication permission list): The secure component 70 confirms whether the probe ID stored in the probe-side certificate is specified in the authentication permission list 75 held by itself. If the probe ID does not exist in the authentication permission list 75, it is regarded as an unauthorized probe, and the process ends.

# 4 (Verification of probe authentication information): The secure component 70 decrypts the authentication information received from the secure component 40 using the probe-side public key, and determines the predetermined information (here, the probe specified in the certificate). Verify that it is ID). If the verification fails, the process ends here.

# 5 (Sending device authentication information and device side public key and certificate): The device side secure component 70 generates authentication information using the device side private key held by itself, and the device side public key and certificate. The authentication information generated together with is sent to the secure component 40 on the probe side. Here, the authentication information may be any content that can confirm that the authentication partner (in this case, the secure component 70 on the device side) holds the private key. For example, the device ID: Device-0001 is kept secret on the device side. A key-encrypted one can be used. Further, a random number element may be included in the authentication information for the probe session key generation described later.

# 6 (Public key and certificate verification): The probe-side secure component 40 verifies the received device-side public key and certificate. Specifically, the secure component 40 verifies the public key signature in the device-side certificate by using the CA public key held by itself. If the verification fails here, it is regarded as an invalid device-side public key and certificate, and the process ends. If the verification is successful, the secure component 70 that has sent the device-side public key and certificate proceeds with the process as being reliable.

# 7 (Confirmation of authentication permission list): The secure component 40 confirms whether the device ID stored in the device-side certificate is specified in the authentication permission list 45 held by itself. If the device ID does not exist in the authentication permission list 45, it is regarded as an unauthorized probe, and the process ends.

# 8 (Verification of device authentication information): The secure component 40 decrypts the authentication information received from the secure component 70 using the device-side public key, and determines the predetermined information (here, the device specified in the certificate). Verify that it is ID). If the verification fails, the process ends here.

# 9 (Generation of probe session key): The secure component 40 and the secure component 70 generate the same probe session key based on the random number elements given and received, and the generated probe session key is used as the probe 30 and the CPU to be debugged. Output to SoC60.

By externally outputting the probe session keys generated by the secure components 40 and 70 to the probe 30 and the debug target CPU / SoC60, the probe 30 and the debug target CPU / SoC60 can directly perform encrypted communication. As a result, it is possible to achieve a good balance between protection by encryption and performance assurance of the debug environment. The secure component 40 and the probe 30 are collectively referred to as the probe side (device side), and the secure component 70 and the CPU / SoC60 to be debugged are collectively referred to as the device side. In this case, the main body for transmitting and receiving the debug signal on the device side may be either the secure component 40 or the probe 30. Further, the main body of transmission / reception of the debug signal on the device side may be either the secure component 70 or the debug target CPU / SoC60.

FIG. 15 is a schematic diagram showing an example of a processing flow of encrypted communication between the probe 30 of the fourth embodiment and the CPU / SoC60 to be debugged. Hereinafter, each process in the figure will be described as # 1 to # 14.

# 1 (Debug operation): The programmer gives a debug operation instruction to the debug operation environment 21.

# 2 (Send operation instruction to probe): The debug operation environment 21 transmits an operation instruction to the probe 30.

# 3 (output operation instruction to device): The probe 30 outputs the received operation instruction to the encryption function 33.

# 4 (encryption of operation instruction): The encryption function 33 encrypts the acquired operation instruction by using the probe session key. Here, the prosession key is generated by the secure component 40 in the process illustrated in FIG.

# 5 (Transmission of encryption operation instruction): The probe 30 transmits an encrypted operation instruction to the device 50 via the debug I / F 32. The device 50 transmits the received encryption operation instruction to the debug function 62 in the CPU / SoC of the CPU / SoC 60 to be debugged.

# 6 (Decryption by the secure component on the device side): The debug function 62 in the CPU / SoC decodes the received encryption operation instruction with the probe session key held by itself. Here, the prosession key is generated by the secure component 70 in the process illustrated in FIG.

# 7 (Operate the debug target program): The debug function 62 in the CPU / SoC operates the debug target CPU / SoC 60 with the instructed content, operates the debug target program 61, or acquires information.

# 8 (Receive instruction result): The debug function 62 in the CPU / SoC receives the instruction result of the above-mentioned # 7 process.

# 9 (encryption): The CPU / SoC debug function 62 encrypts the received instruction result with the prosession key.

# 10 (Returns the instruction result to the probe): The CPU / SoC debug function 62 returns the encrypted instruction result to the probe 30.

# 11 (Transfer to encryption function): The probe 30 transfers the instruction result received from the device 50 to the encryption function 33.

# 12 (Decryption of operation instruction): The encryption function 33 decrypts the received instruction result with the probe session key.

# 13 (Returning the instruction result to the embedded device development PC): The probe 30 returns the decoded instruction result to the embedded device development PC 20.

# 14 (Display instruction result): The embedded device development PC 20 reflects the instruction result received from the probe 30 in the debug operation environment 21 and shows it to the programmer.

As described above, the device 50 includes an encryption function 63 (device encryption unit, device decryption unit), and the secure component 70 is a mutual authentication that generates a probe session key (session key) between the probe 30 and the device 50. When mutual authentication is successful between the function 72 (key generation unit) and the mutual authentication function 72, the mutual authentication function 72 (providing unit) that provides the generated probe session key to the CPU / SoC internal debugging function 62 (device 50 side). The encryption function 63 uses the probe session key to encrypt the debug signal sent to the probe 30, and the encryption function 63 uses the probe session key to acquire the debug signal from the probe 30. , Decrypt the encrypted debug signal.

Further, the probe 30 includes an encryption function 33 (device encryption unit, device decryption unit), and the secure component 40 has a mutual authentication function 44 (session key) for generating a probe session key (session key) between the probe 30 and the device 50. The key generation unit) and the mutual authentication function 44 (providing unit) that provides the generated probe session key to the probe 30 side when the mutual authentication is successful with the mutual authentication function 44, and the encryption function 33 provides the probe. The session key is used to encrypt the debug signal sent to the device 50, and the encryption function 33 uses the probe session key to decrypt the encrypted debug signal acquired from the device 50.

In this way, after mutual authentication between the device 50 and the probe 30, the secure components 40 and 70 provide the session key to the probe 30 and the device 50, respectively, and support the encrypted communication between the two, thereby providing the secure components 40 and 70. Security can be ensured without making it a time bottleneck for debugging.

In the above example, the external output of the probe session key is performed from the secure component in both the probe 30 and the device 50, but the external output may be performed in only one of the probe 30 and the device 50. Moreover, each example of 1st Embodiment to 4th Embodiment may be carried out in combination. For example, it is possible to debug the device 50 having the secure component 70 built in the CPU / SoC 60 to be debugged from the embedded device development PC 20 having the built-in probe function.

The device of the present embodiment is a device having a debug target, and includes a device-side secure component having a device-side secure component provided in the debug device for debugging the debug target and a device-side secure component having an authentication unit for mutual authentication. When the mutual authentication is successful in the authentication unit, the device-side secure component sends and receives a debug signal to and from the device-side secure component.

In the device of the present embodiment, the device-side secure component includes an encryption unit and a decryption unit, and the encryption unit refers to the device-side secure component when mutual authentication is successful in the authentication unit. The decryption unit decodes the encrypted debug signal acquired from the device-side secure component when the mutual authentication is successful in the authentication unit.

The device of the present embodiment includes a device encryption unit and a device decryption unit, and the device-side secure component is a mutual key generation unit that generates a session key between the debug device and the device, and the authentication unit. When the authentication is successful, the device encryption unit includes a provider unit that provides the session key generated by the key generation unit to the device side, and the device encryption unit uses the session key to send a debug to the debug device. The signal is encrypted, and the device decoding unit uses the session key to decrypt the encrypted debug signal acquired from the debug device.

In the device of the present embodiment, the device-side secure component includes an acquisition unit that acquires user authentication information and a user authentication unit that performs user authentication based on the user authentication information acquired by the acquisition unit. In preparation for this, if the user authentication is successful in the user authentication unit, a debug signal can be sent and received.

In the device of the present embodiment, the device-side secure component establishes a secret communication path between a storage unit that stores confidential information including information related to mutual authentication with the device-side secure component and an external device. It is provided with a unit, and the confidential information stored in the storage unit can be updated via the secret communication path established by the establishment unit.

In the device of the present embodiment, the device-side secure component is configured in a semiconductor chip different from the semiconductor chip having the debug target, and is connected to the semiconductor chip having the debug target via a secret communication path. ..

In the device of the present embodiment, the device-side secure component is configured in the semiconductor chip having the debug target.

The debug device of the present embodiment is a debug device for debugging the debug target, and is a device-side secure component having an authentication unit that performs mutual authentication with the device-side secure component provided in the device having the debug target. When the mutual authentication is successful in the authentication unit, the device-side secure component sends and receives a debug signal to and from the device-side secure component.

In the debugging device of the present embodiment, the device-side secure component includes an encryption unit and a decryption unit, and the encryption unit becomes the device-side secure component when mutual authentication is successful in the authentication unit. The debug signal transmitted to the device is encrypted, and the decryption unit decodes the encrypted debug signal acquired from the device-side secure component when the mutual authentication is successful in the authentication unit.

The debug device of the present embodiment includes a debug device encryption unit and a debug device decryption unit, and the device-side secure component includes a key generation unit that generates a session key between the device and the debug device, and the authentication. When the mutual authentication is successful in the unit, the unit includes a provider unit that provides the session key generated by the key generation unit to the device side, and the debug device encryption unit uses the session key to the device. The transmitted debug signal is encrypted, and the debug device decoding unit decodes the encrypted debug signal acquired from the device by using the session key.

In the debug device of the present embodiment, the device-side secure component includes an acquisition unit that acquires user authentication information and a user authentication unit that performs user authentication based on the user authentication information acquired by the acquisition unit. When the user authentication is successful in the user authentication unit, a debug signal can be sent and received.

In the debug device of the present embodiment, the device-side secure component establishes a secret communication path between a storage unit that stores confidential information including information related to mutual authentication with the device-side secure component and an external device. It is provided with an opening unit, and the confidential information stored in the storage unit can be updated via the secret communication path established by the opening unit.

The secure component of the present embodiment is a secure component mounted on a device having a debug target or a debug device for debugging the debug target, and is mutually with the device or another secure component provided on the debug device. It is provided with an authentication unit that performs authentication, and when mutual authentication is successful in the authentication unit, a debug signal is exchanged with the other secure component.

The secure component of the present embodiment includes an encryption unit and a decryption unit, and the encryption unit sends a debug signal to the other secure component when mutual authentication is successful in the authentication unit. The encryption unit decrypts the encrypted debug signal acquired from the other secure component when the mutual authentication is successful in the authentication unit.

The secure component of the present embodiment secures the key generation unit that generates the session key between the debug device and the device, and the session key generated by the key generation unit when mutual authentication is successful in the authentication unit. It includes a providing unit provided to the device or the debugging device on which the component is mounted.

The secure component of the present embodiment includes an acquisition unit that acquires user authentication information and a user authentication unit that performs user authentication based on the user authentication information acquired by the acquisition unit, and the user authentication If the user authentication is successful in the department, the debug signal can be sent and received.

The secure component of the present embodiment includes a storage unit that stores confidential information including information related to mutual authentication with the other secure component, and an opening unit that establishes a secret communication path between the external device and the above. The confidential information stored in the storage unit can be updated via the confidential communication path established by the establishment unit.

The secure component of this embodiment is composed of either a secure element, a trusted platform module, or a trusted execution environment.

The debug system of the present embodiment is a debug system including a device having a debug target and a debug device for debugging the debug target, and the device is a device-side secure component provided in the debug device. The debug device includes a device-side secure component having a device-side authentication unit that performs mutual authentication, and the debug device includes a device-side secure component having a device-side authentication unit that performs mutual authentication with the device-side secure component provided in the device. When mutual authentication is successful in each of the device-side authentication unit and the device-side authentication unit, a debug signal is exchanged between the device side and the device side.

In the debugging method of the present embodiment, the device-side secure component mounted on the device having the debug target performs mutual authentication with the device-side secure component mounted on the debug device for debugging the debug target, and the device. The side secure component performs mutual authentication with the device side secure component, and if each of the mutual authentications is successful, a debug signal is exchanged between the device side and the device side.

10 Debug environment management server 11 Confidential communication function 20 Embedded device development PC
21 Debug operation environment 22 PC side debugger 23 Debug probe I / F
25 Debugger-Device I / F
30 Probe 31 PC side debugger I / F
32 Debug I / F
40 Secure component 41 Confidential communication function 42 User authentication function 43 Encryption function 44 Mutual authentication function 45 Authentication permission list 50 Devices 51 Debug I / F
52 PC-CPU / SoC Debug I / F
60 Debug target CPU / SoC
61 Debug target program 62 CPU / SOC debug function 63 Encryption function 64 Key sharing function 70 Secure component 71 Encryption function 72 Mutual authentication function 73 User authentication function 74 Secret communication function 75 Authentication permission list

Claims (20)

A device that has a debug target
It is provided with a device-side secure component provided in the debug device for debugging the debug target and a device-side secure component having an authentication unit for mutual authentication.
The device-side secure component is
If the mutual authentication is successful in the authentication unit, a debug signal is exchanged with the secure component on the device side.
device. The device-side secure component is
The encryption part and
Equipped with a decryption section
The encryption unit
If mutual authentication is successful in the authentication unit, the debug signal sent to the device-side secure component is encrypted.
The decoding unit
If the mutual authentication is successful in the authentication unit, the encrypted debug signal acquired from the device-side secure component is decrypted.
The device according to claim 1. Device encryption unit and
Equipped with a device decryption unit
The device-side secure component is
A key generator that generates a session key between the debug device and the device,
If the mutual authentication is successful in the authentication unit, the device is provided with a provider unit that provides the session key generated by the key generation unit to the device side.
The device encryption unit
Using the session key, the debug signal sent to the debug device is encrypted.
The device decoding unit
The session key is used to decrypt the encrypted debug signal obtained from the debug device.
The device according to claim 1. The device-side secure component is
The acquisition department that acquires user authentication information,
It is equipped with a user authentication unit that authenticates users based on the user authentication information acquired by the acquisition unit.
If the user authentication is successful in the user authentication unit, it is possible to send and receive debug signals.
The device according to any one of claims 1 to 3. The device-side secure component is
A storage unit that stores confidential information including information related to mutual authentication with the device-side secure component, and a storage unit.
It has an opening section that opens a secret communication channel with an external device.
The confidential information stored in the storage unit can be updated via the confidential communication path established by the establishment unit.
The device according to any one of claims 1 to 4. The device-side secure component is configured in a semiconductor chip different from the semiconductor chip having the debug target, and is connected to the semiconductor chip having the debug target via a secret communication path.
The device according to any one of claims 1 to 5. The device-side secure component is configured in the semiconductor chip having the debug target.
The device according to any one of claims 1 to 5. A debugging device for debugging the debug target,
It is provided with a device-side secure component provided in the device having the debug target and a device-side secure component having an authentication unit that performs mutual authentication.
The device-side secure component is
If mutual authentication is successful in the authentication unit, a debug signal is exchanged with the device-side secure component.
Debugging equipment. The device-side secure component is
The encryption part and
Equipped with a decryption section
The encryption unit
If mutual authentication is successful in the authentication unit, the debug signal sent to the device-side secure component is encrypted.
The decoding unit
If the mutual authentication is successful in the authentication unit, the encrypted debug signal acquired from the device-side secure component is decrypted.
The debug device according to claim 8. Debug device encryption part and
Equipped with a debug device decoding unit
The device-side secure component is
A key generator that generates a session key between the device and the debug device,
If the mutual authentication is successful in the authentication unit, the device is provided with a provider unit that provides the session key generated by the key generation unit to the device side.
The debug device encryption unit
The session key is used to encrypt the debug signal sent to the device.
The debug device decoding unit
The session key is used to decrypt the encrypted debug signal obtained from the device.
The debug device according to claim 8. The device-side secure component is
The acquisition department that acquires user authentication information,
It is equipped with a user authentication unit that authenticates users based on the user authentication information acquired by the acquisition unit.
If the user authentication is successful in the user authentication unit, it is possible to send and receive debug signals.
The debug device according to any one of claims 8 to 10. The device-side secure component is
A storage unit that stores confidential information including information related to mutual authentication with the device-side secure component, and a storage unit.
It has an opening section that opens a secret communication channel with an external device.
The confidential information stored in the storage unit can be updated via the confidential communication path established by the establishment unit.
The debug device according to any one of claims 8 to 11. A secure component installed in a device that has a debug target or a debug device for debugging the debug target.
It has an authentication unit that performs mutual authentication with other secure components provided in other debug devices or other devices.
If mutual authentication is successful in the authentication unit, a debug signal is exchanged with the other secure component.
Secure component. The encryption part and
Equipped with a decryption section
The encryption unit
If mutual authentication is successful in the authentication unit, the debug signal sent to the other secure component is encrypted.
The decoding unit
If the mutual authentication is successful in the authentication unit, the encrypted debug signal obtained from the other secure component is decrypted.
The secure component according to claim 13. A key generator that generates a session key between the debug device and the device,
When the mutual authentication is successful in the authentication unit, the session key generated by the key generation unit is provided with a providing unit that provides the device equipped with the secure component or the debugging device.
The secure component according to claim 13. The acquisition department that acquires user authentication information,
It is equipped with a user authentication unit that authenticates users based on the user authentication information acquired by the acquisition unit.
If the user authentication is successful in the user authentication unit, it is possible to send and receive debug signals.
The secure component according to any one of claims 13 to 15. A storage unit that stores confidential information including information related to mutual authentication with the other secure component, and a storage unit.
It has an opening section that opens a secret communication channel with an external device.
The confidential information stored in the storage unit can be updated via the confidential communication path established by the establishment unit.
The secure component according to any one of claims 13 to 16. Consists of either a secure element, a trusted platform module, or a trusted execution environment,
The secure component according to any one of claims 13 to 17. A debugging system equipped with a device having a debugging target and a debugging device for debugging the debugging target.
The device
A device-side secure component having a device-side authentication unit that performs mutual authentication with the device-side secure component provided in the debug device is provided.
The debug device is
A device-side secure component having a device-side authentication unit that performs mutual authentication with the device-side secure component provided in the device is provided.
When mutual authentication is successful in each of the device-side authentication unit and the device-side authentication unit, a debug signal is exchanged between the device side and the device side.
Debug system. The device-side secure component installed in the device to be debugged is
Mutual authentication is performed with the device-side secure component installed in the debug device for debugging the debug target.
The device-side secure component performs mutual authentication with the device-side secure component, and the device-side secure component performs mutual authentication.
If each of the mutual authentications is successful, a debug signal is exchanged between the device side and the device side.
How to debug.

Images