Multi-modal security authentication system for battery swap interface and encrypted communication method

Abstract

This application provides a multimodal security authentication system and encrypted communication method for swappable interfaces, applied in the field of electric vehicle battery swapping communication technology. After establishing a physical connection between the battery swapping interface on the battery swapping side and the vehicle side, the connection characteristics of the battery swapping interface are detected to generate connection status information. A digital identity tuple composed of multi-layered data is generated on the vehicle side. On the battery swapping side, joint authentication is performed based on the connection status information and the digital identity tuple to generate authentication information. After successful authentication, the digital identity tuple and the authentication information are fused to generate a session key. A layered encryption strategy is executed in the communication link according to different trust levels to establish a corresponding encrypted communication channel, realizing secure transmission of battery swapping business data and reliable interaction in cross-operator environments. This improves data protection capabilities and interconnection efficiency in cross-domain battery swapping scenarios, thereby providing stable and efficient secure communication guarantees for electric vehicle battery swapping networks.

Description

Technical Field

[0001] This application relates to the field of electric vehicle battery swapping communication technology, and in particular to a multimodal security authentication system and encrypted communication method for swappable interfaces. Background Technology

[0002] With the large-scale application of electric vehicle battery swapping and the gradual construction of multi-brand, multi-operator battery swapping networks, the security authentication and encrypted communication technologies of swappable interfaces are increasingly becoming core technologies for ensuring battery swapping safety, improving user experience, and realizing industrial interconnection.

[0003] In existing battery swapping communication technologies, a digital certificate authentication mechanism based on public key infrastructure is typically used, combined with transport layer security protocols to establish an encrypted communication channel to ensure the security of identity verification and data transmission during the battery swapping process.

[0004] However, in practical battery swapping applications, the security authentication of swappable interfaces mainly relies on static digital certificates for single-factor authentication. This single authentication dimension cannot effectively defend against identity impersonation attacks such as certificate forgery and private key theft. When vehicles swap batteries across different operator networks, multiple remote queries are required through a centralized certificate authority (CA), resulting in high authentication latency. At the same time, the encryption strategy for encrypted communication is fixed and singular, and the encryption strength cannot be adjusted according to the actual trust status of the vehicle. This makes it difficult to balance security and communication efficiency. Furthermore, the authentication process and encrypted communication are independent of each other, making it impossible to simultaneously achieve high security levels, low latency response, and effective cross-domain trust transmission in various battery swapping scenarios such as cross-operator networks. This restricts the interoperability efficiency of battery swapping networks. Summary of the Invention

[0005] This application provides a multimodal security authentication system and encrypted communication method for swappable interfaces. The core of this system is as follows: After establishing a physical connection between the swappable interface on the swapping side and the vehicle side, an interface detection module detects the connection characteristics of the swappable interface and generates connection status information. On the vehicle side, an identity tuple module constructs a multi-layered identity structure. The vehicle-side device private key is used to sign the identity credential information to generate root identity data. A derived key is used to sign the swapping behavior information to generate status data. The authorization record issued by the swappable operator is verified and re-signed to form cross-domain data. The root identity data, status data, and cross-domain data are then fused to generate a digital identity tuple. On the swappable side, joint authentication is performed based on the connection status information and the digital identity tuple to generate authentication information containing trust level, session counter, and authentication status result.

[0006] Based on successful authentication, the digital identity tuple, trust level, session counter, and device fingerprint information are integrated. A session key is generated based on the integrated data, and a layered encryption strategy is executed at the physical and transport layers of the communication link according to different trust levels to establish corresponding encrypted communication channels. This enables secure transmission of battery swapping service data, ensuring battery swapping security while improving communication efficiency and interoperability in cross-operator battery swapping scenarios.

[0007] To achieve the above objectives, this application adopts the following technical solution: This application provides a multimodal security authentication system for swappable interfaces, the system may include: The interface detection module is set on the battery swapping side and is used to detect the connection characteristics of the battery swapping interface after the physical connection between the battery swapping side and the vehicle side is established, so as to obtain the corresponding connection status information. The identity tuple module is set on the vehicle side and includes a root identity layer, a state layer, a cross-domain layer, and a fusion layer. The root identity layer is used to obtain the identity credential information on the vehicle side, and sign the identity credential information according to the first preset private key to obtain root identity data. The first preset private key is the device private key on the vehicle side. The state layer is used to obtain battery swapping behavior information of the vehicle at the current battery swapping moment, and to sign the battery swapping behavior information according to the derived key of the first preset private key to obtain state data. The cross-domain layer is used to receive and record the authorization records from the battery swapping side to obtain cross-domain data; The fusion layer is used to fuse the root identity data, state data, and cross-domain data to obtain a digital identity tuple. The authentication module is located on the battery swapping side and is used to authenticate the vehicle side based on the connection status information and the digital identity tuple to obtain authentication information; The communication interface module is used to establish an encrypted communication channel between the battery swapping side and the vehicle side based on the authentication information. The encrypted communication channel is used to transmit battery swapping service data between the battery swapping side and the vehicle side.

[0008] In some possible implementations, the root identity layer is specifically used for: Obtain vehicle-side identity credential information, including vehicle identification number, vehicle digital certificate, and vehicle identity identifier; The vehicle identification number, vehicle digital certificate and vehicle identity identifier are combined in a preset order to form the first data to be signed; The first data to be signed is signed according to the first preset private key to obtain the first signed data. The first signed data is then combined with the first data to be signed to obtain the root identity data.

[0009] In some possible implementations, the state layer is specifically used for: Obtain battery swapping behavior information from the vehicle side at the current battery swapping moment. The battery swapping behavior information includes timestamp information, location information, and device behavior fingerprint. The timestamp information, location information, and device behavior fingerprint are combined in a preset order to form the second data to be signed; The second data to be signed is signed using a derived key from the first preset private key to obtain second signed data. The second signed data is then combined with the second data to be signed to obtain status data.

[0010] In some possible implementations, the cross-domain layer is specifically used for: Obtain the authorization record issued by the battery swapping side to the vehicle side, wherein the authorization record is signed by the battery swapping side using the private key of the battery swapping side operator as a second preset private key; Based on the preset public key of the battery swapping operator, the authorization record is signed and verified to obtain the verified authorization record; The verified authorization records are stored according to their corresponding authorization timestamps to form an authorization record list; Based on the first preset private key, the list of authorized records is signed to obtain third signature data. The list of authorized records and the third signature data are then combined to obtain cross-domain data.

[0011] In some possible implementations, the authentication information includes trust level, session counter, and authentication status result, and the authentication module is specifically used for: Obtain the connection status information and the digital identity tuple; Parse the digital identity tuple to obtain the corresponding root identity data, status data, and cross-domain data; Based on the public key corresponding to the first preset private key, perform hash verification on the first signature data and the first data to be signed in the root identity data to obtain the root identity verification result. Based on the public key corresponding to the derived key, perform a hash verification on the second signature data and the second data to be signed in the state data to obtain the state verification result; Based on the status verification result, the second data to be signed is authenticated to obtain the status authentication result; Based on the public key corresponding to the first preset private key, the third signature data of the cross-domain data and the list of authorized records are hashed to verify the cross-domain verification result. Based on the cross-domain verification result, the list of authorized records is authenticated to obtain the cross-domain authentication result; Based on the root identity verification result, status authentication result, and cross-domain authentication result, the corresponding trust level is obtained, and the corresponding authentication status result is generated by combining the connection status information. When the authentication status result is successful, a corresponding session counter is generated.

[0012] An encrypted communication method for a swappable interface, the method may include; To obtain authentication information, based on the battery swapping interface link, the communication addresses of the vehicle side and the battery swapping side are exchanged, and the physical characteristics of the interface are extracted by combining the connection status information to obtain the device fingerprint information. When the authentication status result is successful, the digital identity tuple, the trust level and session counter in the authentication information, and the device fingerprint information are fused together to obtain fused data. The fused data is then processed to generate the corresponding session key. Based on the trust level and in conjunction with the session key, the battery swapping service data to be transmitted is encrypted in layers at the physical layer and transport layer of the communication link to establish a corresponding encrypted communication channel. The encrypted communication channel is used to transmit battery swapping service data between the battery swapping side and the vehicle side.

[0013] In some possible implementations, the fusion of the digital identity tuple, the trust level and session counter in the authentication information, and the device fingerprint information to obtain fused data includes: The digital identity tuple is parsed to extract the digest value of the first data to be signed in the root identity data, the timestamp information and location information of the second data to be signed in the status data, and the digest value of the authorization record list in the cross-domain data to form an identity feature set. The trust level and session counter are encoded to obtain corresponding encoded values; The device fingerprint information is processed to obtain the corresponding interface feature vector; The identity feature set, encoded value, and interface feature vector are concatenated to obtain initial fused data. Based on the encoded value and timestamp information, a corresponding salt value is generated. The salt value is then fused with the initial fused data to obtain fused data.

[0014] In some possible implementations, the processing of the fused data to generate a corresponding session key includes: The fused data is hashed according to the key derivation function of the SM3 cryptographic hash algorithm to obtain the corresponding hash value; The hash value is truncated and used as the corresponding session key.

[0015] In some possible implementations, the trust level includes a first level, a second level, and a third level. The step of performing layered encryption on the battery swapping service data to be transmitted at the physical and transport layers of the communication link, based on the trust level and the session key, to establish a corresponding encrypted communication channel, includes: If the trust level is the first level, a corresponding pre-key is generated based on the session key. At the physical layer of the communication link, the battery swapping service data to be transmitted is encrypted based on the pre-key and the preset SM4 block cipher algorithm to generate the corresponding first ciphertext data. The first ciphertext data is transmitted through a communication link to form a corresponding first encrypted communication channel; If the trust level is the second level, the session key is used as the pre-shared key. Based on the pre-shared key, a preset first handshake strategy is executed, and the battery swapping service data to be transmitted is encapsulated to generate the corresponding first transport layer security record. At the physical layer of the communication link, the first transport layer security record is encrypted based on the session key and the preset SM4 block cipher algorithm to obtain the corresponding second ciphertext data. The second encrypted data is transmitted through a communication link to form a corresponding second encrypted communication channel; If the trust level is level three, based on the session key, a preset second handshake strategy is executed to generate a corresponding negotiation key, and the battery swapping service data to be transmitted is encapsulated to generate a corresponding second transport layer security record. At the physical layer of the communication link, the second transport layer security record is encrypted based on the negotiated key and the preset SM4 block cipher algorithm to obtain the corresponding third ciphertext data. The third encrypted data is transmitted through a communication link to form a corresponding third encrypted communication channel.

