Intelligent networked automobile password security detection system

Abstract

The invention provides an intelligent network connection automobile password security detection system, which comprises a protocol intelligent analysis module used for unpacking a multi-level vehicle-mounted communication protocol, carrying out field type identification on the unpacked vehicle-mounted communication protocol, carrying out password feature library matching on the vehicle-mounted communication protocol subjected to field type identification, and carrying out password feature library matching on the vehicle-mounted communication protocol subjected to field type identification; identifying whether each field of the vehicle-mounted communication protocol has a risk; the dynamic fuzz test module is used for performing fuzz test on fields of the vehicle-mounted communication protocol with risks and analyzing a fuzz test result; and the compliance evaluation module is used for generating a risk detection report based on the protocol intelligent analysis module and the dynamic fuzzy test module and constructing a password strength scoring model, and the password strength scoring model is used for evaluating the security strength of the field key. According to the invention, comprehensive assessment of the password security of the intelligent networked automobile is realized, and the risk detection report is generated according to all identified risks.

Description

Technical Field

[0001] This invention relates to the field of automotive information security technology, and in particular to a cryptographic security detection system for intelligent connected vehicles. Background Technology

[0002] Passwords, as the first line of defense for information security in intelligent connected vehicles, directly impact the security of the entire vehicle system. Currently, existing technologies suffer from the following technical challenges: Protocol closedness: Automakers' custom proprietary communication protocols are difficult to reverse engineer, and traditional scanners cannot recognize encrypted fields; Dynamic encryption: Keys are dynamically updated during vehicle operation, rendering static analysis ineffective; High false positive rate: General-purpose web scanners mistakenly identify non-password fields as sensitive data; Compliance requirements: UNECE R155 regulations mandate password security verification for in-vehicle systems. Further optimization is needed. Summary of the Invention

[0003] Therefore, the purpose of this invention is to provide an intelligent connected vehicle password security detection system to solve or at least partially solve the above-mentioned problems existing in the prior art.

[0004] To achieve the above objectives, the present invention provides a password security detection system for intelligent connected vehicles, the system comprising: The protocol intelligent parsing module is used to unpack multi-level vehicle communication protocols, identify the field types of the unpacked vehicle communication protocols, and match the vehicle communication protocols that have been identified by field types with a cryptographic feature library to identify whether each field of the vehicle communication protocol has risks. The cryptographic feature library includes sensitive field detection, encryption algorithm identification, hard-coded credential detection, weak algorithm detection, and protocol vulnerability detection. Dynamic fuzzing module: used to perform fuzzing tests on fields of vehicle communication protocols with potential risks and analyze the fuzzing test results. The fuzzing tests include identifying the key location of the field, mutation attacks, response messages, and crash / abnormal behavior reports. Compliance assessment module: This module generates risk detection reports based on the protocol intelligent parsing module and the dynamic fuzzing module, and constructs a password strength scoring model, which is used to evaluate the security strength of field keys.

[0005] Furthermore, the unpacking of the multi-level vehicle communication protocol includes: The frame structure is parsed at the physical layer of the vehicle communication protocol. The parsed frame structure includes arbitration ID, data length code, and data field. The MAC address and VLAN tag are parsed at the data link layer of the vehicle communication protocol, as shown below: Ethernet frame = [Destination MAC][Source MAC][Optional VLAN][Type / Length][Data]; IPv4 / IPv6 addresses and fragmentation information are resolved at the network layer of the vehicle communication protocol. The port, serial number, and flag bits are parsed at the transport layer of the vehicle communication protocol. At the application layer of the vehicle communication protocol, the data is distributed to the corresponding application layer parser based on the transport layer port or protocol-specific identifier, and the application layer protocol performs custom parsing. The protocol stack of the vehicle communication protocol consists of multiple protocol layer parsers, arranged in order from the bottom layer to the top layer. The vehicle communication protocol parsing process starts from the bottom layer, where the vehicle communication protocol is passed in, each layer parser parses it in turn, and the remaining data is passed to the next layer. The context information is stored in a context dictionary, which is updated during the parsing process. Each parser is responsible for parsing the data in its own protocol layer and returning the parsing result and the remaining payload. When the parsing is complete, it returns a context containing all parsing information from the bottom layer to the application layer, which is used as the final output.

