Multi-core chip, vehicle diagnosis method and vehicle diagnosis instrument

Abstract

The invention relates to the technical field of vehicle diagnosis, and discloses a multi-core chip, a vehicle diagnosis method and a vehicle diagnostic agent.The multi-core chip comprises a first kernel, a second kernel and a third kernel, the first kernel is used for establishing encrypted communication connection with a mobile terminal, and the second kernel is used for establishing encrypted communication connection with the mobile terminal; receiving a configuration data packet required by vehicle diagnosis from the mobile terminal; the second kernel is used for sending a diagnosis instruction to the vehicle-mounted control unit based on the configuration data packet, collecting diagnosis data as diagnosed information, and returning the diagnosed information to the mobile terminal through the first kernel; and the third kernel is used for establishing a bidirectional encryption channel between the first kernel and the second kernel by using the first communication key distributed to the first kernel and the second communication key distributed to the second kernel. The safety, the integration level and the communication efficiency of the vehicle diagnosis system are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicle diagnosis, and in particular to a multi-core chip, a vehicle diagnosis method and a vehicle diagnosis instrument. BACKGROUND

[0002] With the rapid development of automotive electronics technology, the on-board diagnostic system has become a standard configuration of modern vehicles, which is used for monitoring vehicle status, reading fault codes and performing remote diagnosis and the like. The existing vehicle diagnosis connector generally adopts wireless communication technology to realize connection with external devices, and the Bluetooth technology is widely used due to its low power consumption, high compatibility and the like. In the traditional implementation scheme, the diagnosis connector adopts a double-chip architecture of "Bluetooth chip + special microcontroller unit": the Bluetooth module is responsible for the wireless communication function, and the special microcontroller unit processes the analysis and execution of the vehicle diagnosis protocol.

[0003] Under this architecture, the Bluetooth module completes the reception of diagnosis instructions and the return of response data by interacting with the diagnosis microcontroller unit through a serial interface such as UART or SPI. However, this double-chip design requires independent communication chips and processor chips to work together, which not only increases the hardware material cost, but also leads to an increase in the layout space requirement of the circuit board. At the same time, since there is no encryption protection mechanism for data transmission between the Bluetooth module and the diagnosis microcontroller unit, the serial port communication data can be intercepted through physical contact or wireless sniffing means, and there is a security risk of diagnosis information leakage or malicious tampering of instructions. SUMMARY

[0004] Therefore, the embodiments of the present application provide a multi-core chip, a vehicle diagnosis method and a vehicle diagnosis instrument, which can effectively solve the problems in the prior art that the vehicle diagnosis connector adopts a double-chip architecture of Bluetooth chip and special microcontroller unit, resulting in high hardware material cost, large space requirement, and security risks such as diagnosis information leakage or malicious tampering of instructions.

[0005] In a first aspect, the embodiments of the present application provide a multi-core chip, comprising: a first core, configured to establish an encrypted communication connection with a mobile terminal, and receive a configuration data packet required for vehicle diagnosis from the mobile terminal; a second core, configured to send a diagnosis instruction to a vehicle control unit based on the configuration data packet, collect diagnosis data as post-diagnosis information, and return the post-diagnosis information to the mobile terminal through the first core; a third core, configured to establish a bidirectional encrypted channel between the first core and the second core by using a first communication key allocated to the first core and a second communication key allocated to the second core.

[0006] In some embodiments, the multi-core chip further comprises: a first storage module, configured to store the first communication key and the second communication key; a second storage module, configured to store non-encrypted operation data and a user operation log. In some embodiments, the first storage module is a one-time programmable storage area or a fuse array. In some embodiments, the third core is further configured to randomly generate a first root key and a second root key with a preset number of bits, generate the first communication key based on an identifier of the first core and the first root key, and generate the second communication key based on an identifier of the second core and the second root key. In a second aspect, embodiments of the present application provide a vehicle diagnosis method applied to at least one multi-core chip as described in the first aspect, and the method comprises: the first core establishes an encrypted communication connection with the mobile terminal and receives the configuration data packet from the mobile terminal; the first core encapsulates and encrypts the configuration data packet, and transmits the encrypted configuration data packet to the second core through the bidirectional encrypted channel established by the third core; the second core decrypts and verifies the received encrypted configuration data packet, and if the verification is passed, obtains corresponding diagnosis control information according to the decrypted configuration data packet; the second core sends the diagnosis control information to the vehicle control unit and collects returned diagnosis data as post-diagnosis information; the second core encapsulates and encrypts the post-diagnosis information, generates an encrypted diagnosis result, and returns to the first core via the bidirectional encrypted channel; the first core decrypts and verifies the encrypted diagnosis result, and forwards it to the mobile terminal after confirming that it is correct.

