Multi-tenant full-link data security isolation management and control system and method

Abstract

This invention discloses a multi-tenant end-to-end data security isolation and control system and method, belonging to the field of vehicle network data security. It aims to solve the problems of easy data crosstalk, discontinuous isolation, unreliable trust benchmarks, and difficulty in compliance traceability in multi-tenant scenarios. The system generates a tenant root identifier (TID) for vehicle enterprise tenants, which, together with the device sub-identifier (DID), forms a tenant identifier chain. This chain is synchronized with a trusted authentication center to establish a vehicle-cloud hardware-level trust root. When the vehicle terminal accesses the system, it completes two-way identity authentication and allocates a dedicated message queue telemetry transmission MQTT topic partition and access permissions according to the TID. The terminal collects time-series vehicle control data and generates encrypted data frames with intrinsic identifiers and checksums for uploading. The access gateway performs dual isolation verification before transparent transmission. Data is forwarded to an independent logical storage partition for isolated storage according to the TID. This invention achieves strong hardware-level isolation, real-time verification, and full traceability throughout the entire end-to-cloud chain, effectively preventing cross-tenant data leakage.

Description

Technical Field

[0001] This invention relates to the field of vehicle network data security technology, and more specifically to a multi-tenant end-to-end data security isolation and control system and method. Background Technology

[0002] With the rapid development of vehicle-to-everything (V2X) technology, an increasing number of automotive tenants rely on V2X ecosystem service platforms to collect, transmit, store, and compute vehicle data, forming a multi-tenant V2X ecosystem. Streaming time-series vehicle control data, as core data for V2X services, contains sensitive information such as vehicle operating status and driving behavior. Its secure isolation and reliable management directly affect the core interests and data security compliance requirements of automotive tenants. However, in current multi-tenant V2X scenarios, the isolation and management of data throughout its entire lifecycle faces numerous challenges. During the generation, transfer, and processing of vehicle data from different tenants at the device side and platform side, issues such as data crosstalk and unauthorized access can easily occur, increasing the risk of tenant data leakage. Simultaneously, existing data isolation and management models struggle to achieve continuous and reliable management across the entire chain, failing to meet the full lifecycle traceability requirements for V2X data security compliance, thus hindering the healthy development of the multi-tenant V2X ecosystem. How to achieve secure isolation and reliable management of multi-tenant data has become a critical issue urgently needing resolution in the current V2X technology field. Therefore, to overcome these limitations, this invention proposes a multi-tenant end-to-end data security isolation and management system and method. Summary of the Invention

[0003] To address the shortcomings of existing technologies, the present invention aims to provide a multi-tenant end-to-end data security isolation and management system and method, which solves the technical problems of high difficulty in secure isolation and reliable management of multi-tenant streaming time-series vehicle control data throughout its entire lifecycle of acquisition, transmission, storage, and computation at the end-user side in the context of vehicle networking, and the susceptibility to data crosstalk, unauthorized access, and leakage.

[0004] To achieve the above objectives, the present invention provides the following technical solution:

[0005] Multi-tenant end-to-end data security isolation and control methods include:

[0006] The vehicle-to-everything (V2X) ecosystem service platform generates TIDs for vehicle enterprise tenants and DIDs for each vehicle under the corresponding vehicle enterprise tenant, thereby generating a tenant identification chain and solidifying it in the secure storage area of ​​the in-vehicle SE; and synchronizes it to the trusted authentication center of the V2X ecosystem service platform to establish a trust root for the entire vehicle-cloud link;

[0007] In response to the access request initiated by the vehicle terminal, the Trusted Authentication Center completes two-way identity authentication with the vehicle terminal through the vehicle SE. If the authentication is successful, it dynamically allocates an MQTT topic partition and transmission queue bound to the TID for the vehicle terminal based on the TID in the tenant identifier chain, and configures access control rules.

[0008] In response to the data acquisition command, the vehicle terminal acquires streaming time-series vehicle control data and performs fragmentation processing to generate time-series data fragments; combined with the tenant identifier chain, it generates an endogenous identifier data frame that embeds the time-series data fragment frame header, and at the same time generates a cyclic redundancy check code to be appended to the frame tail of the endogenous identifier data frame, and after encryption, it is sent to the vehicle network ecosystem service platform through MQTT topic partition.

[0009] The access gateway of the vehicle-to-everything (V2X) ecosystem service platform receives the endogenous identification data frame sent by the vehicle terminal, performs dual isolation verification, and if the verification passes, it transmits the endogenous identification data frame to the time-series data processing node.

[0010] The endogenous identifier data frame is forwarded to the logical storage partition of the time-series database corresponding to the TID for data compression, storage and index construction;

[0011] In response to a tenant's request for a streaming time-series vehicle control data computation task, the system automatically anchors to the logical storage partition corresponding to the TID, allows reading the intrinsic identifier data frame of the logical storage partition for executing the computation task, performs three identity validity checks during the computation process, and writes the computation result into the computation result subpartition within the logical storage partition.

[0012] Specifically, the steps to establish a vehicle-cloud end-to-end trust root include:

[0013] In response to the vehicle mass production pre-configuration requirements submitted by vehicle manufacturers, a TID is generated for the corresponding vehicle manufacturer. The encoding rules of the TID include the vehicle manufacturer's identity code, compliance filing code and random check code.

[0014] For each vehicle under the corresponding car manufacturer tenant, a DID is generated that is uniquely bound to the VIN. The encoding rules of the DID include the prefix field of the corresponding TID, the irreversible hash field of the vehicle VIN, and the device type code.

[0015] Based on the preset hierarchical combination rules, the corresponding TID and the DID of the vehicle under that TID are combined to form a tenant identifier chain. At the same time, an asymmetric encryption key pair is generated for the tenant identifier chain. The private key in the asymmetric encryption key pair is bound and stored with the tenant identifier chain, and the public key is synchronized to the trusted authentication center of the vehicle network ecosystem service platform as the identity authentication credential of the tenant identifier chain.

[0016] The tenant identifier chain and the corresponding bound private key are written into the secure storage area inside the vehicle SE through the secure programming interface of the vehicle SE.

[0017] The public key of the tenant identifier chain, the hierarchical binding relationship between TID and DID, and the preset hierarchical combination rules of the tenant identifier chain are synchronized to the trusted authentication center of the vehicle-to-the-cloud ecosystem service platform for encrypted storage; a trust root credential corresponding to the tenant identifier chain is generated to complete the establishment of the vehicle-cloud full-link trust root.

[0018] Specifically, the steps for dynamically allocating MQTT topic partitions and transmission queues bound to TIDs for the vehicle terminal, and configuring access control rules, include:

[0019] The access gateway of the vehicle-to-everything (V2X) ecosystem service platform receives access requests initiated by vehicle terminals and forwards them to the trusted authentication center of the V2X ecosystem service platform.

[0020] After receiving the access request, the Trusted Authentication Center uses the vehicle-cloud end-to-end trust root as the verification basis and the tenant identifier chain as the authentication credential to initiate two-way identity authentication with the vehicle SE. The two-way identity authentication includes the cloud's authentication of the vehicle terminal's identity legitimacy and the vehicle terminal's authentication of the cloud's Trusted Authentication Center's platform identity legitimacy.

[0021] After the trusted authentication center completes two-way identity authentication, if the authentication result is unsuccessful, it sends an access rejection command to the access gateway.

[0022] If the authentication result is successful, an access permission instruction and the TID information to which the corresponding vehicle terminal belongs are sent to the access gateway. The access gateway dynamically allocates an MQTT topic partition and transmission queue bound to the TID for the vehicle terminal based on the corresponding TID.

[0023] The access gateway automatically generates and configures access control rules for the allocated MQTT topic partitions, and synchronizes the binding relationship between the MQTT topic partitions and TIDs, as well as the corresponding access control rules, to each functional node of the vehicle-to-everything (V2X) ecosystem service platform.

[0024] Specifically, the MQTT topic partition and transmission queue are used to carry the end-to-cloud uplink transmission of streaming time-series vehicle control data collected by the vehicle terminal, as well as the cloud-to-end downlink transmission of vehicle control commands and configuration information issued by the vehicle network ecosystem service platform to the vehicle terminal. It serves as the only data transmission channel between the vehicle terminal and the vehicle network ecosystem service platform that is bound to the corresponding TID.

[0025] Specifically, access control rules refer to the access control rules formulated for MQTT topic partitions and effective on the vehicle-to-everything (V2X) ecosystem service platform. These rules include: clearly defining the scope of legitimate access subjects, clearly defining the permission boundaries of legitimate operations, and clearly defining absolutely prohibited access behaviors. They are used to perform real-time permission verification on all access behaviors of MQTT topic partitions.

[0026] Specifically, by combining the tenant identifier chain, an endogenous identifier data frame is generated that embeds the time-series data fragment frame header. Simultaneously, a cyclic redundancy check (CRC) code is generated and appended to the end of the endogenous identifier data frame. After encryption, it is sent to the vehicle-to-everything (V2X) ecosystem service platform via MQTT topic partitioning, including:

[0027] The irreversible hash verification value of the tenant identifier chain embedded in the vehicle SE is embedded in a fixed reserved position in the frame header of each time-series data segment to form an endogenous identifier data frame structure.

[0028] Based on the irreversible hash check value of the tenant identifier chain and the plaintext content of the corresponding time-series data fragment, a cyclic redundancy check code covering the identity identifier and the full data is generated, and the cyclic redundancy check code is appended to a fixed position at the end of the endogenous identifier data frame.

[0029] After encrypting the irreversible hash check value of the tenant identifier chain in the header of the endogenous identifier data frame, a compliance check is performed. If the compliance check passes, it is sent to the vehicle network ecosystem service platform through the MQTT topic partition associated with the corresponding TID.

[0030] Specifically, the dual isolation verification includes channel attribution verification and identity legitimacy verification;

[0031] Channel attribution verification includes: determining whether the MQTT topic partition receiving the intrinsically identified data frame has been bound to the corresponding TID, and whether the access control rules of the MQTT topic partition are in a normal effective state;

[0032] The identity legitimacy verification includes: extracting the irreversible hash check value of the tenant identifier chain encrypted in the frame header of the endogenous identifier data frame and the cyclic redundancy check code in the frame tail; decrypting the irreversible hash check value of the tenant identifier chain encrypted in the frame header; if the decryption is successful, after obtaining the irreversible hash check value of the tenant identifier chain, recalculating the cyclic redundancy check code based on the irreversible hash check value and the full plaintext content of the endogenous identifier data frame, and comparing it with the cyclic redundancy check code in the frame tail.

[0033] Specifically, the time-series data processing node refers to the functional node on the vehicle-to-everything (V2X) ecosystem service platform side used to receive, temporarily store, and preprocess streaming time-series vehicle control data, and used to receive the endogenous identifier data frames transmitted through the access gateway.

[0034] Specifically, logical storage partitioning refers to the independent storage units pre-created by the time-series database of the vehicle-to-everything (V2X) ecosystem service platform based on the TID of each tenant, which are used to store all streaming time-series vehicle control data belonging to the corresponding TID.

[0035] The time-series database refers to the database used by the vehicle-to-everything (V2X) ecosystem service platform to store streaming time-series vehicle control data. The storage engine layer of the time-series database is configured with ACLs corresponding to TIDs to prohibit access operations across logical storage partitions of TIDs. The logical storage partitions are configured with independent data lifecycle management, backup, and destruction rules.

[0036] Specifically, the steps for performing a computational task include:

