Internet of vehicles device security control method, apparatus, device, and storage medium

Abstract

The application relates to a kind of vehicle networking equipment security control method, device, equipment and storage medium. Including: when the IoT device in access vehicle hub does not have hardware security capability, create the virtual security container corresponding to IoT device, and proxy the cryptography operation of IoT device, to establish the verifiable identity of IoT device, determine the context risk level based on the real-time running state of vehicle, according to the real-time behavior data obtained by monitoring IoT device and the real-time running state of vehicle, update the dynamic trust value of IoT device, according to dynamic trust value and context risk level, the access request of IoT device is executed differentiated authorization processing. Without hardware modification and network dependence, the method establishes the verifiable identity for the IoT device without security capability, and combines vehicle real-time state and behavior monitoring to implement dynamic trust evaluation, according to the trust degree of equipment, environmental risk and operation sensitivity, differentiated authorization is carried out, and a complete closed loop from trusted access to dynamic control is formed.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking and vehicle information security technology, specifically to a vehicle networking device security control method, apparatus, equipment, and storage medium. Background Technology

[0002] As intelligent connected vehicles evolve from "feature phones" to "smartphones," vehicles are becoming super mobile intelligent terminals connecting individuals, transportation infrastructure, and urban services. This requires vehicles to securely and efficiently access and manage massive amounts of heterogeneous IoT devices, including aftermarket OBD diagnostic tools, user smart terminals (phones / watches), V2X roadside units (RSUs), and third-party service terminals (such as smart charging pile interaction modules).

[0003] Existing technologies for vehicle-to-everything (V2X) security mainly revolve around device authentication, access control, and cross-domain collaboration. However, existing security authentication technologies in the Internet of Things (IoT) or IT fields suffer from serious "incompatibility" when directly transplanted to the highly dynamic, security-critical, and resource-constrained V2X environment.

[0004] Therefore, the inability to reliably identify IoT devices that lack hardware security capabilities after they are connected to vehicles is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] One of the objectives of this invention is to provide a method, apparatus, device, and storage medium for security control of Internet of Vehicles (IoV) devices, in order to solve the problem that IoT devices without hardware security capabilities cannot be reliably identified after being connected to a vehicle.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] A vehicle-to-everything (V2X) device security control method is applied to a vehicle central hub deployed on a vehicle, the method comprising:

[0008] The hardware security capabilities of IoT devices connected to the vehicle's central hub are identified.

[0009] If the IoT device does not have hardware security capabilities, a virtual security container corresponding to the IoT device is created in the security execution environment of the vehicle hub, and the virtual security container is used to proxy the cryptographic operations of the IoT device to establish the verifiable identity of the IoT device.

[0010] The real-time operating status of the vehicle is obtained, and the contextual risk level is determined based on the real-time operating status.

[0011] Based on the verifiable identity, the IoT device is continuously monitored for behavior, and the dynamic trust value of the IoT device is updated according to the real-time behavior data obtained from the monitoring and the real-time operating status of the vehicle.

[0012] Based on the dynamic trust value and the context risk level, differentiated authorization processing is performed on the access requests of the IoT device.

[0013] Based on the above technical means, a verifiable cryptographic identity can be established for weakly secure IoT devices without modifying them, enabling them to have a hardware-level trusted identity in the dynamic operating environment of the vehicle; at the same time, based on the real-time status of the vehicle and the identity anchor point, the device behavior can be continuously evaluated and dynamically differentiated, realizing a complete security closed loop from "trustworthy identity" to "trustworthy behavior".

[0014] Furthermore, the method also includes:

[0015] When the IoT device needs to access the vehicle's external service domain, the vehicle's central hub issues a cross-domain access credential based on the IoT device's current dynamic trust value. This credential is then presented by the IoT device to the external service domain. The cross-domain access credential is obtained by digitally signing the private key of the vehicle's central hub's secure execution environment.

[0016] Based on the above technical means, the device can reuse the credentials issued by the vehicle central hub to complete cross-domain access across different external service domains, avoiding repeated registration and authentication, and realizing "one assessment, multiple domain access".

[0017] Furthermore, the real-time operating status includes at least one of vehicle motion status, vehicle control status, vehicle body status, environmental status, and communication status. Determining the context risk level based on the real-time operating status includes:

[0018] A basic risk score is set based on the vehicle's motion state;

[0019] Based on the vehicle control status and / or the communication status, a weighting coefficient is determined, and the basic risk score is weighted and corrected to obtain a composite risk score.

[0020] The composite risk score is compared with a preset risk threshold to determine whether the contextual risk level is high risk, medium risk, or low risk.

[0021] Based on the aforementioned technical means, discrete operating parameters such as vehicle speed, control status, and communication status are quantified into a unified structured risk level, enabling subsequent authorization decisions to accurately reflect the safety sensitivity of the current driving environment.

[0022] Furthermore, updating the dynamic trust value of the IoT device based on real-time behavioral data obtained from monitoring and the real-time operating status of the vehicle includes:

[0023] A rule engine is used to perform correlation analysis between the real-time behavioral data and the real-time operating status to obtain the correlation analysis results.

[0024] An anomaly detection model is used to detect the deviation of the real-time behavior data from the historical behavior baseline of the IoT device, and the deviation detection result is obtained.

[0025] Based on the correlation analysis results and the deviation detection results, the dynamic trust value of the IoT device is updated comprehensively.

[0026] Based on the aforementioned technical means, the rule engine matches known violation patterns, while the anomaly detection model discovers unknown slow attacks. The two complement each other to form a dual detection capability of "precise interception of known violations + comprehensive coverage of unknown violations", thereby improving the comprehensiveness and accuracy of trust assessment.

[0027] Furthermore, the step of performing differentiated authorization processing on access requests to the IoT device based on the dynamic trust value and the context risk level includes:

[0028] Obtain the request sensitivity of the access request;

[0029] Using the dynamic trust value, the context risk level, and the request sensitivity as joint inputs, a preset strategy matrix is ​​queried to determine the corresponding authentication level. The strategy matrix is ​​used to define the authentication level corresponding to different combinations of dynamic trust value, context risk level, and request sensitivity.

[0030] Perform the corresponding security processing actions based on the authentication level.

[0031] Based on the aforementioned technical means, joint decision-making is made from three dimensions: device trustworthiness (trust value), environmental risk (risk level), and operational hazard (request sensitivity), to achieve fine-grained context-adaptive authorization and avoid the "one-size-fits-all" static authorization strategy.

[0032] Furthermore, the authentication level includes at least one of direct release, fast verification, enhanced authentication, and immediate blocking;

[0033] The direct passage means that the access request is allowed to pass;

[0034] The rapid verification refers to verifying a short-term valid token for the IoT device;

[0035] The enhanced authentication indicates that the user is required to manually confirm.

[0036] The immediate blocking means rejecting the access request and triggering an alarm and / or physical isolation.

[0037] Based on the aforementioned technical means, authentication methods of different strengths (high trust, no verification required; low trust, enhanced verification; and extremely low trust, blocking) are matched according to the level of trust, achieving a dynamic balance between security and user experience.

[0038] Furthermore, the step of creating a virtual secure container corresponding to the IoT device within the secure execution environment of the vehicle's central hub, and using the virtual secure container to proxy the cryptographic operations of the IoT device, includes:

[0039] Create the logically isolated virtual security container within the secure execution environment;

[0040] Within the virtual secure container, a unique temporary asymmetric key pair is generated for the IoT device, wherein the private key never leaves the physical boundary of the secure execution environment;

[0041] Using the root private key of the vehicle hub, the device identifier of the IoT device is signed with the temporary public key and the authorization attributes to generate a virtual certificate for the IoT device.

[0042] Based on the above technical means, temporary private keys are stored in a hardware-isolated virtual container and never leave the country, ensuring that even if the device is compromised, the key materials cannot be stolen; at the same time, the virtual certificate issued by the vehicle's root private key provides the device with cryptographic identity credentials that are unforgeable and can be verified externally.

[0043] Furthermore, the method also includes:

[0044] Receive the hash value of the data to be signed sent by the IoT device;

[0045] The hash value is routed to the virtual security container;

[0046] The secure execution environment uses a temporary private key within the virtual secure container to sign the hash value of the data to be signed;

[0047] The signature result is returned to the IoT device.

[0048] Based on the above technical means, the private key never leaves the secure execution environment. The device only needs to submit the hash value of the data to be signed to obtain the signature result. Under the premise of ensuring the physical security of the private key, the cryptographic service proxy to external devices is realized to prevent the risk of key leakage.

[0049] Furthermore, the method also includes:

[0050] If the IoT device has hardware security capabilities, then perform two-way authentication based on digital certificates, and grant an initial dynamic trust value to the IoT device after successful authentication;

[0051] Among them, the initial dynamic trust value of IoT devices with hardware security capabilities is higher than that of IoT devices without hardware security capabilities.

[0052] Based on the above technical means, devices with hardware security capabilities can directly use lightweight certificate authentication and automatically obtain a higher initial trust value, optimizing access efficiency and avoiding unnecessary virtualization overhead; devices without hardware security capabilities can obtain equivalent security capabilities through virtualization, ultimately achieving convergence of security baselines for the two types of devices.

[0053] Furthermore, before creating a virtual security container corresponding to the IoT device within the security execution environment of the vehicle hub, the method further includes:

[0054] The device identifier is initially bound to the IoT device via an out-of-band channel, and a session key is negotiated.

[0055] Based on the above technical means, physical identity verification is achieved through out-of-band channels (such as QR code scanning), preventing device identity from being impersonated and establishing a secure communication foundation for subsequent virtual container creation and cryptographic proxies.

[0056] Furthermore, the method also includes:

[0057] Receive at least one of the following auxiliary services through cloud-based collaborative services: threat intelligence synchronization, risk model updates, policy matrix updates, and cross-domain credential revocation status queries;

[0058] The cloud-based collaborative service provides auxiliary support only when the network is connected, while the vehicle central control system independently executes safety control decisions when the network is interrupted.

[0059] Based on the above technical means, the strong dependence on the network is eliminated, ensuring that the core safety control functions of the vehicle can still operate independently in scenarios with no or weak network, such as tunnels, underground garages, and remote mountainous areas, thus meeting the continuity and reliability requirements of automotive-grade functional safety.

[0060] Furthermore, the method also includes:

