Secure communication method, system, computer device and computer readable storage medium

Abstract

The application discloses a secure communication method, system, computer device and computer readable storage medium, comprising: a diagnostic device uploads device information to a server, the device information comprising a first MAC address of Bluetooth, a first serial number of the diagnostic device and a chip ID of an encryption chip; a diagnostic APP acquires the device information and stores the device information in a whitelist database; the diagnostic APP generates a connection request comprising dynamic encryption data and a timestamp, the dynamic encryption data comprising the device information; the diagnostic device receives the connection request, reads the chip ID of the encryption chip and decrypts the dynamic encryption data based on the chip ID and the timestamp; the diagnostic device performs three-party consistency verification on the dynamic encryption data, if the verification is passed, the diagnostic device establishes an encryption channel with the diagnostic APP, vehicle fault diagnosis is performed, otherwise, the diagnostic device rejects the connection. In this way, the method can ensure the security of data transmission during vehicle fault diagnosis.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to secure communication methods, systems, computer devices, and computer-readable storage media. Background Technology

[0002] Currently, in vehicle diagnostics, Bluetooth communication in diagnostic devices relies on fixed pairing codes for authentication, which is vulnerable to hacking. While diagnostic devices can also encrypt data using fixed keys and pair with authorized devices, these keys are easily forged, and attacks involving the Media Access Control Address (MAC) cannot prevent such attacks, posing a risk to security authentication.

[0003] Therefore, how to establish a secure and reliable channel for diagnostic equipment to prevent vehicle data from being tampered with during fault diagnosis has become an urgent problem to be solved. Summary of the Invention

[0004] This application provides a secure communication method, system, computer device, and computer-readable storage medium. The method can pre-configure Bluetooth MAC addresses and corresponding whitelist databases in authorized devices, encrypt data using dynamic encryption technology, and initiate a connection based on this dynamic encryption technology after verifying the validity of the MAC address, performing vehicle fault diagnosis through a secure encrypted channel. The specific technical solution is as follows:

[0005] Firstly, a secure communication method is provided, the method comprising:

[0006] The diagnostic device uploads its device information to a server. This device contains Bluetooth and an encryption chip. The device information includes the Bluetooth's first MAC address, the diagnostic device's first serial number, and the encryption chip's chip ID. The diagnostic application (APP) retrieves this device information from the server and stores it in a whitelist database. This whitelist database indicates which diagnostic devices the APP can connect to. The APP generates a connection request containing dynamically encrypted data and a timestamp and sends it to the diagnostic device. This dynamically encrypted data is obtained by encrypting the first MAC address and the first serial number with a dynamic key, which is generated by the encryption chip. The chip ID and timestamp are generated in real time; the diagnostic device receives the connection request, reads the chip ID of the encryption chip, and decrypts the dynamically encrypted data based on the chip ID and timestamp; the diagnostic device reads the pre-stored second MAC address from the encryption chip, the third MAC address from the Bluetooth, and the second serial number of the diagnostic device itself, and determines whether the three-party consistency check passes based on the dynamically encrypted data; if the three-party consistency check passes, the diagnostic APP establishes an encrypted channel with the diagnostic device and performs fault diagnosis on the vehicle connected to the diagnostic device; otherwise, the diagnostic device refuses to connect.

[0007] In conjunction with the first aspect, the dynamic key is generated by concatenating the chip ID with the timestamp and is used for Advanced Encryption Standard (AES) encryption.

[0008] In conjunction with the first aspect, this whitelist database is established by the device information downloaded by the diagnostic app from the server.

[0009] In conjunction with the first aspect, the encryption chip is an independent security element (SE) chip.

[0010] In conjunction with the first aspect, the device determines whether the three-party consistency verification passes based on the dynamically encrypted data, including: comparing whether the first serial number and the second column number are consistent; comparing whether the first MAC address and the second MAC address are consistent; comparing whether the first MAC address and the third MAC address are consistent; only after all three comparisons are consistent, the diagnostic device determines that the three-party consistency verification has failed and returns preset verification success data to the diagnostic APP.

[0011] In conjunction with the first aspect, the diagnostic device refuses connection by: returning preset verification failure data or not responding with data to refuse connection.

[0012] In conjunction with the first aspect, the validity period of the timestamp is a first duration. When the diagnostic app detects that the duration from the timestamp to the current time exceeds the first duration, the connection request becomes invalid.

[0013] It should be noted that, in the absence of conflict, the features in the various embodiments of the first aspect can be combined with each other, and any combination of features in different embodiments is also within the protection scope of this application. That is to say, the various embodiments described above can also be arbitrarily combined according to actual needs.

[0014] Secondly, a secure communication system is provided, including:

[0015] The diagnostic device is equipped with Bluetooth and an encryption chip. It is used to upload device information to the server, and after receiving a connection request, it reads the chip ID of the encryption chip, decrypts the dynamically encrypted data based on the chip ID and timestamp, reads the pre-stored second MAC address from the encryption chip, reads the third MAC address from the Bluetooth, reads the second serial number of the diagnostic device in the device itself, and determines whether the three-party consistency verification is passed based on the dynamically encrypted data. If the three-party consistency verification is passed, the diagnostic device establishes an encrypted channel with the diagnostic APP to perform fault diagnosis on the vehicle connected to the diagnostic device; otherwise, the diagnostic device refuses to connect.

[0016] The server is used to store the device information of the diagnostic device, which includes the first MAC address of the Bluetooth device, the first serial number of the diagnostic device, and the chip ID of the encryption chip.

[0017] The diagnostic app is used to obtain device information from the server and store it in a whitelist database. It is also used to determine the diagnostic device that the diagnostic app can connect to in the whitelist database and generate a connection request containing the dynamically encrypted data and a timestamp. The dynamically encrypted data is obtained by encrypting the first MAC address and the first serial number with a dynamic key. The dynamic key is generated in real time by the chip ID and the timestamp.

