Automobile cloud platform access method, system and device based on zero-trust architecture and medium

Abstract

The invention discloses an automobile cloud platform access method, system and device based on a zero-trust architecture and a medium, and the method comprises the steps: verifying a cloud platform connection request of a client, and building a secure session channel between the client and an automobile cloud platform when the verification is successful; obtaining a target operation behavior of the client through the secure session channel, and performing risk assessment on the target operation behavior according to the equipment state of the client to obtain a risk value of the target operation behavior; when the risk value is greater than or equal to a preset risk threshold value, performing risk operation verification on the client; and when the verification is passed, returning a response result corresponding to the target operation behavior through the automobile cloud platform. The security of accessing the cloud platform by the client is improved, and the method can be widely applied to the technical field of Internet of Vehicles.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle networking, and in particular to a method, system, device and medium for accessing an automotive cloud platform based on a zero-trust architecture. Background Art

[0002] In an automotive cloud platform, security authentication is required when a client (vehicle side and user side) accesses the cloud platform. For the vehicle side, a communication module, such as a 4G / 5G, Wi-Fi, etc. communication module, will be built into the vehicle when it leaves the factory for communicating with the automotive cloud platform. These communication modules follow specific communication protocols, such as the TCP / IP protocol family, etc., to establish a connection with the cloud platform; each vehicle will be assigned a unique identification code, such as a vehicle identification number (VIN), etc., during the production process. When the vehicle first connects to the cloud platform, information such as the VIN will be sent to the cloud platform for identity authentication. The cloud platform will query in its database whether the VIN is valid and registered. If the verification passes, the vehicle will be allowed to establish a connection with the cloud platform; otherwise, the connection request will be rejected. For the user side, the user needs to register on the mobile application or web page of the automotive cloud platform, fill in personal information and create an account. When the user logs in, the account and password used during registration need to be entered, and the platform will verify the user's identity. If the match is successful, the user will be allowed to log in; the user sends a request to the cloud platform through the mobile application or web page, such as querying the vehicle location, vehicle status information, etc. After receiving the request, the cloud platform will obtain the corresponding vehicle data from the database according to the content of the user's request and return it to the user.

[0003] The existing automotive cloud platform access solutions have the following problems:

[0004] 1) Single and easily cracked identity authentication: It mainly relies on the vehicle identification number (VIN) and simple account passwords for identity authentication, which are easily stolen, forged or cracked. Once this information is leaked, attackers may disguise themselves as legitimate vehicles or users and illegally access the cloud platform and vehicle data, resulting in security problems such as data leakage and malicious control of vehicles.

[0005] 2) Lack of dynamic authorization and risk assessment: Access permissions are usually assigned based on static user roles and vehicle identities, lacking the ability to evaluate real-time risks and dynamically adjust permissions. When the environment of the vehicle or user changes, such as the vehicle being stolen or the user's account being abnormally logged in, it is impossible to detect and adjust access permissions in a timely manner, easily leading to security vulnerabilities. Summary of the Invention

[0006] The purpose of the present invention is to solve at least to some extent one of the technical problems existing in the prior art.

[0007] To this end, an object of an embodiment of the present invention is to provide a method for accessing an automotive cloud platform based on a zero-trust architecture, which improves the security of a client accessing the cloud platform.

[0008] Another object of an embodiment of the present invention is to provide a system for accessing an automotive cloud platform based on a zero-trust architecture.

[0009] To achieve the above technical object, the technical solutions adopted in the embodiments of the present invention include:

[0010] In a first aspect, an embodiment of the present invention provides a method for accessing an automotive cloud platform based on a zero-trust architecture, including the following steps:

[0011] Verify the cloud platform connection request of the client. When the verification is successful, establish a secure session channel between the client and the automotive cloud platform;

[0012] Obtain the target operation behavior of the client through the secure session channel, and perform a risk assessment on the target operation behavior according to the device state of the client to obtain a risk value of the target operation behavior;

[0013] When the risk value is greater than or equal to a preset risk threshold, perform a risk operation verification on the client;

[0014] When the verification is passed, return a response result corresponding to the target operation behavior through the automotive cloud platform.

[0015] Further, in an embodiment of the present invention, verifying the cloud platform connection request of the client specifically includes:

[0016] Generate a first random number through the hardware security module of the client, and generate plaintext request data according to the first random number, the client identifier of the client, and a time stamp;

[0017] Sign the plaintext request data using a first private key built in the hardware security module to generate a session credential;

[0018] Encrypt the session credential and the plaintext request data using a second public key of the automotive cloud platform to generate the cloud platform connection request, and send the cloud platform connection request to the automotive cloud platform;

[0019] Decrypt the cloud platform connection request using a second private key corresponding to the second public key through the automotive cloud platform to obtain the session credential and the plaintext request data;

[0020] Determine the first random number, the client identifier, and the time stamp according to the plaintext request data;

[0021] Match the first public key corresponding to the first private key according to the client identifier, and use the first public key to verify the signature of the session credential;

[0022] When the signature verification is successful, perform timeliness verification according to the timestamp;

[0023] When the timeliness verification passes, determine that the cloud platform connection request verification is successful.

[0024] Further, in an embodiment of the present invention, the establishment of the secure session channel between the client and the vehicle cloud platform specifically includes:

[0025] Generate a second random number and a first temporary public-private key pair by the vehicle cloud platform, where the first temporary public-private key pair includes a first temporary public key and a first temporary private key;

[0026] Use the first public key to encrypt the second random number and the first temporary public key to obtain a first negotiation message, and return the first negotiation message to the client;

[0027] The client uses the first private key to decrypt the first negotiation message to obtain the second random number and the first temporary public key, and generates a second temporary public-private key pair, where the second temporary public-private key pair includes a second temporary public key and a second temporary private key;

[0028] Use the second public key to encrypt the second temporary public key to obtain a second negotiation message, and send the second negotiation message to the vehicle cloud platform;

[0029] The client generates a shared key according to the second temporary private key and the first temporary public key, and generates a session key according to the first random number, the second random number, and the shared key;

