Hybrid key encapsulation and signature method for vehicle iot gps beidou communication

Abstract

The application relates to the technical field of secure communication, and discloses a hybrid key encapsulation and signature method for vehicle Internet of Things GPS Beidou communication, which comprises the following steps: a vehicle-mounted terminal records GPS data arrival time and Beidou data arrival time in the same positioning period, obtains a positioning interval, an uplink round trip time, an uplink available byte number and a safety frame byte number, generates a double-source same epoch closed loop sending window, a window number, a window byte string and a window digest; the window digest is written into a vehicle end handshake signature, and the window number is written into a plaintext check header of a first positioning message. A vehicle Internet of Things platform verifies the vehicle end handshake signature and reconstructs the sending window, registers a first package record, checks the window number, a session number, a message serial number and the first package record when receiving the first positioning message, and decrypts the encrypted message to obtain the positioning message after the checking. The application is used for improving the consistency of double-source positioning uplink secure exchange and first package receiving processing.

Description

Technical Field

[0001] This invention relates to the field of secure communication technology, and more specifically, to a hybrid key encapsulation and signature method for GPS-BeiDou communication in vehicle Internet of Things (IoT) applications. Background Technology

[0002] Existing vehicle IoT platforms typically report location data via in-vehicle terminals, cellular networks, and platform access services. Common processing steps on the vehicle side include GNSS reception, location data packetization, session establishment, certificate verification, key negotiation, signature verification, authentication encryption, and retransmission management. With the introduction of post-quantum key encapsulation and digital signatures into the secure channel of the vehicle network, the initial handshake message carries more cryptographic materials and certificate information, making it more sensitive to single-frame carrying capacity, latency jitter, and retransmission processing in mobile networks. When GPS and BeiDou data enter the communication process within the same reporting cycle, the arrival time sequence, positioning cycle boundaries, link round-trip time, and first packet transmission timing of the two sources need to be consistently processed on the protocol side. Otherwise, the platform may only verify the session key and message integrity, but it may be difficult to confirm whether the handshake, signature, and first packet message come from the same round of dual-source positioning reporting. Engineering implementation also needs to consider existing in-vehicle hardware and platform access services, avoiding the introduction of positioning coordinates or vehicle service fields into the key material, while reducing the burden of first packet mismatch, cross-session reuse, duplicate submissions, and fragmentation processing caused by insufficient single-frame carrying capacity. Therefore, a processing method for secure uplink communication of GPS and BeiDou for vehicle IoT is needed, which integrates dual-source arrival, link carrying, handshake signing, and first packet reception status into the same verifiable process under the collaboration of existing vehicle terminals, cellular communication modules, and platform services. Summary of the Invention

[0003] This invention provides a hybrid key encapsulation and signature method for GPS and BeiDou communication in vehicle Internet of Things, which solves the technical problems mentioned in the background art.

[0004] To achieve the above-mentioned objectives, the present invention provides the following technical solution.

[0005] A hybrid key encapsulation and signature method for GPS-BeiDou communication in vehicle IoT is applied to in-vehicle terminals and vehicle IoT platforms. The in-vehicle terminal obtains location messages, including: The vehicle-mounted terminal records the arrival time of GPS data and BeiDou data in the same positioning cycle, and obtains the positioning interval, uplink round-trip time, number of available uplink bytes, and number of security frame bytes. The vehicle terminal determines the dual-source time difference based on the arrival time of the GPS data and the arrival time of the Beidou data, determines the remaining closed-loop time based on the positioning interval, the dual-source time difference, and the uplink round-trip time, and determines the single-frame carrying conditions based on the number of available uplink bytes and the number of security frame bytes. When the remaining time of the closed loop meets the time conditions required for one request and confirmation and the single frame carrying conditions are met, a dual-source same-epoch closed loop sending window, window number, window byte string and window summary are generated, and a local countdown is started based on the remaining time of the closed loop. The vehicle terminal writes the window summary into the vehicle handshake signature and writes the window number into the plaintext verification header of the first location message; The vehicle IoT platform verifies the vehicle-side handshake signature and reconstructs the dual-source same-epoch closed-loop transmission window, registering a waiting first packet record containing the window number, session number, and message sequence number; When the vehicle IoT platform receives the first location message, it verifies the consistency between the window number, session number, message sequence number, and the waiting first packet record, and decrypts the encrypted message to obtain the location message after the verification is successful.

[0006] Compared with the prior art, the present invention has the following substantial features and significant progress: This invention, without altering the existing positioning reception, processing, and cellular communication capabilities of the vehicle terminal, incorporates GPS data arrival time, BeiDou data arrival time, positioning interval, uplink round-trip time, uplink available bytes, and security frame bytes into a dual-source, same-epoch closed-loop transmission window before the vehicle-side handshake. The window digest is bound to the vehicle-side handshake signature, and the window number is bound to the first positioning message. This allows the vehicle IoT platform to verify whether the hybrid key establishment, vehicle-side signature, and first packet message correspond to dual-source arrival events within the same positioning cycle. Simultaneously, the platform distinguishes between normal first packets, identical retransmissions, and cross-session reuse by waiting for the first packet record, session number, message sequence number, and first packet ciphertext digest. This reduces cross-cycle exchanges, first packet mismatches, fragmentation processing, and duplicate submissions, improving the consistency and auditability of vehicle positioning data uplink security processing. Attached Figure Description

[0007] Figure 1 This is a system mechanism diagram of the hybrid key encapsulation and signature method for GPS and Beidou communication in vehicle Internet of Things according to the present invention. Detailed Implementation

[0008] The following description is provided in conjunction with the accompanying drawings. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the invention; those skilled in the art can make equivalent substitutions or combinations for the specific implementations.

[0009] This embodiment relates to a hybrid key encapsulation and signature method for GPS / BeiDou communication in vehicle IoT, applied to a secure communication scenario between an in-vehicle terminal and a vehicle IoT platform. After obtaining the location message, the in-vehicle terminal needs to send the GPS / BeiDou location data and existing service fields to the vehicle IoT platform. Both the in-vehicle terminal and the vehicle IoT platform already possess mobile communication interfaces, certificate verification capabilities, hybrid key establishment capabilities, digital signature capabilities, and authentication encryption capabilities. This embodiment adds a dual-source, same-epoch closed-loop transmission window, window number, window byte string, window digest, waiting for the first packet record, and consistency check of the first location message message at the communication protocol processing layer.

