Vehicle-cloud collaborative tls link intelligent diagnosis method, device, equipment, medium and product

Abstract

This application discloses a method, device, equipment, medium, and product for intelligent diagnosis of vehicle-to-cloud collaborative TLS links, relating to the interdisciplinary fields of vehicle network information security and artificial intelligence. The method includes: acquiring multi-source data; performing multimodal temporal dynamic alignment on the multi-source data to obtain aligned data; dividing the aligned data according to the TLS handshake state machine to obtain segmented slices; extracting features from the segmented slices to obtain structured feature vectors; converting the structured feature vectors into hierarchical structured prompts, and using a retrieval enhancement generation mechanism to retrieve relevant knowledge entries from a cryptographic knowledge graph to obtain retrieval results; inputting the hierarchical structured prompts and retrieval results into a large language model inference engine, executing an inference chain including fault delimitation, cross-modal contradiction detection, root cause tracing, and conclusion generation, and outputting diagnostic results. This application can improve the efficiency and capability of TLS link diagnosis.

Description

Technical Field

[0001] This application relates to the field of interdisciplinary technology of vehicle network information security and artificial intelligence, and in particular to a vehicle-cloud collaborative TLS link intelligent diagnostic method, device, equipment, medium and product. Background Technology

[0002] In the Vehicle-to-Everything (V2X) system, numerous heterogeneous terminals, such as in-vehicle telematics boxes (T-BOX), digital video recorders (DVRs), intelligent domain controllers (IDCs), and diagnostic tools, run on Linux, Android, or various real-time operating systems (RTOS). When establishing secure connections with the cloud backend, these devices rely on the PKI (Public Key Infrastructure) system and the TLS (Transport Layer Security) protocol. However, during actual integration, debugging, and after-sales service, TLS connections are highly susceptible to failure due to environmental differences (e.g., mismatch between national and commercial cryptographic algorithm suites, incomplete certificate chains, and abnormal calls to the underlying hardware cryptographic engine).

[0003] The current technology has the following prominent problems: (1) Troubleshooting is highly dependent on human experience. Safety engineers need to manually collect the running logs of the vehicle software development kit (SDK) and the cloud gateway logs, and use network analysis tools (such as Wireshark) to capture network packets and compare and analyze them one by one, which is extremely inefficient.

[0004] (2) Difficulty in aligning log timestamps in heterogeneous environments. Different operating systems (Linux, Android, RTOS) have different system clock precision and time zone configurations. Vehicle-side devices often lack Network Time Protocol (NTP) time synchronization capabilities, resulting in a second-level or even minute-level deviation between log timestamps and actual network packet times, making cross-end event correlation almost impossible.

[0005] (3) There is no direct mapping between network layer errors and application layer root causes. For example, the TLS Fatal Alert Decrypt Error during the TLS handshake / transmission phase may be caused by more than ten different underlying reasons (including cipher suite mismatch, certificate parsing failure, hardware encryption engine parameter error, memory alignment defect, etc.), and the real root cause cannot be located based on network layer information alone.

[0006] (4) Lack of automated closed-loop verification methods. Even if the suspected cause is located, the test environment still needs to be manually rebuilt for verification after the repair, and the overall troubleshooting cycle takes several days, which seriously restricts the project delivery efficiency and after-sales service response speed. Summary of the Invention

[0007] The purpose of this application is to provide a method, device, equipment, medium, and product for intelligent diagnosis of vehicle-cloud collaborative TLS links, which can improve the efficiency and capability of TLS link diagnosis.

[0008] To achieve the above objectives, this application provides the following solution: Firstly, this application provides a vehicle-cloud collaborative TLS link intelligent diagnostic method, including: Acquire multi-source data; the multi-source data is collected based on diagnostic probes deployed on vehicle-side devices and cloud backends, and transmitted through an independent encrypted reporting channel; the multi-source data includes: network traffic packets during the TLS handshake phase, device application layer operation logs, and device system environment fingerprint information; The multi-source data is dynamically aligned in a multimodal time series to obtain aligned data; The aligned data is divided according to the TLS handshake state machine to obtain a segment; the segment includes: negotiation phase segment, certificate exchange phase segment, key exchange phase segment, authentication phase segment, and abnormal termination phase segment; Feature extraction is performed on the segmented slices to obtain structured feature vectors; the dimensions of the feature extraction include three dimensions: network packet features, device log features, and environmental fingerprint features; The structured feature vector is transformed into a hierarchical structured Prompt, and a retrieval enhancement generation mechanism is used to retrieve relevant knowledge entries from the cryptographic knowledge graph to obtain retrieval results; The hierarchical structured Prompt and the retrieval results are input into the large language model inference engine to execute an inference chain that includes fault delimitation, cross-modal contradiction detection, root cause tracing, and conclusion generation, and outputs diagnostic results; the diagnostic results include: root cause diagnosis conclusions and confidence scores.

[0009] Secondly, this application provides a vehicle-cloud collaborative TLS link intelligent diagnostic device, comprising: The data acquisition module is used to acquire multi-source data. The multi-source data is collected based on diagnostic probes deployed on the vehicle-side device and the cloud backend, and transmitted through an independent encrypted reporting channel. The multi-source data includes: network traffic packets during the TLS handshake phase, device application layer operation logs, and device system environment fingerprint information. The alignment module is used to perform multimodal temporal dynamic alignment on the multi-source data to obtain aligned data; The slice partitioning module is used to divide the aligned data according to the TLS handshake state machine to obtain the partitioned slices; the partitioned slices include: negotiation phase slices, certificate exchange phase slices, key exchange phase slices, authentication phase slices, and abnormal termination phase slices. The feature extraction module is used to extract features from the segmented slices to obtain structured feature vectors; the dimensions of the feature extraction include three dimensions: network packet features, device log features, and environmental fingerprint features. The retrieval module is used to convert the structured feature vector into a hierarchical structured Prompt, and to retrieve relevant knowledge entries from the cryptographic knowledge graph using a retrieval enhancement generation mechanism to obtain retrieval results; The diagnostic module is used to input the hierarchical structured Prompt and the retrieval results into the large language model inference engine, execute an inference chain that includes fault delimitation, cross-modal contradiction detection, root cause tracing and conclusion generation, and output diagnostic results; the diagnostic results include: root cause diagnosis conclusions and confidence scores.

[0010] Thirdly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described vehicle-cloud collaborative TLS link intelligent diagnostic method.

[0011] Fourthly, this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described vehicle-cloud collaborative TLS link intelligent diagnostic method.

[0012] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the aforementioned vehicle-cloud collaborative TLS link intelligent diagnostic method.

[0013] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application provides a method, apparatus, device, medium, and product for intelligent diagnosis of TLS links in vehicle-cloud collaboration. By dynamically aligning the acquired multi-source data in a multimodal time sequence, then dividing it according to the TLS handshake state machine, and finally executing inference chain reasoning based on a large language model inference engine, the fault location cycle of TLS links can be shortened, thereby improving diagnostic efficiency and accuracy. Furthermore, the multimodal time sequence dynamic alignment of multi-source data in this application can improve cross-layer penetration diagnostic capabilities. Therefore, this application can improve the efficiency and capability of TLS link diagnosis. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the 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.

[0015] Figure 1 A flowchart for the intelligent diagnostic method of TLS link in vehicle-cloud collaboration; Figure 2 This is the overall architecture diagram for intelligent diagnostics of the TLS link in vehicle-cloud collaboration; Figure 3 A flowchart for multimodal time-series dynamic alignment; Figure 4 A schematic diagram of TLS state machine slicing and feature extraction; Figure 5 This is a diagram illustrating the inference chain diagnosis. Figure 6 Flowchart for closed-loop verification and knowledge accumulation; Figure 7 This is a schematic diagram of a scenario for an example embodiment; Figure 8 This is a structural diagram of the vehicle-cloud collaborative TLS link intelligent diagnostic device; Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0016] The technical solutions of 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. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0017] To overcome the shortcomings of current technologies, such as the heavy reliance on manual packet capture analysis for TLS link fault diagnosis, difficulty in aligning logs in heterogeneous environments, difficulty in locating errors in underlying hardware encryption interfaces, and lack of automatic regression verification after repair, this application aims to utilize a Large Language Model (LLM) to achieve cross-modal joint analysis of network traffic packets and device end logs (device application layer operation logs), automatically output highly accurate root cause diagnosis reports and repair solutions, and confirm the effectiveness of the repair through a closed-loop verification mechanism.