[0007] In some embodiments, after the second core decrypts and verifies the received encrypted configuration data packet, before the second core sends the diagnosis control information to the vehicle control unit, the vehicle diagnosis method further comprises: the second core generates corresponding vehicle adjustment instructions according to the configuration data packet, adjusts the parameters of the vehicle control unit, sends a diagnosis request to the vehicle control unit after adjustment, and automatically matches the corresponding vehicle communication protocol according to the configuration data packet.

[0008] In some embodiments, the first core establishing an encrypted communication connection with the mobile terminal comprises: The first core completes device discovery and pairing with the mobile terminal by running a Bluetooth protocol, establishes a Bluetooth communication link between the first core and the mobile terminal, and encrypts data in the Bluetooth communication link using a preset encryption algorithm.

[0009] In some embodiments, the first core encapsulating and encrypting the configuration data packet comprises: serializing and encapsulating the configuration data packet according to a predefined message structure to form a to-be-transmitted message, and encrypting the to-be-transmitted message using an authentication encryption algorithm with additional data to generate the encrypted configuration data packet containing ciphertext and a message authentication tag.

[0010] In some embodiments, the second core decrypting and verifying the encrypted configuration data packet comprises: verifying whether the message authentication tag is passed, and terminating processing and triggering an abnormal warning if the message authentication tag is not passed.

[0011] In a third aspect, the embodiments of the present application provide a vehicle diagnostic instrument, and the vehicle diagnostic instrument comprises at least one multi-core chip according to the first aspect.

[0012] The embodiments of the present application have the following beneficial effects: The multi-core chip according to the embodiments of the present application comprises a first core, a second core and a third core. The first core is configured to establish an encrypted communication connection with a mobile terminal and receive a configuration data packet required for vehicle diagnosis from the mobile terminal. The second core is configured to send a diagnosis instruction to a vehicle control unit based on the configuration data packet, collect diagnosis data as post-diagnosis information, and return the post-diagnosis information to the mobile terminal through the first core. The third core is configured to establish a bidirectional encrypted channel between the first core and the second core using a first communication key allocated to the first core and a second communication key allocated to the second core, so that sensitive diagnosis data is always in an encrypted state during transmission within the chip, effectively preventing the risk of data leakage or tampering caused by external serial port communication in a traditional dual-chip architecture. At the same time, since all core functions are integrated in a single chip, not only the hardware cost and circuit complexity are reduced, but also the overall data processing efficiency and system security are improved through high-speed and trusted encrypted communication mechanism between cores, thereby providing a high-security, low-latency and easy-to-deploy technical solution for vehicle diagnostic equipment. BRIEF DESCRIPTION OF DRAWINGS

[0013] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A first structural schematic diagram of a multi-core chip according to an embodiment of this application is shown; Figure 2 A schematic diagram of the second structure of a multi-core chip according to an embodiment of this application is shown; Figure 3 A schematic flowchart of a vehicle diagnostic method according to an embodiment of this application is shown.

[0015] Explanation of key component symbols: 10: First kernel; 20: Second kernel; 30: Third kernel; 40: First storage module; 50: Second storage module. Detailed Implementation

[0016] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0017] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0018] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0019] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0020] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0021] Existing vehicle diagnostic connectors employ a dual-chip architecture of a Bluetooth chip and a dedicated microcontroller unit, resulting in high hardware material costs, large space requirements, and security risks such as diagnostic information leakage or malicious tampering of instructions. This application provides a multi-core chip, a vehicle diagnostic method, and a vehicle diagnostic instrument. The multi-core chip of this application includes a first core, a second core, and a third core. The first core is responsible for establishing a secure wireless connection with the mobile terminal and receiving diagnostic configuration data packets. The second core executes vehicle diagnostic tasks according to the configuration and transmits diagnostic results back. The third core uses independent communication keys allocated to the first and second cores to build a bidirectional encrypted channel between the first and second cores. This ensures that sensitive diagnostic data remains encrypted during transmission within the chip, effectively preventing data leakage or tampering risks caused by external serial communication in traditional dual-chip architectures. Furthermore, since all core functions are integrated into a single chip, it not only reduces hardware costs and circuit complexity but also improves overall data processing efficiency and system security through a high-speed, reliable encrypted communication mechanism between cores, providing a highly secure, low-latency, and easily deployable technical solution for vehicle diagnostic equipment. The following describes the multi-core chip using specific examples.