[0010] See Figure 1 The vehicle-mounted terminal 100 serves as the vehicle-side boundary, and the vehicle IoT platform 200 serves as the platform-side boundary. The certificate trust service 300 issues digital certificates to the vehicle-mounted terminal 100 and the vehicle IoT platform 200 and provides trust anchors and certificate status query information. The vehicle-mounted terminal 100 internally includes a dual-source positioning input unit 110, a vehicle-mounted window generation unit 120, a vehicle-side key establishment unit 130, a vehicle-side signature binding unit 140, and a first-packet encrypted transmission unit 150. The vehicle IoT platform 200 internally includes a platform window reconstruction and signature verification unit 210 and a first-packet consistency verification and decryption unit 220.

[0011] Specifically, GPS and BeiDou results may arrive sequentially within the same positioning period. Hybrid key establishment introduces fields such as traditional shared keys, quantum-resistant encapsulated data, quantum-resistant shared keys, platform certificates, platform handshake signatures, and vehicle-side handshake signatures, leading to an increase in the number of bytes exchanged during the initial secure exchange. If only general key establishment, vehicle-side handshake signature, message signature, and authentication encryption are performed, the vehicle IoT platform can verify identity, key materials, and the integrity of encrypted messages. However, it is difficult to confirm a reconstructable relationship between the vehicle-side handshake signature and the arrival times of GPS and BeiDou data within the same positioning period, and it is also difficult to confirm that the first positioning message still belongs to the already verified dual-source arrival event.

[0012] In this implementation, apart from the fixed key materials, public key materials, quantum-resistant encapsulated data, signatures, encrypted messages, and integrity tag lengths of the respective standards X25519, ML-KEM-768, HKDF-SHA-256, ML-DSA-65, and AES-256-GCM, the in-vehicle terminal and vehicle IoT platform perform the same fixed encoding on the fields entering hash processing, key derivation, signature, and authentication encryption. Fixed encoding means that integers use unsigned network byte order, the time field uses 8 bytes, the message sequence number uses 8 bytes, the byte number field uses 4 bytes, the window availability flag uses 1 byte, the SHA-256 output uses 32 bytes, and the original protocol byte string is prefixed with an unsigned length before the original bytes. This fixed encoding is applied throughout the window number, window byte string, window digest, handshake byte string, initial handshake digest, acknowledgment handshake digest, plaintext checksum header, encrypted random variable, and first packet ciphertext digest.

[0013] Furthermore, the implementation methods for dual-source positioning input and dual-source co-epoch closed-loop transmission window are as follows: Before the vehicle-mounted terminal obtains the positioning message, the dual-source positioning input unit 110 receives GPS and BeiDou results. The GPS data arrival time is the terminal's local monotonic clock value read when the GPS result is delivered to the communication process by the existing positioning program, and the BeiDou data arrival time is the terminal's local monotonic clock value read when the BeiDou result is delivered to the communication process by the existing positioning program. The GPS and BeiDou data arrival times use the same terminal local monotonic clock to eliminate conversion errors between different system clocks, satellite time, or network time, so that the subsequent dual-source time difference can only express the time span between the GPS and BeiDou results entering the same communication process.

[0014] The positioning interval is the current reporting cycle configuration of the existing positioning receiver. The positioning interval is not a manually set empirical threshold, but rather a cycle configuration already used by the vehicle's existing positioning receiver or existing positioning processing program. The positioning interval is used to define the time boundary of the same positioning cycle, enabling the vehicle terminal to determine whether the current secure exchange triggered by both GPS and BeiDou results still belongs to the current positioning cycle. If the vehicle's existing positioning receiver reports positioning results according to a one-second, two-second, or other protocol configuration, the positioning interval is read according to that existing configuration.

[0015] The uplink round-trip time is the round-trip duration of the most recent heartbeat or request-response completed by the communication module. The uplink round-trip time is derived from request-response records stored in the existing cellular communication module or communication process of the vehicle terminal, and is used to express the measured time required for the current link to complete one request and acknowledgment. The uplink round-trip time serves as a conventional measurement value in the prior art for determining whether the remaining closed-loop time is sufficient to accommodate one request and acknowledgment. The uplink available bytes are the number of bytes of unfragmented uplink payload in the current link, used to express the uplink payload boundary that the current link can carry under unfragmented conditions.

[0016] The number of bytes in the security frame is the actual number of bytes generated by the existing serializer for this candidate secure exchange. To avoid self-references between the number of bytes in the security frame and the window byte string, window digest, and vehicle-side handshake signature, this implementation determines the number of bytes in the security frame according to a fixed-length template. The fixed-length template consists of a fixed algorithm suite identifier, vehicle-side certificate or vehicle-side certificate reference, quantum-resistant encapsulated data, session number, window byte string field length, window digest field length, vehicle-side handshake signature field length, and prefixes for each field length. The window byte string field length is obtained by summing the fixed encoded lengths of GPS data arrival time, BeiDou data arrival time, positioning interval, uplink round-trip time, uplink available bytes, security frame byte count, dual-source time difference, remaining loop time, remaining bytes, window availability flag, and window number. The window digest field length is fixed at 32 bytes. The vehicle-side handshake signature field length is determined according to the ML-DSA-65 standard output length, and the quantum-resistant encapsulated data field length is determined according to the ML-KEM-768 standard output length. Before generating the window byte string, the vehicle terminal first calls the existing serializer according to the above fixed-length template to calculate the number of security frame bytes, then writes the number of security frame bytes into the window byte string and calculates the window digest and vehicle handshake signature.

[0017] The vehicle-mounted window generation unit 120 first determines the dual-source time difference based on the arrival times of GPS and BeiDou data. The dual-source time difference represents the absolute difference between the arrival times of GPS and BeiDou data, reflecting the waiting time for dual-source results to enter the communication process within the same positioning cycle. Its calculation relationship is as follows: in, Indicates the time difference between the two sources. Indicates the arrival time of GPS data. This indicates the arrival time of the BeiDou data.

[0018] The vehicle-mounted window generation unit 120 then determines the remaining closed-loop time based on the positioning interval, the dual-source time difference, and the uplink round-trip time. The remaining closed-loop time represents the time remaining after deducting the dual-source time difference and the uplink round-trip time from the positioning interval, used to determine whether the measured time conditions for completing a request and confirmation are still available within the current positioning cycle. Its calculation relationship is as follows: in, This indicates the remaining time for the closed loop. Indicates the positioning interval. Indicates the time difference between the two sources. This indicates the uplink round-trip time. GPS data arrival time, BeiDou data arrival time, positioning interval, uplink round-trip time, dual-source time difference, and remaining loop time are all calculated and encoded using millisecond-level monotonic clock counting units. If the positioning interval is given in seconds by an existing positioning receiver, the vehicle terminal multiplies it by 1000 before calculation to convert it to millisecond-level monotonic clock counting units. When the remaining loop time meets the time requirements for one request and confirmation, it is expressed as... As an executable condition; when If the positioning interval has no positive remaining time after deducting the dual-source time difference and uplink round-trip time, the vehicle terminal will not enter the key establishment process.