[0018] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0019] In one exemplary embodiment, such as Figure 1 As shown, a vehicle-cloud collaborative TLS link intelligent diagnostic method is provided, including: Step 100: Obtain multi-source data. Multi-source data is obtained by collecting data from diagnostic probes deployed on the vehicle-side device and the cloud backend, and transmitting it through an independent encrypted reporting channel; the multi-source data includes: network traffic packets during the TLS handshake phase, device application layer operation logs, and device system environment fingerprint information.

[0020] Step 200: Perform multimodal temporal dynamic alignment on the multi-source data to obtain aligned data.

[0021] This includes performing multimodal time-series dynamic alignment on multi-source data to obtain aligned data, specifically including: When the runtime logs in multi-source data are missing timestamps, an event causal order inference mechanism based on the inherent causal order of the TLS protocol state machine is adopted. Combined with the sequence number or monotonically increasing counter in the runtime log, the timing position of the missing event is inferred and inserted into the alignment timeline to perform data alignment.

[0022] When the runtime logs in the multi-source data have timestamps, the preset key anchor events in the TLS handshake state machine are used as control points, and a multi-sequence dynamic time warping algorithm is adopted to eliminate clock offsets between heterogeneous devices in order to perform data alignment.

[0023] Based on the unified timeline view generated after the data alignment operation, the multi-source data is interwoven and arranged in chronological order to form a single ordered sequence of events, thus obtaining the aligned data.

[0024] Step 300: Divide the aligned data according to the TLS handshake state machine to obtain the slices. The slices include: negotiation phase slice, certificate exchange phase slice, key exchange phase slice, authentication phase slice, and abnormal termination phase slice.

[0025] Step 400: Extract features from the segmented data to obtain structured feature vectors. The features extracted include three dimensions: network packet features, device log features, and environmental fingerprint features.

[0026] Specifically, feature extraction is performed on the segmented slices to obtain structured feature vectors, including: Feature extraction is performed on the segmented data to obtain the extracted features; noise reduction and filtering are then applied to the extracted features to obtain a structured feature vector; the noise reduction and filtering process includes: Remove duplicate heartbeat log entries and filter system-level logs that are not relevant to diagnosis; system-level logs that are not relevant to diagnosis include CPU load and network bandwidth statistics.

[0027] Merge consecutively occurring identical error codes, retaining only the first and last occurrences and the total number of occurrences.

[0028] Step 500: Convert the structured feature vector into a hierarchical structured Prompt, and use a retrieval enhancement generation mechanism to retrieve relevant knowledge entries from the cryptographic knowledge graph to obtain the retrieval results.

[0029] The hierarchical structured Prompt uses a hierarchical template structure; the hierarchical template structure has five layers: the first layer is the fault overview layer, the second layer is the network evidence layer, the third layer is the device evidence layer, the fourth layer is the environmental constraints layer, and the fifth layer is the instruction layer.

[0030] The fault overview layer describes the fault phenomenon in natural language; the network evidence layer lists the key feature values ​​in network traffic packets in structured JSON; the key feature values ​​in network traffic packets include the list of cipher suites provided by the client, the suites selected by the server, the certificate chain digest, and the length and time interval of each message during the handshake process.

[0031] The device evidence layer uses structured JSON to list key feature values ​​in the device application layer runtime logs. These key feature values ​​include function call return value sequences, hardware engine input / output parameter length comparisons, exception error codes, and their context log lines.

[0032] The environment constraint layer lists the device system environment fingerprint information; the device system environment fingerprint information includes the operating system version, TLS library version, HSM model and firmware version.

[0033] The instruction layer is used to combine cryptographic knowledge graphs to retrieve relevant knowledge entries and perform cross-modal causal reasoning.

[0034] Step 600: Input the hierarchical structured Prompt and retrieval results into the large language model inference engine, execute the inference chain including fault delimitation, cross-modal contradiction detection, root cause tracing, and conclusion generation, and output the diagnostic results. The diagnostic results include: root cause diagnosis conclusions and confidence scores.

[0035] The hierarchical structured Prompt and retrieval results are input into the large language model inference engine, which executes an inference chain that includes fault delimitation, cross-modal contradiction detection, root cause analysis, and conclusion generation, and outputs diagnostic results, specifically including: The hierarchical structured Prompt and the search results are input into the large language model inference engine. The search results serve as the inference window, and an inference chain including fault delimitation, cross-modal contradiction detection, root cause tracing, and conclusion generation is executed.

[0036] Specifically, during the fault delimitation phase, the following steps are performed: based on the Alert encoding and handshake interruption phase slices in the hierarchical structured Prompt, the range of fault types is narrowed down.

[0037] The cross-modal conflict detection phase involves: narrowing down the range of fault types, comparing network layer features with device layer features at the same time, and identifying conflict points.

[0038] The root cause analysis phase involves combining environmental constraint information and compatibility / constraint rules in the cryptographic knowledge graph to determine the root cause of the contradiction.

[0039] During the conclusion generation phase, the following steps are performed: Based on the root cause of the contradiction, a structured description of the root cause diagnosis conclusion is output, along with a confidence score, to obtain the diagnosis result.

[0040] As an optional implementation, the vehicle-cloud collaborative TLS link intelligent diagnostic method further includes: When the confidence score is lower than the preset threshold, the collection granularity of a preset specific log dimension is increased according to the automatically issued supplementary collection instruction, so as to supplement the data of multiple sources.

[0041] Based on the supplemented multi-source data, return to the step of "perform multi-modal time-series dynamic alignment of multi-source data to obtain aligned data" to execute the diagnostic process.

[0042] Based on the root cause diagnosis conclusion, a pre-set strategy template for repair is matched to generate a structured repair work order, and a closed-loop regression verification is automatically triggered after the repair is implemented. Specifically, after the repair is implemented, a controlled TLS handshake test connection using the exact same connection parameters and certificates as the fault scenario is automatically triggered to recollect packets and logs and execute the complete diagnostic process. If the closed-loop regression verification passes, the complete diagnostic case is archived to the knowledge base for subsequent retrieval and enhancement generation mechanisms. If the closed-loop regression verification fails, the diagnostic process loop is restarted.

[0043] In practical applications, the method mentioned in this application may also include the following execution steps: Step 1: Deploy diagnostic probes on the vehicle-side device and the cloud backend respectively to collect three types of data: network traffic packets during the TLS handshake phase, device application layer operation logs, and device system environment fingerprint information. Report these three types of data (i.e., multi-source data) to the central diagnostic platform through an independent encrypted channel.

[0044] In step one, the vehicle-side diagnostic probe is embedded in the device's operating environment as a dynamic library or an independent daemon process. It collects TLS handshake messages by setting a bypass mirror hook function at the Socket layer of the network protocol stack. The messages only capture data from the Transmission Control Protocol (TCP) three-way handshake to the Application Data first packet stage. The vehicle-side probe and the cloud probe report data through an independent encrypted channel established by a pre-shared key (PSK) PSK-TLS or out-of-band key negotiation mechanism to avoid forming a circular dependency with the diagnosed link.

[0045] Step 2: The central diagnostic platform performs multimodal time-series dynamic alignment on multi-source data from the vehicle and cloud. Using key anchor events in the TLS handshake state machine as control points, it employs a multi-sequence dynamic time warping algorithm to eliminate clock offsets between heterogeneous devices and generate a unified timeline view. Figure 3 This is a flowchart for dynamic alignment of multimodal timing.

[0046] In step two, the coarse-grained clock offset is estimated by subtracting half of the round-trip delay from the difference between the send / receive timestamps of the ClientHello message in the vehicle-side and cloud-side Packet Capture (PCAP) messages of the same TLS session. The fine alignment uses the timestamps of six key anchor events—ClientHello send / receive, ServerHello send / receive, Certificate message send / receive, ServerKeyExchange send / receive, CertificateVerify send / receive, and Finished message send / receive—in the four data streams of vehicle-side messages, cloud-side messages, vehicle-side logs, and cloud-side logs as control points to construct a multi-sequence dynamic time warping alignment model.

