Remote safety isolation method based on digital fingerprint and vehicle behavior anomaly detection

Abstract

This application discloses a remote security isolation method based on digital fingerprinting and vehicle behavior anomaly detection. This method involves periodically generating and uploading "vehicle behavior digital fingerprints" containing features such as acceleration and steering angle at the vehicle end; using a dynamic benchmark model built in the cloud based on real-time learning of a large number of normal vehicle fingerprints, and employing Mahalanobis distance to accurately detect abnormal vehicles; for suspected vehicles, multi-source collaborative verification is initiated, combining surrounding vehicle perception and controller security self-checks to cross-confirm the authenticity of the anomaly; finally, a graded remote isolation strategy is executed according to the anomaly level. This application transforms passive response into active defense, achieving high-precision characterization of driving behavior through "digital fingerprinting," solving the problem of high false alarm rates with fixed thresholds using a "dynamic benchmark model," ensuring the reliability of anomaly judgment through "multi-source collaborative verification," and achieving progressive security intervention through "graded isolation," significantly improving the active safety protection capabilities of intelligent connected vehicles.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicle security technology, and more specifically, to a remote security isolation method based on digital fingerprint and abnormal vehicle behavior detection. Background Technology

[0002] Remote monitoring and control systems for intelligent connected vehicles are now widespread. Cloud platforms can receive real-time vehicle status data (such as speed, location, and battery level) and provide remote services in certain situations, such as remote unlocking, flashing lights, and honking the horn. Furthermore, in the event of a collision or serious malfunction, the onboard system automatically triggers an emergency call service, sending a distress signal to the cloud.

[0003] Currently, the closest existing technology is an alarm system based on rule thresholds. For example: 1) When the cloud detects a vehicle's airbag deployment signal, it automatically triggers human customer service intervention; 2) When the vehicle's battery temperature exceeds a certain fixed threshold, it sends an overheating alarm to the owner and service center; 3) When onboard sensors (such as gyroscopes) detect a rollover or severe collision, it automatically sends an emergency call.

[0004] However, these existing technologies have the following drawbacks:

[0005] 1) Passivity and lag: Most existing systems rely on serious events that have already occurred (such as collisions or fault codes) to trigger a response, lacking the ability to identify and intervene during dangerous behavior.

[0006] 2) Rigid rules: Rules based on fixed thresholds cannot effectively identify complex and atypical abnormal behavior patterns. For example, a vehicle that continues to accelerate without being collided may not trigger any existing rule alerts.

[0007] 3) Lack of verification and isolation capabilities: Even if an abnormal signal is received, the cloud struggles to quickly verify whether it is a genuine vehicle malfunction or attack, or a data mistransmission. More importantly, the existing system lacks the ability to quickly and effectively remotely "soft isolate" confirmed abnormal vehicles, thus failing to limit their potential harm.

[0008] Therefore, how to detect individual vehicles that have lost control due to software malfunctions or malicious attacks from a massive number of vehicles in real time and accurately, and to quickly verify and remotely isolate them to prevent the accident from escalating and to buy time for subsequent rescue, is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0009] This application aims to address the problems existing in the prior art by providing a remote security isolation method and system based on digital fingerprint and vehicle behavior anomaly detection. To achieve the above objective, this application adopts the following technical solution.

[0010] In a first aspect, embodiments of this application provide a remote security isolation method based on digital fingerprints and vehicle behavior anomaly detection, including:

[0011] Receive vehicle behavior digital fingerprint uploaded by the vehicle terminal; the vehicle behavior digital fingerprint is a feature vector that is periodically generated by the vehicle terminal based on real-time vehicle operation data and is used to characterize the short-term driving behavior pattern of the vehicle.

[0012] Based on a pre-established dynamic benchmark model, anomaly detection is performed on the received vehicle behavior digital fingerprint. If the detection result meets the preset suspected anomaly conditions, the vehicle is marked as a suspected abnormal vehicle. The dynamic benchmark model is constructed based on real-time learning of the vehicle behavior digital fingerprints of multiple normal vehicles.

[0013] In response to the marking of the suspected abnormal vehicle, a multi-source collaborative verification process is initiated to obtain multi-party verification information regarding the authenticity of the suspected abnormal vehicle's status;

[0014] Based on the multi-party verification information, after confirming that the vehicle has a real anomaly, according to the preset anomaly level and / or vehicle status, the corresponding graded remote safety isolation strategy is selected and triggered, and a remote control command is sent to the vehicle to restrict its dangerous behavior.

[0015] Furthermore, the vehicle behavior digital fingerprint includes at least one or more of the following feature dimensions:

[0016] The system includes acceleration statistics reflecting the vehicle's longitudinal control behavior, steering angle variation reflecting the vehicle's lateral control behavior, pedal operation coordination reflecting the driver's operational coordination, trajectory deviation reflecting the vehicle's path-keeping ability, and software integrity and operational status reflecting the health status of the vehicle's core controller.

[0017] Furthermore, the dynamic benchmark model uses an unsupervised learning algorithm to cluster the digital fingerprints of normal vehicle behavior, generating one or more normal behavior clusters representing different typical driving modes, and updates the statistical features of the clusters in real time.

[0018] The anomaly detection steps include: calculating the Mahalanobis distance between the vehicle behavior digital fingerprint of the vehicle under test and the normal behavior cluster, and determining whether it is abnormal based on whether the Mahalanobis distance exceeds a preset dynamic threshold.

[0019] Furthermore, the multi-source collaborative verification process includes:

[0020] Send a collaborative perception request to at least one other vehicle in the vicinity of the suspected abnormal vehicle;

[0021] Receive verification information from other vehicles after they perceive the operating status of the suspected abnormal vehicle based on their own sensors;

[0022] A safety challenge command is sent to the suspected abnormal vehicle, requesting its designated controller to perform a safety self-test and return the self-test results.