[0019] The vehicle-mounted window generation unit 120 determines the remaining number of bytes based on the number of available uplink bytes and the number of security frame bytes, and uses the remaining number of bytes to determine the single-frame carrying conditions. The remaining number of bytes represents the number of bytes remaining after deducting the number of security frame bytes from the number of available uplink bytes, and its calculation relationship is as follows: in, Indicates the number of remaining bytes. Indicates the number of bytes available in the upstream line. This indicates the number of bytes in the security frame. The number of available uplink bytes, security frame bytes, and remaining bytes are all calculated and encoded using bytes. If the bearer boundary given by the communication module is expressed in bits or the total link layer length, the vehicle terminal first converts it to the number of bytes of unfragmented uplink payload before participating in the calculation of the remaining bytes. As an executable condition; when If the current candidate secure exchange cannot be fully carried within the current number of bytes of the unfragmented uplink payload, the vehicle terminal will not enter the key establishment process.

[0020] When the remaining time of the closed-loop operation meets the time requirements for one request and acknowledgment, and the remaining number of bytes meets the single-frame carrying requirements, the on-board window generation unit 120 sets the window availability flag to an available state. The window availability flag represents the protocol judgment value indicating whether the remaining time of the closed-loop operation and the remaining number of bytes meet the conditions for entering secure exchange. Its calculation relationship is as follows: in, Indicates that the window is available. This indicates the remaining time for the closed loop. Indicates the number of remaining bytes. This indicates an indicator function that takes the value corresponding to the available state when all conditions within the parentheses are true, and takes the value corresponding to the unavailable state when any condition is false.

[0021] When the window availability flag is in an available state, the vehicle-mounted window generation unit 120 generates a dual-source, same-epoch closed-loop transmission window. The dual-source, same-epoch closed-loop transmission window is a protocol processing relationship jointly defined by GPS data arrival time, BeiDou data arrival time, positioning interval, uplink round-trip time, number of uplink available bytes, number of security frame bytes, dual-source time difference, remaining closed-loop time, number of remaining bytes, and the window availability flag. Specifically, the time endpoint is defined by the remaining closed-loop time, the byte endpoint by the number of remaining bytes, and the cross-message anchor point is defined by the window number and window summary.

[0022] The vehicle-mounted window generation unit 120 generates a window number. The window number is obtained by hashing the vehicle terminal number, message sequence number, GPS data arrival time, BeiDou data arrival time, and positioning interval. The calculation relationship is as follows: in, Indicates the window number. This indicates SHA-256 hash processing, with an output length of 32 bytes. Indicates the vehicle end number. Indicates the message sequence number. Indicates the arrival time of GPS data. Indicates the arrival time of BeiDou data. Indicates the positioning interval. This indicates that each field is concatenated in a fixed order after being encoded in a fixed manner. The vehicle terminal number is encoded according to the original byte string of the protocol with the first 2 bytes of unsigned length. The message sequence number is encoded as an 8-byte unsigned integer. The GPS data arrival time, BeiDou data arrival time, and positioning interval are all encoded as 8-byte unsigned integers. All integers adopt network byte order. The window number binds the vehicle terminal number, message sequence number, and dual-source arrival times within the same positioning period, so that any change in time reading or message sequence number within the same positioning period will cause the window number to change.

[0023] The vehicle-mounted window generation unit 120 generates a window byte string. The window byte string is obtained by serializing the GPS data arrival time, BeiDou data arrival time, positioning interval, uplink round-trip time, number of available uplink bytes, number of security frame bytes, dual-source time difference, remaining closed-loop time, number of remaining bytes, window availability flag, and window number in a fixed field order. The calculation relationship is as follows: in, Represents a window byte string. This indicates serialization in a fixed field order. Indicates the round-trip time. Indicates the number of bytes available in the upstream line. Indicates the number of bytes in the security frame. The window availability flag indicates that the GPS data arrival time, BeiDou data arrival time, positioning interval, uplink round-trip time, dual-source time difference, and remaining closed-loop time in the window byte string are all encoded as 8-byte unsigned integers; the number of available uplink bytes, the number of security frame bytes, and the number of remaining bytes are all encoded as 4-byte unsigned integers; the window availability flag is encoded as 1 byte, and its availability status is [not specified]. The unavailable status is The window number is encoded according to the 32-byte raw digest; all integers are in network byte order. Both the in-vehicle terminal and the vehicle IoT platform generate or parse the window byte string according to the same field order and the same encoding rules.

[0024] The vehicle-mounted window generation unit 120 generates a window digest. The window digest is obtained by hashing the window byte string. The calculation relationship is as follows: in, Indicates a window summary. This represents the window byte string. The window digest is obtained by SHA-256 hashing, with an output length of 32 bytes. The window digest is input to the vehicle-side handshake signature with a fixed length, enabling the vehicle IoT platform to verify that the window byte string has not been tampered with, while avoiding directly extending the longer original window fields into the signature interface. The window byte string is still sent by the vehicle terminal to the vehicle IoT platform, enabling the vehicle IoT platform to reconstruct the dual-source, same-epoch closed-loop transmission window.

[0025] After generating the window summary, the vehicle terminal starts a local countdown based on the remaining time of the closed loop. The duration of the local countdown corresponds to the remaining time of the closed loop and is used to control the eligibility of sending the first location message. The local countdown is used to maintain the time boundary of the same dual-source, same-epoch closed loop transmission window between the current vehicle-side handshake signature and the first location message.

[0026] Furthermore, the implementation methods for key establishment, handshake context, and vehicle-side handshake signature are as follows: The vehicle-side key establishment unit 130 is used to perform key establishment. The vehicle-mounted terminal generates a vehicle-side random number and a vehicle-side temporary public key and sends a handshake request to the vehicle IoT platform. The vehicle-side random number is newly generated by the vehicle-mounted terminal for each handshake and is used to distinguish different sessions and suppress replay; the vehicle-side temporary public key is obtained from the vehicle-side temporary private key and is used to form a traditional shared key. The handshake request sent by the vehicle-mounted terminal carries at least the vehicle-side number, the vehicle-side random number, the vehicle-side temporary public key, and a fixed algorithm suite identifier, enabling the vehicle IoT platform to verify the identity, random input, temporary public key, and algorithm combination used in this handshake request.