[0047] For cases where precise timestamps are missing in the logs, an event causal order inference mechanism based on the inherent causal order of the TLS protocol state machine is adopted. By combining the sequence number or monotonically increasing counter in the log, the temporal position of the missing event is inferred and inserted into the aligned timeline.

[0048] Step 3: Divide the aligned data into negotiation phase slices, certificate exchange phase slices, key exchange phase slices, authentication phase slices, and abnormal termination phase slices according to the TLS handshake state machine. Extract a structured feature vector with three dimensions for each slice: network packet features, device log features, and environmental fingerprint features. Figure 4 This is a schematic diagram of TLS state machine slicing and feature extraction.

[0049] The noise reduction filtering in step three includes: removing duplicate heartbeat log entries, filtering system-level logs that are not related to diagnosis, and merging consecutively repeated identical error codes to retain only the first and last occurrences and the total number of occurrences.

[0050] Step 4: Transform the structured feature vector into a hierarchical structured Prompt. Use the retrieval enhancement generation mechanism to retrieve relevant knowledge entries from the cryptographic knowledge graph. Input the Prompt and retrieval results into the large language model inference engine, execute the inference chain including fault delimitation, cross-modal contradiction detection, root cause tracing and conclusion generation, and output the root cause diagnosis conclusion and confidence score. Figure 5 This is a diagram illustrating the inference chain diagnosis.

[0051] The cryptographic knowledge graph in step four is stored in the form of triples. Entity types include cryptographic algorithms, protocol versions, certificate extensions, hardware security module models, TLS Alert encodings, error codes, and operating system platforms. Relationship types include compatibility, incompatibility, dependency, cause, constraint, and substitution.

[0052] In step four, when the root cause diagnosis confidence score is lower than the preset threshold, the central diagnostic platform automatically sends a supplementary collection instruction to the relevant probes to increase the collection granularity of specific log dimensions, and re-executes the diagnostic process from step two to step four after the supplementary data arrives.

[0053] Step 5: Match the remediation strategy template based on the root cause diagnosis conclusion, generate a structured remediation work order, and automatically trigger closed-loop regression verification after the remediation is implemented. Figure 6 A flowchart for closed-loop verification and knowledge accumulation.

[0054] Step 5, the closed-loop regression verification, includes: automatically triggering a controlled TLS handshake test connection using the exact same connection parameters and certificates as the fault scenario after the remediation measures are implemented; re-collecting packets and logs and executing the complete diagnostic process; if the verification passes, the complete diagnostic case is archived to the knowledge base for subsequent retrieval and enhancement generation mechanisms; if the verification fails, the diagnostic loop is re-entered.

[0055] The method in this application supports a dual task isolation mechanism based on device identifier and session identifier, which can simultaneously receive and process parallel diagnostic requests from multiple devices of different models. Each diagnostic task is executed independently but shares the same cryptographic knowledge graph and repair strategy knowledge base.

[0056] Figure 2 This is a diagram illustrating the overall architecture of intelligent diagnostics for vehicle-cloud collaborative TLS links. The overall architecture of this application comprises four layers: a data acquisition layer, a data processing layer, an intelligent diagnostic layer, and a policy output layer. Distributed multimodal data (multi-source data) collection and secure reporting: S101. Deploy a lightweight diagnostic probe (DiagnosticAgent) on the vehicle-side equipment (T-BOX, DVR, IDC, diagnostic instrument, etc.). The probe is embedded in the device's runtime environment as a dynamic library (.so / .dll) or a standalone daemon process, occupying no more than 8MB of memory. The vehicle-side probe is responsible for collecting the following three types of data: The first category is network traffic packets during the TLS handshake phase. This is captured by setting a bypass mirror hook function in the Socket layer of the device's network protocol stack. The output is a standard PCAP format file, capturing only packets during the TLS handshake phase (from the TCP three-way handshake to the first Application Data packet) to reduce data volume and privacy risks.

[0057] The second category is device application layer operation logs, including function call chain logs of TLS / SSL libraries (such as OpenSSL and GmSSL), certificate loading and parsing logs, and hardware encryption engine (Engine / Provider) call logs (including input parameters, output parameters and return codes).

[0058] The third category is device system environment fingerprint information, including operating system type and version, TLS library name and version number, list of installed root certificates (including fingerprint hashes), hardware security module (HSM) model and firmware version.

[0059] S102. Deploy corresponding cloud probes (Cloud Agents) in the cloud backend (such as Nginx, Message Queuing Telemetry Transport (MQTT) Broker, API Gateway, and other access gateways) to collect TLS handshake messages, gateway access logs, certificate issuance records, and cryptographic algorithm configuration parameters on the cloud side.

[0060] The S103, vehicle-side probe, and cloud-based probe each upload collected data to the central diagnostic platform's data access gateway via independent encrypted reporting channels (using pre-shared key PSK-TLS or out-of-band key negotiation mechanisms to avoid circular dependencies with the diagnosed link). During transmission, the log content undergoes field-level anonymization, replacing privacy fields such as device serial number and vehicle identification number (VIN) with one-way hash mapping values.

[0061] S104. The data access gateway performs integrity verification (based on HMAC-SM3 message authentication code) and format standardization on the received data: the logs reported by different devices are uniformly converted into JSON Lines format, and each log record contains the following necessary fields: device identifier (device_id), data source type (source_type, with the value of pcap / app_log / env_info), raw timestamp (raw_timestamp), event type code (event_code), and event payload (payload).

[0062] Multimodal temporal dynamic alignment: S201. After receiving multi-source data from vehicle-side probes and cloud-side probes, the central diagnostic platform first performs clock offset estimation. The specific method is as follows: extract the sending timestamp T_client of the ClientHello message from the vehicle-side PCAP message, and extract the receiving timestamp Tserver of the same ClientHello message from the cloud PCAP message (matching the same session through the unique value of the ClientHello.random field). Then, the coarse-grained clock offset Δtcoarse = Tserver - Tclient - RTT / 2, where RTT is the round-trip delay estimated by the TCP SYN / SYN-ACK time difference.

[0063] S202. Building upon coarse-grained clock calibration, a fine-grained alignment method based on TLS handshake state machine anchor points is further adopted. Six key anchor events in the TLS handshake state machine are defined: Anchor point A1: ClientHello send / receive; Anchor point A2: ServerHello send / receive; Anchor point A3: Certificate message send / receive; Anchor point A4: ServerKeyExchange send / receive (if applicable); Anchor point A5: CertificateVerify send / receive; Anchor point A6: Finished message send / receive.

[0064] Using the timestamps of the anchor points appearing in the four data streams (vehicle-side messages, cloud-side messages, vehicle-side logs, and cloud-side logs) as control points, a Multi-Sequence Dynamic Time Warping (DTW) alignment model is constructed. Its mathematical expression is: for the four time series Scar_pcap, Scloud_pcap, Scar_log, and Scloud_log, with the anchor events as alignment constraints, solve for the global alignment cost Cost = Σi Σ{j≠i} |T i (A k ) - T j (A k )| 2 Minimize the time offset function δ i (t). After alignment, the time deviation of the same TLS handshake event in the four data streams is normalized to within ±5ms precision.

[0065] Where Cost is the global alignment cost; i and j are both data stream numbers, with a maximum value of 4. Cost represents the total penalty for placing the current 4 data streams on a single timeline, indicating the distance between all anchor points with the same name. T is the timestamp; A k This is the k-th anchor event; the maximum value of k is 6.

[0066] T i T is the timestamp corresponding to the i-th data stream; j Let be the timestamp corresponding to the j-th data stream.

[0067] S203. For cases where precise timestamps are missing in logs, which are common in Real-Time Operating System (RTOS) environments, a log event causal order inference mechanism is adopted: based on the inherent causal order of the TLS protocol state machine (e.g., "certificate resolution" must occur after "Certificate message reception" and "signature operation" must occur before "CertificateVerify message sending"), combined with the sequence number or monotonically increasing counter in the log, the timing position of the missing event is inferred and inserted into the aligned timeline.