[0023] Furthermore, the security challenge instruction is randomly generated and different each time, requiring the designated controller to perform a signature operation on the security challenge instruction based on its internal private key within a preset very short time, and return the signature result as a self-test result; the correctness of the signature result is verified using the corresponding pre-stored public key.

[0024] Furthermore, the tiered remote security isolation strategy includes one or more progressively higher levels of intervention:

[0025] Level 1: Guide the vehicle to a minimum risk state by limiting some of its power and activating hazard warnings;

[0026] The second level activates the vehicle's security domain isolation mechanism to block network communication between abnormal functional domains and other domains.

[0027] The third level involves dynamically setting and enforcing electronic fences for vehicles to restrict their driving area.

[0028] Level 4 triggers a group warning, broadcasting the abnormal vehicle's abnormal status information and real-time location to other traffic participants around the abnormal vehicle, so as to coordinate and achieve proactive avoidance of surrounding traffic flow.

[0029] Furthermore, the step of guiding the vehicle into a minimum risk state includes:

[0030] Based on the vehicle's current geographical location, traffic flow, and / or road conditions, a safe and feasible guidance route and parking point are calculated, and instructions containing the guidance route and parking point are sent to the vehicle for execution by the vehicle's advanced driver assistance system or autonomous driving system.

[0031] Secondly, embodiments of this application provide a remote security isolation system capable of implementing any of the aforementioned remote security isolation methods, comprising:

[0032] The vehicle fingerprint generation module is installed on the target vehicle and is used to periodically generate vehicle behavior digital fingerprints that characterize the vehicle's short-term driving behavior patterns based on the vehicle's real-time operating data, and report them to the cloud.

[0033] The cloud-based anomaly detection engine receives the vehicle's digital fingerprint and performs anomaly detection based on a dynamically updated normal behavior benchmark model, marking vehicles that meet the suspected anomaly conditions as suspected abnormal vehicles.

[0034] The cloud-based verification and coordination module is used to respond to the marking of the suspected abnormal vehicle, initiate a multi-source collaborative verification process, obtain multi-party verification information on the authenticity of the suspected abnormal vehicle's status, and confirm whether the vehicle is truly abnormal based on the multi-party verification information.

[0035] The remote isolation command issuing module is used to select and trigger the corresponding hierarchical remote security isolation strategy according to the preset abnormality level and / or vehicle status after confirming that there is a real abnormality in the vehicle, and generate and send the corresponding remote control command to the vehicle.

[0036] Thirdly, embodiments of this application provide an electronic device, including: one or more processors;

[0037] A memory for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors are able to implement the steps in the remote security isolation method described in any of the preceding claims.

[0038] Fourthly, embodiments of this application provide a computer-readable medium storing a computer program, which, when executed by a processor, can implement the steps of the remote security isolation method described in any of the preceding claims.

[0039] This application discloses a remote security isolation method based on digital fingerprinting and vehicle behavior anomaly detection. This method involves periodically generating and uploading "vehicle behavior digital fingerprints" containing features such as acceleration and steering angle at the vehicle end; using a dynamic benchmark model built in the cloud based on real-time learning of a large number of normal vehicle fingerprints, and employing Mahalanobis distance to accurately detect abnormal vehicles; for suspected vehicles, multi-source collaborative verification is initiated, combining surrounding vehicle perception and controller security self-checks to cross-confirm the authenticity of the anomaly; finally, a graded remote isolation strategy is executed according to the anomaly level. This application transforms passive response into active defense, achieving high-precision characterization of driving behavior through "digital fingerprinting," solving the problem of high false alarm rates with fixed thresholds using a "dynamic benchmark model," ensuring the reliability of anomaly judgment through "multi-source collaborative verification," and achieving progressive security intervention through "graded isolation," significantly improving the active safety protection capabilities of intelligent connected vehicles. Attached Figure Description

[0040] Figure 1 The core flowchart of a remote security isolation method based on digital fingerprint and vehicle behavior anomaly detection provided in this application embodiment;

[0041] Figure 2 A flowchart illustrating a remote security isolation method based on digital fingerprint and vehicle behavior anomaly detection provided in this application embodiment;

[0042] Figure 3 A schematic diagram of the module structure of a remote security isolation system based on digital fingerprint and vehicle behavior anomaly detection provided in an embodiment of this application;

[0043] Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0044] To enable those skilled in the art to better understand the technical solutions of this application, exemplary embodiments of this application are described below with reference to the accompanying drawings, including various details of the embodiments of this application to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description. Unless otherwise specified, the various embodiments of this application and the features within those embodiments can be combined with each other.

