Data detection method and electronic equipment

Abstract

The invention relates to the technical field of data processing, in particular to a data detection method and electronic equipment. The method comprises the following steps: receiving a real-time data request, and obtaining equipment data and encrypted data corresponding to the real-time data request; calling target historical equipment data and target historical encrypted data from a historical database; detecting and comparing the equipment data with target historical equipment data, and determining an equipment data detection result; detecting and comparing the encrypted data with target historical encrypted data, and determining an encrypted data detection result; the equipment data detection result and the encrypted data detection result are combined and analyzed, a final detection result is determined, and the final detection result is used for representing whether the real-time data request is responded or not. The equipment data and the encrypted data are combined for detection, so that the detection accuracy and reliability are improved, the data are compared with historical data, disguise attack behaviors are effectively recognized, damage caused by the attack behaviors is reduced, and the safety is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data detection method and electronic device. Background Technology

[0002] Currently, the application of data transmission and communication between two devices is becoming increasingly widespread, making communication security increasingly important.

[0003] However, with the advancement of attack methods, data in the communication process is easily tampered with or leaked, making it impossible to effectively guarantee the security of communication transmission. Summary of the Invention

[0004] In view of this, the purpose of this application is to propose a data detection method and electronic device to solve the technical problem that data security cannot be effectively guaranteed in the current communication transmission process.

[0005] To achieve the above objectives, this application provides a data detection method, comprising: Receive a real-time data request and obtain the device data and encrypted data corresponding to the real-time data request; Retrieve target historical device data and target historical encrypted data from the historical database; The device data is compared with the target historical device data to determine the device data detection result; The encrypted data is compared with the target historical encrypted data to determine the encrypted data detection result; The final detection result is determined by combining and analyzing the device data detection results and the encrypted data detection results. Based on the final detection result, determine whether to respond to the real-time data request.

[0006] Based on the same inventive concept, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor implements the method described above when executing the computer program.

[0007] As can be seen from the above, the data detection method and electronic device provided in this application can, upon receiving a real-time data request, determine the corresponding device data and encrypted data based on the real-time data request, and retrieve the target historical device data and target historical encrypted data corresponding to the real-time data request from the historical database. Then, the device data can be compared with the target historical device data to determine the degree of difference between the two, thereby obtaining the device data detection result; and the encrypted data can be compared with the target historical encrypted data to determine the degree of difference between the two, thereby obtaining the encrypted data detection result. Finally, the device data detection result and the encrypted data detection result can be combined to determine the degree of difference between the overall situation and the historical situation, obtaining the final detection result. In this way, the security of the real-time data request can be identified based on the final detection result. If the final detection result determines that the device data and encrypted data are significantly different from the stored target historical device data and target historical encrypted data, and the real-time data request is identified as insecure and may involve attack behavior, the real-time data request will be intercepted in a timely manner and not responded to. The real-time data request will only be responded to when it is determined to be secure. This approach combines device data with encrypted data to improve detection accuracy and reliability. It also compares the data with historical data to effectively identify disguised attack behaviors and promptly intercept abnormal real-time data requests, thereby reducing the damage caused by attacks and enhancing security. Attached Figure Description

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

[0009] Figure 1 This is a schematic diagram illustrating an application scenario of the data detection method according to an embodiment of this application; Figure 2 This is a flowchart of a data detection method according to an embodiment of this application; Figure 3 This is a structural block diagram of the data detection device according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0010] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0011] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0012] Token: A token is a digital identifier used in various scenarios in the computer field. In information technology, it is a random string or encrypted data block used for authentication, secure access, or authorization control, representing authorization information for a user, device, or session.

[0013] SSL: Security Socket Layer, is an encryption technology used to protect sensitive data during transmission.

[0014] TLS: Transport Layer Security.

[0015] VIN: Vehicle Identification Number, also known as the chassis number.

[0016] SNI: Service Node Interface.

[0017] ALPN: Application Layer Protocol Negotiation, is an extension of TLS that allows application layer protocol negotiation over a secure connection.

[0018] IMEI: International Mobile Equipment Identity.

[0019] JA4: A new generation of network traffic fingerprinting technology, mainly used for TLS protocol traffic feature identification, to detect bot traffic and improve network security protection capabilities.

[0020] SOC_SN: A combination of System-on-a-Chip (SOC) and Serial Number (SN).

[0021] SIEM: Security Information and Event Management.

[0022] IP: Internet Protocol Address.

[0023] In related technologies, communication security is crucial during communication transmission between two devices (such as a vehicle and the cloud). However, with the continuous upgrading of attack methods, certificate key leakage attacks have become an increasingly serious problem. When leaked certificates or token keys are maliciously used to construct access to cloud services, attackers can impersonate legitimate senders to perform illegal operations, leading to user privacy leaks and data security risks.

[0024] The detection methods in related technologies mainly rely on static analysis of the request content, such as checking the legality of request parameters. However, these methods cannot effectively identify spoofing attacks based on leaked keys. In addition, they do not make full use of device data (such as device fingerprints) and historical behavior data to enhance the accuracy and real-time performance of detection.

[0025] Problems existing in related technologies: (1) When the leaked certificate or token key is maliciously used to construct access (e.g., forging vehicle access to the cloud), the detection methods of related technologies are difficult to detect and block the behavior of potential attackers in a timely manner.

[0026] (2) The detection methods of related technologies do not fully consider device fingerprints and historical behavior data, resulting in insufficient detection accuracy and real-time performance.

[0027] The reason for the problem: (1) The leakage of certificates or token keys may occur at multiple stages. For example, attackers may forge data on the vehicle side, which may occur during the production, transportation or use of the vehicle.

[0028] (2) Attackers can use leaked keys to construct seemingly legitimate requests and bypass static parameter-based detection.

[0029] (3) The detection methods in related technologies lack comprehensive analysis of device fingerprints and historical behavior, and cannot effectively identify spoofing attacks.

[0030] Based on the above description, the principles and spirit of this application will be explained in detail below with reference to several representative embodiments.

[0031] refer to Figure 1This diagram illustrates an application scenario for the data detection method provided in this application. The application scenario includes a vehicle-side terminal 101 and a cloud-side terminal 102. Both the vehicle-side terminal 101 and the cloud-side terminal 102 can be connected via wired or wireless communication networks. The cloud-side terminal 102 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network) architecture, and big data and artificial intelligence platforms.