[0068] S204. After alignment, a unified timeline view is generated, interweaving the events from the four data streams in the calibrated chronological order to form a single, ordered sequence of events. Each event in this sequence is labeled with its source (vehicle message / cloud message / vehicle log / cloud log) and its absolute position on the unified timeline.

[0069] TLS state machine feature slicing and multidimensional feature extraction: S301. Divide the aligned unified timeline event sequence into the following five phase slices according to the TLS handshake state machine: Slice P1: Negotiation phase slice (ClientHello-ServerHello), corresponding to the cipher suite negotiation process.

[0070] Slice P2: Certificate exchange phase slice (Certificate-CertificateRequest), corresponding to certificate chain transmission and parsing.

[0071] Slice P3: Key exchange phase slice (ServerKeyExchange - ClientKeyExchange), corresponding to the key negotiation process.

[0072] Slice P4: Certificate Verify-Finished slice, corresponding to signature verification and integrity verification.

[0073] Slice P5: Abnormal Termination Phase Slice (Alert message and all events within a 200ms time window before and after it).

[0074] When the TLS handshake is interrupted at a certain stage, the last valid slice is the faulty slice, which is analyzed together with slice P5.

[0075] S302. Perform multi-dimensional feature extraction on the data within each slice to generate a structured feature vector. Specific extraction dimensions include: (a) Network message characteristic dimension: A list of cipher suites supported by the client and their order of priority.

[0076] The cipher suite selected by the server.

[0077] TLS protocol version number (such as TLSv1.2, TLSv1.3, or Transport Layer Cryptography Protocol (TLCP)).

[0078] The list of extension fields includes SNI (Server Name Indication), Supported Groups, Signature Algorithms, etc.

[0079] The Level (Warning / Fatal) and Description encoding values ​​of the Alert message (e.g., 20=bad_record_mac (error in record message authentication code), 40=handshake_failure (failed handshake negotiation), 42=bad_certificate (invalid certificate), 51=decrypt_error (decryption / signature verification error), etc.).

[0080] The certificate chain includes the serial number of each certificate, the signature algorithm OID (Object Identifier), the validity period, the Key Usage extension, and the Extended Key Usage extension.

[0081] The byte length of each handshake message (used to detect truncation or padding anomalies).

[0082] (b) Device log feature dimensions: The sequence of TLS / SSL library function calls and the return values ​​of each function (such as the SSL_get_error value corresponding to SSL_do_handshake returning -1).

[0083] The field extraction status (success / failure / skip) during the ASN.1 (Abstract Syntax Notation One) DER encoding parsing process includes the parsed OID value and the encoding exceptions encountered (such as Tag Mismatch, Length Overflow).

[0084] The hardware encryption engine's method call sequence (such as engine_ecc_method_sign, engine_sm2_method_encrypt, engine_rsa_method_decrypt), as well as the input data length, output data length, and return error code for each call.

[0085] The size of the buffers related to cryptographic operations in the memory allocation and deallocation log (used to detect memory alignment and truncation issues).

[0086] (c) Environmental fingerprint feature dimensions: Operating system type and kernel version (affect memory alignment, byte order, etc.).

[0087] TLS library version (different versions have different compatibility with certificate extensions, such as the difference in the provider mechanism between OpenSSL 1.1.1 and 3.0).

[0088] The coverage of the root certificate trust store (whether it includes the required CA root certificate and intermediate certificates).

[0089] HSM firmware version (affects the supported algorithm types and the maximum key length).

[0090] Compilation toolchain information (such as the target architecture for cross-compilation, which affects the memory layout of the structure).

[0091] S303. Denoising and filtering are performed on the extracted features. Denoising rules include: removing duplicate heartbeat log entries; filtering system-level logs irrelevant to diagnosis (such as CPU load, network bandwidth statistics, etc.); merging consecutively recurring identical error codes, retaining only the first and last occurrences and the total number of occurrences. The compression rate of the denoised feature sequence is typically 60%-80%, ensuring the signal-to-noise ratio of subsequent AI inference inputs.