[0018] Thirdly, a computer is provided, including one or more memories and one or more processors; the memory is coupled to the one or more processors, the memory being used to store computer program code including computer instructions, the one or more processors calling the computer instructions to cause the computer to implement the method as described in the first aspect or any of the embodiments of the first aspect.

[0019] Fourthly, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the method as described in the first aspect or any of the embodiments in the first aspect.

[0020] Fifthly, a chip is provided for use in a computer, the chip including one or more processors for invoking computer instructions to cause the computer to perform a method as described in the first aspect or any of the embodiments of the first aspect.

[0021] In this application embodiment, the method provided includes: pre-setting authorized diagnostic device MAC addresses, establishing a whitelist database corresponding to the MAC addresses, and performing advanced encryption standard AES encryption based on dynamic keys to ensure the security of device information during storage and transmission; the diagnostic APP is only allowed to communicate with diagnostic devices located in the whitelist to prevent unauthorized devices from accessing the system; the diagnostic device can use an encryption chip to store MAC addresses and initiate connection requests based on a data encryption mechanism; when the diagnostic APP and the diagnostic device connect, they need to verify whether the Bluetooth MAC address passes the verification; after confirming that the MAC address passes the verification, a secure and reliable encrypted channel is established to prevent vehicle diagnostic data from being intercepted and tampered with by unauthorized diagnostic devices, thereby improving the security of diagnostic device data transmission. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of a vehicle diagnostic scenario provided in an embodiment of this application;

[0024] Figure 2 This is a schematic diagram of a secure communication system provided in an embodiment of this application;

[0025] Figure 3 This is a flowchart illustrating a general method for secure communication provided in an embodiment of this application;

[0026] Figure 4 This is a flowchart of a method for third-party consistency verification provided in an embodiment of this application;

[0027] Figure 5 This is a schematic diagram of a diagnostic device provided in an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of a diagnostic APP provided in an embodiment of this application;

[0029] Figure 7 This is a software schematic diagram of a computer device provided in an embodiment of this application;

[0030] Figure 8 This is a schematic diagram of the hardware structure of a computer device provided in an embodiment of this application;

[0031] Figure 9 This is a schematic diagram of a computer-readable storage medium provided in an embodiment of this application. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0033] It should be understood that "multiple" as mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, " / " indicates "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, to facilitate a clear description of the technical solutions of this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0034] The terms "one embodiment" or "some embodiments" used in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this application do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. Furthermore, the terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0035] Currently, in vehicle diagnostic scenarios, diagnostic devices use Bluetooth communication based on fixed pairing codes for verification, which is vulnerable to being cracked. Furthermore, while diagnostic devices use fixed-key encryption to pair with authorized devices, this fixed key cannot prevent attacks that forge Media Access Control Addresses (MAC addresses), leading to a risk of data tampering during vehicle fault diagnosis via Bluetooth communication.

[0036] To address the aforementioned technical issues, embodiments of this application provide a secure communication method, system, computer device, and computer-readable storage medium, including: a diagnostic device uploading device information to a server; the diagnostic device is equipped with Bluetooth and an encryption chip; the device information includes the first MAC address of the Bluetooth device, the first serial number of the diagnostic device, and the chip identity number of the encryption chip. The diagnostic application (APP) obtains device information from the server and stores it in a whitelist database, which indicates which diagnostic devices the diagnostic APP can connect to. The diagnostic APP generates a connection request containing dynamically encrypted data and a timestamp and sends it to the diagnostic device. The dynamically encrypted data is obtained by encrypting the first MAC address and the first serial number with a dynamic key, which is generated in real time by the chip ID and the timestamp. The diagnostic device receives the connection request, reads the chip ID of the encryption chip, and decrypts the dynamically encrypted data based on the chip ID and the timestamp. The diagnostic device reads the pre-stored second MAC address from the encryption chip, the third MAC address from the Bluetooth, and the second serial number of the diagnostic device itself, and determines whether the three-party consistency check passes based on the dynamically encrypted data. If the three-party consistency check passes, the diagnostic APP establishes an encrypted channel with the diagnostic device and performs fault diagnosis on the vehicle connected to the diagnostic device; otherwise, the diagnostic device refuses to connect. In this way, the diagnostic device connected to the diagnostic app is determined based on a whitelist. The authorized Bluetooth MAC address is obtained by storing it through an encrypted chip. The data is then encrypted using AES encryption, which prevents unauthorized devices from intercepting and tampering with the vehicle's data during fault diagnosis, thus improving the security of data transmission during vehicle fault diagnosis.

[0037] The following describes the vehicle diagnostic method, system, computer device, and computer-readable storage medium provided in this application through three embodiments. Embodiment 1 describes a vehicle diagnostic scenario and a secure communication system for a secure communication method. Embodiment 2 describes the method flow for implementing secure communication. Embodiment 3 describes the diagnostic device module structure, diagnostic APP module structure, computer device software structure, computer device hardware structure, and computer storage medium for executing the secure communication method.

[0038] Example 1

[0039] Figure 1 A schematic diagram of a vehicle diagnostic scenario is shown. (For example...) Figure 1As shown, the vehicle diagnostic scenario includes a vehicle 100, a diagnostic device 200, a server 300, and a diagnostic app 400. The vehicle 100 establishes a communication connection with the diagnostic device 200, the diagnostic device 200 establishes a communication connection with the server 300, and the diagnostic app 400 establishes communication connections with both the diagnostic device 200 and the server 300.

[0040] In this embodiment, the vehicle 100 and the diagnostic device 200 can communicate via a wired connection, for example, through an On-Board Diagnostics (OBD) interface; the diagnostic device 200 and the server 300 can communicate via a wireless connection, for example, based on Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS); the diagnostic app 400 and the diagnostic device 200 can communicate via a wired and / or wireless connection, and the diagnostic app 400 and the server 300 can communicate via a wireless connection.