[0032] Vehicle terminal 101 sends a real-time data request to cloud terminal 102. Upon receiving the request, cloud terminal 102 determines the corresponding device data and encrypted data based on the request, and retrieves the target historical device data and target historical encrypted data corresponding to the real-time data request from the historical database. Then, it compares the device data with the target historical device data to determine the degree of difference, thus obtaining the device data detection result. Similarly, it compares the encrypted data with the target historical encrypted data to determine the degree of difference, thus obtaining the encrypted data detection result. Finally, it combines the device data detection result and the encrypted data detection result to determine the degree of difference between the overall data and historical data, obtaining the final detection result. In this way, cloud terminal 102 can identify and determine the security of the real-time data request based on the final detection result. If the real-time data request is determined to be insecure, it will be intercepted and not responded to. Only when the real-time data request is determined to be secure will it be responded to, reducing the damage caused by attacks.

[0033] The following is combined with Figure 1 The application scenarios described above illustrate the data detection method according to exemplary embodiments of this application. It should be noted that the above application scenarios are merely shown to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way. Rather, the embodiments of this application can be applied to any applicable scenario.

[0034] Based on the above, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0035] The data detection method proposed in the embodiments of this application is applied to a receiving end, which is communicatively connected to a sending end. The receiving end is a device capable of responding to requests from the sending end, and the sending end is a device capable of sending requests.

[0036] The receiving end is the cloud, while the corresponding sending end can be a terminal device. Terminal devices include, but are not limited to, desktop computers, mobile phones, mobile computers, tablets, media players, smart wearable devices, personal digital assistants (PDAs), in-vehicle devices, or other electronic devices capable of performing the corresponding functions.

[0037] like Figure 2 As shown, the method includes: Step 201: Receive a real-time data request and obtain the device data and encrypted data corresponding to the real-time data request.

[0038] In practice, the receiving end will receive a real-time data request from the target sending end. The receiving end will pause responding to the real-time data request and first determine the corresponding device data and encrypted data based on the real-time data request.

[0039] Among them, a real-time data request is a function request that the target sender wants to use the receiver to execute. For example, a real-time data request includes at least one of the following: a data retrieval request, an authentication request, a control instruction request, or a forwarding request.

[0040] The device data is the identification information of the corresponding target sender (e.g., device fingerprint), and the identification information includes at least one of the following: device number, device number operating system version, and hardware configuration.

[0041] Encrypted data refers to data information encrypted using the encryption method employed to encrypt the transmission of this real-time data request, such as SSL-encrypted data.

[0042] Step 202: Retrieve the target historical device data and target historical encrypted data corresponding to the real-time data request from the historical database.

[0043] In practice, the receiving end stores each data request sent by the sending end, along with its corresponding historical device data and historical encrypted data, in a historical database for subsequent detection and comparison.

[0044] In addition, two repositories are built for each sender in the historical database: one for device data to store historical device data, and another for encrypted data to store historical encrypted data. Furthermore, the historical database stores only the historical device data and encrypted data corresponding to secure data requests.

[0045] After receiving a real-time data request, the receiving end will find the device data repository corresponding to the target sender in the historical database according to the target sender of the real-time data request, extract the target historical device data from it, and extract the target historical encrypted data from the corresponding encrypted data repository.

[0046] Step 203: Compare the device data with the target historical device data to determine the device data detection result.

[0047] In practice, the degree of difference between the equipment data and the extracted target historical equipment data is compared to obtain the equipment data detection results.

[0048] Equipment data detection results are used to characterize the differences between the equipment data and the target historical equipment data. The greater the difference, the higher the value of the corresponding equipment data detection result.

[0049] Step 204: Compare the encrypted data with the target historical encrypted data to determine the encrypted data detection result.

[0050] In practice, the degree of difference between the encrypted data and the extracted target historical encrypted data is compared to obtain the encrypted data detection result.

[0051] The encrypted data detection result is used to characterize the difference between the encrypted data and the target's historical encrypted data. The greater the difference, the higher the value of the corresponding encrypted data detection result.

[0052] Step 205: Combine and analyze the device data detection result and the encrypted data detection result to determine the final detection result, wherein the final detection result is used to indicate whether to respond to the real-time data request.

[0053] In practice, the device data detection results and encrypted data detection results can be combined to analyze the overall security of the real-time data request and obtain the final detection result. For example, the device data detection results and encrypted data detection results can be directly summed or weighted summed to obtain the final detection result.

[0054] The larger the value of the final detection result, the greater the difference between the device data and encrypted data and the historical target device data and historical target encrypted data, and the higher the corresponding level of security risk.

[0055] In practice, after obtaining the final test results, the security level of the final test results can be determined, and then the real-time data request can be intercepted according to the security level.

[0056] For example, the corresponding security levels include four levels, namely: The final detection result is in the range of [0, first threshold], which belongs to the release level. Real-time data requests at this release level are released and a response is executed.

[0057] The final detection result is within the range of (first threshold, second threshold), which belongs to the marking level. Real-time data requests of this marking level are marked and saved, and a response is executed. Subsequently, all data requests of the marking level are combined. If the combined request is considered to be an abnormal request, the sender of the corresponding data request will be marked as abnormal, and subsequent data requests from the sender marked as abnormal will be directly intercepted.

[0058] The final detection result falls within the range of (second threshold, third threshold), which is considered the assessment level. Real-time data requests at this assessment level are displayed to allow users to determine whether the request is abnormal. Based on the user's assessment, the appropriate response is determined. (For example, the display may show three options: allow, block for a predetermined duration, or revoke; users can choose based on experience, and the action is taken accordingly.) Targets identified as abnormal after assessment are marked as such, and subsequent data requests from these marked targets are directly blocked.

[0059] If the final detection result is greater than the third threshold, it is considered an anomaly. Real-time data requests of this anomaly level will be directly intercepted, and the target sender that sent the real-time data request will be marked as an anomaly, generating a warning message. After anomaly marking, subsequent data requests from the marked sender will be directly intercepted.