[0030] The vehicle cloud platform uses the second private key to decrypt the second negotiation message to obtain the second temporary public key, generates the shared key according to the first temporary private key and the second temporary public key, and generates the session key according to the first random number, the second random number, and the shared key;

[0031] Establish the secure communication channel according to the session key.

[0032] Further, in an embodiment of the present invention, the obtaining of the target operation behavior of the client through the secure session channel and the risk assessment of the target operation behavior according to the device state of the client to obtain the risk value of the target operation behavior specifically includes:

[0033] Obtain the session information of the client through the secure session channel, and extract the target operation behavior according to the session information;

[0034] Obtain the device status of the client, where the device status includes the IP address jump frequency, the API call time distribution, and the access token life cycle;

[0035] Generate an operation behavior sequence according to the target operation behavior, and input the device status and the operation behavior sequence into a pre-trained risk assessment model to obtain the risk value.

[0036] Further, in an embodiment of the present invention, the risk assessment model is trained through the following steps:

[0037] Obtain the device status sample data and the operation behavior sequence sample data of the test end, and determine the risk value label corresponding to the device status sample data and the operation behavior sequence sample data through manual annotation;

[0038] Construct a training sample according to the device status sample data and the operation behavior sequence sample data;

[0039] Input the training sample into a pre-constructed multi-branch hybrid neural network to obtain a risk prediction value;

[0040] Determine the loss value according to the risk prediction value and the risk value label;

[0041] Update the parameters of the multi-branch hybrid neural network through the backpropagation algorithm according to the loss value to obtain the trained risk assessment model;

[0042] Wherein, the multi-branch hybrid neural network includes an input layer, a CNN branch network, an LSTM branch network, a feature fusion layer, and a fully connected layer. The CNN branch network includes multiple convolutional layers and a spatial pyramid pooling layer, and the LSTM branch network includes a one-dimensional convolutional layer and a bidirectional LSTM layer.

[0043] Further, in an embodiment of the present invention, the inputting the training sample into a pre-constructed multi-branch hybrid neural network to obtain a risk prediction value specifically includes:

[0044] Input the device status sample data into the CNN branch network through the input layer, and input the operation behavior sequence sample data into the LSTM branch network;

[0045] Perform multi-scale convolution processing on the device status sample data through the multiple convolutional layers to obtain a multi-scale feature subgraph, and perform feature fusion on the multi-scale feature subgraph through the spatial pyramid pooling layer to obtain the device status feature;

[0046] The local temporal pattern extraction is performed on the sample data of the operation behavior sequence through the one-dimensional convolutional layer to obtain local temporal features, and the forward and backward temporal dependencies of the local temporal features are captured through the bidirectional LSTM layer to obtain operation behavior features;

[0047] The feature fusion layer performs feature fusion on the device state features and the operation behavior features to obtain fusion features;

[0048] The fully connected layer maps the fusion features to the sample label space to obtain the risk prediction value.

[0049] Further, in an embodiment of the present invention, the risk operation verification for the client specifically includes:

[0050] The biometric information of the operator is obtained through the biometric sensor set on the client, and the biometric information is sent to the vehicle cloud platform;

[0051] The vehicle cloud platform compares the biometric information with the identity authentication database stored locally to obtain the identity information of the operator;

[0052] According to the identity information and the preset permission rules, the operation permission of the operator is determined, and it is judged whether the target operation behavior conforms to the operation permission;

[0053] When the target operation behavior conforms to the operation permission, it is determined that the risk operation verification is passed;

[0054] When the target operation behavior does not conform to the operation permission, it is determined that the risk operation verification fails.

[0055] In a second aspect, an embodiment of the present invention provides a vehicle cloud platform access system based on a zero-trust architecture, including:

[0056] A session establishment module, configured to verify the cloud platform connection request of the client, and when the verification is successful, establish a secure session channel between the client and the vehicle cloud platform;

[0057] A risk assessment module, configured to obtain the target operation behavior of the client through the secure session channel, and perform a risk assessment on the target operation behavior according to the device state of the client to obtain the risk value of the target operation behavior;

[0058] An operation verification module, configured to perform risk operation verification on the client when the risk value is greater than or equal to a preset risk threshold;

[0059] A response module, configured to return a response result corresponding to the target operation behavior through the vehicle cloud platform when the verification is passed.

[0060] In a third aspect, an embodiment of the present invention provides a vehicle cloud platform access device based on a zero-trust architecture, including:

[0061] At least one processor;

[0062] At least one memory, configured to store at least one program;

[0063] When the at least one program is executed by the at least one processor, the at least one processor is caused to implement the above-mentioned vehicle cloud platform access method based on a zero-trust architecture.

[0064] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, in which a program executable by a processor is stored, and the program executable by the processor is used to execute the above-mentioned vehicle cloud platform access method based on a zero-trust architecture when executed by the processor.

[0065] The advantages and beneficial effects of the present invention will be partially given in the following description, partially will become obvious from the following description, or will be understood through the practice of the present invention:

[0066] In the embodiment of the present invention, the cloud platform connection request of the client is verified. When the verification is successful, a secure session channel between the client and the vehicle cloud platform is established. The target operation behavior of the client is obtained through the secure session channel, and the risk of the target operation behavior is evaluated according to the device state of the client to obtain the risk value of the target operation behavior. When the risk value is greater than or equal to a preset risk threshold, a risk operation verification is performed on the client. When the verification is passed, a response result corresponding to the target operation behavior is returned through the vehicle cloud platform. In the embodiment of the present invention, the cloud platform connection request of the client is verified when the client connects to the vehicle cloud platform, and the operation behavior of the client is continuously and dynamically risk-evaluated when the client interacts with the vehicle cloud platform. When the risk value is greater than the preset risk threshold, a risk operation verification is performed to ensure that only the operation behavior that meets the identity permissions can obtain the response of the vehicle cloud platform, improving the security of the client accessing the cloud platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following introduces the drawings required to be used in the embodiments of the present invention. It should be understood that the drawings introduced below only conveniently and clearly represent some embodiments of the technical solutions in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative efforts.

[0068] Figure 1Flowchart of steps of a method for accessing an automotive cloud platform based on a zero-trust architecture provided by an embodiment of the present invention;