[0061] A device agent client is pushed and installed to the IoT device. The device agent client is used to execute a lightweight agent protocol, which includes negotiating a session key, forwarding requests that require a secure execution environment agent signature, and receiving and applying at least one of a virtual certificate and a cross-domain credential.

[0062] Based on the aforementioned technical means, a lightweight proxy protocol enables IoT devices to access the vehicle's central security system at extremely low development costs, reducing the barriers to ecosystem integration and ensuring the security of communication links and the timeliness of credential updates.

[0063] A vehicle networking device safety control device, comprising:

[0064] The identification module is used to identify the hardware security capabilities of IoT devices connected to the vehicle's central hub.

[0065] A module is established to create a virtual security container corresponding to the IoT device in the secure execution environment of the vehicle hub if the IoT device does not have hardware security capabilities, and to use the virtual security container to proxy the cryptographic operations of the IoT device in order to establish a verifiable identity for the IoT device.

[0066] The acquisition module is used to acquire the real-time operating status of the vehicle and determine the context risk level based on the real-time operating status.

[0067] The update module is used to continuously monitor the behavior of the IoT device based on the verifiable identity, and update the dynamic trust value of the IoT device according to the real-time behavior data obtained from the monitoring and the real-time operating status of the vehicle.

[0068] The execution module is used to perform differentiated authorization processing on the access request of the IoT device based on the dynamic trust value and the context risk level.

[0069] A vehicle central control unit includes: a storage unit and a processing unit;

[0070] The storage unit stores computer-executed instructions;

[0071] The processing unit executes the computer execution instructions stored in the storage unit to implement the vehicle networking device safety control method described above.

[0072] A computer-readable storage medium storing computer-executable instructions, which, when executed by a processing unit, are used to implement the vehicle networking device security control method as described in any of the preceding claims.

[0073] A computer program product includes a computer program that, when executed by a processing unit, implements the vehicle networking device security control method described in any of the above claims.

[0074] The beneficial effects of this invention are:

[0075] By creating a virtual secure container for IoT devices lacking hardware security capabilities within the secure execution environment of the vehicle's central hub and proxying their cryptographic operations, these devices can obtain verifiable cryptographic identities and hardware-level key protection without any hardware modifications. This fundamentally solves the core problem of untrustworthy access for weakly secure connected vehicle devices. Building upon this, the real-time operating status of the vehicle is quantified into structured risk levels. A rule engine and anomaly detection model are integrated to continuously monitor the behavior of connected devices and conduct dynamic trust assessments. Furthermore, by combining request sensitivity with a policy matrix, context-adaptive differentiated authorization is achieved. This upgrades security decisions from static, one-size-fits-all access control to dynamic, refined management based on a three-dimensional joint judgment of "trustworthy identity + trustworthy behavior + environmental risk." Simultaneously, verifiable credentials issued by the vehicle enable cross-domain authentication without duplication, and cloud-based decision support ensures independent operation even when offline. Ultimately, without modifying existing equipment, relying on the network, or increasing ecosystem costs, a complete closed-loop system from device access, identity establishment, continuous monitoring to dynamic authorization management is constructed. This represents a comprehensive architectural upgrade of connected vehicle device security management from "passive defense" to "proactive adaptive management." Attached Figure Description

[0076] Figure 1 Example 1 of the vehicle networking device security control method provided in this solution;

[0077] Figure 2 Example 2 of the vehicle networking device security control method provided in this solution;

[0078] Figure 3 Example 3 of the vehicle networking device security control method provided in this solution;

[0079] Figure 4 Example 4 of the vehicle networking device security control method provided in this solution;

[0080] Figure 5 Example 5 of the vehicle networking device security control method provided in this solution;

[0081] Figure 6 A schematic diagram of the vehicle networking equipment security control device provided for this solution;

[0082] Figure 7 A schematic diagram of the vehicle's central structure provided for this solution. Detailed Implementation

[0083] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0084] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0085] Figure 1 Example 1 of the vehicle networking device security control method provided in this solution, such as Figure 1 As shown, this method is applied to a vehicle central control unit deployed on a vehicle, specifically including:

[0086] S101: Hardware security capabilities for identifying IoT devices connected to the vehicle's central hub.

[0087] This step assesses the security capabilities of the IoT devices requesting access in order to determine which access strategy to adopt subsequently.

[0088] Specifically, the vehicle's central control system establishes initial communication with IoT devices through a device agent client, and the devices report their hardware security capabilities. The central control system then determines whether the device possesses a hardware security module (such as an SE secure element or a TPM trusted platform module) based on the reported information. Specific criteria for this determination include whether the device has a built-in independent security chip, whether it supports hardware-level key storage and cryptographic operations, and whether it meets the HSM level defined in the EVITA standard. Based on the detection results, the devices are categorized into two types: "strong security devices" (possessing hardware security capabilities such as SE / TPM) and "weak / no security devices" (lacking hardware security capabilities), each corresponding to different subsequent processing paths.

[0089] S102: If the IoT device does not have hardware security capabilities, a virtual security container corresponding to the IoT device is created in the secure execution environment of the vehicle's central hub, and the virtual security container is used to proxy the cryptographic operations of the IoT device to establish a verifiable identity for the IoT device.

[0090] This step enables IoT devices that lack hardware security capabilities to obtain verifiable cryptographic identity and hardware-level key protection without any hardware modifications.

[0091] Specifically, a logically isolated virtual secure container is created within the secure execution environment. Within the virtual secure container, a unique temporary asymmetric key pair is generated for the IoT device. The private key never leaves the physical boundary of the secure execution environment. The root private key of the vehicle hub is used to identify the IoT device, sign the temporary public key and authorization attributes, and generate a virtual certificate for the IoT device. The hash value of the data to be signed sent by the IoT device is received, and the hash value is routed to the virtual secure container. The secure execution environment uses the temporary private key within the virtual secure container to sign the hash value of the data to be signed, and returns the signing result to the IoT device.

[0092] Optionally, the method further includes performing two-way authentication based on digital certificates if the IoT device has hardware security capabilities, and granting an initial dynamic trust value to the IoT device after successful authentication, wherein the initial dynamic trust value of the IoT device with hardware security capabilities is higher than that of the IoT device without hardware security capabilities.

[0093] For IoT devices with hardware security capabilities, strong two-way authentication based on digital certificates is performed. Upon successful authentication, a higher initial dynamic trust value is directly granted, skipping the virtualization empowerment step and directly entering the continuous behavior monitoring stage. The initial trust value of a strongly secure device is higher than the initial trust value of a weakly secure device after virtualization empowerment.

[0094] S103: Obtain the real-time operating status of the vehicle and determine the context risk level based on the real-time operating status.

[0095] This step quantifies the vehicle's dynamic operating environment into a structured risk level, providing an environmental risk dimension for subsequent differentiated authorization decisions.

[0096] Specifically, a basic risk score is set based on the vehicle's motion state, and a weighting coefficient is determined based on the vehicle's control state and / or communication state. The basic risk score is then weighted and corrected to obtain a composite risk score. The composite risk score is compared with a preset risk threshold to determine whether the contextual risk level is high, medium, or low.

[0097] S104: Based on verifiable identity, continuously monitor the behavior of IoT devices and update the dynamic trust value of IoT devices according to the real-time behavior data obtained from the monitoring and the real-time operating status of the vehicle.

[0098] This step, based on established verifiable identities, continuously monitors the behavior of access devices, quantifies their credibility in real time by integrating multi-dimensional information, and discovers known violations and unknown slow, covert attacks.

[0099] Specifically, a rule engine is used to perform correlation analysis on real-time behavioral data and real-time operating status to obtain correlation analysis results. An anomaly detection model is used to detect the deviation of real-time behavioral data from the historical behavior baseline of IoT devices to obtain deviation detection results. Based on the correlation analysis results and deviation detection results, the dynamic trust value of IoT devices is updated comprehensively.

[0100] S105: Perform differentiated authorization processing on access requests to IoT devices based on dynamic trust values ​​and contextual risk levels.

[0101] This step combines the device's real-time trustworthiness, the current vehicle operating environment risk, and the sensitivity of the request. Through a policy matrix, it achieves context-adaptive and refined authorization decisions, avoiding security vulnerabilities or user experience degradation caused by static "one-size-fits-all" policies.

[0102] Specifically, the request sensitivity of the access request is obtained. Using the dynamic trust value, context risk level, and request sensitivity as joint inputs, a preset policy matrix is ​​queried to determine the corresponding authentication level, and the corresponding security processing action is executed according to the authentication level.

[0103] Optionally, the method further includes: when an IoT device needs to access an external service domain of the vehicle, the vehicle central hub issues a cross-domain access credential based on the current dynamic trust value of the IoT device, which the IoT device can then present to the external service domain, wherein the cross-domain access credential is obtained by digitally signing the private key of the secure execution environment of the vehicle central hub.

[0104] This step eliminates the need for devices to repeatedly register and authenticate in every external service domain, enabling "one-time in-vehicle authentication for trusted access across all domains." Meanwhile, credential verification can be completed offline, adapting to in-vehicle environments with intermittent network connectivity.

[0105] Specifically, when a vehicle enters a cooperating external service domain (such as a branded charging station or smart parking lot), in-vehicle devices may need to access services in that external domain. The vehicle's central cross-domain credential manager issues a short-term, limited-access credential (e.g., 5 minutes) with restricted permissions (e.g., only able to query charging station status) based on the device's current dynamic trust score. This credential conforms to the W3C verifiable credential standard, contains device identity information, authorization scope, validity period, etc., and is digitally signed by the private key of the vehicle's central secure execution environment.

[0106] When a device presents this credential to an external service domain, the external service provider does not need to recognize the device or query the cloud online. It only needs to verify the validity of the signature on the credential using a pre-obtained vehicle public key. Successful verification indicates that the request has been endorsed by the vehicle central authority, thus allowing the service to proceed. This mechanism simplifies the authentication problem for external services dealing with a massive number of heterogeneous devices to the verification problem of a single trusted vehicle identity, and fully supports offline operation.