[0060] The above scheme enables the determination of corresponding device data and encrypted data upon receiving a real-time data request. It also retrieves the target historical device data and target historical encrypted data corresponding to the real-time data request from the historical database. The device data is then compared with the target historical device data to determine the degree of difference, thus obtaining the device data detection result. Similarly, the encrypted data is compared with the target historical encrypted data to determine the degree of difference, thus obtaining the encrypted data detection result. Finally, the device data detection result and the encrypted data detection result are combined to determine the overall difference from historical data, resulting in the final detection result. This final detection result allows for the identification of the security of the real-time data request. If the final detection result indicates a significant difference between the device data and encrypted data and the stored target historical device data and target historical encrypted data, the real-time data request is deemed insecure and may involve attacks. In such cases, the real-time data request is promptly intercepted and not responded to. Only when the security of the real-time data request is determined will a response be given. This approach combines device data with encrypted data to improve detection accuracy and reliability. It also compares the data with historical data to effectively identify disguised attack behaviors and promptly intercept abnormal real-time data requests, thereby reducing the damage caused by attacks and enhancing security.

[0061] In some embodiments, prior to step 201, the method further includes: Step A1: Obtain historical data request and determine the historical device data and historical encrypted data in the historical data request.

[0062] In practice, the receiving end records and stores each received data request. During historical periods, historical device data and encrypted data are extracted from historical data requests.

[0063] Step A2: Determine the historical sender of the historical data request and obtain the historical login data of the historical sender.

[0064] In practice, to facilitate storage, the corresponding historical sender will be determined based on the historical data request, and its corresponding historical login data (e.g., device number, certificate, or token) will be determined.

[0065] Step A3: Associate the historical login data with the corresponding historical device data and historical encrypted data, and store them in the historical database.

[0066] In practice, if the historical sender has been stored, the historical database will contain a device data repository and an encrypted data repository corresponding to the historical login data. If the historical sender has not been stored, the historical database will create a new device data repository and an encrypted data repository corresponding to the historical login data.

[0067] The obtained historical device data is stored in the device data repository associated with the historical login data; the obtained historical encrypted data is stored in the encrypted data repository associated with the historical login data.

[0068] The above scheme can store historical device data and historical encrypted data corresponding to each historical sender in the historical database. This makes it convenient to directly look up the corresponding historical device data and historical encrypted data for detection and comparison after receiving a data request. Then, based on the degree of difference after comparison, it can determine the abnormality of the subsequent data request, thereby enabling timely detection of abnormal data requests and interception, thus improving the security of data requests.

[0069] In some embodiments, step A1 includes: Step A11: Obtain historical data request, determine the identification information of the historical sender that sent the historical data request, and use the identification information as the historical device data.

[0070] In practice, the historical sending end is equipped with a fingerprint collection module, which can collect the identification information (e.g., unique identification information) of the historical sending end. The identification information includes at least one of the following: device number, operating system version, and hardware configuration.

[0071] When a historical data request is received, the receiving end sends a command to the fingerprint collection module of the historical sending end. The fingerprint collection module then feeds back the collected identification information to the receiving end so that the receiving end can store it.

[0072] Step A12: Determine the encryption process data during the transmission authentication process with the historical sender, and use the encryption process data as the historical encrypted data.

[0073] In practice, the receiving end will also retrieve the encryption process data from the historical sender during the transmission authentication process when sending historical data requests. At least a portion of this encryption process data can be used as historical encrypted data. This encryption process data represents the key negotiation process for certificate two-way authentication between the receiving end and the historical sender before the formal TSP data transmission.

[0074] The above scheme can accurately identify historical device data and historical encrypted data from the historical sending end, providing a reliable basis for combining and comparing the two when making subsequent data requests.

[0075] In some embodiments, step A12 includes: Step A121: Determine the handshake process data for two-way authentication with the historical sender.

[0076] In practice, the mutual authentication between the receiving end and the historical sending end includes either TLS 1.2 mutual authentication or TLS 1.3 mutual authentication. The corresponding handshake process data is the handshake process data for either TLS 1.2 or TLS 1.3 mutual authentication.

[0077] The handshake process data for TLS 1.2 mutual authentication is as follows: Phase 1: Initial handshake.

[0078] 1. ClientHello → The previous sender initiated a connection, sending the supported TLS versions, a list of cipher suites, a random number, etc.; 2. ServerHello → The receiving end selects the TLS version and cipher suite, and sends a random number to the receiving end.

[0079] Phase Two: Authentication of the Receiving End.

[0080] 3. Certificate (SRV) → The receiving end sends its own certificate chain to prove its identity; 4. Certificate Request → Key step: The receiving end requires the sending end to also provide a certificate (unique to two-way authentication); 5. Server Hello Done → This indicates to the receiver that the initial message has been sent.

[0081] Phase 3: Historical sender authentication.

[0082] 6. Client Certificate → The sending end sends its own certificate to the receiving end; 7. Client Key Exchange → The sender generates a pre-master key, encrypts it with the receiver's public key, and then sends it. 8. Certificate Verify → The sender in the past signs the handshake message with its private key to prove that it has the private key corresponding to the certificate. Phase 4: Establishment of safe passages.

[0083] 9. ChangeCipherSpec (C) → Enables negotiated encryption parameters on historical senders; 10. Finished (C) → The historical sender sends an encrypted completion message to verify the integrity of the handshake; 11. ChangeCipherSpec (S) → Enables negotiated encryption parameters on the receiving end; 12. Finished (S) → The receiving end sends an encrypted completion message.

[0084] For the TLS 1.3 two-way authentication handshake process data, the messages after 2.ServerHello in the above TLS 1.2 two-way authentication handshake process data are packaged into EncryptedExtensions, and the other contents are the same as the above TLS 1.2 two-way authentication handshake process data.

[0085] Step A122: Extract encryption-related encryption process data from the handshake process data, and use the encryption process data as the historical encryption data.

[0086] In practice, encryption-related encryption process data is extracted from the handshake process data. This encryption process data includes at least one of the following: SSL cryptographic fingerprint, certificate chain, encryption protocol version, and key exchange algorithm.

[0087] For example, encryption process data includes: SSL cryptographic fingerprints (such as JA4 fingerprints). The specific extraction process of SSL cryptographic fingerprints is as follows: Extract the protocol version (e.g., the protocol version of ClientHello), the list of ciphertext packages (arranged in order of appearance), the list of extension types (arranged in order of appearance), and the SNI length (where "00" is used if there is no SNI). Concatenate these components and, for hash-encrypted data, extract a predetermined number of bytes (e.g., for 256-bit hash-encrypted data SHA256, extract the first 12 bytes). Combine these components and convert them into a character stream using a predetermined conversion rule (e.g., base64url) to obtain the SSL cryptographic fingerprint.