[0069] Figure 2 Schematic diagram of a structure of a multi-branch hybrid neural network provided by an embodiment of the present invention;

[0070] Figure 3 Block diagram of a structure of a system for accessing an automotive cloud platform based on a zero-trust architecture provided by an embodiment of the present invention;

[0071] Figure 4 Block diagram of a structure of a device for accessing an automotive cloud platform based on a zero-trust architecture provided by an embodiment of the present invention. Detailed implementation manners

[0072] The embodiments of the present invention will be described in detail below. Examples of the embodiments are shown in the accompanying drawings, where the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the accompanying drawings are exemplary only for explaining the present invention and should not be construed as limiting the present invention. For the step numbers in the following embodiments, they are only set for the convenience of elaboration and explanation, and no limitation is imposed on the order between the steps. The execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0073] In the description of the present invention, "a plurality of" means two or more. If there is a description of "first" and "second", it is only for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance or implicitly indicating the quantity of the indicated technical features or implicitly indicating the sequence of the indicated technical features. In addition, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the technical field to which this application belongs.

[0074] Refer to Figure 1 , an embodiment of the present invention provides a method for accessing an automotive cloud platform based on a zero-trust architecture, specifically including the following steps:

[0075] S101. Verify the cloud platform connection request of the client. When the verification is successful, establish a secure session channel between the client and the automotive cloud platform;

[0076] S102. Obtain the target operation behavior of the client through the secure session channel, and perform a risk assessment on the target operation behavior according to the device state of the client to obtain the risk value of the target operation behavior;

[0077] S103. When the risk value is greater than or equal to a preset risk threshold, perform a risk operation verification on the client;

[0078] S104. When the verification passes, return the response result corresponding to the target operation behavior through the vehicle cloud platform.

[0079] Specifically, the zero-trust architecture emphasizes "never trust, always verify". In the embodiments of the present invention, the traditional static trust mode based on a single identity identifier (such as VIN code, simple account password) is abandoned, and strict identity verification and dynamic authorization are performed on each interaction request between the vehicle, the user and the cloud platform. Combining means such as multi-factor authentication and continuous risk assessment to ensure that only legitimate requests can access cloud resources.

[0080] For the vehicle side, equip each vehicle with a dedicated hardware security module (HSM). An internal unique encryption key is installed. When the vehicle interacts with the cloud platform, the HSM generates a single-encrypted session credential, which can only be verified by the cloud platform through a specific decryption algorithm; install biometric sensors (such as fingerprint recognition, face recognition) in the vehicle, and compare the biometric information with the stored template during risky operations to further enhance the security of vehicle-side identity authentication.

[0081] For the user side, when the user logs in to the mobile application or web page of the cloud platform, in addition to entering the preset password, the system will send a one-time SMS verification code to the user's registered mobile phone. The user can log in only after entering the correct verification code; issue a digital certificate to the user, which can be stored in the secure area of the mobile phone (such as TEE, trusted execution environment). When performing important operations (such as remotely controlling the vehicle), the user is required to use the digital certificate for signature verification to ensure the authenticity and integrity of the operation.

[0082] The cloud uses a secure access proxy (SDP). As the intermediate layer of access, the SDP hides the real IP address and service port of the cloud platform. When a user-side or vehicle-side access request is initiated, the SDP first authenticates and authorizes it, and only requests that pass the verification can establish a connection with the cloud platform.

[0083] In the embodiments of the present invention, when the client connects to the vehicle cloud platform, the cloud platform connection request of the client is verified, and a continuous and dynamic risk assessment is performed on the operation behavior of the client when the client interacts with the vehicle cloud platform. When the risk value is greater than the preset risk threshold, risk operation verification is performed to ensure that only operation behaviors that meet the identity permissions can obtain a response from the vehicle cloud platform, improving the security of the client accessing the cloud platform.

[0084] Further as an optional implementation manner, verifying the cloud platform connection request of the client specifically includes:

[0085] A1. Generate a first random number through the hardware security module of the client, and generate plaintext request data according to the first random number, the client identifier of the client, and the timestamp;

[0086] A2. Sign the plaintext request data with the first private key built in the hardware security module to generate a session credential;

[0087] A3. Encrypt the session credential and the plaintext request data with the second public key of the vehicle cloud platform to generate a cloud platform connection request, and send the cloud platform connection request to the vehicle cloud platform;

[0088] A4. Decrypt the cloud platform connection request by the vehicle cloud platform using the second private key corresponding to the second public key to obtain the session credential and the plaintext request data;

[0089] A5. Determine the first random number, the client identifier, and the timestamp according to the plaintext request data;

[0090] A6. Match the first public key corresponding to the first private key according to the client identifier, and verify the signature of the session credential using the first public key;

[0091] A7. When the signature verification is successful, perform timeliness verification according to the timestamp;

[0092] A8. When the timeliness verification passes, determine that the cloud platform connection request verification is successful.

[0093] Specifically, verifying the cloud platform connection request of the client includes client-side operations and vehicle cloud platform-side operations, which are as follows:

[0094] 1. Client-side operations

[0095] 1) Generate the first random number and the plaintext request data

[0096] The client generates a first random number with the help of its hardware security module (HSM). This random number is unique and unpredictable, which can enhance the security of subsequent data. Then, the client combines the first random number, its own client identifier, and the current timestamp to generate the plaintext request data. The client identifier is the unique identifier of the client, which is used to identify the client in the vehicle cloud platform; the timestamp records the time when the request is initiated, which is used for subsequent timeliness verification.

[0097] 2) Generate the session credential

[0098] The client uses the first private key built in the hardware security module to sign the previously generated plaintext request data. Signing is a mathematical operation that encrypts the data with the private key to generate a unique signature value, that is, the session credential. This session credential can guarantee the integrity and authenticity of the plaintext request data, and prevent the data from being tampered with during the transmission process.

[0099] 3) Encrypt and send the cloud platform connection request

[0100] The client obtains the second public key of the vehicle cloud platform, uses this second public key to encrypt the session credential and the plaintext request data, and generates a cloud platform connection request. Public key encryption is an asymmetric encryption method, and only the corresponding second private key can decrypt the encrypted data. Finally, the client sends the encrypted cloud platform connection request to the vehicle cloud platform.