[0006] Furthermore, the process of identifying the field types of the unpacked vehicle communication protocol includes: By combining the BiLSTM model with the CRF model, a field recognition model is constructed. This model is then used to identify the field types of vehicle communication protocols. A dataset is constructed using publicly available protocol documents, Wireshark samples, and manually labeled data. Protocol field types are labeled on the dataset and used as training data for the model. The field recognition model is then trained based on this training data. The field recognition model has a structure consisting of an input layer, a BiLSTM layer, and a CRF layer. The field recognition model is designed as follows: Model input: byte sequence of vehicle communication protocol payload, each byte is converted into a 256-dimensional one-hot vector or embedding vector; Model output: a sequence of labels for each byte; Input layer: Maps byte sequences to embedding vectors; BiLSTM layer: Uses bidirectional LSTM to capture contextual features; CRF layer: Models label transition probabilities and optimizes the global optimum of the label sequence; During the parsing of vehicle communication protocols, if an unknown protocol format is encountered, the application layer payload is intercepted and fed into the field recognition model for sequence labeling to obtain the field boundaries and types. The field information output by the field recognition model is then used for subsequent password feature database matching.

[0007] Furthermore, the training of the field recognition model based on the training data specifically includes the following steps: S11. Divide the training data into training set, validation set and test set according to a certain ratio, and initialize the field recognition model parameters; S12. Iterate the field recognition model several times. Each iteration includes dividing the training set into multiple batches, calculating the loss through forward propagation for each batch, updating the parameters through backpropagation, evaluating the performance on the validation machine, and saving the best model. S13. Evaluate the performance of the final model on the test set.

[0008] Furthermore, the process of using a field recognition model to identify the field types of the vehicle communication protocol specifically includes the following steps: S21. Convert the original messages in the vehicle communication protocol into byte sequences and extract their features; S22. Use the trained field recognition model to label the byte sequence and obtain the field type of each byte; S23. Based on the annotation results, merge bytes with consecutive identical labels into one field, and determine the starting position and length of the field.

[0009] Furthermore, the sensitive field detection includes general sensitive field detection, framework and protocol specialization rule detection, and obfuscation and anti-obfuscation detection; The encryption algorithm is identified by pattern matching to determine the encryption algorithm usage method, including key length and working mode; The hard-coded credential detection is a pattern that matches the hard-coded password, key, and API key; The protocol vulnerability detection includes protocol version detection, weak password suite detection, and certificate security detection. The weak algorithm detection includes a weak algorithm dictionary, a weak cipher suite list, and call chain analysis detection. The weak algorithm dictionary includes a hash algorithm list, a symmetric encryption algorithm list, and an asymmetric encryption algorithm list.

[0010] Furthermore, the call chain analysis and detection specifically includes the following steps: S31. Search for calls to specific methods in the weak algorithm detection code; S32. Extract the algorithm name from the call; S33. Compare the extracted algorithm name with the list of algorithms of different categories in the weak algorithm dictionary to determine whether it belongs to a weak algorithm. S34. Analyze the data flow of the extracted algorithm instance to determine where it is used. If step S33 determines that it is a weak algorithm, then determine whether the weak algorithm instance is used for safety-critical operations. If so, mark it as a safety issue.

[0011] Furthermore, the key location of the identification field includes sensitive field location logic and key usage scenario classification logic corresponding to the field; The mutation attacks include the following: Boundary value mutation: Generate test cases by selecting different boundary values ​​for the input field type; Formatting error injection: This involves applying formatting distortions to fields in the vehicle communication protocol to generate abnormal data. Intelligent deep mutation: Generate a 128-dimensional random latent vector based on the fields of the vehicle communication protocol, which follows a normal distribution; input the fields of the vehicle communication protocol and the latent vector into the generator model to generate adversarial examples, and return the generated adversarial examples as the mutated data; The crash / abnormal behavior report includes behavior state analysis, entropy mutation detection, crash report architecture, and mutation strategy matrix.

[0012] Furthermore, the password strength scoring model is expressed as follows: Score = f(key length, randomness entropy value, key update period); The score is the final rating.

[0013] Compared with the prior art, the beneficial effects of the present invention are: This invention proposes a cryptographic security detection system for intelligent connected vehicles. It utilizes an intelligent protocol parsing module to perform multi-layer protocol unpacking, intelligent field identification, and cryptographic feature database matching to identify potential risks. A dynamic fuzzing module performs fuzzing tests on fields of risky in-vehicle communication protocols. A compliance assessment module generates a risk detection report and constructs a cryptographic strength scoring model to achieve a comprehensive assessment of the cryptographic security of intelligent connected vehicles, generating a report based on all identified risks. Attached Figure Description

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

[0015] Figure 1 This is a schematic diagram of the overall structure of an intelligent connected vehicle password security detection system provided in an embodiment of the present invention. Detailed Implementation