[0037] The streaming computing engine of the vehicle-to-everything (V2X) ecosystem service platform pre-establishes a computing task thread pool for each tenant's TID, and configures CPU and memory resource quotas for the computing task thread pool, and divides the computing cache space and memory space.

[0038] The streaming computing engine responds to the streaming time-series vehicle control data computing task request initiated by the vehicle enterprise tenant, verifies the TID authorization status of the requesting tenant, and if the verification passes, binds the computing task to the TID of the requesting tenant.

[0039] The streaming computing engine allocates a thread pool for computing tasks bound to a TID, automatically anchors the logical storage partition corresponding to the TID, and allows reading the endogenous identifier data frame in the logical storage partition anchored to the TID.

[0040] After the computing task starts, the streaming computing engine reads the endogenous identifier data frame that meets the requirements of the computing task from the logical storage partition corresponding to the anchored TID, performs standardized computing operations, and performs three identity legality checks in the standardized computing operations to obtain the computing results.

[0041] The streaming computing engine appends a frame structure with the same format as the intrinsic identifier data frame to the calculation result bound to the TID. Based on the TID hash value and the full content of the calculation result, a cyclic redundancy check code is generated and appended to a fixed position at the end of the frame to form the result data frame, which is then written to the calculation result sub-partition in the logical storage partition corresponding to the TID.

[0042] Specifically, standardized computational operations include computational preprocessing operations and computational logic operations;

[0043] Three identity verifications are performed in standardized calculation operations, including:

[0044] Before the computation preprocessing operation, the first identity legality verification is performed to verify that the TID of the read endogenous identifier data frame matches the TID bound to the computation task.

[0045] During the computational preprocessing operation, a second identity legitimacy check is performed simultaneously to verify whether the endogenous identifier data frame has been tampered with during the reading and caching process.

[0046] After the computational logic operation process is completed, a third identity validity check is performed synchronously to verify whether the TID bound to the computation result, the TID bound to the computation task, and the TID corresponding to the logical storage partition are consistent.

[0047] The multi-tenant end-to-end data security isolation and control system includes a tenant pre-configuration module, an access authentication module, an end-side binding module, a transmission verification module, a storage isolation and control module, and a computing isolation and control module.

[0048] The tenant pre-configuration module is used to generate TIDs for car manufacturer tenants and DIDs for each vehicle under the corresponding car manufacturer tenant, thereby generating a tenant identification chain and solidifying it in the secure storage area of ​​the vehicle SE; and synchronized to the trusted authentication center of the vehicle network ecosystem service platform to establish a trust root for the entire vehicle-cloud link;

[0049] The access authentication module is used to respond to access requests initiated by the vehicle terminal. The trusted authentication center completes two-way identity authentication with the vehicle terminal through the vehicle SE. If the authentication is successful, it dynamically allocates MQTT topic partitions and transmission queues bound to the TID for the vehicle terminal based on the TID in the tenant identifier chain, and configures access control rules.

[0050] The end-side binding module is used to respond to data acquisition commands. The vehicle terminal collects streaming time-series vehicle control data and performs fragmentation processing to generate time-series data fragments. Combined with the tenant identifier chain, an endogenous identifier data frame with an embedded time-series data fragment frame header is generated. At the same time, a cyclic redundancy check code is generated and appended to the frame tail of the endogenous identifier data frame. After encryption, it is sent to the vehicle network ecosystem service platform through MQTT topic partition.

[0051] The transmission verification module is used to receive the endogenous identifier data frame sent by the vehicle terminal, perform double isolation verification, and if the verification passes, the endogenous identifier data frame is transparently transmitted to the timing data processing node.

[0052] The storage isolation and control module is used to forward endogenous identifier data frames to the logical storage partition of the time-series database corresponding to the TID for data compression, storage and index construction;

[0053] The computation isolation and control module is used to respond to the request for streaming time-series vehicle control data computation task initiated by the tenant, automatically anchor the logical storage partition corresponding to the TID, allow reading the endogenous identifier data frame of the logical storage partition for execution of computation tasks, and perform three identity legality checks during the computation process, and write the computation result into the computation result subpartition in the logical storage partition.

[0054] The beneficial effects of this invention are:

[0055] This application generates a unique TID and a vehicle-bound DID for vehicle enterprise tenants, forming a tenant identifier chain that is solidified in the vehicle SE and synchronized with a trusted authentication center to establish a vehicle-cloud end-to-end trust root. This effectively ensures the immutability and uniqueness of tenant identity identifiers, eliminating tenant identity forgery and identifier tampering at the root. By performing two-way identity authentication based on the trust root when the vehicle terminal accesses the system and dynamically allocating MQTT topic partitions and access control rules bound to the TID, tenant-specific isolation of the transmission channel is achieved, preventing cross-tenant data streaming and unauthorized access. Furthermore, by embedding the tenant identifier into the data frame header and appending a loop... Redundant verification codes enable an intrinsic binding between data and tenant identity, ensuring data traceability throughout its entire lifecycle while reducing edge computing overhead. Through dual isolation verification at the access gateway, logical storage partitioning of the time-series database by TID and configuration of ACLs, and allocation of independent thread pools by TID and execution of three identity verifications by the streaming computing engine, continuous isolation and control of the entire process of data transmission, storage, and computing are achieved. This effectively prevents cross-tenant data leakage, balances data security with the real-time performance of transmission and processing, meets the compliance audit requirements for the entire lifecycle of vehicle network data, and ensures the stable and healthy operation of the multi-tenant vehicle network ecosystem. Attached Figure Description

[0056] Figure 1 This is a flowchart of the multi-tenant end-to-end data security isolation and control method of the present invention;

[0057] Figure 2 This is a flowchart illustrating the process of establishing a vehicle-cloud end-to-end trust root in this invention.

[0058] Figure 3 This is a flowchart illustrating the dynamic allocation of MQTT topic partitions and transmission queues bound to TIDs in the vehicle terminal of this invention, and the configuration of access control rules.

[0059] Figure 4 This is a flowchart illustrating the computational task performed by the present invention. Detailed Implementation

[0060] Example 1

[0061] The multi-tenant end-to-end data security isolation and control method in this embodiment is applied to the vehicle-to-everything (V2X) ecosystem service platform. The V2X ecosystem service platform has a multi-tenant architecture, and the tenants served include at least car manufacturer tenants with vehicle data sovereignty and ecosystem service tenants that provide V2X value-added services. The vehicle terminal devices connected to the V2X ecosystem service platform are vehicle telematics units and intelligent cockpit domain controllers equipped with hardware security chips. The target data controlled by this method is streaming time-series vehicle control data collected at high frequency by the vehicle terminal devices. The streaming time-series vehicle control data includes at least vehicle CAN bus signal data, vehicle sensor data, vehicle real-time location data, and battery management system status data.

[0062] Because existing multi-tenant data isolation and control technologies for connected vehicle ecosystem service platforms directly reuse multi-tenant isolation solutions from general cloud computing or general IoT scenarios, they are not adapted to the inherent attributes of connected vehicle scenarios, such as streaming time-series vehicle control data terminals, continuous cloud-to-end flow, high frequency and high throughput, strong demand for low-latency services, and high sensitivity and high compliance requirements. They generally adopt a fragmented, piecemeal isolation mechanism with tenant identifiers added after the cloud. This not only fails to resolve the core contradiction between isolation security and business real-time performance, but also suffers from the lack of a unified hardware-level root of trust and a continuous verification benchmark for the entire chain. As a result, the isolation mechanisms at each stage are fragmented, single-point failures can easily lead to full-chain data leakage, and it is difficult to meet the requirements of automotive data security compliance. Therefore, this specific implementation provides the following technical solution.

[0063] Please see Figure 1 This embodiment introduces a multi-tenant end-to-end data security isolation and control method, including:

[0064] Step S1: In response to the vehicle manufacturer tenants' pre-installed vehicle mass production requirements, the vehicle-to-everything (V2X) ecosystem service platform generates a globally unique and non-repeatable Tenant ID (TID) for each corresponding V2X tenant, and generates a Device ID (DID) for each vehicle under the corresponding V2X tenant, which is uniquely bound to the Vehicle Identification Number (VIN). Based on the TID and DID, a tenant identifier chain is generated and solidified into the tamper-proof secure storage area of ​​the SE (SecureElement) through the secure burning interface of the vehicle's SE. The tenant identifier chain cannot be tampered with, stripped, or deleted by software throughout the vehicle's entire lifecycle. At the same time, the public key information of the tenant identifier chain and the binding relationship between TID and DID are synchronized to the trusted authentication center of the V2X ecosystem service platform to establish a vehicle-cloud end-to-end trust root. This provides a unique and tamper-proof verification benchmark for subsequent end-to-end isolation and control, fundamentally solving the defects of existing technologies such as post-attached tenant identifiers, easy tampering, and lack of a unified trust benchmark.

[0065] In this embodiment, the tenant identifier chain refers to a unique identity sequence formed by combining the TID of the corresponding vehicle manufacturer tenant with the DID of the vehicle ordered by that tenant according to a preset hierarchical rule. As the only continuously verifiable dual identity benchmark for both tenant and vehicle during the vehicle-to-cloud end-to-end data flow, it differs from the separate tenant ID or device ID used in existing technologies, and can simultaneously meet the dual requirements of tenant-level isolation and device-level identity traceability. The vehicle-to-cloud end-to-end trust root refers to the end-to-end trust starting point jointly recognized by the trusted authentication center of the vehicle network ecosystem service platform and the vehicle terminal, using the immutable secure storage area of ​​the vehicle SE as the hardware carrier and the solidified tenant identifier chain as the core trust credential. Unlike the software-generated trust root in existing technologies, the core trust credential of this vehicle-to-cloud end-to-end trust root cannot be tampered with, stripped, or deleted by software throughout the vehicle's entire lifecycle. It can serve as the unique and irreversible trust benchmark for verifying the isolation status of each link in the subsequent end-to-end, ensuring the consistency and authority of the end-to-end isolation rules.

[0066] Please see Figure 2 In one implementation, the specific steps for establishing a vehicle-cloud end-to-end trust root include:

[0067] In response to vehicle production pre-configuration requests submitted by vehicular tenants, the connected vehicle ecosystem service platform generates globally unique and non-repeatable TIDs for each tenant. The TID encoding rules include the tenant's identity code, compliance filing code, and random check code, ensuring that the TID remains unique and conflict-free throughout its entire lifecycle on the connected vehicle ecosystem service platform. Vehicle production pre-configuration requests refer to formal business requests submitted by vehicular tenants to the connected vehicle ecosystem service platform during the pre-configuration phase before their mass-produced vehicles roll off the production line. These requests are used to complete the confirmation of vehicle tenant ownership, pre-configuration of in-vehicle safety credentials, and activation of connected vehicle access permissions. Vehicle production pre-configuration requests include the tenant's compliance operating qualification documents, vehicle access filing information from the Ministry of Industry and Information Technology, a list of unique vehicle identification codes for vehicles to be mass-produced, the unique hardware serial number of the in-vehicle security chip, and authorization documents for secure flashing operations.

[0068] The vehicle-to-everything (V2X) ecosystem service platform generates a DID that is uniquely bound to the VIN for each vehicle under the corresponding vehicle manufacturer tenant. The encoding rules of the DID include the prefix field of the corresponding TID, the irreversible hash field of the vehicle VIN, and the device type code, ensuring that the DID of a single vehicle is strongly associated with the corresponding TID and cannot be separated.