[0101] 2. Operations on the vehicle cloud platform side

[0102] 1) Decrypt the cloud platform connection request

[0103] After receiving the cloud platform connection request sent by the client, the vehicle cloud platform uses the second private key corresponding to the second public key to decrypt it. After decryption, the vehicle cloud platform can obtain the session credential and the plaintext request data.

[0104] 2) Extract key information

[0105] The vehicle cloud platform extracts the first random number, the client identifier, and the timestamp from the decrypted plaintext request data. These pieces of information will be used in subsequent verification steps.

[0106] 3) Signature verification operation

[0107] Based on the extracted client identifier, the vehicle cloud platform matches in its database to obtain the first public key corresponding to the first private key of this client. Then, it uses the first public key to verify the signature of the session credential. The signature verification process is to verify whether the signature is generated by the corresponding first private key and whether the plaintext request data has been tampered with during transmission. If the signature verification is successful, it indicates that the integrity and authenticity of the data are guaranteed.

[0108] 4) Timeliness verification

[0109] When the signature verification is successful, the vehicle cloud platform performs timeliness verification based on the extracted timestamp. The purpose of timeliness verification is to ensure that the request is initiated within a valid time and prevent replay attacks. For example, if the timestamp of the request differs from the current time by more than a certain threshold, the request is considered expired.

[0110] 5) Determine the verification result

[0111] If the timeliness verification passes, the vehicle cloud platform determines that the cloud platform connection request verification is successful. At this time, a secure connection can be established between the client and the vehicle cloud platform for subsequent data interaction. If the signature verification fails or the timeliness verification fails, it is considered that the cloud platform connection request verification fails, and the vehicle cloud platform will reject the connection request.

[0112] Furthermore, as an optional implementation manner, a secure session channel between the client and the vehicle cloud platform is established, which specifically includes:

[0113] B1. Generate a second random number and a first temporary public-private key pair through the vehicle cloud platform. The first temporary public-private key pair includes a first temporary public key and a first temporary private key;

[0114] B2. Encrypt the second random number and the first temporary public key using the first public key to obtain a first negotiation message, and return the first negotiation message to the client;

[0115] B3. The client decrypts the first negotiation message using the first private key to obtain the second random number and the first temporary public key, and generates a second temporary public-private key pair. The second temporary public-private key pair includes a second temporary public key and a second temporary private key;

[0116] B4. Encrypt the second temporary public key using the second public key to obtain a second negotiation message, and send the second negotiation message to the vehicle cloud platform;

[0117] B5. The client generates a shared key based on the second temporary private key and the first temporary public key, and generates a session key based on the first random number, the second random number, and the shared key;

[0118] B6. The vehicle cloud platform decrypts the second negotiation message using the second private key to obtain the second temporary public key, generates a shared key based on the first temporary private key and the second temporary public key, and generates a session key based on the first random number, the second random number, and the shared key;

[0119] B7. Establish a secure communication channel based on the session key.

[0120] Specifically, the session key is determined through session negotiation between the client and the vehicle cloud platform, thereby establishing a secure communication channel. The specific process is as follows:

[0121] 1. Initial operation of the vehicle cloud platform

[0122] 1) Generate a random number and a public-private key pair

[0123] The vehicle cloud platform starts the key negotiation process. First, it generates a second random number, which is a randomly generated value used to increase the randomness and security in the subsequent key generation process. At the same time, the platform generates a first temporary public-private key pair, which includes a first temporary public key and a first temporary private key. The public key can be made public, while the private key is secretly stored by the platform.

[0124] 2) Encrypt and generate the first negotiation message

[0125] The vehicle cloud platform obtains the first public key of the client (this public key is pre-published by the client) and uses this first public key to encrypt the second random number and the first temporary public key. The purpose of encryption is to ensure the confidentiality of data during transmission and prevent information leakage. The encrypted data combination forms the first negotiation message.

[0126] 3) Return the first negotiation message

[0127] The vehicle cloud platform sends the first negotiation message back to the client, initiating the key negotiation interaction between the two parties.

[0128] 2. The client processes the first negotiation message

[0129] 1) Decrypt the first negotiation message

[0130] After receiving the first negotiation message, the client uses its own first private key (the private key paired with the first public key) to decrypt it. Through decryption, the client successfully obtains the second random number and the first temporary public key of the vehicle cloud platform.

[0131] 2) Generate a second temporary public-private key pair

[0132] After obtaining the relevant information, the client generates a second temporary public-private key pair, including a second temporary public key and a second temporary private key. Similarly, the second temporary public key is used for subsequent transmission, and the second temporary private key is secretly saved by the client.

[0133] 3. The client generates and sends the second negotiation message

[0134] 1) Encrypt to generate the second negotiation message

[0135] The client obtains the second public key of the vehicle cloud platform (previously announced) and uses this second public key to encrypt its own generated second temporary public key. The encrypted result forms the second negotiation message.

[0136] 2) Send the second negotiation message

[0137] The client sends the second negotiation message to the vehicle cloud platform to continue the key negotiation process.

[0138] 4. The client generates the session key

[0139] 1) Generate the shared key

[0140] The client uses its own second temporary private key and the first temporary public key obtained from the vehicle cloud platform to generate a shared key through a specific key exchange algorithm (such as the Diffie-Hellman algorithm). This shared key is an intermediate key between the client and the vehicle cloud platform, and only the two parties can calculate it through their respective private keys and the other party's public key.

[0141] 2) Generate the session key

[0142] The client combines the first random number, the second random number, and the just-generated shared key to generate the session key according to a certain key derivation function. The session key will be used for subsequent secure communication between the two parties.

[0143] 5. The vehicle cloud platform generates a session key

[0144] 1) Decrypt the second negotiation message

[0145] After receiving the second negotiation message sent by the client, the vehicle cloud platform decrypts it using its own second private key to obtain the client's second temporary public key.

[0146] 2) Generate a shared key

[0147] The vehicle cloud platform uses its own first temporary private key and the client's second temporary public key to generate a shared key through the same key exchange algorithm. This shared key is the same as the shared key generated by the client.