[0016] The principles and features of the present invention are described below with reference to the accompanying drawings. The listed embodiments are only used to explain the present invention and are not intended to limit the scope of the present invention.

[0017] Reference Figure 1 This embodiment provides a password security detection system for intelligent connected vehicles, the system comprising: The intelligent protocol parsing module is used to unpack multi-level vehicle communication protocols, identify the field types of the unpacked protocols, and perform cryptographic feature matching on the identified protocols to identify whether each field of the protocol contains risks. The cryptographic feature database includes sensitive field detection, encryption algorithm identification, hard-coded credential detection, weak algorithm detection, and protocol vulnerability detection, specifically including: The unpacking of the multi-level vehicle communication protocol includes: The frame structure is parsed at the physical layer of the vehicle communication protocol (such as CAN bus). The parsed frame structure includes arbitration ID, data length code (DLC), data field (0-8 bytes), etc. For example: CAN frame = [arbitration ID (11 / 29 bits)][DLC (4 bits)][data field (0-8 bytes)]; In the data link layer of vehicular communication protocols (such as Ethernet), MAC addresses, VLAN tags, etc., are resolved as follows: Ethernet frame = [Destination MAC][Source MAC][Optional VLAN][Type / Length][Data]; At the network layer (such as IP) of the vehicle communication protocol, resolve IPv4 / IPv6 addresses, fragmentation information, etc. The port number, sequence number, and flag bits are parsed at the transport layer of the vehicle communication protocol (such as TCP / UDP). At the application layer of in-vehicle communication protocols (such as SOME / IP, DoIP, HTTP, MQTT), the protocol is dispatched to the corresponding application layer parser based on the transport layer port or protocol-specific identifier (such as the Service ID of SOME / IP). The application layer protocol then performs custom parsing, for example: SOME / IP: Includes headers such as message ID, request ID, protocol version, and interface version, followed by the payload.

[0018] HTTP: Parsing method, URL, header fields; payload may be JSON / XML, etc.

[0019] The protocol stack of the vehicle communication protocol consists of multiple protocol layer parsers, arranged in order from the bottom layer to the top layer (e.g., from Ethernet parser to application layer parser). The vehicle communication protocol parsing process starts from the lowest layer (such as Ethernet), where the vehicle communication protocol is passed in, each layer parser parses it in turn, and passes the remaining data to the next layer; The context information is stored in a context dictionary (context) to store cross-layer information (such as IP fragmentation and reassembly that requires crossing multiple packets, or TCP stream reassembly, etc.), and this context is updated during the parsing process; Each parser is responsible for parsing the data of its own protocol layer and returning the parsing result (stored in the context) and the remaining payload (i.e., upper-layer protocol data, passed to the next layer parser). When the parsing is complete, it returns a context containing all parsing information from the bottom layer to the application layer, which is used as the final output.

[0020] The process of identifying the field types of the unpacked vehicle communication protocol includes: By combining the BiLSTM model with the CRF model, a field recognition model is constructed. This model is then used to identify the field types of vehicle communication protocols. A dataset is built using publicly available protocol documents, Wireshark samples, and manually labeled data. Protocol field types are labeled on the dataset, such as username and password fields in login requests, encryption key fields, initialization vectors (IVs), and tokens. This data serves as the training data for the model, which is then used to train the field recognition model. The field recognition model has a structure consisting of an input layer, a BiLSTM layer, and a CRF layer. The field recognition model is designed as follows: Model input: byte sequence of vehicle communication protocol payload, each byte is converted into a 256-dimensional one-hot vector or embedding vector; Model output: a sequence of tags for each byte (e.g., tag set = {B-Password, I-Password, B-Username, I-Username, O}, etc.); Input layer: Maps byte sequences to embedding vectors (256-dimensional -> 16-dimensional, reducing sparsity); BiLSTM layer: Uses bidirectional LSTM to capture contextual features; CRF layer: Models label transition probabilities and optimizes the global optimum of the label sequence; During the parsing of vehicle communication protocols, if an unknown protocol format is encountered, the application layer payload is intercepted and fed into the field recognition model for sequence labeling to obtain the field boundaries and types. The field information output by the field recognition model is then used for subsequent password feature database matching.

[0021] The training process of the field recognition model based on training data includes: Input: A batch of vehicle communication protocol messages (each message is represented as a characteristic sequence); Output: Predicted label for each byte; Loss function: Negative log-likelihood loss of CRF; Optimizer: Adam.