[0107] The vehicle-to-everything (V2X) device security control method provided in this application identifies the hardware security capabilities of IoT devices accessing the vehicle's central hub. If the IoT device lacks hardware security capabilities, a virtual security container corresponding to the IoT device is created within the vehicle's central hub's security execution environment. This virtual security container proxies the IoT device's cryptographic operations to establish a verifiable identity for the IoT device. The method then acquires the vehicle's real-time operating status and determines the contextual risk level based on this status. Based on the verifiable identity, continuous behavior monitoring of the IoT device is performed. The dynamic trust value of the IoT device is updated based on the real-time behavior data and the vehicle's real-time operating status. Differential authorization processing is then applied to the IoT device's access requests based on the dynamic trust value and the contextual risk level. This method establishes a verifiable cryptographic identity for IoT devices lacking hardware security capabilities without modifying the device or relying on the network. It combines the vehicle's real-time operating status with dual-engine behavior monitoring for continuous dynamic trust assessment. Furthermore, it implements context-adaptive, refined authorization based on device trust, environmental risk, and operational sensitivity. Ultimately, this forms a complete closed loop from trusted access and continuous assessment to dynamic control, achieving a comprehensive upgrade of V2X device security management from static passive defense to dynamic proactive control.

[0108] Figure 2 Example 2 of the vehicle networking device security control method provided in this solution, such as Figure 2 As shown, based on the above embodiments, the real-time operating state includes at least one of vehicle motion state, vehicle control state, vehicle body state, environmental state, and communication state. Step S103 specifically includes:

[0109] S201: Set a basic risk score based on the vehicle's motion status.

[0110] This step maps real-time vehicle speed, the most crucial vehicle dynamic parameter, to an initial risk metric, serving as the starting point for subsequent comprehensive scoring.

[0111] Specifically, the vehicle's central control unit continuously receives real-time vehicle speed signals from the vehicle dynamics control system via the CAN bus or FlexRay bus. The acquisition frequency is consistent with the system synchronization period (e.g., it can be set to 200ms) to ensure that the risk level can be updated in a timely manner as the vehicle speed changes.

[0112] After being converted by the gateway MCU, the vehicle speed sensor data is transmitted to the vehicle's central safety coprocessor in structured data format. The central system then sets a basic risk score based on the current vehicle speed according to a preset segmented mapping rule. This mapping rule employs a stepped piecewise function design, discretizing the continuous speed range into a finite number of score ranges corresponding to different risk levels.

[0113] For example, when the vehicle speed is above 80 km / h, the vehicle's central control system directly determines that the current scenario is extremely sensitive to safety control, and any erroneous network commands or device operations could lead to serious traffic accidents. Therefore, a base risk score is set as the threshold corresponding to the high-risk level (e.g., 1.0). When the vehicle speed is between 30 km / h and 80 km / h, the vehicle is in a medium-to-high-speed driving state. Network attacks or misoperations may still cause personal injury or property damage, but the risk level is lower than at high speeds. Therefore, a base score corresponding to the medium-risk level is set (e.g., 0.6). When the vehicle speed is below 30 km / h, the vehicle is basically in a low-speed driving, creeping, or stationary state. The consequences of erroneous network commands are relatively controllable. Therefore, a base score corresponding to the low-risk level is set (e.g., 0.3). In the specific implementation, the vehicle speed threshold and the corresponding base score can be loaded through a configuration file during system initialization and can be remotely adjusted through cloud policy updates.

[0114] S202: Determine the weighting coefficients based on the vehicle control status and / or communication status, and perform weighted correction on the basic risk score to obtain the composite risk score.

[0115] This step incorporates vehicle dynamics factors other than speed into the risk score, and performs multi-dimensional weighted adjustments to the base score so that the risk level can comprehensively reflect the vehicle's overall safety sensitivity.

[0116] Specifically, while collecting vehicle speed signals, the vehicle's central control unit simultaneously obtains vehicle control status information and communication status information from the vehicle bus. Control status information includes the current gear position (P / R / N / D), whether the brake pedal is depressed, and the status of the turn signals; communication status information includes cellular network signal strength, Wi-Fi signal strength, and current network latency.

[0117] The vehicle's central control system determines the weighting coefficients for each dimension based on the specific values ​​of the control and communication states, according to a preset weighting mapping rule. The weighting coefficients are designed to reflect the degree of impact of different vehicle states on safety sensitivity: When the vehicle is in D or R gear, it is in a movable state. At this time, any network command to the powertrain or chassis system may directly change the vehicle's physical motion state. Therefore, the base risk score in this state is multiplied by 1.5 to improve the overall risk score. When the brake pedal is depressed, the vehicle is in the process of deceleration or emergency braking. If interference commands are injected from the network side (such as sudden acceleration requests), it will directly conflict with the driver's physical braking intention, posing a very high risk. Therefore, it is multiplied by 2.0, the highest among all correction items. When the cellular or Wi-Fi network signal strength is weak, communication between the vehicle's central control system and cloud-based collaborative services may be unstable or interrupted. The vehicle needs to rely entirely on local decision-making, limiting remote monitoring and emergency command issuance capabilities. Furthermore, devices are more susceptible to man-in-the-middle attacks or signal interference in weak signal environments. Therefore, it is multiplied by 1.2 to reflect the additional risks brought about by communication instability.

[0118] The specific values ​​of each weighting coefficient are defined by the configuration file during system initialization and can be dynamically adjusted via OTA remote updates. The weighting coefficients are determined in real time based on the current vehicle status each time the risk level is recalculated (e.g., every 200ms cycle), thus ensuring that the correction coefficients can be adjusted in real time as the vehicle status changes rapidly.

[0119] S203: Compare the composite risk score with the preset risk threshold to determine the context risk level as high risk, medium risk or low risk.

[0120] This step discretizes the continuous risk scores into three structured risk levels—high, medium, and low—through threshold comparison, enabling subsequent strategy decisions to be quickly matched based on clear risk classifications and avoiding decision delays caused by complex comparisons of continuous values.

[0121] Specifically, the vehicle control system multiplies the basic risk score set in S201 with the various weighting coefficients determined in S202 and sums them to obtain the final composite risk score. This composite score is a quantitative result of weighted fusion of multiple dimensions such as vehicle speed, control status, and communication status, and its magnitude comprehensively reflects the safety sensitivity of the current vehicle operating environment.

[0122] The vehicle's central control system compares the calculated composite risk score with preset upper and lower risk thresholds. These thresholds are determined based on vehicle safety engineering experience and risk tolerance analysis. The upper threshold corresponds to the critical point where "exceeding this threshold indicates the vehicle is in an extremely high-risk state," while the lower threshold corresponds to the boundary where "below this threshold indicates the vehicle is in an acceptable low-risk state." For example, a high-risk threshold is set at a composite risk score of at least 1.2, meaning that when the vehicle speed is high and high-weight corrections such as braking or gear shifting are applied, exceeding this threshold triggers a high-risk assessment. A medium-risk threshold is set at a composite risk score between 0.5 and 1.2, corresponding to medium-to-high speed driving or situations where some high-weight corrections are triggered but not applied. A composite risk score below 0.5 is considered low-risk, corresponding to low-speed or stationary situations without high-weight corrections. Based on the comparison results, the current context risk level is determined to be one of three discrete levels: high risk, medium risk, or low risk.

[0123] The vehicle-to-everything (V2X) device safety control method provided in this application sets a basic risk score based on the vehicle's motion state, determines weighting coefficients based on the vehicle's control state and / or communication state, and performs a weighted correction on the basic risk score to obtain a composite risk score. The composite risk score is then compared with a preset risk threshold to determine whether the contextual risk level is high, medium, or low. This method incorporates multi-dimensional real-time operating parameters such as vehicle speed, vehicle control state, and communication state into a unified weighted fusion calculation framework, and discretizes them into structured risk levels based on preset thresholds. This provides a quantitative input dimension that accurately reflects the safety sensitivity of the current driving environment for subsequent differentiated authorization decisions.

[0124] Figure 3 Example 3 of the vehicle networking device security control method provided in this solution, such as Figure 3 As shown, based on the above embodiments, step S104 specifically includes:

[0125] S301: Use a rule engine to perform correlation analysis on real-time behavioral data and real-time operating status to obtain correlation analysis results.

[0126] This step uses predefined safety rules that are strongly correlated with the vehicle context to match device behavior in real time, accurately identify known types of illegal operation patterns, and achieve rapid interception of deterministic abnormal behavior.

[0127] Specifically, the vehicle's central control unit continuously receives request streams from connected IoT devices. The request streams contain at least metadata fields such as request type, target resource, request frequency, and data load.

[0128] Building upon this foundation, the vehicle's central processing unit employs a rule engine to perform correlation analysis between real-time behavioral data and the current real-time operational status. The rule engine pre-configures a series of safety rules strongly bound to the vehicle's physical context. Each rule uses a logical structure of conditions and decisions; the condition section describes a specific combination of behavioral characteristics and vehicle state, while the decision section defines the risk level corresponding to that combination.

[0129] In actual operation, the rule engine sequentially matches the current device behavior against the conditions of each rule. When all conditions of a rule are met, it is determined that the device behavior has triggered that rule, and the corresponding risk assessment result is output as the correlation analysis result. The rule engine can complete the matching and assessment of all rules within milliseconds, ensuring real-time response capabilities to known violations.

[0130] Typical examples of the rules are as follows: When the vehicle speed is detected to be higher than 80 km / h, the target resource is a brake control unit, and the operation type is a write command, the rule engine immediately classifies the request as extremely high risk. As another example, when the vehicle speed is detected to be higher than 50 km / h, the device type is an aftermarket OBD device, and the target resource is the powertrain CAN bus, the rule engine classifies the request as high risk. Furthermore, when the door status is detected to be unlocked, the device type is a T-Box, and the operation type is a remote door opening command, the rule engine combines real-time vehicle speed for judgment; if the vehicle speed is higher than 5 km / h, it is classified as high risk; if the vehicle speed is zero and the vehicle is parked, it is classified as low risk.

[0131] S302: Use an anomaly detection model to detect the deviation of real-time behavior data from the historical behavior baseline of IoT devices, and obtain the deviation detection result.

[0132] This step identifies unknown types of attacks that the rule engine cannot cover, especially slow, covert attacks that have low frequency of behavior, long duration, and seemingly normal single operations (such as long-term low-rate data theft after device hijacking).

[0133] Specifically, the vehicle central control maintains a dynamic behavioral baseline model independently for each connected IoT device. The process of establishing this baseline model is as follows: In the initial stage of device access, the system continuously collects behavioral characteristic data of the device under normal conditions (including at least request type distribution, target resource distribution, request frequency, data throughput, access time patterns, etc.) to form a multi-dimensional statistical distribution model as the "normal behavioral baseline" of the device.