[0088] The above scheme allows for the extraction of more accurate historical encrypted data by using the handshake process data from the encryption process during which the sender and receiver perform two-way authentication before sending historical data requests. This handshake process data includes the negotiated encryption process data.

[0089] In some embodiments, step 201 includes: Step 2011: Determine the identification information of the target sender that sent the real-time data request, and use the identification information of the target sender as the device data.

[0090] In practice, the target sending end is equipped with a fingerprint acquisition module, which can collect the identification information of the target sending end. The identification information includes at least one of the following: device number, operating system version, and hardware configuration.

[0091] In response to a real-time data request, the receiving end sends a command to the fingerprint acquisition module of the target sending end, and the fingerprint acquisition module then feeds back the acquired identification information to the receiving end.

[0092] Step 2012: Determine the encryption process data during the transmission authentication process with the target sending end as the encrypted data.

[0093] In practice, the mutual authentication between the receiving end and the target sending end includes either TLS 1.2 mutual authentication or TLS 1.3 mutual authentication. The corresponding handshake process data is the handshake process data for either TLS 1.2 or TLS 1.3 mutual authentication (the specific process is the same as the handshake process data for TLS 1.2 or TLS 1.3 mutual authentication described in step A121 above, and will not be repeated here).

[0094] The above scheme enables the accurate identification of the device data and encrypted data corresponding to the target sender of a real-time data request after receiving the request. This facilitates the subsequent combination of the two for testing, determining whether the real-time data request is secure. The accuracy of security testing by combining device data and encrypted data is higher.

[0095] In some embodiments, step 202 includes: Step 2021: Determine the target login data of the target sending end that sent the real-time data request, and retrieve the target historical device data and target historical encrypted data corresponding to the target login data from the historical database.

[0096] In practice, the target login data includes at least one of the following: device ID, certificate, or token, preferably device ID.

[0097] Since the historical database stores historical device data and historical encrypted data corresponding to various sending ends, after obtaining the target login data of the target sending end, the device data repository and encrypted data repository corresponding to the target login data can be determined. Then, the target historical device data can be retrieved from the device data repository, and the target historical encrypted data can be retrieved from the encrypted data repository.

[0098] The above method can accurately identify the target sender of the real-time data request, the corresponding target historical device data, and the target historical encrypted data. This extraction method ensures accuracy while being relatively simple and quick.

[0099] In addition, as a preferred embodiment, the device data repository and encrypted data repository corresponding to the sending end in the historical database can be arranged in chronological order, so that the target historical device data and target historical encrypted data can be selected within a predetermined time period (e.g., within a predetermined time before the current time) during extraction.

[0100] In some embodiments, step 203 includes: Step 2031: Determine certificate data based on the device data.

[0101] In practice, the device number (e.g., chassis number) in the device data is determined, and the certificate data is determined based on the device number.

[0102] Step 2032: Obtain a normal certificate data packet, determine whether the certificate data is in the normal data packet, and obtain the certificate detection result.

[0103] In practice, the receiving end stores normal certificate data packets from various legitimate devices and determines whether the obtained certificate data exists in the normal data packets. If it exists, the corresponding certificate detection result is determined to be normal; if it does not exist, the corresponding certificate result is determined to be abnormal.

[0104] In addition, the receiving end will set a certificate blacklist to determine whether the received certificate data is on the blacklist. If it is, the real-time data request will be directly intercepted. Otherwise, the process described above will be repeated to determine whether the certificate data exists in a normal certificate data packet.

[0105] Step 2033: Extract the device fingerprint from the device data, and compare the device fingerprint with the target historical device data to determine the device fingerprint detection result.

[0106] In practice, the device fingerprint in the device data is the identification information. The device fingerprint is matched with the extracted target historical device data. If any field does not match, the device fingerprint detection result is determined to be abnormal. If all fields match, the device fingerprint detection result is determined to be normal.

[0107] In addition, during the field matching process, if the device number does not match, the real-time data request will be directly intercepted.

[0108] Step 2034: The certificate detection result and the device fingerprint detection result are used as the device data detection result.

[0109] The above solution combines certificate detection and device fingerprint detection, resulting in device data detection results that include both certificate detection and device fingerprint detection results, thus ensuring more accurate device data detection.

[0110] In some embodiments, step 204 includes: Step 2041: Extract the content of the specified fields from the encrypted data, and concatenate the extracted specified fields to obtain the encrypted fingerprint data to be detected.

[0111] In practice, the encrypted data includes the encrypted data of the entire two-way authentication process. The corresponding set field content can be extracted from it, and after being concatenated according to a predetermined format, the encrypted fingerprint data to be detected (e.g., JA4 fingerprint) can be obtained.

[0112] Step 2042: Compare the similarity between the encrypted fingerprint data to be detected and the target historical encrypted data to determine the similarity comparison result.

[0113] In practice, the most frequently occurring common historical encrypted fingerprints (e.g., common JA4 fingerprints) are extracted from the target historical encrypted data within a predetermined time period.

[0114] The encrypted fingerprint data to be tested is compared with common historical encrypted fingerprints in terms of string similarity. If they are the same, it proves that the encrypted fingerprint data to be tested is not abnormal, and the similarity comparison result is not abnormal; if they are different, it proves that the encrypted fingerprint data to be tested is abnormal, and the similarity comparison result is abnormal.

[0115] Step 2043: Determine the location information corresponding to the encrypted fingerprint data to be detected and the distance between it and the location information corresponding to the target historical encrypted data; determine whether the distance is less than or equal to the distance movement threshold; and obtain the location comparison result.

[0116] In practice, the location information corresponding to the encrypted fingerprint data to be detected (e.g., the current IP address of the target sender) is determined. Then, the location information of the target sender at a predetermined time (e.g., the IP address of the target sender 5 minutes ago) is retrieved from the target's historical encrypted data.

[0117] Then, the location information corresponding to the encrypted fingerprint data to be detected can be determined, along with the distance between it and the location information corresponding to the target historical encrypted data. Based on this distance, it can be determined whether the user's movement within a predetermined time period is less than or equal to a distance movement threshold. If so, the location comparison result is considered normal; otherwise, it is considered abnormal. For example, if the location information corresponding to the encrypted fingerprint data to be detected is Shenzhen, and the location information corresponding to the target historical encrypted data is Beijing, it is impossible to move from Beijing to Shenzhen within the predetermined time period. Therefore, it is clear that the sending end corresponding to the encrypted fingerprint data to be detected is a different sending end from the sending end corresponding to the target historical encrypted data, and the location comparison result is abnormal.