[0041] In this embodiment, the diagnostic APP 400 can be located in the terminal device, and the diagnostic device 200 communicates with the diagnostic APP 400 in the terminal device via a wireless connection (e.g., Bluetooth, Wireless Fidelity (WiFi), and Internet communication protocols). Alternatively, the diagnostic APP 400 can be located in the diagnostic device 200, and the diagnostic device 200 can directly read the data in the diagnostic APP 400 via a wired connection. Meanwhile, the wireless communication between the diagnostic APP 400 and the server 300 is the same as the wireless communication between the diagnostic device 200 and the server 300.

[0042] In this embodiment, vehicle 100 is connected to diagnostic equipment 200. The electronic control unit (ECU) in vehicle 100 can receive signals sent by diagnostic equipment 200 to perform vehicle fault diagnosis and return the parameter information obtained by the ECU to diagnostic equipment 200. The diagnostic signal can be sent by diagnostic equipment 200 or by diagnostic APP 400, instructing diagnostic equipment 200 to perform vehicle fault diagnosis.

[0043] In this embodiment, the diagnostic device 200 includes an encryption chip, which can be an independent Secure Element (SE) chip. This chip provides protection for the data stored within it (e.g., a metal shielding layer to prevent physical detection, generating a key after confirming the security of the diagnostic device 200, and making critical data storage areas unreadable). This protects the stored data from tampering by third-party devices or applications. Furthermore, an authenticated (i.e., authorized) Bluetooth MAC address (i.e., a second MAC address) can be programmed into the encryption chip. This second MAC address is used for three-way consistency verification.

[0044] In this embodiment of the application, when verifying the diagnostic device 200, the diagnostic device 200 can be a device to be verified. The Bluetooth MAC address read by the device to be verified is a third MAC address, and the serial number read by the device to be verified is a second serial number.

[0045] In this embodiment, the diagnostic device 200 can upload diagnostic device information to the server 300 for storage. This diagnostic device information may include: the serial number of the diagnostic device 200 (i.e., the first serial number), the chip ID of the encryption chip, the name of the Bluetooth device in the diagnostic device 200 (i.e., the Bluetooth serial number), the Bluetooth MAC address of the diagnostic device 200 (i.e., the first MAC address), and the version information of the diagnostic device 200, etc. The server 300 can store the above diagnostic information in a database.

[0046] In this embodiment, the diagnostic app 400 has a whitelist database for storing diagnostic device information downloaded from the server 300. This diagnostic device information can be data encrypted using the Advanced Encryption Standard (AES). The AES-based encryption method includes setting a dynamic key using the chip ID and timestamp of the encryption chip in the diagnostic device 200. This dynamic key is used to implement dynamic encryption based on AES, preventing third-party devices or applications from tampering with the diagnostic device information.

[0047] In this embodiment, AES encryption of diagnostic device information can be performed by the diagnostic device 200 before uploading the diagnostic device information to the server 300, by the server 300 after receiving the diagnostic device information, or by the diagnostic APP 400 after receiving the diagnostic device information. This embodiment does not limit the specific encryption device for the diagnostic information.

[0048] In this embodiment, the diagnostic app 400 searches for connectable devices via Bluetooth and matches the MAC addresses found through Bluetooth with those stored in a whitelist database (i.e., the first MAC address). Devices matching the first MAC address (i.e., connectable devices) are then displayed on the interface for user selection. For example, the user can select the connectable device from multiple connectable devices and perform vehicle fault diagnosis after successful connection.

[0049] In this embodiment of the application, the diagnostic APP 400 determines that the diagnostic device 200 selected by the user initiates a connection request. The parameters of the connection request include dynamically encrypted data (including a first serial number and a first MAC address) encrypted with AES and a timestamp.

[0050] In this embodiment, the diagnostic device 200 receives a connection request, reads the chip ID of the encryption chip to generate a decryption key, decrypts the dynamically encrypted data, and performs a three-way consistency check. The diagnostic device 200 that receives the connection request can be the device to be verified.

[0051] In this embodiment, the device to be verified (i.e., diagnostic device 200) obtains the chip ID and generates a decryption key based on the timestamp in the connection request. It then decrypts the dynamically encrypted data to obtain the first serial number and the first MAC address. The device to be verified then reads its own second serial number, the Bluetooth third MAC address, and the second MAC address of the pre-existing encryption chip to perform a three-way consistency check.

[0052] Specifically, the tripartite consistency verification includes:

[0053] Compare whether the first serial number and the second serial number are consistent;

[0054] Compare whether the first MAC address and the second MAC address are the same;

[0055] Compare whether the first MAC address and the third MAC address are the same;

[0056] Only after all three comparisons are consistent will the diagnostic device 200 determine that the three-party consistency check has passed; otherwise, the diagnostic device 200 will determine that the three-party consistency check has failed.

[0057] In this embodiment, if the diagnostic device 200 determines that the three-party consistency verification passes, it indicates that the diagnostic device 200 is an authorized device and returns verification success data (e.g., the first data value 0x00) to the diagnostic APP 400; if the diagnostic device 200 determines that the three-party consistency verification fails, it indicates that the diagnostic device 200 is an uncertified device (e.g., an unauthorized third-party device) and returns verification failure data (e.g., the second data value 0x01) to the diagnostic APP 400 or does not respond with data.

[0058] In this embodiment, the diagnostic APP 400 receives the return data of the connection request and parses the connection request result. If the diagnostic APP 400 receives successful verification data, it establishes an encrypted channel with the diagnostic device 200 and instructs the diagnostic device 200 to perform vehicle fault diagnosis on the connected vehicle 100. If the diagnostic APP 400 receives failed verification data or does not receive data for more than a second time period (e.g., 5 seconds), it terminates the connection with the diagnostic device 200.

[0059] In this embodiment of the application, when the diagnostic device 200 has completed the vehicle fault diagnosis of a vehicle 100, it connects to the next vehicle 100. At this time, the aforementioned authentication process can be repeated to perform vehicle fault diagnosis on the new vehicle 100, or the diagnostic device 200 can be directly instructed to be authorized to perform vehicle fault diagnosis directly.