[0022] The training of the field recognition model based on training data specifically includes the following steps: S11. Divide the training data into training set, validation set and test set according to a certain ratio, and initialize the field recognition model parameters (including the embedding layer); S12. Iterate the field recognition model for several epochs. Each iteration includes dividing the training set into multiple batches, calculating the loss through forward propagation for each batch, updating the parameters through backpropagation, evaluating the performance on the validation machine, and saving the best model. S13. Evaluate the performance of the final model on the test set.

[0023] The process of using a field recognition model to identify field types in vehicle communication protocols specifically includes the following steps: S21. Convert the original messages in the vehicle communication protocol into byte sequences and extract their features; S22. Use the trained field recognition model to label the byte sequence and obtain the field type of each byte; S23. Based on the annotation results, merge bytes with consecutive identical labels into one field, and determine the starting position and length of the field; The effects achieved include the following: Accuracy: On known protocols, the field recognition accuracy can reach over 90%; Generalization capability: For variants of known protocols (such as the length field changing from 1 byte to 2 bytes) or new custom protocols, it can perform good generalization based on the context, with an accuracy of over 85%. Reduced manual configuration: Compared to traditional rule-based parsing methods, it can automatically adapt to multiple protocols, reducing the workload of manual configuration; Handling unknown protocols: For entirely new protocols, it can also provide some parsing capabilities (better than starting from scratch); Speed: Processing a message typically takes milliseconds, meeting real-time requirements.

[0024] The sensitive field detection includes general sensitive field detection, framework and protocol specialization rule detection, and obfuscation countermeasure detection, specifically including: The general sensitive field detection includes the following: User credential detection: Detect fields containing pass, pwd and their common variations (such as password, passcode, passphrase); Technical features: The (?i) flag is used to achieve case-insensitive matching, and the (?:) flag is used to achieve non-capturing groups to improve efficiency; Key and token detection: Identifies combinations of secret_key, priv_token, etc. Transformation overlay: Supports either the _ connector or direct concatenation (e.g., secrettoken); Encryption parameter detection: Accurately detects key cryptographic parameters: initialization vector (iv), random number (nonce), and salt value (salt).

[0025] Boundary control: Use \b to ensure complete word matching (avoiding misjudgments of words like "ivory").

[0026] The framework and protocol specialization rule detection includes the following: Database connection credential leakage: Identifying plaintext codes in JDBC connection strings; Capture the actual password value after password= (using the (.+?) capture group); API key leakage detection: Identify API key declarations in JSON / YAML and other configurations; Format adaptation: Supports underscore format (api_key) and concatenated format (apikey).

[0027] The obfuscation-resistant detection includes the following: Character obfuscation and distortion detection: Identifying common obfuscation techniques: Character substitution: s→5 or e→3 (e.g., 5ecret, s3cr3t); Special characters: @ replaces a (e.g., p@ssword); Number substitution: 0 replaces 0 (e.g., passw0rd).

[0028] Encoded data detection: Identifying sensitive encoded data. Base64 encoding features (including = padding and specific character sets); Hex encoding characteristics (pure hexadecimal number string); Depth capture: Extracts the actual value within the parentheses of the encoded parameters.