[0092] AI joint inference enhanced by cryptographic knowledge graphs and Retrieval-Augmented Generation (RAG): S401. Construct a domain-specific cryptographic knowledge graph (Crypto-KG). The knowledge graph is stored in the form of triples (entity-relation-entity), containing the following entity types and relations: Entity type: cryptographic algorithm (e.g., SM2, RSA-2048, ECDSA-P256, SM4-CBC), protocol version (e.g., TLSv1.2, TLSv1.3, TLCP), certificate extensions (e.g., Key Usage, Extended Key Usage, Subject Alternative Name, Authority Information Access), hardware security module model (e.g., SE chip A, B from a certain brand), TLS Alert encoding (e.g., 40, 42, 48, 51, etc.), error code (e.g., OpenSSL's ERR_R_INTERNAL_ERROR), operating system platform (e.g., Linux ARM64, Android AArch64, FreeRTOS Cortex-M4).

[0093] Relationship types include: "Compatible" (e.g., SM2 is compatible with the TLCP protocol), "Incompatible" (e.g., the ML-KEM algorithm in a Post-Quantum Cryptography (PQC) hybrid certificate is not parsed by GmSSL 2.x version), "Dependent" (e.g., ECDSA-P256 signature depends on the secp256r1 curve parameter), "Cause" (e.g., Alert 40 handshake_failure → usually caused by the client and server not having a common cipher suite), "Constraint" (e.g., the maximum length of input data for a single signature of a certain HSM model is 64 bytes), and "Substitute" (e.g., ECDHE_SM4_SM3 can replace ECC_SM4_SM3 for key exchange).

[0094] The knowledge graph contains no fewer than 5,000 pre-defined triples, covering mainstream cryptographic algorithms, national / commercial cryptographic standards (GM / T 0024-2014, GM / T 0028-2014, etc.), common HSM model constraints, version compatibility matrices of mainstream TLS libraries (OpenSSL, GmSSL, BoringSSL, wolfSSL), and mapping relationships between common Alert encodings and root causes.

[0095] S402. The extracted structured feature sequences are transformed into a diagnostic Prompt, i.e., a hierarchical structured Prompt. The Prompt uses a hierarchical template structure with five layers: The first layer (fault overview layer) describes the fault phenomenon in natural language, such as the TLS connection being interrupted during the CertificateVerify stage, the cloud returning Alert: Decrypt Error (51), and the handshake taking 342ms before abnormally terminating.

[0096] The second layer (network evidence layer) lists key feature values ​​in network packets using structured JSON, including a list of cipher suites provided by the client, the suites selected by the server, certificate chain digests (issuer, subject, signature algorithm, and validity period of each certificate), and the length and time interval of each message during the handshake process.

[0097] The third layer (device evidence layer) uses structured JSON to list key feature values ​​in the vehicle and cloud logs, including function call return value sequences, hardware engine input / output parameter length comparisons, exception error codes and their context log lines, etc.

[0098] The fourth layer (environmental constraint layer) lists the device's environmental fingerprint, including operating system version, TLS library version, HSM model, and firmware version.

[0099] The fifth layer (instruction layer) requires the model to combine the knowledge graph to perform cross-modal causal reasoning and output root cause diagnosis conclusions and confidence scores according to the specified reasoning chain format.

[0100] S403. The diagnostic platform sends the Prompt to the large language model inference engine. During inference, the RAG (Retrieval-Augmented Generation) mechanism is used: based on the entity keywords involved in the Prompt (such as specific algorithm name, HSM model, Alert encoding, TLS library version), relevant constraint triples and historical similar cases are retrieved from the cryptographic knowledge graph (through vector similarity matching, with the hyperparameter Top-K taking a preset positive integer K=10), and the retrieval results are injected into the model inference window as supplementary context. The physical meaning of the above mechanism is that the large language model only holds parameterized knowledge that may be outdated or incomplete, while the diagnosis of vehicle-to-cloud TLS faults depends on current standards (such as the national cryptographic standard GM / T), manufacturer constraints, the compatibility of specific software and hardware versions, and the handling records of past real faults. RAG explicitly sends the "rule entries and case texts found in the local knowledge base" into the model context during inference, which is equivalent to experts simultaneously consulting technical manuals and historical work orders when interpreting on-site logs and messages. This anchors the output conclusions to verifiable external knowledge rather than pure parameter memory, thereby improving the accuracy and interpretability of root cause identification.

[0101] S404. The large language model executes the following chain of inference: Step 1 (Fault Bounding): Based on the Alert encoding and the stage where the handshake interruption occurred, narrow down the range of fault types (such as cipher suite mismatch, certificate parsing failure, signature verification failure, key exchange parameter error, etc.).

[0102] The second step (cross-modal conflict detection): After narrowing down the fault range, compare the network layer characteristics and device layer characteristics at the same time to find conflicting points. For example: the network layer shows that the ECDHE_SM4_SM3 kit was successfully negotiated, but the vehicle-side device log shows that engine_rsa_method_sign was actually called instead of engine_sm2_method_sign, which is a contradiction of inconsistent algorithm calls.

[0103] Step 3 (Root Cause Analysis): Combining environmental constraints and compatibility / constraint rules in the knowledge graph, determine the root cause of the contradiction. For example, querying the knowledge graph reveals that this version of the TLS library has a defect in NID mapping for the SM2 algorithm when selecting the Engine method, causing a fallback to the default RSA implementation.

[0104] Step 4 (Conclusion Generation): Output a structured description of the root cause conclusion, including: fault type, fault stage, root cause description, involved components, and chain of inference evidence (listing each piece of evidence supporting the root cause conclusion and its source), along with a confidence score (0-100 points); if the confidence score is below 70 points, it will be automatically marked as requiring manual review.

[0105] S405. For diagnostic results with a confidence level lower than the preset threshold (default 70 points), the platform automatically triggers a supplementary collection instruction, which is issued through the probe management channel to require the relevant probes to increase the collection granularity of specific log dimensions (such as enabling ssl_trace level debug output of OpenSSL and enabling APDU command communication log of HSM), and re-executes the diagnostic process of steps two to four after the supplementary data arrives, forming an iterative enhanced diagnosis.

[0106] Adaptive repair strategy generation and closed-loop verification: S501. Based on the root cause diagnosis conclusion, the diagnostic platform matches the corresponding repair template from the pre-set repair strategy knowledge base. The repair strategy knowledge base is organized by fault category and includes the following four repair types: Configuration repairs include: modifying the cipher suite priority list in the ssl_ciphers configuration item of the cloud gateway, updating the certificate chain PEM file, adjusting the TLS version negotiation range in the ssl_protocols directive, and modifying the minimum TLS version configuration of the MQTT Broker.

[0107] Code fixes include: adding length verification logic for the digestsign method input parameter in the Engine Wrapper layer of the device-side TLS library (forcing a fixed number of bytes output by the hash algorithm), fixing pointer offset issues caused by memory structure alignment, and adding compatibility adaptation branch code for certificate extension OID.

[0108] Firmware upgrades: such as upgrading the HSM firmware version to support new algorithm parameters in SM2 / SM9, and updating the vehicle-side security SDK version to fix known ASN.1 parsing defects.

[0109] Certificate re-signing: such as re-issuing device terminal certificates with the correct Extended Key Usage, and re-issuing intermediate CA certificates that are missing in the certificate chain.

[0110] S502. The remediation strategy is generated in the form of a structured work order, including: a fault summary, root cause analysis, remediation steps (down to the specific configuration file path, code modification location, or upgrade version number), responsible party (vehicle-side developer / cloud-based operations / certificate administrator), and priority (Critical / High / Medium / Low). The work order is pushed to the project management system via API.

[0111] S503. The platform has a built-in closed-loop regression verification mechanism. After the remediation measures are implemented, the platform automatically triggers a controlled TLS handshake test connection (using the exact same connection parameters and certificates as the fault scenario) through the probe management channel. New handshake messages and logs are collected through the probe, and the complete diagnostic process from steps two to four is re-executed. If the diagnostic result shows no fault (handshake completed successfully and no alerts), the remediation is deemed effective, the work order is closed, and the complete diagnostic case (including fault characteristics, root cause, remediation plan, and verification results) is archived to the knowledge base for subsequent RAG retrieval and model fine-tuning. If the verification fails, it is marked as the remediation not taking effect and new diagnostic information is attached, re-entering the diagnostic loop.

[0112] S504. This application supports parallel diagnostics for multiple devices. The diagnostic platform adopts a dual task isolation mechanism based on device ID and session ID, which can simultaneously receive and process diagnostic requests from multiple devices of different models and operating system environments. Each diagnostic task independently executes data alignment, feature extraction, and AI inference processes, and resource balancing is achieved through task queue scheduling, sharing the same cryptographic knowledge graph and repair strategy knowledge base.

[0113] Regarding timing alignment, in addition to the Dynamic Time Warping (DTW) alignment method based on TLS state machine anchors in step two, a pre-calibration scheme based on NTP time synchronization (suitable for scenarios where the device has an NTP client) or an association method based on event fingerprint hash matching (calculating the hash of the type, length, and first N bytes of each TLS handshake message, and matching different perspective records of the same message across data sources) can also be used.

[0114] In addition to reasoning methods based on large language models, lightweight reasoning schemes based on decision trees / rule engines (suitable for edge deployment scenarios and offline scenarios) can also be used, or a multi-model cascade scheme can be adopted (first use a lightweight model for coarse screening and classification, and then use a large language model for deep reasoning on difficult cases).

[0115] In addition to the embedded probe method, network bypass mirroring can also be used to obtain PCAP data at the switch / router level (suitable for wired network environments in laboratories), or eBPF technology can be used to non-intrusively collect TLS function call parameters at the Linux system kernel level.

[0116] This application represents a leap from manual, consultant-based packet capture and debugging to AI-automated, second-level diagnosis, and its advantages include: (1) Improved diagnostic efficiency: Through automated multimodal data collection, time-series alignment and AI inference, the location cycle of typical TLS link failures is shortened from 1-5 working days in the traditional way to 1-5 minutes, which is more than two orders of magnitude more efficient.

[0117] (2) Cross-layer penetration diagnostic capability: Through the unique network packet and heterogeneous system log time sequence alignment technology, AI can penetrate the network layer and reach the hardware cryptographic layer directly, accurately solving deep problems that are extremely difficult to locate by traditional methods, such as algorithm suite mismatch, certificate extension incompatibility, hardware engine data length truncation, and parameter transmission abnormality caused by memory alignment.

[0118] (3) Diagnostic accuracy: Based on the LLM reasoning mechanism enhanced by cryptographic knowledge graph, the accuracy of the first diagnosis can reach more than 85% in test scenarios covering national cryptographic / commercial cryptographic algorithms, mainstream TLS library versions, and multiple HSM models; the accuracy of the second diagnosis after supplementary data collection can reach more than 95%.

[0119] (4) Reduced labor costs: The reliance on senior security engineers has been greatly reduced. Junior technicians can use this platform to troubleshoot complex faults. The labor costs of security experts required for project delivery and after-sales response have been reduced by about 70%.

[0120] (5) Knowledge accumulation and reuse: The automatic archiving of each diagnostic case forms a continuously growing fault knowledge base, which makes the system's diagnostic capabilities increase with the time of use and its coverage of new fault modes continuously enhanced.

[0121] (6) Closed-loop verification guarantee: An automated regression verification mechanism after repair ensures that the effectiveness of the repair solution is technically confirmed, avoiding the problem in the traditional method where repairs are thought to be successful but are actually not repaired.

[0122] Figure 7 This is a schematic diagram of an example scenario. Example 1: Diagnosis of handshake failure caused by abnormal hardware encryption engine parameters in the T-BOX-cloud TLS connection.

[0123] Scenario Description: When a T-BOX of a certain vehicle model (based on Linux ARM64 system, equipped with a security chip of a certain brand, and using GmSSL2.5 as the TLS library) is conducting TLS connection testing with a cloud-based Nginx / MQTT node (configured in TLSv1.2 + national cryptographic dual certificate mode), the connection keeps dropping.

[0124] The diagnostic process is as follows: (1) Data Acquisition: The vehicle-side diagnostic probe automatically collects TLS handshake messages (PCAP format, a total of 12 handshake message packets) and vehicle-side security SDK operation logs (including GmSSL function call chains and security chip Engine method call records, a total of 847 valid logs); the cloud-side diagnostic probe collects the corresponding Nginx access logs and cloud-side TLS handshake messages. Vehicle-side environment fingerprint display: The operating system is Linux 4.14 ARM64, the TLS library is GmSSL 2.5.0, and the security chip firmware version is v1.2.3.

[0125] (2) Timing Alignment: The central diagnostic platform confirms that the vehicle-side and cloud-side PCAP belong to the same TLS session by matching the ClientHello.random field. The RTT calculated by TCP SYN / SYN-ACK is approximately 23ms, and the estimated clock offset Δt_coarse is approximately 1.37 seconds. Fine-grained DTW alignment is performed using four anchor points: ClientHello (A1), ServerHello (A2), Certificate (A3), and CertificateVerify (A5) to calibrate the event time deviation of the four data streams to within ±3ms.

[0126] (3) Feature Slicing and Extraction: After alignment, it was found that the handshake was interrupted during the P4 authentication phase (CertificateVerify). Network packet characteristics: The cloud returned a TLSv1.2 Alert (Level: Fatal, Description: Decrypt Error, Code=51). Vehicle log characteristics: About 15ms before the Alert occurred, the security chip Engine call record showed that the engine_ecc_method_digestsign method was called, the input parameter data length field value was 4296 bytes (abnormal), and the error code 0xE103 was returned; under normal circumstances, the SM3 hash output should be 32 bytes. Environment characteristics: Linux ARM64 platform, GmSSL 2.5.0, security chip firmware v1.2.3.

[0127] (4) AI Joint Reasoning: Fault delimitation: Alert Code 51 (Decrypt Error) + interruption in the CertificateVerify phase → scope narrowed to the "signature verification failed" class.

[0128] Cross-modal contradiction detection: The network layer shows that the CertificateVerify message was sent but the signature data is invalid. At the same time, the vehicle log shows that the input parameter length of the Engine signature method is abnormal (4296 bytes vs. expected 32 bytes), which is a contradiction that "the network layer sees the signature data but the underlying signature operation is based on the wrong input".

[0129] Root cause analysis: AI combined with knowledge graph retrieval revealed that the signature interface of the security chip v1.2.3 firmware requires a memory pointer to the original hash value as input parameter. However, GmSSL 2.5.0 has a known structure memory alignment issue on the ARM64 platform. When the length field (len) and the data pointer field (data) in the data buffer structure are offset due to 8-byte alignment padding, the length value passed to the Engine actually reads dirty data in adjacent memory (4296 in this case), instead of the actual hash length of 32.

[0130] Conclusion: The incorrect length of the signature input data was caused by misalignment between GmSSL 2.5.0 and the memory structure of the chip's driver wrapper layer on the ARM64 platform. Confidence score: 92 points.

[0131] (5) Repair strategy: The platform outputs code repair work orders to guide developers to add the following verification logic to the data pointer passed to engine_ecc_method_digestsign in the wrapper of the chip driver: ① assert that the length of the input parameter is equal to the output length of the currently negotiated hash algorithm (32 bytes for SM3, 32 bytes for SHA-256, etc.); ② use a fixed-size buffer and explicitly assign the length field when copying to memory to eliminate the offset caused by structure alignment.

[0132] (6) Closed-loop verification: After the developer modifies the Wrapper layer code according to the repair suggestions and recompiles and deploys, the platform automatically triggers regression verification. The newly collected handshake message shows that the TLS handshake was successfully completed to the Application Data stage, the length of the engine_ecc_method_digestsign input parameter in the vehicle log is restored to the normal 32 bytes, and the return code is 0x0000 (success). The diagnostic conclusion is marked as "repaired", and the case is archived to the knowledge base.

[0133] This system can accurately pinpoint a complex TLS failure involving multiple hardware and software layers within 3 minutes.

[0134] Example 2: Diagnosis of handshake failure between DVR device and cloud due to mismatch between national cryptographic / commercial cryptographic algorithm suites.

[0135] Scenario Description: When a certain model of in-vehicle DVR (based on Android 9 system and using the security SDK compiled with OpenSSL 1.1.1k) attempts to establish an encrypted connection with the cloud API Gateway (configured to only support the Chinese national cryptographic TLCP protocol + SM2 / SM3 / SM4 algorithm suite), it immediately returns a handshake failure.

[0136] The diagnostic process is as follows: (1) Data Collection: The vehicle-side probe collected TLS handshake messages (containing only ClientHello and ServerHello followed by Alert, a total of 4 packets), as well as the OpenSSL runtime logs of the Android SDK (126 lines in total). The cloud probe collected gateway logs, recording connection attempts and Alert sending events. Vehicle-side environment fingerprint display: Android 9AArch64, OpenSSL 1.1.1k (without Chinese national cryptographic engine plugin).

[0137] (2) Timing alignment: Since the handshake is interrupted very early (ClientHello→ServerHello→Alert), only two anchor points, A1 and A2, are available. The central diagnostic platform matches sessions using ClientHello.random, performs coarse alignment using TCP layer timestamps, and then performs single-point calibration based on anchor point A1 (because the handshake process is extremely short, the impact of clock drift can be ignored).

[0138] (3) Feature Slicing and Extraction: The fault occurred during the P1 negotiation phase. Network packet feature extraction results: The ClientHello client provides a list of 28 cryptographic suites, all of which are international standard suites (such as TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, etc.) and do not include any Chinese national cryptographic algorithm suites (such as ECC_SM4_CBC_SM3, ECDHE_SM4_CBC_SM3, etc.).

[0139] ServerHello was not sent (the cloud returned an Alert directly after checking ClientHello).

[0140] Alert message: Level=Fatal, Description=handshake_failure (40).

[0141] Vehicle-side log characteristics: OpenSSL logs show that SSL_do_handshake returns -1, SSL_get_error returns SSL_ERROR_SSL, and the error queue records "no ciphers available".

[0142] (4) AI Joint Reasoning: Fault delimitation: Alert Code 40 (handshake_failure) + interrupted before ServerHello → narrow the scope to the "cipher suite negotiation failed" class.

[0143] Cross-modal contradiction detection: The client only provides a list of international standard suites, while the cloud only supports Chinese cryptographic suites. There is no overlap between the two. Alert 40 is completely consistent with this and there is no contradiction, which is the direct cause.

[0144] Root cause analysis: AI-powered knowledge graph retrieval confirmed that the native OpenSSL 1.1.1k compilation does not include support for Chinese cryptographic algorithms, requiring the additional loading of the GmSSL Engine plugin or the use of the OpenSSL 3.x + Chinese cryptographic provider solution. Environment fingerprinting showed that the DVR's SDK compilation did not include GmSSL Engine, indicating a missing SDK integration configuration.

[0145] Conclusion: The root cause is that the OpenSSL SDK of the vehicle-mounted DVR does not integrate support for the Chinese national cryptographic algorithm suite, resulting in ClientHello not containing the Chinese national cryptographic algorithm suite required by the cloud. Confidence score: 9 points.

[0146] Repair strategy: Output two optional repair suggestions: Option A (Recommended): Load the GmSSL Engine plugin in the DVR's SDK compilation configuration, and add the priority configuration of the national cryptographic suite through SSL_CTX_set_cipher_list during SSL_CTX initialization.

[0147] Option B (alternative): Modify the cloud API Gateway configuration to add downgrade support for international standard suites in addition to supporting only Chinese cryptographic suites (security compliance needs to be assessed).

[0148] (6) Closed-loop verification: After recompiling and integrating GmSSL Engine and deploying the solution using Scheme A, the platform automatically verifies and displays that the TLS handshake was successfully completed. Two national cryptographic suites, ECC_SM4_CBC_SM3 and ECDHE_SM4_CBC_SM3, are added to ClientHello, and ECC_SM4_CBC_SM3 is selected for ServerHello. Case archive.

[0149] Example 3: Diagnosis of TLS handshake interruption caused by incomplete certificate chain in IDC domain controller.

[0150] Scenario Description: When a smart domain controller (IDC) (based on QNX RTOS system, using wolfSSL 5.5.1 as TLS library) establishes a connection with the cloud MQTT Broker (configured in two-way authentication mode), the cloud returns a bad_certificate alarm.

[0151] The diagnostic process is as follows: (1) Data Acquisition: The vehicle-side probe collected complete handshake messages (including ClientHello, ServerHello, Certificate(Server), CertificateRequest, Certificate(Client), and Alert, a total of 8 packets) and the IDC-side wolfSSL operation log (412 lines in total). The cloud-side probe collected the TLS authentication log of the MQTT Broker. IDC environment fingerprint display: QNX 7.1, wolfSSL 5.5.1, and the device certificate was issued by the enterprise's internal CA three-level architecture.

[0152] (2) Timing Alignment: The QNX system log only provides a monotonically increasing tick counter without an absolute timestamp. The platform adopts a causal order inference mechanism: the processing of CertificateRequest events in the wolfSSL log must occur after the receipt of CertificateRequest messages in the PCAP, thus establishing a causal anchor. The four-stream alignment is completed by combining the PCAP dual-end anchors.

[0153] (3) Feature Slicing and Extraction: The fault occurred during the P2 certificate exchange phase. Network packet characteristics: The Certificate message sent by the client contains only one certificate (device terminal certificate), instead of a complete certificate chain (which should include terminal certificate + intermediate CA certificate + secondary intermediate CA certificate, a total of 3 certificates).

[0154] After receiving the Certificate from the client, the cloud returns Alert: bad_certificate (42).

[0155] Cloud log characteristics: The TLS authentication log of MQTT Broker records "verify error: unable to get local issuer certificate (depth=0)", indicating that the certificate chain verification fails at layer 0 (end certificate) because the issuer (intermediate CA) certificate cannot be found.

[0156] IDC log characteristics: The wolfSSL log shows that only one PEM certificate block (BEGIN CERTIFICATE...END CERTIFICATE) was read when loading the device certificate file, and a success was returned.

[0157] (4) AI Joint Reasoning: Fault delimitation: Alert Code 42 (bad_certificate) + interruption after Certificate(Client) is sent → scope narrowed to the "Client certificate verification failed" class.

[0158] Cross-modal contradiction detection: The network layer shows that the client only sent one certificate, and the cloud log shows that the intermediate CA is missing in the verification chain → the certificate chain is incomplete; the IDC log shows that the certificate was loaded successfully, indicating that wolfSSL considers the certificate file to be valid → there is a contradiction of "wolfSSL loaded successfully but the actual certificate is incomplete".

[0159] Root cause analysis: AI retrieval of the knowledge graph confirmed that the wolfSSL_CTX_use_certificate_file function in SSL_FILETYPE_PEM mode only loads the first PEM certificate block in the file by default, and does not automatically load subsequent certificate blocks (intermediate CA certificates) in the same file. It is necessary to additionally call wolfSSL_CTX_use_certificate_chain_file or separately call wolfSSL_CTX_load_verify_buffer to load intermediate CA certificates.

[0160] The IDC-side TLS library used `wolfSSL_CTX_use_certificate_file` instead of `wolfSSL_CTX_use_certificate_chain_file` when loading the device certificate, resulting in only loading the terminal certificate and omitting the intermediate CA certificates in the certificate chain. Confidence score: 96 points.

[0161] (5) Repair strategy: Replace the device-side certificate loading function from wolfSSL_CTX_use_certificate_file with wolfSSL_CTX_use_certificate_chain_file, and ensure that the PEM certificate file contains the following in order: terminal certificate, secondary intermediate CA certificate, and primary intermediate CA certificate.

[0162] Alternatively, the intermediate CA certificate can be loaded separately into the trust chain using wolfSSL_CTX_load_verify_locations.

[0163] (6) Closed-loop verification: After the repair, the verification shows that the client's Certificate message contains 3 certificates, the cloud verification is successful, and the TLS handshake is successfully completed. Case archive.

[0164] In one exemplary embodiment, such as Figure 8 As shown, a vehicle-cloud collaborative TLS link intelligent diagnostic device is provided, comprising: The data acquisition module is used to acquire multi-source data. The multi-source data is collected based on diagnostic probes deployed on the vehicle-side device and the cloud backend, and transmitted through an independent encrypted reporting channel. The multi-source data includes: network traffic packets during the TLS handshake phase, device application layer operation logs, and device system environment fingerprint information.

[0165] The alignment module is used to perform multimodal temporal dynamic alignment on the multi-source data to obtain aligned data.

[0166] The slice partitioning module is used to divide the aligned data according to the TLS handshake state machine to obtain the partitioned slices; the partitioned slices include: negotiation phase slices, certificate exchange phase slices, key exchange phase slices, authentication phase slices, and abnormal termination phase slices.

[0167] The feature extraction module is used to extract features from the segmented slices to obtain structured feature vectors; the dimensions of the feature extraction include three dimensions: network packet features, device log features, and environmental fingerprint features.

[0168] The retrieval module is used to convert the structured feature vector into a hierarchical structured Prompt, and to retrieve relevant knowledge entries from the cryptographic knowledge graph using a retrieval enhancement generation mechanism to obtain retrieval results.

[0169] The diagnostic module is used to input the hierarchical structured Prompt and the retrieval results into the large language model inference engine, execute an inference chain that includes fault delimitation, cross-modal contradiction detection, root cause tracing and conclusion generation, and output diagnostic results; the diagnostic results include: root cause diagnosis conclusions and confidence scores.

[0170] In practical applications, this application also provides a vehicle-cloud collaborative TLS link intelligent diagnostic platform based on multimodal timing alignment, including: The data acquisition layer includes vehicle-side diagnostic probes deployed on vehicle-side devices and cloud-side diagnostic probes deployed on cloud-based backend gateways. The probes are used to collect TLS handshake messages, application layer operation logs, and system environment fingerprint information, and report them to the data access gateway through an independent encrypted channel.

[0171] The data processing layer includes a data access gateway, a format standardization module, a time-series dynamic alignment engine, and a feature slicing and extraction module. It is used to perform integrity verification, format standardization, multi-sequence dynamic time warping and alignment based on TLS handshake state machine anchors, as well as slicing and multi-dimensional feature extraction according to the handshake stage on multi-source data.

[0172] The intelligent diagnostic layer includes a Prompt building module, a cryptographic knowledge graph, a retrieval enhancement generation module, and a large language model inference engine. It is used to transform feature vectors into hierarchical structured Prompts, retrieve relevant knowledge entries from the knowledge graph, and perform inference chain analysis, including fault delimitation, cross-modal contradiction detection, root cause tracing, and conclusion generation, through the large language model.

[0173] The strategy output layer includes a repair strategy matching module, a work order generation and push module, and a closed-loop verification module, which are used to match repair templates, generate structured repair work orders, and automatically trigger regression verification after repair.

[0174] The vehicle-side diagnostic probe is embedded in the device's operating environment as a dynamic library or a standalone daemon, occupying no more than 8MB of memory. It collects TLS handshake messages by setting a bypass mirror hook function in the Socket layer of the network protocol stack.

[0175] The time-series dynamic alignment engine supports two alignment modes: when the device log has an accurate timestamp, it adopts multi-sequence dynamic time warping alignment based on TLS state machine anchors; when the device log lacks an accurate timestamp, it adopts an event causal order inference mechanism based on the inherent causal order of the TLS protocol state machine.

[0176] After the repair is implemented, the closed-loop verification module automatically triggers a controlled TLS handshake test and re-executes the complete diagnostic process. Once the verification is successful, the complete diagnostic case is archived to the cryptographic knowledge graph and historical case library, enabling the continuous accumulation of diagnostic knowledge.

[0177] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 9As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores intelligent diagnostic data for the vehicle-to-cloud (V2X) collaborative TLS link. The I / O interfaces are used for information exchange between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements the vehicle-to-cloud collaborative TLS link intelligent diagnostic method.

[0178] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0179] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0180] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0181] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0182] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0183] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0184] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, data processing logic devices, etc., and are not limited to these.