[0069] The vehicle-to-everything (V2X) ecosystem service platform, based on preset hierarchical combination rules, combines the corresponding TID with the DID of the vehicle under that TID to form a tenant identifier chain. Simultaneously, it generates a matching asymmetric encryption key pair for this tenant identifier chain. The private key in the asymmetric encryption key pair is bound and stored with the tenant identifier chain, while the public key serves as the identity authentication credential of the tenant identifier chain and is synchronized to the trusted authentication center of the V2X ecosystem service platform. The preset hierarchical combination rules refer to standardized coding combination rules established to achieve the binding of TID and DID. These standardized coding combination rules specify that the tenant identifier chain adopts a fixed hierarchical structure of root identifier segment, fixed separator, sub-identifier segments, and tail check segment. The root identifier segment is the TID, the sub-identifier segments are the DIDs, the fixed separator uses a non-printable special character uniformly used across the entire V2X ecosystem service platform, and the tail check segment is the irreversible hash check value of the combined content of the root identifier segment and the sub-identifier segments. This ensures that the hierarchical structure of the tenant identifier chain can be quickly identified by all nodes in the entire chain without full parsing, while also guaranteeing that the identifier chain is tamper-proof, indivisible, and that the hierarchical binding relationship is not broken. For example, a car manufacturer's tenant has a TID of QC10086CN001, and the corresponding DID for a single vehicle is QC10086CN001-LS9876543210ABCDEF-01. According to the preset hierarchical combination rules, the generated tenant identifier chain is as follows:

[0070] QC10086CN001|QC10086CN001-LS9876543210ABCDEF-01|A1B2C3D4E5F67890, where | is a fixed separator uniform across the entire network, and A1B2C3D4E5F67890 is the irreversible hash check value of the combined content of the root identifier segment and the child identifier segment.

[0071] The vehicle-to-everything (V2X) ecosystem service platform writes the tenant identifier chain and the corresponding bound private key into the tamper-proof secure storage area inside the vehicle SE through the secure burning interface of the vehicle SE. After the writing operation is completed, a readback verification is performed immediately to confirm that the written content is completely consistent with the preset tenant identifier chain. After the verification is passed, the software write permission of the secure storage area is locked, and the identifier reading operation can only be completed through the hardware secure channel of the vehicle SE, ensuring that the tenant identifier chain cannot be tampered with, stripped or deleted by software throughout the entire life cycle of the vehicle.

[0072] The vehicle-to-everything (V2X) ecosystem service platform synchronizes the public key of the corresponding tenant identifier chain, the hierarchical binding relationship between TID and DID, and the preset hierarchical combination rules of the tenant identifier chain to the trusted authentication center of the V2X ecosystem service platform for encrypted storage. After the trusted authentication center completes the integrity verification and identity confirmation verification of the synchronized information, it generates a trust root credential that uniquely corresponds to the tenant identifier chain, establishes a unique mapping relationship between the tenant identifier chain fixed on the vehicle and the trusted authentication center in the cloud, completes the establishment of the vehicle-cloud full-link trust root, and provides a unique and tamper-proof verification benchmark for subsequent full-link isolation and control.

[0073] Step S2: In response to the access request from the vehicle-mounted terminal to the vehicle-to-everything (V2X) ecosystem service platform, the access gateway of the V2X ecosystem service platform first forwards the access request to the trusted authentication center. The trusted authentication center completes two-way identity authentication with the vehicle-mounted terminal through the vehicle-mounted SE, verifying whether the irreversible hash checksum of the tenant identifier chain uploaded by the vehicle-mounted terminal matches the pre-stored public key information. If the authentication fails, the trusted authentication center directly rejects the access request of the vehicle-mounted terminal through the access gateway, and generates an illegal access alarm record. If the authentication succeeds, the access gateway dynamically allocates an MQTT (Message Queuing Telemetry) bound to the TID for the vehicle-mounted terminal based on the TID in the tenant identifier chain. Transport (message queue telemetry transport) topic partitions and transport queues, while automatically generating and configuring access control rules: only the vehicle terminal to which the TID belongs and the authorized service node on the platform side have the publishing and subscription permissions for the topic partition, and cross-TID topic partition access operations are permanently prohibited; at the same time, the binding relationship between topic partitions and TIDs is synchronized to all functional nodes in the entire link on the vehicle network ecosystem service platform side, so as to realize the continuous transmission of tenant isolation rules from the end side to the platform side, providing lightweight isolation protection for the transmission link of streaming time-series vehicle control data, and solving the problems of permission vulnerabilities and disconnection between isolation rules and tenant identities that are prone to occur in the static Topic configuration of existing technologies.

[0074] In this embodiment, the vehicle terminal refers to an embedded hardware device equipped with a vehicle SE, possessing cellular vehicle-to-everything (V2X) wireless communication capabilities, and capable of collecting vehicle status data and performing two-way data interaction between the vehicle and the cloud. It serves as the end-side acquisition entity for streaming time-series vehicle control data, the hardware storage carrier for the tenant identifier chain, and the end-side execution node for the vehicle-to-cloud communication link. It is uniquely bound to the corresponding vehicle's VIN throughout the vehicle's entire lifecycle and cannot be reused across vehicles. It includes embedded hardware units with V2X communication and data acquisition capabilities in the vehicle telematics unit equipped with a vehicle SE, the intelligent cockpit domain controller, the vehicle central gateway controller, and the autonomous driving domain controller. The MQTT topic partition refers to a message transmission topic partition dynamically generated based on the corresponding vehicle manufacturer's tenant's TID and bound to the TID. The naming rules of the topic partition include a unique encoded field of the corresponding TID, forming a unique mapping relationship with the tenant's identity. Unlike the statically configured general topics in the prior art, this tenant MQTT topic partition is bound to the tenant's identity, and the access permissions are deeply associated with the TID. It can achieve tenant-level data isolation from the transmission channel level, eliminating the risks of cross-tenant subscriptions and data crosstalk.

[0075] Please see Figure 3 In one embodiment, the specific steps for dynamically allocating MQTT topic partitions and transmission queues bound to TIDs for the vehicle terminal include:

[0076] The access gateway of the vehicle-to-everything (V2X) ecosystem service platform receives the access request initiated by the vehicle terminal and forwards the access request to the trusted authentication center of the V2X ecosystem service platform. The access request initiated by the vehicle terminal refers to the formal network access request initiated by the vehicle terminal after completing power-on initialization in order to access the V2X ecosystem service platform and obtain V2X service permissions. The access request includes at least the irreversible hash check value of the tenant identifier chain generated by the vehicle SE, the hardware serial number of the vehicle SE, the vehicle VIN, and the access terminal type information.

[0077] After receiving the access request, the Trusted Authentication Center initiates two-way identity authentication with the vehicle-mounted SE. This two-way identity authentication refers to a process that uses the vehicle-cloud end-to-end trust root established in step S1 as the verification basis and the vehicle-mounted SE and the cloud-based Trusted Authentication Center as dual trust anchors. It is a two-way legitimacy authentication process executed between the vehicle terminal and the vehicle network ecosystem service platform, verifying the identity of the vehicle-side tenant and the identity of the cloud platform. Unlike the one-way software authentication based on account passwords and software tokens in existing technologies, this two-way identity authentication is completed entirely within a trusted execution environment. The authentication credentials are tenant identification chains that cannot be tampered with by software, which can completely eliminate the risks of identity forgery, credential misuse, and man-in-the-middle attacks, ensuring that the identity of the tenant accessing the vehicle terminal is real, legitimate, and tamper-proof.

[0078] Specifically, the specific steps for implementing two-way authentication include:

[0079] After the trusted authentication center completes the format compliance verification of the access request, it generates an authentication challenge message containing a random number, a timestamp, and a unique platform identifier. The authentication challenge message is then sent to the vehicle terminal that initiated the access request through the access gateway. At the same time, the random number and timestamp of the authentication challenge message are bound to the access request information of the corresponding vehicle terminal and stored in encryption. A fixed-length challenge validity window is set, and authentication messages that exceed the challenge validity window will be directly determined as invalid.

[0080] After receiving the authentication challenge message, the vehicle terminal forwards it to the trusted execution environment inside the vehicle SE. The vehicle SE reads the tenant identifier chain and the private key bound to the tenant identifier chain, which are fixed in the internal immutable secure storage area. Combining the random number and timestamp in the authentication challenge message, it generates an authentication response message. The authentication response message includes the irreversible hash check value of the tenant identifier chain, the vehicle VIN, the vehicle SE hardware serial number, and a digital signature of the entire challenge message. The digital signature is generated using the private key fixed in the vehicle SE. The private key cannot be exported outside the vehicle SE at any time, ensuring that the signing process is immutable and cannot be forged.

[0081] The vehicle terminal uploads the authentication response message generated by the vehicle SE to the trusted authentication center through the access gateway. After receiving the authentication response message within the challenge validity window, the trusted authentication center first retrieves the public key corresponding to the tenant identifier chain pre-stored in step S1 and performs a signature verification operation on the digital signature in the authentication response message. After the signature verification is successful, the trusted authentication center sequentially verifies the consistency between the irreversible hash verification value of the tenant identifier chain and the pre-stored information, the hierarchical binding relationship between the vehicle VIN and the corresponding TID, and the consistency between the vehicle SE hardware serial number and the pre-stored filing information, thus completing the cloud-based authentication of the vehicle terminal's vehicle identity legitimacy.

[0082] After the trusted authentication center completes the vehicle-side identity legitimacy authentication and the verification is successful, it generates a platform authentication message containing platform identity credentials, challenge response confirmation information, and session key negotiation parameters. After digitally signing the platform authentication message with the private key of the vehicle network ecosystem service platform, it is sent to the vehicle terminal through the access gateway for the vehicle terminal to authenticate the identity legitimacy of the cloud platform.

[0083] After receiving the platform authentication message, the vehicle terminal forwards the platform authentication message to the trusted execution environment inside the vehicle SE. The vehicle SE uses the pre-programmed root public key of the Internet of Vehicles ecosystem service platform to verify the digital signature of the platform authentication message. After the verification is successful, the legality and validity of the platform identity certificate are verified, thus completing the vehicle terminal's authentication of the platform identity of the trusted authentication center in the cloud.

[0084] If both the cloud-based authentication of the vehicle's identity and the vehicle's authentication of the platform's identity with the cloud-based trusted authentication center pass, the two-way authentication is considered successful; otherwise, the two-way authentication fails.

[0085] After the trusted authentication center completes two-way identity authentication, if the authentication result is unsuccessful, the trusted authentication center immediately sends an access rejection instruction to the access gateway. The access gateway directly terminates the access process of the corresponding vehicle terminal, rejects all its network access requests, and generates an illegal access alarm record, which is synchronized to the security control center of the vehicle network ecosystem service platform and the control platform of the corresponding vehicle enterprise tenant.

[0086] If the authentication result is successful, the trusted authentication center sends an access license instruction and the TID information to the access gateway. Based on the corresponding TID, the access gateway dynamically allocates a tenant MQTT topic partition and transmission queue bound to the TID for the vehicle terminal. This queue is used to carry the end-to-cloud uplink transmission of streaming time-series vehicle control data collected by the vehicle terminal, as well as the cloud-to-end downlink transmission of vehicle control instructions and configuration information issued by the vehicle network ecosystem service platform to the vehicle terminal. This queue serves as the only data transmission channel between the vehicle terminal and the vehicle network ecosystem service platform that is bound to the corresponding TID, ensuring that all business data of the vehicle terminal flows within the corresponding tenant's transmission channel, thus achieving tenant-level data isolation at the transmission link level. The naming rule of the MQTT topic partition adopts the unified coding standard of the entire vehicle network ecosystem service platform, ensuring that the topic partition and TID form a unique and unchangeable mapping relationship.