[0045] As used herein, the term "and / or" includes any and all combinations of one or more of the associated enumerated entries. The terminology used herein is for describing particular embodiments only and is not intended to limit the application. As used herein, the singular forms "a" and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that when the terms "comprising" and / or "made of" are used herein, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as "connected" or "linked" are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0046] Unless otherwise specified, all terms used in this application (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It should also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this application, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined in this application.

[0047] The core concept of this application lies in: achieving real-time cloud-based perception of vehicle driving behavior through a lightweight "behavioral digital fingerprint" generated on the vehicle side; accurately identifying individuals with abnormal behavior from a massive number of vehicles using a cloud-based dynamic benchmark model and machine learning algorithms; cross-verifying the authenticity of anomalies through a multi-source collaborative verification mechanism to avoid false alarms; and finally, implementing a graded and progressive remote safety isolation strategy based on the confirmed anomaly level to minimize the risk of out-of-control vehicles. The technical solution of this application will be described in detail below with reference to a complete embodiment.

[0048] refer to Figure 1 and Figure 2 One embodiment of this application provides a remote security isolation method based on digital fingerprint and vehicle behavior anomaly detection, which may specifically include the following steps.

[0049] Step 1: The vehicle generates a digital fingerprint of vehicle behavior, and the cloud receives the digital fingerprint of vehicle behavior uploaded by the vehicle. The digital fingerprint of vehicle behavior is a feature vector that is periodically generated by the vehicle terminal based on real-time vehicle operation data and is used to characterize the short-term driving behavior pattern of the vehicle.

[0050] The vehicle periodically (e.g., every 5 seconds) uploads a lightweight digital fingerprint data packet of vehicle behavior to the cloud. This fingerprint is not raw sensor data, but a locally computed feature vector that highly summarizes short-term driving behavior.

[0051] The fingerprint feature vector V can contain the following dimensions:

[0052] V1: Average acceleration and standard deviation (past 30 seconds), which is the acceleration statistical characteristic reflecting the longitudinal control behavior of the vehicle.

[0053] V2: Steering angle change frequency and amplitude, which is the steering angle change characteristic that reflects the vehicle's lateral control behavior.

[0054] V3: Coordination of brake / accelerator pedal opening (whether there is an abnormality of pressing deeply at the same time), which is the pedal operation coordination characteristic that reflects the driver's operation coordination.

[0055] V4: The deviation between the vehicle trajectory and the predicted trajectory of the lane line, which is the trajectory deviation feature that reflects the vehicle's ability to maintain its path.

[0056] V5: Checksum and / or heartbeat signal of key controllers (such as ESP, EPS), which is the software integrity and operational status characteristics that reflect the health status of the vehicle's core controller.

[0057] Example of calculation formula: Deviation V4 = Σ(|actual lateral position - predicted lane center position|) / number of sampling points.

[0058] Taking a smart traffic management cloud platform as an example, the on-board terminal (T-Box) of a smart connected vehicle A traveling on the road periodically calculates a feature vector V called "behavioral fingerprint" based on CAN bus data and sensor data (such as vehicle speed, acceleration, steering angle, and GPS trajectory). The dimensions of V can be designed as V=[v1,v2,v3,v4], where v1 is the average acceleration and standard deviation over the past 30 seconds, v2 is the rate of change of steering angle, v3 is the coordination index of the brake and accelerator pedals, and v4 is the average deviation of the vehicle's actual trajectory from the lane centerline. This fingerprint data packet is lightweight encrypted and uploaded to the cloud.

[0059] To more precisely characterize vehicle behavior, this embodiment proposes that, for an electric truck traveling on mountainous roads, its onboard fingerprint generation module collects richer data. The generated fingerprint vector V' not only contains basic elements but also specifically emphasizes considerations of load and gradient.

[0060] (1) Acceleration statistics: It includes not only the average acceleration and standard deviation of the past 30 seconds, but also the distribution probability of positive acceleration (throttle) and negative acceleration (brake) to identify whether there is excessive reliance on braking on long downhill sections.

[0061] (2) Steering angle change characteristics: It not only includes the frequency and amplitude of steering angle change, but also introduces the concept of steering wheel angle entropy, which is used to measure the smoothness of driver operation. A sudden increase in entropy value may mean that the driver loses control or the system malfunctions.

[0062] (3) Pedal operation coordination characteristics: Calculate the percentage of time when the accelerator and brake pedals are pressed at the same time. If this value increases sharply in a short period of time, it is highly suspected that the driver misoperation or pedal sensor failure is the cause.

[0063] (4) Trajectory Deviation Feature: Combining high-precision map data, the root mean square error (RMSE) of the lateral deviation between the vehicle's actual driving trajectory and the center line of the lane recommended by the map is calculated. This indicator can effectively reflect whether the vehicle deviates from the normal driving route, such as gradually deviating from the lane due to steering system failure. After receiving V', the cloud will assign different weights to the features of different dimensions to perform a comprehensive anomaly score. For example, for trucks, the weight of trajectory deviation will be set higher.

[0064] Step 2: Real-time anomaly detection in the cloud. This involves detecting anomalies in the received vehicle behavior digital fingerprints based on a pre-established dynamic benchmark model. If the detection result meets preset suspected anomaly conditions, the vehicle is marked as a suspected abnormal vehicle. The dynamic benchmark model is constructed by real-time learning of the vehicle behavior digital fingerprints of multiple normal vehicles.

[0065] A dynamic benchmark model is established in the cloud. This model uses machine learning (such as clustering algorithms) to learn in real time the digital fingerprints of vehicle behavior of normal vehicles in the same area and on the same type of road (such as urban highways), forming a "normal behavior cluster".

[0066] For each vehicle that uploads its fingerprint, the cloud calculates the Mahalanobis distance or cosine similarity between its fingerprint feature vector and the center of the current "normal behavior cluster".

[0067] Mahalanobis distance formula: Where x is the fingerprint vector of the vehicle under test, μ is the mean vector of the normal behavior cluster, and Σ is the covariance matrix. The larger the value, the more abnormal the behavior.

[0068] When a certain vehicle If a vehicle consistently exceeds a dynamic threshold (e.g., falls outside the 99% confidence interval), it will be marked as a "suspected abnormal vehicle".

[0069] In this embodiment, the cloud-deployed anomaly detection engine maintains a dynamically updated "normal behavior cluster" based on a Gaussian Mixture Model (GMM). This model continuously learns the behavioral fingerprints of tens of thousands of normally driving vehicles within the same time period and geographical area (e.g., Beijing's Third Ring Road during weekday evening rush hour), forming multiple clusters representing different driving modes (e.g., smooth driving, congested following, normal lane changing). When the engine receives the fingerprint V of vehicle A, it calculates the Mahalanobis distance between V and the centers of all normal behavior clusters. If V is far from all cluster centers, and its distance value exceeds a dynamically adjusted threshold three times consecutively (e.g., the upper limit of the 99.9% confidence interval based on historical data statistics), the engine marks vehicle A as a "suspected abnormal vehicle." This threshold is dynamic; for example, in rainy or snowy weather, the system automatically relaxes the threshold to tolerate more common phenomena such as tire slippage.

[0070] To achieve a more accurate dynamic baseline model, this application employs an online clustering algorithm. On a smart transportation cloud platform in a certain city, the system uses the online clustering algorithm BIRCH (Balanced Iterative Reducing and Clustering using Hierarchies) to process massive, high-speed data streams.

[0071] (1) Cluster generation: The platform distributes vehicle fingerprint data according to time (morning peak, midday off-peak, evening peak) and region (commercial area, residential area, highway section). For example, for vehicles around the Central Business District (CBD) at 9 am on weekdays, the BIRCH algorithm automatically clusters the massive amount of fingerprints received into three main clusters: cluster C1 (congestion following mode, characterized by low speed, frequent starts and stops, and small-angle turns), cluster C2 (normal driving mode, characterized by medium and low speed, smooth acceleration and deceleration), and cluster C3 (parking lot entry and exit mode, characterized by extremely low speed and large-angle turns). Each cluster stores its core statistical information: mean vector μ and covariance matrix Σ.

[0072] (2) Dynamic Updates: The model is not static. When new normal vehicle fingerprint data flows in, the BIRCH algorithm updates the μ and Σ of the nearest cluster in real time. For example, if the overall traffic flow slows down due to a large event nearby, the mean vector μ of cluster C2 will slowly drift towards the lower speed direction, and its covariance matrix Σ will also change accordingly. This means that the definition of "normal" is adaptive to the environment.

[0073] (3) Anomaly detection: When the fingerprint V of vehicle A is transmitted, the engine calculates the Mahalanobis distance between V and all clusters (C1, C2, C3) and takes the minimum value D. M_min (V). Assuming V is closest to C2, D is calculated. M_min (V)=15. The current dynamic threshold T of the C2 cluster... C2 It is dynamically calculated based on the 99th percentile of its historical data distribution, for example, T. C2 =8. Since 15 > 8, V is determined to be significantly deviating from any normal pattern, and vehicle A is therefore marked as potentially abnormal. This dynamic threshold T C2 It will change in real time according to the compactness of the cluster to ensure that the sensitivity of the detection is always at the optimal level.

[0074] Step 3: Multi-source collaborative verification mechanism. In response to the flagging of the suspected abnormal vehicle, a multi-source collaborative verification process is initiated to obtain multi-party verification information regarding the authenticity of the suspected abnormal vehicle's status.

[0075] To avoid false alarms, the cloud does not take immediate intervention measures, but instead initiates a rapid verification process:

[0076] Collaborative perception verification: The cloud sends instructions to other connected vehicles within a certain range of the target vehicle, requesting them to report perception data of the target vehicle (such as determining whether its driving status is abnormal through V2X or visual algorithms). This utilizes the concept of "crowdsourcing" for cross-validation.

[0077] Vehicle Self-Check Challenge: The cloud sends a "safety challenge" command to the target vehicle, requiring one of its controllers (such as the brake controller) to perform a simple, non-safety-affecting self-check procedure (such as calculating the hash value of a piece of core code) and respond within a very short time. If the response times out, contains an error, or does not conform to the standard value, it indicates that the controller may have been tampered with or malfunctioned.

[0078] In some embodiments, after the cloud marks vehicle M as potentially abnormal, the verification process then begins, specifically including two parallel verification paths:

[0079] Path 1: Vehicle-Cloud-Vehicle Collaborative Perception

[0080] Based on the last known location of vehicle M, the cloud uses geofencing technology to filter out other connected vehicles (N1, N2, N3...) within a 300-meter radius of vehicle M. The cloud then sends a "cooperative perception request" message to these vehicles, containing vehicle M's ID, location, and appearance characteristics (such as color and model). The request information is anonymized to protect privacy.

[0081] Upon receiving a request, vehicle N2's perception system (such as a forward-facing camera and millimeter-wave radar) initiates a target tracking task. N2's multi-sensor fusion algorithm matches information provided by the cloud with its perceived target, locking onto vehicle M. N2 then continuously observes M for several seconds, analyzing its motion. For example, N2's onboard computing unit detects that M is traveling at approximately 80 km / h, but its heading angle fluctuates drastically by more than 15 degrees within 2 seconds, and its turn signals are not activated. Based on this, N2 generates a "perception verification report": "Target vehicle's trajectory is abnormal, suspected of being out of control," and sends this report along with its own confidence level (e.g., 95%) back to the cloud. Simultaneously, vehicles N1, N3, and others may also report their respective perception results.

[0082] Path Two: Security Challenges - Response

[0083] Almost simultaneously, the cloud sends an encrypted security challenge command to the intelligent gateway of vehicle M. This command instructs M's steering controller (EPS) to execute a pre-defined, lightweight self-test procedure that does not affect driving safety. For example, the procedure requires the EPS controller to read and calculate the hash value (e.g., SHA-256) of a critical security code within its protected storage area and respond within 20 ms via a secure and trusted channel. This calculation process does not interfere with the normal power assist function of the EPS.

[0084] If the firmware of M's EPS controller has been tampered with, the hash value it calculates will inevitably differ from the golden mirror hash value stored in the cloud; if M's computing power has been occupied by an attack, it may time out and become unresponsive. After receiving the result, the cloud compares it with the expected value.

[0085] Ultimately, the cloud-based integrated collaborative perception results (N2 reported an abnormal trajectory with high confidence) and the security challenge results (hash value error) confirmed with extremely high confidence that the EPS controller of vehicle M had been tampered with, causing its abnormal behavior.

[0086] To further enhance the security of the "security challenge-response" mechanism and prevent replay attacks and man-in-the-middle attacks, this application adopts a combination of challenge-response based two-way authentication and integrity verification:

[0087] The cloud-based verification module generates a 256-bit random number as the challenge value (Nonce). The cloud sends a safety challenge command to the vehicle A's ESP (Electronic Stability Program) controller, with the format: {Command ID, Controller ID requesting self-test, Nonce, Timestamp}. The entire data packet is protected using a transport layer secure channel (such as TLS) between the cloud and the vehicle.

[0088] Vehicle A's ESP controller has a pre-installed Hardware Security Module (HSM) that stores its unique, non-exportable private key K. priv After receiving the instruction, the ESP's HSM performs the following operations:

[0089] (1) Code integrity measurement: HSM first performs hash calculation on a critical security code region (such as anti-lock braking control logic) in its own FLASH to obtain the measurement value H. code .

[0090] (2) Signature generation: HSM uses private key K priv For the spliced ​​data (Nonce||H) code The signature operation is performed to generate a signature value S. Here, || represents concatenation. Since the nonce is different for each challenge, the generated signature S is also completely different each time.

[0091] (3) Return result: ESP encapsulates the signature value S in the response message and returns it to the cloud through a secure channel.

[0092] After receiving the response, the cloud retrieves the pre-stored public key K of the ESP controller from the vehicle information database. pub Using K in the cloud pub Decrypting the signature value S yields (Nonce'||H) code Then, the comparison is performed in the cloud:

[0093] Is Nonce the same as the previously generated random number Nonce?

[0094] H code Is it consistent with the gold hash value of this version of ESP firmware maintained in the cloud database?

[0095] Only when both match will the cloud determine that the controller has passed the security challenge and that its software is intact and untampered.

[0096] Step 4: Implement tiered remote security isolation. Based on the multi-party verification information, after confirming a genuine anomaly in the vehicle, and according to the preset anomaly level and / or vehicle status, select and trigger the corresponding tiered remote security isolation strategy, and send remote control commands to the vehicle to restrict its dangerous behavior.

[0097] Once a genuine anomaly is verified, the cloud will select and trigger one or more of the following security isolation strategies in sequence, based on the anomaly level and vehicle status:

[0098] (1) Guiding to the minimum risk state: The cloud sends instructions to the vehicle through a secure channel to trigger its built-in minimum risk strategy. For example, limiting power output, slowing down gradually, automatically turning on hazard lights, and automatically pulling over to the side of the road when conditions permit.

[0099] (2) Activate security domain isolation: If the vehicle supports a domain controller architecture, the cloud can instruct the vehicle gateway to isolate the communication between the abnormal functional domain (such as the power domain) and other domains, retaining only the most basic driving capabilities to prevent the spread of faults.

[0100] (3) Dynamic electronic fence: Define a virtual "safe zone" for abnormal vehicles and restrict them from leaving the zone (e.g., avoid entering the congested city center).

[0101] (4) Group warning: Broadcast the abnormal status and location of the vehicle to surrounding vehicles and traffic management system to achieve coordinated avoidance.

[0102] In some embodiments, after integrating information from various sources (most surrounding vehicles reporting abnormalities + failed self-check challenge), the cloud determines that vehicle A's behavior is out of control due to malicious tampering with its controller, classifying it as a high-risk vehicle. Subsequently, the cloud-based isolation strategy engine triggers a "tiered remote security isolation strategy": First, it sends a command to vehicle A through a secure channel, activating its built-in "minimum risk state," ordering it to limit power output to a maximum of 20 km / h and automatically activate its hazard lights; second, the cloud sends a warning to the roadside units (RSUs) and traffic management center in the area, dynamically defining a 500-meter radius circular electronic fence around vehicle A, prohibiting it from entering the city's core area. Once it approaches the boundary, the system will provide a voice prompt to the driver and further restrict power. Ultimately, the harm caused by the out-of-control vehicle is successfully minimized.

[0103] To implement tiered isolation more precisely, this application provides a three-tiered, progressive remote safety isolation strategy. After confirming that vehicle B's abnormal behavior is due to a malfunction in its high-level autonomous driving system, the cloud-based system activates the following strategy based on the severity of the malfunction, current speed, location (e.g., urban expressway), and surrounding traffic density:

[0104] Level 1: Minimum Risk State

[0105] Execution: The cloud immediately sends a "Enter Minimum Risk State" command to the Automated Driving Domain Controller (ADCU) of Vehicle B. Vehicle B then executes a preset program: smoothly limiting the maximum speed to 30 km / h (from 80 km / h), with extremely smooth power response; automatically activating the hazard warning lights; and simultaneously, displaying a prominent text and voice prompt on the central control screen: "Vehicle malfunction has occurred, a safe stopping procedure is being performed, please take over the steering wheel." The goal at this stage is to immediately reduce the potential hazards of the vehicle.

[0106] Level 2: Security Domain Isolation

[0107] Triggering conditions: Cloud monitoring detects that after Level 1 intervention, vehicle B's abnormal behavior (such as S-shaped driving) has not improved, indicating that the driver may not have effectively taken over or the malfunction has spread. Simultaneously, collaborative perception information from surrounding vehicles indicates that vehicle B remains in a dangerous state.

[0108] Execution: The cloud sends an "Activate Domain Isolation" command to the central gateway of vehicle B. The central gateway then dynamically adds rules to its internal firewall according to preset policies, blocking all unnecessary communication between the "Autonomous Driving Domain" and the "Powertrain Domain" and "Chassis Domain." However, the channel for the "Autonomous Driving Domain" to receive cloud commands and report status is preserved. In this way, even if the faulty domain continues to generate erroneous commands, they cannot be transmitted to the actuators (such as the engine and brakes), while basic power output and braking functions are directly controlled by the driver or taken over by a lower-level safety controller, preventing the spread of faults and the execution of malicious commands.

[0109] Level 3: Dynamic electronic fence

[0110] Triggering condition: Vehicle B continued to drive towards the city center after being quarantined. Cloud-based assessment indicated an extremely high risk of it entering a densely populated area.

[0111] Execution: The cloud-based traffic signal control system and high-precision map service of the traffic management center work together to dynamically define a non-enterable "hard electronic fence" area for vehicle B (e.g., a prime commercial area 500 meters ahead). Once vehicle B's GPS trajectory predicts it will reach the fence boundary, the cloud will not only issue a strong warning and stricter deceleration instructions to vehicle B again, but also notify the roadside unit (RSU) to prepare to trigger physical intervention measures on the roadside, such as variable message signs to warn surrounding vehicles to give way. This strategy aims to confine at-risk vehicles to a relatively safe area until they come to a complete stop or are taken over.

[0112] Furthermore, when guiding the vehicle to a minimum risk state, this application does not simply instruct it to slow down and stop on the spot, but rather provides an intelligent guidance solution. When it is confirmed that vehicle C has lost control due to a sudden illness of the driver, the cloud immediately initiates minimum risk state guidance:

[0113] (1) Environmental Perception and Path Planning: The cloud first obtains the precise location (e.g., at K35+200 on G4 Expressway), heading, and speed of vehicle C. Simultaneously, it retrieves high-precision maps of the road segment, real-time traffic flow data, and roadside camera footage. After comprehensively analyzing this information, the cloud-based safe path planning engine discovers an emergency parking bay 300 meters ahead, with less traffic behind the bay, a straight road, and good visibility. Therefore, the engine plans a smooth path from the current lane to the rightmost lane, ultimately sliding into the emergency parking bay. Simultaneously, the engine calculates the target speed and steering angle required for each stage of lane changing and deceleration, forming a series of trajectory points, and verifies the safety of the path (e.g., dynamic distance to surrounding vehicles).

[0114] (2) Command Issuance and Execution: The cloud sends the "guided path" command, containing precise trajectory points and speed curves, to the autonomous driving domain controller of vehicle C through a secure channel. After receiving the command, the trajectory tracking controller of vehicle C takes over vehicle control, smoothly controlling steering, throttle, and braking, and strictly following the planned path. During lane changing, vehicle C communicates with surrounding vehicles via V2X to inform them of its intentions. Finally, vehicle C safely and smoothly stops in the emergency parking bay, automatically turns on its hazard lights, and unlocks the central locking system for subsequent rescue.

[0115] This application also provides a remote security isolation system based on digital fingerprint and vehicle behavior anomaly detection to implement the aforementioned remote security isolation method. For example... Figure 3 As shown, the remote security isolation system includes:

[0116] (1) Vehicle fingerprint generation module, which is installed on the target vehicle, is used to periodically generate vehicle behavior digital fingerprints based on the vehicle's real-time operation data to characterize the vehicle's short-term driving behavior patterns and report them to the cloud.

[0117] (2) Cloud-based anomaly detection engine, used to receive the vehicle behavior digital fingerprint and perform anomaly detection on it based on a dynamically updated normal behavior benchmark model, and mark vehicles that meet the suspected anomaly conditions as suspected abnormal vehicles.

[0118] (3) Cloud verification coordination module, used to respond to the mark of the suspected abnormal vehicle, start the multi-source collaborative verification process, obtain multi-party verification information on the authenticity of the suspected abnormal vehicle status, and confirm whether the vehicle is truly abnormal based on the multi-party verification information.

[0119] (4) Remote isolation command issuing module, which is used to select and trigger the corresponding hierarchical remote security isolation strategy according to the preset abnormality level and / or vehicle status after confirming that there is a real abnormality in the vehicle, and generate and send the corresponding remote control command to the target vehicle.

[0120] In some embodiments, a complete "Tian Shu" intelligent connected vehicle safety control system is constructed, which is the system-level implementation of this application.

[0121] (1) Vehicle-side fingerprint generation module: Integrated into Dongfeng Motor's new-generation central computing platform (CCU), it runs as a background service. This module continuously monitors data from CAN FD and in-vehicle Ethernet, extracts key signals (vehicle speed, wheel speed, yaw rate, steering wheel angle, accelerator pedal position, GPS, etc.), calculates various statistical features through sliding time windows (such as 3 seconds, 10 seconds, 30 seconds), and compresses them into a 128-byte data packet "behavioral fingerprint". The fingerprint data is reported to the cloud via the 5G network with extremely high priority and encryption.

[0122] (2) Cloud-based anomaly detection engine: Deployed in a microservice cluster on Dongfeng Motor's private cloud, it is implemented based on the Flink stream processing framework. This engine subscribes to the behavioral fingerprint data streams of all online vehicles and maintains dozens of real-time updated normal behavior cluster models based on different spatiotemporal dimensions (time period, city, road type). For each fingerprint of each vehicle, the engine performs millisecond-level Mahalanobis distance calculation and outputs an "anomaly score". When the score exceeds a dynamic threshold, the vehicle and its related information (including fingerprint data, location, and timestamp) are encapsulated into an "anomaly event" and published to a Kafka message queue.

[0123] (3) Cloud Verification Coordination Module: As another microservice, it subscribes to "abnormal events" in Kafka. Once an event is received, this module initiates a stateful verification workflow. It first calls the geographic information service to query the list of vehicles around the target vehicle. Then, it sends a collaborative perception request to these vehicles through the V2X cloud control platform. At the same time, it sends a hardware security challenge instruction based on PUF (Physically Unclonable Function) to the designated controller of the target vehicle through the dedicated interface of the Secure Remote Over-The-Air (SOTA) platform. This module is responsible for aggregating and parsing all feedback information, and finally arriving at the conclusion of "abnormal confirmation" or "false alarm exclusion" based on the preset confidence fusion algorithm.

[0124] (4) Remote Isolation Command Issuance Module: This module is triggered after the verification and coordination module confirms the anomaly. It first queries a policy database and retrieves the matching "tiered safety isolation policy" (e.g., executing the minimum risk state policy - level 2 domain isolation) based on the anomaly type (e.g., "brake system tampering") and the vehicle's current status (e.g., "vehicle speed 80 km / h, on an urban expressway") contained in the "anomaly confirmation" report. Then, it sends specific, formatted control commands (e.g., {target: central gateway, command: ACTIVATE_DOMAIN_ISOLATION, parameter: isolated power domain}) to the vehicle through an independent, highly reliable remote command issuance channel (isolated from the ordinary TSP service), and tracks the execution results of the commands until the vehicle status is effectively controlled.

[0125] Overall, the advantages of this application compared to the prior art include:

[0126] (1) Improved detection accuracy: from fixed rules to dynamic behavioral fingerprint model

[0127] Existing technologies generally employ rule-based alarm systems with fixed thresholds, such as triggering an emergency call when an airbag deploys or sending an alarm when the battery temperature exceeds the limit. The limitation of this approach lies in the rigidity of the rules, making it unable to identify complex and atypical abnormal behavior patterns. For example, situations such as a vehicle continuously accelerating without being collided, or driving in an S-shape due to a software malfunction, may not trigger any existing rule alarms. This application proposes a detection mechanism combining "vehicle behavior digital fingerprints" and a "cloud-based dynamic benchmark model." The vehicle periodically uploads not raw sensor data, but locally computed feature vectors that highly summarize short-term driving behavior (such as acceleration statistics, steering angle changes, and trajectory deviation). The cloud uses unsupervised learning algorithms to learn the fingerprints of normal vehicles in the same area and on similar roads in real time, forming a dynamically updated "normal behavior cluster." Mahalanobis distance is then used to calculate the deviation of the fingerprint of the vehicle under test from the center of the normal cluster. The advantage of this method is that the definition of "normal" is adaptive to the environment—the threshold is automatically relaxed in rainy or snowy weather, and the model is automatically adjusted when there is traffic congestion, thus achieving high-precision and low-false-alarm identification of hidden and progressive abnormal behaviors in complex and ever-changing real traffic environments.

[0128] (2) Enhanced reliability of verification: from single data source to multi-source collaborative verification

[0129] In existing technologies, it is difficult for the cloud to quickly verify the authenticity of abnormal signals received—is it a genuine vehicle malfunction / attack, a sensor false alarm, or a data link error? The limitations of a single data source make the cloud hesitant to intervene, often missing the best opportunity for response. This application introduces a "multi-source collaborative verification mechanism." After a vehicle is marked as potentially abnormal, the cloud does not intervene immediately but initiates a rapid verification process, which includes two parallel verification paths: one is "vehicle-cloud-vehicle collaborative perception," which sends instructions to other connected vehicles around the target vehicle, requesting them to conduct "crowdsourced" observations of the target vehicle through their own V2X or visual perception systems and report the results; the other is "security challenge-response," which sends instructions to the target vehicle itself, requiring its designated controller (such as a brake controller) to execute a lightweight self-check procedure that does not affect safety (such as calculating the hash value of critical code) and respond within a very short time. By cross-verifying "external group observation" and "internal self-inspection evidence," the cloud can confirm the authenticity of anomalies with extremely high confidence, effectively resisting external deception of vehicle sensors and internal tampering of controllers, and providing a solid basis for subsequent intervention.

[0130] (3) Optimization of intervention safety: from abrupt braking to graded soft isolation

[0131] In existing technologies, once a vehicle malfunction is confirmed, the available remote intervention methods are extremely limited, often resorting to the crude method of remotely shutting off the engine. However, in high-speed driving scenarios, suddenly cutting off power can lead to serious secondary accidents such as loss of vehicle control, loss of power steering, and rear-end collisions. This application proposes a "tiered remote safety isolation strategy," which executes a series of progressive, non-intrusive intervention measures based on the level of malfunction and vehicle status: Level 1, "Minimum Risk State," restricts power output, automatically activates hazard lights, and guides the vehicle to a smooth pullover when conditions permit; Level 2, "Safety Domain Isolation," isolates communication between the malfunctioning functional domain (such as the power domain) and other domains through a vehicle gateway, cutting off the fault propagation path at the architectural level while preserving basic driving capabilities; Level 3, "Dynamic Electronic Fence," defines a virtual safety zone for the malfunctioning vehicle, restricting its entry into densely populated areas, and coordinates with roadside units to achieve area control. This progressive intervention strategy avoids the secondary risks caused by excessive intervention while enabling decisive and stronger measures to be taken as risks escalate, achieving the best balance between safety and user experience.

[0132] (4) System architecture innovation: from passive response to active defense closed loop

[0133] From a system architecture perspective, existing technologies are typical "passive response" architectures—relying on events that have already occurred (collisions, fault codes) to trigger alarms, lacking the ability to perceive and intervene in ongoing dangerous behaviors. This application constructs a complete "perception-detection-verification-intervention" proactive defense closed loop: the vehicle continuously perceives and generates lightweight behavioral fingerprints; the cloud-based streaming engine performs real-time anomaly detection on massive amounts of vehicle fingerprints; the verification and coordination module initiates cross-verification when an anomaly is suspected; and the isolation module accurately issues intervention commands after confirming the anomaly. The four core modules have clear division of labor and a clear data flow, forming a highly available and scalable proactive safety control system. The vehicle-side modules ensure the lightweight and effectiveness of the data source, the two cloud-based engines achieve high-precision anomaly judgment, and the isolation module ensures the accuracy and effectiveness of intervention measures, providing all-weather proactive safety assurance for large-scale intelligent connected vehicle fleets.

[0134] (5) Social value dimension: from single-vehicle safety to collective intelligent collaboration

[0135] Existing technologies are limited to monitoring from a single vehicle's perspective, failing to fully utilize the perception capabilities of other vehicles in a connected vehicle environment. This application, through a "vehicle-cloud-vehicle collaborative verification" mechanism, transforms all connected vehicles on the road into a distributed sensor network, achieving collective intelligent perception of abnormal events. When a vehicle behaves abnormally, multiple surrounding vehicles can observe and cross-verify it from different angles and using different sensors (cameras, radar, V2X). This approach to safety monitoring, utilizing the concept of "crowdsourcing," significantly enhances the coverage and accuracy of abnormal event perception. Simultaneously, during the isolation phase, the cloud broadcasts dynamic information of abnormal vehicles to surrounding vehicles and the traffic management system, enabling collaborative avoidance. This elevates the management of single-vehicle safety risks to a collaborative public safety level involving "vehicle-road-cloud," yielding significant social benefits.

[0136] The embodiments of remote security isolation methods and the embodiments of remote security isolation systems are identical or related in technical concept, and can be referenced and learned from each other in terms of technical details and technical effects, which will not be repeated here.

[0137] Based on the same inventive concept, embodiments of this application also provide an electronic device. Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of this application. Figure 4 As shown in the embodiments of this application, an electronic device includes: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement any of the remote security isolation methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0138] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0139] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0140] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0141] This application also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the remote secure isolation methods described in the above embodiments. The computer-readable storage medium may be volatile or non-volatile.

