Debugging method and related device
By employing random number generation, encrypted communication, and authentication mechanisms during ECU debugging, the security risks of the ECU debugging interface are resolved, ensuring the security and data integrity of the ECU debugging process.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-09
- Publication Date
- 2026-03-10
AI Technical Summary
In existing technologies, the existence of vehicle ECU debugging interfaces may pose a security risk of ECU code tampering. How can the security of the debugging process be improved?
By generating random numbers, encrypting communication, and employing authentication mechanisms, secure interaction between the target device and the ECU is ensured. This includes using a hardware encryption module to generate random numbers, uploading them from the target device to the encryption device for encryption, and then having the ECU decrypt and verify the target data to open the debugging interface.
It effectively prevents unauthorized access from causing ECU code tampering, ensures data confidentiality and communication integrity during the debugging process, and is suitable for equipment and systems with high security requirements.
Smart Images
Figure CN121637522A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of debugging, in particular to a debugging method and related device. BACKGROUND
[0002] With the increasing complexity and integration of ECU (Electronic Control Unit) functions in vehicles, in order to ensure vehicle performance, after the SOP (Standard Operating Procedure) of the vehicle, the target device needs to be connected to the debugging interface of the vehicle, and the ECU is debugged by the target device.
[0003] Although the debugging interface enables the target device to debug the ECU, the presence of the debugging interface may bring potential safety risks to the ECU, and the ECU code may be tampered with. Therefore, how to provide a debugging method to improve the safety of vehicle debugging has become a technical problem that needs to be solved by those skilled in the art. SUMMARY
[0004] In view of the above problems, the present application provides a debugging method and related device to ensure the security of the target device in the process of debugging the electronic control unit through encryption communication and identity authentication mechanism. The specific scheme is as follows:
[0005] A debugging method applied to an electronic control unit, the debugging method comprising:
[0006] generating a random number when receiving a handshake request sent by a target device;
[0007] sending the random number to the target device;
[0008] obtaining encrypted data returned by the target device, and decrypting the encrypted data to obtain target data;
[0009] opening a debugging interface to the target device if the target data passes the verification.
[0010] Optionally, the generating a random number when receiving a handshake request sent by a target device comprises:
[0011] generating the random number by using a hardware encryption module when receiving the handshake request sent by the target device.
[0012] Optionally, the sending the random number to the target device further comprises:
[0013] sending the random number to the target device, uploading, by the target device, the random number to an encryption device, signing, by the encryption device, the random number using a private key in a hardware asymmetric encryption algorithm to obtain a signature value as the encrypted data;
[0014] Correspondingly, the encrypted data returned by the target device is acquired, and the encrypted data is decrypted to obtain target data, and the method further comprises:
[0015] The signature value returned by the target device is acquired, and the signature value is decrypted using a public key in the hardware asymmetric encryption algorithm to obtain a random number hash value as the target data.
[0016] Optionally, the process of verifying the target data comprises:
[0017] determining a target hash value corresponding to the random number;
[0018] When the random number hash value and the target hash value are consistent, it is determined that the random number hash value passes the correctness verification;
[0019] When the random number hash value and the target hash value are inconsistent, it is determined that the random number hash value fails the correctness verification.
[0020] Optionally, the method further comprises:
[0021] In the case that the target data fails the correctness verification, outputting a connection failure prompt information to the target device.
[0022] A debugging method applied to a target device, the method comprising:
[0023] sending a handshake request to an electronic control unit;
[0024] After receiving a random number sent by the electronic control unit, sending the random number to an encryption device;
[0025] After receiving encrypted data sent by the encryption device, sending the encrypted data to the electronic control unit.
[0026] A debugging device applied to an electronic control unit, the debugging device comprising:
[0027] a random number generation unit configured to generate a random number when receiving a handshake request sent by a target device;
[0028] a random number sending unit configured to send the random number to the target device;
[0029] an encrypted data acquisition unit configured to acquire encrypted data returned by the target device, and decrypt the encrypted data to obtain target data;
[0030] The debugging interface opening unit is configured to open the debugging interface for the target device if the target data is verified.
[0031] A debugging device applied to a target device, the debugging device comprising:
[0032] The request sending unit is configured to send a handshake request to the electronic control unit.
[0033] The random number uploading unit is configured to send the random number to the encryption device after receiving the random number sent by the electronic control unit.
[0034] The encrypted data sending unit is configured to send the encrypted data to the electronic control unit after receiving the encrypted data sent by the encryption device.
[0035] A debugging system comprising an electronic control unit, a target device and an encryption device, the target device being communicatively connected with the electronic control unit and the encryption device respectively.
[0036] The electronic control unit comprises the above-mentioned debugging device.
[0037] The target device comprises the above-mentioned debugging device.
[0038] A computer program product comprising computer readable instructions which, when executed on an electronic control unit, cause the electronic control unit to implement the above-mentioned debugging method.
[0039] An automobile comprising a plurality of electronic control units, each of the electronic control units comprising the above-mentioned debugging device.
[0040] A computer storage medium carrying one or more computer programs which, when executed by an electronic control unit, enable the electronic control unit to implement the above-mentioned debugging method.
[0041] From the above technical solutions, the application provides a debugging method and related device. When the electronic control unit receives the handshake request sent by the target device, the electronic control unit generates a random number and sends the random number to the target device. The electronic control unit obtains the encrypted data returned by the target device and decrypts the encrypted data to obtain target data. In the case that the target data passes the verification, the electronic control unit opens the debugging interface for the target device, so that the target device establishes a connection relationship with the electronic control unit through the debugging interface, and the electronic control unit is debugged by using the debugging interface. The application ensures the security of the target device when interacting with the electronic control unit in the process of debugging the electronic control unit by using the encryption communication and identity authentication mechanism. Therefore, the application not only effectively prevents the potential security risks of the electronic control unit caused by unauthorized access, and the code of the electronic control unit is tampered, but also guarantees the confidentiality and communication integrity of the data in the entire debugging process, and is suitable for various devices and systems that need high security debugging. BRIEF DESCRIPTION OF DRAWINGS
[0042] The above and other features, advantages, and aspects of the present disclosure will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings in which:
[0043] Figure 1 A debugging system architecture schematic diagram is provided for the application;
[0044] Figure 2 An optional hardware structure schematic diagram of an ECU is provided for the application;
[0045] Figure 3 A structure schematic diagram of an encryption device is provided for the application;
[0046] Figure 4 A flowchart of a debugging method is provided for the embodiments of the application;
[0047] Figure 5 A flowchart of another debugging method is provided for the embodiments of the application;
[0048] Figure 6 A flowchart of another debugging method is provided for the embodiments of the application;
[0049] Figure 7 A structure schematic diagram of a debugging device is provided for the embodiments of the application;
[0050] Figure 8 A structure schematic diagram of another debugging device is provided for the embodiments of the application;
[0051] Figure 9This is a schematic diagram of another debugging device provided in an embodiment of this application. Detailed Implementation
[0052] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.
[0053] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.
[0054] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.
[0055] See Figure 1 , Figure 1 A schematic diagram of a debugging system architecture is shown. The system may include an ECU 100, an encryption device 200, and a target device 300, with the target device 300 communicatively connected to both the ECU 100 and the encryption device 200. The encryption device 200 may include one or more servers, and can provide the methods described in this application embodiment to one or more ECUs 100.
[0056] The ECU100 is installed in the vehicle. A third-party system application can be installed on the ECU100. The application and webpage can provide an interface. The ECU100 can receive relevant parameters input by the user on the interface and send the parameters to the encryption device 200 through the target device 300. The encryption device 200 can obtain the processing result based on the received parameters and return the processing result to the ECU100 through the target device 300.
[0057] It should be understood that in some optional implementations, the ECU100 can also complete the action of obtaining the processing result based on the received parameters on its own, without the need for the server to cooperate. This application embodiment is not limited to this.
[0058] The following descriptionFigure 1 The product form of the ECU100;
[0059] Figure 2 A schematic diagram of an optional hardware structure for the ECU100 is shown.
[0060] refer to Figure 2 As shown, the ECU 100 may include components such as a processor 110, a memory 120, an input unit 130, an external interface 140, a power supply 150, and a radio frequency unit 160. Those skilled in the art will understand that... Figure 2 This is merely an example of ECU100 and does not constitute a limitation on ECUs or multifunction devices. It may include more or fewer components than shown, or combine certain components, or use different components.
[0061] The input unit 130 can be used to receive input numeric or character information, and to generate key signal inputs related to user settings and function control of the portable multifunction device. The input unit 130 can also receive and execute commands from the processor 110.
[0062] The memory 120 can be used to store instructions and data. The memory 120 may primarily include an instruction storage area and a data storage area. The data storage area can store various types of data, such as multimedia files and text. The instruction storage area can store software units such as operating systems, applications, and instructions required for at least one function, or subsets or extended sets thereof. It may also include non-volatile random access memory. It provides the processor 110 with hardware, software, and data resources for managing the computing device, supporting control software and applications. It is also used for storing multimedia files, as well as storing running programs and applications.
[0063] The processor 110 is the control center of the ECU 100. It connects various parts of the ECU 100 via various interfaces and lines. By running or executing instructions stored in the memory 120 and calling data stored in the memory 120, it performs various functions of the ECU 100 and processes data, thereby providing overall control of the ECU 100. Optionally, the processor 110 may include one or more processing units; preferably, the processor 110 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 110. In some embodiments, the processor and memory can be implemented on a single chip; in some embodiments, they can also be implemented on separate chips. The processor 110 can also be used to generate corresponding operation control signals, send them to the corresponding components of the computing device, read and process data in the software, especially read and process data and programs in the memory 120, so that the various functional modules therein perform corresponding functions, thereby controlling the corresponding components to act according to the instructions.
[0064] The memory 120 can be used to store software code related to the debugging method, and the processor 110 can execute the steps of the debugging method, or schedule other units (such as the input unit 130 mentioned above) to achieve the corresponding functions.
[0065] In this embodiment of the application, the radio frequency unit 160 can send data to the encryption device 200 through the target device 300, and receive the processing result sent by the encryption device 200 through the target device 300.
[0066] It should be understood that the radio frequency unit 160 is optional and can be replaced with other communication interfaces, such as a network port.
[0067] The ECU 100 also includes a power supply 150 (such as a battery) that supplies power to various components. Preferably, the power supply can be logically connected to the processor 110 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.
[0068] ECU100 also includes an external interface 140, which can be a standard Micro USB interface or a multi-pin connector, which can be used to connect ECU100 to other devices for communication or to connect a charger to charge ECU100.
[0069] The following description Figure 1 The product form of the Zhongxin Encryption Equipment 200;
[0070] Figure 3A schematic diagram of the structure of an encryption device 200 is provided, such as... Figure 3 As shown, the encryption device 200 includes a bus 201, a processor 202, a communication interface 203, and a memory 204. The processor 202, the memory 204, and the communication interface 203 communicate with each other via the bus 201.
[0071] Bus 201 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0072] The processor 202 can be any one or more of the following processors: a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).
[0073] Memory 204 may include volatile memory, such as random access memory (RAM). Memory 204 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).
[0074] The memory 204 can be used to store software code related to the debugging method, and the processor 202 can execute the steps of the chip's debugging method, and can also schedule other units to achieve corresponding functions.
[0075] It should be understood that the ECU 100 and encryption device 200 can be centralized or distributed devices. The processors (e.g., processor 110 and processor 202) in the ECU 100 and encryption device 200 can be hardware circuits (such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), general-purpose processors, digital signal processors (DSPs), microprocessors or microcontrollers, etc.) or combinations of these hardware circuits. For example, the processor can be a hardware system with instruction execution capabilities, such as a CPU or DSP, or a hardware system without instruction execution capabilities, such as an ASIC or FPGA, or a combination of the aforementioned hardware systems without instruction execution capabilities and hardware systems with instruction execution capabilities.
[0076] The debugging method of the embodiments of this application will be described in detail below with reference to the accompanying drawings.
[0077] Reference Figure 4 , Figure 4 This is a flowchart illustrating a debugging method provided in an embodiment of this application. The debugging method is applied to... Figure 1 and Figure 2 The ECU shown can be debugged using the following methods:
[0078] Step S401: When a handshake request is received from the target device, a random number is generated.
[0079] When the target device needs to establish a connection with the ECU's debugging interface, the target device sends a handshake request to the ECU. When the ECU receives the handshake request from the target device, it prioritizes using the Hardware Security Module (HSM) to generate a random number.
[0080] The target device in this application is an ECU tuning device for debugging the ECU in a vehicle, such as HP Tuners. HP Tuners has powerful ECU tuning capabilities, allowing users to read, edit, and write programs into the ECU, thereby enabling customization and optimization of vehicle performance.
[0081] Hardware encryption modules can employ specialized hardware design and encryption technology to provide high-strength encryption, digital signatures, key management and other security functions, aiming to protect the security of keys and sensitive data stored therein.
[0082] This embodiment prioritizes the use of a hardware encryption module to generate random numbers, thereby ensuring the unpredictability and security of the random numbers and improving the security of debugging.
[0083] In practical applications, the random numbers generated in this application are preferably true random numbers. True random numbers refer to completely unpredictable sequences of numbers without a fixed pattern. Compared to pseudo-random numbers, true random numbers have a high degree of unpredictability, which can significantly improve system security and prevent attackers from damaging the system by predicting random number sequences.
[0084] Step S402: Send the random number to the target device.
[0085] In this embodiment, after receiving the random number sent by the ECU, the target device does not directly encrypt the random number, but uploads it to the encryption device, which then encrypts the random number to obtain encrypted data. The encryption device then sends the encrypted data to the target device.
[0086] Using encryption devices to encrypt random numbers, instead of having the target device directly encrypt the random numbers, can greatly reduce the amount of data processing required by the target device and ensure the speed of ECU debugging.
[0087] The encryption device can exist in the form of a server, such as a backend server responsible for encrypting data.
[0088] Step S403: Obtain the encrypted data returned by the target device, and decrypt the encrypted data to obtain the target data.
[0089] In practical applications, the ECU stores a preset decryption algorithm corresponding to the preset encryption algorithm in the encryption device, which can decrypt the encrypted data returned by the target device to obtain the target data.
[0090] It should be noted that in practical applications, when encrypting random numbers, the encryption device may adjust the data structure of the random numbers. Therefore, when the ECU decrypts the encrypted data using a preset decryption algorithm, the target data obtained may not be a random number, but rather the data corresponding to the random number.
[0091] Step S404: If the target data passes verification, open the debugging interface to the target device.
[0092] If the target data is verified, the target device is determined to be authenticated. A connection is established with the target device by opening a debugging interface, so that the target device can use the debugging interface to debug the ECU.
[0093] This application authenticates the target device by verifying the correctness of the target data, thereby ensuring the security of the target device when interacting with the ECU.
[0094] In summary, this invention discloses a debugging method applied to an ECU. Upon receiving a handshake request from a target device, the ECU generates a random number and sends it to the target device. It then obtains encrypted data returned by the target device, decrypts the encrypted data to obtain the target data, and, if the target data passes verification, opens a debugging interface to the target device. This allows the target device to establish a connection with the ECU through the debugging interface and debug the ECU. This invention, through encrypted communication and authentication mechanisms, ensures the security of the interaction between the target device and the ECU during debugging. This effectively prevents potential security risks to the ECU due to unauthorized access, such as ECU code tampering, and also guarantees data confidentiality and communication integrity throughout the debugging process. Therefore, it is applicable to various devices and systems requiring high-security debugging.
[0095] In practical applications, the encryption device can use a hardware asymmetric encryption algorithm to encrypt random numbers, ensuring that the encrypted data is verified by the ECU before the target device can perform debugging operations on the ECU.
[0096] Hardware asymmetric encryption algorithms, also known as public-key encryption algorithms, use a pair of keys for encrypting and decrypting data. These keys are a public key and a private key. The public key is public and can be obtained and used by anyone to encrypt data; the private key is kept secret and can only be used by the key owner to decrypt data. The advantage of this encryption method is that even if someone else obtains the public key, they cannot deduce the private key from it, thus ensuring the security of the encrypted information.
[0097] Common hardware asymmetric encryption algorithms include RSA and ECC (Elliptic Curve Cryptography).
[0098] RSA algorithm: Proposed by Ron Rivest, Adi Shamir, and Leonard Adleman in 1977, it is one of the most widely used asymmetric encryption algorithms. The security of RSA algorithm is based on the difficulty of factoring large numbers. Its encryption and decryption processes involve relatively complex mathematical operations, thus incurring a certain computational overhead while ensuring security.
[0099] ECC algorithm: It is an emerging asymmetric encryption algorithm. Compared with RSA algorithm, ECC can use a shorter key at the same security level, thereby reducing the computation and storage space requirements.
[0100] Therefore, to further optimize the above embodiment, step S402 further includes:
[0101] The random number is sent to the target device, and the target device uploads the random number to the encryption device for signing using the private key in the hardware asymmetric encryption algorithm to obtain the signature value as the encrypted data.
[0102] Correspondingly, step S403 also includes:
[0103] Obtain the signature value returned by the target device, and use the public key in the hardware asymmetric encryption algorithm to decrypt the signature value to obtain a random number hash value as the target data.
[0104] Specifically, the ECU uploads a random number to the encryption device via the target device. The encryption device signs the random number using the private key in a hardware asymmetric encryption algorithm, obtaining a corresponding signature value, which is the encrypted data. The encryption device sends this signature value to the target device, which then sends it back to the ECU. The ECU stores the private key corresponding to the private key in the encryption device. Therefore, after receiving the signature value from the target device, the ECU can decrypt the signature value using the public key in a hardware asymmetric encryption algorithm, obtaining a hash value of the random number, which is the decrypted target data.
[0105] In practical applications, different public-private key pairs can be set in the ECU and encryption device according to different ECU types. To ensure the integrity of the public key in the ECU, the pre-set public key in each ECU can be stored in the hardware encryption module.
[0106] To further optimize the above embodiments, the process of the ECU verifying the correctness of the target data also includes:
[0107] Determine the target hash value corresponding to the random number;
[0108] When the random number hash value and the target hash value are consistent, the random number hash value is determined to have passed the correctness verification.
[0109] When the random number hash value and the target hash value are inconsistent, it is determined that the random number hash value has failed the correctness verification.
[0110] Hash value calculation is the process of converting an input of arbitrary length (also called a message) into a fixed-length output (also called a hash value, digest) using a hash algorithm. In this embodiment, a random number is converted into a fixed-length output using a hash algorithm to obtain the corresponding target hash value.
[0111] After the ECU decrypts the signature value returned by the target device using the public key in the hardware asymmetric encryption algorithm to obtain a random number hash value, it performs identity authentication on the target device by verifying the correctness of the random number hash value. The ECU calculates the corresponding target hash value by using a hash algorithm on the random number sent to the target device. By comparing the consistency between the decrypted random number hash value and the target hash value calculated on the random number, it determines whether the random number hash value has passed the correctness verification.
[0112] When the random hash value and the target hash value are consistent, the random hash value is determined to have passed the correctness verification, thus confirming that the target device has passed authentication. At this time, the ECU establishes a connection with the target device through the debugging interface, allowing the target device to debug the ECU using the debugging interface. Conversely, when the random hash value and the target hash value are inconsistent, the random hash value is determined to have failed the correctness verification, thus confirming that the target device has failed authentication. The ECU does not establish a connection with the target device through the debugging interface, but instead outputs a connection failure message to the target device.
[0113] To further optimize the above embodiments, the debugging method may further include:
[0114] If the target data fails the correctness verification, a connection failure message is output to the target device.
[0115] Corresponding to the above embodiments, this application also provides another debugging method.
[0116] See Figure 5 , Figure 5 This is a flowchart illustrating another debugging method disclosed in an embodiment of this application. The debugging method is applied to... Figure 1 The target device shown includes the following debugging methods:
[0117] Step S501: Send a handshake request to the ECU.
[0118] When the target device needs to establish a connection with the ECU's debugging interface, the target device sends a handshake request to the ECU.
[0119] Step S502: After receiving the random number sent by the electronic control unit, send the random number to the encryption device.
[0120] In this embodiment, when the ECU receives a handshake request from the target device, the ECU prioritizes using the hardware encryption module to generate a random number and sends the random number to the target device. After receiving the random number sent by the ECU, the target device does not directly encrypt the random number, but uploads it to the encryption device, which then encrypts the random number to obtain encrypted data.
[0121] Using encryption devices to encrypt random numbers, instead of having the target device directly encrypt the random numbers, can greatly reduce the amount of data processing required by the target device and ensure the speed of ECU debugging.
[0122] Step S503: After receiving the encrypted data sent by the encryption device, send the encrypted data to the electronic control unit.
[0123] The encryption device sends the encrypted data to the target device, which then sends the encrypted data back to the ECU for decryption to obtain the target data.
[0124] In practical applications, the ECU stores a preset decryption algorithm corresponding to the preset encryption algorithm in the encryption device, which can decrypt the encrypted data returned by the target device to obtain the target data.
[0125] It should be noted that in practical applications, when encrypting random numbers, the encryption device may adjust the data structure of the random numbers. Therefore, when the ECU decrypts the encrypted data using a preset decryption algorithm, the target data obtained may not be a random number, but rather the data corresponding to the random number.
[0126] In practical applications, if the ECU determines that the target data has passed the correctness verification, it determines that the target device has passed the identity authentication and establishes a connection with the ECU's debugging interface so as to use the debugging interface to debug the ECU.
[0127] After receiving the target data from the target device, the ECU verifies the correctness of the target data to determine the target device's identity. If the ECU determines that the target data passes the correctness verification, the target device is considered successfully authenticated. At this point, the ECU connects to the target device through a debugging interface, allowing the target device to debug the ECU using this interface.
[0128] In summary, this invention discloses a debugging method applied to a target device. The target device sends a handshake request to the ECU. After receiving a random number from the ECU, it sends the random number to an encryption device. After receiving encrypted data from the encryption device, it sends the encrypted data back to the ECU, allowing the ECU to authenticate the target device based on the encrypted data. This invention, through encrypted communication and authentication mechanisms, ensures the security of the target device's interaction with the ECU during debugging. This effectively prevents potential security risks to the ECU due to unauthorized access, such as ECU code tampering, and also guarantees data confidentiality and communication integrity throughout the debugging process. Therefore, it is applicable to various devices and systems requiring high-security debugging.
[0129] To further optimize the above embodiments, this application also provides another debugging method.
[0130] See Figure 6 , Figure 6 This is a flowchart illustrating another debugging method disclosed in an embodiment of this application. The debugging method is applied to... Figure 1 and Figure 3 The encryption device shown includes the following debugging methods:
[0131] Step S601: Obtain the random number uploaded by the target device.
[0132] The random number is generated by the ECU when it receives a handshake request from the target device and then sends it to the target device.
[0133] Specifically, when the target device needs to establish a connection with the ECU's debugging interface, the target device sends a handshake request to the ECU. When the ECU receives the handshake request from the target device, it first uses a hardware encryption module to generate a random number and sends the random number to the target device, which then uploads the random number to the encryption device.
[0134] Step S602: Encrypt the random number to obtain encrypted data.
[0135] After receiving a random number, the encryption device uses a preset encryption algorithm to encrypt the random number to obtain encrypted data.
[0136] In practical applications, the encryption device can use a hardware asymmetric encryption algorithm to encrypt random numbers, ensuring that the encrypted data is verified by the ECU before the target device can perform debugging operations on the ECU.
[0137] Step S603: The encrypted data is transmitted back to the ECU through the target device. The ECU uses the encrypted data to verify the target device and opens the debugging interface to the target device if the target device passes the verification.
[0138] The ECU stores a preset decryption algorithm corresponding to the preset encryption algorithm in the encryption device, allowing it to decrypt the encrypted data returned by the target device to obtain the target data. It should be noted that in practical applications, the encryption device may adjust the data structure of the random number when encrypting it. Therefore, the target data obtained by the ECU when decrypting the encrypted data using the preset decryption algorithm may not be a random number, but rather the data corresponding to the random number.
[0139] After receiving the target data from the target device, the ECU verifies the correctness of the target data to determine the target device's identity. If the ECU determines that the target data passes the correctness verification, the target device is considered successfully authenticated. At this point, the ECU connects to the target device through a debugging interface, allowing the target device to debug the ECU using this interface.
[0140] It should be noted that the specific process of the encryption device encrypting the random number, and the process of the ECU decrypting the target data obtained by the encryption device, can be found in the corresponding parts of the above embodiments, and will not be repeated here.
[0141] In summary, this invention discloses a debugging method applied to an encrypted device. The encrypted device obtains a random number uploaded by the target device. This random number is generated by the ECU when it receives a handshake request from the target device and sent to the target device. The encrypted device encrypts the random number to obtain encrypted data and sends the encrypted data back to the ECU through the target device. The ECU uses the encrypted data to verify the target device. If the target device passes the verification, the ECU opens a debugging interface to the target device, allowing the target device to establish a connection with the ECU through the debugging interface and debug the ECU. This invention ensures the security of the target device's interaction with the ECU during the debugging process through encrypted communication and authentication mechanisms. This not only effectively prevents potential security risks to the ECU caused by unauthorized access and the possibility of ECU code tampering, but also guarantees the confidentiality of data and the integrity of communication throughout the debugging process. Therefore, it is applicable to various devices and systems requiring high-security debugging.
[0142] To facilitate understanding of the specific interaction process between the ECU, encryption device, and target device when debugging the ECU in a vehicle, the following section combines... Figure 1The connection relationships between the ECU, encryption device, and target device are shown below, along with a detailed explanation of the debugging process:
[0143] The target device sends a handshake request to the ECU;
[0144] After receiving the handshake request, the ECU generates a random number and sends the random number to the target device;
[0145] The target device uploads the random number to the encrypted device;
[0146] The encryption device encrypts the random number to obtain encrypted data, and then sends the encrypted data back to the ECU through the target device;
[0147] The ECU decrypts the encrypted data to obtain the target data, verifies the target data to authenticate the target device, and determines that the target device has passed the authentication if the target device passes the verification, and opens the debugging interface to the target device.
[0148] The target device establishes a connection with the ECU through a debugging interface and uses this debugging interface to debug the ECU.
[0149] In summary, this invention, through encrypted communication and identity authentication mechanisms, ensures the security of the target device during the debugging process of the electronic control unit and the interaction with the electronic control unit. This not only effectively prevents potential security risks to the electronic control unit caused by unauthorized access and the possibility of the electronic control unit code being tampered with, but also guarantees the confidentiality of data and the integrity of communication throughout the debugging process. Therefore, it is applicable to various devices and systems that require high-security debugging.
[0150] The above describes a debugging method provided by an embodiment of this application. The following will describe the apparatus for performing the above debugging method.
[0151] Please see Figure 7 , Figure 7 This is a schematic diagram of a debugging device provided in an embodiment of this application. The debugging device is applied to... Figure 1 and Figure 2 The ECU shown, the debugging device includes:
[0152] The random number generation unit 701 is used to generate random numbers when a handshake request is received from the target device.
[0153] When the target device needs to establish a connection with the ECU's debugging interface, the target device sends a handshake request to the ECU. When the ECU receives the handshake request from the target device, it prioritizes using the hardware encryption module to generate a random number.
[0154] The hardware encryption module employs specialized hardware design and encryption technology, providing high-strength encryption, digital signatures, key management and other security functions, aiming to protect the security of keys and sensitive data stored within it.
[0155] This embodiment prioritizes the use of a hardware encryption module to generate random numbers, thereby ensuring the unpredictability and security of the random numbers and improving the security of debugging.
[0156] Therefore, the random number generation unit 701 is also used for:
[0157] When the handshake request sent by the target device is received, the random number is generated using a hardware encryption module.
[0158] The random number sending unit 702 is used to send the random number to the target device.
[0159] In this embodiment, after receiving the random number sent by the ECU, the target device does not directly encrypt the random number, but uploads it to the encryption device, which then encrypts the random number to obtain encrypted data. The encryption device then sends the encrypted data to the target device.
[0160] Using encryption devices to encrypt random numbers, instead of having the target device directly encrypt the random numbers, can greatly reduce the amount of data processing required by the target device and ensure the speed of ECU debugging.
[0161] The encrypted data acquisition unit 703 is used to acquire the encrypted data returned by the target device and decrypt the encrypted data to obtain the target data.
[0162] In practical applications, the ECU stores a preset decryption algorithm corresponding to the preset encryption algorithm in the encryption device, which can decrypt the encrypted data returned by the target device to obtain the target data.
[0163] It should be noted that in practical applications, when encrypting random numbers, the encryption device may adjust the data structure of the random numbers. Therefore, when the ECU decrypts the encrypted data using a preset decryption algorithm, the target data obtained may not be a random number, but rather the data corresponding to the random number.
[0164] The debugging interface opening unit 704 is used to open the debugging interface to the target device when the target data passes verification.
[0165] If the target data is verified, the target device is determined to be authenticated. A connection is established with the target device by opening a debugging interface, so that the target device can use the debugging interface to debug the ECU.
[0166] This application authenticates the target device by verifying the correctness of the target data, thereby ensuring the security of the target device when interacting with the ECU.
[0167] In summary, this invention discloses a debugging device applied to an ECU. Upon receiving a handshake request from a target device, the ECU generates a random number and sends it to the target device. It then obtains encrypted data returned by the target device, decrypts the encrypted data to obtain the target data, and, if the target data passes verification, opens a debugging interface to the target device. This allows the target device to establish a connection with the ECU through the debugging interface and debug the ECU. This invention, through encrypted communication and authentication mechanisms, ensures the security of the interaction between the target device and the ECU during debugging. This effectively prevents potential security risks to the ECU due to unauthorized access, such as ECU code tampering, and also guarantees data confidentiality and communication integrity throughout the debugging process. Therefore, it is suitable for various devices and systems requiring high-security debugging.
[0168] In practical applications, the encryption device can use a hardware asymmetric encryption algorithm to encrypt random numbers, ensuring that the encrypted data is verified by the ECU before the target device can perform debugging operations on the ECU.
[0169] Hardware asymmetric encryption algorithms, also known as public-key encryption algorithms, use a pair of keys for encrypting and decrypting data. These keys are a public key and a private key. The public key is public and can be obtained and used by anyone to encrypt data; the private key is kept secret and can only be used by the key owner to decrypt data. The advantage of this encryption method is that even if someone else obtains the public key, they cannot deduce the private key from it, thus ensuring the security of the encrypted information.
[0170] Common hardware asymmetric encryption algorithms include RSA and ECC (Elliptic Curve Cryptography).
[0171] Therefore, to further optimize the above embodiments, the random number sending unit 702 is also used for:
[0172] The random number is sent to the target device, and the target device uploads the random number to the encryption device for signing using the private key in the hardware asymmetric encryption algorithm to obtain the signature value as the encrypted data.
[0173] Correspondingly, the encrypted data acquisition unit 703 is also used for:
[0174] Obtain the signature value returned by the target device, and use the public key in the hardware asymmetric encryption algorithm to decrypt the signature value to obtain a random number hash value as the target data.
[0175] Specifically, the ECU uploads a random number to the encryption device via the target device. The encryption device signs the random number using the private key in a hardware asymmetric encryption algorithm, obtaining a corresponding signature value, which is the encrypted data. The encryption device sends this signature value to the target device, which then sends it back to the ECU. The ECU stores the private key corresponding to the private key in the encryption device. Therefore, after receiving the signature value from the target device, the ECU can decrypt the signature value using the public key in a hardware asymmetric encryption algorithm, obtaining a hash value of the random number, which is the decrypted target data.
[0176] In practical applications, different public-private key pairs can be set in the ECU and encryption device according to different ECU types. To ensure the integrity of the public key in the ECU, the pre-set public key in each ECU can be stored in the hardware encryption module.
[0177] To further optimize the above embodiments, the debugging device may further include:
[0178] A correctness verification unit is used to verify the correctness of the target data.
[0179] The correctness verification unit is also used for:
[0180] Determine the target hash value corresponding to the random number;
[0181] When the random number hash value and the target hash value are consistent, the random number hash value is determined to have passed the correctness verification.
[0182] When the random number hash value and the target hash value are inconsistent, it is determined that the random number hash value has failed the correctness verification.
[0183] After the ECU decrypts the signature value returned by the target device using the public key in the hardware asymmetric encryption algorithm to obtain a random number hash value, it performs identity authentication on the target device by verifying the correctness of the random number hash value. The ECU calculates the corresponding target hash value by using a hash algorithm on the random number sent to the target device. By comparing the consistency between the decrypted random number hash value and the target hash value calculated on the random number, it determines whether the random number hash value has passed the correctness verification.
[0184] When the random hash value and the target hash value are consistent, the random hash value is determined to have passed the correctness verification, thus confirming that the target device has passed authentication. At this time, the ECU establishes a connection with the target device through the debugging interface, allowing the target device to debug the ECU using the debugging interface. Conversely, when the random hash value and the target hash value are inconsistent, the random hash value is determined to have failed the correctness verification, thus confirming that the target device has failed authentication. The ECU does not establish a connection with the target device through the debugging interface, but instead outputs a connection failure message to the target device.
[0185] To further optimize the above embodiments, the debugging device may further include:
[0186] The prompt message output unit is used to output a connection failure prompt message to the target device when the target data fails the correctness verification.
[0187] Corresponding to the above embodiments, this application also provides another debugging device.
[0188] Please see Figure 8 , Figure 8 This is a schematic diagram of a debugging device provided in an embodiment of this application. The debugging device is applied to... Figure 1 The target device shown, the debugging apparatus includes:
[0189] The request sending unit 801 is used to send a handshake request to the ECU.
[0190] When the target device needs to establish a connection with the ECU's debugging interface, the target device sends a handshake request to the ECU.
[0191] The random number uploading unit 802 is used to send the random number to the encryption device after receiving the random number sent by the electronic control unit.
[0192] In this embodiment, when the ECU receives a handshake request from the target device, the ECU prioritizes using the hardware encryption module to generate a random number and sends the random number to the target device. After receiving the random number sent by the ECU, the target device does not directly encrypt the random number, but uploads it to the encryption device, which then encrypts the random number to obtain encrypted data.
[0193] Using encryption devices to encrypt random numbers, instead of having the target device directly encrypt the random numbers, can greatly reduce the amount of data processing required by the target device and ensure the speed of ECU debugging.
[0194] The encrypted data sending unit 803 is used to send the encrypted data to the electronic control unit after receiving the encrypted data sent by the encryption device.
[0195] The encryption device sends the encrypted data to the target device, which then sends the encrypted data back to the ECU for decryption to obtain the target data.
[0196] In practical applications, the ECU stores a preset decryption algorithm corresponding to the preset encryption algorithm in the encryption device, which can decrypt the encrypted data returned by the target device to obtain the target data.
[0197] It should be noted that in practical applications, when encrypting random numbers, the encryption device may adjust the data structure of the random numbers. Therefore, when the ECU decrypts the encrypted data using a preset decryption algorithm, the target data obtained may not be a random number, but rather the data corresponding to the random number.
[0198] In practical applications, if the ECU determines that the target data has passed the correctness verification, it determines that the target device has passed the identity authentication and establishes a connection with the ECU's debugging interface so as to use the debugging interface to debug the ECU.
[0199] After receiving the target data from the target device, the ECU verifies the correctness of the target data to determine the target device's identity. If the ECU determines that the target data passes the correctness verification, the target device is considered successfully authenticated. At this point, the ECU connects to the target device through a debugging interface, allowing the target device to debug the ECU using this interface.
[0200] In summary, this invention discloses a debugging device applied to a target device. The target device sends a handshake request to the ECU. After receiving a random number from the ECU, it sends the random number to an encryption device. After receiving encrypted data from the encryption device, it sends the encrypted data back to the ECU, allowing the ECU to authenticate the target device based on the encrypted data. This invention, through encrypted communication and authentication mechanisms, ensures the security of the target device's interaction with the ECU during debugging. This effectively prevents potential security risks to the ECU due to unauthorized access, such as ECU code tampering, and also guarantees data confidentiality and communication integrity throughout the debugging process. Therefore, it is applicable to various devices and systems requiring high-security debugging.
[0201] Corresponding to the above embodiments, this application also provides another debugging device.
[0202] Please see Figure 9 , Figure 9 This is a schematic diagram of a debugging device provided in an embodiment of this application. The debugging device is applied to... Figure 1 and Figure 3The encryption device shown includes a debugging apparatus comprising:
[0203] The random number acquisition unit 901 is used to acquire random numbers uploaded by the target device.
[0204] The random number is generated by the ECU when it receives a handshake request from the target device and then sends it to the target device.
[0205] Specifically, when the target device needs to establish a connection with the ECU's debugging interface, the target device sends a handshake request to the ECU. When the ECU receives the handshake request from the target device, it first uses a hardware encryption module to generate a random number and sends the random number to the target device, which then uploads the random number to the encryption device.
[0206] The encryption unit 902 is used to encrypt the random number to obtain encrypted data.
[0207] After receiving a random number, the encryption device uses a preset encryption algorithm to encrypt the random number to obtain encrypted data.
[0208] In practical applications, the encryption device can use a hardware asymmetric encryption algorithm to encrypt random numbers, ensuring that the encrypted data is verified by the ECU before the target device can perform debugging operations on the ECU.
[0209] The data return unit 903 is used to return the encrypted data to the ECU through the target device, and the ECU uses the encrypted data to verify the target device, and opens the debugging interface to the target device if the target device passes the verification.
[0210] The ECU stores a preset decryption algorithm corresponding to the preset encryption algorithm in the encryption device, allowing it to decrypt the encrypted data returned by the target device to obtain the target data. It should be noted that in practical applications, the encryption device may adjust the data structure of the random number when encrypting it. Therefore, the target data obtained by the ECU when decrypting the encrypted data using the preset decryption algorithm may not be a random number, but rather the data corresponding to the random number.
[0211] After receiving the target data from the target device, the ECU verifies the correctness of the target data to determine the target device's identity. If the ECU determines that the target data passes the correctness verification, the target device is considered successfully authenticated. At this point, the ECU connects to the target device through a debugging interface, allowing the target device to debug the ECU using this interface.
[0212] It should be noted that the specific process of the encryption device encrypting the random number, and the process of the ECU decrypting the target data obtained by the encryption device, can be found in the corresponding parts of the above embodiments, and will not be repeated here.
[0213] In summary, this invention discloses a debugging device applied to an encryption device. The encryption device acquires a random number uploaded by the target device. This random number is generated and sent to the target device by the ECU upon receiving a handshake request from the target device. The encryption device encrypts the random number to obtain encrypted data and sends the encrypted data back to the ECU via the target device. The ECU uses the encrypted data to verify the target device. If the target device passes verification, the ECU opens a debugging interface to the target device, allowing the target device to establish a connection with the ECU and debug the ECU using the debugging interface. This invention ensures the security of the target device's interaction with the ECU during debugging through encrypted communication and authentication mechanisms. This effectively prevents potential security risks to the ECU due to unauthorized access, such as ECU code tampering, and also guarantees data confidentiality and communication integrity throughout the debugging process. Therefore, it is applicable to various devices and systems requiring high-security debugging.
[0214] Corresponding to the above embodiments, the present invention also provides a debugging system. See details. Figure 1 The debugging system includes: ECU100, encryption device 200 and target device 300. Target device 300 is communicatively connected to ECU100 and encryption device 200 respectively.
[0215] Among them, ECU100 includes Figure 7 The debugging device in the illustrated embodiment.
[0216] Target equipment 300 includes Figure 8 The debugging device in the illustrated embodiment.
[0217] Encryption device 200 includes Figure 9 The debugging device in the illustrated embodiment.
[0218] For details on the specific working principle of the debugging system, please refer to the corresponding section of the above embodiments, which will not be repeated here.
[0219] Corresponding to the above embodiments, the present invention also discloses a vehicle, which includes a plurality of ECUs, each ECU including Figure 7 The debugging device in the illustrated embodiment. For the specific working principle of each ECU, please refer to the corresponding section of the above embodiment; it will not be repeated here.
[0220] This application also provides a computer program product including computer-readable instructions, which, when executed on an ECU, cause the ECU to implement any of the debugging methods provided in this application.
[0221] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an ECU, the ECU can implement any of the debugging methods provided in this application.
[0222] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.
[0223] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0224] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.
[0225] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line, DSL) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs (Digital Versatile Discs)), or semiconductor media (e.g., solid-state drives (SSDs)).
Claims
1. A debugging method characterized by, The debugging method applied to an electronic control unit comprises: generating a random number when receiving a handshake request sent by a target device; sending the random number to the target device; obtaining encrypted data returned by the target device and decrypting the encrypted data to obtain target data; opening a debugging interface for the target device if the target data passes verification.
2. The commissioning method of claim 1, wherein, The generating of the random number when receiving the handshake request sent by the target device comprises: generating the random number by using a hardware encryption module when receiving the handshake request sent by the target device.
3. The commissioning method of claim 1, wherein, The sending of the random number to the target device further comprises: sending the random number to the target device, and uploading the random number to an encryption device by the target device to obtain a signature value as the encrypted data by using a private key in a hardware asymmetric encryption algorithm; correspondingly, the obtaining of the encrypted data returned by the target device and the decrypting of the encrypted data to obtain the target data further comprises: obtaining the signature value returned by the target device and decrypting the signature value by using a public key in the hardware asymmetric encryption algorithm to obtain a random number hash value as the target data.
4. The commissioning method of claim 3, wherein, The verification of the target data comprises: determining a target hash value corresponding to the random number; determining that the random number hash value passes correctness verification when the random number hash value is consistent with the target hash value; determining that the random number hash value does not pass correctness verification when the random number hash value is inconsistent with the target hash value.
5. The commissioning method of any one of claims 1-4, wherein, The method further comprises: outputting a connection failure prompt information to the target device if the target data does not pass correctness verification.
6. A debugging method characterized by, The method applied to the target device comprises: sending a handshake request to an electronic control unit; sending the random number to an encryption device after receiving the random number sent by the electronic control unit; sending the encrypted data to the electronic control unit after receiving the encrypted data sent by the encryption device.
7. A debugging apparatus characterized by comprising: The debugging device applied to the electronic control unit comprises: a random number generation unit configured to generate a random number when receiving a handshake request sent by a target device; a random number sending unit configured to send the random number to the target device; an encrypted data obtaining unit configured to obtain encrypted data returned by the target device and decrypt the encrypted data to obtain target data; a debugging interface opening unit configured to open a debugging interface for the target device if the target data passes verification.
8. A debugging apparatus characterized by comprising: The debugging device applied to the target device comprises: a request sending unit configured to send a handshake request to an electronic control unit; a random number uploading unit configured to send the random number to an encryption device after receiving the random number sent by the electronic control unit; an encrypted data sending unit configured to send the encrypted data to the electronic control unit after receiving the encrypted data sent by the encryption device.
9. A system for debugging, characterized by The debugging device comprises: an electronic control unit, a target device and an encryption device, the target device being communicatively connected with the electronic control unit and the encryption device respectively. The electronic control unit comprises the commissioning device of claim 7. The target device comprises the commissioning device of claim 8.
10. A computer program product, characterised in that, Computer readable instructions are included, which, when run on an electronic control unit, cause the electronic control unit to implement the commissioning method of any one of claims 1 to 5.
11. An automobile characterized by comprising: A plurality of electronic control units are included, each of which comprises the commissioning device of claim 7.
12. A computer storage medium, characterized in that The storage medium carries one or more computer programs, which, when executed by an electronic control unit, can cause the electronic control unit to implement the commissioning method of any one of claims 1 to 5.