[0087] The access gateway automatically generates and configures access control rules for the allocated tenant MQTT topic partitions. These access control rules are unique mappings between tenant TIDs and dynamically bound MQTT topic partitions. They are access control rules for the corresponding MQTT topic partitions, effective on the connected vehicle ecosystem service platform, and serve as the core execution basis for achieving tenant-level data isolation in the transmission process. Unlike existing technologies that statically configure Topic access rules that only restrict basic permissions, these access control rules are deeply bound to the corresponding tenant's TID. The rule content is dynamically updated in sync with the TID's authorization status, enabling full-process, full-domain control over topic partition access behavior. Scene control; the core control content of access control rules includes: clarifying the scope of legitimate access subjects, for example, only the vehicle terminal corresponding to the TID and the service nodes on the vehicle networking ecosystem service platform that have been specifically authorized by the TID have legitimate access permissions to the topic partition; clarifying the permission boundaries of legitimate operations, for example, only message publishing and message subscription permissions matching vehicle networking services are opened, and all unnecessary high-risk operation permissions such as topic modification, deletion, and configuration changes are permanently closed; clarifying absolutely prohibited access behaviors, for example, permanently blocking any access requests to the topic partition from all subjects not corresponding to the TID, and intercepting all illegal operations that exceed the permission boundaries in real time. Access control rules are used to perform real-time permission verification on all access behaviors of MQTT topic partitions, intercepting all unauthorized access and cross-tenant access requests at the entry point of the transmission channel, completely eliminating the risk of cross-tenant data access and data streaming at the transmission channel level; at the same time, the characteristic of this access control rule being bound to the tenant TID can ensure that all nodes in the entire link of the vehicle networking ecosystem service platform can complete the consistent identification of permission verification based on the TID, providing a unified rule benchmark for the transmission link for the continuous transmission of subsequent end-to-end isolation rules. For example, the TID corresponding to the vehicle manufacturer tenant is QC10086CN001. According to the unified topic partitioning naming rules across the entire network, the tenant MQTT topic partition assigned to this vehicle terminal is:

[0088] / vehicle / tenant / QC10086CN001 / device / LS9876543210ABCDEF / data;

[0089] QC10086CN001 is the TID of the corresponding tenant, and LS9876543210ABCDEF is the irreversible hash check value of the vehicle VIN. The access control rules only allow the vehicle terminal and authorized service node with TID QC10086CN001 to access this topic partition, and the subjects of all other TIDs have no access rights.

[0090] The access gateway binds the tenant's MQTT topic partition with TID and the corresponding access control rules, and synchronizes them to all functional nodes on the Internet of Vehicles (IoV) ecosystem service platform side through the full network configuration synchronization channel. Each functional node receives the data and completes local rule updates and confirmation of effectiveness, realizing the continuous transmission of tenant isolation rules from the end-side access link to the platform side. This provides a unified isolation and control benchmark for the subsequent full-link flow of streaming time-series vehicle control data.

[0091] Step S3: After completing the two-way identity authentication and platform access in Step S2, the vehicle terminal responds to the data collection command issued by the vehicle network ecosystem service platform and collects streaming time-series vehicle control data at a preset collection frequency; it segments the collected streaming time-series vehicle control data according to a preset fixed time window to generate time-series data segments with continuous timestamps; it generates an endogenous identifier data frame embedded in the time-series data segment frame header by combining the tenant identifier chain, and generates a cyclic redundancy check code based on the tenant identifier chain and the time-series data segment content and appends it to the frame tail of the endogenous identifier data frame; after encrypting the frame header identifier, it sends it to the vehicle network ecosystem service platform through MQTT topic partitioning; in order to complete the immutable endogenous binding of tenant identity and business data at the source of streaming time-series vehicle control data generation, while minimizing the terminal side computing power overhead and processing latency, ensuring the real-time performance of high-frequency vehicle control data collection and transmission, and fundamentally solving the core defects of existing technologies such as easy crosstalk of cloud post-labeling, excessive latency of full encryption processing, and easy separation and tampering of identifiers and data.

[0092] In this embodiment, the preset collection frequency refers to the standard number of times streaming time-series vehicle control data is collected per unit time for the vehicle terminal to which the corresponding TID belongs. This is uniformly set through high-frequency data collection commands issued by the vehicle network ecosystem service platform to the corresponding vehicle terminal, and can be configured differently based on the business scenarios, data application needs, and computing resources of the vehicle terminal for the vehicle enterprise tenant. The preset fixed time window refers to the standard time length for processing continuously collected streaming time-series vehicle control data in segments for the vehicle terminal to which the corresponding TID belongs. It is a core configuration parameter for achieving standardized segmentation of time-series data, lightweight edge-to-cloud transmission, and end-to-end identity verification. This is also uniformly set through high-frequency data collection commands issued by the vehicle network ecosystem service platform to the corresponding vehicle terminal, and can be adapted based on the collection frequency of streaming time-series vehicle control data, edge-to-cloud transmission bandwidth, and real-time data processing requirements. An endogenous identifier data frame refers to a standardized data frame structure that uses time-series data fragments as the payload, embeds the irreversible hash check value of the tenant identifier chain solidified in step S1 into a fixed position in the frame header, and appends the corresponding cyclic redundancy check code to a fixed position in the frame tail. The tenant identity identifier of this endogenous identifier data frame is inseparable from the data payload, cannot be separated, and cannot be tampered with individually. It can uniquely identify the tenant ownership of the data throughout the entire data lifecycle, eliminating the risk of multi-tenant data streaming and identifier tampering from the source of data generation.

[0093] In one embodiment, the specific steps for generating time-series data fragments with consecutive timestamps include:

[0094] The vehicle terminal receives data collection instructions issued by the vehicle networking ecosystem service platform. The core configuration parameters in the data collection instructions include at least the preset collection frequency, preset fixed time window, collection signal dimension, time synchronization reference, and fragmentation format specification bound to the corresponding TID.

[0095] Based on the time synchronization benchmark obtained through parsing, the vehicle terminal completes real-time clock synchronization with the trusted time source of the vehicle network ecosystem service platform. According to the preset collection frequency after parsing, it continuously collects streaming time-series vehicle control data from corresponding data sources such as the vehicle CAN bus, vehicle sensors, battery management system, and vehicle controller, and marks the collection timestamp after clock synchronization to achieve time traceability of each smallest data unit.

[0096] The vehicle terminal divides the continuous streaming time-series vehicle control data with collection timestamps into segments according to the parsed preset fixed time window. Each time window corresponds to an independent segment unit, ensuring that the time range of each segment has no overlap, no interruption, and no omission, thus guaranteeing the continuity and integrity of the time-series data.

[0097] The continuous streaming time-series vehicle control data within each preset fixed time window is standardized and encapsulated to generate independent time-series data slices. Each time-series data slice is assigned a master timestamp corresponding to the start time of the preset fixed time window and a continuously increasing global slice number bound to the acquisition session. The master timestamp and the slice number form a dual time-series identifier. A uniform and standardized fixed reserved field is reserved in the frame header of the time-series data slice for subsequent embedding of the irreversible hash verification value of the tenant identifier chain.

[0098] The vehicle terminal performs full-dimensional verification on each encapsulated time-series data fragment, including at least fragment format compliance verification, time continuity verification, data integrity verification, and fragment sequence number continuity verification. Time-series data fragments that pass the verification enter the subsequent intrinsic identifier binding process, while time-series data fragments that fail the verification are marked as abnormal fragments, and are discarded after the corresponding abnormal log is retained, ensuring that all time-series data fragments entering the end-to-end flow comply with standardized specifications.

[0099] In one implementation, an endogenous identifier data frame is generated by combining the tenant identifier chain with the embedded time-series data fragment frame header. Simultaneously, a cyclic redundancy check (CRC) code is generated based on the tenant identifier chain and the time-series data fragment content and appended to the end of the endogenous identifier data frame. After encrypting the frame header identifier, it is sent to the vehicle-to-everything (V2X) ecosystem service platform via MQTT topic partitioning. Specifically, this includes:

[0100] The vehicle terminal segments the time-series data and, within the trusted execution environment of the vehicle SE, reads the tenant identifier chain stored in the immutable secure storage area inside the vehicle SE in step S1, and obtains the irreversible hash verification value of the tenant identifier chain. The irreversible hash verification value is generated using the national cryptographic SM3 hash algorithm, which is unified across the entire vehicle network ecosystem service platform, to ensure that the irreversible hash verification value uniquely corresponds to the tenant identifier chain and cannot be reverse-crawled or tampered with.

[0101] The vehicle terminal embeds the irreversible hash verification value of the tenant identifier chain into a fixed reserved field in the header of the time-series data fragment frame, forming an endogenous identifier data frame structure in which the tenant identity and data payload are inseparable. The fixed reserved position is a standardized frame structure field that is unified across the entire vehicle network ecosystem service platform. It is a fixed reserved field that can only store the irreversible hash verification value of the tenant identifier chain. It can only be used to store the irreversible hash verification value of the tenant identifier chain and cannot be used to store other data content, ensuring that the tenant identity and data payload are deeply bound within the frame structure and cannot be separated or modified separately.

[0102] The vehicle-mounted terminal generates a Cyclic Redundancy Check (CRC) code based on the irreversible hash check value of the corresponding tenant identifier chain and the full plaintext content of the time-series data fragments within the intrinsic identifier data frame. This CRC code is generated using a 32-bit Cyclic Redundancy Check algorithm, standardized across the entire vehicle network ecosystem service platform. The CRC code is then appended to a fixed position at the end of the intrinsic identifier data frame. The calculation scope of the CRC code simultaneously covers the tenant identity identifier in the frame header and the full data payload within the frame, ensuring that the check code can simultaneously verify the authenticity of the tenant's ownership and the integrity of the data content. If the tenant identifier or data payload is tampered with, the check code will become invalid. The fixed position at the end of the frame is a verification field position uniformly defined across the entire vehicle network ecosystem service platform, located at the end of the intrinsic identifier data frame. This field is solely used to carry the CRC code, forming a head-to-tail correspondence with the fixed reserved field in the frame header. This ensures that all functional nodes across the entire link can quickly locate and verify the CRC code without conflicting with the data payload or identifier field.

[0103] Within the trusted execution environment of the vehicle-mounted SE, the vehicle-mounted terminal employs an asymmetric encryption algorithm to encrypt the irreversible hash checksum of the tenant identifier chain in the header of the endogenous identifier data frame, while not fully encrypting the time-series data fragment payload content within the endogenous identifier data frame. The private key used for encryption is the one uniquely bound to the tenant identifier chain in step S1 and stored throughout the vehicle-mounted SE, ensuring that the encrypted identity cannot be forged or tampered with. This also minimizes the computational overhead and processing latency of the end-side encryption, adapting to the real-time transmission requirements of high-frequency time-series data.

[0104] The vehicle terminal performs compliance verification on the encrypted intrinsic identifier data frame, including at least frame structure integrity verification, cyclic redundancy check code validity verification, and frame header encryption content format verification. The intrinsic identifier data frame that passes the verification enters the transmission process, while the intrinsic identifier data frame that fails the verification is marked as an abnormal data frame, the corresponding abnormal log is retained and then discarded, and it does not enter the subsequent transmission process.

[0105] The vehicle terminal sends the verified encrypted intrinsic identifier data frame to the access gateway of the vehicle network ecosystem service platform through the MQTT topic partition pre-bound in step S2, which is strongly associated with the corresponding TID. For example, the TID of the corresponding car enterprise tenant is QC10086CN001. The vehicle terminal completes the data transmission through the MQTT topic partition allocated in step S2, ensuring that the data flows within the transmission channel of the corresponding tenant throughout the process, thus avoiding the risk of cross-tenant data crosstalk from the source of transmission.