[0185] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0186] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A vehicle-cloud collaborative TLS link intelligent diagnostic method, characterized in that, include: Acquire multi-source data; The multi-source data is collected based on diagnostic probes deployed on vehicle-side devices and cloud backends, and transmitted through an independent encrypted reporting channel; the multi-source data includes: network traffic packets during the TLS handshake phase, device application layer operation logs, and device system environment fingerprint information; The multi-source data is dynamically aligned in a multimodal time series to obtain aligned data; The aligned data is divided according to the TLS handshake state machine to obtain a segment; the segment includes: negotiation phase segment, certificate exchange phase segment, key exchange phase segment, authentication phase segment, and abnormal termination phase segment; Feature extraction is performed on the segmented slices to obtain structured feature vectors; the dimensions of the feature extraction include three dimensions: network packet features, device log features, and environmental fingerprint features; The structured feature vector is transformed into a hierarchical structured Prompt, and a retrieval enhancement generation mechanism is used to retrieve relevant knowledge entries from the cryptographic knowledge graph to obtain retrieval results; The hierarchical structured Prompt and the retrieval results are input into the large language model inference engine to execute an inference chain that includes fault delimitation, cross-modal contradiction detection, root cause tracing, and conclusion generation, and outputs diagnostic results; the diagnostic results include: root cause diagnosis conclusions and confidence scores.