[0060] In the embodiments of this application, the diagnostic device 200 may include user equipment (UE), mobile device, mobile station, mobile unit, machine-to-machine (M2M) terminal, wireless unit, terminal device, remote unit, terminal agent, mobile client, etc.

[0061] In the embodiments of this application, Figure 1 The vehicle diagnostic scenario described herein uses the communication between a vehicle 100, a diagnostic device 200, a server 300, and a diagnostic app 400 as an example. In practical applications, the number of vehicles 100, diagnostic devices 200, servers 300, and diagnostic apps 400 can be greater. For example, a single diagnostic app 400 can obtain diagnostic device information from multiple diagnostic devices 200 stored in the server 300. In the following description, the secure communication method involved in the embodiments of this application is applied to, for example... Figure 1 The vehicle diagnostic scenario shown.

[0062] It should be noted that the vehicle diagnostic scenario in this embodiment only uses vehicle 100, diagnostic device 200, server 300, and diagnostic APP 400 as an example. Specific vehicle diagnostic scenarios may involve more or fewer devices. For example, diagnostic device 200 may include diagnostic APP 400 and implement the diagnostic functions shown by APP 400. In this case, only vehicle 100, diagnostic device 200, and server 300 are needed to implement the above-mentioned vehicle diagnostic scenario. This embodiment does not limit the specific vehicle diagnostic scenario for implementing the secure communication method.

[0063] Figure 2A schematic diagram of a secure communication system is shown, which is applied to, for example Figure 1 The vehicle diagnostic scenario shown is as follows. Figure 2 As shown, the secure communication system includes a vehicle 100, a diagnostic device 200, a server 300, and a diagnostic application 400. The diagnostic device 200 includes an encryption chip, a verification module, and a Bluetooth module; the server 300 includes a storage module; and the diagnostic application 400 includes a whitelist database.

[0064] In this embodiment, the diagnostic device 200 and the server 300 can establish a connection via HTTP / HTTPS, as detailed above. Figure 1 The description of the communication between the diagnostic device 200 and the server 300 will not be repeated here.

[0065] In this embodiment, the encryption chip in the diagnostic device 200 has a burned-in MAC address, which is an authenticated Bluetooth MAC address (i.e., a second MAC address); the diagnostic device 200 also has a unique identifier (i.e., a first serial number) burned into it. This first serial number and the second MAC address can identify the authenticated diagnostic device 200. The encryption chip is an SE chip, which protects the stored data from tampering by third-party devices or applications.

[0066] In this embodiment, a three-party consistency check is performed on the diagnostic device 200, which is the device to be checked. The consistency between the second MAC address and the Bluetooth MAC address (i.e., the third MAC address) in the device to be checked can be compared. By comparing the second and third MAC addresses, it can be determined whether the Bluetooth module in the device to be checked (i.e., the diagnostic device 200) is an original Bluetooth module. If the Bluetooth module in the device to be checked is an original Bluetooth module, then the second and third MAC addresses are consistent; otherwise, they are inconsistent. Similarly, the first serial number of the diagnostic device 200 corresponds to the second MAC address. If the Bluetooth MAC addresses are the same (i.e., the second and third MAC addresses are the same), comparing the first serial number of the diagnostic device 200 with the second serial number of the device to be checked can determine whether the device to be checked is an authorized original device.

[0067] In this embodiment, the server 300 and the diagnostic APP 400 can establish a connection via HTTP / HTTPS. The server 300 stores the device information sent by the diagnostic device 200 through a storage module. This device information includes the first serial number, first MAC address, and chip ID of the diagnostic device 200. For a detailed description of the server 300, please refer to the foregoing. Figure 1 This will not be elaborated upon here.

[0068] In this embodiment, the diagnostic app 400 can be located on a terminal device and establish a connection with the diagnostic device 200 based on wired or wireless communication. The terminal device and the diagnostic device 200 can be the same device or different devices. When the terminal device and the diagnostic device 200 are the same device, the communication between the diagnostic app 400 and the diagnostic device 200 is internal wired communication. When the terminal device and the diagnostic device 200 are not the same device, the communication between the diagnostic app 400 and the diagnostic device 200 can be wireless (e.g., based on Bluetooth, Wi-Fi, Internet Protocol, etc.). This embodiment does not limit whether the diagnostic app 400 is located on the diagnostic device 200.

[0069] In this embodiment, the diagnostic app 400 establishes a whitelist database to store device information downloaded from the server 300. The whitelist database includes the device serial number (i.e., the first serial number), chip ID, and MAC address (i.e., the first MAC address). The device information can be encrypted using AES, and the diagnostic app 400 can also store a dynamic key (including a timestamp for generating the dynamic key) used for AES encryption.

[0070] In this embodiment, the device information may be AES encrypted in the diagnostic device 200 and then transmitted to the server 300 for storage; the device information may also be AES encrypted in the server 300 and then transmitted to the diagnostic APP 400 by the server 300; or the device information may be AES encrypted in the diagnostic APP 400. This embodiment does not limit the specific device used for encrypting the device information.

[0071] In some implementations, the dynamic key can also decrypt AES-encrypted data, and the timestamp for generating the dynamic key can be set to have a validity period of a first duration. Specifically, starting from the timestamp for generating the dynamic key, if the time elapsed from the current time to that timestamp exceeds the first duration (e.g., 1 minute), the timestamp is considered invalid, and the dynamic key is deleted to prevent attacks using forged dynamic keys.

[0072] In this embodiment, the diagnostic APP 400 determines multiple diagnostic devices 200 that can be connected via Bluetooth based on the first MAC address in the whitelist, and after receiving user operation, determines the diagnostic device 200 to be connected via Bluetooth (the diagnostic device 200 can be the device to be verified), and initiates a connection request and three-party consistency verification to the device to be verified.

[0073] For example, the device to be verified (i.e., diagnostic device 200) performs a three-way consistency verification through the verification module, as detailed above. Figure 1The specific description of the three-party consistency verification between the diagnostic APP400 and the diagnostic device 200 is not repeated here.