[0016] Among some possible implementation methods, the following are also included: After the encrypted communication channel is established, the number of times the session key is used is counted based on the session counter to obtain the key usage count; When the number of times the key is used is greater than or equal to a preset usage threshold, the session key is updated to obtain the updated session key; Based on the updated session key and trust level, the battery swapping service data to be transmitted is encrypted in layers at the physical layer and transport layer of the communication link to establish a corresponding encrypted communication channel.

[0017] As can be seen from the above technical solution, this application has the following beneficial effects: 1. This application generates a unique session key by integrating device fingerprint data, interface physical feature data, link identification data, and salt value perturbation mechanism, and participates the integrated data in the key derivation process, so that each battery swapping communication forms an independent encryption parameter system, realizing strong binding between the session key and the device environment. In the cross-device communication scenario of electric vehicle battery swapping interface, it can effectively avoid the problems of fixed key reuse and key leakage, and improve the identity uniqueness and anti-replay attack capability of the communication link while ensuring the real-time interaction efficiency of battery swapping business.

[0018] 2. This application employs layered encryption based on trust levels, matching differentiated encryption strategies at the physical and transport layers of the communication link according to different trust environments. This enables fast physical layer encryption to ensure low-latency transmission of battery swapping services in trusted link environments, dual-layer protection through pre-shared key handshake and transport layer secure encapsulation in cross-carrier or public network environments, and high-security communication channels to be built through negotiated keys and multi-round handshakes in high-risk access environments. This achieves a dynamic balance between security strength and communication efficiency, improving the security and controllability of the battery swapping system in complex network environments.

[0019] 3. This application generates a digital identity tuple containing a root identity layer, a state layer, and a cross-domain layer by setting an identity tuple module on the vehicle side, and stores and solidifies the cross-domain authorization record with the vehicle, realizing localized verification of cross-domain trust. When the vehicle enters any battery swapping station, the authorization chain verification can be completed without real-time querying of the remote certificate authority, thereby reducing the authentication latency in cross-operator battery swapping scenarios and improving the interconnection efficiency and user experience of the battery swapping network. Attached Figure Description

[0020] The present application will be further described below with reference to the accompanying drawings.

[0021] Figure 1 An example diagram of a multimodal security authentication system for a swappable interface provided in this application; Figure 2 A flowchart illustrating an encrypted communication method for a swappable interface provided in this application; Figure 3 A flowchart of another encrypted communication method for a swappable interface provided in this application. Detailed Implementation

[0022] The terms "first," "second," and "third," etc., used in this application specification, claims, and drawings are used to distinguish different objects, not to limit a specific order.

[0023] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0024] To ensure clarity and conciseness in the description of the following embodiments, a brief introduction to the related technologies is given first: In existing electric vehicle battery swapping systems, security authentication and encrypted communication are typically built on a public key infrastructure (PKI) architecture. After establishing a battery swapping interface connection, the vehicle and battery swapping sides establish a basic data link through the communication interface. The vehicle sends an authentication request data containing the vehicle identification code, device identifier, and vehicle digital certificate to the battery swapping side. Upon receiving the authentication request data, the battery swapping side verifies the vehicle digital certificate based on a pre-stored root certificate or operator-trusted certificate, and checks the certificate validity period, certificate issuing authority, and certificate revocation list. After successful certificate verification, the battery swapping side generates a random number and returns it to the vehicle. The vehicle uses its device private key to sign the random number to form authentication response data and sends it to the battery swapping side. The battery swapping side verifies the authentication response data based on the public key in the vehicle digital certificate, thereby completing the vehicle's authentication.

[0025] After identity authentication is completed, the vehicle side and the battery swapping side perform a key negotiation process through the transport layer security protocol. The two parties exchange key negotiation parameters and generate a session key. After the session key is generated, the two parties encrypt the communication data based on the symmetric encryption algorithm, encapsulating the battery swapping control command, status information and business data into encrypted messages, which are transmitted through a secure communication link. During the data transmission process, the two parties use message authentication codes to verify the integrity of the data, and continuously encrypt subsequent communication data through the session key until the communication connection is closed after the battery swapping process is completed. In cross-operator battery swapping scenarios, the battery swapping side will also verify the vehicle certificate and authorization information online through a remote authentication server, and establish an encrypted communication link after the verification is successful, thereby completing the security authentication and encrypted communication process of the battery swapping system.

[0026] Research has revealed that in the existing electric vehicle battery swapping systems, the vehicle and battery swapping sides primarily rely on vehicle digital certificates and device private keys for identity authentication. After authentication, a session key is negotiated through a transport layer security protocol to establish an encrypted communication link. The overall secure communication process is centered on static certificate authentication and a unified key negotiation mechanism. The authentication and communication encryption processes are executed sequentially in a fixed order, which can guarantee identity verification and data transmission security to a certain extent. However, in application scenarios where multi-brand and multi-operator battery swapping networks are gradually interconnected, the identity authentication stage mainly relies on vehicle digital certificates and device private keys for single-dimensional identity verification. The authentication criteria are mainly focused on the legality of the certificate and the validity of the signature. This means that the authentication result can only reflect the legality of the device's identity and is difficult to assess the credibility of the vehicle's current battery swapping behavior. In cases where the certificate is copied, the private key is stolen, or the device is counterfeited, authentication may still be successful, thus triggering the risk of identity theft.

[0027] In cross-carrier battery swapping scenarios, the battery swapping side typically relies on a remote authentication server to verify vehicle certificates and authorization information online. The authentication process involves multiple interactions with an external trust center, leading to extended authentication links and increased communication latency. In unstable network environments or when remote servers are slow to respond, this can easily result in excessively long authentication wait times, impacting the real-time performance and user experience of the battery swapping process. After identity authentication, a unified transport layer security protocol and a fixed key negotiation mechanism are usually used to establish an encrypted communication link. The generation of session keys and encryption strategies are largely independent of the authentication results, and the communication security level cannot be adjusted according to the actual trust status of the vehicle. This results in the use of fixed encryption strength in high-risk scenarios and the execution of the complete handshake process in low-risk scenarios, making it difficult to balance communication security and efficiency. In cross-carrier and other multi-scenario battery swapping environments, it is difficult to achieve effective transmission of trust information and adjustment of communication strategies, resulting in significant constraints on the security, real-time performance, and interoperability of the battery swapping system.

[0028] Example 1: To address the above problems, this application provides a multimodal security authentication system for swappable interfaces. Please refer to [link to example]. Figure 1 The system includes: an interface detection module, an identity tuple module, an authentication module, and a communication interface module.

[0029] The interface detection module is located on the battery swapping side. It is mainly used to detect the connection characteristics of the battery swapping interface after the physical connection between the battery swapping side and the vehicle side is established, and to obtain the corresponding connection status information.

[0030] To make the description of the following embodiments clear and concise, a brief introduction to the relevant terms is given first: Battery swapping side: refers to the battery swapping station side of electric vehicles, which is the equipment and system used to provide battery swapping services.

[0031] Vehicle side: refers to the electric vehicle itself.

[0032] Battery swapping interface: refers to the physical connection device used to connect electric vehicles and battery swapping stations. It includes battery swapping interfaces set on the vehicle side and battery swapping interfaces set on the swapping side. The connection is fixed by a mechanical locking mechanism and data is exchanged through power line communication (PLC).

[0033] Connection characteristics: refers to the detectable electrical and mechanical characteristics of the battery swapping interface during the physical connection process, including but not limited to mechanical locking state, contact resistance, PLC link signal strength, communication link establishment flag, interface physical identifier, and signal attenuation characteristics.

[0034] Connection status information refers to the detection results of the connection characteristics of the battery swapping interface. It is used to determine whether the battery swapping interface between the vehicle side and the battery swapping side has completed the physical connection. This information is usually a binary value or a status identifier, including connected and disconnected states. It is used to trigger subsequent security authentication and encrypted communication, ensuring that authentication and communication are only carried out after the interface docking is completed, thereby avoiding security risks or communication anomalies caused by starting authentication or data transmission when the interface is not fully connected.

[0035] In some possible implementations, the interface detection module detects the connection characteristics of the battery swapping interface in real time to ensure reliable interface docking between the vehicle side and the battery swapping side before the battery swapping operation. This module detects the connection characteristics through various physical parameter acquisition and signal analysis methods, including but not limited to electrical contact detection, interface resistance measurement, voltage or current change monitoring, and signal integrity verification.

[0036] Specifically, when the vehicle-side battery swapping interface is inserted into the battery swapping-side interface, the interface detection module detects the contact status of the interface pins. The module uses a built-in measurement circuit to detect the resistance or conductance of each key pin of the battery swapping interface. When the interface pins are inserted, the module measures the resistance or conduction status of each key pin under preset low voltage and low current conditions. By comparing this measurement with a standard contact resistance threshold, it determines whether the interface is fully in contact. If the resistance of a pin is detected to be higher than the preset threshold or if there is a discontinuity, it is determined to be a poor contact or a loose interface, and an abnormality flag is generated. Simultaneously, a low-power test signal (such as a square wave or pulse signal) is applied to the power supply and data lines on the battery swapping interface, and the amplitude, waveform, frequency, and phase of the transmitted signal are collected. Signal integrity analysis is used to determine whether there are any abnormalities such as short circuits, open circuits, or noise interference in the interface. When the battery swapping interface initially establishes a physical connection, a test data packet is sent and the return response is detected. By analyzing the delay, packet loss rate, and bit error rate of the return signal, the reliability of the interface connection is further confirmed, and any poor contact or abnormal impedance is detected.