2. The intelligent diagnostic method for vehicle-cloud collaborative TLS links according to claim 1, characterized in that, Also includes: When the confidence score is lower than a preset threshold, the collection granularity of a preset specific log dimension is increased according to the automatically issued supplementary collection instruction, so as to supplement the data of multiple sources. Based on the supplemented multi-source data, return to the step of "perform multi-modal temporal dynamic alignment on the multi-source data to obtain aligned data" to execute the diagnostic process; Based on the root cause diagnosis conclusion, a pre-set repair strategy template is matched to generate a structured repair work order, and a closed-loop regression verification is automatically triggered after the repair is implemented; wherein, after the repair is implemented, a controlled TLS handshake test connection using the exact same connection parameters and certificate as the fault scenario is automatically triggered, packets and logs are re-collected and the complete diagnostic process is executed. If the closed-loop regression validation passes, the complete diagnostic case will be archived in the knowledge base for use by the subsequent retrieval enhancement generation mechanism. If the closed-loop regression validation fails, the diagnostic process will re-enter the loop.

3. The intelligent diagnostic method for vehicle-cloud collaborative TLS links according to claim 1, characterized in that, The multi-source data is dynamically aligned in a multimodal time series to obtain aligned data, specifically including: When the runtime log in the multi-source data is missing a timestamp, an event causal order relationship inference mechanism based on the inherent causal order of the TLS protocol state machine is adopted. Combined with the sequence number or monotonically increasing counter in the runtime log, the timing position of the missing event is inferred and inserted into the alignment timeline to perform data alignment. When the runtime logs in the multi-source data have timestamps, the preset key anchor events in the TLS handshake state machine are used as control points, and a multi-sequence dynamic time warping algorithm is adopted to eliminate clock offsets between heterogeneous devices in order to perform data alignment. Based on the unified timeline view generated after the data alignment operation, the multi-source data is interwoven and arranged in chronological order to form a single ordered event sequence, thus obtaining the aligned data.