[0118] Step 2044: Combine the encrypted fingerprint data to be detected with the target historical encrypted data within a predetermined time period to obtain combined data; determine the number of types of encrypted data in the combined data; determine whether the number of types is greater than the type threshold; and obtain the type comparison result.

[0119] In practice, to avoid excessive screen-spamming, the encrypted fingerprint data to be detected is combined with target historical encrypted data over a predetermined time period to determine the corresponding number of categories. A higher number of categories indicates a higher frequency of screen-spamming. If the number of categories exceeds a category threshold, excessive screen-spamming is confirmed, and the corresponding category comparison result is abnormal; if the number of categories is less than or equal to the category threshold, the screen-spamming is considered normal, and the category comparison result is normal.

[0120] The corresponding scheduled time period is the time period from the current time, which can be set according to the user's actual needs.

[0121] Step 2044: Combine the similarity comparison result, the location comparison result, and the category comparison result as the encrypted data detection result.

[0122] In practice, the results of similarity comparison, location comparison, and category comparison are combined to obtain the encrypted data detection results.

[0123] The above scheme combines similarity detection, location detection, and category detection, resulting in more accurate encrypted data detection results.

[0124] In some embodiments, step 205 includes: Step 2051: Determine the equipment data anomaly index based on the equipment data detection results.

[0125] In practice, the data detection results of this device include: certificate detection results and device fingerprint detection results.

[0126] The certificate anomaly index is determined based on the certificate detection results, with higher anomaly indices corresponding to higher certificate differences; similarly, the device fingerprint anomaly index is determined based on the device fingerprint detection results, with higher anomaly indices corresponding to higher device fingerprint differences.

[0127] The certificate anomaly index is added to the device fingerprint anomaly index, or a weighted sum is added, to obtain the device data anomaly index.

[0128] Step 2052: Determine the encryption data anomaly index based on the encryption data detection results.

[0129] In practice, the encrypted data detection results include: similarity comparison results, location comparison results, and category comparison results.

[0130] The similarity anomaly index is determined based on the similarity comparison results, with a higher similarity anomaly index corresponding to a lower degree of similarity; the position anomaly index is determined based on the position comparison results, with a higher position anomaly index corresponding to a higher degree of position difference; and the category anomaly index is determined based on the category comparison results, with a higher category anomaly index corresponding to a higher number of categories.

[0131] The obtained similarity anomaly index, location anomaly index, and category anomaly index can be added together, or weighted together, to obtain the encrypted data anomaly index.

[0132] Step 2053: The device data anomaly index and the encrypted data anomaly index are summed to obtain the total anomaly index, and the total anomaly index is used as the final detection result.

[0133] In practice, the total anomaly index is used as the final detection result, and the final detection result is classified into security levels. Then, the corresponding strategy is executed on the real-time data request according to the corresponding security level (as described in detail in step 205 above, which will not be repeated here).

[0134] The above solution allows for a comprehensive assessment of anomalies in both device data and encrypted data. The resulting total anomaly index more closely reflects the actual anomalies in real-time data requests, making the final detection result more accurate. This leads to a more accurate assessment of the security of real-time data requests based on this final detection result, enabling timely interception of abnormal real-time data requests, preventing data leakage, and improving data security.

[0135] The data detection method of this application embodiment is described below with a specific example (e.g., the receiving end is the cloud and the sending end is the vehicle end). The specific process is as follows: I. The process of storing historical data: (1) Historical device data collection: Each historical sending end is equipped with a fingerprint collection module. The fingerprint collection module can collect the identification information of the historical sending end. The identification information includes at least one of the following: device number, operating system version and hardware configuration.

[0136] (2) Historical encrypted data collection: Before receiving historical data requests, determine the handshake process data for two-way authentication between the receiving end and each vehicle end.

[0137] The handshake process data for TLS 1.2 mutual authentication is as follows: Phase 1: Initial handshake.

[0138] 1. ClientHello → The previous sender initiated a connection, sending the supported TLS versions, a list of cipher suites, a random number, etc.; 2. ServerHello → The receiving end selects the TLS version and cipher suite, and sends a random number to the receiving end.

[0139] Phase Two: Authentication of the Receiving End.

[0140] 3. Certificate (SRV) → The receiving end sends its own certificate chain to prove its identity; 4. Certificate Request → Key step: The receiving end requires the sending end to also provide a certificate (unique to two-way authentication). 5. Server Hello Done → This indicates to the receiver that the initial message has been sent.

[0141] Phase 3: Historical sender authentication.

[0142] 6. Client Certificate → The sending end sends its own certificate to the receiving end; 7. Client Key Exchange → The sender generates a pre-master key, encrypts it with the receiver's public key, and then sends it. 8. Certificate Verify → The sender in the past signs the handshake message with its private key to prove that it has the private key corresponding to the certificate. Phase 4: Establishment of safe passages.

[0143] 9. ChangeCipherSpec (C) → Enables negotiated encryption parameters on historical senders; 10. Finished (C) → The historical sender sends an encrypted completion message to verify the integrity of the handshake; 11. ChangeCipherSpec (S) → Enables negotiated encryption parameters on the receiving end; 12. Finished (S) → The receiving end sends an encrypted completion message.

[0144] For the TLS 1.3 two-way authentication handshake process data, the messages after 2.ServerHello in the above TLS 1.2 two-way authentication handshake process data are packaged into EncryptedExtensions, and the other contents are the same as the above TLS 1.2 two-way authentication handshake process data.

[0145] Extract the SSL cryptographic fingerprint (i.e., encryption-related encryption process data) from the handshake process data: The protocol version (e.g., the protocol version of ClientHello), the list of ciphertext packages (arranged in order of appearance), the list of extension types (arranged in order of appearance), and the SNI length (where "00" is used if there is no SNI) are extracted from the handshake process, concatenated, and for hash-encrypted data, the first 12 bytes of the hash-encrypted data are taken as a predetermined number of bytes. These are combined and converted into a character stream using a predetermined conversion rule (e.g., base64url) to obtain the SSL cryptographic fingerprint.