[0142] This application also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described remote security isolation method.

[0143] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0144] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0145] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0146] The computer program instructions used to perform the operations of this application may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), are personalized by utilizing the status information of the computer-readable program instructions. These electronic circuits can execute the computer-readable program instructions to implement various aspects of this application.

[0147] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0148] Various aspects of this application are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0149] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0150] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

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

[0152] Exemplary embodiments have been disclosed in this application, and while specific terminology has been used, it is used only and should be interpreted in a general illustrative sense and is not intended to be limiting. In some embodiments, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this application as set forth by the appended claims.

Claims

1. A method for remote security isolation based on digital fingerprint and vehicle behavior anomaly detection, characterized in that, include: Receive vehicle behavior digital fingerprint uploaded by the vehicle terminal; the vehicle behavior digital fingerprint is a feature vector that is periodically generated by the vehicle terminal based on real-time vehicle operation data and is used to characterize the short-term driving behavior pattern of the vehicle. Based on a pre-established dynamic benchmark model, anomaly detection is performed on the received vehicle behavior digital fingerprint. If the detection result meets the preset suspected anomaly conditions, the vehicle is marked as a suspected abnormal vehicle. The dynamic benchmark model is constructed based on real-time learning of the vehicle behavior digital fingerprints of multiple normal vehicles. In response to the marking of the suspected abnormal vehicle, a multi-source collaborative verification process is initiated to obtain multi-party verification information regarding the authenticity of the suspected abnormal vehicle's status; Based on the multi-party verification information, after confirming that the vehicle has a real anomaly, according to the preset anomaly level and / or vehicle status, the corresponding graded remote safety isolation strategy is selected and triggered, and a remote control command is sent to the vehicle to restrict its dangerous behavior.