[0074] In this embodiment, if the diagnostic device 200 determines that the three-party consistency verification has passed based on the verification module, it returns verification success data to the diagnostic APP 400; if the diagnostic device 200 determines that the three-party consistency verification has failed, it returns verification failure data to the diagnostic APP 400 or does not respond with data. For details, please refer to the foregoing. Figure 1 The specific descriptions in the text will not be repeated here.

[0075] It is understood that the functional division between the modules illustrated in the embodiments of this application is merely illustrative and does not constitute a functional limitation on the secure communication system. In other embodiments of this application, the secure communication system may also employ different modules or combinations of multiple modules to implement the functions of the secure communication system.

[0076] Example 2

[0077] Figure 3 A flowchart illustrating an overall method for secure communication is shown, applicable to, for example... Figure 1 The vehicle diagnostic scenarios shown and such Figure 2 The secure communication system shown specifically includes:

[0078] S101. Diagnostic equipment uploads device information.

[0079] In this embodiment, the diagnostic device uploads device information to the server. The diagnostic device is equipped with Bluetooth and an encryption chip. The device information includes the first MAC address of the Bluetooth, the first serial number of the diagnostic device, and the chip ID of the encryption chip. The encryption chip is an independent SE chip, which can protect the data burned into the chip from modification by third-party devices or applications.

[0080] In this embodiment of the application, the server is provided with a database for storing device information. The database can store device information of multiple diagnostic devices and record them in order (such as the order in which the device information was obtained).

[0081] In this embodiment of the application, the encryption chip is pre-programmed with an authenticated Bluetooth MAC address, namely the second MAC address, which is used to perform a three-way consistency check to determine whether the diagnostic device is an original device.

[0082] S102. The diagnostic app obtains device information and establishes a whitelist database.

[0083] In this embodiment of the application, the diagnostic APP obtains device information from the server and stores it in a whitelist database. The whitelist database is used to indicate the diagnostic devices that the diagnostic APP can connect to.

[0084] In some implementations, the whitelist database in the diagnostic app is established by the device information downloaded by the diagnostic app from the server in one go, and subsequent communication does not require the server to participate in verification. The diagnostic app can communicate with the device to be verified (i.e. the diagnostic device) based on the whitelist database to perform three-way consistency verification.

[0085] S103. The diagnostic app identifies the connected device and obtains dynamically encrypted data.

[0086] In this embodiment, the diagnostic app determines connectable diagnostic devices based on a whitelist database and obtains a connection request containing dynamically encrypted data and a timestamp. The dynamically encrypted data is obtained by encrypting a first MAC address and a first serial number using an AES key. The dynamic key is generated by concatenating a chip ID and a timestamp and is used for AES encryption. The specific value of the dynamic key is related to the timestamp captured when it is generated, thus achieving dynamic security authentication.

[0087] In some implementations, the timestamp is set with a first validity period (e.g., 1 minute). When the diagnostic app detects that the time elapsed from the timestamp to the current time exceeds the first validity period, it can either deactivate the dynamic key or delete the dynamic key and accept connection requests, thus minimizing the risk of forgery attacks after the key is intercepted.

[0088] In some implementations, the dynamically encrypted data may also be generated by the diagnostic device before transmitting device information to the server, and the dynamically encrypted device information may be transmitted to the server; the dynamically encrypted data may also be generated by the server before transmitting to the diagnostic APP, and the dynamically encrypted device information may be transmitted to the diagnostic APP. The embodiments of this application do not limit the specific device for performing dynamic encryption.

[0089] S104. The diagnostic app sends a connection request to the diagnostic device based on dynamically encrypted data.

[0090] In the embodiments of this application, such as Figure 1In the vehicle diagnostic scenario shown, a user needs to perform fault diagnosis on vehicle 100. This can be achieved by launching the diagnostic app 400. After successful user login verification, the diagnostic app 400 enables Bluetooth to search for connectable devices. Based on the first MAC address in the whitelist database, it matches the MAC address of the corresponding device and displays diagnostic devices 200 that have MAC addresses in the whitelist database. The diagnostic app 400 receives the diagnostic device 200 selected by the user for connection; this device 200 is the device to be verified. The diagnostic app 400 sends a connection request including dynamically encrypted data and a timestamp corresponding to the dynamic key to the device to be verified, instructing the device to obtain its own device information for three-way consistency verification.

[0091] In some implementations, the diagnostic app can determine whether the timestamp of the dynamic key is valid and automatically terminate the connection request after the timestamp expires.

[0092] S105. The diagnostic device decrypts the dynamically encrypted data.

[0093] In this embodiment, the device to be verified (i.e., the diagnostic device) receives the connection request and timestamp. The device to be verified can read the chip ID of the encryption chip and decrypt the dynamically encrypted data based on the chip ID and timestamp. Specifically, in AES encryption, the key used for encryption and the key used for decryption can be the same key. The diagnostic device can generate a decryption key based on the chip ID and timestamp, and the decrypted data yields a first serial number and a first MAC address.

[0094] S106. The diagnostic device performs a three-way consistency check based on the decrypted data.

[0095] In this embodiment, the device to be verified (i.e., the diagnostic device) reads the device's serial number (i.e., the second serial number), the Bluetooth MAC address (i.e., the third MAC address), and the Bluetooth MAC address stored in the encryption chip (i.e., the second MAC address) for three-way verification. Specifically, the diagnostic device sequentially compares whether the first serial number and the second serial number are consistent; compares whether the first MAC address and the second MAC address are consistent; and compares whether the first MAC address and the third MAC address are consistent. By analyzing the results of the three comparisons, it determines whether the three-way consistency verification has passed and executes the steps shown in S107.

[0096] S107. The diagnostic equipment determines whether the three-party consistency verification has passed.

[0097] In this embodiment of the application, only after all three comparisons in step S106 are consistent, the diagnostic device determines that the three-party consistency verification has passed, and the diagnostic device is an original device with reliable security, and executes the step shown in S108; otherwise, the diagnostic device determines that the three-party consistency verification has not passed, and the diagnostic device is a modified device or an unauthorized third-party device, and the security of the diagnostic device cannot be guaranteed, and executes the step shown in S109.