[0106] Step S4: The access gateway of the vehicle-to-everything (V2X) ecosystem service platform receives the intrinsically linked identifier data frame sent by the vehicle terminal and performs dual isolation verification. If the verification fails, the access gateway directly discards the intrinsically linked identifier data frame and generates an abnormal transmission alarm message, which is synchronized to the trusted authentication center and the corresponding tenant's management platform. If all verifications pass, the access gateway does not perform secondary parsing, modification, or additional processing on the payload content of the data frame, and directly transmits the complete intrinsically linked identifier data frame to the time-series data processing node of the V2X ecosystem service platform. This completes the dual isolation verification of the tenant data channel and identity during transmission, significantly reduces the gateway forwarding latency, ensures the real-time performance and isolation security of streaming time-series vehicle control data transmission, and retains the complete structure of the intrinsically linked identifier data frame throughout the process, providing a continuous isolation verification benchmark for subsequent storage, computation, and end-to-end verification stages.

[0107] In this embodiment, dual isolation verification refers to the dual verification process performed by the access gateway on the received intrinsically identified data frames. This process involves both channel ownership verification and identity legitimacy verification, based on the TID and MQTT topic partition binding relationship and access control rules synchronized in step S2, and the vehicle-cloud full-link trust root established in step S1. This is a core protection measure to prevent cross-tenant data streaming and data tampering during transmission. Unlike existing technologies that only verify transmission channel permissions without verifying the tenant ownership of the data itself, this ensures that only legitimate data from the corresponding tenant can enter subsequent stages through the transmission channel, further strengthening tenant isolation from the midpoint of transmission. The time-series data processing node refers to a functional node on the vehicle network ecosystem service platform side specifically used to receive, temporarily store, and preprocess streaming time-series vehicle control data. It receives the intrinsically identified data frames transparently transmitted by the access gateway, providing standardized data input for subsequent storage isolation and computational isolation. Its processing logic is bound to the isolation rules of the corresponding TID, ensuring the consistency of tenant isolation in the data processing stage.

[0108] In one embodiment, the specific steps for performing dual isolation verification include:

[0109] The access gateway receives the intrinsically identified data frame sent by the vehicle terminal through the MQTT topic partition, extracts the transmission channel information of the intrinsically identified data frame, that is, the complete encoding of the MQTT topic partition of the received data, retrieves the binding relationship between the MQTT topic partition and TID stored synchronously in step S2, and performs the first verification, channel ownership verification:

[0110] The system determines whether the MQTT topic partition receiving the intrinsically identified data frame has been bound to the corresponding TID and whether the access control rules for the topic partition are in a normal and effective state. If the MQTT topic partition is not bound to any TID, the access control rules are invalid, or the TID bound to the MQTT topic partition is in an unauthorized or blocked state, the channel ownership verification is determined to fail. If the MQTT topic partition is bound to the corresponding TID, the access control rules are in a normal and effective state, and the TID is in a legal and authorized state, the channel ownership verification is passed, and the TID bound to the MQTT topic partition is used as the basis for subsequent identity verification.

[0111] After the channel attribution verification passes, the access gateway performs a second verification: identity legitimacy verification. This involves extracting only the irreversible hash check value of the tenant identifier chain encrypted in the frame header of the endogenous identifier data frame and the cyclic redundancy check code in the frame tail. At the same time, it retrieves the public key of the tenant identifier chain corresponding to the TID, which was synchronized to the trusted authentication center in step S1, as well as the 32-bit cyclic redundancy check algorithm rules agreed upon in step S3.

[0112] Using the public key of the tenant identifier chain corresponding to the TID, the irreversible hash checksum of the tenant identifier chain encrypted in the frame header is decrypted. If decryption fails, it indicates that the identity identifier has been forged or the encryption key does not match, and the identity legitimacy verification is directly deemed to have failed. If decryption is successful and the irreversible hash checksum of the tenant identifier chain is obtained, the cyclic redundancy check code is recalculated based on the irreversible hash checksum and the full plaintext content of the endogenous identifier data frame using the unified 32-bit cyclic redundancy check algorithm of the entire vehicle network ecosystem service platform. The recalculated cyclic redundancy check code is compared with the cyclic redundancy check code appended to the frame tail. If the comparison is inconsistent, it indicates that the data has been tampered with during transmission or that the tenant identifier does not match the data payload, and the identity legitimacy verification is deemed to have failed. The identity legitimacy verification is deemed to have passed only when decryption is successful and the checksum comparison is completely consistent.

[0113] If either the channel attribution verification or the identity legitimacy verification fails, the access gateway immediately discards the intrinsically identified data frame without performing any forwarding operation, and generates an abnormal transmission alarm message. The alarm message includes at least the reception time of the abnormal data frame, the transmission channel, the abnormality type, and the serial number of the sending end vehicle SE hardware. The alarm message is synchronized to the trusted authentication center of the vehicle network ecosystem service platform and the vehicle enterprise tenant management platform to which the TID belongs, so that the platform can monitor the transmission abnormality in real time and trace the cause of the abnormality.

[0114] If all dual isolation checks pass, the access gateway strictly follows the transparent transmission principle and does not perform any secondary parsing, modification, appending, or encryption on the frame header identifier, data payload, or frame tail check code of the endogenous identifier data frame. This ensures that the data frame structure remains completely consistent with that sent by the vehicle terminal, minimizing the gateway's forwarding processing latency and adapting to the real-time transmission requirements of high-frequency streaming time-series vehicle control data.

[0115] The access gateway forwards the complete endogenous identifier data frame directly to the time-series data processing node of the vehicle-to-everything (V2X) ecosystem service platform through the tenant transparent transmission channel preset on the V2X ecosystem service platform side. Among them, the tenant transparent transmission channel is bound to TID, and each TID corresponds to an independent transparent transmission channel. The transparent transmission channels of different TIDs are physically isolated and logically independent, preventing data from different tenants from being streamed or mixed in the transparent transmission process, and further strengthening the tenant isolation effect in the transmission process.

[0116] After the access gateway completes the data pass-through, it generates a transmission log and stores it in encryption. The transmission log includes at least the reception time, forwarding time, MQTT topic partition, corresponding TID, master timestamp and fragment sequence number of the time-series data fragment. The log information is bound to the corresponding TID and stored for a preset duration for subsequent end-to-end data traceability, compliance auditing and anomaly investigation.

[0117] Step S5: The time-series database of the vehicle-to-everything (V2X) ecosystem service platform pre-establishes logical storage partitions based on the TIDs of each tenant. Each TID corresponds to a unique logical storage partition, and the index key of the logical storage partition is bound to the corresponding TID and DID. At the same time, an ACL (Access Control List) corresponding to each TID is configured one-to-one in the storage engine layer of the time-series database. A List (access control list) is used to prohibit access operations across logical storage partitions of a specific TID. After receiving an intrinsically identified data frame, the time-series data processing node only parses the irreversible hash check value of the TID in the frame header and automatically forwards the intrinsically identified data frame to the logical storage partition of the corresponding TID. At the same time, it performs a secondary check on the cyclic redundancy check code at the end of the frame. After the check passes, the data is written. During the writing process, data compression, storage, and indexing are performed independently based on the logical storage partition corresponding to the TID. The compressed data blocks of logical storage partitions of different TIDs are completely physically isolated. At the same time, independent data lifecycle management, backup, and destruction rules are configured for each logical storage partition to achieve proactive pre-isolation of streaming time-series vehicle control data in the storage stage. This blocks cross-tenant data access paths from the storage engine layer while taking into account storage resource utilization and real-time data read and write performance. This solves the inherent conflicts of low resource utilization in the existing strong isolation mode, data leakage due to SQL filtering omissions in the weak isolation mode, and blurred boundaries between time-series data compression storage and isolation.

[0118] In this embodiment, the time-series database refers to a database on the vehicle network ecosystem service platform side specifically used to store high-frequency streaming time-series vehicle control data. It has the core characteristics of high throughput, low latency, and optimized time-series indexing. Its storage architecture is bound to TID and is the core carrier for realizing tenant isolation in the storage link. The logical storage partition refers to an independent storage unit pre-created by the time-series database based on each tenant's TID, which is uniquely corresponding to the TID. It is used to store all streaming time-series vehicle control data belonging to the corresponding TID, serving as the storage carrier for the tenant's vehicle control data. At the same time, it provides the basis for accurate data forwarding, independent compression, time-series index construction, lifecycle management, backup and destruction rules, ensuring that the data of the corresponding tenant is isolated from other tenants at the storage level. The ACL refers to the permission control list configured in the storage engine layer of the time-series database, which corresponds one-to-one with the TID. It is the core execution basis for realizing cross-tenant access blocking in the storage link, forming a closed loop of full-link permission control with the access control rules of the MQTT topic partition in step S2.

[0119] In one implementation, data compression, storage, and index construction refer to the following: each logical storage partition corresponding to a TID uses an independent data compression algorithm and compression ratio that matches the business needs of that tenant to independently complete data compression and storage. The generated compressed data blocks are stored in independent physical storage addresses, and the compressed data blocks of different TIDs have no physical association or logical overlap, achieving dual protection of physical and logical isolation. At the same time, each logical storage partition independently constructs a time-series index. The index rules are designed based on the DID of the vehicle under that tenant, the master timestamp of the time-series data shard, and the shard sequence number, ensuring that the authorized service nodes of the corresponding tenant can quickly query and retrieve their own data without affecting the data read and write performance of other tenants, thus balancing storage resource utilization and real-time data access.

[0120] In one implementation, independent data lifecycle management, backup, and destruction rules refer to configuring data retention duration, backup frequency, backup storage location, and destruction strategy separately for each logical storage partition corresponding to a TID, based on the business needs and compliance requirements of the corresponding automotive tenant, and binding it to the corresponding TID. For example, if an automotive tenant needs to retain vehicle control data for 3 years, with a backup frequency of once a day and a destruction strategy of irreversible physical deletion after expiration, then this rule is only executed on the logical storage partition corresponding to that tenant, without affecting the storage rule configuration of other tenants. This satisfies the differentiated needs of different automotive companies and complies with automotive data security compliance requirements, achieving tenant-level independent management and control of the entire data lifecycle.

[0121] Step S6: The streaming computing engine of the vehicle-to-everything (V2X) ecosystem service platform pre-establishes a computing task thread pool for each tenant's TID. In response to a tenant's request for a streaming time-series vehicle control data computing task, the streaming computing engine binds the computing task to the requesting tenant's TID, automatically anchoring the logical storage partition corresponding to the TID from step S5. The engine's underlying layer only allows the computing task to read the intrinsic identifier data frames within the logical storage partition anchored to the TID for execution. Simultaneously, during the computing process, the irreversible hash checksum of the TID header and the cyclic redundancy checksum of the tail of each read intrinsic identifier data frame are triple-checked. The identity validity verification fails, and time-series data fragments that fail the verification are directly discarded and do not enter the calculation process. After the calculation is completed, the generated calculation result is automatically bound to the corresponding TID and written to the calculation result sub-partition in the logical storage partition corresponding to the TID in step S5. This achieves lightweight and strong isolation of streaming time-series vehicle control data in the calculation process, taking into account both the isolation security of the calculation process and the low latency requirements of streaming computing. At the same time, it realizes the continuous transmission of tenant isolation benchmark in the calculation process, solving the defects of existing technologies such as high resource consumption of container isolation mode, inability to adapt to real-time computing scenarios, and easy occurrence of calculation data crossover and cache leakage in filtering mode.