[0134] During normal equipment operation, the anomaly detection model continuously monitors the equipment's real-time behavioral data and compares the real-time behavioral characteristics with the corresponding historical behavioral baseline. The core indicator for this comparison is statistical deviation, which is the degree of deviation of the current behavior from the baseline model. This is specifically quantified by calculating the Mahalanobis distance or a similar statistical distance between the real-time behavioral feature vector and the baseline model. The meaning of deviation is: the closer the equipment's behavior is to its historical normal behavior pattern, the lower the deviation, indicating a more trustworthy equipment; when the equipment's behavior suddenly changes significantly (e.g., a sensor that normally requests only 3-5 read operations per hour suddenly starts continuously requesting sensitive data at a frequency of 30 times per minute), the deviation will increase significantly, indicating a possible anomaly.

[0135] The training and updating of the anomaly detection model are both performed online. The baseline model of the device is continuously optimized and updated using new data generated during device operation to adapt to gradual changes in the device's normal behavior patterns (such as reasonable changes in behavioral characteristics due to software upgrades). This step runs continuously, working in parallel with the rules engine.

[0136] S303: Based on the correlation analysis results and deviation detection results, update the dynamic trust value of IoT devices.

[0137] This step merges the outputs from the rule engine and the anomaly detection model, and updates the device's trust score in real time using a unified dynamic deduction / addition algorithm to form a comprehensive quantitative evaluation of the device's trustworthiness.

[0138] Specifically, the vehicle central control receives the correlation analysis results output by the rule engine in S301 and the deviation detection results output by the anomaly detection model in S302, and uses both as dual inputs for updating the trust value.

[0139] If the correlation analysis results indicate that a high-risk rule has been triggered, the trust value will be deducted according to the pre-set deduction weight of that rule. For example, if the rule of "writing instructions to the brake control unit while driving at high speed" is triggered, a large amount of points will be deducted from the trust value at once (e.g., a direct deduction of 40-60 points). If a medium-risk rule is triggered, a smaller amount of points will be deducted (e.g., 5-20 points). Deviation detection results continuously affect the trust value. The higher the deviation, the faster the deduction rate. In extreme deviation cases, the trust value drops exponentially to quickly reflect abnormal changes in equipment behavior. Within a time window where no abnormalities are triggered and the behavior remains normal, the trust value gradually recovers at a slow rate to reflect the credit recovery brought about by long-term stable operation of the equipment.

[0140] The influence weights of the two detection results can be dynamically adjusted according to the actual running effect. In the early stage of deployment, the rule engine has a higher weight to ensure stability. As the baseline of the anomaly detection model is gradually established, the weight ratio of the model output can be appropriately increased.

[0141] The vehicle-to-everything (V2X) device security control method provided in this application uses a rule engine to perform correlation analysis on real-time behavior data and real-time operating status to obtain correlation analysis results. It also uses an anomaly detection model to detect the deviation of real-time behavior data from the historical behavior baseline of the IoT device to obtain deviation detection results. Based on the correlation analysis results and the deviation detection results, the dynamic trust value of the IoT device is comprehensively updated. This method uses a rule engine to correlate and match real-time behavior with vehicle status to accurately identify known violation patterns. Simultaneously, it uses an anomaly detection model to continuously monitor the statistical deviation of device behavior from its historical baseline to detect unknown slow attacks. The detection results from both channels are then converged and merged to comprehensively update the device's dynamic trust value, achieving accurate quantification and continuous dynamic evaluation of device trustworthiness.

[0142] Figure 4 Example 4 of the vehicle networking device security control method provided in this solution, such as Figure 4 As shown, based on the aforementioned embodiments, step S105 specifically includes:

[0143] S401: Get the request sensitivity of the access request.

[0144] This step assesses the risk level of each specific access request initiated by an IoT device, determines the sensitivity level of the target resources and operation types involved in the request, and provides the key input dimension of object sensitivity for three-dimensional joint decision-making.

[0145] Specifically, when an IoT device initiates a service request (such as "read vehicle speed", "open the door", "obtain temperature and humidity sensor data", "write instructions to the powertrain CAN bus", etc.), the vehicle's central control system first parses the request and extracts two key pieces of information: the target resource type and the operation type. The target resource type refers to the specific object the request seeks to access (such as the brake control unit, powertrain CAN bus, vehicle speed sensor, door controller, temperature and humidity sensor, telematics unit, etc.). The operation type refers to the specific action the request seeks to perform on the target resource (such as reading, writing, subscribing, controlling, batch exporting, etc.).

[0146] The vehicle's central control system, based on the extracted target resource type and operation type, queries the system's pre-set request sensitivity judgment rules to determine the sensitivity level of the current request. These sensitivity judgment rules are defined and maintained by the system during initialization, and their design follows the basic principle that "the more dangerous the operation and the more critical the resource, the higher the sensitivity." For example, specific judgment rules are as follows:

[0147] In terms of resources, sensitivity baseline values ​​are preset for different target resources. Non-critical system read operation resources (such as temperature and humidity sensors, in-vehicle temperature sensors, ambient light sensors, etc.) are classified as low-sensitivity resources. Critical information reading resources (such as vehicle speed sensors, GPS location information, accelerometers, etc.) are classified as medium-sensitivity resources. Core control command resources (such as brake control units, steering control units, power CAN bus, etc.) and privacy data resources (such as biometric information, in-vehicle microphone / camera data, etc.) are classified as high-sensitivity resources. In terms of operations, query operations are defaulted to low or medium sensitivity, write / control operations are defaulted to high sensitivity, and batch data export operations are considered high sensitivity. In actual judgment, the target resource baseline value and operation type are comprehensively evaluated. For example, accessing a temperature and humidity sensor (low-sensitivity resource) to perform a read operation (query type) is comprehensively judged as low sensitivity; accessing a vehicle speed sensor (medium-sensitivity resource) to perform a read operation is comprehensively judged as medium sensitivity; accessing a brake control unit (high-sensitivity resource) to perform a write command is comprehensively judged as high sensitivity.

[0148] Sensitivity assessment rules can be remotely updated via cloud-based collaborative services. When new attack methods emerge or the security rating of specific resources needs adjustment, OEMs can distribute updated sensitivity rule libraries via the cloud. All change records are logged in the audit log.

[0149] S402: Using dynamic trust value, context risk level, and request sensitivity as joint inputs, query the preset policy matrix to determine the corresponding authentication level.

[0150] This step integrates information from three dimensions: device trustworthiness (trust value), environmental risk (risk level), and operational hazard (request sensitivity). Through a preset strategy matrix, it quickly matches the authentication level that best suits the current overall situation, enabling context-adaptive and refined authorization decisions.

[0151] Specifically, the vehicle's central control system combines the current dynamic trust value of the IoT device (from the continuously updated results in S303), the current contextual risk level (from the judgment result in S203), and the sensitivity of this request obtained in S401 to form a three-dimensional query index (T, C, S). The vehicle's central control system uses this three-dimensional index as input to query the system's preset strategy matrix.

[0152] The strategy matrix is ​​a three-dimensional decision table whose core function is to predefine the corresponding output authentication level for each possible (T, C, S) combination. The matrix's dimensions are structured as follows: The first dimension is the dynamic trust value range, dividing the possible range of trust values ​​into multiple continuous intervals, such as a high-trust interval (e.g., 80-100 points), a medium-trust interval (e.g., 50-80 points), and a low-trust interval (e.g., 0-50 points). The second dimension is the contextual risk level, i.e., the three discrete levels of high risk, medium risk, or low risk output in S203. The third dimension is the request sensitivity, i.e., the three levels of low sensitivity, medium sensitivity, or high sensitivity output in S401. The intersection of these three dimensions forms a 3×3×3 matrix with a total of 27 combinations. The strategy matrix pre-configures the corresponding authentication level output for each combination.

[0153] The basic principle behind the authentication level mapping logic in the matrix is ​​that higher trust values, lower risk levels, and lower request sensitivity result in a more lenient output authentication level (more inclined to grant permission directly). Conversely, lower trust values, higher risk levels, and higher request sensitivity result in a more stringent output authentication level (more inclined to enhance authentication or immediately block). Specific mapping rules are illustrated below: When T falls into the high trust range, C is low risk, and S is low sensitivity, the matrix outputs "grant permission directly." When T falls into the medium trust range, C is medium risk, and S is medium sensitivity, the matrix outputs "quick verification." When T falls into the low trust range, C is high risk, and S is high sensitivity, the matrix outputs "immediate blocking." Other combinations follow the same logic, with each combination having a corresponding authentication level output. After querying the matrix, the vehicle central control obtains the authentication level corresponding to the current request.

[0154] S403: Perform the corresponding security processing actions according to the authentication level.

[0155] This step transforms the authentication level output by the policy matrix into executable security operations, achieving a closed loop from decision-making to execution.

[0156] Specifically, the vehicle's central control system executes corresponding safety procedures based on the authentication level obtained from the S402 query. Four authentication levels are pre-set, each corresponding to a different procedure, creating a progressive relationship between safety stringency and user experience.

[0157] The authentication levels include at least one of the following: direct release, fast verification, enhanced authentication, and immediate blocking;

[0158] Directly allowing access means permitting the access request to pass;

[0159] Quick Validation refers to valid short-term tokens for verifying IoT devices;

[0160] Enhanced authentication indicates that manual confirmation from the user is required;

[0161] Immediate blocking means denying the access request and triggering alerts and / or physical isolation.

[0162] Direct access indicates complete trust in the access request, allowing it to pass and execute without any additional verification steps. This level typically occurs when the device has a high trust value, the vehicle is in a low-risk state, and the request itself does not involve sensitive resources or operations. For example, this might be triggered when a device has a trust value of 90, the vehicle is stationary, and the request is to read data from a temperature and humidity sensor. Direct access minimizes interference with normal functions while ensuring security, achieving a seamless security management experience.

[0163] Quick verification requires a lightweight identity check of the device, specifically verifying a short-term valid token held by the IoT device. This token is a time-sensitive credential issued by the vehicle central control system when a device connects or its trust value is updated, typically valid for several minutes to several hours. Quick verification is typically used when the device's trust value is in the mid-to-high range but not the highest (e.g., around 70 points) and the vehicle is in a low-to-medium risk state. Compared to full access, quick verification adds a lightweight verification overhead but avoids user intervention, balancing security and convenience.