[0037] After completing resistance and conductance measurements, electrical signal integrity analysis, and low-power communication signal testing, the interface detection module performs a comprehensive judgment and analysis of the test results. By comprehensively analyzing the contact status of key pins, electrical signal characteristics, and low-power test data, it determines the final connection status of the battery swapping interface and outputs unified connection status information including interface connection status, abnormality indicators, and key test indicators.

[0038] In some possible implementations, the interface detection module periodically collects the aforementioned resistance, conductance, and signal parameters through a continuous sampling mechanism, updates the connection status in real time, and provides the judgment result to the authentication module as a trigger condition for subsequent secure authentication and encrypted communication. Through this mechanism, this application can initiate identity authentication and encrypted communication only after the physical interface has reliably connected, ensuring that the battery swapping system will not perform sensitive data interaction if the interface is not fully connected or if there are anomalies. This reduces security risks during the battery swapping process and guarantees the reliability and security of data transmission in battery swapping services.

[0039] The identity tuple module is set on the vehicle side and includes the root identity layer, state layer, cross-domain layer and fusion layer.

[0040] The root identity layer is used to obtain the identity credential information from the vehicle side. It performs the first signature on the identity credential information based on the first preset private key to obtain the root identity data.

[0041] To make the description of the following embodiments clear and concise, a brief introduction to the relevant terms is given first: Identity credential information: refers to the various data sets used by the vehicle to prove its legal identity, including vehicle identification number, vehicle digital certificate and vehicle identity mark, etc. This information can be used to provide verifiable identity evidence to the battery swapping side during the battery swapping process.

[0042] Among them, the Vehicle Identification Number (VIN) is a unique code assigned to each vehicle under a globally unified standard. It is used to uniquely identify individual vehicles. The VIN usually contains key information such as manufacturer information, year of production, vehicle model and serial number, and can be used for vehicle identity authentication, battery swapping authorization management and vehicle history tracking.

[0043] Vehicle digital certificate: refers to a digital credential issued by a trusted Certificate Authority (CA) to prove the legitimacy of a vehicle's identity. It includes the vehicle's public key and related signature information and can be used by the battery swapping side to verify the authenticity and integrity of the vehicle's identity.

[0044] Vehicle identification: refers to the vehicle's identification information in a specific battery swapping network or operating environment. It may include the vehicle's account or registration number in the operator's system. It is used to form a complete identity credential together with the vehicle identification code and digital certificate during the battery swapping process to realize multimodal identity verification.

[0045] First preset private key: refers to the private key pre-configured on the vehicle side during factory or initialization, used to digitally sign identity credential information.

[0046] Technical expansion based on the above technical terminology: A Trusted Certificate Authority (CA) is a trusted third-party entity responsible for issuing, managing, and revoking digital certificates in battery swapping systems or broader vehicle-to-everything (V2X) security environments. By employing public key infrastructure (PKI) technology, CAs generate and sign digital certificates for vehicles or battery swapping devices to prove their authenticity and legitimacy. They also provide certificate revocation lists and online certificate status protocols to ensure timely updates to security verification information should a certificate be leaked, expired, or invalidated. This supports cross-domain identity authentication and secure communication for vehicles from multiple operators and brands within the battery swapping system.

[0047] In some possible implementations, the root identity layer performs structured processing and encrypted signing of the vehicle-side identity credential information, thereby generating root identity data that can be verified by the battery swapping side, thus achieving reliable confirmation of the vehicle's identity.

[0048] Specifically, the root identity layer obtains complete identity credential information from the vehicle's internal secure storage unit, including the vehicle identification number (VIN), vehicle digital certificate, and vehicle identity identifier. The root identity layer combines this information in a preset order to form the first data to be signed, ensuring that the data structure is fixed and the field order can be parsed by the battery swapping side, so as to avoid verification failure due to different parsing order.

[0049] After combining the data to be signed, the root identity layer uses the vehicle-side's first preset private key to digitally sign the first data to be signed, generating the first signature data. The digital signature process is based on the SM2 asymmetric encryption algorithm, using the private key to encrypt the data digest, thereby ensuring the uniqueness and immutability of the signature. The root identity layer combines the first signature data with the first data to be signed to form the corresponding root identity data. This data contains both data content that can be verified by the battery swapping side and the corresponding signature information, ensuring that the battery swapping side can perform integrity and legality verification using the vehicle's public key.

[0050] In some possible implementations, after obtaining the first data to be signed, the root identity layer can perform a signing operation on the data based on the SM2 asymmetric encryption algorithm to generate the corresponding first signed data. The specific implementation methods are as follows: The first piece of data to be signed is input into the SM3 hash function to perform a digest calculation, resulting in a fixed-length message digest value. The SM3 hash algorithm can map inputs of arbitrary length to a fixed-length 256-bit digest, and is irreversible and collision resistant, thus ensuring the integrity of the data to be signed.

[0051] Use the first preset private key on the vehicle side and the SM2 asymmetric encryption algorithm for message digest values Perform asymmetric encryption computation.

[0052] Specifically, the root identity layer generates a random integer. To ensure the uniqueness and unpredictability of each signature, the corresponding curve points are calculated using the elliptic curve algorithm of SM2. ,in The generation point specified by the SM2 asymmetric encryption algorithm. For the corresponding curve points, is the random integer generated above.

[0053] Signature parameters are further generated using the SM2 algorithm formula. and This ensures that the signature is tightly bound to the vehicle's private key.

[0054] Calculate signature parameters : ;in, For signature parameters, The message digest value obtained above, Let be the order of the elliptic curve.

[0055] Calculate signature parameters : ;in, For signature parameters, As the first preset private key, The random integer generated above, Let be the order of the elliptic curve.

[0056] Signature parameters and The first signature data is formed by combining the data, and then the signature data is combined with the first data to be signed to generate the corresponding root identity data.

[0057] Based on the above embodiments, the SM2 asymmetric encryption algorithm and the SM3 cryptographic hash algorithm are extended technically.

[0058] SM2 Asymmetric Encryption Algorithm: SM2 is a public-key cryptography algorithm based on elliptic curve cryptography, primarily used for digital signatures, key exchange, and public-key encryption. Its core principles include point operations on elliptic curves and the mathematical mapping between private and public keys: each vehicle device holds a unique private key, and the public key is calculated from elliptic curve points and the private key. The signing process hashes the data to be signed, then generates elliptic curve points using random numbers, and finally generates signature parameters through mathematical operations. This signature possesses unforgeability, resistance to replay attacks, and the characteristic of corresponding to the device's private key. Through SM2 signatures, the root identity layer can ensure that the vehicle's identity credentials are not tampered with during transmission, while providing verifiable authentication evidence. The battery swapping side can verify the signature using the public key to confirm the data's source and integrity. SM2's security relies on the computational difficulty of the elliptic curve discrete logarithm problem, ensuring signature strength while achieving efficient computation with limited computing resources, making it suitable for embedded device applications on the vehicle side.

[0059] SM3 cryptographic hash algorithm: SM3 is a cryptographically secure hash function that maps input data of arbitrary length to a fixed-length 256-bit digest value. Its algorithm principles include message padding, iterative block compression, and nonlinear permutation operations, ensuring that small changes in the input data will lead to significant changes in the output digest. It also possesses collision resistance and irreversibility. In this application, SM3 is mainly used in two scenarios: generating digest values ​​for data to be signed, providing input for SM2 signing, and ensuring data integrity before signing; and in the session key generation stage, using SM3 hashing to obtain a fixed-length hash value from the fused data, used to derive the session key, thereby ensuring the randomness and security of encrypted communication. SM3's collision resistance and irreversibility effectively prevent identity credentials or session keys from being forged or reverse-engineered during transmission, enhancing the overall system security.

[0060] The state layer is used to obtain battery swapping behavior information of the vehicle at the current battery swapping moment, and to sign the battery swapping behavior information according to the derived key of the first preset private key to obtain state data.

[0061] To make the description of the following embodiments clear and concise, a brief introduction to the relevant terms is given first: Battery swapping behavior information refers to a collection of various data generated by the vehicle during the current battery swapping process, which can be used to assess the credibility and status of vehicle behavior. This includes timestamp information, location information, and device behavior fingerprints. The timestamp information records the specific time point when the vehicle performs the battery swapping operation, which can be used to prevent replay attacks or behavior tampering. The location information reflects the vehicle's location during the battery swapping process and is used to verify whether the battery swapping operation occurs at an authorized battery swapping station or within a designated geographical area. The device behavior fingerprint can include the electrical signal characteristics of the vehicle's battery swapping interface, controller operation sequence, sensor reading patterns, etc., which can reflect the action characteristics performed by the vehicle during the battery swapping process.

[0062] The derived key of the first preset private key: refers to the subkey generated from the device's private key on the vehicle side through a key derivation algorithm, used to sign or encrypt battery swapping information. While maintaining the security of the original private key, the derived key enables one-time or time-varying signature capabilities, which can limit the signature scope and lifespan, thereby reducing the security risks of misuse or leakage of the private key.

[0063] In some possible implementations, it should be noted that in the implementation of this application, the signature logic of the state layer is consistent with that of the root identity layer. Both are based on the SM2 asymmetric encryption signature principle to ensure data integrity and non-repudiation. The only difference is the signature object and the key used. The state layer collects current battery swapping behavior information from the vehicle side, including timestamp information, location information, and device behavior fingerprints. The timestamp information records the time of the battery swapping operation, the location information reflects the vehicle's battery swapping location, and the device behavior fingerprint reflects the vehicle's action characteristics during the battery swapping process, such as the characteristics of the battery swapping interface operation signals, sensor data patterns, and controller response sequences. After collection, the state layer combines these data in a preset order to form the second data to be signed, ensuring that the order and integrity of each behavior information in the signature are controllable, thereby facilitating subsequent verification.