[0027] Upon receiving the handshake request, the vehicle IoT platform returns a platform random number, a platform temporary public key, a quantum-resistant encapsulated public key, a platform certificate, and a platform handshake signature. The platform random number is newly generated by the vehicle IoT platform for each handshake and is used to prove the freshness of the platform's response; the platform temporary public key is obtained from the platform temporary private key; the quantum-resistant encapsulated public key is the vehicle IoT platform's ML-KEM-768 public key; the platform certificate is used to bind the platform ID, the platform verification public key, and the quantum-resistant encapsulated public key to the digital certificate system issued by Certificate Trust Service 300; the platform handshake signature proves the vehicle IoT platform's control over the temporary public key and the quantum-resistant encapsulated public key.

[0028] The vehicle-mounted terminal verifies the platform certificate, platform handshake signature, and handshake context. Platform certificate verification includes checking the certificate chain, certificate validity period, certificate status, and platform number within the certificate. Platform handshake signature verification involves using the platform's verification public key to check whether the handshake signature covers the vehicle-mounted terminal number, platform number, vehicle-mounted random number, platform random number, vehicle-mounted temporary public key, platform temporary public key, quantum-resistant encapsulation public key, and fixed algorithm suite identifier. Handshake context verification confirms that the platform response matches the current vehicle-mounted terminal number, vehicle-mounted random number, vehicle-mounted temporary public key, and fixed algorithm suite identifier. If any verification fails, the vehicle-mounted terminal terminates the connection and clears the vehicle-mounted temporary private key.

[0029] The handshake context includes at least the vehicle ID, platform ID, vehicle-side random number, platform random number, vehicle-side temporary public key, platform temporary public key, quantum-resistant encapsulation public key, quantum-resistant encapsulation data, and a fixed algorithm suite identifier. The purpose of the handshake context is to provide stable input for the initial handshake digest, ensuring that the traditional shared key, quantum-resistant shared key, synthesized master key, uplink encryption key, downlink encryption key, and session ID are all bound to the same handshake context. The handshake context does not include location coordinates, vehicle brand, vehicle model, geofence, driver information, or other vehicle business payloads.

[0030] The vehicle-mounted terminal generates a traditional shared key, quantum-resistant encapsulated data, and a quantum-resistant shared key. The traditional shared key is obtained by performing an X25519 operation on the vehicle-mounted temporary private key and the platform's temporary public key. The calculation relationship is as follows: in, This refers to a traditional shared key. This represents the vehicle's temporary private key. This represents the platform's temporary public key. Traditional shared keys are used to provide key components based on temporary key negotiation.

[0031] The vehicle terminal performs ML-KEM-768 encapsulation using a quantum-resistant encapsulation public key to obtain quantum-resistant encapsulated data and a quantum-resistant shared key. The computational relationship is as follows: in, Indicates quantum-resistant encapsulated data. Indicates quantum-resistant shared key, This represents the quantum-resistant encapsulated public key. The quantum-resistant encapsulated data is sent to the vehicle's IoT platform, and the quantum-resistant shared key is locally stored by the in-vehicle terminal for use in synthesizing the master key. The X25519 temporary key generation process and the ML-KEM-768 encapsulation process each use their respective specified random sources.

[0032] The vehicle-mounted terminal obtains the handshake byte string from the handshake context and then derives the initial handshake digest from the handshake byte string. The handshake byte string serializes the identities of both parties, random numbers, public keys, encapsulated data, and algorithm identifiers in a fixed order. The calculation relationship for the initial handshake digest is as follows: in, This represents the initial handshake summary. This represents the handshake byte string. The vehicle ID, platform ID, and fixed algorithm suite identifier in the handshake byte string are all encoded with a 2-byte unsigned prefix to the original protocol byte string. The vehicle random number, platform random number, vehicle temporary public key, platform temporary public key, quantum-resistant encapsulated public key, and quantum-resistant encapsulated data are all encoded with a fixed-length original byte string as specified by the corresponding algorithm or protocol. When a certificate or certificate reference enters the handshake byte string, the certificate or certificate reference is encoded with a 4-byte unsigned prefix to the original protocol byte string. All length prefixes and integers use network byte order. The initial handshake digest is obtained by SHA-256 hashing, with an output length of 32 bytes, serving as the key derivation context to ensure that the vehicle terminal and the vehicle IoT platform obtain consistent key derivation results under the same handshake context.

[0033] The vehicle-mounted terminal derives a master key, uplink encryption key, downlink encryption key, and session number from a traditional shared key, a quantum-resistant shared key, and an initial handshake digest. The computational relationship is as follows: in, Indicates the synthesis of the master key. Indicates the uplink encryption key. Indicates the downlink encryption key. Indicates the session number. and Labels representing protocol-predefined byte strings encoded in ASCII. This represents a protocol-predefined session number derived label in ASCII encoding. HKDF uses HKDF-SHA-256, and the output lengths of the synthesized master key, uplink encryption key, and downlink encryption key are all 32 bytes. The session number is obtained by SHA-256 hashing, with an output length of 32 bytes. The uplink encryption key is used for encrypting positioning messages from the vehicle terminal to the vehicle IoT platform, and the downlink encryption key is used for encrypting acknowledgment messages from the vehicle IoT platform to the vehicle terminal.

[0034] The vehicle IoT platform recovers the traditional shared key and the quantum-resistant shared key based on the platform's temporary private key and quantum-resistant encapsulated data. The vehicle IoT platform calculates the traditional shared key using the platform's temporary private key and the vehicle's temporary public key; the calculation relationship is as follows: in, This indicates the platform's temporary private key. This represents the vehicle-side temporary public key. The vehicle IoT platform uses the quantum-resistant desealing private key to perform ML-KEM-768 desealing on the quantum-resistant encapsulated data to obtain the quantum-resistant shared key. The calculation relationship is as follows: in, This represents the quantum-resistant unsealing private key. The vehicle IoT platform derives and synthesizes the master key, uplink encryption key, downlink encryption key, and session number within the same handshake context, and uses the downlink encryption key to generate an encrypted handshake confirmation. Upon receiving the encrypted handshake confirmation, the vehicle terminal checks if the session number matches; if they match, it continues sending the first location message; otherwise, it terminates the current session.