[0022] Figure 1 A schematic diagram of a multi-core chip according to an embodiment of this application is shown. It is understood that the multi-core chip of this application embodiment can be applied to any vehicle diagnostic tool. Exemplarily, the multi-core chip is disposed on a vehicle diagnostic connector used for vehicle diagnostics. The multi-core chip includes a first core 10, a second core 20, and a third core 30.

[0023] The first kernel 10 is used to establish an encrypted communication connection with the mobile terminal and to receive configuration data packets required for vehicle diagnostics from the mobile terminal.

[0024] Understandably, the mobile terminal can be any type of mobile terminal, such as a mobile phone or computer. Exemplarily, the first kernel 10 can perform device discovery and Bluetooth pairing with the mobile terminal via BLE 5.3 or ISO 15118-2, establishing a Bluetooth communication link between the first kernel 10 and the mobile terminal. Furthermore, an encryption algorithm can be selected to encrypt and protect the data in the Bluetooth communication link according to the actual application.

[0025] For example, the first core 10 uses the BLE5.3 protocol to pair with the mobile terminal via Bluetooth, complete device authentication, and after the two parties exchange encryption keys, a Bluetooth communication link is formed. Based on the AES-128 algorithm, all data on the Bluetooth link, including configuration data and diagnostic data, is encrypted, which effectively prevents data from being eavesdropped, tampered with or forged during transmission, and significantly improves the system's communication security and privacy protection capabilities.

[0026] As an example, the third core 30 is a dedicated security chip, physically isolated from the external interface of the diagnostic header via a dedicated hardware interface, effectively preventing unauthorized access to the key generation and distribution process and man-in-the-middle attacks. The third core 30 is used to establish a bidirectional encrypted channel between the first core 10 and the second core 20 using the first communication key assigned to the first core 10 and the second communication key assigned to the second core 20.

[0027] Specifically, the third core 30 can randomly generate two random numbers using hardware noise sources such as internal chip thermal noise or clock jitter, which will serve as the first and second root keys respectively. The number of bits in the root keys can be set according to the actual application; for example, both the first and second root keys are 256-bit symmetric keys. Then, the third core 30 generates a first communication key based on the identifier of the first core 10 and the first root key, and generates a second communication key based on the identifier of the second core 20 and the second root key. Specifically, the kernel identifier can be the kernel serial number or the hash value of the MAC address. A hash algorithm can be used to generate the first and second communication keys. Using the identifier as part of the communication key ensures the randomness, uniqueness, and unpredictability of the key. Even if the root key is accidentally duplicated, the uniqueness of the final communication key can be guaranteed, significantly improving the security strength of the key system.

[0028] Furthermore, such as Figure 2As shown, the multi-core chip also includes a first storage module 40 and a second storage module 50. The first storage module 40 stores a first communication key and a second communication key, while the second storage module 50 stores unencrypted operating data and user operation logs. By storing the communication key, unencrypted operating data, and user operation logs in separate first and second storage modules 40 and 50 respectively, secure isolation storage of sensitive information is achieved, reducing the risk of key leakage and improving the overall security and reliability of data management of the system. Furthermore, the first storage module 40 is a one-time programmable storage area or a fuse array, thus achieving physically immutable and unreadable storage, and realizing tamper-proof storage. The communication key is stored in a physically isolated and tamper-proof one-time programmable storage area or fuse array, realizing unreadable and unmodifiable fixed storage of the key, which further enhances the ability to resist reverse analysis and side-channel attacks. Meanwhile, the running data and logs are stored independently in the second storage module 50, realizing strict isolation between sensitive information and ordinary data. The whole system constructs a reliable, secure and auditable multi-core communication architecture, which greatly improves the system's anti-attack capability and long-term operational security and reliability.