[0164] Enhanced authentication indicates that the current request is deemed risky and requires stronger identity verification. Specifically, a pop-up message appears on the vehicle's infotainment screen, requiring the driver or other in-vehicle users to manually verify the request's legitimacy. This level typically occurs when the device's trust value is medium to low, the vehicle is in a high-risk state, or the request involves highly sensitive resources. Examples include a third-party device with a trust value between 40 and 60, the vehicle being in motion, or the device requesting to read critical data. Enhanced authentication compensates for the uncertainty of automated assessments by introducing human judgment, adding a human verification step before execution to ensure that any risky access requires explicit authorization from in-vehicle personnel.

[0165] Immediate blocking indicates that the current request poses a serious security threat. The specific actions include rejecting the access request, triggering an alarm notification (notifying the cloud management platform and / or the driver), and, if necessary, initiating physical isolation (such as disconnecting the device's network connection or cutting off its power supply via the firewall function of the vehicle gateway). This level typically occurs when the device's trust value drops to an extremely low level (e.g., below 20 points), the vehicle is in a high-risk operating state, and the request itself involves highly sensitive core control resources. For example, this could be triggered when the trust value of an aftermarket OBD device continuously drops to 15 points, the vehicle is traveling at high speed, or the device requests to write control commands to the power CAN bus. Immediate blocking is a multi-level emergency response from "network layer isolation" to "physical layer disconnection," designed to minimize the actual impact of potential attacks on vehicle driving safety.

[0166] The vehicle-to-everything (V2X) device security control method provided in this application obtains the request sensitivity of access requests. Using dynamic trust value, contextual risk level, and request sensitivity as joint inputs, it queries a preset policy matrix to determine the corresponding authentication level and executes corresponding security processing actions based on the authentication level. This method uses information from three dimensions—device trust value, vehicle operating environment risk, and request operation danger—as joint inputs to query a preset policy matrix to automatically match differentiated authentication levels. Based on the authentication level, it executes progressive security processing actions, from seamless access to blocking and isolation, achieving precise dynamic adaptation between security control intensity and real-time risk status.

[0167] Figure 5 Example 5 of the vehicle networking device security control method provided in this solution, such as Figure 5 As shown, based on the aforementioned embodiments, step S102 specifically includes:

[0168] S501: Create logically isolated virtual secure containers within a secure execution environment.

[0169] This step establishes an independent cryptographic execution environment within the vehicle's central control for IoT devices that lack hardware security capabilities. This environment is isolated from other devices and system components, enabling subsequent key generation and cryptographic operations to be performed within a protected space. This prevents interference between devices and lateral movement by potential attackers.

[0170] Specifically, before triggering the virtualization empowerment process, the vehicle's central hub has already completed an initial binding and negotiated a session key with the IoT device via an out-of-band channel. An out-of-band channel refers to an independent channel that bypasses the conventional communication path between the vehicle's central hub and the device. For example, this could be achieved by scanning a dynamic QR code displayed on the vehicle's infotainment screen using the device's accompanying mobile app, allowing the driver or other in-vehicle user to perform physical verification and ensure the authenticity of the device's identifier. The negotiated session key is used for subsequent encrypted communication between the vehicle's central hub and the device.

[0171] For IoT devices identified as lacking hardware security capabilities in S101, the vehicle hub triggers a virtualization empowerment process after completing an out-of-band initial binding and negotiating a session key with the device. The vehicle hub creates a virtual security container for the device within its secure execution environment.

[0172] A secure execution environment (TEE) is a trusted computing area within the vehicle's central control unit that possesses hardware-level security isolation capabilities. Specifically, it can be an isolated execution domain within the Hardware Security Module (HSM) or a secure partition within the TEE. A virtual secure container is a logically isolated instance within this TEE. Each container is logically independent, possessing its own independent memory space, key storage area, and execution context. Data or program errors within one container will not affect the normal operation of other containers. Strict boundary isolation is maintained between containers and between containers and the outside of the TEE through hardware-level access control mechanisms. A one-to-one correspondence is established between the container and the device; one container specifically serves one IoT device, ensuring the isolation of cryptographic resources between devices.

[0173] S502: Generate a unique temporary asymmetric key pair for IoT devices within a virtual secure container, where the private key never leaves the physical boundaries of the secure execution environment.

[0174] This step generates a pair of temporary asymmetric keys for the device inside an isolated container, giving the device cryptographic material that can be used for digital signatures and authentication, while preventing the risk of key leakage by permanently locking the private key inside a secure execution environment.

[0175] Specifically, after the virtual secure container is created, the vehicle's central control system generates a temporary asymmetric key pair for the IoT device inside the container, containing a temporary public key and a temporary private key. The key generation algorithm can employ elliptic curve cryptography to balance security strength and computational efficiency.

[0176] The entire key generation process is performed within the Secure Execution Environment (SEA). The temporary private key is permanently stored in the SEA's internal memory from the moment it is generated, never leaving the SEA's physical boundaries in any form (plaintext or encrypted). This means that even if an attacker gains root access to the vehicle's central operating system through a software vulnerability, they cannot read or export any device's temporary private key, because the private key never appears in memory or storage outside the SEA. Temporary key pairs are bound to the device and its corresponding virtual secure container. Each device's key pair is logically isolated from others; a container's private key cannot be accessed by other containers or external entities.

[0177] S503: Use the root private key of the vehicle hub to identify the IoT device, sign the temporary public key and authorization attributes, and generate a virtual certificate for the IoT device.

[0178] This step binds the device's identity information and temporary public key to the trusted root of the vehicle's central hub, enabling the device to obtain a virtual certificate endorsed by the vehicle's trusted root that can be independently verified by any external service domain, thereby establishing a verifiable cryptographic identity for the device.

[0179] Specifically, in S502, a temporary key pair for the device is generated. However, at this point, the external service domain cannot trust that the temporary public key truly belongs to the device because there is no pre-established trust relationship between the external service domain and the device. To solve this problem, the vehicle hub uses its own root private key to digitally sign the IoT device's device identifier, temporary public key, and authorization attributes, generating a virtual certificate for the device.

[0180] A virtual certificate contains at least a unique identifier for the device (indicating which device the certificate belongs to), a temporary public key (used to verify the correctness of all subsequent digital signatures on the device), and authorization attributes (defining the scope of operations that the device is allowed to perform). The root private key of the vehicle hub is a top-level trust anchor pre-set when the vehicle leaves the factory or is initialized, and is uniquely bound to the vehicle's identity.

[0181] After hashing the above information, the vehicle's central control system signs the hash value using the root private key and appends the signature to the certificate to form a complete virtual certificate. The entire signing process is completed within a secure execution environment. After the virtual certificate is generated, the vehicle's central control system encrypts it using the session key negotiated during the initial binding and sends it to the IoT device.

[0182] Optionally, the method further includes:

[0183] S504: The hash value of the data to be signed sent by the IoT device.

[0184] This step receives the data digest sent by the device that needs to be digitally signed, and initiates the proxy signing process, enabling the device to obtain a trusted digital signature result without accessing the private key.

[0185] Specifically, when an IoT device that has obtained a virtual certificate needs to send a signed message (e.g., to prove to an external service domain that the message indeed comes from the device), the IoT device first uses a hash algorithm to hash the original data to be signed, obtaining a fixed-length hash value. The IoT device then encrypts this hash value using the session key negotiated during the initial binding and sends it to the vehicle hub.

[0186] The reason IoT devices send only hash values ​​instead of the original data is that hash values ​​have a fixed length and are much shorter than the original data, effectively reducing communication overhead. In most digital signature algorithms, the signing operation itself involves encrypting the hash value of the data with a private key, thus pre-completing the hash operation and standard digital signature process on the device side. Furthermore, the original data may contain private or sensitive content, and not uploading it to the vehicle's central control system helps protect data privacy. After receiving the encrypted data, the vehicle's central control system uses the corresponding session key to decrypt it and reconstruct the hash value of the data to be signed.

[0187] S505: Routes the hash value to the virtual secure container.

[0188] This step directs the signature request to the virtual security container corresponding to the device based on the device's identity information, ensuring that the signature operation uses the correct temporary private key.

[0189] Specifically, the vehicle's central control extracts the unique identifier of the IoT device from the request and uses this identifier to locate and confirm the corresponding virtual secure container instance. Since each device is assigned a dedicated container in S501, and a temporary key pair bound to the device has been generated within that container in S502, the vehicle's central control knows exactly which container should handle the request upon receiving it. After confirming the target container, the vehicle's central control passes the hash value to that virtual secure container.

[0190] S506: The secure execution environment signs the hash value of the data to be signed using a temporary private key within a virtual secure container.

[0191] This step completes the digital signature operation on the device data, ensuring the non-repudiation and integrity of the signature result, provided that the private key never leaves the security boundary.

[0192] Specifically, after the hash value is passed into the corresponding virtual secure container, the secure execution environment of the vehicle's central control calls the cryptographic engine inside the container, uses the temporary private key stored in the container in S502 to perform a digital signature operation on the hash value, and outputs the signature result. The entire signature operation process is performed entirely within the secure execution environment, and the temporary private key does not leave the physical boundary of the secure execution environment throughout the entire process.

[0193] S507: Return the signature result to the IoT device.

[0194] This step returns the signature result to the device, enabling the device to obtain trusted signature data that can be used for external verification, thus completing the entire proxy signature process.

[0195] Specifically, the vehicle's central control unit encrypts the signature result generated in S506 using a session key and returns it to the requesting IoT device. Upon receiving the signature result, the device assembles it along with the original data and sends it to the target external service domain. Upon receiving the data packet, the external service domain first verifies the signature using the temporary public key in the virtual certificate issued in S503, and then further verifies whether the signature in the virtual certificate itself was issued by a trusted vehicle root private key. Once both verifications pass, the external service domain can confirm that the data indeed originated from the device and has not been tampered with.

[0196] The vehicle-to-everything (V2X) device security control method provided in this application creates a logically isolated virtual security container within a secure execution environment. Within this virtual security container, a dedicated temporary asymmetric key pair is generated for the IoT device. The private key never leaves the physical boundary of the secure execution environment. The root private key of the vehicle's central hub is used to sign the device identifier of the IoT device, the temporary public key, and the authorization attributes, generating a virtual certificate for the IoT device. The method receives the hash value of the data to be signed from the IoT device, routes the hash value to the virtual security container, and the secure execution environment uses the temporary private key within the virtual security container to sign the hash value of the data to be signed. The signing result is then returned to the IoT device. This method establishes a dedicated hardware-isolated virtual container for IoT devices lacking hardware security capabilities, generates a temporary key pair that cannot leave the environment, and issues a virtual certificate that can be independently verified externally using the vehicle's root private key. Simultaneously, a proxy signature mechanism enables the device to complete trusted digital signatures without accessing the private key. Therefore, without modifying the device's hardware, a fully verifiable cryptographic identity and hardware-level key protection capability are established for the device.

[0197] Optionally, the method further includes: initial binding of the device identifier with the IoT device via an out-of-band channel and negotiation of a session key.

[0198] Before the device officially enters the virtualization empowerment process, a physical verification method independent of the conventional communication path is used to ensure that the device's identity is legitimate and physically exists. A shared session key is also established for all subsequent encrypted communication between the vehicle hub and the device to prevent man-in-the-middle attacks and replay attacks.

[0199] This step occurs after the S101 device is identified and before the S501 creates the virtual container. After the vehicle hub performs a preliminary verification of the device's legitimacy, it initiates the out-of-band binding process. The out-of-band channel refers to an independent channel that does not pass through the regular communication path between the vehicle hub and the device. Its core function is that even if the regular communication link between the device and the vehicle hub is eavesdropped or hijacked by an attacker, the confirmation behavior on the out-of-band channel remains unaffected, and attackers cannot forge or interfere with it.

[0200] Specifically, when the vehicle's central control system confirms that an IoT device lacks hardware security capabilities, it generates a dynamic QR code on the vehicle's infotainment screen. This QR code contains the session identifier for this binding, the vehicle's central control system's temporary public key, and a one-time random number. The user scans this QR code using the device's accompanying mobile app. During the scanning process, the app verifies the device's hardware identifier (such as the device serial number or MAC address) and its own generated temporary public key through the physical act of scanning, and then uploads them to the vehicle's central control system via the mobile network. Upon receiving this information, the vehicle's central control system cross-references the device identifier uploaded by the app with the identifier reported by the device itself through the regular communication link. If they match, it indicates that the device is indeed physically present near the vehicle, and the user has verified its legitimacy via their mobile phone, confirming the authenticity of both parties' identities.

[0201] After identity verification, the vehicle hub and the device app (or the device itself) negotiate and generate a shared symmetric session key, denoted as Ks, based on their respective generated temporary public keys using a standard key exchange algorithm (such as elliptic curve Diffie-Hellman key exchange). This session key is used for all subsequent encrypted communication between the vehicle hub and the device, including the encrypted issuance of virtual certificates, the encrypted transmission of hash values ​​uploaded by the device, and the encrypted return of signature results.

[0202] The above operations establish the authenticity binding of the device identifier through an out-of-band physical verification channel (such as scanning a code) independent of the regular communication link, effectively preventing the device identity from being impersonated or forged; at the same time, a communication session key is negotiated and generated to provide encryption protection for all communication between the vehicle hub and the device, such as subsequent virtual certificate issuance and signature request transmission, ensuring the confidentiality and integrity of data during transmission and fundamentally eliminating man-in-the-middle attacks and replay attacks.

[0203] Optionally, the method also includes at least one auxiliary service among receiving threat intelligence synchronization, risk model updates, policy matrix updates, and cross-domain credential revocation status queries via cloud collaboration services;

[0204] Among them, the cloud-based collaborative service only provides auxiliary support when the network is connected, while the vehicle central hub independently executes safety control decisions when the network is interrupted.

[0205] When the vehicle is connected to the network, the computing and intelligence advantages of cloud services are used to provide the vehicle's central hub with enhanced capabilities such as threat intelligence synchronization and policy updates. At the same time, it is clear that the cloud only plays an auxiliary role, ensuring that the vehicle's central hub can still independently and completely execute all safety control decisions when the vehicle enters tunnels, underground garages, remote mountainous areas or other conditions where the network signal is poor or interrupted, thus meeting the stringent requirements of automotive-grade functional safety for continuity and reliability.

[0206] Specifically, the vehicle hub and cloud-based collaborative services establish a communication link via cellular networks or Wi-Fi. The cloud-based collaborative services are deployed in an enterprise private or public cloud environment, acting as an auxiliary node to provide four types of auxiliary services to the vehicle hub:

[0207] 1. Threat intelligence synchronization refers to the continuous collection of the latest threat intelligence (including new attack signatures, lists of malicious IP addresses, and information on known vulnerabilities) from the global security community, vulnerability databases, and OEM security operations centers in the cloud. When the vehicle is connected to the internet, the vehicle's central control system requests the latest incremental updates of threat intelligence from the cloud and supplements and adjusts the local security rule base accordingly.

[0208] 2. Risk model update refers to the continuous training and optimization of the anomaly detection model in the cloud using data aggregated from a large fleet of vehicles, generating updated model parameters and sending them to the vehicle central control system to improve the accuracy and generalization ability of the local anomaly detection model.

[0209] 3. Policy Matrix Update refers to the OEM security policy team remotely adjusting the authentication level mapping rules corresponding to each three-dimensional combination in the policy matrix, or adjusting the request sensitivity determination rules, based on new attack methods or changes in business needs. This updated information is then distributed to the vehicle central control system via the cloud. The updated content takes effect after being verified and signed by the vehicle central control system.

[0210] 4. Cross-domain credential revocation status query refers to the ability of an external service domain to query the cloud whether the cross-domain access credential presented by the device has been marked as revoked by the vehicle central hub when verifying the cross-domain access credential presented by the device (e.g., the credential is revoked in advance after the device is detected as a malicious device).

[0211] All of the aforementioned cloud-based collaborative services are explicitly defined as auxiliary in design. The vehicle central hub locally stores all the data required to execute all safety control decisions (including complete policy rules, risk models, device trust databases, vehicle status data, etc.). Cloud synchronization and updates only optimize and enhance the accuracy of local decisions, not serve as prerequisites for decision execution. When the vehicle is in a network outage state, the vehicle central hub can independently execute the entire process from device identification, virtualization empowerment, contextual risk perception, dynamic trust assessment to differentiated authorization without relying on any real-time cloud queries, ensuring that the continuity and real-time nature of safety control decisions are unaffected by network conditions.

[0212] In the context of vehicle connectivity, the aforementioned operations leverage cloud computing power and intelligence advantages to provide enhanced capabilities to the vehicle's central hub, such as threat intelligence synchronization, risk model updates, and remote optimization of the policy matrix. This enables security strategies to continuously evolve in response to new attack methods and changing business needs. More importantly, the cloud is explicitly positioned as a purely auxiliary role, while the vehicle's central hub retains all the data and rules required for decision-making locally. Even during network outages, it can still independently execute the complete security decision-making chain from access control to differentiated authorization, eliminating the strong dependence of traditional solutions on the cloud and meeting the stringent requirements of automotive-grade functional safety for continuity and reliability.

[0213] Optionally, the method further includes pushing and installing a device agent client to the IoT device. The device agent client is used to execute a lightweight agent protocol, which includes negotiating a session key, forwarding requests that require a secure execution environment agent signature, and receiving and applying at least one of a issued virtual certificate and a cross-domain credential.

[0214] Deploying a lightweight software agent for IoT devices standardizes and secures communication between the devices and the vehicle's central hub, enabling any type of IoT device (regardless of its operating system and hardware platform) to access the vehicle's central hub's security management system with extremely low development costs and adaptation workload, effectively lowering the barriers to entry for the connected vehicle ecosystem.

[0215] Specifically, the device agent client is a lightweight software agent that is pushed by the vehicle's central control system via OTA to IoT devices that have completed initial binding and established a trusted relationship. Upon receiving the push notification, the device automatically installs and launches the agent client. The agent client has a very small code size, its consumption of device storage and computing resources is negligible, and it can run on various resource-constrained IoT devices (such as low-power sensors, OBD diagnostic tools, etc.).

[0216] After the agent client is installed, a communication mechanism based on a lightweight agent protocol is established between it and the vehicle's central control system. This protocol includes the following functions:

[0217] 1. Negotiating the session key refers to the negotiation of the session key between the device and the vehicle central hub during the initial access phase. For devices with weak security, this negotiation process is combined with the key negotiation during the initial out-of-band binding; for devices that have obtained a virtual certificate, the agent client can trigger periodic updates of the session key in subsequent communications based on instructions from the vehicle central hub.

[0218] 2. Forwarding requests requiring secure execution environment proxy signatures refers to the process where, when a device needs to perform a digital signature operation, the proxy client is responsible for receiving the hash value of the data to be signed from the device's operating system or application, encapsulating it into a proxy protocol request message, encrypting it with the session key, sending it to the vehicle hub, and waiting for the signature result to be returned before delivering it to the device's application.

[0219] 3. Receiving and applying the issued virtual certificates and cross-domain credentials: After the vehicle central hub completes the issuance of virtual certificates or cross-domain credentials, it sends them to the device through the proxy protocol. The proxy client is responsible for receiving, decrypting, verifying the integrity of the credentials, storing them in the device's local secure storage area, and automatically retrieving the corresponding credentials and attaching them to the message when the device sends a signature message.

[0220] The introduction of the proxy client eliminates the need for devices to develop complex cryptographic logic and secure communication protocol stacks. All security-related complex operations are completed by the proxy client in collaboration with the vehicle's central control system. Device applications can obtain security services such as signing and encryption simply through local API calls, which greatly reduces the access cost and security adaptation workload of various IoT devices in the vehicle connectivity ecosystem.

[0221] The above operations standardize and protocolize the communication process and cryptographic operations between the device and the vehicle's central hub by pushing and installing a lightweight agent client to IoT devices. This allows various IoT devices, regardless of their operating system and hardware capabilities, to access the vehicle's central hub's security management system without the need to develop complex cryptographic logic and security protocol stacks. This effectively reduces the access development costs and adaptation workload for all parties in the vehicle connectivity ecosystem and solves the ecosystem access threshold problem caused by device heterogeneity in large-scale deployment scenarios.

[0222] The following will illustrate the specific implementation process of the present invention in detail with a complete user journey example covering multiple devices and scenarios. The background of the example includes:

[0223] Device A (weak security): Third-party OBD smart terminal. It lacks a security chip, connects via the OBD-II interface, and its functions include driving behavior recording and vehicle data reading.

[0224] Device B (weak security): Third-party in-vehicle smart device. It lacks a security chip, connects via Bluetooth, and supports environmental control functions such as climate adjustment.

[0225] Device C (High Security): Original factory integrated T-Box. Equipped with an SE security chip, responsible for core functions such as vehicle-to-cloud communication and remote control.

[0226] External service domain:

[0227] Domain X: UBI service platform for third-party insurance companies.

[0228] Domain Y: Third-party brand supercharging stations.

[0229] Specifically, it includes:

[0230] The vehicle's central control system detects a new device connection on the bus. The system initiates a security capability probe, sending a cryptographic challenge to the device (such as a request to sign a random number with an asymmetric key). Device A fails to respond and is classified as a weakly secure device.

[0231] The vehicle's central control screen prompts the user to scan a dynamic QR code using the device's accompanying mobile app to complete the binding process. After scanning, the app communicates with device A's cloud management platform via the internet, and the management platform then establishes a temporary out-of-band secure channel with the vehicle. Through this channel, the vehicle's central control system and device A complete lightweight key negotiation, generating a temporary symmetric session key. After successful binding, device A is marked as "Bound, Awaiting Enhancement" and granted an initial dynamic trust score of 50 points.

[0232] The vehicle central trigger device security capability virtualization module creates a logically isolated virtual security container for device A within the HSM. A temporary asymmetric key pair is generated within the container; the private key exists only in the HSM's physical secure storage area and can never be exported.

[0233] HSM uses the vehicle's root private key to sign the unique identifier, temporary public key, and authorized attributes of device A, generating a virtual device certificate. The certificate is then encrypted using a session key and sent to device A's storage. Simultaneously, a proxy relationship is established; for subsequent operations requiring digital signatures, device A only needs to send the hash value of the data to be signed to the vehicle's central security proxy interface.

[0234] Thus, without changing its own hardware, device A has obtained a virtual identity endorsed by the vehicle's root key, verifiable by any external party that trusts the vehicle, and transparent remote signature capabilities implemented through the vehicle's HSM.

[0235] Repeat the above process, and out-of-band binding is completed with the assistance of Bluetooth, generating an independent symmetric key, virtual container, key pair and virtual certificate. The authorization attributes are limited to allowing reading of basic in-vehicle sensor data and performing environmental control operations.

[0236] Device C is equipped with an SE security chip, which can respond normally to asymmetric cryptographic challenges. The vehicle hub and device C perform two-way authentication based on a pre-set certificate. After successful authentication, an initial dynamic trust score of 80 points is granted, skipping the virtualization empowerment step.

[0237] During initial normal operation, the behavior-context fusion risk control engine establishes behavioral baselines for each device:

[0238] Device A: Requests to read standard OBD data once per second, with the target being within the standard diagnostic ID range, and this behavior continues while the vehicle is in motion.

[0239] Device B: Reports in-vehicle sensor data once per minute and sends control commands only when the vehicle is started and triggered by the user.

[0240] Device C: Maintains a heartbeat connection with the cloud and occasionally reads the vehicle location and door status.

[0241] Based on stable and normal behavior, the trust scores of devices A and B slowly increase. Device C maintains a high trust score.

[0242] Device A's firmware was tampered with by malware implanted through a third-party upgrade channel, attempting to launch a low-speed CAN bus scanning attack in preparation for the subsequent injection of malicious frames.

[0243] The risk control engine detected an abnormally high increase in the request flow of device A, requesting to read non-standard and wide-ranging CAN IDs at an abnormal frequency, including sensitive IDs related to the powertrain and body control. At the same time, the current context indicates that the vehicle is traveling on an urban expressway.

[0244] The rules engine triggered a pre-defined rule, classifying it as a high-risk event. The statistical model detected that the current request frequency deviated significantly from the established baseline. The risk control engine, considering both the rule trigger and the statistical deviation, executed a weighted deduction in the high-risk context of high-speed travel. Device A's trust score was drastically reduced from 58 points to 15 points within a short period.

[0245] The moment the trust score drops to the threshold, the next abnormal request from device A arrives at the policy scheduling module. The module obtains the triple input, queries the policy matrix, and triggers a decision. The vehicle's central control immediately discards all subsequent packets from device A at the routing level and cuts off its unnecessary power supply via the OBD interface power management (only retaining the status indicator). At the same time, visual warnings pop up on the instrument panel and the central control screen to alert the driver.

[0246] The entire detection, decision-making, isolation, and alarm closed loop is completed within milliseconds to seconds, requiring no user operation and no network connection.

[0247] It is worth emphasizing that when the trust value drops to 15 points, the policy module not only blocks the access request from device A, but also physically terminates the possibility of device A calling the virtual container proxy signature service by cutting off the power supply to the OBD interface. This means that even if malware from device A attempts to directly initiate a proxy signature request to the vehicle's central control system, the request cannot reach the central control system because it has been cut off at the underlying hardware power supply level.

[0248] This effect essentially reflects the reverse constraint that the differentiated authorization processing steps in the above embodiments place on the cryptographic proxy service of the virtual secure container. When the trust value is too low, the result of the authorization processing is not only to reject the current request, but also to directly terminate the operation of the container service by physically cutting off the power supply. When the trust value is restored, the cryptographic proxy capability of device A can be restored by powering on and rebuilding the container, thus forming a complete closed loop from capability granting to capability use, then to capability retrieval based on behavior, and finally to capability re-granting after repair.

[0249] After obtaining the firmware repair package from the device manufacturer, the vehicle owner initiates a device recovery request via the vehicle's infotainment system while the vehicle is stationary. The vehicle's central control system performs enhanced authentication, requiring the user to scan a dynamic QR code again using their mobile app to confirm their presence. Upon successful authentication, the central control system creates a new virtual container for device A, generates a new key pair, and issues a new virtual certificate, ensuring the old key becomes invalid and the device resumes normal operation.

[0250] The car owner purchased a UBI product from a third-party insurance company. The contract stipulated that the insurance company needed to obtain driving behavior data to calculate the premium discount.

[0251] At the beginning of each month, the vehicle hub's cross-domain credential manager checks the current dynamic trust score of device A. Once the trust score meets the requirements, the manager requests the HSM to issue a verifiable credential for device A, encapsulating driving behavior data within it. The vehicle hub then sends the credential to the insurance company's server via the cellular network of device C.

[0252] After receiving the credential, the insurance company's server retrieves the user's vehicle's public key from the trusted vehicle public key directory, verifies the credential signature, and confirms that the data report was officially issued by the user's vehicle central control system and has not been tampered with. The insurance company does not need to develop its own device anti-tampering solutions; it only needs to trust the vehicle manufacturer's root certificate.

[0253] Upon arrival at the supercharging station, the vehicle's central control system completes identity authentication with the charging pile via short-range communication. The user wishes to continue watching any content not yet completed in the car on the large screen in the charging station's lounge.

[0254] The vehicle's central system assesses the trust score of relevant devices and issues short-term, limited-access verifiable credentials. In areas with poor network connectivity in the charging station's underground parking garage, the edge server uses a locally pre-configured list of public keys for partner vehicle models to offline verify credential signing. Once verified, the server allows the device to access user-authorized content and display it on the main screen.

[0255] Users do not need to register an account, scan a code to log in, or perform any pairing operations at the charging station, achieving seamless cross-domain service continuation.

[0256] When the vehicle is connected to the network, it uploads the complete log of abnormal behavior events of device A and the new behavior baseline after repair to the cloud collaborative service.

[0257] After analyzing massive amounts of similar logs, the cloud service identifies emerging attack patterns, generates new risk control rules, and updates the strategy matrix. The updated rules are then pushed to fleets of vehicles of the same brand or model via the cloud, enabling collaborative security evolution.

[0258] Figure 6 A schematic diagram of the vehicle networking equipment security control device provided in this solution is shown below. Figure 6 As shown, the vehicle networking device safety control device 60 specifically includes:

[0259] Identification module 61 is used to identify the hardware security capabilities of IoT devices connected to the vehicle's central hub;

[0260] Module 62 is established to create a virtual security container corresponding to the IoT device in the secure execution environment of the vehicle hub if the IoT device does not have hardware security capabilities, and to use the virtual security container to proxy the cryptographic operations of the IoT device in order to establish a verifiable identity for the IoT device.

[0261] The acquisition module 63 is used to acquire the real-time operating status of the vehicle and determine the context risk level based on the real-time operating status.

[0262] The update module 64 is used to continuously monitor the behavior of IoT devices based on verifiable identities, and update the dynamic trust value of IoT devices according to the real-time behavior data obtained from the monitoring and the real-time operating status of the vehicle.

[0263] Execution module 65 is used to perform differentiated authorization processing on access requests from IoT devices based on dynamic trust values ​​and context risk levels.

[0264] Furthermore, the vehicle networking device safety control device 60 also includes:

[0265] The external access module 66 is used to issue a cross-domain access credential by the vehicle central hub based on the current dynamic trust value of the IoT device when the IoT device needs to access the external service domain of the vehicle. The cross-domain access credential is obtained by digitally signing the private key of the secure execution environment of the vehicle central hub.

[0266] Furthermore, the real-time operating status includes at least one of the following: vehicle motion status, vehicle control status, vehicle body status, environmental status, and communication status. The acquisition module 63 is specifically used for:

[0267] A basic risk score is set based on the vehicle's motion status;

[0268] The weighting coefficients are determined based on the vehicle control status and / or communication status, and the basic risk score is weighted and corrected to obtain the composite risk score.

[0269] The composite risk score is compared with a preset risk threshold to determine whether the contextual risk level is high, medium, or low.

[0270] Furthermore, update module 64, specifically for:

[0271] A rule engine is used to perform correlation analysis between real-time behavioral data and real-time operational status to obtain correlation analysis results.

[0272] An anomaly detection model is used to detect the deviation of real-time behavioral data from the historical behavioral baseline of IoT devices, and the deviation detection results are obtained.

[0273] Based on the correlation analysis results and deviation detection results, the dynamic trust value of IoT devices is updated comprehensively.

[0274] Furthermore, execution module 65 is specifically used for:

[0275] Get the request sensitivity of the access request;

[0276] Using dynamic trust value, context risk level, and request sensitivity as joint inputs, the system queries a preset strategy matrix to determine the corresponding authentication level. The strategy matrix is ​​used to define the authentication level corresponding to different combinations of dynamic trust value, context risk level, and request sensitivity.

[0277] Perform the corresponding security actions based on the authentication level.

[0278] Furthermore, the certification levels include at least one of direct release, rapid verification, enhanced certification, and immediate blocking;

[0279] Directly allowing access means permitting the access request to pass;

[0280] Quick Validation refers to valid short-term tokens for verifying IoT devices;

[0281] Enhanced authentication indicates that manual confirmation from the user is required;

[0282] Immediate blocking means denying the access request and triggering alerts and / or physical isolation.

[0283] Furthermore, module 62 is established, specifically for:

[0284] Create logically isolated virtual secure containers within a secure execution environment;

[0285] Generate exclusive temporary asymmetric key pairs for IoT devices within a virtual secure container, where the private key never leaves the physical boundary of the secure execution environment;

[0286] The root private key of the vehicle hub is used to identify the IoT device, and the temporary public key and authorization attributes are signed to generate a virtual certificate for the IoT device.

[0287] Furthermore, module 62 is specifically used for:

[0288] Receive the hash value of the data to be signed sent by the IoT device;

[0289] Route the hash value to the virtual secure container;

[0290] The secure execution environment uses a temporary private key within a virtual secure container to sign the hash value of the data to be signed.

[0291] The signature result is returned to the IoT device.

[0292] Furthermore, the vehicle networking device safety control device 60 also includes:

[0293] The granting module 67 is used to perform two-way authentication based on digital certificates if the IoT device has hardware security capabilities, and to grant an initial dynamic trust value to the IoT device after successful authentication.

[0294] Among them, the initial dynamic trust value of IoT devices with hardware security capabilities is higher than that of IoT devices without hardware security capabilities.

[0295] Furthermore, the vehicle networking device safety control device 60 also includes:

[0296] Binding module 68 is used to perform initial binding of device identifier with IoT device through out-of-band channel and negotiate session key.

[0297] Furthermore, the vehicle networking device safety control device 60 also includes:

[0298] The receiving module 69 is used to receive at least one auxiliary service among threat intelligence synchronization, risk model update, policy matrix update and cross-domain credential revocation status query through cloud collaboration services;

[0299] Among them, the cloud-based collaborative service only provides auxiliary support when the network is connected, while the vehicle central hub independently executes safety control decisions when the network is interrupted.

[0300] Furthermore, the vehicle networking device safety control device 60 also includes:

[0301] The push module 610 is used to push the device agent client to IoT devices. The device agent client is used to execute a lightweight agent protocol. The lightweight agent protocol includes negotiating session keys, forwarding requests that require a secure execution environment agent signature, receiving and applying at least one of the issued virtual certificates and cross-domain credentials.

[0302] Figure 7 The schematic diagram of the vehicle's central structure provided for this solution is as follows: Figure 7 As shown, the vehicle central hub 70 includes a storage unit 71 and a processing unit 72;

[0303] Storage unit 71 stores computer-executed instructions;

[0304] The processing unit 72 executes the computer execution instructions stored in the storage unit 71 to implement the methods provided in the above embodiments.

[0305] Optionally, the vehicle hub 70 also includes a communication component 73. The processing unit 72 and the communication component 73 are connected via a bus 74.

[0306] In a specific implementation, at least one processing unit 72 executes computer execution instructions stored in the storage unit 71, causing at least one processing unit 72 to perform the above-described method.

[0307] The specific implementation process of the processing unit 72 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0308] In the above embodiments, it should be understood that the processing unit can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as execution by the hardware processing unit, or execution by a combination of hardware and software modules within the processing unit.