[0122] In this embodiment, the computing task thread pool refers to an independent computing resource unit pre-created by the streaming computing engine based on each tenant's TID, corresponding to the TID. It serves as the running environment for the corresponding tenant's streaming computing tasks. Its resource quota is matched with the business scale and computing needs of the corresponding tenant. The thread pools of different TIDs are physically isolated and logically independent, with no cross-access paths such as shared memory and shared cache. This eliminates the risk of cross-tenant computing resource contention and data cache leakage from the underlying computing engine. The three identity legality verifications refer to the three consistency verifications performed on the endogenous identifier data frame during the execution of the computing task, at the data reading stage, the computing preprocessing stage, and the result writing stage. This ensures that the verification benchmark is consistent throughout the entire chain and completely avoids the risk of cross-tenant data mixing and data tampering in the computing stage.

[0123] Please see Figure 4 In one embodiment, the specific steps for performing the computation task include:

[0124] During the platform initialization phase, the streaming computing engine of the connected vehicle ecosystem service platform pre-establishes a computing task thread pool for each TID that has completed tenant ownership confirmation. Each computing task thread pool is configured with an independent CPU and memory resource quota bound to the corresponding TID. The quota can be dynamically adjusted based on the business scale and computing needs of the corresponding car company tenant. At the same time, each computing task thread pool is allocated an independent computing cache space and memory space. There are no cross-access paths between computing task thread pools of different TIDs that share computing cache or shared memory. The engine's underlying layer permanently prohibits cross-TID thread pool resource calls, data interaction, and cache access, thus achieving physical and logical isolation of tenant-level computing resources from the underlying computing engine layer.

[0125] When the streaming computing engine responds to a request for streaming time-series vehicle control data computing tasks initiated by a vehicle manufacturer tenant, it first forwards the computing task request to the trusted authentication center to verify the TID authorization status of the tenant that initiated the request. If the verification fails, the computing task request is directly rejected, and an illegal task request alarm is generated and synchronized to the corresponding tenant management platform. If the verification passes, the computing task is bound to the TID of the requesting tenant, locking the TID to which the computing task belongs. The bound TID cannot be changed throughout the entire lifecycle of the task, ensuring that the computing task can only access the resources and data corresponding to the TID to which it belongs.

[0126] For computing tasks bound to a TID, the streaming computing engine allocates a thread pool for the computing task corresponding to that TID, initializes the task's runtime environment, independent computing cache, and intermediate data storage area, and the runtime environment is completely isolated from computing tasks of other TIDs; at the same time, it automatically anchors the logical storage partition corresponding to that TID, and the engine's underlying layer enforces locking through access control rules: the computing task can only read the intrinsic identifier data frame in the logical storage partition anchored to the TID, and is permanently prohibited from reading any data in other logical storage partitions across TIDs, thus blocking the path of cross-tenant data cross-access from the access entry point.

[0127] After the computing task is started, the streaming computing engine reads the endogenous identifier data frame that meets the requirements of the computing task from the logical storage partition corresponding to the anchored TID, performs standardized computing operations on streaming time-series vehicle control data based on the endogenous identifier data frame, including computing preprocessing operations and computing logic operations, and performs three identity legality checks in the standardized computing operations to obtain the computing results.

[0128] Specifically, before performing the preprocessing operations, a first identity verification is performed, including:

[0129] Extract the irreversible hash checksum of the TID encrypted in the frame header of the endogenous identifier data frame and the cyclic redundancy check (CRC) code in the frame tail. Decrypt the frame header hash value using the tenant identifier chain public key pre-stored in step S1 corresponding to the TID. Confirm that the decrypted hash value completely matches the TID bound to the computation task. Simultaneously, based on the hash value and the full plaintext content of the endogenous identifier data frame, recalculate the checksum using a network-wide unified 32-bit CRC algorithm and compare it with the checksum appended to the frame tail. If the verification passes, proceed to the subsequent computation preprocessing stage; if the verification fails, discard the endogenous identifier data frame directly and do not enter the computation process. At the same time, generate a data verification exception log.

[0130] For endogenous identifier data frames that pass the first identity legitimacy check, the streaming computing engine performs computational preprocessing operations and simultaneously performs a second identity legitimacy check, including: re-checking the consistency between the irreversible hash checksum of the TID in the frame header of the endogenous identifier data frame and the TID bound to the computation task, and re-checking the validity of the cyclic redundancy checksum in the frame tail to confirm that the data has not been tampered with during reading and caching and that the tenant ownership matches; if the check passes, only the time-series data fragment payload within the endogenous identifier data frame is extracted and enters the core computation process, preserving the complete structure of the endogenous identifier data frame and the tenant identity binding relationship throughout, without stripping or modifying the tenant identifier and checksum in the original frame; if the check fails, the endogenous identifier data frame is directly discarded and does not enter the core computation stage, while a preprocessing exception log is generated.

[0131] The streaming computing engine executes computational logic operations within the computation task thread pool corresponding to the TID. All intermediate data generated during the computation process is cached only in the memory space of the computation task thread pool. There is no intermediate data interaction, sharing, or transmission between computation tasks of different TIDs. The engine monitors the running behavior of the computation tasks in real time throughout the process. Once it detects that a task initiates a request for cross-TID resource access or cross-partition data reading, it immediately intercepts the illegal request, terminates the computation task, and generates illegal access alarm information, which is synchronized to the trusted authentication center of the vehicle network ecosystem service platform and the management platform of the corresponding tenant.

[0132] After the computation logic operation is completed, the streaming computing engine generates the computation result and binds the computation result to the TID bound to the computation task. Simultaneously, a third identity legality verification is performed, including: verifying that the TID bound to the computation result, the TID bound to the computation task, and the TID corresponding to the logical storage partition are completely consistent. At the same time, the ownership and integrity of all original endogenous identifier data frames associated with the computation result are verified to ensure that the data source of the computation result is all legitimate data belonging to the TID. If the verification passes, the result writing stage begins. If the verification fails, the result writing operation is terminated, the computation result is discarded, and a computation result verification anomaly alarm is generated and synchronized to the corresponding tenant management platform.

[0133] After the third identity verification passes, the streaming computing engine appends a frame structure consistent with the format of the intrinsic identifier data frame to the calculation result bound to the TID: embeds the irreversible hash check value of the corresponding TID into a fixed position in the header of the result data frame, generates a cyclic redundancy check code based on the TID hash value and the full content of the calculation result, and appends it to a fixed position in the tail of the frame, forming a result data frame with the same format as the original data and continuous binding of the tenant identifier; writes the result data frame into the calculation result sub-partition in the logical storage partition corresponding to the TID in step S5, and configures the result data frame with the same data lifecycle management, backup and destruction rules as the logical storage partition of the TID, so as to realize the continuous transmission of tenant isolation rules throughout the entire calculation process.

[0134] Throughout the entire computation task process, the streaming computing engine synchronously generates encrypted computation audit logs. The audit logs include at least the TID bound to the computation task, the task start and end times, the range of intrinsically identified data frames read, the location where the computation results are written, the full-process verification results, and abnormal alarm information. The audit logs are stored in conjunction with the corresponding TIDs and retained for a preset duration for subsequent full-link data traceability, compliance auditing, and anomaly investigation. After the computation task is completed, all computation caches and intermediate data of the task in the thread pool are immediately cleared, completely eliminating the risk of data cache leakage across tasks and tenants.

[0135] Step S7: The end-to-end isolation verification engine of the vehicle-to-everything (V2X) ecosystem service platform uses the tenant identifier chain embedded in the hardware in step S1 as the unique verification benchmark for the entire link. It performs real-time continuous consistency verification of the isolation status of the entire process of end-side acquisition, transmission, storage, and computing. During the verification process, the end-to-end isolation verification engine reuses the irreversible hash verification value of TID, cyclic redundancy check code, TID end-to-end binding relationship and access control rules generated in each link. It does not need to perform secondary parsing of the payload content of time-series data fragments. It sequentially verifies the legality of the end-side embedded identifier data frame, the matching of the topic partition and TID in the transmission link, the consistency of the logical partition and TID in the storage link, and the anchoring relationship between the task and TID in the computing link. If any link in the verification process is found to have an abnormal isolation status, the end-to-end isolation verification engine will immediately trigger an end-to-end interception operation to block the subsequent flow of the abnormal data. At the same time, it will generate an abnormal alarm message and synchronize it to the corresponding tenant's management platform and trusted authentication center. If all links pass the verification, the end-to-end isolation verification engine will generate a traceable certificate of the end-to-end isolation status of the corresponding TID based on the end-to-end verification log. This will fully record the isolation status of the data from the end-side collection, transmission, storage, calculation to final destruction, so as to realize the end-to-end closed loop of multi-tenant data isolation management and control, completely avoid the spread of single-point isolation failure to end-to-end data leakage, and meet the compliance audit requirements of the entire life cycle of vehicle network data.

[0136] In this embodiment, the end-to-end isolation verification engine refers to a functional node on the vehicle network ecosystem service platform side that is specifically used to perform end-to-end isolation state consistency verification, anomaly interception, and compliance traceability. It is the core execution entity for realizing the end-to-end closed loop of multi-tenant data isolation management and control. It is linked in real time with all functional nodes of the end-to-end, including the trusted authentication center, access gateway, time-series data processing node, time-series database, and streaming computing engine.

[0137] Real-time continuous consistency verification refers to the closed-loop verification process executed by the end-to-end isolation verification engine for the entire lifecycle of a single intrinsically identified data frame, checking the consistency of tenant identity across stages, the continuity of isolation rules, and the integrity of data. Its core verification logic is to verify that the TID bound to the same intrinsically identified data frame in the end-side acquisition stage is completely consistent with the TID bound to the tenant MQTT topic partition in the transmission stage, the TID corresponding to the logical storage partition in the storage stage, and the TID anchored to the computing task in the computing stage. Moreover, the access control rules and isolation configurations of each stage are strongly matched with the TID, with no abnormal situations such as disconnection of isolation rules, identity tampering, or cross-TID flow. The verification process reuses the verification information generated in each stage throughout the process, without parsing the data payload content. While ensuring the rigor of the end-to-end verification, it does not increase additional computing power overhead or processing latency, adapting to the end-to-end flow requirements of high-frequency streaming time-series vehicle control data.

[0138] The end-to-end isolation status traceable credential refers to the standardized compliance credential generated by the end-to-end isolation verification engine based on the full-process verification log for each intrinsically identified data frame under the corresponding TID. The credential content fully covers the end-to-end node information, isolation status verification results, operation subject and timestamp of the data from the end-side collection and generation of intrinsically identified data frames, dual isolation verification in the transmission link, partition writing in the storage link, full-process identity verification in the computing link to the final data destruction. It is uniquely bound to the corresponding TID and DID and cannot be tampered with or forged.

[0139] The end-to-end interception operation refers to the abnormal data interception command that the end-to-end isolation verification engine synchronously sends to each functional node of the end-to-end after detecting an abnormal isolation status. The command is strongly associated with the TID bound to the abnormal data and the unique identifier of the abnormal data frame. It can drive the access gateway to intercept the subsequent transmission of the data frame, the time-series database to prohibit the writing and reading of the data frame, and the streaming computing engine to terminate the computing tasks related to the data frame. This achieves the immediate blocking of abnormal data throughout the end-to-end and completely avoids the spread of single-point isolation anomalies into cross-link and cross-tenant data security events.