[0064] The state layer uses a derived key from the first preset private key to perform a signature operation on the second data to be signed. The derived key is generated using a key expansion function based on SM3 hashing and the vehicle equipment private key, enabling one-time or time-varying signature capabilities to ensure the uniqueness and non-replayability of the signature for each battery swapping transaction. During the signing process, the derived key and the second data to be signed are used as inputs to generate the second signature data through the SM2 asymmetric encryption algorithm, completing the encrypted signature protection for the battery swapping transaction. Specifically, in the root identity layer's consistent state layer, the generated second signature data is combined with the original second data to be signed to form state data, which is then provided to the fusion layer as a component of the digital identity tuple.

[0065] In some possible implementations, the derived key is generated based on a combination of a first preset private key and a derived identifier, implemented using the SM3 cryptographic hash algorithm as the key derivation function. The first preset private key is obtained on the vehicle side, and a corresponding derived identifier is generated for each battery swapping action. This identifier may contain a timestamp, session number, or other unique action identification information to ensure the uniqueness and unpredictability of each derived key. The first preset private key and the derived identifier are combined in a preset order and used as input data for hashing using the SM3 algorithm. Continuous hashing generates a fixed-length output value, which is the derived key. This derived key has a strong correlation with the original private key, is irreversible, and has a fixed length. It can be directly used for digital signature operations on battery swapping information. Through this mechanism, this application achieves data signature for each battery swapping action using an independent and secure key, enabling state-level signatures to be dynamically bound to the vehicle's current behavior, ensuring the uniqueness and tamper-proof nature of the signature, and enhancing the security and traceability of identity verification in cross-operator battery swapping scenarios.

[0066] The cross-domain layer is used to receive and record authorization records from the battery swapping side to obtain cross-domain data.

[0067] To make the description of the following embodiments clear and concise, a brief introduction to the relevant terms is given first: Authorization records refer to the credentials issued and stored by the battery swapping provider during the battery swapping process, verifying vehicle identity, swapping permissions, and operational behavior. These records serve to prove that the vehicle has obtained legitimate operational authorization within a specific battery swapping network or operating environment. Authorization records typically include the issuance date, validity period, scope of authorization, battery swapping operation number, and the digital signature of the battery swapping provider's operator. They can be used to verify and track vehicle identity and behavior in cross-operator battery swapping scenarios, enabling trust transfer and secure interoperability between different battery swapping operating domains.

[0068] In some possible implementations, the cross-domain layer receives authorization records issued by the battery swapping operator to the vehicle side. These authorization records are digitally signed by the battery swapping operator using its proprietary second pre-set private key to ensure that the records have not been tampered with during transmission and to prove the legitimacy of the authorization. The cross-domain layer verifies the signature of the received authorization records using the pre-obtained public key of the battery swapping operator. The verification process includes checking the integrity of the signature, the consistency of the authorization record content, and the validity of the issuance time, thereby obtaining the verified authorization record.

[0069] The second preset private key refers to the private key pre-configured by the battery swapping side at the factory or during initialization. It is held by the battery swapping side operator or authorized management agency and is used to digitally sign the authorization records on the vehicle side, thereby generating verifiable authorization credentials. By using the second preset private key for signing, the battery swapping side can ensure the legality and integrity of the source of the authorization records. The vehicle side or other operators can use the corresponding battery swapping side public key to verify the signature, thereby supporting cross-domain identity authentication and secure communication.

[0070] The cross-domain layer stores all verified authorization records in chronological order according to their corresponding authorization timestamps, forming a complete list of authorization records to ensure the timeliness and traceability of cross-domain authorization information. Based on this, the cross-domain layer uses the vehicle-side's first preset private key to digitally sign the authorization record list, generating a third signature data. This signature data is then combined with the authorization record list to obtain the cross-domain data. It should be noted that in this implementation, the signature logic of the cross-domain layer is consistent with that of the root identity layer, both based on the SM2 asymmetric encryption signature principle to ensure data integrity and non-repudiation; only the signature objects differ. Detailed signature logic will not be elaborated upon here.

[0071] In some possible implementations, the cross-domain layer performs cross-domain authentication on the vehicle by utilizing historical authorization records stored on the vehicle side or authorization records from other operators of the same or different types. This assists the battery swapping side in determining the trustworthiness of the vehicle in the current battery swapping operation. After the battery swapping interface connection is established for the first time and the root identity data and status data are verified, the cross-domain layer retrieves these historical authorization records from the vehicle side's local database or cross-operator authorization data cache, performs signature verification and integrity checks, and generates a list of verified authorization records. The list is then signed using the vehicle side's first preset private key to form cross-domain data, which is used by the fusion layer to generate a digital identity tuple together with the root identity data and status data.

[0072] The authorization record for this battery swap operation will only be sent and recorded by the battery swapping side after the battery swap is completed or during the next battery swap interaction. This ensures that cross-domain data can reflect the vehicle's historical trust foundation without relying on the current battery swap authorization that has not yet been completed. This ensures that the authentication process can be executed independently during the first battery swap contact, while providing a reliable identity assessment basis for cross-carrier scenarios.

[0073] The cross-domain layer, based on digital signature and public key infrastructure technologies, verifies the authorization records issued by the battery swapping side by signing them, ensuring the authenticity and integrity of the authorization information. Simultaneously, the record list is re-signed by the vehicle side, achieving effective transfer of trust across domains. External authorization information is bound to the vehicle's private key to form a trusted credential that can be verified in subsequent authentication processes. This supports cross-domain verification of vehicle identity and behavior across multi-operator and multi-brand battery swapping networks, ensuring the continuity and reliability of secure authentication in cross-domain battery swapping scenarios, while preventing the tampering or forgery of authorization records.

[0074] The fusion layer is used to merge root identity data, state data, and cross-domain data to obtain digital identity tuples.

[0075] To make the description of the following embodiments clear and concise, a brief introduction to the relevant terms is given first: Digital identity tuples refer to a comprehensive identity information structure generated by the vehicle side through the root identity layer, state layer, and cross-domain layer. They are used to perform multi-dimensional and reliable identity authentication of vehicles in the battery swapping system. Digital identity tuples include root identity data, state data, and cross-domain data, which can simultaneously reflect the legitimacy of the vehicle's device identity, the credibility of the current battery swapping behavior, and the historical cross-domain authorization status. Through digital identity tuples, the battery swapping side can perform joint authentication before establishing an encrypted communication channel, thereby supporting multimodal identity confirmation, dynamic trust assessment, and secure cross-carrier interconnection communication.

[0076] Specifically, the fusion layer combines root identity data, status data, and cross-domain data into a continuous data stream or structured byte string according to a preset order or structure, forming a complete data unit. A hash algorithm (such as SM3) is then used to generate a digest for the combined data unit, which is used for integrity verification and tamper-proof verification. This data unit is bound to its corresponding digest and provided to the battery swapping side as a digital identity tuple for subsequent federated authentication and session key generation. In this way, the digital identity tuple maintains the integrity and correlation of data at each layer, while simplifying the processing flow and ensuring that it can be quickly used for secure authentication and encrypted communication triggering after the battery swapping interface is established.

[0077] The authentication module is located on the battery swapping side and is used to authenticate the vehicle based on the connection status information and digital identity tuple to obtain authentication information.

[0078] In some possible implementations, the authentication module is primarily used to obtain connection state information and digital identity tuples; Parse the digital identity tuple to obtain the corresponding root identity data, status data, and cross-domain data; Based on the public key corresponding to the first preset private key, perform hash verification on the first signature data and the first data to be signed in the root identity data to obtain the root identity verification result. Based on the public key corresponding to the derived key, perform hash verification on the second signature data and the second data to be signed in the state data to obtain the state verification result. Based on the status verification result, the second data to be signed is authenticated to obtain the status authentication result; Based on the public key corresponding to the first preset private key, the third signature data of the cross-domain data and the list of authorized records are hashed and verified to obtain the cross-domain verification result. Based on the cross-domain verification results, the list of authorized records is authenticated to obtain the cross-domain authentication results; Based on the root identity verification result, state authentication result, and cross-domain authentication result, the corresponding trust level is obtained, and the corresponding authentication state result is generated by combining the connection state information. When the authentication status result is successful, a corresponding session counter is generated.

[0079] Specifically, after a physical connection is established between the battery swapping interface on the vehicle side and the battery swapping side, the interface detection module provides the detected connection status information to the authentication module. After confirming that the interface is fully connected and stable, the authentication module begins to process the digital identity tuple transmitted on the vehicle side. The digital identity tuple consists of three parts in structure: root identity data, status data, and cross-domain data. Each part contains data to be signed and corresponding signature data.

[0080] The root identity data is authenticated by retrieving the public key corresponding to the first preset private key from the vehicle's public key pre-stored on the battery swapping side. This public key can be verified using a digital certificate issued by a trusted Certificate Authority (CA) at the time the vehicle leaves the factory. The battery swapping side stores the CA root certificate and uses it to sign and verify the vehicle's digital certificate, thereby confirming the legitimacy of the vehicle's public key. After confirming the validity of the public key, the authentication module uses this public key to perform a hash verification operation on the first signature data in the root identity data and compares the result with the hash value of the first data to be signed to confirm that the identity credential has not been tampered with and its source is trustworthy, thus obtaining the root identity verification result.

[0081] The status data is authenticated. The status data is a signature generated based on the vehicle's current battery swapping behavior information. It is verified using the public key corresponding to the derived key derived from the first preset private key. The public key corresponding to the derived key is calculated synchronously by the vehicle side when generating the derived key and is sent to the battery swapping side through the derived public key field in the status data. The battery swapping side first uses the vehicle side's public key to verify the signature of the derived public key. After confirming the authenticity of the derived public key and its binding relationship with the current vehicle, it uses the derived public key to perform a hash verification on the second signature data in the status data. The result is compared with the hash value of the second data to be signed to confirm that the battery swapping behavior data has not been tampered with and to perform credibility authentication of the behavior information, forming a status authentication result. The implementation methods involved in behavior authentication include comparing the continuity of timestamps, the legality of location information, and the device behavior fingerprint with historical behavior patterns to determine whether the battery swapping behavior is abnormal.