[0309] The storage unit may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0310] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0311] This application also provides a computer program product, including a computer program that, when executed by a processing unit, implements the above-described method.

[0312] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processing unit, implement the above-described method.

[0313] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0314] An exemplary readable storage medium is coupled to a processing unit, enabling the processing unit to read information from and write information to the readable storage medium. Alternatively, the readable storage medium can be an integral part of the processing unit. Both the processing unit and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processing unit and the readable storage medium can exist as discrete components within the device.

[0315] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0316] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0317] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0318] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0319] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0320] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A security control method for vehicle networking devices, characterized in that, The method, applied to a vehicle central control unit deployed on a vehicle, includes: The hardware security capabilities of IoT devices connected to the vehicle's central hub are identified. If the IoT device does not have hardware security capabilities, a virtual security container corresponding to the IoT device is created in the secure execution environment of the vehicle hub, and the virtual security container is used to proxy the cryptographic operations of the IoT device to establish a verifiable identity for the IoT device. The real-time operating status of the vehicle is obtained, and the contextual risk level is determined based on the real-time operating status. Based on the verifiable identity, the IoT device is continuously monitored for behavior, and the dynamic trust value of the IoT device is updated according to the real-time behavior data obtained from the monitoring and the real-time operating status of the vehicle. Based on the dynamic trust value and the context risk level, differentiated authorization processing is performed on the access requests of the IoT device.