[0146] For example, an SSL cryptographic fingerprint is a 24-character JA4 fingerprint: (JA4= <protocol><cipher_hash><extension_hash><sni_len> <alpn>).

[0147] Example JA4 fingerprint: t13d171100_8daaf6152771_e5623e34a96a_00h2; Where: t13 → TLS1.3; d171100 → 6-bit hash of 17 ciphertext suites; 8daaf6152771 → 6-bit hash of extended list; e5623e34a96a → SNI length and ALPN hash; 00h2 → SNI length 00, ALPN is h2.

[0148] In addition, the encryption process data also includes at least one of the following: certificate chain, encryption protocol version, and key exchange algorithm.

[0149] II. The detection process for real-time data requests: (1) Obtain the device data and encrypted data corresponding to the real-time data request.

[0150] 1) Obtain device data from the target sending end (e.g., the target vehicle) of the real-time data request.

[0151] In response to a real-time data request, the receiving end sends a command to the fingerprint acquisition module of the target sending end, and the fingerprint acquisition module then feeds back the acquired identification information to the receiving end.

[0152] For example, the device data obtained from the target vehicle is: Vehicle Identification Number (VIN) + Vehicle Serial Number (IMEI) + Chip Unique Number (SOC_SN) + Operating System Version Number.

[0153] 2) Obtain encrypted data for the transmission authentication process with the target sender (e.g., the target vehicle).

[0154] For example, encrypted data is the JA4 fingerprint in the SSL encrypted data of the two-way authentication process (e.g., 24 characters, recording the TLS version, cipher suite, extension order, SNI length, etc.).

[0155] (2) Retrieve from historical database.

[0156] The identified device data includes: device number (e.g., vehicle identification number, VIN), certificate-related data, target historical device data, and target historical encrypted data, which are determined from the historical database based on the device number.

[0157] The certificate-related data includes: at least one certificate corresponding to the target sender, the corresponding certificate serial number, and currently used valid certificates, forming a normal certificate packet. It will also retrieve revoked certificates (i.e., the certificate blacklist).

[0158] The target historical device data is the historical device data corresponding to the previous historical data request preceding this real-time data request. For example, IMEI and SOC_SN.

[0159] The target historical encrypted data is: the most frequently used JA4, and other JA4s, for a predetermined period of time (e.g., within the previous 30 days).

[0160] (3) Compare the equipment data and encrypted data with the data retrieved from the historical database.

[0161] 1) Certificate comparison.

[0162] Determine if the certificate data obtained above exists in the normal data packet. If it exists, determine that the corresponding certificate detection result is that the certificate is not abnormal; if it does not exist, determine that the corresponding certificate result is abnormal and determine that the certificate has drifted (for example, determine that the first abnormality score corresponding to the certificate abnormality is 30 points).

[0163] The receiving end also sets a certificate blacklist to determine whether the received certificate data is in the certificate blacklist. If it is, the real-time data request will be directly intercepted.

[0164] 2) Equipment data comparison.

[0165] The device fingerprint in the device data is a unique identifier. The device fingerprint is matched with the extracted target historical device data. If any field does not match, the device fingerprint detection result is determined to be abnormal (for example, the second abnormal score corresponding to the abnormal device fingerprint is determined); if all fields match, the device fingerprint detection result is determined to be normal.

[0166] For example, compare the IMEI and SOC_SN in the device data with the IMEI and SOC_SN of the target historical device data field by field: If any field does not match, it indicates a device mutation and an abnormal device fingerprint. For example, the corresponding second abnormality score is 20 points.

[0167] During the field matching process, if the device number (VIN) in the device data and the target historical device data are inconsistent, the real-time data request will be directly intercepted.

[0168] 3) Comparison of encrypted data.

[0169] I. The encrypted data includes the encrypted data of the entire two-way authentication process. The corresponding set field content can be extracted from it, and after being concatenated according to a predetermined format, the encrypted fingerprint data to be detected (e.g., JA4 fingerprint) can be obtained.

[0170] Extract the most frequently occurring common historical encrypted fingerprints (e.g., common JA4 fingerprints) from the target historical encrypted data within a predetermined time period.

[0171] The encrypted fingerprint data to be detected is compared with the string similarity of common historical encrypted fingerprints. If they are the same, it proves that the encrypted fingerprint data to be detected is not abnormal and the similarity comparison result is not abnormal; if they are different, it proves that the encrypted fingerprint data to be detected is abnormal and the similarity comparison result is abnormal (for example, determining the third abnormal score).

[0172] For example, compare the JA4 fingerprints in the currently obtained encrypted data with common JA4 fingerprints in the target's historical encrypted data: if they are different, the similarity comparison result is determined to be abnormal, and the third abnormality score is 15 points.

[0173] II. Check IP geolocation: Determine the location information corresponding to the encrypted fingerprint data to be detected (e.g., the current IP address of the target sender). Retrieve the location information of the target sender from the target's historical encrypted data at a predetermined time (e.g., 5 minutes) prior to the current time (e.g., the IP address of the target sender 5 minutes ago).

[0174] Then the location information corresponding to the encrypted fingerprint data to be detected can be determined, and the distance between it and the location information corresponding to the target historical encrypted data can be determined. Based on the distance, it can be determined whether the distance the user moves within a predetermined time period is less than or equal to the distance movement threshold. If it is, the location comparison result is determined to be normal; otherwise, the location comparison result is determined to be abnormal (for example, determining the fourth abnormal score).

[0175] For example, the location information corresponding to the encrypted fingerprint data to be detected is Shenzhen, while the location information corresponding to the target historical encrypted data is Beijing. It is impossible to move from Beijing to Shenzhen within the predetermined time period. Therefore, it is obvious that the sending end corresponding to the encrypted fingerprint data to be detected is a different sending end from the sending end corresponding to the target historical encrypted data, and the location comparison result is abnormal.

[0176] 4) Compare refresh rates.

[0177] The number of different types of encrypted fingerprints to be detected is determined by combining the target historical encrypted data within a predetermined time period (e.g., the number of JA4 types in the current period and the predetermined time period). The more types there are, the higher the frequency of the screen refresh.

[0178] If the number of categories exceeds the category threshold, it is determined that there is excessive posting behavior, and the corresponding category comparison result is abnormal (for example, the fifth abnormal score is determined); if the number of categories is less than or equal to the category threshold, it is determined that the posting behavior is normal, and the category comparison result is normal.