[0140] Example 2

[0141] This embodiment introduces a multi-tenant end-to-end data security isolation and control system, including: a tenant pre-configuration module, an access authentication module, an end-side binding module, a transmission verification module, a storage isolation and control module, and a computing isolation and control module;

[0142] The tenant pre-configuration module, deployed on the vehicle-to-everything (V2X) ecosystem service platform, has the core function of responding to vehicle manufacturer tenants' mass production pre-configuration requirements. It generates a globally unique and non-repeatable TID for each corresponding V2X tenant and a DID for each vehicle under that tenant, each uniquely bound to its Vehicle Identifier (VIN). Based on preset hierarchical combination rules, it combines the corresponding TID with the DID of the vehicle under that TID to form a tenant identifier chain. Simultaneously, it generates a matching asymmetric encryption key pair for this tenant identifier chain. Through the secure programming interface of the vehicle-mounted security chip (SE), it writes the tenant identifier chain and the corresponding bound private key into the immutable secure storage area inside the SE, completing write verification and access control. Simultaneously, it synchronizes the public key of the corresponding tenant identifier chain, the hierarchical binding relationship between TID and DID, and the preset hierarchical combination rules of the tenant identifier chain to the trusted authentication center of the V2X ecosystem service platform for encrypted storage, completing the establishment of a vehicle-cloud end-to-end trust root and providing a unique and immutable verification benchmark for the end-to-end isolation and control of the V2X ecosystem service platform.

[0143] The access authentication module, deployed in the access gateway and trusted authentication center of the vehicle-to-everything (V2X) ecosystem service platform, has the core function of receiving access requests from vehicle terminals to the V2X ecosystem service platform. It forwards these requests to the trusted authentication center, driving it to complete two-way authentication with the vehicle terminal via the vehicle's SE (Secure Entity Provider). The module verifies whether the irreversible hash checksum of the tenant identifier chain uploaded by the vehicle terminal matches the pre-stored public key information. If authentication fails, the access gateway directly rejects the vehicle terminal's access request and generates an illegal access alarm record. If authentication succeeds, the access gateway dynamically allocates MQTT (Message Queue Telemetry) topic partitions and transmission queues bound to the TID (Tencent Identifier ID) for the vehicle terminal, automatically generates and configures access control rules deeply bound to the TID, and synchronizes the binding relationship between the topic partition and the TID, along with the corresponding access control rules, to all functional nodes across the entire V2X ecosystem service platform, achieving continuous transmission of tenant isolation rules from the terminal side to the platform side.

[0144] The edge binding module, deployed within the trusted execution environment of the vehicle terminal and the vehicle SE, has the core function of responding to data collection commands issued by the vehicle ecosystem service platform after the vehicle terminal completes two-way identity authentication and platform access. It collects streaming time-series vehicle control data at a preset collection frequency, segments the collected data within a preset fixed time window, and generates time-series data fragments with continuous timestamps. Within the trusted execution environment of the vehicle SE, it reads the permanently stored tenant identifier chain and generates its irreversible hash check value. This irreversible hash check value is then embedded into a fixed reserved field in the time-series data fragment frame header, forming... The structure of the intrinsically identified data frame is inseparable from the tenant identity identifier and data payload. Based on the irreversible hash check value of the tenant identifier chain and the full plaintext content of the time-series data fragments in the intrinsically identified data frame, a cyclic redundancy check code is generated and appended to a fixed position at the end of the intrinsically identified data frame. An asymmetric encryption algorithm is used to encrypt the irreversible hash check value of the tenant identifier chain in the frame header, but the time-series data fragment payload content is not fully encrypted. After the encrypted intrinsically identified data frame completes compliance verification, it is sent to the access gateway of the vehicle network ecosystem service platform through a pre-bound MQTT topic partition strongly associated with the corresponding TID.

[0145] The transmission verification module, deployed on the access gateway of the vehicle-to-everything (V2X) ecosystem service platform, has the core function of receiving endogenous identification data frames sent by vehicle terminals and performing dual isolation verification consisting of channel attribution verification and identity legitimacy verification on the endogenous identification data frames. If either verification fails, the endogenous identification data frame is directly discarded, and an abnormal transmission alarm is generated and synchronized to the trusted authentication center of the V2X ecosystem service platform and the vehicle enterprise tenant management platform to which the corresponding TID belongs. If both isolation verifications pass, the transparent transmission principle is strictly followed, and no secondary parsing, modification, appending, or encryption processing is performed on the frame header identifier, data payload, or frame tail check code of the endogenous identification data frame. The complete endogenous identification data frame is directly forwarded to the time-series data processing node of the V2X ecosystem service platform through the tenant-specific transparent transmission channel bound to the TID, which is preset on the V2X ecosystem service platform side. At the same time, a transmission log bound to the corresponding TID is generated and encrypted and stored for subsequent full-link data traceability, compliance auditing, and anomaly investigation.

[0146] The storage isolation and management module, deployed in the time-series database and time-series data processing nodes of the vehicle-to-everything (V2X) ecosystem service platform, has the core function of driving the time-series database to pre-establish logical storage partitions based on each tenant's TID, configuring a unique logical storage partition for each TID, binding the index key of the logical storage partition with the corresponding TID and DID, and configuring an Access Control List (ACL) at the storage engine layer of the time-series database that corresponds one-to-one with the TID, permanently prohibiting cross-TID logical storage partition access operations. After receiving an intrinsically identified data frame, the time-series data processing node only parses the irreversible hash checksum of the TID in the frame header, automatically forwards the intrinsically identified data frame to the logical storage partition of the corresponding TID, and performs a secondary check on the cyclic redundancy checksum at the frame tail. After successful check, the data is written. During the data writing process, data compression, storage, and indexing are performed independently based on the logical storage partition corresponding to the TID, ensuring complete physical isolation of compressed data blocks in logical storage partitions of different TIDs. Simultaneously, independent data lifecycle management, backup, and destruction rules are configured for each logical storage partition and bound to the corresponding TID, blocking cross-tenant data access paths from the storage engine layer.

[0147] The computation isolation and control module, deployed within the streaming computing engine of the connected vehicle ecosystem service platform, has the core function of establishing a computation task thread pool bound to each tenant-authorized TID during the platform's initialization phase. This involves configuring independent CPU and memory resource quotas for each thread pool, allocating separate computation cache and memory spaces to achieve physical and logical isolation between thread pools for different TIDs. Upon responding to streaming time-series vehicle control data computation task requests initiated by vehicle manufacturer tenants, and after verifying the TID authorization status of the requesting tenant, the module strongly binds the computation task to the requesting tenant's TID, assigns it the corresponding TID's computation task thread pool, and automatically anchors it. Define the logical storage partition of the time-series database corresponding to the TID, and enforce access control rules to lock the computing task to read only the intrinsic identifier data frame in the logical storage partition anchored to the TID; during the entire execution process of the computing task, perform three identity validity checks on the read intrinsic identifier data frame, and discard the intrinsic identifier data frame that fails the check directly and does not enter the computing process; after the calculation is completed, the generated calculation result is strongly bound to the corresponding TID and written to the calculation result sub-partition in the logical storage partition of the corresponding TID, and an encrypted calculation audit log bound to the corresponding TID is generated synchronously. After the calculation task is completed, immediately clear all calculation caches and intermediate data corresponding to the task to prevent the risk of data cache leakage across tasks and across tenants.

[0148] Working principle and its effects:

[0149] The core of this invention is to focus on the full lifecycle security isolation and management of streaming time-series vehicle control data in multi-tenant scenarios of the Internet of Vehicles. It uses the tenant identification chain as the core trust benchmark and connects the entire process of edge data collection, platform access, data transmission, storage, and computing. Through the coordinated linkage of each link, data isolation and trusted management are achieved, while taking into account the real-time performance and compliance of data processing. This solves the problems of multi-tenant data streaming, unauthorized access, and leakage at the root.

[0150] This invention responds to the pre-installation requirements of vehicle manufacturers' tenants' mass-production vehicles through a vehicle-to-everything (V2X) ecosystem service platform. It generates a Tenant Identifier (TID) and a DID bound to the vehicle's VIN, combining them into a tenant identifier chain and embedding it into the in-vehicle SE. This is synchronized with a trusted authentication center to establish a vehicle-cloud end-to-end trust root, ensuring the tenant's identity is tamper-proof and traceable, thus mitigating the risk of identity forgery. When the in-vehicle terminal connects, the trusted authentication center completes two-way identity authentication through the in-vehicle SE. After successful authentication, it dynamically allocates MQTT topic partitions, transmission queues, and access control rules bound to the TID, achieving tenant-specific isolation of the transmission channel and preventing cross-tenant data crosstalk. After the in-vehicle terminal collects streaming time-series vehicle control data and segments it, it embeds the irreversible hash checksum of the tenant identifier chain into the frame header and appends a cyclic redundancy check (CRC) code to the frame tail to generate an endogenous identifier data frame. After encryption, data is uploaded via a dedicated MQTT topic partition, achieving intrinsic binding between data and tenant identity, reducing end-side computing power overhead and ensuring data integrity. The access gateway performs dual verification of channel ownership and identity legitimacy on data frames. After successful verification, the data is passed through to the time-series data processing node, which forwards the data to the time-series database logical storage partition corresponding to the TID. Storage isolation is achieved through independent partition compression storage and ACL permission control, and independent data lifecycle rules are configured to meet compliance requirements. When responding to tenant computing task requests, the streaming computing engine anchors the corresponding storage partition through a dedicated thread pool bound to the TID, reads the data and performs three identity legitimacy verifications to ensure that data is not interleaved or tampered with during the computing process. The computing results are bound to the TID and written to the corresponding sub-partition, achieving isolation and control of the computing process.

[0151] In summary, this invention, through a collaborative control logic across the entire data lifecycle, integrates tenant identification throughout the data lifecycle, achieving continuous isolation and reliable verification from the edge to the cloud and from data collection to computation. This effectively prevents risks of cross-tenant data leakage, unauthorized access, and data tampering, while also ensuring the real-time nature of data transmission and processing. It meets the compliance audit requirements for the entire lifecycle of vehicle network data and guarantees the stable and orderly operation of the multi-tenant vehicle network ecosystem, providing reliable support for the core data security in multi-tenant vehicle network scenarios.

[0152] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A multi-tenant end-to-end data security isolation and control method, characterized in that, include: The vehicle-to-everything (V2X) ecosystem service platform generates a tenant root identifier (TID) for vehicle enterprise tenants, which in turn generates a tenant identifier chain and solidifies it into the secure storage area of ​​the vehicle hardware security chip (SE). In response to the access request initiated by the vehicle terminal, the Trusted Authentication Center completes two-way identity authentication with the vehicle terminal through the vehicle SE. If the authentication is successful, it dynamically allocates a message queue telemetry transmission MQTT topic partition and transmission queue bound to the TID for the vehicle terminal based on the TID in the tenant identifier chain, and configures access control rules. In response to the data acquisition command, the vehicle terminal acquires streaming time-series vehicle control data and generates time-series data fragments; combined with the tenant identifier chain, it generates an endogenous identifier data frame that embeds the time-series data fragment frame header, and at the same time generates a cyclic redundancy check code and appends it to the frame tail of the endogenous identifier data frame, and after encryption, it sends it to the vehicle network ecosystem service platform through the MQTT topic partition. The access gateway of the vehicle-to-everything (V2X) ecosystem service platform receives the endogenous identification data frame sent by the vehicle terminal, performs dual isolation verification, and if the verification passes, it transmits the endogenous identification data frame to the time-series data processing node. The dual isolation verification includes channel attribution verification and identity legitimacy verification; The endogenous identifier data frame is forwarded to the logical storage partition of the time-series database corresponding to the TID for data compression, storage and index construction; In response to the request for streaming time-series vehicle control data calculation task initiated by the tenant, the logical storage partition corresponding to the TID is automatically anchored. After the calculation task starts, the intrinsic identifier data frame that meets the requirements of the calculation task is read from the logical storage partition corresponding to the anchored TID, standardized calculation operation is performed, and three identity legality checks are performed in the standardized calculation operation to obtain the calculation result. The standardized computational operations include computational preprocessing operations and computational logic operations; The three identity verifications performed in the standardized calculation operation include: Before the computational preprocessing operation, a first identity legitimacy check is performed to verify whether the TID of the read endogenous identifier data frame matches the TID bound to the computation task. During the computational preprocessing operation, a second identity legitimacy check is performed simultaneously to verify whether the endogenous identifier data frame has been tampered with during the reading and caching process. After the computational logic operation process is completed, a third identity validity check is performed synchronously to verify whether the TID bound to the computation result, the TID bound to the computation task, and the TID corresponding to the logical storage partition are consistent.