2. The method according to claim 1, characterized in that, The method further includes: When the IoT device needs to access the vehicle's external service domain, the vehicle's central hub issues a cross-domain access credential based on the IoT device's current dynamic trust value. This credential is then presented by the IoT device to the external service domain. The cross-domain access credential is obtained by digitally signing the private key of the vehicle's central hub's secure execution environment.

3. The method according to claim 1, characterized in that, The real-time operating status includes at least one of vehicle motion status, vehicle control status, vehicle body status, environmental status, and communication status. Determining the context risk level based on the real-time operating status includes: A basic risk score is set based on the vehicle's motion state; Based on the vehicle control status and / or the communication status, a weighting coefficient is determined, and the basic risk score is weighted and corrected to obtain a composite risk score. The composite risk score is compared with a preset risk threshold to determine whether the contextual risk level is high risk, medium risk, or low risk.

4. The method according to claim 1, characterized in that, The step of updating the dynamic trust value of the IoT device based on real-time behavioral data obtained from monitoring and the real-time operating status of the vehicle includes: A rule engine is used to perform correlation analysis between the real-time behavioral data and the real-time operating status to obtain the correlation analysis results. An anomaly detection model is used to detect the deviation of the real-time behavior data from the historical behavior baseline of the IoT device, and the deviation detection result is obtained. Based on the correlation analysis results and the deviation detection results, the dynamic trust value of the IoT device is updated comprehensively.