[0029] After obtaining the first communication key and the second communication key, the third kernel 30 can first verify the identity of the first kernel 10 and the second kernel 20 through the hardware certificates built into the first kernel 10 and the second kernel 20. After the verification is successful, the first communication key and the second communication key are injected into the first kernel 10 and the second kernel 20 respectively through the internal hardware bus to complete the key synchronization and form a two-way encrypted channel.

[0030] Furthermore, the internal hardware bus and the external interface of the diagnostic connector are completely isolated, preventing signals from the external interface from accessing the bus. The third kernel 30 and the encrypted channel interface are not connected to any external physical pins, making the encrypted channel physically inaccessible to external pins, thus achieving physical isolation and ensuring the physical inaccessibility of critical security modules. The third kernel 30 has a built-in access control list, allowing only the secure areas of the first kernel 10 and the second kernel 20 to access the encrypted channel via dedicated instructions. Any access attempts from external interfaces are directly blocked, triggering a hardware interrupt to record an exception, thus achieving logical isolation and forming a strict logical isolation mechanism. During initialization, the third kernel 30 disables all its external interface drivers, ensuring that even if the first kernel 10 and the second kernel 20 are compromised, external interfaces cannot interact with the third kernel 30 and the encrypted channel. Disabling all external interface drivers of the third kernel 30 during initialization further strengthens the defense-in-depth capability. Even if the first or second kernel 20 is compromised, attackers cannot penetrate the secure kernel or disrupt the encrypted channel through peripheral interfaces, significantly improving the system's security and robustness in complex threat scenarios.

[0031] As an example, during vehicle diagnostics, after the user selects the model of the vehicle to be diagnosed via a mobile terminal, the mobile terminal generates a configuration data packet including protocol type, baud rate, and data frame format based on the vehicle model. The configuration data packet is transmitted to the first kernel 10 via a Bluetooth communication link. The first kernel 10 encapsulates and encrypts the configuration data packet, and then transmits the encrypted configuration data packet to the second kernel 20 via a bidirectional encrypted channel established by the third kernel 30.

[0032] Specifically, the first kernel 10 serializes and encapsulates the configuration data packet according to a predefined message structure to form a message to be transmitted. It then encrypts the message using an authentication encryption algorithm with additional data, generating an encrypted configuration data packet containing ciphertext and a message authentication tag. The predefined message structure and encryption algorithm can be set according to the actual application. For example, the message structure can be [Message Header (4B)] [Counter (4B)] [Payload Length (2B)] [Payload Data (nB)] [CRC Check (4B)]. The message header contains metadata such as message type (e.g., configuration instructions / diagnostic data) and priority; the counter is a monotonically increasing sequence number to prevent replay attacks; and the CRC check is a cyclic redundancy check of the payload data to detect transmission errors. The entire message is encrypted using AES-256-GCM mode, and a 128-bit authentication tag is generated, resulting in the encrypted configuration data packet. The first kernel 10 transmits the encrypted configuration data packet to the second kernel 20 through an encrypted channel.

[0033] The second kernel 20 is used to send diagnostic commands to the vehicle control unit based on the configuration data packet, collect diagnostic data as post-diagnosis information, and send the post-diagnosis information back to the mobile terminal through the first kernel 10.

[0034] Specifically, the second kernel 20 decrypts and verifies the received encrypted configuration data packet, verifying whether the message authentication tag passes. If the verification passes, subsequent processing is performed based on the decrypted configuration data packet; if it fails, processing is terminated and an exception warning is triggered. Furthermore, the first kernel 10 can append a monotonically increasing counter to each data frame. The second kernel 20 verifies the continuity of the counter after verifying the authentication tag, thereby preventing replay attacks. Upon receiving data, the second kernel 20 first verifies the message authentication tag to ensure data integrity and source credibility, then verifies the continuity of the counter to resist replay attacks. Only after both verifications pass does it parse the configuration information and execute subsequent diagnostic operations. This effectively prevents security threats such as man-in-the-middle tampering, data forgery, or illegal instruction injection, ensuring the reliable transmission of key configuration parameters during vehicle diagnostics and improving the overall security and diagnostic accuracy of the system.