[0098] S108. Establish a connection between the diagnostic equipment and the diagnostic APP to perform vehicle fault diagnosis.

[0099] In this embodiment, the diagnostic device returns successful verification data (e.g., a first value of 0x00) to the diagnostic app. Upon receiving the connection request response, the diagnostic app establishes an encrypted channel with the diagnostic device, allowing fault diagnosis of the vehicle connected to the diagnostic device. Users can operate the diagnostic app and use the diagnostic device to perform vehicle fault diagnosis.

[0100] In this embodiment, after a user completes vehicle fault diagnosis for one vehicle, the diagnostic device can be disconnected from that vehicle and connected to a subsequent vehicle for fault diagnosis. The diagnostic app and the diagnostic device can re-execute steps S101-S107 to perform vehicle fault diagnosis. The diagnostic app can also consider the diagnostic device authorized and directly establish an encrypted channel with the diagnostic device to perform vehicle fault diagnosis.

[0101] S109. Disconnect the diagnostic device from the diagnostic APP and exit vehicle fault diagnosis.

[0102] In this embodiment of the application, the diagnostic device returns verification failure data (e.g., the second value 0x01) to the diagnostic APP. Upon receiving the connection request, the diagnostic APP responds with a connection rejection and exits the vehicle fault diagnosis.

[0103] In this embodiment of the application, the diagnostic device may not return data to the diagnostic APP after determining that the three-party consistency verification has failed. After the diagnostic APP waits for a second period of time (e.g., 5 seconds) without receiving the data returned by the diagnostic device, it determines that the three-party consistency verification of the diagnostic device has failed and exits the vehicle fault diagnosis.

[0104] Based on the method shown in steps S101-S109 above, the MAC address of the authorized device and the corresponding dynamic key are pre-set in the whitelist database in the diagnostic APP, and the validity of the MAC address in the diagnostic device is verified when the diagnostic APP connects to the diagnostic device. The diagnostic device is verified based on the data returned by the diagnostic device, thereby establishing a secure encrypted channel and ensuring the security of vehicle fault diagnosis based on Bluetooth communication.

[0105] It should be understood that, as mentioned above Figure 3 The steps in the flowcharts are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise explicitly stated herein, there is no strict order in which these steps are performed; they can be executed in other orders. Furthermore, as mentioned above... Figure 3 The flowchart may include at least some steps or stages. These steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the steps or stages in other steps.

[0106] Figure 4 A flowchart of a three-party consistency verification method is shown, which specifically includes:

[0107] S201. The diagnostic device reads its own serial number, chip ID, Bluetooth MAC address, and the Bluetooth MAC address stored in the encrypted chip.

[0108] In this embodiment, after receiving a connection request from the diagnostic app, the diagnostic device reads its own device information for three-way consistency verification. A detailed description of the diagnostic app sending the connection request can be found in the foregoing. Figure 3 The steps shown in S104 will not be repeated here.

[0109] S202. The diagnostic device obtains the timestamp in the connection request, combines it with the chip ID to obtain the decryption key, and decrypts the dynamically encrypted data to obtain the first serial number and the first MAC address.

[0110] In this embodiment, the key used for AES encryption and the key used for decryption can be the same key. The diagnostic device can generate a decryption key using a timestamp and a chip ID, and decrypt the dynamically encrypted data to obtain a first serial number and a first MAC address. A detailed description of the diagnostic device's decryption of the data can be found in the foregoing. Figure 3 The steps shown in S105 will not be repeated here.

[0111] S203. The diagnostic device performs a three-way consistency comparison of the first serial number, the first MAC address, the serial number read by the device itself, the Bluetooth MAC address, and the Bluetooth MAC address stored in the encryption chip.

[0112] In this embodiment, the diagnostic device performs a three-way consistency check based on its own device information and the decoded data. A detailed description of the three-way consistency check performed by the diagnostic device can be found in the foregoing. Figure 3 The steps shown in S107 will not be repeated here.

[0113] In this embodiment, the diagnostic device can further determine whether the three-party consistency verification has passed. If the three-party consistency verification passes, it returns successful verification data (e.g., a first value of 0x00) to the diagnostic app; if the three-party consistency verification fails, it returns failed verification data (e.g., a second value of 0x01) to the diagnostic app or does not return any data. The specific execution method for the diagnostic device to return data based on the verification result can be referred to the foregoing. Figure 3 The steps shown in S108-S109 will not be repeated here.

[0114] Based on the method shown in steps S201-S203 above, the authorization of the diagnostic device can be verified through three-party consistency verification, and an encrypted channel with the diagnostic APP can be established after the verification is passed, allowing fault diagnosis of the vehicle connected to the diagnostic device, thus ensuring that the user uses the authorized diagnostic device to perform vehicle fault diagnosis.

[0115] It should be understood that, as mentioned above Figure 4 The steps in the flowcharts are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise explicitly stated herein, there is no strict order in which these steps are performed; they can be executed in other orders. Furthermore, as mentioned above... Figure 4 The flowchart may include at least some steps or stages. These steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the steps or stages in other steps.

[0116] Example 3

[0117] Figure 5 A schematic diagram of a diagnostic device module is shown. Figure 5 As shown, the diagnostic device 200 specifically includes the following modules:

[0118] The communication module 210 is used to upload the device information to the server and to receive connection requests sent by the diagnostic APP. The device information includes the first MAC address of Bluetooth, the first serial number of the diagnostic device 200, and the chip ID of the encryption chip.

[0119] Security chip module 220 is used to pre-store the second MAC address and chip ID.

[0120] The data decryption module 230 is used to decrypt dynamically encrypted data using the chip ID and the timestamp sent by the diagnostic APP.

[0121] The third-party verification module 240 is used to determine whether the three-party consistency verification of the decrypted dynamic encrypted data has passed. If the three-party consistency verification is passed, the diagnostic device establishes an encrypted channel with the diagnostic APP to perform fault diagnosis on the vehicle connected to the diagnostic device 200. Otherwise, the diagnostic device 200 refuses to connect.