[0029] The encryption algorithm identification involves pattern matching to identify common encryption algorithms (such as AES, RSA, DES) and their usage patterns, including key length and operating mode (such as CBC, GCM). This identification includes pattern matching, algorithm parameter parsing, and compliance verification, as shown below: (1) Pattern matching: Use the regular expression r'Cipher\.getInstance\(["\'](.+?)["\']' to match the parameters of the Cipher.getInstance method in the string; Regular expression explanation: - Cipher.getInstance: Matches the literal string "Cipher.getInstance"; - ["\']: Matches single or double quotes; - (.+?): Non-greedy match for any character (up to the next quotation mark), capture groups are used to extract parameters; - ["\']: Matches the closing quotation mark; If a match is successful, the string within the quotation marks is extracted, which is the algorithm description string (in this example, "AES / CBC / PKCS5Padding").

[0030] (2) Algorithm parameter parsing: The extracted algorithm description string (algo_spec) is split into multiple parts by forward slashes / ; In this example, after segmentation: - parts[0] = "AES" -> Algorithm Name - parts[1] = "CBC" -> Working Mode - parts[2] = "PKCS5Padding" -> Padding mode.

[0031] - Algorithm name: Always exists, is the first part; - Working mode: If there are at least two parts after splitting, then the second part is the working mode; otherwise, it is None. - Fill pattern: If there are at least three parts after splitting, the third part is filled; otherwise, it is None. (3) Compliance Verification: Verification is performed based on the extracted algorithm information. In the example, the algorithm is "AES", so the following is performed: - Key length verification: Call the function validate_key_size(algorithm, detected_key_length) (Note: The example does not show how to obtain detected_key_length; in practice, it may be necessary to extract the key length information from other lines of code). - Working mode validation: If the working mode is "ECB", report a violation ("AES_ECB_MODE") because ECB mode is unsafe.

[0032] The hard-coded credential detection involves matching patterns of common hard-coded passwords, keys, and API keys (such as fixed-length Base64 strings and hexadecimal strings), as shown in Table 1 below: Table 1

[0033] The protocol vulnerability detection includes protocol version detection, weak cipher suite detection, and certificate security detection, including: (1) Protocol version detection: Risk scope: TLS 1.0 (0x0301): Vulnerable to BEAST attacks; TLS 1.1 (0x0302): Lack of modern cryptographic support. Automotive regulations require that GB / T 38628-2020 mandate the disabling of TLS < 1.2 in vehicle systems. UN R155 requires that OTA updates must use TLS ≥ 1.3; (2) Weak cipher suite detection: As shown in Table 2 below: Table 2

[0034] (3) Certificate security test: Key strength: RSA key length < 2048 bits or ECC key < 256 bits; Validity period: Certificates that have expired or exceeded the 13-month validity period limit; Extended domain: lacks critical extensions such as OCSP Must Staple.

[0035] The weak algorithm detection includes a weak algorithm dictionary, a weak cipher suite list, and call chain analysis. The weak algorithm dictionary includes a list of hash algorithms, a list of symmetric encryption algorithms, and a list of asymmetric encryption algorithms, specifically including the following: (1) Dictionary of weak algorithms: List of hash algorithms (HASH): Includes algorithms such as MD5, SHA1, and MD4; List of symmetric encryption algorithms: Includes DES, 3DES, RC4, and Blowfish; List of asymmetric encryption algorithms: Includes algorithms RSA-1024 and DSA-1024; Operating Mode (MODE): Includes the following modes: ECB, OFB; Padding schemes include: PKCS1v1.5 and ZeroPadding. (2) List of Weak Cipher Suite: Some SSL / TLS cipher suites are considered insecure. These suites typically use the weak algorithms or outdated protocol versions mentioned above. Examples are listed below: TLS_RSA_WITH_AES_128_CBC_SHA; TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA; TLS_ECDHE_RSA_WITH_RC4_128_SHA.

[0036] (3) The call chain analysis and detection specifically includes the following steps: S31. Search for calls to specific methods in the weak algorithm detection code, such as MessageDigest.getInstance (used in Java to get a hash algorithm instance). S32. Extract the algorithm name from the call, for example, the string parameter "MD5" in getInstance("MD5"); S33. Compare the extracted algorithm name with the list of hash algorithms (and other categories) in weak_algorithms to determine whether it belongs to a weak algorithm; S34. Analyze the data flow of the extracted algorithm instance (e.g., variable md) to determine where it is used. If step S33 determines it to be a weak algorithm, then determine whether the weak algorithm instance is used for security-critical operations (e.g., password storage, data encryption, or message authentication). If so, mark it as a security issue.

[0037] The password feature database matching process is as follows: Field-level matching: For each parsed application-layer field (fields identified through protocol parsing or model recognition), search for matches in the cryptographic feature database: Field name matching: such as field names containing "password"; Field value feature matching: If the value conforms to Base64 encoding (regular expression: [A-Za-z0-9+ / =]{20,}) or hexadecimal string (regular expression: [0-9A-Fa-f]{32,}), it may be a key; Protocol behavior-level matching: For the entire protocol process, check for security flaws. Passwords are transmitted in plaintext during the authentication process; No encryption was used or a weak encryption algorithm was used; Session tokens may be predictable or lack sufficient entropy.

[0038] Dynamic fuzzing module: Used to perform fuzzing tests on fields of potentially risky vehicle communication protocols and analyze the fuzzing results. The fuzzing tests include identifying key locations, mutation attacks, response messages, and crash / abnormal behavior reports for the identified fields. Specifically, it includes: The key location of the identified field includes sensitive field location logic and key usage scenario classification logic corresponding to the field, including the following: Sensitive field location logic: (1) Accurately locate cryptographic key fields in the parsed vehicle communication protocol data: key type: symmetric key, certificate private key; Random parameters: Initialization vector (IV), random number (nonce); Derived parameters: salt, KDF input.

[0039] (2) Metadata field collection dimensions, as shown in Table 3 below: Table 3

[0040] The classification logic for key usage scenarios corresponding to each field is detailed in Table 4 below. Table 4

[0041] The scenario classification system constructs a key scenario matrix for vehicle-to-everything (V2X) characteristics, as shown in Table 5 below: Table 5

[0042] The mutation attacks include the following: Boundary Value Mutation: Function Objective: To generate boundary value test cases for fields of a specific type, as shown below: (1) Select different boundary value generation strategies based on the field type (field_type) passed in; (2) Mutation strategy for SM4_KEY (128-bit key): Generate a 16-byte key consisting entirely of zeros (bytes(16)); Generate a 16-byte key consisting entirely of 0xFF bytes(

[255] *16)); Generate a key with the first 15 bytes being 0 and the last byte being 0x01 (minimum increment). Generate a key with the first 15 bytes being 0xFF and the last byte being 0xFE (decreasing in the largest order). (3) It can extend the processing of other field types (such as AES_KEY).