[0148] 3) Generate a session key

[0149] The vehicle cloud platform also combines the first random number, the second random number, and the shared key to generate a session key according to the same key derivation function, ensuring consistency with the session key generated by the client.

[0150] 6. Establish a secure communication channel

[0151] After both the client and the vehicle cloud platform generate the same session key, they use this session key to establish a secure communication channel. In this channel, both parties can conduct encrypted communication to ensure the confidentiality, integrity, and authenticity of data during transmission, preventing information from being stolen, tampered with, or forged.

[0152] The above describes the process of key negotiation and secure channel establishment. It can be recognized that the embodiments of the present invention ensure the secure exchange of information between the client and the vehicle cloud platform through multiple encryption, decryption, and key generation operations.

[0153] Further, as an optional implementation manner, obtain the target operation behavior of the client through the secure session channel, and perform a risk assessment on the target operation behavior according to the device state of the client to obtain the risk value of the target operation behavior, which specifically includes:

[0154] S1021. Obtain the session information of the client through the secure session channel, and extract the target operation behavior according to the session information;

[0155] S1022. Obtain the device state of the client, where the device state includes the IP address jump frequency, the API call time distribution, and the access token life cycle;

[0156] S1023. Generate an operation behavior sequence according to the target operation behavior, and input the device state and the operation behavior sequence into a pre-trained risk assessment model to obtain the risk value.

[0157] Specifically, session information of the client is extracted from the secure session channel, including session identifiers, operation logs, and context information, so as to determine the current target operation behavior; the real IP of the client is obtained by parsing the HTTP header (such as X-Forwarded-For7) or the network layer protocol, and the number of IP changes within a unit time is counted to obtain the IP address hopping frequency; the time pattern of the client's operation requests is analyzed to obtain the API call time distribution; the validity period of the client's Token is monitored to obtain the access token lifecycle; the discrete operations of the client are converted into time series data, for example, login → query data → download file → logout. It should be noted that every time the client has an operation behavior, it is necessary to perform behavior sequence modeling on all the previous operation behaviors and the current operation behavior of the current session; the IP address hopping frequency, API call time distribution, access token lifecycle, and operation behavior sequence are input into a pre-trained risk assessment model to obtain a risk value.

[0158] Further as an optional implementation manner, the risk assessment model is trained through the following steps:

[0159] S201. Obtain the device status sample data and operation behavior sequence sample data of the test end, and determine the risk value labels corresponding to the device status sample data and operation behavior sequence sample data through manual annotation;

[0160] S202. Construct training samples according to the device status sample data and operation behavior sequence sample data;

[0161] S203. Input the training samples into a pre-constructed multi-branch hybrid neural network to obtain a risk prediction value;

[0162] S204. Determine the loss value according to the risk prediction value and the risk value label;

[0163] S205. Update the parameters of the multi-branch hybrid neural network through the backpropagation algorithm according to the loss value to obtain a trained risk assessment model;

[0164] Among them, the multi-branch hybrid neural network includes an input layer, a CNN branch network, an LSTM branch network, a feature fusion layer, and a fully connected layer. The CNN branch network includes multiple convolutional layers and a spatial pyramid pooling layer, and the LSTM branch network includes a one-dimensional convolutional layer and a bidirectional LSTM layer.

[0165] Further as an optional implementation manner, inputting the training samples into a pre-constructed multi-branch hybrid neural network to obtain a risk prediction value specifically includes:

[0166] S2031. Input the device status sample data into the CNN branch network through the input layer, and input the operation behavior sequence sample data into the LSTM branch network;

[0167] S2032. Perform multi-scale convolution processing on the device status sample data through multiple convolutional layers to obtain multi-scale feature subgraphs, and perform feature fusion on the multi-scale feature subgraphs through the spatial pyramid pooling layer to obtain device status features;

[0168] S2033. Extract local temporal patterns from the operation behavior sequence sample data through a one-dimensional convolutional layer to obtain local temporal features, and capture the forward and backward temporal dependencies of the local temporal features through a bidirectional LSTM layer to obtain operation behavior features;

[0169] S2034. Perform feature fusion on the device status features and the operation behavior features through a feature fusion layer to obtain fused features;

[0170] S2035. Map the fused features to the sample label space through a fully connected layer to obtain risk prediction values.

[0171] Specifically, as Figure 2 shown in the structural schematic diagram of a multi-branch hybrid neural network provided by an embodiment of the present invention, combined with Figure 2 , the specific training process of the risk assessment model in the embodiment of the present invention is as follows:

[0172] 1. Data acquisition and annotation

[0173] Collect device status sample data and operation behavior sequence sample data from the test end. The device status sample data includes the IP address jump frequency, API call time distribution, and access token lifecycle at the test end; the operation behavior sequence sample data records the sequence data of operation behavior requests sent by the test end to the vehicle cloud platform.

[0174] Organize professional personnel to manually annotate the collected data, and determine the corresponding risk value labels for each group of device status sample data and operation behavior sequence sample data. The risk value labels can be discrete categories (such as low risk, medium risk, high risk), or continuous numerical values (such as risk probabilities between 0 and 1). Clear annotation rules and standards need to be formulated during the annotation process to ensure the consistency and accuracy of the annotation results.

[0175] 2. Training sample construction

[0176] Preprocess the obtained device status sample data and operation behavior sequence sample data, including data cleaning (removing missing values and outliers), normalization (unifying the data to the same scale range), etc.

[0177] Combine the processed data into training samples according to a certain format. The device status sample data and the operation behavior sequence sample data can be used as different feature dimensions respectively to construct a multi-dimensional training sample matrix. For example, for each sample, the first part of the dimensions represents the device status data, and the second part represents the operation behavior sequence data.

[0178] 3. Construction of Multi-branch Hybrid Neural Network

[0179] 1) Input layer: The input layer receives the training sample data, and the number of its neurons is determined according to the feature dimensions of the training samples.

[0180] 2) CNN branch network:

[0181] Multi-layer convolutional layer: Perform convolutional operations on the input data to extract local features. The convolutional layer slides different convolutional kernels on the input data to perform convolutional operations and obtain feature maps. Multiple convolutional layers can be set to gradually extract more advanced features.