[0035] The vehicle-side signature unit concatenates the initial handshake digest, session number, and window digest in a fixed order to obtain the acknowledgment handshake digest, and then uses the vehicle-side signature private key to generate a vehicle-side handshake signature from the acknowledgment handshake digest. The calculation relationship for the acknowledgment handshake digest is as follows: in, This indicates confirmation of the handshake summary. This represents the initial handshake summary. Indicates the session number. This represents the window digest. The initial handshake digest, session number, and window digest are all 32-byte raw digests or numbered byte strings, concatenated in a fixed order according to the formula, and then processed using SHA-256 hashing to confirm the handshake digest output length is 32 bytes. The confirmed handshake digest compresses the key establishment context, session number, and dual-source same-epoch closed-loop transmission window into the same signature input, enabling the vehicle IoT platform to verify that the vehicle-side handshake signature indeed corresponds to this window digest.

[0036] The calculation relationship for the vehicle-side handshake signature is as follows: in, This indicates a handshake and signature from the vehicle side. This indicates the vehicle-side signature private key. This indicates a confirmation handshake summary. The in-vehicle terminal sends quantum-resistant encapsulated data, session number, window byte string, window summary, vehicle certificate or vehicle certificate reference, and vehicle handshake signature to the vehicle IoT platform.

[0037] Furthermore, the implementation methods for the platform to rebuild the sending window, wait for the first packet record, and verify the number of available bytes in the uplink are as follows: The platform window reconstruction unit is used to reconstruct the dual-source, same-epoch closed-loop transmission window. After verifying the vehicle-side certificate, the vehicle IoT platform parses the window byte string according to a fixed field order and redetermines the number of security frame bytes. When redetermining the number of security frame bytes, the vehicle IoT platform uses the same fixed-length template as the vehicle terminal. Based on the fixed algorithm suite identifier, vehicle-side certificate or vehicle-side certificate reference, quantum-resistant encapsulated data, session number, window byte string field length, window digest field length, vehicle-side handshake signature field length, and prefixes for each field length, it calls the existing serializer to calculate the actual number of bytes formed by the existing serializer for this candidate secure exchange. The vehicle IoT platform does not use the numerical value of the security frame byte count in the window byte string to reverse-determine the window byte string field length, but only uses the fixed encoded length of the security frame byte number segment to participate in the fixed-length template calculation.

[0038] After the platform window reconstruction unit parses the window byte string, it re-determines the dual-source time difference, remaining loop time, remaining bytes, window availability flag, and window number. When re-determining the dual-source time difference, the vehicle IoT platform uses the GPS data arrival time and BeiDou data arrival time in the window byte string to perform the same calculation; when re-determining the remaining loop time, the vehicle IoT platform uses the positioning interval, dual-source time difference, and uplink round-trip time in the window byte string to perform the same calculation; when re-determining the remaining bytes, the vehicle IoT platform uses the uplink available bytes and security frame bytes in the window byte string to perform the same calculation; when re-determining the window number, the vehicle IoT platform uses the vehicle terminal number, message sequence number, GPS data arrival time, BeiDou data arrival time, and positioning interval to perform the same SHA-256 hash processing.

[0039] The vehicle IoT platform verifies the window digest consistency. Specifically, the vehicle IoT platform calculates a window digest for the received window byte string and compares it with the window digest sent by the vehicle terminal. If the window digests do not match, it indicates that the window byte string may have been tampered with during transmission or that the field order is inconsistent, and the vehicle IoT platform terminates the session. If the window digests match, the vehicle IoT platform continues to use the vehicle-side signature verification public key to verify the vehicle-side handshake signature, confirming that the vehicle-side handshake signature covers the initial handshake digest, session number, and window digest.

[0040] The vehicle IoT platform registers a wait-for-first-packet record only when the window availability flag is in an available state, the window number matches, the window summary matches, and the vehicle-side handshake signature is valid. The wait-for-first-packet record contains the window number, session number, and message sequence number.

[0041] The vehicle IoT platform verifies that the number of available uplink bytes is included in the window byte string and bound to the vehicle's handshake signature. Specifically, the number of available uplink bytes is used as a field in the window byte string for window digest calculation. The window digest then participates in the confirmation handshake digest, which is used to generate the vehicle's handshake signature from the vehicle's signing private key. Therefore, the vehicle IoT platform does not accept an isolated declaration of the number of available uplink bytes, but rather an uplink available byte count that has been included in both the window digest and the vehicle's handshake signature.

[0042] The vehicle IoT platform also verifies that the number of available uplink bytes is consistent with the number of security frame bytes, the number of remaining bytes, and the window availability flag in the window byte string. Specifically, the vehicle IoT platform recalculates the number of remaining bytes using the number of available uplink bytes and the number of security frame bytes, and checks whether the recalculated number of remaining bytes is equal to the number of remaining bytes in the window byte string; then, the vehicle IoT platform redetermines the window availability flag using the remaining loop time and the number of remaining bytes, and checks whether the redetermined window availability flag is equal to the window availability flag in the window byte string. If any result is inconsistent, the vehicle IoT platform terminates the session.

[0043] The vehicle IoT platform does not use the number of available uplink bytes as a platform-side remeasurement value. This constraint stems from the fact that the number of available uplink bytes reflects the number of unfragmented uplink payload bytes in the current uplink of the vehicle terminal. The path status measured in real-time by the platform may differ from the uplink bearer status at the time the candidate security exchange is formed. The vehicle IoT platform verifies that the number of available uplink bytes has been bound to the vehicle-side handshake signature and is consistent with the number of security frame bytes, the number of remaining bytes, and the window availability flag, rather than replacing the vehicle terminal-side input with a platform-side remeasurement value.

[0044] The state boundary for the waiting first packet record is jointly maintained by the vehicle IoT platform based on the session number and window number. When the waiting first packet record is in a waiting state, only the first location message with the same session number, window number, and message sequence number as that waiting first packet record is allowed to enter the message signature verification, integrity tag verification, and decryption processing. When the waiting first packet record is in a bound state, only the exact same first location message is allowed to be retransmitted and the original confirmation result is returned. When the waiting first packet record is in a rejected state or an expired state, the corresponding window number will no longer accept new first location message messages. This state boundary is used to ensure that the window number is bound to only one first location message in a single session.

[0045] Specifically, the status of waiting for the first packet record is "waiting" during registration, and changes to "bound" after the first location message is successfully submitted. If the waiting record for the first packet has not been bound to the first packet within the validity period of this session, the vehicle IoT platform can delete the waiting record according to the platform policy.