2. The multi-tenant end-to-end data security isolation and control method as described in claim 1, characterized in that, The multi-tenant end-to-end data security isolation and control method further includes establishing a vehicle-cloud end-to-end trust root, the steps of which include: In response to the vehicle mass production pre-configuration requirements submitted by vehicle manufacturer tenants, generate TIDs for the corresponding vehicle manufacturer tenants; For each vehicle under the corresponding car manufacturer tenant, generate a device sub-identifier (DID) that is uniquely bound to the vehicle identification number (VIN). Based on the preset hierarchical combination rules, the corresponding TID and the DID of the vehicle under the TID are combined to form a tenant identifier chain. At the same time, an asymmetric encryption key pair is generated for the tenant identifier chain. The private key in the asymmetric encryption key pair is bound and stored with the tenant identifier chain, and the public key is synchronized to the trusted authentication center of the vehicle network ecosystem service platform as the identity authentication credential of the tenant identifier chain. The tenant identifier chain and the corresponding bound private key are written into the secure storage area inside the vehicle SE through the secure programming interface of the vehicle SE. The public key of the tenant identifier chain, the hierarchical binding relationship between TID and DID, and the preset hierarchical combination rules of the tenant identifier chain are synchronized to the trusted authentication center of the vehicle-to-the-cloud ecosystem service platform for encrypted storage; a trust root credential corresponding to the tenant identifier chain is generated to complete the establishment of the vehicle-cloud full-link trust root.

3. The multi-tenant end-to-end data security isolation and control method as described in claim 1, characterized in that, The steps for dynamically allocating MQTT topic partitions and transmission queues bound to TIDs for the vehicle terminal, and configuring access control rules, include: The access gateway of the vehicle-to-everything (V2X) ecosystem service platform receives access requests initiated by vehicle terminals and forwards them to the trusted authentication center of the V2X ecosystem service platform. After receiving the access request, the Trusted Authentication Center uses the vehicle-cloud end-to-end trust root as the verification basis and the tenant identifier chain as the authentication credential to initiate two-way identity authentication with the vehicle SE. The two-way identity authentication includes the cloud's authentication of the vehicle terminal's identity legitimacy and the vehicle terminal's authentication of the cloud's Trusted Authentication Center's platform identity legitimacy. After the trusted authentication center completes two-way identity authentication, if the authentication result is unsuccessful, it sends an access rejection command to the access gateway. If the authentication result is successful, an access permission instruction and the TID information to which the corresponding vehicle terminal belongs are sent to the access gateway. The access gateway dynamically allocates an MQTT topic partition and transmission queue bound to the TID for the vehicle terminal based on the corresponding TID. The access gateway automatically generates and configures access control rules for the allocated MQTT topic partitions, and synchronizes the binding relationship between the MQTT topic partitions and TIDs, as well as the corresponding access control rules, to each functional node of the vehicle-to-everything (V2X) ecosystem service platform.

4. The multi-tenant end-to-end data security isolation and control method as described in claim 3, characterized in that, The MQTT topic partition and transmission queue are used to carry the end-to-cloud uplink service transmission of streaming time-series vehicle control data collected by the vehicle terminal, as well as the cloud-to-end downlink service transmission of vehicle control commands and configuration information issued by the vehicle network ecosystem service platform to the vehicle terminal. It serves as the data transmission channel between the vehicle terminal and the vehicle network ecosystem service platform that is uniquely bound to the corresponding TID.

5. The multi-tenant end-to-end data security isolation and control method as described in claim 3, characterized in that, The access control rules refer to the access permission management rules formulated for MQTT topic partitions and effective on the vehicle networking ecosystem service platform. These rules include: clearly defining the scope of legitimate access subjects, clearly defining the permission boundaries of legitimate operations, and clearly defining absolutely prohibited access behaviors. They are used to perform real-time permission verification on all access behaviors of MQTT topic partitions.

6. The multi-tenant end-to-end data security isolation and control method as described in claim 1, characterized in that, Combining the tenant identifier chain, an endogenous identifier data frame is generated that embeds a time-series data fragment frame header. Simultaneously, a cyclic redundancy check (CRC) code is generated and appended to the end of the endogenous identifier data frame. After encryption, it is sent to the vehicle-to-everything (V2X) ecosystem service platform via MQTT topic partitioning, including: The irreversible hash verification value of the tenant identifier chain embedded in the vehicle SE is embedded in a fixed reserved position in the frame header of each time-series data segment to form an endogenous identifier data frame structure. Based on the irreversible hash check value of the tenant identifier chain and the plaintext content of the corresponding time-series data fragment, a cyclic redundancy check code covering the identity identifier and the full data is generated, and the cyclic redundancy check code is appended to a fixed position at the end of the intrinsic identifier data frame. After encrypting the irreversible hash check value of the tenant identifier chain in the header of the endogenous identifier data frame, a compliance check is performed. If the compliance check passes, it is sent to the vehicle network ecosystem service platform through the MQTT topic partition associated with the corresponding TID.

7. The multi-tenant end-to-end data security isolation and control method as described in claim 1, characterized in that, The channel attribution verification includes: determining whether the MQTT topic partition receiving the endogenous identifier data frame has been bound to the corresponding TID, and whether the access control rules of the MQTT topic partition are in a normal effective state; The identity legitimacy verification includes: extracting the irreversible hash check value of the tenant identifier chain encrypted in the frame header and the cyclic redundancy check code in the frame tail of the endogenous identifier data frame; decrypting the irreversible hash check value of the tenant identifier chain encrypted in the frame header; if the decryption is successful, after obtaining the irreversible hash check value of the tenant identifier chain, recalculating the cyclic redundancy check code based on the irreversible hash check value and the full plaintext content of the endogenous identifier data frame, and comparing it with the cyclic redundancy check code in the frame tail.

8. The multi-tenant end-to-end data security isolation and control method as described in claim 1, characterized in that, The time-series data processing node refers to the functional node on the vehicle network ecosystem service platform side used to receive, temporarily store, and preprocess streaming time-series vehicle control data, and used to receive the endogenous identifier data frames transmitted through the access gateway.

9. The multi-tenant end-to-end data security isolation and control method as described in claim 1, characterized in that, The logical storage partition refers to the independent storage unit corresponding to each TID, which is pre-created by the time-series database of the vehicle network ecosystem service platform based on the TID of each tenant. It is used to store all streaming time-series vehicle control data belonging to the corresponding TID. The time-series database refers to the database used by the vehicle-to-everything (V2X) ecosystem service platform to store streaming time-series vehicle control data; the storage engine layer of the time-series database is configured with an Access Control List (ACL) corresponding to the TID, which is used to prohibit access operations across logical storage partitions of TID; the logical storage partition is configured with independent data lifecycle management, backup and destruction rules.

10. The multi-tenant end-to-end data security isolation and control method as described in claim 1, characterized in that, The execution steps of the computation task include: The streaming computing engine of the vehicle-to-everything (V2X) ecosystem service platform pre-establishes a computing task thread pool for each tenant's TID, and configures CPU and memory resource quotas for the computing task thread pool, and divides the computing cache space and memory space. The streaming computing engine responds to the request for streaming time-series vehicle control data computing task initiated by the vehicle enterprise tenant, verifies the TID authorization status of the requesting tenant, and if the verification passes, binds the computing task to the TID of the requesting tenant. The streaming computing engine allocates a thread pool for computing tasks bound to a TID, automatically anchors the logical storage partition corresponding to the TID, and allows reading the endogenous identifier data frame in the logical storage partition anchored to the TID. After the computing task is started, the streaming computing engine reads the endogenous identifier data frame that meets the requirements of the computing task from the logical storage partition corresponding to the anchored TID, performs standardized computing operations, and performs three identity legality checks in the standardized computing operations to obtain the computing results.

11. The multi-tenant end-to-end data security isolation and control method as described in claim 10, characterized in that, The steps for performing the computation task also include: The streaming computing engine appends a frame structure with the same format as the intrinsic identifier data frame to the calculation result bound to the TID. Based on the TID hash value and the full content of the calculation result, a cyclic redundancy check code is generated and appended to a fixed position at the end of the frame to form the result data frame, which is then written to the calculation result sub-partition in the logical storage partition corresponding to the TID.

12. A multi-tenant end-to-end data security isolation and control system, used to implement the multi-tenant end-to-end data security isolation and control method according to any one of claims 1-11, characterized in that, This includes a tenant pre-configuration module, an access authentication module, an end-side binding module, a transmission verification module, a storage isolation and control module, and a compute isolation and control module. The tenant pre-configuration module is used to generate TIDs for car manufacturer tenants and DIDs for each vehicle under the corresponding car manufacturer tenant, thereby generating a tenant identification chain and solidifying it into the secure storage area of ​​the vehicle SE. It is also synchronized to the trusted authentication center of the vehicle-to-cloud ecosystem service platform to establish a root of trust for the entire vehicle-cloud link; The access authentication module is used to respond to the access request initiated by the vehicle terminal. The trusted authentication center completes two-way identity authentication with the vehicle terminal through the vehicle SE. If the authentication is successful, it dynamically allocates an MQTT topic partition and transmission queue bound to the TID for the vehicle terminal based on the TID in the tenant identifier chain, and configures access control rules. The end-side binding module is used to respond to data acquisition commands. The vehicle terminal acquires streaming time-series vehicle control data and performs fragmentation processing to generate time-series data fragments. Combined with the tenant identifier chain, an endogenous identifier data frame with an embedded time-series data fragment frame header is generated. At the same time, a cyclic redundancy check code is generated and appended to the frame tail of the endogenous identifier data frame. After encryption, it is sent to the vehicle network ecosystem service platform through the MQTT topic partition. The transmission verification module is used to receive the endogenous identifier data frame sent by the vehicle terminal, perform dual isolation verification, and if the verification passes, the endogenous identifier data frame is transparently transmitted to the time sequence data processing node. The storage isolation and control module is used to forward the endogenous identifier data frame to the logical storage partition of the time-series database corresponding to the TID for data compression, storage and index construction; The computation isolation and control module is used to respond to the request for streaming time-series vehicle control data computation task initiated by the tenant, automatically anchor the logical storage partition corresponding to the TID, allow reading the endogenous identifier data frame of the logical storage partition for executing the computation task, and perform three identity legality checks during the computation process, and write the computation result into the computation result sub-partition in the logical storage partition.

Images