2. The method of remote secure isolation of claim 1, wherein, The vehicle behavior digital fingerprint includes at least one or more of the following feature dimensions: The system includes acceleration statistics reflecting the vehicle's longitudinal control behavior, steering angle variation reflecting the vehicle's lateral control behavior, pedal operation coordination reflecting the driver's operational coordination, trajectory deviation reflecting the vehicle's path-keeping ability, and software integrity and operational status reflecting the health status of the vehicle's core controller.

3. The method of remote secure isolation according to claim 1 or 2, characterized in that, The dynamic benchmark model uses an unsupervised learning algorithm to cluster the digital fingerprints of normal vehicle behavior, generating one or more normal behavior clusters representing different typical driving modes, and updates the statistical features of the clusters in real time. The anomaly detection steps include: calculating the Mahalanobis distance between the vehicle behavior digital fingerprint of the vehicle under test and the normal behavior cluster, and determining whether it is abnormal based on whether the Mahalanobis distance exceeds a preset dynamic threshold.

4. The remote security isolation method according to claim 1, characterized in that, The multi-source collaborative verification process includes: Send a collaborative perception request to at least one other vehicle in the vicinity of the suspected abnormal vehicle; Receive verification information from other vehicles after they perceive the operating status of the suspected abnormal vehicle based on their own sensors; A safety challenge command is sent to the suspected abnormal vehicle, requesting its designated controller to perform a safety self-test and return the self-test results.