[0082] Cross-domain data is authenticated. This data includes a list of authorization records issued by the battery swapping station and other operators. The authentication module obtains the public key corresponding to the first preset private key from the vehicle's public key pre-stored on the battery swapping station. The authentication module uses this public key to perform hash verification on the third signature data in the cross-domain data and compares it with the hash value of the authorization record list to ensure that the authorization information is reliable and has not been tampered with. The verified authorization record list is then subjected to a legitimacy analysis, such as checking the authorization timestamp, the validity period of the operator's signature, and the vehicle's registration status in the authorization records, to generate a cross-domain authentication result.

[0083] Upon receiving the digital identity tuple, the authentication module parses the root identity data, status data, and cross-domain data separately, extracting the data to be signed for each. The module then generates a hash digest for each data segment using the SM3 cryptographic hash algorithm. This process involves grouping, iteratively compressing, and performing nonlinear permutations to obtain a fixed-length digest value, which uniquely identifies the corresponding original data and ensures high sensitivity to even minor modifications to the original data, thus achieving integrity verification. After generating the hash digest, the signature data is verified using the corresponding public keys: the root identity data uses the public key corresponding to the vehicle-side first preset private key, the status data uses the public key corresponding to the derived key, and the cross-domain data uses the public key of the battery swapping operator. The result of decrypting the public key is compared with the hash digest. If they match, the signature is valid and the data has not been tampered with; if they do not match, the signature is invalid or the data has been modified. The authentication module generates corresponding verification results based on the hash comparison results of each part, such as root identity verification passed, status verification passed, and cross-domain verification passed.

[0084] In some possible implementation methods, when authenticating status data, the authentication module performs credibility verification on the battery swapping behavior information provided by the vehicle side to generate status authentication results. It verifies the continuity of timestamps by checking whether the records continuously increase according to the timestamp sequence in the battery swapping behavior information. Abnormal jumps or duplicate records will be marked as abnormal. Minimum and maximum allowable time interval thresholds can be set to identify time anomalies or forgery. The authentication module also verifies the legality of location information by comparing the location information in the battery swapping behavior information with the vehicle's registration location, expected battery swapping station location, or historical battery swapping path. Using geofencing or distance-limiting algorithms, the system determines whether the vehicle's current location is reasonable. Abnormal deviations or impossible movement trajectories will trigger an abnormal behavior flag. The system compares device behavior fingerprints, which include the vehicle's battery swapping interface insertion / removal time, signal response characteristics, and electrical load change patterns. Standard fingerprint templates are formed by collecting historical battery swapping behavior data or the vehicle's own device feature database. The authentication module performs similarity analysis between the current battery swapping behavior fingerprint and historical templates, using methods such as Euclidean distance, cosine similarity, or dynamic time warping to calculate similarity scores. If the score is below a preset threshold, it is considered abnormal behavior. The authentication module integrates the results of timestamp continuity, location information validity, and device behavior fingerprint comparison to form a status authentication result.

[0085] In some possible implementations, after completing the hash verification of cross-domain data and confirming that the authorization record list has not been tampered with, the authentication module performs a legality analysis on the authorization record list to generate a cross-domain authentication result. It also verifies the validity of the authorization timestamps, extracting the authorization timestamp of each authorization record from the list and comparing it with the current system time on the battery swapping side to determine if the authorization record is within a valid time window. A preset authorization validity period can be implemented; for example, authorization records are valid within a certain time range, and authorization records exceeding this time range will be marked as invalid. Simultaneously, the continuity of authorization timestamps is checked to ensure that authorization records are arranged in chronological order, without abnormal reverse order or time conflicts, thereby guaranteeing the reliability of the authorization history.

[0086] To verify the validity of the operator's signature, the authentication module reads the operator's digital signature and corresponding certificate information contained in the authorization record. It then verifies the validity of the operator's certificate using a pre-stored trusted certificate authority root certificate, checking the certificate's effective and expiration dates to confirm that the certificate was valid when the authorization record was issued. Simultaneously, it checks the certificate revocation list or online certificate status information to determine whether the certificate has been revoked or expired. If the operator's certificate is valid, the authorization record is considered trustworthy; if the certificate is expired or revoked, the corresponding authorization record is marked as invalid.

[0087] The authentication module verifies the vehicle's registration status in the authorization record. It extracts the vehicle identification number and vehicle identity identifier from the authorization record and matches them with the root identity data in the current digital identity tuple to confirm that the authorization record indeed belongs to the current vehicle. The module also checks the vehicle's registration status in the corresponding operator's system using the operator's registration database or a locally cached list of vehicle registration information. This includes checking if the vehicle is already registered, if it is in a battery swapping state, and if it is on a blacklist or frozen. If the vehicle is in a normal registration state in the operator's system corresponding to the authorization record, the authorization record is deemed legitimate and valid.

[0088] The authentication module sequentially verifies the validity of the authorization timestamp, the operator signature, and the vehicle registration status. If the authorization timestamp is within a valid time window, the operator certificate is valid and not revoked, and the vehicle is in a normal registration status in the corresponding operator's system, then the corresponding authorization record is determined to be a valid authorization record. Once all three verifications—authorization timestamp verification, operator signature verification, and vehicle registration status verification—pass, the authentication module successfully outputs the corresponding cross-domain authentication result.

[0089] Furthermore, when generating cross-domain authentication results, the authentication module will identify the source type of the authorization record, determine whether the authorization record includes historical authorization records issued by the current battery swapping operator, or authorization records issued by the same type of operator as the current battery swapping operator, or authorization records issued by different types of operators, and write the authorization source type into the cross-domain authentication results to characterize the trust basis of the vehicle in a cross-operator environment.

[0090] In some possible implementations, after obtaining the root identity verification result, the state authentication result, and the cross-domain authentication result, the authentication module will comprehensively judge the three types of results to generate the corresponding trust level, and combine the connection state information to generate the authentication state result.

[0091] The authentication module prioritizes the root identity verification results, which are used to confirm the authenticity and legitimacy of the vehicle device's identity and are a fundamental security condition in the authentication process. If the root identity verification fails—that is, if the hash comparison between the first signature data and the first data to be signed is inconsistent, or if the vehicle digital certificate is invalid, expired, or revoked—the authentication status is directly determined as failed, the subsequent process is terminated, and no trust level is output.

[0092] If the root identity verification passes, the authentication module further performs authentication based on the status authentication result. The status authentication result includes hash verification of the second signature data, validity of the timestamp information, and whether the location information matches the location of the battery swapping station in the connection status information. If the status authentication fails (e.g., timestamp exceeds the limit, location deviation is too large, or second signature verification fails), the authentication module determines the authentication status result as unsuccessful, records the reason for failure as status abnormality, and does not output the trust level.

[0093] Once the root identity verification and state authentication are both successful, the authentication module determines the trust level based on the cross-domain authentication results. The cross-domain authentication results include the integrity verification of the authorized record list (the hash comparison between the third signature data and the authorized record list) as well as the signature verification, validity period verification, and evidence query results of each authorized record in the list.

[0094] If the cross-domain authentication result shows that there is at least one valid authorization record directly issued by the current battery swapping operator in the authorization record list (that is, the operator identity of the authorization record matches the current battery swapping operator, and the signature verification is successful, it is within the validity period, it has not been revoked, and the blockchain evidence is valid), then regardless of whether there are other operator authorization records, the authentication module will output the trust level as the first level. This level indicates that the vehicle has obtained direct authorization from the current battery swapping operator and belongs to the trust scenario of this network. Subsequent encrypted communication can adopt the lowest latency physical layer encryption strategy.

[0095] If the first-level conditions are not met, but the cross-domain authentication result shows that there is at least one valid authorization record issued by another battery swapping operator in the authorization record list (i.e., the authorization record list does not contain direct authorization from the current battery swapping side, but there is at least one authorization record from another operator, and the signature verification is successful, it is within the validity period, has not been revoked, and the blockchain evidence is valid), then the authentication module outputs a trust level of the second level. This level indicates that although the vehicle has not directly obtained authorization from the current battery swapping side, it has obtained valid trust endorsement from other operators, which belongs to a cross-domain trust scenario. Subsequent encrypted communication can adopt a zero-round-trip time transport layer encryption strategy based on a pre-shared key.

[0096] If the conditions for Level 1 and Level 2 are not met, i.e. the authorization record list is empty, or all authorization records in the list are marked as invalid due to expiration, revocation, signature verification failure, or invalid blockchain evidence, but the root identity verification and status authentication are both passed, then the authentication module outputs a trust level of Level 3. This level indicates that the vehicle is accessing the current battery swapping network for the first time and has no valid authorization records. This is a first-time cross-domain or high-risk scenario, and subsequent encrypted communication must use a complete transport layer security protocol handshake and perform dynamic key negotiation.

[0097] After determining the trust level, the authentication module combines the connection status information to generate the final authentication status result. If the connection status information indicates that the battery swapping interface has completed physical connection and all the above verifications have passed, the authentication status result is set to successful authentication. If the connection status information indicates that the interface is not fully connected (e.g., mechanical locking is not complete), even if all verifications pass, the authentication module will set the authentication status result to unsuccessful and record the interface anomaly to prevent the establishment of a communication channel under unstable conditions. After successful authentication, the authentication module simultaneously generates an incrementing session counter to identify the sequence number of this authentication session and sends the initial value of the session counter to the communication interface module. The authentication module finally outputs authentication information containing the trust level, session counter, and authentication status result, which the communication interface module uses to establish the corresponding encrypted communication channel.

[0098] The communication interface module is used to establish an encrypted communication channel between the battery swapping side and the vehicle side based on authentication information.

[0099] In some possible implementations, the communication interface module begins working after the authentication module generates authentication information, and is used to establish an encrypted communication channel between the battery swapping side and the vehicle side.

[0100] When the authentication status result is successful, the communication interface module reads the trust level and session counter, and confirms that the physical connection status of the battery swapping interface is stable based on the connection status information. Under the premise that the interface is stable, the communication interface module sends a communication initialization command to the vehicle side. The communication initialization command includes the initial value of the session counter, the trust level identifier, and the communication policy identifier, which is used to start the secure communication process.

[0101] After completing the communication initialization, the communication interface module generates the corresponding session key based on the authentication information and executes differentiated encryption communication strategies according to different trust levels to establish corresponding encrypted communication channels on the communication link.