[0182] Spatial pyramid pooling layer: Perform pooling operations on the feature maps output by the convolutional layer to convert feature maps of different scales into fixed-length feature vectors to meet the input requirements of the subsequent network.

[0183] 3) LSTM branch network:

[0184] One-dimensional convolutional layer: Perform convolutional operations on the input operation behavior sequence data to extract local features in the sequence.

[0185] Bidirectional LSTM layer: Bidirectional LSTM can consider both the past and future information of the sequence at the same time to better capture the temporal dependencies in the operation behavior sequence.

[0186] 4) Feature fusion layer: Fuse the feature vectors output by the CNN branch network and the LSTM branch network. Methods such as concatenation and weighted summation can be used to obtain the fused feature vectors.

[0187] 5) Fully connected layer: Input the fused feature vectors into the fully connected layer. Through a series of linear transformations and non-linear activation functions, map the features to the output space of the risk prediction value.

[0188] 4. Risk Prediction and Loss Calculation

[0189] Risk prediction: Input the training samples into the pre-constructed multi-branch hybrid neural network, and through the forward propagation process of the network, calculate the risk prediction value.

[0190] Loss calculation: Based on the risk prediction value and the risk value label manually marked, select an appropriate loss function to calculate the loss value. For classification problems, the cross-entropy loss function can be used; for regression problems, the mean squared error loss function can be used.

[0191] 5. Model parameter update

[0192] According to the calculated loss value, use the backpropagation algorithm to calculate the gradients of the loss function with respect to each parameter in the network.

[0193] According to the gradient information, use an optimization algorithm (such as stochastic gradient descent, Adam, etc.) to update the parameters of the multi-branch hybrid neural network to reduce the loss value.

[0194] Repeat steps 4 - 5 for multiple iterative trainings until the loss value converges or reaches the preset number of training epochs to obtain a trained risk assessment model.

[0195] Through the above steps, the training process of the risk assessment model can be completed, and thus the trained model can be used to perform risk assessment on the device status and operation behavior sequence of the client obtained in real time.

[0196] Further, as an optional implementation manner, risk operation verification is performed on the client, which specifically includes:

[0197] S1031. Obtain the biometric information of the operator through the biometric sensor set on the client and send the biometric information to the vehicle cloud platform;

[0198] S1032. Compare the biometric information with the identity authentication database stored locally through the vehicle cloud platform to obtain the identity information of the operator;

[0199] S1033. Determine the operation permission of the operator according to the identity information and the preset permission rules, and judge whether the target operation behavior conforms to the operation permission;

[0200] S1034. When the target operation behavior conforms to the operation permission, determine that the risk operation verification passes;

[0201] S1035. When the target operation behavior does not conform to the operation permission, determine that the risk operation verification fails.

[0202] Specifically, when the risk value of the target operation behavior is greater than the preset risk threshold, risk operation authentication is triggered, and the specific process is as follows:

[0203] 1. Biometric collection and transmission

[0204] The client collects the user's biometric characteristics through biometric sensors (fingerprint recognition module, infrared camera or iris scanner) integrated in the in-vehicle system (such as the steering wheel). For example: after the fingerprint sensor obtains the fingerprint image, an image enhancement algorithm is used to optimize the feature point extraction and generate an encrypted feature vector.

[0205] The feature data is encrypted and transmitted to the automotive cloud platform through a secure communication channel. During the process, two-way certificate verification is used to ensure communication security. For example: an SSL certificate is used to encrypt the transmission channel to prevent man-in-the-middle attacks.

[0206] 2. Cloud identity matching and verification

[0207] After receiving the data, the cloud platform calls a biometric comparison engine (such as a deep learning model) to perform 1:N matching of the real-time collected data with the pre-stored template library. The iris recognition system will extract a 256-bit feature code through an iris localization algorithm and calculate the similarity with the feature vector in the database.

[0208] The database adopts a hierarchical storage architecture. The main index is the user ID, and the secondary index contains the biometric hash value. After successful matching, an identity token containing extended attributes such as user role and device binding records is generated.

[0209] 3. Dynamic permission determination mechanism

[0210] After parsing the identity token, the permission engine performs permission determination in combination with the RBAC (Role-Based Access Control) and ABAC (Attribute-Based Access Control) models. For example: an ordinary car owner role can start the vehicle but cannot modify ECU parameters, while a maintenance technician role requires additional verification of the work order validity period.

[0211] The preset permission rule library contains more than 300 policies, such as "engine overclocking operation requires secondary administrator permission + biometric verification + geographical location verification". The system continuously compares the matching degree between the target operation (such as an OTA upgrade request) and the permission matrix.

[0212] 4. Determine the verification result

[0213] When the target operation behavior conforms to the operator's operation permissions, it is determined that the risk operation verification passes; when the target operation behavior does not conform to the operator's operation permissions, it is determined that the risk operation verification fails.

[0214] It should be noted that after the risk operation verification passes, the automotive cloud platform can return the corresponding response result according to the target operation behavior of the client to complete the interaction between the client and the automotive cloud platform.

[0215] The above has described the method steps of the embodiments of the present invention. It can be understood that in the embodiments of the present invention, when the client connects to the vehicle cloud platform, the cloud platform connection request of the client is verified, and when the client interacts with the vehicle cloud platform, a continuous and dynamic risk assessment is carried out on the operation behavior of the client. When the risk value is greater than the preset risk threshold, a risk operation verification is carried out to ensure that only the operation behaviors that meet the identity permissions can obtain the response of the vehicle cloud platform, improving the security of the client accessing the cloud platform.

[0216] Compared with the prior art, the embodiments of the present invention also have the following advantages:

[0217] 1) Dynamic authorization and continuous verification: Traditional access mechanisms are mostly based on static identity authentication and authorization. Once a user or device passes the authentication, a certain set of permissions is granted, and the permissions remain basically unchanged during the entire session. In contrast, the zero-trust architecture emphasizes continuous identity verification and authorization. Whether at the initial stage of access or during the access process, it will continuously evaluate based on multi-dimensional information such as user behavior and device status, and dynamically adjust access permissions in real time, enabling timely detection and blocking of abnormal behaviors and potential attacks.