5. The remote security isolation method according to claim 4, characterized in that, The security challenge instruction is randomly generated and different each time. The designated controller is required to perform a signature operation on the security challenge instruction based on its internal private key within a preset very short time and return the signature result as a self-test result. The correctness of the signature result is verified using the corresponding pre-stored public key.

6. The remote security isolation method according to claim 1, characterized in that, The tiered remote security isolation strategy includes one or more progressively higher levels of intervention: Level 1: Guide the vehicle to a minimum risk state by limiting some of its power and activating hazard warnings; The second level activates the vehicle's security domain isolation mechanism to block network communication between abnormal functional domains and other domains. The third level involves dynamically setting and enforcing electronic fences for vehicles to restrict their driving area. Level 4 triggers a group warning, broadcasting the abnormal vehicle's abnormal status information and real-time location to other traffic participants around the abnormal vehicle, so as to coordinate and achieve proactive avoidance of surrounding traffic flow.

7. The remote security isolation method according to claim 6, characterized in that, The steps for guiding the vehicle into a minimum risk state include: Based on the vehicle's current geographical location, traffic flow, and / or road conditions, a safe and feasible guidance route and parking point are calculated, and instructions containing the guidance route and parking point are sent to the vehicle for execution by the vehicle's advanced driver assistance system or autonomous driving system.

8. A remote security isolation system capable of implementing the remote security isolation method according to any one of claims 1-7, characterized in that, include: The vehicle fingerprint generation module is installed on the target vehicle and is used to periodically generate vehicle behavior digital fingerprints that characterize the vehicle's short-term driving behavior patterns based on the vehicle's real-time operating data, and report them to the cloud. The cloud-based anomaly detection engine receives the vehicle's digital fingerprint and performs anomaly detection based on a dynamically updated normal behavior benchmark model, marking vehicles that meet the suspected anomaly conditions as suspected abnormal vehicles. The cloud-based verification and coordination module is used to respond to the marking of the suspected abnormal vehicle, initiate a multi-source collaborative verification process, obtain multi-party verification information on the authenticity of the suspected abnormal vehicle's status, and confirm whether the vehicle is truly abnormal based on the multi-party verification information. The remote isolation command issuing module is used to select and trigger the corresponding hierarchical remote security isolation strategy according to the preset abnormality level and / or vehicle status after confirming that there is a real abnormality in the vehicle, and generate and send the corresponding remote control command to the vehicle.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors are enabled to implement the steps in the remote security isolation method as described in any one of claims 1 to 7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it can implement the steps of the remote security isolation method as described in any one of claims 1 to 7.

Images