[0179] For example, if more than 3 types of JA4 appear within 30 seconds, the type comparison result is determined to be abnormal, and the corresponding fifth abnormality score is 10 points.

[0180] (4) Calculate the total score and determine the safety level.

[0181] The first abnormal score (i.e., certificate abnormality index) and the second abnormal score (i.e. device fingerprint abnormality index) obtained above are added together to obtain the device data abnormality score (i.e. device data abnormality index).

[0182] The third anomaly score (i.e., similarity anomaly index), the fourth anomaly score (i.e., location anomaly index), and the fifth anomaly score (i.e., category anomaly index) obtained above are added together to obtain the encrypted data anomaly score (i.e., encrypted data anomaly index).

[0183] The total anomaly score (i.e., the total anomaly index) is obtained by adding the device data anomaly score and the encrypted data anomaly score together.

[0184] The safety level is divided into four levels based on the total anomaly score: 1) If the total anomaly score is between [0, first threshold] (e.g., 0 to 39 points), it belongs to the release level. Real-time data requests of this release level are released and a response is executed. 2) The total anomaly score is between (first threshold, second threshold) (e.g., 40 to 54 points). It belongs to the marking level. Real-time data requests of this marking level are marked (e.g., highlighted, bolded, underlined, flashing, or font color changed) and written into SIEM. The response is executed. Subsequently (e.g., the next day), all data requests of the marking level are combined. If the combined data request is considered to be an anomaly request, the sender of the corresponding data request will be marked as an anomaly. Subsequent data requests from the sender marked as an anomaly will be directly intercepted.

[0185] 3) Total anomaly scores falling within the range of (second threshold, third threshold) (e.g., 55 to 69 points) are considered an assessment level. Real-time data requests at this assessment level are displayed to allow users to determine whether they are anomaly requests. Based on the user's assessment, a decision is made on whether to allow the real-time data request. Target senders identified as having anomaly requests are marked as such, and subsequent data requests from these marked target senders are directly blocked.

[0186] For example, the on-duty user will receive the device data, encrypted data, various anomaly scores, and total anomaly score (such as VIN, the composition of various anomaly scores, map trajectory, certificate chain, and before-and-after comparison screenshots of JA4) corresponding to the assessment level. When displaying this data, three controls will be shown: release, block for a predetermined duration, or revocation. The user needs to make a choice based on experience within the predetermined duration (e.g., 3 to 5 minutes), and then execute the corresponding result based on the user's choice.

[0187] Furthermore, for real-time data requests deemed normal by the user, the corresponding device data and encrypted data are added to the corresponding whitelist repository in the historical database. Conversely, for real-time data requests deemed abnormal by the user, the corresponding device data and encrypted data are added to the corresponding blacklist repository in the historical database.

[0188] 4) If the total anomaly score is greater than the third threshold (e.g., greater than or equal to 70 points), it belongs to the anomaly level. Real-time data requests of this anomaly level will be directly intercepted, the target sender that sent the real-time data request will be marked as an anomaly, the certificate corresponding to the target sender will be temporarily blacklisted for a predetermined period of time (e.g., 1 hour), and an early warning message will be generated for the operation and maintenance terminal. After the anomaly is marked, subsequent data requests from the anomaly marked sender will be directly intercepted.

[0189] It should be noted that the method in this embodiment can be executed by a single device, such as a computer or server. The method can also be applied in a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method in this embodiment, and the multiple devices will interact with each other to complete the method described.

[0190] It should be noted that the above description describes some embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0191] Based on the same inventive concept, corresponding to any of the above embodiments, this application also provides a data detection device, which is disposed at the receiving end.

[0192] refer to Figure 3 The device includes: The receiving module 301 is configured to receive a real-time data request and obtain the device data and encrypted data corresponding to the real-time data request. The history retrieval module 302 is configured to retrieve target historical device data and target historical encrypted data corresponding to the real-time data request from the historical database; The device data detection module 303 is configured to detect and compare the device data with the target historical device data to determine the device data detection result; The encrypted data detection module 304 is configured to detect and compare the encrypted data with the target historical encrypted data to determine the encrypted data detection result; The analysis module 305 is configured to combine and analyze the device data detection result and the encrypted data detection result to determine the final detection result, wherein the final detection result is used to indicate whether to respond to the real-time data request.

[0193] In some embodiments, the apparatus further includes a history storage module configured to: Obtain historical data requests and identify historical device data and historical encrypted data within the historical data requests; Determine the historical sender of the historical data request and obtain the historical login data of the historical sender; The historical login data is associated with the corresponding historical device data and historical encrypted data, and stored in the historical database.

[0194] In some embodiments, the historical storage module is specifically configured as follows: Obtain historical data requests, determine the identification information of the historical sender that sent the historical data requests, and use the identification information as the historical device data; The encrypted process data during the transmission authentication process with the historical sender is determined, and the encrypted process data is used as the historical encrypted data.

[0195] In some embodiments, the historical storage module is further configured as follows: Determine the handshake process data for two-way authentication with the historical sender; Extract encryption-related encryption process data from the handshake process data, and use the encryption process data as the historical encryption data.

[0196] In some embodiments, the receiving module 301 is specifically configured as follows: Determine the identification information of the target sender that sent the real-time data request, and use the identification information of the target sender as the device data; The encrypted process data during the transmission authentication process with the target sending end is determined as the encrypted data.

[0197] In some embodiments, the history retrieval module 302 is specifically configured as follows: Determine the target login data of the target sending end that sent the real-time data request, and retrieve the target historical device data and target historical encrypted data corresponding to the target login data from the historical database.

[0198] In some embodiments, the device data detection module 303 is specifically configured as follows: Determine the certificate data based on the device data; Obtain a normal certificate data packet, determine whether the certificate data is in the normal data packet, and obtain the certificate detection result; The device fingerprint is extracted from the device data, and the device fingerprint is detected and compared with the target historical device data to determine the device fingerprint detection result. The certificate detection result and the device fingerprint detection result are used as the device data detection result.