[0122] It is understood that the functional division between the modules illustrated in the embodiments of this application is merely illustrative and does not constitute a limitation on the function of the diagnostic device 200. In other embodiments of this application, the diagnostic device 200 may also employ different modules or combinations of multiple modules to implement the functions of the diagnostic device 200.

[0123] Figure 6 A schematic diagram of a diagnostic app module is shown. (For example...) Figure 6 As shown, the diagnostic APP400 specifically includes the following modules:

[0124] The communication module 410 is used to obtain device information from the server, send connection requests to the diagnostic device, and receive response data returned by the diagnostic device.

[0125] The data encryption module 420 is used to determine the connectable diagnostic devices through a whitelist database and obtain dynamically encrypted data. The dynamically encrypted data is obtained by encrypting the first MAC address and the first serial number with a dynamic key. The dynamic key is generated in real time by the chip ID and the timestamp.

[0126] The connection request module 430 is used to generate a connection request containing dynamically encrypted data and a timestamp, and is also used to receive response data returned by the diagnostic device 200, determine whether to perform vehicle fault diagnosis through the diagnostic device. If the diagnostic device returns verification success data, the diagnostic APP 400 establishes an encrypted channel with the diagnostic device, allowing fault diagnosis of the vehicle connected to the diagnostic device. If the diagnostic device returns verification failure data or does not return response data, the diagnostic APP 400 terminates the connection.

[0127] The whitelist storage module 440 is used to store device information in the whitelist database.

[0128] It is understood that the functional division between the modules illustrated in the embodiments of this application is merely illustrative and does not constitute a limitation on the functionality of the diagnostic APP 400. In other embodiments of this application, the diagnostic APP 400 may also employ different modules than those in the above embodiments, or a combination of multiple modules, to implement the functionality of the diagnostic APP 400.

[0129] Figure 7 This is a software structure block diagram of a computer device 800 according to an embodiment of this application. The software structure of the computer device 800 may include, for example: Figures 1-6 The diagnostic app shown.

[0130] In computer devices, a layered architecture divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces.

[0131] In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer. The application layer may include a series of application packages.

[0132] like Figure 7 As shown, the application package may include applications such as camera, gallery, calendar, map, navigation, WLAN, Bluetooth, music, video, and SMS.

[0133] In this embodiment, the application framework layer provides an application programming interface (API) and programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0134] like Figure 7 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0135] In this embodiment, the window manager is used to manage window programs. The window manager can obtain the screen size, determine whether there is a status bar, lock the screen, and capture the screen, etc.

[0136] In this embodiment, the content provider stores and retrieves data, making that data accessible to applications. This data may include videos, images, audio, user activity logs, browsing history, and bookmarks.

[0137] In this embodiment, the view system includes visual controls, such as controls for displaying text and controls for displaying images. The view system can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

[0138] In this embodiment of the application, the resource manager provides the application with various resources, such as localized strings, icons, images, layout files, video files, etc.

[0139] In this embodiment, the notification manager enables applications to display notification information in the status bar. It can be used to convey informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of download completion or message alerts.

[0140] In this embodiment, the notification manager can also display notifications in the form of icons or scrollbar text in the system's top status bar, such as notifications from background applications, or notifications in the form of dialog windows on the screen. Examples include displaying text messages in the status bar, emitting alert sounds, or flashing indicator lights on electronic devices.

[0141] In this embodiment, the Android runtime includes a core library and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system. The core library consists of two parts: one part contains the functionalities that the Java language needs to call, and the other part contains the Android core library.

[0142] In this embodiment, the application layer and the application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0143] In the embodiments of this application, the system library may include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL), etc.

[0144] In this embodiment, the surface manager is used to manage the display subsystem and provides fusion of 2D and 3D layers for multiple applications.

[0145] In this embodiment, the media library supports playback and recording of various commonly used audio and video formats, as well as still image files. The media library can support multiple audio and video encoding formats, including MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0146] In this embodiment, the 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing, etc. The 2D graphics engine is a drawing engine for 2D drawing.

[0147] In this embodiment, the kernel layer is the layer between hardware and software. The kernel layer includes various driver programs such as display driver, camera driver, audio driver, and sensor driver.

[0148] like Figure 8 This illustration shows the hardware structure of a computer device 800 provided in an embodiment of this application. The computer device 800 may include the aforementioned... Figures 1-5 The diagnostic device shown. The computer device 800 includes: a processor 801, a memory 802, a communication module 804, and a computer program 803 stored in the memory 802 and executable on the processor 801. When the processor 801 executes the computer program 803, it implements the above-mentioned... Figures 1-6 The execution steps are shown. For example, the computer program 803 described above can be divided into one or more units / modules, which are stored in the memory 802 and executed by the processor 801 to complete this application.

[0149] The aforementioned one or more units / modules may be a series of computer program instruction segments capable of performing a specific function. These instruction segments describe the execution process of the aforementioned computer program 803 within the aforementioned computer device 800. For example, the aforementioned computer program 803 may be used to perform actions such as... Figure 3 The secure communication method shown in steps S101-S109 has specific functions or mechanisms described in the above embodiments and will not be repeated here.

[0150] Those skilled in the art will understand that Figure 8 This is merely an example of computer device 800 and does not constitute a limitation on computer device 800. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device 800 described above may also include input / output devices, network access devices, buses, etc.

[0151] The processor 801 mentioned above can be a CPU, or other general-purpose processors, DSPs, ASICs, FPGAs, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0152] In some embodiments, the processor 801 may include one or more interfaces. Interfaces may include I2C, I2S, PCM, URAT, MIPI, GPIO, OBD, and / or USB, etc. It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the computer device 800. In other embodiments of this application, the computer device 800 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0153] In some embodiments, the computer device 800 can connect internal devices and modules through one or more interfaces. The aforementioned memory 802 can be an internal storage unit of the computer device 800, such as a hard disk or RAM. The aforementioned memory 802 can also include both internal storage units and external storage devices. The aforementioned memory 802 is used to store the aforementioned computer program and other programs and data required by the computer device 800. The aforementioned memory 802 can also be used to temporarily store data that has been output or will be output.