5. The method according to claim 1, characterized in that, The step of performing differentiated authorization processing on access requests to the IoT device based on the dynamic trust value and the context risk level includes: Obtain the request sensitivity of the access request; Using the dynamic trust value, the context risk level, and the request sensitivity as joint inputs, a preset strategy matrix is ​​queried to determine the corresponding authentication level. The strategy matrix is ​​used to define the authentication level corresponding to different combinations of dynamic trust value, context risk level, and request sensitivity. Perform the corresponding security processing actions based on the authentication level.

6. The method according to claim 5, characterized in that, The authentication level includes at least one of direct access, fast verification, enhanced authentication, and immediate blocking; The direct passage means that the access request is allowed to pass; The rapid verification refers to verifying a short-term valid token for the IoT device; The enhanced authentication indicates that the user is required to manually confirm. The immediate blocking means rejecting the access request and triggering an alarm and / or physical isolation.

7. The method according to claim 1, characterized in that, The step of creating a virtual secure container corresponding to the IoT device within the secure execution environment of the vehicle's central hub, and using the virtual secure container to proxy the cryptographic operations of the IoT device, includes: Create the logically isolated virtual security container within the secure execution environment; Within the virtual secure container, a unique temporary asymmetric key pair is generated for the IoT device, wherein the private key never leaves the physical boundary of the secure execution environment; Using the root private key of the vehicle hub, the device identifier of the IoT device is signed with the temporary public key and the authorization attributes to generate a virtual certificate for the IoT device.

8. The method according to claim 7, characterized in that, The method further includes: Receive the hash value of the data to be signed sent by the IoT device; The hash value is routed to the virtual security container; The secure execution environment uses a temporary private key within the virtual secure container to sign the hash value of the data to be signed; The signature result is returned to the IoT device.

9. The method according to claim 1, characterized in that, The method further includes: If the IoT device has hardware security capabilities, then perform two-way authentication based on digital certificates, and grant an initial dynamic trust value to the IoT device after successful authentication; Among them, the initial dynamic trust value of IoT devices with hardware security capabilities is higher than that of IoT devices without hardware security capabilities.

10. The method according to claim 1, characterized in that, Before creating a virtual security container corresponding to the IoT device within the security execution environment of the vehicle hub, the method further includes: The device identifier is initially bound to the IoT device via an out-of-band channel, and a session key is negotiated.

11. The method according to claim 1, characterized in that, The method further includes: Receive at least one of the following auxiliary services through cloud-based collaborative services: threat intelligence synchronization, risk model updates, policy matrix updates, and cross-domain credential revocation status queries; The cloud-based collaborative service provides auxiliary support only when the network is connected, while the vehicle central control system independently executes safety control decisions when the network is interrupted.

12. The method according to claim 1, characterized in that, The method further includes: A device agent client is pushed and installed to the IoT device. The device agent client is used to execute a lightweight agent protocol, which includes negotiating a session key, forwarding requests that require a secure execution environment agent signature, and receiving and applying at least one of a virtual certificate and a cross-domain credential.

13. A safety control device for vehicle networking equipment, characterized in that, include: The identification module is used to identify the hardware security capabilities of IoT devices connected to the vehicle's central hub. A module is established to create a virtual security container corresponding to the IoT device in the security execution environment of the vehicle hub if the IoT device does not have hardware security capabilities, and to use the virtual security container to proxy the cryptographic operations of the IoT device in order to establish the verifiable identity of the IoT device. The acquisition module is used to acquire the real-time operating status of the vehicle and determine the context risk level based on the real-time operating status. The update module is used to continuously monitor the behavior of the IoT device based on the verifiable identity, and update the dynamic trust value of the IoT device according to the real-time behavior data obtained from the monitoring and the real-time operating status of the vehicle. The execution module is used to perform differentiated authorization processing on the access request of the IoT device based on the dynamic trust value and the context risk level.

14. A vehicle central control unit, characterized in that, include: Storage unit, processing unit; The storage unit stores computer-executed instructions; The processing unit executes the computer execution instructions stored in the storage unit to implement the method as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by the processing unit, are used to implement the method as described in any one of claims 1 to 12.

Images