[0046] Furthermore, the implementation method for the first location message sending, verification, decryption, and retransmission process is as follows: The first packet encryption sending unit 150 is used to generate the first positioning message. After receiving the encrypted handshake confirmation, the vehicle terminal checks the local countdown. If the local countdown has not expired, the vehicle terminal continues to generate the first positioning message; if the local countdown has expired, the vehicle terminal does not use the current session to send the first positioning message, clears the pending state of the window, and re-acquires the positioning message, re-records the GPS data arrival time and BeiDou data arrival time, re-acquires the positioning interval, uplink round-trip time, uplink available bytes, and security frame bytes in the next positioning cycle.

[0047] The vehicle-mounted terminal writes the vehicle terminal number, session number, window number, message sequence number, and message location time into the plaintext check header. The plaintext check header is not encrypted but participates in integrity verification, used to bind identity, session, window, sequence number, and time. The calculation relationship of the plaintext check header is as follows: in, Indicates plaintext check header, Indicates the vehicle end number. Indicates the session number. Indicates the window number. Indicates the message sequence number. This indicates the message location time. The message location time is the time carried in the location message itself and is used for timeliness checks; the message location time is different from the GPS data arrival time and the BeiDou data arrival time, and is not used to generate window numbers.

[0048] The vehicle-mounted terminal determines the encrypted random value based on the session number and message sequence number. This encrypted random value is used to authenticate the encryption process and ensures that it is not repeated under the same uplink encryption key. The calculation relationship for the encrypted random value is as follows: in, Indicates an encrypted random quantity. This represents a predefined deterministic derived function in the protocol. Indicates the session number. This represents the message sequence number. The encrypted random value is obtained by concatenating the 32-byte original byte string of the session number and the 8-byte unsigned network byte order encoding of the message sequence number, then inputting it into SHA-256 hash processing, and truncating the first 12 bytes of the hash output to meet the AES-256-GCM requirement for the length of the encrypted random value. Under the same uplink encryption key, message sequence numbers must not be duplicated. The vehicle IoT platform records the message sequence numbers that have been received or rejected under the same session number. If the same message sequence number reappears with a different ciphertext digest in the first packet, the corresponding first location message is rejected.

[0049] The vehicle-mounted terminal uses the uplink encryption key to perform authentication and encryption on the location message, obtaining an encrypted message and an integrity tag. The calculation relationship is as follows: in, Indicates encrypted message, Indicates integrity label, Indicates the uplink encryption key. Indicates an encrypted random quantity. Indicates a location message, This indicates a plaintext checksum header. The location message carries the first... GPS / BeiDou location data and existing business fields.

[0050] The vehicle-mounted terminal uses its private key to generate a message signature from the digests of the plaintext checksum, the encrypted message, and the integrity tag. The calculation relationship is as follows: in, Indicates message signature, This indicates the vehicle-side signature private key. Indicates plaintext check header, Indicates encrypted message, The integrity tag is used to verify that the first location message was indeed generated by the in-vehicle terminal holding the vehicle-side signing private key, and enables the vehicle IoT platform to confirm that the plaintext checksum header, encrypted message, and integrity tag have not been replaced before decryption.

[0051] The first location message includes a plaintext checksum header, an encrypted message, an integrity tag, and a message signature.

[0052] When the vehicle IoT platform receives the first location message, the first packet consistency verification unit checks the consistency of the window number, session number, message sequence number, and the waiting first packet record. The vehicle IoT platform searches for the session and the waiting first packet record based on the session number, checking whether the window number in the plaintext check header matches the window number in the waiting first packet record, whether the session number in the plaintext check header matches the session number in the waiting first packet record, and whether the message sequence number in the plaintext check header matches the message sequence number in the waiting first packet record.

[0053] After the consistency check is passed, the vehicle IoT platform verifies the message signature and integrity tag, and decrypts the encrypted message to obtain the location message. The platform's decryption unit reconstructs the plaintext check header and encrypted random variable, uses the uplink encryption key to verify the integrity tag, and decrypts the encrypted message. The decryption calculation relationship is as follows: in, Indicates a location message, Indicates authentication and decryption. Indicates the uplink encryption key. Indicates an encrypted random quantity. Indicates encrypted message, Indicates integrity label, This indicates a plaintext verification header. Only when the consistency relation, message signature, integrity tag, and decryption are all verified successfully will the vehicle IoT platform submit the location message to the location service program.

[0054] When the vehicle IoT platform submits a location message for the first time, it records the window number as already bound and saves the session number, message sequence number, and first packet ciphertext digest. The first packet ciphertext digest is obtained by hashing the plaintext checksum header, encrypted message, integrity tag, and message signature. The calculation relationship is as follows: in, This indicates the digest of the first packet of encrypted text. Indicates plaintext check header, Indicates encrypted message, Indicates integrity label, This indicates the message signature. The first packet ciphertext digest is used to distinguish between retransmissions of identical first location messages and impersonation with different first packet ciphertexts.

[0055] When the vehicle IoT platform receives a retransmission of the first location message that is identical to the one corresponding to a bound window number, it returns the original acknowledgment. An identical first location message retransmission means that the session number, window number, message sequence number, and first packet ciphertext digest are all consistent with the bound record. While waiting for the first packet record to be in a bound state, the vehicle IoT platform will no longer accept other session numbers, other message sequence numbers, or different first packet ciphertext digests corresponding to the same window number. In this case, the vehicle IoT platform returns the original acknowledgment instead of resubmitting the location message, avoiding duplicate service submissions due to link interruption or lost acknowledgment messages.

[0056] When the vehicle IoT platform recognizes a window number that corresponds to another session number, another message sequence number, or a different first packet ciphertext digest, it rejects the corresponding first location message. This rejection process ensures that a window number can only be bound to the first location message within a single session, preventing cross-session reuse, cross-first packet reuse, and impersonation with different ciphertexts.

[0057] The vehicle IoT platform uses the downlink encryption key to generate an encrypted acknowledgment message or the original acknowledgment result. The encrypted acknowledgment message includes a session number, message sequence number, and reception result. Upon receiving the encrypted acknowledgment message or the original acknowledgment result, the vehicle terminal checks if the session number and message sequence number correspond to the first location message; if they match, it marks the location message as delivered. In the event of a link interruption, the vehicle terminal only retransmits the exact same encrypted message, integrity tag, and message signature; a new message sequence number is used when re-encryption is required.