[0043] Formatting Fault Injection: Function Objective: To apply formatting distortion to fields of the original vehicle communication protocol, generating abnormal data, as shown below: (1) Receive the original vehicle communication protocol field (original) and length (length).

[0044] (2) Generate four types of format errors: Truncation distortion: Only the first half of the original vehicle communication protocol field is retained (length is halved); Excessive length distortion: 100 0x00 bytes are appended to the original vehicle communication protocol field to make the data excessively long.

[0045] First byte tampering: Change the first byte of the original vehicle communication protocol field to 0xFF, and leave the rest unchanged.

[0046] Bit Flip: Flips a bit in the original vehicle communication protocol field at a random position (implemented via the bit_flip function).

[0047] The intelligent deep mutation is as follows: Class initialization: Added during initialization to the pre-trained generative model (e.g., a generative adversarial network GAN model) to set the model's default path; Mutation generation method: Receive the fields of the original vehicle communication protocol (original) and generate a 128-dimensional random latent vector (latent_vec) based on it, which follows a normal distribution; input the fields of the vehicle communication protocol and the latent vector into the generator model (generator) to generate adversarial examples, and return the generated adversarial examples as the mutated data; The crash / abnormal behavior report includes behavior state analysis, entropy mutation detection, crash report architecture, and mutation strategy matrix, as shown below: Behavioral state analysis includes timeout detection and memory leak characteristics, as shown below: Timeout detection: (1) Dynamic threshold: Set differentiated timeout thresholds for different ECUs (power domain ≤ 50ms, entertainment domain ≤ 300ms). (2) Fault symptoms: ECU bus silence, watchdog timeout trigger.

[0048] Memory leak characteristics (1) Memory overwrite characteristic: 0xDEADBEEF (uninitialized memory); (2) Heap fragmentation characteristics: Repeated 0xFEFEFEFE pattern; (3) Null pointer dereference: 8 consecutive bytes of 0x00000000; Entropy mutation detection includes an information entropy security model and accurate memory corruption identification, as shown in Table 6 below: Table 6

[0049] Crash report architecture includes attack attribution, vulnerability description, and digital forensics, as shown below: (1) Attack attribution: attack_id: A unique identifier in the format FUZZ-YYYYMMDD-XXX; payload_hash: Provides a cryptographic fingerprint of the attack payload.

[0050] (2) Vulnerability Description: severity: An optimized version of CVSS 3.1 scoring; repro_steps: Multi-step reproduction with precise time windows; Impact: Identify abnormal ECU behavior (reboot / crash / data leak).

[0051] (3) Digital forensics: As shown in Table 7 below: Table 7

[0052] The mutation strategy matrix includes password field mutation strategies, as shown in Table 8 below: Table 8

[0053] The password field mutation strategy is expressed as follows: (1) Null byte injection Attack principle: Triggering a C language string processing vulnerability (null byte as terminator); The test boundary condition check is missing; typical vulnerability pattern: incorrect buffer length calculation.

[0054] Automotive-grade applications: Vulnerability in CAN bus authentication field processing; truncation of password field in OTA upgrade packages.

[0055] (2) Historical key replay Attack principle: Exploiting a vulnerability in the key rotation policy; testing the key expiration check mechanism; common vulnerability: session keys not expiring in a timely manner.

[0056] Automotive-grade applications: ECU debugging key reuse vulnerability; diagnostic session key rotation defect; vehicle-to-everything (V2X) TLS session recovery attack.

[0057] (3) ECB Oracle attack Attack principle: Exploit the lack of diffusion in ECB mode; test the error padding handling mechanism; typical vulnerability: Padding Oracle side channel.

[0058] Automotive-grade applications: AutoSAR SecOC frame encryption / decryption vulnerability; media stream encryption flaw in in-vehicle entertainment systems.