[0218] 2) Breaking the trust of network boundaries: Traditional access mechanisms usually default that the internal network is secure and have relatively loose reviews of access requests from the internal network. The zero-trust architecture breaks this absolute trust in network boundaries. Whether the access request comes from the internal or external network, it must go through strict identity verification and authorization, effectively preventing internal threats and security risks caused by the breach of network boundaries.

[0219] Referring to Figure 3 , the embodiments of the present invention provide a vehicle cloud platform access system based on the zero-trust architecture, including:

[0220] A session establishment module, configured to verify the cloud platform connection request of the client, and when the verification is successful, establish a secure session channel between the client and the vehicle cloud platform;

[0221] A risk assessment module, configured to obtain the target operation behavior of the client through the secure session channel, and perform a risk assessment on the target operation behavior according to the device state of the client to obtain the risk value of the target operation behavior;

[0222] An operation verification module, configured to perform a risk operation verification on the client when the risk value is greater than or equal to the preset risk threshold;

[0223] A response module, configured to return the response result corresponding to the target operation behavior through the vehicle cloud platform when the verification is passed.

[0224] The content in the above method embodiments is applicable to the system embodiments of the present invention. The functions specifically implemented by the system embodiments of the present invention are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those of the above method embodiments.

[0225] Referring to Figure 4 , an embodiment of the present invention provides an access device for an automotive cloud platform based on a zero-trust architecture, including:

[0226] At least one processor;

[0227] At least one memory for storing at least one program;

[0228] When the above at least one program is executed by the above at least one processor, the above at least one processor implements the above method for accessing an automotive cloud platform based on a zero-trust architecture.

[0229] The content in the above method embodiments is applicable to the device embodiments of the present invention. The functions specifically implemented by the device embodiments of the present invention are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those of the above method embodiments.

[0230] An embodiment of the present invention also provides a computer-readable storage medium, in which a program executable by a processor is stored. The program executable by the processor is used to execute the above method for accessing an automotive cloud platform based on a zero-trust architecture when executed by the processor.

[0231] A computer-readable storage medium according to an embodiment of the present invention can execute a method for accessing an automotive cloud platform based on a zero-trust architecture provided by the method embodiment of the present invention, can execute any combination of implementation steps of the method embodiment, and has the corresponding functions and beneficial effects of the method.

[0232] An embodiment of the present invention also discloses a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes Figure 1 the method shown.

[0233] In some alternative embodiments, the functions / operations recited in the block diagrams may not occur in the order presented in the operational illustrations. For example, depending on the functions / operations involved, two blocks shown in succession may actually be executed substantially simultaneously or the blocks may sometimes be executed in the reverse order. Further, the embodiments presented and described in the flowcharts of the present invention are provided by way of example in order to provide a more thorough understanding of the technology. The disclosed methods are not limited to the operations and logical flows presented herein. Alternative embodiments are envisioned in which the order of various operations is altered and in which sub-operations described as part of a larger operation are performed independently.

[0234] Moreover, although the present invention has been described in the context of functional modules, it should be understood that, unless otherwise stated to the contrary, one or more of the above-described functions and / or features may be integrated in a single physical device and / or software module, or one or more functions and / or features may be implemented in separate physical devices or software modules. It should also be understood that a detailed discussion of the actual implementation of each module is not necessary for an understanding of the present invention. Rather, given the attributes, functions, and internal relationships of the various functional modules in the devices disclosed herein, the actual implementation of the modules will be understood within the ordinary skill of an engineer. Accordingly, those of ordinary skill in the art will be able to implement the present invention as set forth in the claims without undue experimentation. It should also be understood that the particular concepts disclosed are illustrative only and are not intended to limit the scope of the present invention, the scope of which is determined by the full scope of the appended claims and their equivalents.

[0235] If the above functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art or part of the technical solution can be embodied in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the above methods of various embodiments of the present invention. The foregoing storage medium includes: various media that can store program codes, such as a USB flash drive, a portable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disc.

[0236] The logic and / or steps represented in the flowchart or otherwise described herein can, for example, be considered as a definitional sequence of executable instructions for implementing logical functions, which can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, a system including a processor, or other systems that can fetch and execute instructions from the instruction execution system, apparatus, or device. As used in this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by or in connection with the instruction execution system, apparatus, or device.

[0237] More specific examples (non-exhaustive list) of computer-readable media include the following: an electrical connection (electronic device) having one or more wirings, a portable computer diskette (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium can even be paper or other suitable media on which the above program can be printed, as the above program can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpretation, or other suitable processing as necessary, and then stored in a computer memory.

[0238] It should be understood that various parts of the present invention can be implemented by hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, any one or a combination of the following techniques well known in the art can be used: discrete logic circuits having logic gate circuits for implementing logical functions on data signals, application specific integrated circuits having appropriate combinational logic gate circuits, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0239] In the above description of this specification, the descriptions referring to the terms "one embodiment / example", "another embodiment / example", or "certain embodiments / examples", etc. mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0240] Although embodiments of the present invention have been shown and described, those of ordinary skill in the art can understand that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the claims and their equivalents.

[0241] The above has specifically described the preferred embodiments of the present invention, but the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent deformations or substitutions without departing from the spirit of the present invention, and these equivalent deformations or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A method for accessing an automobile cloud platform based on a zero-trust architecture, characterized in that: The following steps are involved: Verify the client's cloud platform connection request, and when the verification is successful, establish a secure session channel between the client and the automotive cloud platform; Acquire the target operation behavior of the client through the secure session channel, and perform risk assessment on the target operation behavior according to the device status of the client to obtain a risk value of the target operation behavior; When the risk value is greater than or equal to a preset risk threshold, performing risk operation verification on the client; When the verification is successful, the automobile cloud platform returns a response result corresponding to the target operation behavior.