[0102] After the encrypted communication channel is established, the communication interface module continuously encrypts and transmits battery swapping service data, and uses a session counter to control the order of the communication process. When an abnormality in the session counter, a data verification failure, or a change in the interface status is detected, the communication interface module automatically terminates the communication and closes the encrypted channel to ensure the security and stability of the battery swapping process.

[0103] After the battery swapping service is completed, the communication interface module destroys the current communication key and closes the encrypted communication channel. At the same time, the authorization record generated by this battery swapping is written to the cross-domain layer for subsequent cross-domain authentication. In Example 2, the session key generation method and the layered encryption strategy are further described in detail.

[0104] This application utilizes a multimodal security authentication system for the swappable interface. This system combines an interface detection module to detect the physical connection characteristics of the swappable interface with an identity tuple module to verify vehicle identity, swappable behavior, and cross-domain authorization records from multiple dimensions. This achieves a mechanism that triggers identity authentication and encrypted communication only after reliable interface docking. Through comprehensive detection of resistance, conductance, signal integrity, and low-power communication signals, it ensures complete and stable connection between the vehicle and swappable interfaces, preventing abnormal data transmission due to poor contact. By fusing root identity data, status data, and cross-domain data to generate a digital identity tuple, it verifies the legitimacy of the vehicle identity and the credibility of the current swappable behavior. The joint verification of historical cross-domain authorization effectively prevents identity forgery or tampering with authorization records; through the verification of timestamp continuity, location information legality, and device behavior fingerprints, it can instantly identify abnormal or malicious operations in battery swapping, ensuring the safety of battery swapping operations; by verifying and binding cross-domain authorization records with signatures, it enables trusted identity transfer between different operators, allowing vehicles to securely complete authentication in first-time or cross-domain battery swapping scenarios without relying on the instant authorization of this battery swapping operation. It can achieve comprehensive security authentication in various battery swapping scenarios, thereby improving communication efficiency and interoperability in cross-operator battery swapping scenarios while ensuring the safety of battery swapping.

[0105] Example 2: This application provides an encrypted communication method for a swappable interface, applied to the encrypted communication system for the swappable interface described in Example 1. Please refer to [link / reference]. Figure 2 .

[0106] S101, obtain authentication information. Based on the battery swapping interface link, exchange the communication address on the vehicle side and the communication address on the battery swapping side, and extract the physical characteristics of the interface by combining the connection status information to obtain the device fingerprint information.

[0107] To ensure clarity and conciseness in the description of the following embodiments, a brief introduction to the relevant terms is given first.

[0108] Equipment fingerprint information refers to comprehensive information used to uniquely identify the physical link characteristics of the battery swapping interface. This includes the communication address on the vehicle side, the communication address on the battery swapping side, and the interface physical characteristics extracted from the connection status information. The communication address is the MAC address of the power line communication controller, and the interface physical characteristics include parameters such as signal attenuation characteristics, transmission delay characteristics, interface contact resistance, and communication link bit error rate. This equipment fingerprint information is used during session key derivation to bind the encrypted channel to the current physical link, thereby preventing man-in-the-middle attacks through address spoofing or link cloning to hijack the communication session, ensuring the uniqueness and security of the communication object during the battery swapping process.

[0109] Specifically, the vehicle side and the battery swapping side obtain their respective communication addresses through the power line communication controller, and extract the corresponding interface physical features from the connection status information collected by the interface detection module, such as contact resistance, interface locking status and signal integrity parameters; and measure the characteristics of link attenuation, transmission delay, bit error rate and phase change by sending test signals, and structure the above information into interface feature vectors, and combine them with the communication address to form device fingerprint information.

[0110] S102, when the authentication status result is successful, the digital identity tuple, the trust level and session counter in the authentication information are fused with the device fingerprint information to obtain fused data, and the fused data is processed to generate the corresponding session key.

[0111] To ensure clarity and conciseness in the description of the following embodiments, a brief introduction to the relevant terms is given first.

[0112] Session key: refers to the temporary symmetric encryption key generated after the vehicle side and the battery swapping side complete identity authentication and device fingerprint verification in the secure communication method of the swappable interface in this application. It is used to encrypt and decrypt the communication data between the vehicle side and the battery swapping side during a battery swapping operation session to ensure the confidentiality, integrity and tamper resistance of data transmission.

[0113] In some possible implementations, when the authentication status result is successful, the digital identity tuple, the trust level and session counter in the authentication information, and the device fingerprint information are fused together to generate the fused data required for subsequent session keys.

[0114] During the integration process, the digital identity tuple is parsed into multiple fields. The identity digest value is extracted from the first data to be signed in the root identity data, and the timestamp and location information are extracted from the second data to be signed in the status data to ensure session timeliness and regional uniqueness. The digest value of the historical authorization status is extracted from the list of authorization records in the cross-domain data. These pieces of information together form a set of identity features.

[0115] Trust levels and session counters are encoded into corresponding coded values, while device fingerprint information is processed to generate interface feature vectors, reflecting the physical link characteristics of the battery swapping interface. The identity feature set, coded values, and interface feature vectors are concatenated to form initial fused data. A unique salt value is generated based on the coded values ​​and timestamps, and this salt value is further fused with the initial fused data to obtain the fused data for this session. This fused data integrates identity features, trust levels, session counters, device fingerprints, and salt value information, ensuring the uniqueness and unpredictability of each session's data, thereby effectively preventing man-in-the-middle attacks and replay attacks.

[0116] Based on this, the fused data is input into the key derivation function of the SM3 cryptographic hash algorithm for hash operation to obtain a fixed-length hash value. After obtaining the fixed-length hash value, the hash value is truncated or formatted and mapped to a session key of a preset length, such as the first 128 or 256 bits, as the session key for this communication session. This session key is bound to the multi-dimensional identity of the vehicle and the battery swapping terminal, as well as to the characteristics of the physical link, and combined with timeliness information to make the session key unique and secure in this session. It is used to encrypt communication data and ensure the confidentiality, integrity and anti-tampering capability of data transmission, thereby significantly improving the overall security authentication level in the battery swapping process.

[0117] In some possible implementations, the salt is random or pseudo-random data used in cryptography to enhance security. It is typically mixed with the user's password or sensitive input data before hashing. Its core function is to prevent pre-computation attacks. The generation method is as follows: the encoded value and timestamp information obtained from the above processing are used. The encoded value originates from the encoding of trust level and session counter, reflecting the current session's state and trust level. The timestamp information comes from the data to be signed in the identity tuple, ensuring the session's temporal uniqueness. The encoded value and timestamp are processed according to fixed combination rules (e.g., bitwise XOR, concatenation, or a simple mixing function) to generate an initial salt. When enhanced randomness is needed, the initial salt can be further hashed or encrypted using a unique vehicle identifier, interface physical characteristics, or random number generator output to obtain the salt used for merging with the initial fusion data.

[0118] S103, based on the trust level and in conjunction with the session key, performs layered encryption on the physical and transport layers of the communication link to establish the corresponding encrypted communication channel. Please refer to [link to relevant documentation]. Figure 3 .

[0119] To ensure clarity and conciseness in the description of the following embodiments, a detailed introduction of the relevant terms is given first.

[0120] The preset first handshake strategy refers to the transport layer security protocol handshake method used when the trust level is level two. This strategy is based on the pre-shared key mode and executes the zero round-trip time handshake process defined in the transport layer security protocol. In this strategy, the two communicating parties can directly carry encrypted application data in the first message packet without waiting for the handshake to complete, thereby reducing the handshake latency to zero round-trip time. It is suitable for battery swapping communication with high real-time requirements in cross-domain trust scenarios.

[0121] The preset second handshake strategy refers to the transport layer security protocol handshake method used when the trust level is level three. This strategy executes the complete handshake process defined in the transport layer security protocol, including certificate exchange, key negotiation, and authentication. In this strategy, the communicating parties generate a new session key through dynamic negotiation and can optionally enable two-way certificate verification to provide the highest level of security protection. It is suitable for battery swapping communication in first-time cross-domain or high-risk scenarios.

[0122] First Transport Layer Security Record: When the trust level is second level, the data unit generated after the battery swapping service data to be transmitted is encapsulated by the transport layer security protocol through a preset first handshake strategy. It includes encrypted service data, message authentication code and related protocol header information. This record serves as input data for physical layer encryption.

[0123] The second transport layer security record refers to the data unit generated after the battery swapping service data to be transmitted is encapsulated with transport layer security protocols through a preset second handshake strategy when the trust level is third. It includes encrypted service data, message authentication code and related protocol header information. This record also serves as input data for physical layer encryption, but it differs from the first transport layer security record in that it uses a dynamically negotiated new session key for encryption and may contain two-way certificate verification information.

[0124] Pre-shared key: refers to a key information distributed and shared in advance through a secure channel before the two communicating parties establish an encrypted session. It is used to verify the identities of both parties and encrypt the transmitted data during the initial handshake phase. In this application, the pre-shared key is derived from the initial value of the session key and can be used to generate encryption keys for the physical layer or transport layer. This ensures that the two communicating parties can verify each other's identities through encryption during the first or multiple handshake rounds and prevents man-in-the-middle attacks or key hijacking.

[0125] To make the following description of the embodiments clear and concise, a technical extension is first provided.

[0126] The SM4 block cipher algorithm is a symmetric block encryption algorithm suitable for encrypting and decrypting fixed-length data blocks. Its basic principles include round key expansion and multi-round iterative transformations. Key operations include XOR operations between data blocks and round keys, nonlinear byte substitution (S-box permutation), fixed linear transformations, and cyclic shifting. Through iterative multi-round transformations, the original data can be highly diffused and bound to the key, thereby ensuring the confidentiality and attack resistance of the encrypted data. In this application, the SM4 block cipher algorithm is used to encrypt the physical and transport layers of battery swapping service data based on a session key or a pre-set key, ensuring the security and uniqueness of the data during link transmission.