[0059] Compliance assessment module: This module generates risk detection reports based on the protocol intelligent parsing module and the dynamic fuzzing module, and constructs a cryptographic strength scoring model. This model is used to assess the security strength of field keys, specifically including: The password strength scoring model is expressed as follows: Score = f(key length, randomness entropy value, key update period); The score is the final rating.

[0060] The construction principle of the cryptographic strength scoring model includes the following: Key length (L): Generally, the longer the key length, the more difficult it is to crack and the higher the security. However, the relationship is not linear but logarithmic (because the complexity of a brute-force attack is exponentially related to the key length). For example, each additional bit doubles the security. Randomness entropy (E): Entropy measures the quality of randomness. Assuming key generation is random, entropy represents the uncertainty of the key space, and its unit is usually bits. For example, a completely random 128-bit key has an entropy of 128 bits. If the randomness is insufficient, the entropy will be less than 128. Key update cycle (T): The shorter the update cycle, the less harm will be caused if the key is cracked, thus improving overall security. However, the update cycle cannot be too short, otherwise it may lead to excessive operational complexity and system load. Therefore, the update cycle should be within a suitable range in the scoring; it is neither better the shorter it is, nor better the longer it is.

[0061] The overall scoring range of the cryptographic strength scoring model includes the following: The final score can be a score from 0 to 100, or a star rating from 0 to 10. An example calculation process is shown below: Assumption: Key length L = 128 bits; The randomness entropy value E = 120 (bits); The key update cycle is T = 7 days (i.e., 7 * 24 = 168 hours). Set L_min=64, L_max=512; Set the key length normalization: NL = log2(L) / log2(L_max); NL = log2(128) / log2(512) = 7 / 9 ≈ 0.7778; Entropy normalization: NE = E / L = 120 / 128 = 0.9375; Key update cycle normalization: set ideal intervals [T1=24 hours (1 day), T2=720 hours (30 days)].

[0062] T = 168 hours, which is between 24 and 720, so NT = 1.0; Weights: w1=0.4, w2=0.4, w3=0.2 (arithmetic mean); Therefore, Score = 0.40.7778 + 0.40.9375 + 0.2*1.0 = 0.31112 + 0.375 + 0.2 = 0.88612; The above is mapped to 100 points: 88.6 points.

[0063] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A password security detection system for intelligent connected vehicles, characterized in that, The system includes: The protocol intelligent parsing module is used to unpack multi-level vehicle communication protocols, identify the field types of the unpacked vehicle communication protocols, and match the vehicle communication protocols that have been identified by field types with a cryptographic feature library to identify whether each field of the vehicle communication protocol has risks. The cryptographic feature library includes sensitive field detection, encryption algorithm identification, hard-coded credential detection, weak algorithm detection, and protocol vulnerability detection. Dynamic fuzzing module: used to perform fuzzing tests on fields of vehicle communication protocols with potential risks and analyze the fuzzing test results. The fuzzing tests include identifying the key location of the field, mutation attacks, response messages, and crash / abnormal behavior reports. Compliance assessment module: This module generates risk detection reports based on the protocol intelligent parsing module and the dynamic fuzzing module, and constructs a password strength scoring model, which is used to evaluate the security strength of field keys.

2. The intelligent connected vehicle password security detection system according to claim 1, characterized in that, The unpacking of the multi-level vehicle communication protocol includes: The frame structure is parsed at the physical layer of the vehicle communication protocol. The parsed frame structure includes arbitration ID, data length code, and data field. The MAC address and VLAN tag are parsed at the data link layer of the vehicle communication protocol, as shown below: Ethernet frame = [Destination MAC][Source MAC][Optional VLAN][Type / Length][Data]; IPv4 / IPv6 addresses and fragmentation information are resolved at the network layer of the vehicle communication protocol. The port, serial number, and flag bits are parsed at the transport layer of the vehicle communication protocol. At the application layer of the vehicle communication protocol, the data is distributed to the corresponding application layer parser based on the transport layer port or protocol-specific identifier, and the application layer protocol performs custom parsing. The protocol stack of the vehicle communication protocol consists of multiple protocol layer parsers, arranged in order from the bottom layer to the top layer. The vehicle communication protocol parsing process starts from the bottom layer, where the vehicle communication protocol is passed in, each layer parser parses it in turn, and the remaining data is passed to the next layer. The context information is stored in a context dictionary, which is updated during the parsing process. Each parser is responsible for parsing the data in its own protocol layer and returning the parsing result and the remaining payload. When the parsing is complete, it returns a context containing all parsing information from the bottom layer to the application layer, which is used as the final output.