[0199] In some embodiments, the encrypted data detection module 304 is specifically configured as follows: Extract the content of a set field from the encrypted data, and concatenate the extracted content of the set field to obtain the encrypted fingerprint data to be detected; The similarity comparison result is determined by comparing the encrypted fingerprint data to be detected with the target historical encrypted data. Determine the location information corresponding to the encrypted fingerprint data to be detected and the distance between it and the location information corresponding to the target historical encrypted data, determine whether the distance is less than or equal to the distance movement threshold, and obtain the location comparison result; The encrypted fingerprint data to be detected is combined with target historical encrypted data within a predetermined time period to obtain combined data. The number of types of encrypted data in the combined data is determined, and it is determined whether the number of types is greater than the type threshold to obtain the type comparison result. The similarity comparison result, the location comparison result, and the category comparison result are combined to form the encrypted data detection result.

[0200] In some embodiments, the analysis module 305 is specifically configured as follows: The equipment data anomaly index is determined based on the equipment data detection results. The encryption data anomaly index is determined based on the encryption data detection results. The device data anomaly index and the encrypted data anomaly index are summed to obtain the total anomaly index, which is then used as the final detection result.

[0201] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.

[0202] The apparatus of the above embodiments is used to implement the corresponding method in any of the foregoing embodiments and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0203] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides an electronic 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 methods described in any of the above embodiments.

[0204] Figure 4 This embodiment illustrates a more specific hardware structure of an electronic device. The device may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0205] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0206] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0207] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0208] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0209] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0210] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0211] The electronic devices described above are used to implement the corresponding methods in any of the foregoing embodiments and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0212] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a non-transitory computer-readable storage medium that stores computer instructions for causing the computer to perform the methods described in any of the above embodiments.

[0213] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital video disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0214] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to perform the methods described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0215] Based on the same concept, corresponding to any of the above embodiments, this application also provides a computer program product, including computer program instructions, which, when run on a computer, cause the computer to perform the method described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0216] Based on the same inventive concept, this application also provides a vehicle including the device or electronic device described in the above embodiments. The beneficial effects of embodiments having corresponding devices or electronic devices will not be elaborated further here.

[0217] It is understood that before using the technical solutions of the various embodiments in this application, users will be informed of the type, scope of use, and usage scenarios of the personal information involved in an appropriate manner, and user authorization will be obtained.

[0218] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose, based on the prompt message, whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media performing the operations described in this application.

[0219] As an optional but not limited implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0220] It is understood that the above notification and user authorization process is merely illustrative and does not limit the implementation of this application. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this application.

[0221] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application (including the claims) is limited to these examples; within the framework of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in the details for the sake of brevity.

[0222] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0223] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0224] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.< / alpn> < / protocol>

Claims

1. A method for detecting data, characterized in that, include: Receive a real-time data request and obtain the device data and encrypted data corresponding to the real-time data request; Retrieve the target historical device data and target historical encrypted data corresponding to the real-time data request from the historical database; The device data is compared with the target historical device data to determine the device data detection result; The encrypted data is compared with the target historical encrypted data to determine the encrypted data detection result; The device data detection results and the encrypted data detection results are combined and analyzed to determine the final detection result, wherein the final detection result is used to indicate whether to respond to the real-time data request.

2. The method according to claim 1, characterized in that, Before receiving the real-time data request, the following is also included: Obtain historical data requests and identify historical device data and historical encrypted data within the historical data requests; Determine the historical sender of the historical data request and obtain the historical login data of the historical sender; The historical login data is associated with the corresponding historical device data and historical encrypted data, and stored in the historical database.

3. The method according to claim 2, characterized in that, The process of obtaining historical data requests, including determining historical device data and historical encrypted data within the historical data requests, includes: Obtain historical data requests, determine the identification information of the historical sender that sent the historical data requests, and use the identification information as the historical device data; The encrypted process data during the transmission authentication process with the historical sender is determined, and the encrypted process data is used as the historical encrypted data.

4. The method according to claim 3, characterized in that, The step of determining the encrypted process data during the transmission authentication process with the historical sender, and using the encrypted process data as the historical encrypted data, includes: Determine the handshake process data for two-way authentication with the historical sender; Extract encryption-related encryption process data from the handshake process data, and use the encryption process data as the historical encryption data.

5. The method according to claim 1, characterized in that, The process of obtaining the device data and encrypted data corresponding to the real-time data request includes: Determine the identification information of the target sender that sent the real-time data request, and use the identification information of the target sender as the device data; The encrypted process data during the transmission authentication process with the target sending end is determined as the encrypted data.

6. The method according to claim 1, characterized in that, The step of retrieving target historical device data and target historical encrypted data corresponding to the real-time data request from the historical database includes: Determine the target login data of the target sending end that sent the real-time data request, and retrieve the target historical device data and target historical encrypted data corresponding to the target login data from the historical database.

7. The method according to claim 1, characterized in that, The step of comparing the device data with the target historical device data to determine the device data detection result includes: Determine the certificate data based on the device data; Obtain a normal certificate data packet, determine whether the certificate data is in the normal data packet, and obtain the certificate detection result; The device fingerprint is extracted from the device data, and the device fingerprint is detected and compared with the target historical device data to determine the device fingerprint detection result. The certificate detection result and the device fingerprint detection result are used as the device data detection result.

8. The method according to claim 1, characterized in that, The step of comparing the encrypted data with the target historical encrypted data to determine the encrypted data detection result includes: Extract the content of a set field from the encrypted data, and concatenate the extracted content of the set field to obtain the encrypted fingerprint data to be detected; The similarity comparison result is determined by comparing the encrypted fingerprint data to be detected with the target historical encrypted data. Determine the location information corresponding to the encrypted fingerprint data to be detected and the distance between it and the location information corresponding to the target historical encrypted data, determine whether the distance is less than or equal to the distance movement threshold, and obtain the location comparison result; The encrypted fingerprint data to be detected is combined with target historical encrypted data within a predetermined time period to obtain combined data. The number of types of encrypted data in the combined data is determined, and it is determined whether the number of types is greater than the type threshold to obtain the type comparison result. The similarity comparison result, the location comparison result, and the category comparison result are combined to form the encrypted data detection result.

9. The method according to claim 1, characterized in that, The step of combining and analyzing the device data detection results and the encrypted data detection results to determine the final detection result includes: The equipment data anomaly index is determined based on the equipment data detection results. The encryption data anomaly index is determined based on the encryption data detection results. The device data anomaly index and the encrypted data anomaly index are summed to obtain the total anomaly index, which is then used as the final detection result.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 9.

Images