[0035] If the second kernel 20 verifies that both the authentication tag and the counter pass, it generates corresponding vehicle adjustment instructions based on the configuration data packet to adjust the parameters of the vehicle control unit. Specifically, the second kernel 20 loads the vehicle model diagnostic file based on the configuration data. The file contains vehicle adjustment instructions corresponding to the vehicle model, such as adjusting the CAN controller filter parameters. It then sends the vehicle adjustment instructions to the vehicle control unit to complete the initial configuration of the communication link, thereby achieving active adaptation and assisted establishment of the vehicle bus communication environment. After adjustment, a diagnostic request is sent to the vehicle control unit, and the corresponding vehicle communication protocol is automatically matched according to the configuration data packet. Furthermore, the diagnostic header is equipped with multiple communication interfaces, and the second kernel 20 can control the corresponding communication interface to connect with the vehicle according to the corresponding vehicle communication protocol.

[0036] The second kernel 20 automatically matches the corresponding vehicle communication protocol based on the configuration data and activates the corresponding physical channels in multiple communication interfaces, enabling the diagnostic head to flexibly support multiple vehicle network standards. This process can complete protocol identification and hardware resource configuration without external intervention, significantly improving the compatibility and connection reliability of the diagnostic head for multiple brands and models of vehicles. At the same time, the security kernel ensures the integrity and execution reliability of configuration commands, realizing efficient, safe, and adaptive vehicle diagnostic access.

[0037] After protocol matching is complete, the second kernel 20 generates corresponding diagnostic control information based on the vehicle diagnostic file and transmits it to the vehicle control unit. It also collects returned diagnostic data, such as fault codes and sensor signals, according to the matched vehicle communication protocol. This diagnostic data is encapsulated and encrypted as post-diagnostic information to generate encrypted diagnostic results, which are then transmitted back to the first kernel 10 via a bidirectional encrypted channel. The first kernel 10 decrypts and verifies the encrypted diagnostic results. Once confirmed to be correct, it transmits the results to the mobile terminal via Bluetooth. The mobile terminal decrypts the results and visualizes them. This achieves end-to-end data security and efficient transmission from the vehicle to the user, improving the reliability, compatibility, and user experience of the diagnostic system.

[0038] In one embodiment, Figure 3 A flowchart illustrating a vehicle diagnostic method according to an embodiment of this application is shown. The vehicle diagnostic method provided in this application is applied to a multi-core chip in any of the above embodiments, specifically including steps S101-S106: S101, the first kernel 10 establishes an encrypted communication connection with the mobile terminal and receives configuration data packets from the mobile terminal; S102, the first kernel 10 encapsulates and encrypts the configuration data packet, and transmits the encrypted configuration data packet to the second kernel 20 through the bidirectional encrypted channel established by the third kernel 30; S103, the second kernel 20 decrypts and verifies the received encrypted configuration data packet. If the verification is successful, the corresponding diagnostic control information is obtained based on the decrypted configuration data packet. S104, the second core 20 sends diagnostic control information to the vehicle control unit and collects the returned diagnostic data as post-diagnosis information; S105, the second kernel 20 encapsulates and encrypts the diagnostic information, generates an encrypted diagnostic result, and sends it back to the first kernel 10 via a two-way encrypted channel; S106, the first kernel 10 decrypts and verifies the encryption diagnostic results, and forwards them to the mobile terminal after confirming that they are correct.

[0039] Optionally, after the second kernel 20 decrypts and verifies the received encrypted configuration data packet, and before the second kernel 20 sends diagnostic control information to the vehicle control unit, the vehicle diagnostic method further includes: the second kernel 20 generates a corresponding vehicle adjustment command based on the configuration data packet to adjust the parameters of the vehicle control unit, and after adjustment sends a diagnostic request to the vehicle control unit, and automatically matches the corresponding vehicle communication protocol based on the configuration data packet.

[0040] Optionally, the first kernel 10 establishes an encrypted communication connection with the mobile terminal by: the first kernel 10 completing device discovery and pairing with the mobile terminal by running the Bluetooth protocol, establishing a Bluetooth communication link between the first kernel 10 and the mobile terminal, and using a preset encryption algorithm to encrypt and protect the data in the Bluetooth communication link.

[0041] Optionally, the first kernel 10 encapsulates and encrypts the configuration data packet by: serializing and encapsulating the configuration data packet according to a predefined message structure to form a message to be transmitted, and encrypting the message to be transmitted using an authentication encryption algorithm with additional data to generate an encrypted configuration data packet containing ciphertext and a message authentication tag.