[0127] The PKCS#7 encryption syntax standard is a standardized data block padding method used to pad plaintext data that is insufficient in block length, ensuring it meets the fixed block length requirement of the encryption algorithm. Several bytes are appended to the end of the data to be encrypted, with each padding byte equal to the number of padding bytes. For example, if the last block is short of a set number of bytes, then the corresponding number of bytes are padded, with each byte having the value of that padding length. In this application, the PKCS#7 padding method is used to process battery swapping service data into blocks, ensuring that the length of each data block is consistent with the preset block length of the SM4 algorithm, thereby supporting the smooth execution of round function iterative operations and block encryption.

[0128] In some possible implementations, for communication with a trust level of Level 1, the session key generated in step S102 is used to generate a pre-key using the SM3 key derivation function. The pre-key has a preset length of bytes and is used for physical layer data encryption. The battery swapping service data to be transmitted is divided into packets of a set number of bytes each. Packets that are less than the set number of bytes are padded using the PKCS#7 rule. The pre-key is input into the SM4 round key expansion module to generate a round key set. Each round key is obtained by combining the previous round key with a fixed round constant and a nonlinear S-box. Each data packet sequentially enters the SM4 round function for multiple rounds of iterative operations. The round function includes XORing the packet data with the round key, performing byte permutation using a nonlinear S-box, performing a fixed linear transformation, and performing cyclic shift operations. After the packets are encrypted, the outputs of each packet are concatenated in order and XORed with a preset length salt value generated based on the session key and session-related information to form complete ciphertext data, which is then sent through the physical layer communication link to realize the first encrypted communication channel. This process ensures that the ciphertext of each physical link communication depends on the session key and link feature binding, thereby preventing man-in-the-middle attacks or link cloning.

[0129] In the second-level communication, the session key serves as a pre-shared key, executing a handshake strategy. This includes both parties exchanging random numbers, session identifiers, and negotiating encryption parameters, confirming supported SM4 block encryption modes and block modes. The battery swapping service data is encapsulated at the transport layer to generate a first transport layer security record, including data length, sequence number, identifier, and integrity verification fields. After encapsulation, the record is input into the SM4 encryption module in byte-by-byte blocks. Iterative encryption is performed using a round key generated by expanding the session key, with each round performing XOR, S-box permutation, linear transformation, and cyclic shift operations. After encryption, a chained XOR process is performed using a salt value or initialization vector generated based on the session key and session-related information to output second-ciphertext data. This second-ciphertext data is transmitted through the physical layer, forming a second encrypted communication channel, achieving dual protection through transport layer encapsulation and physical layer encryption.

[0130] In the third-level communication, the session key serves as the basic input. A dynamic handshake strategy is executed to generate the negotiation key. The handshake strategy includes both parties exchanging random numbers, link identifiers, timestamps, and identity information. A session negotiation key is generated through nonlinear combination and hash operations, which is used to encrypt the current communication session. The battery swapping service data is then encapsulated at the transport layer to form a second transport layer security record, including fragmented data, sequence numbers, length information, integrity check codes, and identifiers. After encapsulation, this record is input into the SM4 encryption module in byte groups according to a set parameters. Iterative encryption is performed using the round key generated by the negotiation key. Each round performs XOR operations between the group and the round key, S-box nonlinear permutation, linear transformation, and cyclic shift operations. After encryption, each group output is chained XORed with a salt value or initialization vector generated based on the negotiation key and session information to output the third ciphertext data, which is transmitted through the physical layer communication link to establish a third encrypted communication channel. This process ensures the short-term validity of the dynamic negotiation key and high session uniqueness. Combined with transport layer encapsulation and physical layer encryption, it achieves confidentiality, integrity, and authentication of communication data, significantly improving the ability to resist man-in-the-middle attacks, link cloning attacks, and replay attacks.

[0131] In some possible implementations, to achieve dual-layer security protection of the communication link's physical and transport layers, after generating the first or second transport layer security record, the communication interface module does not directly send the transport layer security record to the power line communication link. Instead, before entering the modulation and transmission process of the power line communication controller, it performs physical layer encryption on the transport layer security record. This physical layer encryption does not re-apply layer encryption to the service data itself, but rather uses the session key to control the bit sequence formation method, frequency domain resource allocation method, and modulation parameter generation method during the physical signal generation process. This uniquely binds the physical layer characteristics of the transmitted signal to the current battery swapping session, thus achieving physical layer encryption.

[0132] Specifically, the communication interface module acquires the session key, device fingerprint information, and session counter. The device fingerprint information includes the vehicle-side communication address, the battery swapping-side communication address, and the interface physical feature vector. The communication interface module concatenates the session key, device fingerprint information, and session counter in a preset order to form scrambling seed data, and performs a hash operation on the scrambling seed data using the SM3 cryptographic hash algorithm to obtain the physical layer scrambling key. The physical layer scrambling key is used as the initialization parameter of a pseudo-random sequence generator, which generates a corresponding pseudo-random bit sequence through a linear feedback shift register. This pseudo-random bit sequence is then used as the physical layer scrambling sequence. The communication interface module converts the transport layer security record to be transmitted into a continuous bit stream, and performs a bitwise XOR operation between the continuous bit stream and the physical layer scrambling sequence to obtain the scrambled transmission bit stream. Because the physical layer scrambling sequence is dynamically associated with the session key, device fingerprint information, and session counter, even when sending the same battery swapping service data, different physical layer transmission bit streams will be generated.

[0133] After scrambling, the communication interface module generates dynamic frequency domain selection parameters based on the physical layer scrambling key. Specifically, the communication interface module uses the physical layer scrambling key to generate a frequency domain index sequence and selects a target transmission carrier set from multiple available subcarriers supported by the power line communication system based on the frequency domain index sequence. The target transmission carrier set is used to carry the data for this battery swapping service, while unselected subcarriers remain idle or carry invalid padding data. Since the target transmission carrier set changes dynamically with the session key, different communication sessions correspond to different frequency domain resource distribution characteristics. After completing the frequency domain resource selection, the communication interface module further generates dynamic carrier mapping parameters based on the physical layer scrambling key and constructs a carrier mapping table based on the dynamic carrier mapping parameters. The carrier mapping table is used to define the mapping relationship between the scrambled bit stream and the target transmission carrier set.

[0134] Specifically, the communication interface module uses the physical layer scrambling key to generate a random sorting sequence, and rearranges the carrier numbers of the target transmission carrier set according to the random sorting sequence, thereby forming a corresponding carrier mapping table. The communication interface module maps the scrambled transmission bit stream to the corresponding target transmission carrier according to the carrier mapping table, realizing the dynamic binding of data and carrier resources.

[0135] After carrier mapping is completed, the communication interface module performs modulation processing. During modulation, the communication interface module generates phase perturbation parameters based on the physical layer scrambling key. These phase perturbation parameters control the phase offset of the transmitted symbols. The communication interface module performs dynamic phase rotation processing on the modulated symbols based on the phase perturbation parameters, causing the modulated transmitted signal to dynamically change relative to the standard modulated signal. Since the phase perturbation parameters are dynamically generated by the session key, different sessions correspond to different modulation phase characteristics. The communication interface module inputs the processed modulated signal into the power line communication controller for transmission and then transmits it to the receiving end via the battery swapping interface link.

[0136] After receiving the power line communication signal, the receiving end recovers the physical layer scrambling key using the session key corresponding to the current session; it then recovers the target transmission carrier set, carrier mapping table, and phase perturbation parameters based on the physical layer scrambling key; next, it sequentially performs phase compensation processing, carrier inverse mapping processing, and frequency domain recovery processing to obtain the corresponding scrambling code and transmit the bit stream; it then performs inverse scrambling processing using the physical layer scrambling code sequence to recover the original transport layer security record, and finally recovers the battery swapping service data through the transport layer decryption process.

[0137] Through the above mechanism, the session key also participates in the physical layer encryption process, dynamically binding the formation process of the physical layer transmitted signal with the current battery swapping session. Even if an attacker obtains the original power line communication signal in the communication link, they still cannot correctly recover the real business data because they cannot obtain the corresponding session key and dynamic physical layer parameters. This achieves collaborative protection between physical layer encryption and transport layer encryption, improving the anti-eavesdropping capability, anti-link cloning capability, and anti-replay attack capability in the battery swapping communication process.

[0138] In some possible implementations, under the second-level trust strategy, the core purpose of the handshake strategy is to transmit trust confirmation information of the session key on the communication link and encapsulate the battery swapping service data to generate a first transport layer security record.

[0139] Specifically, the session key is used as a pre-shared key, and an initial handshake request is sent through a physical layer secure channel. This handshake request includes an identity digest, session counter, and timestamp information encrypted with SM4 blocks, used to verify the identities of both communicating parties and the validity of the session. The receiving end decrypts the handshake request and verifies the validity of the identity digest and timestamp. If the verification passes, a handshake response is generated, including an acknowledgment message and an encrypted random number, used to further strengthen the uniqueness of subsequent session keys. The sending end generates a complete first-level transport layer security record based on the handshake response, encapsulates the original battery swapping service data, adds message integrity verification information, and encrypts the encapsulated data using SM4 to obtain second-level ciphertext data, thus completing the establishment of the second-level encrypted communication channel.

[0140] Under the third-level trust strategy, the handshake policy is more stringent and suitable for high-security communication scenarios. Its main features include dynamic generation of the negotiation key and multi-round verification. The communicating parties exchange their random numbers and device fingerprint digests based on an initial session key, transmitting them via SM4 block-encrypted handshake messages to form the first handshake. After verifying the consistency of the other party's random numbers and device fingerprints, the receiving end generates a negotiation key, which is used for subsequent data encryption. Subsequently, the sending end encapsulates the original battery swapping service data into a second-layer transport layer security record, appending a session counter and timestamp information to prevent replay attacks, and then encrypts it using the negotiation key with SM4 to generate third-layer ciphertext data, completing the establishment of a layered encrypted communication channel under a high trust level. This strategy, through dynamic key negotiation and multi-round verification mechanisms, ensures link security and data integrity, preventing man-in-the-middle attacks, replay attacks, and key leakage.