[0154] The communication module 804 can provide solutions for wireless communication applications such as WLAN, BT, GNSS, FM, NFC, and IR on computer equipment 800. The communication module 804 can be one or more devices integrating at least one communication processing module. The communication module 804 receives electromagnetic waves via an antenna, demodulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 801. The communication module 804 can also receive signals to be transmitted from the processor 801, frequency-modulate and amplify them, and then convert them into electromagnetic waves for radiation via an antenna.

[0155] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the above equipment can be divided into different functional units or modules to complete all or part of the functions described above.

[0156] The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of software functional units.

[0157] In the embodiments of this application, the specific names of each functional unit and module are only for easy distinction and are not intended to limit the scope of protection of this application. It should be understood that each step in the above-described method embodiments provided in this application can be completed by the integrated logic circuits in the processor hardware or by instructions in software form. The method steps disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0158] This application also provides a computer program product comprising: a computer program (also referred to as code or instructions) that, when run, causes a computer to perform the method executed by the diagnostic device in the above embodiments.

[0159] The various embodiments of this application can be combined arbitrarily to achieve different technical effects.

[0160] In the foregoing 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.

[0161] The computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.

[0162] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is run, it causes the computer to perform the method executed by the computer device in any of the foregoing embodiments.

[0163] like Figure 9 As shown, the computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0164] The computer-readable storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives).

[0165] Those skilled in the art will understand that implementing all or part of the processes in the foregoing embodiments can be accomplished by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the foregoing method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0166] In summary, the above description is merely an embodiment of the technical solution of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made according to the disclosure of the present invention should be included within the scope of protection of the present invention.

Claims

1. A secure communication method, characterized in that, The method includes: The diagnostic device uploads device information to the server. The diagnostic device is equipped with Bluetooth and an encryption chip. The device information includes the first MAC address of the Bluetooth, the first serial number of the diagnostic device, and the chip ID of the encryption chip. The diagnostic application (APP) obtains the device information from the server and stores it in a whitelist database. The whitelist database is used to indicate the diagnostic devices that the diagnostic application can connect to. The diagnostic APP generates a connection request containing dynamically encrypted data and a timestamp, and sends it to the diagnostic device. The dynamically encrypted data is obtained by encrypting the first MAC address and the first serial number with a dynamic key. The dynamic key is generated in real time by the chip ID and the timestamp. The diagnostic device receives the connection request, reads the chip ID of the encryption chip, and decrypts the dynamic encrypted data based on the chip ID and the timestamp; The diagnostic device reads the pre-stored second MAC address from the encryption chip, reads the third MAC address from the Bluetooth, reads the second serial number of the diagnostic device in its own memory, and determines whether the three-party consistency verification passes based on the dynamic encrypted data. If the tripartite consistency verification passes, the diagnostic APP establishes an encrypted channel with the diagnostic device to perform fault diagnosis on the vehicle connected to the diagnostic device. Otherwise, the diagnostic device refuses to connect.

2. The method according to claim 1, characterized in that, The dynamic key is generated by concatenating the chip ID and the timestamp, and is used for Advanced Encryption Standard (AES) encryption.

3. The method according to claim 1, characterized in that, The whitelist database is established by the device information downloaded by the diagnostic APP from the server.

4. The method according to claim 1, characterized in that, The encryption chip is a separate Security Element (SE) chip.

5. The method according to claim 1, characterized in that, The step of determining whether the three-party consistency verification passes based on the dynamically encrypted data includes: Compare whether the first serial number and the second serial number are consistent; Compare whether the first MAC address and the second MAC address are the same; Compare whether the first MAC address and the third MAC address are consistent; Only after all three comparisons are consistent will the diagnostic device determine that the three-party consistency verification has failed and return preset verification success data to the diagnostic APP.

6. The method according to claim 1, characterized in that, The diagnostic device refuses to connect, including: The diagnostic device returns preset verification failure data or does not respond with data to refuse the connection.

7. The method according to claim 1, characterized in that, The validity period of the timestamp is a first duration. When the diagnostic APP detects that the duration from the timestamp to the current time exceeds the first duration, the connection request becomes invalid.

8. A secure communication system, characterized in that, include: The diagnostic device is equipped with Bluetooth and an encryption chip. It is used to upload device information to a server, and after receiving a connection request, it reads the chip ID of the encryption chip, decrypts dynamically encrypted data based on the chip ID and timestamp, reads a pre-stored second MAC address from the encryption chip, reads a third MAC address from the Bluetooth, reads the second serial number of the diagnostic device itself, and determines whether the three-party consistency verification passes based on the dynamically encrypted data. If the three-party consistency verification passes, the diagnostic device establishes an encrypted channel with the diagnostic APP to perform fault diagnosis on the vehicle connected to the diagnostic device; otherwise, the diagnostic device refuses to connect. A server is used to store device information of the diagnostic device, including the first MAC address of the Bluetooth device, the first serial number of the diagnostic device, and the chip ID of the encryption chip. The diagnostic app is used to obtain device information from the server and store it in a whitelist database. It is also used to determine the diagnostic devices that the diagnostic app can connect to in the whitelist database and generate a connection request containing the dynamic encrypted data and a timestamp. The dynamic encrypted data is obtained by encrypting the first MAC address and the first serial number with a dynamic key. The dynamic key is generated in real time by the chip ID and the timestamp.

9. A computer device, characterized in that, The device includes one or more memories and one or more processors; the memories are coupled to the one or more processors, the memories are used to store computer program code, the computer program code including computer instructions, and the one or more processors invoke the computer instructions to cause the computer device to implement the secure communication method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing computer instructions thereon, characterized in that, When the computer instructions are executed by the processor, they implement the secure communication method according to any one of claims 1 to 7.

Images