2. According to claim 1, a method for accessing an automobile cloud platform based on a zero-trust architecture is characterized in that: Verify the client's cloud platform connection request, including: Generate a first random number through a hardware security module of the client, and generate plaintext request data according to the first random number, a client identifier of the client, and a timestamp; Sign the plaintext request data using the first private key built into the hardware security module to generate a session credential; encrypting the session credential and the plaintext request data using a second public key of the automotive cloud platform, generating the cloud platform connection request, and sending the cloud platform connection request to the automotive cloud platform; Decrypting the cloud platform connection request by the automobile cloud platform using the second private key corresponding to the second public key to obtain the session credential and the plaintext request data; Determine the first random number, the client identifier, and the timestamp according to the plaintext request data; Obtaining a first public key corresponding to the first private key according to the client identifier, and using the first public key to verify the signature of the session credential; When the signature verification succeeds, the validity is verified according to the timestamp; When the validity verification is passed, it is determined that the cloud platform connection request verification is successful.

3. The method for accessing an automobile cloud platform based on a zero-trust architecture according to claim 2, characterized in that: The step of establishing a secure session channel between the client and the automotive cloud platform specifically includes: Generate a second random number and a first temporary public-private key pair through the automobile cloud platform, wherein the first temporary public-private key pair includes a first temporary public key and a first temporary private key; Using the first public key to encrypt the second random number and the first temporary public key to obtain a first negotiation message, and returning the first negotiation message to the client; Decrypting the first negotiation message by the client using the first private key to obtain the second random number and the first temporary public key, and generating a second temporary public-private key pair, where the second temporary public-private key pair includes a second temporary public key and a second temporary private key; Using the second public key to encrypt the second temporary public key to obtain a second negotiation message, and sending the second negotiation message to the automobile cloud platform; Generate a shared key by the client according to the second temporary private key and the first temporary public key, and generate a session key according to the first random number, the second random number and the shared key; decrypting the second negotiation message by using the second private key through the automobile cloud platform to obtain the second temporary public key, generating the shared key according to the first temporary private key and the second temporary public key, and generating the session key according to the first random number, the second random number and the shared key; The secure communication channel is established based on the session key.

4. The method for accessing an automobile cloud platform based on a zero-trust architecture according to claim 1, characterized in that: The step of obtaining the target operation behavior of the client through the secure session channel and performing risk assessment on the target operation behavior according to the device status of the client to obtain a risk value of the target operation behavior specifically includes: Acquiring session information of the client through the secure session channel, and extracting the target operation behavior according to the session information; Obtaining the device status of the client, the device status including IP address hopping frequency, API call time distribution and access token life cycle; An operation behavior sequence is generated according to the target operation behavior, and the device state and the operation behavior sequence are input into a pre-trained risk assessment model to obtain the risk value.

5. The method for accessing an automobile cloud platform based on a zero-trust architecture according to claim 4, characterized in that: The risk assessment model is trained by the following steps: Acquire device status sample data and operation behavior sequence sample data of the test end, and determine risk value labels corresponding to the device status sample data and the operation behavior sequence sample data through manual labeling; Constructing a training sample according to the device state sample data and the operation behavior sequence sample data; Inputting the training samples into a pre-built multi-branch hybrid neural network to obtain a risk prediction value; Determine a loss value according to the risk prediction value and the risk value label; According to the loss value, the parameters of the multi-branch hybrid neural network are updated through a back propagation algorithm to obtain the trained risk assessment model; Among them, the multi-branch hybrid neural network includes an input layer, a CNN branch network, an LSTM branch network, a feature fusion layer and a fully connected layer. The CNN branch network includes multi-layer convolutional layers and spatial pyramid pooling layers, and the LSTM branch network includes a one-dimensional convolutional layer and a bidirectional LSTM layer.

6. The method for accessing an automobile cloud platform based on a zero-trust architecture according to claim 5, characterized in that: The step of inputting the training sample into a pre-built multi-branch hybrid neural network to obtain a risk prediction value specifically includes: Input the device status sample data into the CNN branch network through the input layer, and input the operation behavior sequence sample data into the LSTM branch network; Performing multi-scale convolution processing on the device state sample data through the multi-layer convolution layer to obtain a multi-scale feature subgraph, and performing feature fusion on the multi-scale feature subgraph through the spatial pyramid pooling layer to obtain device state features; Extracting local time series patterns from the operation behavior sequence sample data through the one-dimensional convolution layer to obtain local time series features, and capturing forward and backward time series dependencies of the local time series features through the bidirectional LSTM layer to obtain operation behavior features; The device state feature and the operation behavior feature are fused by the feature fusion layer to obtain a fused feature; The fusion feature is mapped to the sample label space through the fully connected layer to obtain the risk prediction value.

7. A method for accessing an automobile cloud platform based on a zero-trust architecture according to any one of claims 1 to 6, characterized in that: The risk operation verification of the client specifically includes: Acquiring biometric information of the operator through a biometric sensor disposed on the client, and sending the biometric information to the automotive cloud platform; The automobile cloud platform compares the biometric information with a locally stored identity authentication database to obtain the identity information of the operator; Determine the operation authority of the operator according to the identity information and preset authority rules, and judge whether the target operation behavior complies with the operation authority; When the target operation behavior meets the operation authority, it is determined that the risk operation verification has passed; When the target operation behavior does not comply with the operation authority, it is determined that the risk operation verification fails.

8. An automotive cloud platform access system based on zero-trust architecture, characterized in that: include: A session establishment module, used to verify the client's cloud platform connection request, and when the verification is successful, establish a secure session channel between the client and the automotive cloud platform; A risk assessment module, configured to obtain the target operation behavior of the client through the secure session channel, and perform risk assessment on the target operation behavior according to the device status of the client to obtain a risk value of the target operation behavior; An operation verification module, used for performing risk operation verification on the client when the risk value is greater than or equal to a preset risk threshold; The response module is used to return a response result corresponding to the target operation behavior through the automobile cloud platform when the verification is passed.

9. An automobile cloud platform access device based on zero-trust architecture, characterized in that: include: at least one processor; at least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements a method for accessing an automobile cloud platform based on a zero-trust architecture as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a program executable by a processor, characterized in that: The program executable by the processor is used to execute a method for accessing an automobile cloud platform based on a zero-trust architecture as described in any one of claims 1 to 7 when executed by the processor.

Images