[0058] As an optional implementation, in a road scenario where the vehicle is located with a stable cellular communication link, GPS and BeiDou results enter the communication process sequentially within the same positioning cycle. GPS data arrival time, BeiDou data arrival time, positioning interval, uplink round-trip time, dual-source time difference, and remaining closed-loop time are all calculated using millisecond-level monotonic clock units. The number of available uplink bytes, security frame bytes, and remaining bytes are calculated using bytes. The dual-source time difference between GPS and BeiDou data arrival times is less than the positioning interval, and the uplink round-trip time of the most recent heartbeat or request-response completed by the communication module is also less than the remaining amount after deducting the dual-source time difference from the positioning interval; simultaneously, the number of available uplink bytes is greater than or equal to the number of security frame bytes. At this point, the remaining closed-loop time is greater than 0, the number of remaining bytes is greater than or equal to 0, and the window availability flag is in an available state. The vehicle terminal generates a window number, a window byte string, and a window digest, writes the window digest into the vehicle-side handshake signature, and writes the window number into the plaintext check header of the first positioning message. The vehicle IoT platform reconstructs the dual-source co-epoch closed-loop transmission window and registers the waiting first packet record. The first location message is decrypted after being verified through the consistency relationship to obtain the location message.

[0059] As an optional implementation, this method is used in road scenarios where the network status changes rapidly but a single request and confirmation can still be completed. Although there is a gap between the arrival times of GPS data and BeiDou data, this gap remains within the same positioning cycle. The uplink round-trip time increases due to link changes, and the number of bytes in the security frame is significantly increased due to certificate references, quantum-resistant encapsulated data, and vehicle-side handshake signatures. The onboard window generation unit 120 simultaneously checks the remaining time and number of bytes in the closed loop, allowing the key establishment process to proceed only when both the time and byte endpoints are satisfied.

[0060] As an optional implementation, a large time difference between the arrival times of GPS data and BeiDou data, or a large uplink round-trip time, may result in a closed-loop remaining time of no more than 0; alternatively, the number of security frame bytes may be greater than the number of available uplink bytes, resulting in a remaining byte count of less than 0. In any of these situations, the window availability flag is not in an available state, the vehicle terminal does not enter the current key establishment process, does not write the current window digest into the vehicle handshake signature, and does not write the current window number into the first positioning message. The vehicle terminal waits for the next positioning cycle to re-acquire the positioning message and re-executes the dual-source same-epoch closed-loop transmission window calculation, thereby avoiding including security exchange errors that cross positioning cycles or cannot meet the conditions for non-fragmented single-frame carrying in the first packet binding.

[0061] As an optional implementation, the vehicle IoT platform has already registered a waiting first packet record during the handshake phase. However, if the window number in the plaintext verification header of the first received location message does not match the window number in the waiting first packet record, or the session number in the plaintext verification header does not match the session number in the waiting first packet record, or the message sequence number in the plaintext verification header does not match the message sequence number in the waiting first packet record, the vehicle IoT platform will reject the corresponding first location message and will not execute the location message submission. Even if the encrypted message and integrity tag are formally processable, the first packet consistency verification unit will still reject the message as long as the consistency relationship fails.

[0062] As an optional implementation, if the vehicle IoT platform detects any of the following: invalid vehicle certificate, invalid vehicle handshake signature, inconsistent window digest, inconsistent window number reconstruction results, inconsistent window availability flag with remaining time and bytes, invalid message signature, or integrity tag verification or decryption failure, the vehicle IoT platform will terminate the corresponding session or reject the first location message. If multiple anomalies occur simultaneously, the vehicle IoT platform will process them in the following order: certificate verification failure, vehicle handshake signature failure, window reconstruction failure, consistency relationship failure, message signature failure, integrity tag failure, and decryption failure, with the first failure condition determining the rejection reason. When the vehicle terminal receives a failure result or does not receive an acknowledgment, it waits for the next positioning cycle to re-execute key establishment; if the link is interrupted but the first packet record is in a bound state and the first packet ciphertext digest is consistent, the vehicle terminal will only retransmit the exact same ciphertext, integrity tag, and message signature.

[0063] It should be noted that this implementation can be carried out on existing in-vehicle terminals, vehicle IoT platforms, and certificate trust services. The in-vehicle terminal may include a GPS / BeiDou positioning module, an in-vehicle processor, a memory, a cellular communication module, and a secure storage area.

[0064] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A hybrid key encapsulation and signature method for GPS-BeiDou communication in vehicle IoT, applied to an in-vehicle terminal and a vehicle IoT platform, wherein the in-vehicle terminal obtains a positioning message, characterized in that... include: The vehicle-mounted terminal records the arrival time of GPS data and BeiDou data in the same positioning cycle, and obtains the positioning interval, uplink round-trip time, number of available uplink bytes, and number of security frame bytes. The vehicle terminal determines the dual-source time difference based on the arrival time of the GPS data and the arrival time of the Beidou data, determines the remaining closed-loop time based on the positioning interval, the dual-source time difference, and the uplink round-trip time, and determines the single-frame carrying conditions based on the number of available uplink bytes and the number of security frame bytes. When the remaining time of the closed loop meets the time conditions required for one request and confirmation and the single frame carrying conditions are met, a dual-source same-epoch closed loop sending window, window number, window byte string and window summary are generated, and a local countdown is started based on the remaining time of the closed loop. The vehicle terminal writes the window summary into the vehicle handshake signature and writes the window number into the plaintext verification header of the first location message; The vehicle IoT platform verifies the vehicle-side handshake signature and reconstructs the dual-source same-epoch closed-loop transmission window, registering a waiting first packet record containing the window number, session number, and message sequence number; When the vehicle IoT platform receives the first location message, it verifies the consistency between the window number, session number, message sequence number, and the waiting first packet record, and decrypts the encrypted message to obtain the location message after the verification is successful.

2. The hybrid key encapsulation and signature method for GPS-BeiDou communication in vehicle IoT according to claim 1, characterized in that, The GPS data arrival time is the terminal's local monotonic clock value read when the GPS result is delivered to the communication process by the existing positioning program. The BeiDou data arrival time is the terminal's local monotonic clock value read when the BeiDou result is delivered to the communication process by the existing positioning program. The positioning interval is the current reporting cycle configuration of the existing positioning receiver. The uplink round-trip time is the round-trip time of the communication module's most recent completed heartbeat or request response. The number of uplink available bytes is the number of bytes of the current link's non-fragmented uplink payload. The number of security frame bytes is the actual number of bytes formed by the existing serializer in this candidate security exchange.