[0141] In some possible implementation methods, after the encrypted communication channel is established, a dynamic key update mechanism based on a session counter is introduced to ensure the security and controllability of the session key during communication. After the encrypted communication channel is established and enters the normal communication phase, both the sending and receiving ends in the communication link maintain a unified session counter. The session counter records the number of times the current session key is used in encrypted battery swapping service data. Each time a packet of battery swapping service data is successfully encrypted and transmitted, the session counter automatically increments, and the current session counter status information is synchronously carried in the corresponding transport layer security record. This allows the receiving end to perform consistency verification on the number of times the session key is used, thereby ensuring that the usage status of the session key remains synchronized between the communicating parties. During the continuous accumulation of the session counter, the number of key uses is statistically analyzed in real time and stored in the security management module to determine the current session key's security lifecycle.

[0142] When the number of times a key is used is detected to have reached or exceeded a preset usage threshold, the key management module in the communication link triggers a session key update process. Based on the current session key, session counter status information, link identification information, and the current session random number, a new key seed is generated. The key seed is then non-linearly expanded and linearly mapped using SM3's key derivation function to generate the updated session key. After generation, the updated session key undergoes consistency verification. The sending end sends a key update notification to the receiving end through the established encrypted communication channel. The receiving end decrypts the key update notification and verifies the consistency between the session counter and the link identification information. If the verification passes, both parties synchronously replace the old session key and enter a new session encryption cycle. During the key replacement process, the old session key is marked as invalid and erased in a secure storage area to prevent key reuse or malicious recovery. After the session key update is completed, the communication link re-establishes a new hierarchical encrypted communication channel based on the updated session key and the current trust level, following the same procedure.

[0143] This application's encrypted communication method addresses cross-device and cross-operator data interaction scenarios for electric vehicle battery swapping interfaces. By integrating technologies such as data-generated session keys, dynamic salt value perturbation mechanisms, trust-level hierarchical encryption strategies, and session counter key lifecycle management, it enables vehicles and battery swapping stations to automatically match the corresponding encryption strength based on different link trust environments during short-term, high-frequency communication. In trusted link environments, it ensures low-latency transmission of battery swapping service data; in cross-network environments, it enhances data anti-tampering capabilities; and in high-risk access environments, it strengthens the ability to block unauthorized devices. Simultaneously, the dynamic session key update mechanism avoids security risks caused by long-term key use. Thus, it achieves a synergistic improvement in communication security, real-time performance, and stability during continuous operation of battery swapping services, enhancing the security protection and reliable operation capabilities of the swappable interface in complex network environments.

[0144] The foregoing has shown and described the basic principles, main features, and advantages of this application. Those skilled in the art should understand that this application is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of this application. Various changes and modifications can be made to this application without departing from the spirit and scope thereof, and all such changes and modifications fall within the scope of this application as claimed. The scope of protection of this application is defined by the appended claims and their equivalents.

Claims

1. A multimodal security authentication system with a swappable interface, characterized in that, The system includes: The interface detection module is set on the battery swapping side and is used to detect the connection characteristics of the battery swapping interface after the physical connection between the battery swapping side and the vehicle side is established, so as to obtain the corresponding connection status information. The identity tuple module is set on the vehicle side and includes a root identity layer, a state layer, a cross-domain layer, and a fusion layer. The root identity layer is used to obtain the identity credential information on the vehicle side, and sign the identity credential information according to the first preset private key to obtain root identity data. The first preset private key is the device private key on the vehicle side. The state layer is used to obtain battery swapping behavior information of the vehicle at the current battery swapping moment, and to sign the battery swapping behavior information according to the derived key of the first preset private key to obtain state data. The cross-domain layer is used to obtain the authorization record issued by the battery swapping side to the vehicle side, wherein the authorization record is signed by the battery swapping side using the private key of the battery swapping side operator as a second preset private key; Based on the preset public key of the battery swapping operator, the authorization record is signed and verified to obtain the verified authorization record; The verified authorization records are stored according to their corresponding authorization timestamps to form an authorization record list; Based on the first preset private key, the list of authorized records is signed to obtain third signature data. The list of authorized records and the third signature data are then combined to obtain cross-domain data. The fusion layer is used to fuse the root identity data, state data, and cross-domain data to obtain a digital identity tuple. The authentication module is located on the battery swapping side and is used to authenticate the vehicle side based on the connection status information and the digital identity tuple to obtain authentication information; The communication interface module is used to establish an encrypted communication channel between the battery swapping side and the vehicle side based on the authentication information. The encrypted communication channel is used to transmit battery swapping service data between the battery swapping side and the vehicle side.

2. The system according to claim 1, characterized in that, The root identity layer is specifically used for: Obtain vehicle-side identity credential information, including vehicle identification number, vehicle digital certificate, and vehicle identity identifier; The vehicle identification number, vehicle digital certificate and vehicle identity identifier are combined in a preset order to form the first data to be signed; The first data to be signed is signed according to the first preset private key to obtain the first signed data. The first signed data is then combined with the first data to be signed to obtain the root identity data.

3. The system according to claim 2, characterized in that, The state layer is specifically used for: Obtain battery swapping behavior information from the vehicle side at the current battery swapping moment. The battery swapping behavior information includes timestamp information, location information, and device behavior fingerprint. The timestamp information, location information, and device behavior fingerprint are combined in a preset order to form the second data to be signed; The second data to be signed is signed using a derived key from the first preset private key to obtain second signed data. The second signed data is then combined with the second data to be signed to obtain status data.

4. The system according to claim 3, characterized in that, The authentication information includes trust level, session counter, and authentication status result. The authentication module is specifically used for: Obtain the connection status information and the digital identity tuple; Parse the digital identity tuple to obtain the corresponding root identity data, status data, and cross-domain data; Based on the public key corresponding to the first preset private key, perform hash verification on the first signature data and the first data to be signed in the root identity data to obtain the root identity verification result. Based on the public key corresponding to the derived key, perform a hash verification on the second signature data and the second data to be signed in the state data to obtain the state verification result; Based on the status verification result, the second data to be signed is authenticated to obtain the status authentication result; Based on the public key corresponding to the first preset private key, the third signature data of the cross-domain data and the list of authorized records are hashed to verify the cross-domain verification result. Based on the cross-domain verification result, the list of authorized records is authenticated to obtain the cross-domain authentication result; Based on the root identity verification result, status authentication result, and cross-domain authentication result, the corresponding trust level is obtained, and the corresponding authentication status result is generated by combining the connection status information. When the authentication status result is successful, a corresponding session counter is generated.

5. An encrypted communication method for a swappable interface, characterized in that, Applied to the system according to any one of claims 1-4; To obtain authentication information, based on the battery swapping interface link, the communication addresses of the vehicle side and the battery swapping side are exchanged, and the physical characteristics of the interface are extracted by combining the connection status information to obtain the device fingerprint information. When the authentication status result is successful, the digital identity tuple, the trust level and session counter in the authentication information, and the device fingerprint information are fused together to obtain fused data. The fused data is then processed to generate the corresponding session key. Based on the trust level and in conjunction with the session key, the battery swapping service data to be transmitted is encrypted in layers at the physical layer and transport layer of the communication link to establish a corresponding encrypted communication channel. The encrypted communication channel is used to transmit battery swapping service data between the battery swapping side and the vehicle side.

6. The method according to claim 5, characterized in that, The step of fusing the digital identity tuple, the trust level and session counter in the authentication information, and the device fingerprint information to obtain fused data includes: The digital identity tuple is parsed to extract the digest value of the first data to be signed in the root identity data, the timestamp information and location information of the second data to be signed in the status data, and the digest value of the authorization record list in the cross-domain data to form an identity feature set. The trust level and session counter are encoded to obtain corresponding encoded values; The device fingerprint information is processed to obtain the corresponding interface feature vector; The identity feature set, encoded value, and interface feature vector are concatenated to obtain initial fused data. Based on the encoded value and timestamp information, a corresponding salt value is generated. The salt value is then fused with the initial fused data to obtain fused data.

7. The method according to claim 5, characterized in that, The process of processing the fused data to generate a corresponding session key includes: The fused data is hashed according to the key derivation function of the SM3 cryptographic hash algorithm to obtain the corresponding hash value; The hash value is truncated and used as the corresponding session key.

8. The method according to claim 6, characterized in that, The trust levels include a first level, a second level, and a third level. Based on the trust level and the session key, the data to be transmitted for battery swapping services is encrypted layer by layer at the physical and transport layers of the communication link to establish a corresponding encrypted communication channel, including: If the trust level is the first level, a corresponding pre-key is generated based on the session key. At the physical layer of the communication link, the battery swapping service data to be transmitted is encrypted based on the pre-key and the preset SM4 block cipher algorithm to generate the corresponding first ciphertext data. The first ciphertext data is transmitted through a communication link to form a corresponding first encrypted communication channel; If the trust level is the second level, the session key is used as the pre-shared key. Based on the pre-shared key, a preset first handshake strategy is executed, and the battery swapping service data to be transmitted is encapsulated to generate the corresponding first transport layer security record. At the physical layer of the communication link, the first transport layer security record is encrypted based on the session key and the preset SM4 block cipher algorithm to obtain the corresponding second ciphertext data. The second encrypted data is transmitted through a communication link to form a corresponding second encrypted communication channel; If the trust level is level three, based on the session key, a preset second handshake strategy is executed to generate a corresponding negotiation key, and the battery swapping service data to be transmitted is encapsulated to generate a corresponding second transport layer security record. At the physical layer of the communication link, the second transport layer security record is encrypted based on the negotiated key and the preset SM4 block cipher algorithm to obtain the corresponding third ciphertext data. The third encrypted data is transmitted through a communication link to form a corresponding third encrypted communication channel.

9. The method according to claim 5, characterized in that, Also includes: After the encrypted communication channel is established, the number of times the session key is used is counted based on the session counter to obtain the key usage count; When the number of times the key is used is greater than or equal to a preset usage threshold, the session key is updated to obtain the updated session key; Based on the updated session key and trust level, the battery swapping service data to be transmitted is encrypted in layers at the physical layer and transport layer of the communication link to establish a corresponding encrypted communication channel.

Images