[0042] Optionally, verify whether the message authentication tag is valid. If it fails, terminate the process and trigger an exception warning.

[0043] It is understood that the method in this embodiment corresponds to the multi-core chip in the above embodiments, and the options in the above embodiments are also applicable to this embodiment. The vehicle diagnostic method provided in this application embodiment can realize the function of the multi-core chip corresponding to the above embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0044] This application also provides a vehicle diagnostic tool, exemplary of which is equipped with the aforementioned multi-core chip.

[0045] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0046] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0047] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0048] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A multi-core chip, characterized by comprising: The method comprises: a first core, configured to establish an encrypted communication connection with a mobile terminal, and receive a configuration data packet required for vehicle diagnosis from the mobile terminal; a second core, configured to send a diagnosis instruction to a vehicle control unit based on the configuration data packet, collect diagnosis data as post-diagnosis information, and return the post-diagnosis information to the mobile terminal through the first core; a third core, configured to establish a bidirectional encrypted channel between the first core and the second core by using a first communication key assigned to the first core and a second communication key assigned to the second core.

2. The multi-core chip of claim 1, wherein, The multi-core chip further comprises: a first storage module, configured to store the first communication key and the second communication key; a second storage module, configured to store non-encrypted operation data and user operation logs.

3. The multi-core chip of claim 2, wherein, The first storage module is a one-time programmable storage area or a fuse array.

4. The multi-core chip of claim 1, wherein, The third core is further configured to randomly generate a first root key and a second root key with a preset number of bits, generate the first communication key based on an identifier of the first core and the first root key, and generate the second communication key based on an identifier of the second core and the second root key.

5. A vehicle diagnosis method characterized by, The method is applied to the multi-core chip according to any one of claims 1 to 4, and the method comprises: the first core establishes an encrypted communication connection with the mobile terminal, and receives the configuration data packet from the mobile terminal; the first core encapsulates and encrypts the configuration data packet, and transmits the encrypted configuration data packet to the second core through the bidirectional encrypted channel established by the third core; the second core decrypts and verifies the received encrypted configuration data packet, and if the verification is passed, obtains corresponding diagnosis control information according to the decrypted configuration data packet; the second core sends the diagnosis control information to the vehicle control unit and collects returned diagnosis data as post-diagnosis information; the second core encapsulates and encrypts the post-diagnosis information, generates an encrypted diagnosis result, and returns the encrypted diagnosis result to the first core through the bidirectional encrypted channel; the first core decrypts and verifies the encrypted diagnosis result, and forwards the encrypted diagnosis result to the mobile terminal after confirming that the encrypted diagnosis result is correct.

6. The vehicle diagnostic method of claim 5, wherein After the second core decrypts and verifies the received encrypted configuration data packet, before the second core sends the diagnosis control information to the vehicle control unit, the vehicle diagnosis method further comprises: the second core generates corresponding vehicle adjustment instructions according to the configuration data packet, adjusts parameters of the vehicle control unit, sends a diagnosis request to the vehicle control unit after the adjustment, and automatically matches a corresponding vehicle communication protocol according to the configuration data packet.

7. The vehicle diagnostic method of claim 5, wherein The first core establishing an encrypted communication connection with the mobile terminal comprises: the first core completes device discovery and pairing with the mobile terminal by running a Bluetooth protocol, establishes a Bluetooth communication link between the first core and the mobile terminal, and encrypts data in the Bluetooth communication link by using a preset encryption algorithm.

8. The vehicle diagnostic method of claim 5, wherein, The first core encapsulating and encrypting the configuration data packet comprises: The configuration data packet is serialized and packaged according to a predefined message structure to form a to-be-transmitted message, and the to-be-transmitted message is encrypted by using an authentication encryption algorithm with additional data to generate the encrypted configuration data packet containing cipher text and a message authentication tag.

9. The vehicle diagnostic method of claim 8, wherein, The second core decrypts and verifies the encrypted configuration data packet, including: verifying whether the message authentication tag is passed, and if not, terminating the processing and triggering an abnormal warning.

10. A vehicle diagnostic tool, characterized by, The vehicle diagnostic instrument comprises the multi-core chip of claim 1.

Images