3. The hybrid key encapsulation and signature method for GPS-BeiDou communication in vehicle IoT according to claim 2, characterized in that, Generating the dual-source co-epoch closed-loop transmission window includes: The vehicle terminal determines the dual-source time difference based on the arrival time of the GPS data and the arrival time of the Beidou data, determines the remaining closed-loop time based on the positioning interval, the dual-source time difference, and the uplink round-trip time, determines the remaining number of bytes based on the number of available uplink bytes and the number of secure frame bytes, and sets the window availability flag to an available state when the remaining closed-loop time meets the time condition required for one request and confirmation and the remaining number of bytes meets the single-frame carrying condition.

4. The hybrid key encapsulation and signature method for GPS-BeiDou communication in vehicle IoT according to claim 3, characterized in that, The window number is obtained by hashing the vehicle terminal number, the message sequence number, the GPS data arrival time, the BeiDou data arrival time, and the positioning interval; the window byte string is obtained by serializing the GPS data arrival time, the BeiDou data arrival time, the positioning interval, the uplink round-trip time, the number of uplink available bytes, the number of security frame bytes, the dual-source time difference, the remaining closed-loop time, the number of remaining bytes, the window availability flag, and the window number in a fixed field order; the window digest is obtained by hashing the window byte string.

5. The hybrid key encapsulation and signature method for GPS-BeiDou communication in vehicle IoT according to claim 4, characterized in that, Key establishment includes: The vehicle terminal generates a vehicle-side random number and a vehicle-side temporary public key, and sends a handshake request to the vehicle IoT platform. The vehicle IoT platform returns a platform random number, a platform temporary public key, a quantum-resistant encapsulated public key, a platform certificate, and a platform handshake signature. The vehicle terminal verifies the platform certificate, the platform handshake signature, and the handshake context, generates a traditional shared key, quantum-resistant encapsulated data, and a quantum-resistant shared key, and derives and synthesizes a master key, an uplink encryption key, a downlink encryption key, and the session number from the traditional shared key, the quantum-resistant shared key, and the initial handshake digest; The vehicle IoT platform recovers the traditional shared key and the quantum-resistant shared key based on the platform's temporary private key and the quantum-resistant encapsulation data, and derives the synthesized master key, the uplink encryption key, the downlink encryption key, and the session number under the same handshake context, and uses the downlink encryption key to generate an encrypted handshake confirmation.

6. The hybrid key encapsulation and signature method for GPS-BeiDou communication in vehicle IoT according to claim 5, characterized in that, The handshake context includes at least the vehicle ID, platform ID, vehicle random number, platform random number, vehicle temporary public key, platform temporary public key, quantum-resistant encapsulation public key, quantum-resistant encapsulation data, and fixed algorithm suite identifier.

7. The hybrid key encapsulation and signature method for GPS-BeiDou communication in vehicle IoT according to claim 5, characterized in that, The vehicle terminal concatenates the initial handshake digest, the session number, and the window digest in a fixed order to obtain an acknowledgment handshake digest, and uses the vehicle terminal's signature private key to generate the vehicle terminal handshake signature from the acknowledgment handshake digest; the vehicle IoT platform verifies the vehicle terminal certificate, parses the window byte string according to the fixed field order and redetermines the number of bytes in the security frame, and registers the waiting first packet record when the window availability flag is in the available state, the window number is consistent, the window digest is consistent, and the vehicle terminal handshake signature is valid.

8. The hybrid key encapsulation and signature method for GPS-BeiDou communication in vehicle IoT according to claim 7, characterized in that, The vehicle IoT platform verifies that the number of available uplink bytes is included in the window byte string and has been bound by the vehicle-side handshake signature, and verifies that the number of available uplink bytes is consistent with the number of security frame bytes, the number of remaining bytes, and the window availability flag in the window byte string, and does not use the number of available uplink bytes as a platform-side remeasurement value.

9. The hybrid key encapsulation and signature method for GPS-BeiDou communication in vehicle IoT according to claim 8, characterized in that, Sending the first location message includes: After receiving the encrypted handshake confirmation, the vehicle terminal checks the local countdown. If the local countdown has not expired, it writes the vehicle terminal number, the session number, the window number, the message sequence number, and the message location time into the plaintext verification header. It determines the encrypted random quantity based on the session number and the message sequence number, performs authentication encryption on the location message using the uplink encryption key to obtain the encrypted message and the integrity tag, and generates a message signature by using the vehicle terminal signature private key to digest the plaintext verification header, the encrypted message, and the integrity tag. When the vehicle IoT platform verifies the consistency relationship, the message signature, the integrity tag, and the decryption and submits the location message for the first time, it records the window number as bound and saves the session number, the message sequence number, and the first packet ciphertext digest obtained by hashing the plaintext check header, the encrypted message, the integrity tag, and the message signature. When the vehicle IoT platform receives a retransmission of the first location message that is exactly the same as the bound window number, it returns the original confirmation result. When the same window number corresponds to other session numbers, other message sequence numbers, or different first packet ciphertext digests, it rejects the corresponding first location message.

10. A hybrid key encapsulation and signature system for GPS-BeiDou communication in vehicle Internet of Things (IoT), characterized in that, This includes an in-vehicle terminal, a vehicle IoT platform, and a certificate trust service; the certificate trust service is used to issue digital certificates to the in-vehicle terminal and the vehicle IoT platform; the in-vehicle terminal includes an in-vehicle window generation unit, an in-vehicle key establishment unit, an in-vehicle signature unit, and a first-packet encrypted transmission unit; the in-vehicle window generation unit is used to generate a dual-source same-epoch closed-loop transmission window, a window number, a window byte string, and a window digest; the in-vehicle key establishment unit is used to generate a traditional shared key, quantum-resistant encapsulated data, a quantum-resistant shared key, an uplink encryption key, and a downlink encryption key; the in-vehicle signature unit is used to write the window digest into the in-vehicle handshake signature; and the first-packet encrypted transmission unit is used to generate the first location message; the vehicle IoT platform... The network platform includes a platform key recovery unit, a platform signature verification unit, a platform window reconstruction unit, a first packet waiting record unit, a first packet consistency verification unit, and a platform decryption unit. The platform key recovery unit is used to recover the traditional shared key and the quantum-resistant shared key and generate the uplink encryption key and the downlink encryption key. The platform signature verification unit is used to verify the vehicle-side handshake signature and message signature. The platform window reconstruction unit is used to reconstruct the dual-source same-epoch closed-loop transmission window. The first packet waiting record unit is used to register the first packet waiting record. The first packet consistency verification unit is used to verify the consistency relationship between the window number, session number, message sequence number, and the first packet waiting record. The platform decryption unit is used to decrypt the encrypted message to obtain the location message.

Images