3. The intelligent connected vehicle password security detection system according to claim 2, characterized in that, The process of identifying the field types of the unpacked vehicle communication protocol includes: By combining the BiLSTM model with the CRF model, a field recognition model is constructed. This model is then used to identify the field types of vehicle communication protocols. A dataset is constructed using publicly available protocol documents, Wireshark samples, and manually labeled data. Protocol field types are labeled on the dataset and used as training data for the model. The field recognition model is then trained based on this training data. The field recognition model has a structure consisting of an input layer, a BiLSTM layer, and a CRF layer. The field recognition model is designed as follows: Model input: byte sequence of vehicle communication protocol payload, each byte is converted into a 256-dimensional one-hot vector or embedding vector; Model output: a sequence of labels for each byte; Input layer: Maps byte sequences to embedding vectors; BiLSTM layer: Uses bidirectional LSTM to capture contextual features; CRF layer: Models label transition probabilities and optimizes the global optimum of the label sequence; During the parsing of vehicle communication protocols, if an unknown protocol format is encountered, the application layer payload is intercepted and fed into the field recognition model for sequence labeling to obtain the field boundaries and types. The field information output by the field recognition model is then used for subsequent password feature database matching.

4. The intelligent connected vehicle password security detection system according to claim 3, characterized in that, The training of the field recognition model based on training data specifically includes the following steps: S11. Divide the training data into training set, validation set and test set according to a certain ratio, and initialize the field recognition model parameters; S12. Iterate the field recognition model several times. Each iteration includes dividing the training set into multiple batches, calculating the loss through forward propagation for each batch, updating the parameters through backpropagation, evaluating the performance on the validation machine, and saving the best model. S13. Evaluate the performance of the final model on the test set.

5. The intelligent connected vehicle password security detection system according to claim 4, characterized in that, The process of using a field recognition model to identify field types in vehicle communication protocols specifically includes the following steps: S21. Convert the original messages in the vehicle communication protocol into byte sequences and extract their features; S22. Use the trained field recognition model to label the byte sequence and obtain the field type of each byte; S23. Based on the annotation results, merge bytes with consecutive identical labels into one field, and determine the starting position and length of the field.

6. The intelligent connected vehicle password security detection system according to claim 1, characterized in that, The sensitive field detection includes general sensitive field detection, framework and protocol specialization rule detection, and obfuscation and anti-obfuscation detection. The encryption algorithm is identified by pattern matching to determine the encryption algorithm usage method, including key length and working mode; The hard-coded credential detection is a pattern that matches the hard-coded password, key, and API key; The protocol vulnerability detection includes protocol version detection, weak password suite detection, and certificate security detection. The weak algorithm detection includes a weak algorithm dictionary, a weak cipher suite list, and call chain analysis detection. The weak algorithm dictionary includes a hash algorithm list, a symmetric encryption algorithm list, and an asymmetric encryption algorithm list.

7. The intelligent connected vehicle password security detection system according to claim 6, characterized in that, The call chain analysis and detection specifically includes the following steps: S31. Search for calls to specific methods in the weak algorithm detection code; S32. Extract the algorithm name from the call; S33. Compare the extracted algorithm name with the list of algorithms of different categories in the weak algorithm dictionary to determine whether it belongs to a weak algorithm. S34. Analyze the data flow of the extracted algorithm instance to determine where it is used. If step S33 determines that it is a weak algorithm, then determine whether the weak algorithm instance is used for safety-critical operations. If so, mark it as a safety issue.

8. The intelligent connected vehicle password security detection system according to claim 1, characterized in that, The key location of the identification field includes sensitive field location logic and key usage scenario classification logic corresponding to the field; The mutation attacks include the following: Boundary value mutation: Generate test cases by selecting different boundary values ​​for the input field type; Formatting error injection: This involves applying formatting distortions to fields in the vehicle communication protocol to generate abnormal data. Intelligent deep mutation; A 128-dimensional random latent vector is generated based on the fields of the vehicle communication protocol, following a normal distribution. The fields of the vehicle communication protocol and the latent vector are input into the generator model to generate adversarial examples, and the generated adversarial examples are returned as the mutated data. The crash / abnormal behavior report includes behavior state analysis, entropy mutation detection, crash report architecture, and mutation strategy matrix.

9. The intelligent connected vehicle password security detection system according to claim 1, characterized in that, The password strength scoring model is expressed as follows: Score = f(key length, randomness entropy value, key update period); The score is the final rating.

Images