4. The intelligent diagnostic method for vehicle-cloud collaborative TLS links according to claim 1, characterized in that, Feature extraction is performed on the segmented slices to obtain structured feature vectors, specifically including: Feature extraction is performed on the segmented slices to obtain the extracted features; The extracted features are denoised and filtered to obtain a structured feature vector; wherein the denoising and filtering process includes: Remove duplicate heartbeat log entries and filter system-level logs that are not related to diagnosis; system-level logs that are not related to diagnosis include: CPU load and network bandwidth statistics; Merge consecutively occurring identical error codes, retaining only the first and last occurrences and the total number of occurrences.

5. The intelligent diagnostic method for vehicle-cloud collaborative TLS links according to claim 1, characterized in that, The hierarchical structured Prompt adopts a hierarchical template structure; the hierarchical template structure has five layers; the first layer is the fault overview layer, the second layer is the network evidence layer, the third layer is the device evidence layer, the fourth layer is the environmental constraint layer, and the fifth layer is the instruction layer; The fault overview layer describes the fault phenomenon in natural language; the network evidence layer lists the key feature values ​​in network traffic packets in structured JSON; the key feature values ​​in network traffic packets include the list of cipher suites provided by the client, the suites selected by the server, the certificate chain digest, and the length and time interval of each message during the handshake process; The device evidence layer uses structured JSON to list key feature values ​​in the device application layer runtime logs. These key feature values ​​include function call return value sequences, hardware engine input / output parameter length comparisons, exception error codes, and their context log lines. The environment constraint layer lists the device system environment fingerprint information; the device system environment fingerprint information includes the operating system version, TLS library version, HSM model, and firmware version; The instruction layer is used to combine cryptographic knowledge graphs to retrieve relevant knowledge entries and perform cross-modal causal reasoning.

6. The intelligent diagnostic method for vehicle-cloud collaborative TLS links according to claim 1, characterized in that, The hierarchical structured Prompt and the retrieval results are input into the large language model inference engine to execute an inference chain that includes fault delimitation, cross-modal contradiction detection, root cause tracing, and conclusion generation, and outputs diagnostic results, specifically including: The hierarchical structured Prompt and the search results are input into the large language model inference engine. The search results serve as the inference window, and an inference chain including fault delimitation, cross-modal contradiction detection, root cause tracing, and conclusion generation is executed. Specifically, during the fault delimitation phase, the following steps are performed: based on the Alert encoding and handshake interruption phase slices in the hierarchical structured Prompt, the range of fault types is narrowed down. During the cross-modal conflict detection phase: narrow down the range of fault types, compare the network layer features and device layer features at the same time to find conflict points; In the root cause investigation phase, the following steps are performed: combining environmental constraint information and compatibility / constraint rules in the cryptographic knowledge graph to determine the root cause of the contradictions; During the conclusion generation phase, the following steps are performed: Based on the root cause of the contradiction, a structured description of the root cause diagnosis conclusion is output, along with a confidence score, to obtain the diagnosis result.

7. A vehicle-cloud collaborative TLS link intelligent diagnostic device, characterized in that, include: The data acquisition module is used to acquire data from multiple sources; The multi-source data is collected based on diagnostic probes deployed on vehicle-side devices and cloud backends, and transmitted through an independent encrypted reporting channel; the multi-source data includes: network traffic packets during the TLS handshake phase, device application layer operation logs, and device system environment fingerprint information; The alignment module is used to perform multimodal temporal dynamic alignment on the multi-source data to obtain aligned data; The slice partitioning module is used to divide the aligned data according to the TLS handshake state machine to obtain the partitioned slices; the partitioned slices include: negotiation phase slices, certificate exchange phase slices, key exchange phase slices, authentication phase slices, and abnormal termination phase slices. The feature extraction module is used to extract features from the segmented slices to obtain structured feature vectors; the dimensions of the feature extraction include three dimensions: network packet features, device log features, and environmental fingerprint features. The retrieval module is used to convert the structured feature vector into a hierarchical structured Prompt, and to retrieve relevant knowledge entries from the cryptographic knowledge graph using a retrieval enhancement generation mechanism to obtain retrieval results; The diagnostic module is used to input the hierarchical structured Prompt and the retrieval results into the large language model inference engine, execute an inference chain that includes fault delimitation, cross-modal contradiction detection, root cause tracing and conclusion generation, and output diagnostic results; the diagnostic results include: root cause diagnosis conclusions and confidence scores.

8. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the vehicle-cloud collaborative TLS link intelligent diagnostic method according to any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the vehicle-cloud collaborative TLS link intelligent diagnostic method as described in any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the vehicle-cloud collaborative TLS link intelligent diagnostic method as described in any one of claims 1-6.

Images