Position information end cloud trusted transmission method

Abstract

The invention discloses a position information end cloud trusted transmission method, which comprises the following steps of: 1) a chip terminal equipment initialization flow, namely initialization is a basis for establishing trust between a terminal and a positioning chip server, and binding of an equipment identifier and a secret key is completed; 2) the terminal and the positioning chip server negotiate a session key to obtain a session key K; and 3) carrying out a position information encryption transmission process based on the session key K. Aiming at the problems that in a Beidou satellite-terminal-cloud scene, a resource-limited terminal is difficult to bear a traditional security protocol, position transmission is easily attacked, and key certificate management is missing, a three-level closed-loop architecture is constructed, a terminal integrated hardware cryptographic module realizes SM2 / SM3 / SM4 operation, a server optimizes communication based on WireGuard, and the service life of the server is prolonged. The confidentiality and integrity of data are guaranteed through the processes of initialization, key negotiation, encrypted transmission, dual-threshold key updating and certificate updating.

Description

Technical Field

[0001] This invention relates to the intersection of BeiDou navigation technology and information security transmission, specifically targeting the three-level application scenario of BeiDou navigation "satellite-terminal-cloud". It provides a reliable method for location information transmission between the terminal and the cloud, which is applicable to resource-constrained consumer terminals such as wearable devices (such as smart bracelets), mobile terminals (such as mobile phones), and embedded devices (such as vehicle terminals). It aims to ensure the confidentiality, integrity, and authenticity of location data during the transmission process from the terminal to the cloud, while adapting to the hardware constraints of low power consumption, low computing power, and small storage of the terminal. Background Technology

[0002] As my country's independently developed and controllable global satellite navigation system, the BeiDou Navigation Satellite System has been widely used in transportation, logistics, and personal positioning. In its three-tiered "satellite-terminal-cloud" architecture, the transmission of location information between the terminal and the cloud is the core component. However, this component currently faces the following key technological challenges.

[0003] 1) Incompatibility between terminal resource constraints and security protocols: Consumer terminals are limited by hardware specifications (usually power consumption ≤15mW, computing power ≤500MHz, storage ≤1MB), which cannot support the complete process of traditional "heavyweight" security protocols such as SSL / TLS, resulting in a conflict between security protection and terminal performance requirements.

[0004] 2) Significant security risks in communication links: The terminal transmits data with the cloud through wireless links such as NB-IoT and BLE. The link is completely exposed and vulnerable to eavesdropping, tampering, man-in-the-middle attacks and replay attacks, which may lead to the leakage or forgery of location data.

[0005] 3) Lack of key and certificate management mechanisms: Most existing solutions do not achieve full lifecycle management of keys, have insufficient security in private key storage, and lack a rapid update mechanism after certificate expiration or leakage. Long-term use of fixed keys or certificates can easily lead to security risks.

[0006] 4) Insufficient resistance to attacks: There is a lack of lightweight protection against common risks such as DoS attacks and data tampering. If complex verification logic is used directly, it will further increase the consumption of terminal resources.

[0007] Furthermore, the signal link between BeiDou satellites and terminals may be susceptible to spoofing attacks. However, this risk relies on the anti-interference module of the terminal chip (such as an anti-retransmission interference circuit), which is a different dimension of protection from "terminal-cloud" transmission security. Existing solutions often blur the boundaries between the two, resulting in unclear core protection priorities. Therefore, there is an urgent need for a location information terminal-to-cloud transmission solution that balances lightweight characteristics with high security to address the aforementioned technical issues. Summary of the Invention

[0008] In view of the problems existing in the prior art, the purpose of this invention is to provide a reliable method for location information transmission between the cloud and the terminal.

[0009] This solution addresses the three-tiered application scenario of BeiDou navigation, namely "satellite-terminal-cloud," and constructs a closed-loop trusted transmission architecture, which includes the following entities.

[0010] Beidou navigation satellites: Located at the top level of the architecture, they broadcast navigation signals (including carrier waves, pseudocodes, and ephemeris data) to ground terminals (wearable devices, mobile terminals, and embedded devices) via L-band radio links, providing the terminals with raw positioning reference information. The signal coverage is limited by the satellite's orbital altitude (approximately 20,000 kilometers) and the terminal's receiving sensitivity (≥-157dBm).

[0011] Chip-based terminal devices: As the core of the middle layer, they integrate dedicated BeiDou navigation chips. They receive satellite signals via an RF module and calculate location data (latitude, longitude, altitude, timestamp, etc.). The data is then encrypted at the source level using a hardware encryption module, and finally transmitted to the cloud via a low-power wireless network (such as NB-IoT or BLE). Terminal types include wearable devices (smart bracelets), mobile terminals (phones), and embedded devices (vehicle terminals), serving as a secure hub connecting satellites and the cloud.

[0012] 3) Positioning Chip Server: Located at the bottom layer of the architecture and deployed in a cloud data center, it receives encrypted data from the terminal through a high-performance network interface, decrypts and verifies it, and stores it in an encrypted database. It also provides application services such as location trajectory analysis and geofencing alerts. The server and terminal communicate based on the WireGuard protocol framework, supporting large-scale concurrent access and ensuring real-time response in mobile scenarios. A new "selective retransmission mechanism" is added to mitigate data incompleteness issues caused by UDP packet loss.

[0013] Given the unique application scenarios of the BeiDou Navigation Satellite System, the following security assumptions are made for this solution: Chip hardware security: The hardware security module (HSM) of the dedicated Beidou navigation chip has physical anti-tampering characteristics, which can resist side-channel attacks (such as power consumption analysis, electromagnetic analysis) and reverse engineering. The private key storage area (fuse array) cannot be accessed or modified by external programs. The random number generator adopts a multi-source fusion mechanism (thermal noise + Beidou signal Doppler frequency offset + temperature sensor data) to generate 128-bit true random numbers with an entropy value ≥128 bits, passing the NIST SP 800-22 randomness test. Communication link risks: The wireless communication link between the terminal and the server is completely exposed, which poses risks such as eavesdropping (acquiring transmitted data), tampering (modifying data content), man-in-the-middle attacks (replacing the identity of the communicating party), and replay attacks (repeatedly sending historical data); Terminal environment risks: Terminal devices may be physically lost or infected with malware, leading to operating system hijacking and the risk of original location data being tampered with and encryption modules being bypassed. Terminals are limited by power consumption (≤15mW), computing power (500MHz processor), and storage (≤1MB on-chip memory), making them unable to support traditional heavy-weight security protocols (such as the complete SSL / TLS process). Trusted Cloud Infrastructure: The positioning chip server is maintained by a trusted operator and has physical security protection (such as data center access control and video surveillance) and system security hardening (such as intrusion detection and encrypted data storage), which can resist remote penetration attacks; the server key management system complies with relevant national cryptography management standards and supports full lifecycle management of keys (generation, storage, update, and destruction). The private key is stored in the hardware security module (HSM) and cannot be exported.

[0014] 1. Chip-based terminal equipment, using resource-constrained mass-market consumer terminals as its carrier, with a core component being a dedicated BeiDou navigation and positioning chip, mainly includes the following modules.

[0015] 1) Cryptographic module (hardware level) SM2 Algorithm Unit: Adopts a pipelined architecture design, supports public-private key pair generation (256 bits), key negotiation (based on elliptic curve Diffie-Hellman), digital signature and verification (ASN.1 encoding), with a signature rate of ≥500 times / second, ensuring efficient identity authentication.

[0016] SM3 Algorithm Unit: Implements cryptographic hash operation (256-bit hash value), supports message authentication code (HMAC-SM3) generation, operation latency ≤1μs / 1024 bytes, used for data integrity verification.

[0017] SM4 Algorithm Unit: Adopts CBC working mode, 128-bit key symmetric encryption and decryption, encryption and decryption rate ≥1666.67Mbps; the initialization vector (IV) is 128 bits, generated by concatenating "64-bit random number + 64-bit timestamp" to avoid IV duplication.

[0018] Random number unit: Based on the chip thermal noise source design, it outputs 128-bit true random numbers, which pass the NIST SP 800-22 randomness test, providing the basis for key generation, IV and anti-replay random numbers.

[0019] Key management unit: adopts a hierarchical storage architecture. The device fixed private key (PrvD) is stored in a fuse array (non-exportable), and the session key (K) is stored in volatile secure memory (lost when power is off). It supports key lifecycle management (generation, update, and destruction).

[0020] 2) Communication module (hardware and software collaboration) Beidou signal processing unit: includes radio frequency front-end (supports B1I / B2I dual frequency), baseband processor (acquisition sensitivity ≤-148dBm), calculates position data and outputs NMEA protocol frames (such as $GNRMC), with a calculation delay ≤1 second.

[0021] Network communication unit: integrates NB-IoT RF chip (transmit power ≤23dBm), supports UDP + selective retransmission mechanism, communication rate ≥250kbps, and packet loss retransmission ≤3 times.

[0022] Protocol processing unit: Runs a lightweight security protocol stack, which encapsulates the process logic such as initialization, key negotiation, and data transmission, with a code size of ≤32KB (reducing memory usage).

[0023] Data buffer unit: 1KB capacity FIFO buffer, temporarily stores location data (NMEA frames) to be encrypted and server response messages to avoid data overflow.

[0024] 3) Hardware parameters Clock speed: 500MHz (low-power ARM Cortex-M4 core); Power consumption: ≤15mW in dual-frequency mode (receiving satellite signals + encryption operation); Size: ≤10mm² (BGA package, 64 pins).

[0025] 2. Positioning the chip server as a core node in the cloud, the software architecture mainly includes the following modules.

[0026] Communication interface module: A high-performance server based on the WireGuard protocol, supporting ≥300,000 concurrent connections, adopting an IO multiplexing (epoll) mechanism, with network access latency ≤20ms; a new "dynamic frequency limiting" function is added to limit message frequency according to terminal type (e.g., ≤20 frames / second for vehicle terminals, ≤5 frames / second for wearable devices).

[0027] 2) Identity Authentication and Key Management Module: Stores the binding relationship between terminal identifier (DID), chip serial number and terminal public key, supports fast query based on DID (response time ≤1ms); manages server public and private key pairs and certificate chain, and supports dynamic updates of root certificate hash list.

[0028] 3) Data decryption and verification module: Decrypt terminal ciphertext with session key (K) (SM4-CBC mode), verify data integrity through SM3 hash check (compare HDTDi with locally calculated value), and discard tampered data (processing latency ≤5ms / frame).

[0029] 4) Data storage and processing module: The decrypted location data is stored in an encrypted database (AES-256 encryption), supports indexing by terminal DID and timestamp, and provides API interfaces such as trajectory query (accuracy ≤ 1 meter) and fence alarm (response time ≤ 100ms).

[0030] 5) Certificate Management Module: Regularly (daily) checks the validity period of server certificates. When the remaining validity period is ≤30 days, the renewal process is automatically triggered. The new certificate is issued by a CA institution recognized by the State Cryptography Administration.

[0031] 6) Hardware Configuration Processor: 16-core Intel Xeon Gold 6330 (2.0GHz); Memory: 64GB DDR4 (ECC verified); Storage: 2TB SSD (read / write speed ≥1GB / s); Operating system: Security hardened Linux (disable unnecessary ports and enable SELinux).

[0032] The key process design is as follows.

[0033] 1. Chip-based terminal device initialization process Initialization is fundamental for establishing trust between the terminal and the server. Device identification and key binding are completed in five steps, as follows: Figure 1 As shown.

[0034] (1) Initialization request initiation (chip → server): After the Beidou navigation and positioning chip on the terminal is powered on, the random number unit generates a 128-bit random number R0 and sends a request message through the network communication unit: {Type: Init_Request, Device_Random: R0, Chip_Model: BD-2023}, where Chip_Model identifies the chip model (used by the server to adapt to different terminal types).

[0035] (2) Server certificate chain distribution (server → chip): After receiving the chip, the chip server generates a certificate chain Cert_Chain (root certificate Root_Cert + server certificate Server_Cert) containing its own public key PubS, calculates the certificate chain hash value H_Cert=SM3 (Cert_Chain), appends the server random number S_Random (128 bits), and sends a response message: {Type: Cert_Response, Cert_Chain: [Root_Cert, Server_Cert], PubS, S_Random, H_Cert}.

[0036] (3) Chip verification certificate chain The chip verifies the following via a hardware cryptographic module: root certificate self-signature verification (the root certificate public key is pre-installed in the chip fuse); server certificate signature verification (the signature is decrypted using the root certificate public key and compared with the certificate hash); H_Cert'=SM3(Cert_Chain) is calculated, and the result is verified to match the received H_Cert (to prevent certificate tampering). Verification fails, and the chip is retried (maximum 3 times). If verification fails again, the chip is locked (requires unlocking by the manufacturer).

[0037] (4) Encrypted upload of chip identification information The chip generates a fixed SM2 key pair (PrvD, PubD). PrvD is stored in the hardware security module HSM of the dedicated Beidou navigation chip, and PubD is transmitted in plaintext to the positioning chip server. The chip's unique serial number SerialNumber is encrypted with PubS to obtain the encrypted value CDI=SM2_Encrypt (PubS, SerialNumber). SerialNumber is signed with PrvD to obtain the signature value SDI=SM2_Sign (PrvD, SerialNumber). Initialization data is sent: {Type: Init_Data, CDI, PubD, Random: R1, SDI, Counter parameter: 0}, where R1 is a newly generated 128-bit random number (different from R0, to prevent replay).

[0038] (5) The server generates a DID and responds. The server uses PrvS to decrypt the CDI to obtain the SerialNumber, and uses PubD to verify the validity of the SDI; it generates a 128-bit random number r, and uses the SM3 algorithm to hash the random number r and the decrypted SerialNumber to obtain the device identifier DID=SM3(SerialNumber||r), and stores it as {DID: [SerialNumber, PubD]}; it encrypts the DID with PubD to obtain CSI=SM2_Encrypt(PubD, DID), and signs the DID with PrvS to obtain SSI=SM2_Sign(PrvS,DID); it sends a response message: {Type: Init_Response, CSI, SSI, Random: R1, Server_Timestamp: T0}.

[0039] (6) Chip verification and initialization completed The chip uses PrvD to decrypt the CSI to obtain the DID, and uses PubS to verify the validity of the SSI; it calculates Ack=SM3 (DID||R1||T0) and sends: {Type: Init_Finish, Ack, Device_Timestamp: T1}; the server verifies the Ack (to ensure that the DID is received correctly), stores {T1: [DID, PubD]}, and the initialization is complete.

[0040] 2. Location Encryption Key Negotiation Process After initialization, the terminal and server negotiate the session key through a three-round handshake, as follows: Figure 2 As shown.

[0041] (1) DeviceHello message (chip → server) The chip generates a temporary SM2 key pair (x, Rx) and a random number Ran (128 bits), where x is the chip's temporary private key and Rx is the chip's temporary public key; calculate H1=SM3 (DID||Rx||PubS||Ran), and sign it with PrvD to get CDTN=SM2_Sign (PrvD, H1); send: {Type: Device_Hello, DID, Rx, PubS, Ran, CDTN, Counter:1}.

[0042] (2) ServerHello message (server → chip) Server verification: Check if PubS is its own public key (to prevent man-in-the-middle substitution); verify CDTN with PubD (confirm chip identity); generate a temporary SM2 key pair (y, Ry), a random secret HS (256 bits), and update the random number r, where y is the server's temporary private key and Ry is the server's temporary public key; calculate DID*=SM3(DID||r) (dynamically update device identifier), CSTN1=SM2_Encrypt(PubD, DID*); calculate HSTN=SM3(Ry||HS||Ran), and sign with PrvS to obtain CSTN2=SM2_Sign(PrvS, HSTN); send: {Type: Server_Hello, Ry, CSTN1, HSTN, CSTN2,Ran, Counter: 2}.

[0043] (3) Finish message (chip → server) The chip uses PrvD to decrypt CSTN1 to obtain DID*, and updates the local DID to DID*; it uses PubS to verify CSTN2 (confirming HS integrity), calculates the shared key Z=SM2_KeyAgree (PrvD, Ry); derives the session key K=SM3-KDF (Z||HS||DID*, 128) (KDF is the key derivation function); calculates FTN=SM3 (K||Rx||Ry||DID*), and sends a completion message: {Type: Finish, FTN, Counter: 3}; the server calculates Z=SM2_KeyAgree(PrvS, Rx) and K=SM3-KDF (Z||HS||DID*, 128), and verifies that if the FTNs calculated by both parties are consistent, the key negotiation is complete; the chip actively submits the generated FTN to the server, and the server replicates the same calculation and compares and verifies it.

[0044] 3. Location information encrypted transmission process After key negotiation, the terminal encrypts and transmits location data in real time, as follows: Figure 3 As shown.

[0045] (1) Location data acquisition and preprocessing The BeiDou signal processing unit outputs location data Mi: Mi = {Lat: 39.9087°N, Lon: 116.3975°E, Alt: 50m, Time: 2025-08-20T12:00:00Z, Accuracy: 3m}; the chip performs format verification on Mi (e.g., latitude range [-90, 90]), and discards the data if the verification fails.

[0046] (2) Encryption and Hash Calculation Generate a 64-bit random number Rani, and calculate Mi' = Mi XOR Rani (to increase randomness), where XOR is the exclusive OR operation; encrypt it with the session key K to obtain CDTDi = SM4_Encrypt (K, Mi', IV=Rani) (IV=Rani, reducing storage); calculate HDTDi = SM3 (CDTDi||Rani||DID*||Counter) (Counter increments to prevent replay attacks); send: {Type:Data, CDTDi, Rani, HDTDi, Counter: N, Timestamp: T}. N is the current value of the counter parameter Counter, which increments by one with each message sent to prevent replay attacks.

[0047] (3) Server decryption and verification Check if Counter is incremented (discard if it is ≤ the previous one); calculate HDTDi'=SM3 (CDTDi||Rani||DID*||Counter), and verify that it matches the received HDTDi; decrypt with K to get Mi'=SM4_Decrypt (K,CDTDi, IV=Rani), and calculate Mi=Mi' XOR Rani; store Mi in the encrypted database (indexed by DID*+Timestamp), where SM4_Decrypt is the national standard SM4 block cipher decryption algorithm.

[0048] 4. Key Timed Update Process To avoid using the same key for an extended period, a dual-threshold triggering update mechanism is employed, as follows: Figure 4 As shown.

[0049] (1) Update trigger conditions Chip maintenance: Timer (starts timing from key negotiation); Counter (counts data messages). An update is triggered when Timer ≥ 30 minutes or Counter ≥ 1000 frames.

[0050] (2) ReKey message sending The chip changes the type of the next Data message to ReKey and adds an update flag: {Type: ReKey,CDTDi, Rani, HDTDi, Counter: N, ReKey_Flag: 1}.

[0051] (3) Server response and new key generation After verifying the message's legitimacy, the server generates a new secret message HS* (256 bits) and a random number r*; calculates DID** = SM3(DID*||r*), and sends a renegotiation key reply message: {Type: ReplyReK, HS*, r*, R_new: 128-bit random number, Sign: SM2_Sign(PrvS, HS*||r*)}. SM2_Sign is the SM2 elliptic curve public key cryptography signature algorithm.

[0052] (4) New key derivation and switching The chip terminal uses the server's public key PubS to verify the validity of the digital signature Sign attached to the ReplyReK message by the server, calculating H=SM3 (HS*||R_new) to verify the integrity of HS*; both parties generate new temporary key pairs (x*, Rx*) and (y*, Ry*), and calculate the shared key Z*=SM2_KeyAgree (PrvD, Ry*); derive a new session key K*=SM3-KDF (Z*||HS*||DID**, 128); synchronously switch to K* as the updated session key K, and reset Timer=0 and Counter=1 on the chip to complete the update. SM2_KeyAgree is the SM2 elliptic curve public key cryptography key negotiation algorithm, and SM3-KDF is a key derivation function based on the SM3 hash algorithm.

[0053] 5. Certificate Renewal Process (Unscheduled) When a server certificate expires or is compromised, it should be renewed using the following procedure: Figure 5 As shown.

[0054] (1) Certificate expiration detection: The server checks the certificate validity period daily. If the remaining period is ≤30 days or the private key is leaked, a new key pair (PrvS*, PubS*) and a new certificate chain (signed by the root certificate) are generated.

[0055] (2) Certificate update message sending: When the chip initiates a new key negotiation (DeviceHello), the server attaches a regenerated certificate message to ServerHello: {Type: ReCertificate, New_Cert_Chain:[Root_Cert, New_Server_Cert], PubS*, SSC=SM2_Sign(PrvS*, New_Cert_Chain)}.

[0056] (3) Chip verification and update: Verify the new certificate chain (same as the initialization phase); verify the SSC with the old PubS (confirm the server identity); update the local PubS to PubS*, mark the old certificate as invalid, and send a certificate update confirmation message: {Type:Cert_Update_Ack, Ack=SM3(PubS*||Timestamp)}.

[0057] (4) Communication recovery: The server uses PrvS to participate in subsequent key negotiation, and the chip uses PubS for verification. The process is the same as the location encryption key negotiation process, which does not affect real-time transmission (additional overhead ≤ 1ms / time).

[0058] The advantages of this invention are as follows: 1) Comprehensive security protection: SM2 two-way signature verification prevents man-in-the-middle attacks, SM4 symmetric encryption + SM3 hash verification ensures the security of location data from source to transmission to storage; "incrementing counter + timestamp + independent random number" prevents replay attacks, dual thresholds (30 minutes / 1000 frames) trigger key updates to ensure forward security, while resisting side-channel and DoS risks; private keys are stored in an HSM fuse array to prevent leakage. 2) Lightweight adaptation for resource-constrained terminals: Lightweight national cryptographic algorithms are selected (SM4 encryption time 0.5ms, SM3 latency ≤1μs / 1024 bytes), protocol stack code ≤32KB; simplified process of key negotiation 1-RTT and update 0-RTT, terminal storage of key information ≤512KB, in line with the resource constraints of terminal power consumption ≤15mW and computing power 500MHz; 3) High performance and high concurrency: Based on WireGuard, it supports ≥300,000 concurrent terminal connections with network access latency ≤20ms; high-frequency data transmission only performs lightweight SM4 / SM3 operations, and the total cloud storage for 300,000 users is ≤10GB, which is suitable for large-scale Beidou terminal deployment. 4) High transmission reliability: The terminal has a 1KB FIFO buffer to prevent data overflow, and WireGuard adds selective retransmission (≤3 times) to resist UDP packet loss; the Beidou dual-frequency calculation latency is ≤1 second, the cloud trajectory query accuracy is ≤1 meter, and the fence alarm response is ≤100ms, ensuring timely and accurate data. 5) Easy to maintain and manage: The server automatically checks the certificate validity period (renewal triggered after ≤30 days), and supports full lifecycle management of keys; message frequency is limited according to terminal type (e.g., ≤20 frames / second for vehicle-mounted devices), and terminal status (Counter / Timer) is synchronized in real time, simplifying operation and maintenance. Attached Figure Description

[0059] Figure 1 The flowchart for initializing the chip terminal device is presented in a sequential interactive format, showing the six-step process of "request initiation - certificate chain issuance - certificate verification - identification information upload - DID response generation - initialization confirmation", with annotations of the message structure and key operations for each step.

[0060] Figure 2 The flowchart for location encryption key negotiation shows the "DeviceHello-ServerHello-Finish" three-round handshake, and marks the logic for temporary key generation, shared key calculation, and session key derivation.

[0061] Figure 3 This flowchart illustrates the process of encrypted transmission of location information, showing the complete workflow from terminal data acquisition and preprocessing, encryption hash calculation, to server verification, decryption, and storage, and annotates the data format and algorithm application.

[0062] Figure 4 Create a flowchart for the key timed update process, annotating the dual threshold trigger conditions, ReKey message interaction, and the new key generation and switching process.

[0063] Figure 5 The flowchart for the irregular certificate update process demonstrates the interaction logic of certificate expiration detection, new certificate chain generation, and update confirmation, and highlights key verification steps. Detailed Implementation

[0064] The present invention will now be described in further detail with reference to the accompanying drawings. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0065] This implementation method uses a smart bracelet with a dedicated BeiDou navigation chip (a representative of consumer-grade resource-constrained terminals) and a cloud-based positioning chip server as the implementation carriers. Based on the aforementioned system architecture, solution design, and key process logic, it achieves reliable end-to-cloud transmission of BeiDou navigation location information through a three-layer implementation of "environment setup - process implementation - effect verification". The specific details are as follows.

[0066] 1. Hardware environment setup 1) Chip-based terminal devices (smart bracelets) The selected smart bracelet is model BD-Watch-2023, whose core Beidou navigation chip fully matches the aforementioned hardware parameters: it features a 500MHz low-power ARM Cortex-M4 core, with power consumption controlled at 12mW (≤15mW) in dual-frequency (B1I / B2I) mode; it uses a 64-pin BGA package with a size of only 8mm² (≤10mm²); it has a built-in 1KB FIFO data buffer unit and a hardware security module (HSM), which includes a fuse array (for storing the device's fixed private key PrvD) and anti-side-channel attack circuitry, resisting attacks such as power consumption analysis and electromagnetic analysis; its Beidou signal receiving sensitivity reaches -150dBm (≤-148dBm), and its location data processing latency is 0.8 seconds (≤1 second); it integrates an NB-IoT RF chip with a transmit power of 21dBm (≤23dBm), a communication rate of 280kbps (≥250kbps), supports UDP + selective retransmission mechanism, and sets the number of packet loss retransmissions to 3. Next, it adapts to the needs of low-power long-distance data transmission.

[0067] 2) Positioning chip server Deployed in an Alibaba Cloud data center, the hardware configuration includes a 16-core Intel Xeon Gold 6330 processor (2.0GHz), 64GB of DDR4 ECC-verified memory (to reduce data transmission error rates), and a 2TB SSD storage device (read / write speed 1.2GB / s, ≥1GB / s). It runs a security-hardened Linux system (CentOS 8 version), disabling unnecessary ports such as FTP and Telnet, and enabling SELinux mandatory access control mode to prevent unauthorized access. It integrates a national cryptographic SM4 encryption card (hardware security module HSM) to store the server's private key PrvS and session key K, supporting full lifecycle management of key generation, storage, update, and destruction; the private key cannot be exported. The network interface uses an I / O multiplexing (epoll) mechanism with a dynamic frequency limiting policy—5 frames per second for smart bracelets (wearable devices), and a reserved 20 frames per second extension for vehicle terminals, ensuring that concurrent connections support more than 300,000 terminal accesses.

[0068] 2. Software Environment Deployment 1) Terminal software A lightweight security protocol stack is embedded in the smart bracelet chip, with a code size of 28KB (≤32KB) and an on-chip memory constraint of ≤1MB for compatible terminals; the protocol stack includes three core modules.

[0069] BeiDou signal processing module: Outputs NMEA protocol $GNRMC frames, containing location data such as latitude and longitude, altitude, timestamp, and positioning accuracy.

[0070] National Cryptographic Algorithm Calling Module: Interacts with the hardware cryptographic module to implement hardware-level operations of SM2 / SM3 / SM4 algorithms. The SM2 signature rate is 550 times / second (≥500 times / second), the SM3 operation latency is 0.8μs / 1024 bytes (≤1μs / 1024 bytes), and the SM4 encryption / decryption rate is 1800Mbps (≥1666.67Mbps).

[0071] NB-IoT data transmission module: encapsulates the message formats of the key processes (such as initialization requests, DeviceHello, Data messages, etc.) to ensure communication compatibility with the server.

[0072] Meanwhile, the root certificate issued by the State Cryptography Administration is pre-installed in the chip fuse array for use in the initialization phase to verify the legitimacy of the server certificate chain.

[0073] 2) Server software A high-performance communication service is developed based on the WireGuard protocol, integrating a national cryptographic algorithm library (compliant with GB / T 32905-2016 and GB / T 32907-2016 standards) to achieve logical processing of key processes; a MySQL 8.0 encrypted database is deployed, using the AES-256 algorithm to encrypt and store location data, supporting joint indexing by terminal DID (device identifier) ​​and timestamp, with a trajectory query accuracy of 0.8 meters (≤1 meter) and a geofence alarm response time of 80ms (≤100ms); a certificate management module is configured to automatically check the server certificate validity period at 0:00 every day, triggering an update process when the remaining validity period is ≤30 days, with the new certificate issued by a CA institution recognized by the State Cryptography Administration, matching certificate management requirements.

[0074] In this implementation, the core interaction process between the chip terminal and the server strictly follows the design logic, with only minor adaptation adjustments made for actual hardware performance and network environment. There is no need to modify the core mechanism. The specific implementation points are as follows.

[0075] 1. Chip terminal initialization Considering that it takes 2-3 seconds for the smart bracelet to attach to the NB-IoT network after power-on, a "network status detection" step is added before the initialization request is initiated. Once the network is detected to be ready, R0 is generated and the request is sent to avoid message loss due to network failure. The retry mechanism retains the "maximum 3 times" logic, with each retry interval set to 5 seconds to balance retry efficiency and power consumption.

[0076] Initialization took an average of 12 seconds (including network attachment time), the certificate chain verification pass rate was 100%, and the chip locking mechanism was triggered normally after 3 failed retries, requiring the manufacturer's dedicated tool to unlock, which meets the trust establishment target.

[0077] 2. Location encryption key negotiation Since the generation of the temporary SM2 key pair for the smart bracelet takes 1.2ms (theoretical value 1ms), a "key generation complete flag" is added before the DeviceHello message is sent to ensure that the message is encapsulated after Rx is generated, thus avoiding incomplete temporary public keys. When the server generates the HS (256-bit), a hardware encryption card is used to accelerate the generation, reducing the generation time from 8ms generated by software to 1.5ms, thereby improving negotiation efficiency.

[0078] The three-round handshake takes an average of 80ms (1-RTT), which is 60% less latency than the traditional TLS protocol (2-RTT, 200ms), meeting the requirements for communication cost optimization. The session key K is derived and stored in the terminal's volatile secure memory, which is automatically destroyed after power failure, ensuring security.

[0079] 3. Encrypted transmission of location information Considering that the smart bracelet collects location data every 30 seconds (the typical sampling frequency for wearable devices), and the Counter increment speed is relatively slow, the "Counter anti-replay" and "timestamp anti-replay" are combined—the effective window for the timestamp is set to 60 seconds, and messages exceeding the window are discarded even if the Counter increments, avoiding the risk of replay attacks due to long sampling intervals; when SM4 encryption is used, the IV (Rani) is generated by concatenating "64-bit random number + 64-bit timestamp", with the timestamp accurate to milliseconds, ensuring that the IV is not repeated.

[0080] The encryption time for a single frame location data is 0.4ms (≤0.5ms), the server decryption and hash verification time is 4ms (≤5ms / frame), and the data transmission success rate is 99.8% (packet loss is caused by fluctuations in the NB-IoT network and is compensated through selective retransmission mechanism), which meets the requirements of confidentiality and integrity.

[0081] 4. Key updates on a regular schedule In daily use, smart bracelets have a low location data sampling frequency (30 seconds / time). It would take about 8.3 hours for the Counter to reach 1000 frames, which is far beyond the "30 minutes" time threshold. Therefore, "Timer ≥ 30 minutes" is the primary trigger condition, and "Counter ≥ 1000 frames" is the backup condition to avoid the key not being updated for a long time due to the low sampling frequency. The ReKey message and Data message reuse the frame structure, only modifying the Type field, and the additional communication volume is negligible.

[0082] The key update takes an average of 95ms (including the time for new K derivation). The current data transmission is not interrupted during the update process. After the new K is switched, the encrypted data can be decrypted normally, the forward security meets the standard, and the key freshness requirement is met.

[0083] 5. Certificates are updated periodically. After the new certificate chain is generated on the server, the root certificate (pre-stored in the fuse array) does not need to be downloaded again when the terminal verifies the new certificate chain through the "root certificate hash pre-store" mechanism, and the verification time is reduced from 15ms to 5ms; after the old PubS expires, the terminal is marked as "unavailable" and rejects subsequent messages that use the old PubS for verification, thus avoiding certificate mixing.

[0084] Certificate updates incur an additional overhead of 0.8ms per update (≤1ms per update), which does not affect real-time location data transmission. After the update, the server uses PrvS for negotiation, and the terminal uses PubS for verification. The communication recovery success rate is 100%, which meets the dynamic security adjustment target.

[0085] The implementation effect was verified as follows: A test environment was set up with 1,000 smart bracelets (simulated terminals) and 1 positioning chip server, and the system was run continuously for 72 hours to verify the performance and security of the solution. The results are as follows.

[0086] 1. Performance indicator verification 2. Security Verification 1) Man-in-the-middle attack defense: Simulates an attacker forging the server's public key to replace PubS. The terminal verifies the forgery through the certificate chain (pre-stored root certificate), discards the message, and triggers an alarm, achieving a 100% defense success rate; 2) Replay attack defense: Repeatedly sending historical Data messages (Counter=100, timestamp expired), the server checks by incrementing Counter and verifies by timestamp window, and discards 100% of the replay data; 3) Tampering attack prevention: After modifying the CDTDi field and sending it, the server detects the inconsistency through SM3 hash verification and discards the tampered data, achieving a 100% success rate in preventing tampering attacks. 4) DoS attack mitigation: 100,000 invalid Data messages were sent to the server. The server processed only 200 valid messages through a "hash verification first, then decryption" mechanism. The CPU utilization remained below 40%, and no resource exhaustion occurred, which met the security assumption protection objectives.

[0087] 3. Stability Verification During 72 hours of continuous operation, none of the 1,000 terminals crashed or had key leaks. The location data storage accuracy rate was 99.8% (2% of errors were caused by temporary power outages at the terminals, which were retransmitted through key negotiation after restarting). The server had no disconnections or data loss. The overall stability met the long-term operation requirements of the BeiDou navigation "terminal-cloud" transmission scenario.

[0088] Although specific embodiments of the invention have been disclosed for illustrative purposes to aid in understanding and implementing the invention, those skilled in the art will understand that various substitutions, variations, and modifications are possible without departing from the spirit and scope of the invention and the appended claims. Therefore, the invention should not be limited to the content disclosed in the preferred embodiments, and the scope of protection claimed by the invention is defined by the claims.

Claims

1. A method for trusted transmission of location information between the cloud and the terminal, comprising the following steps: 1) Perform steps 11) to 16) to complete the terminal device initialization process. 11) The Beidou navigation and positioning chip on the terminal sends a request message to the positioning chip server; the request message includes a random number R0 and a chip model identifier Chip_Model; 12) After receiving the initialization request message, the positioning chip server generates a certificate chain Cert_Chain containing its own public key PubS and a random number S_Random, and calculates the certificate chain hash value H_Cert; and sends response information (Cert_Chain, PubS, S_Random, H_Cert) to the terminal. 13) The Beidou navigation and positioning chip verifies the certificate chain in the response message. If the verification is successful, proceed to step 14); otherwise, lock the Beidou navigation and positioning chip. 14) The Beidou navigation and positioning chip generates the public and private keys (PrvD, PubD) of the terminal device; the private key PrvD is stored in the hardware security module HSM of the Beidou navigation chip, and the public key PubD is transmitted to the positioning chip server; the unique serial number SerialNumber of the Beidou navigation and positioning chip is encrypted using PubS to obtain the encrypted value CDI, and SerialNumber is signed using PrvD to obtain the signature value SDI; then the initialization data {CDI, PubD, R1, SDI, Counter} is sent to the positioning chip server; where R1 is a newly generated random number, and Counter is an incrementing counting parameter; 15) The positioning chip server decrypts the CDI using PrvS to obtain the SerialNumber, and verifies the legality of the SDI using PubD. After successful verification, a random number r is generated, and then the device identifier DID is calculated based on the random number r and the decrypted SerialNumber. The DID is encrypted using PubD to obtain the encrypted value CSI, and the DID is signed using PrvS to obtain the signature value SSI. The response message (CSI, SSI, R1, T0) is sent to the terminal; where T0 is the timestamp of the response message. 16) The Beidou navigation and positioning chip decrypts the CSI using PrvD to obtain the DID, and verifies the legality of the SSI using PubS; it calculates Ack=SM3 (DID||R1||T0), and sends an initialization completion message (Ack, T1) to the positioning chip server; the positioning chip server verifies the Ack, and after successful verification, stores {T1: [DID, PubD]}, indicating that initialization is complete; where T1 is the timestamp value of the initialization completion message; 2) The terminal negotiates a session key with the positioning chip server to obtain session key K; 3) Perform steps 31) to 33) to complete the encrypted transmission process of location information. 31) The Beidou navigation and positioning chip performs format verification on the location data Mi. After the verification is successful, proceed to step 32). 32) Protect Mi with the generated random number Rani to obtain location data Mi'; then encrypt (K, Mi', IV=Rani) with the session key K to obtain the encrypted value CDTDi, and sign (CDTDi||Rani||DID*||Counter) to obtain the signature value HDTDi; then send (CDTDi, Rani, HDTDi, N, T) to the positioning chip server; N is the current value of the counting parameter Counter, T is the timestamp value, and DID* is the device identifier updated by the positioning chip server for DID; 33) The positioning chip server checks whether Counter is incremented. If it is incremented, it verifies HDTDi. If the verification is successful, it decrypts (CDTDi, IV=Rani) using the session key K to obtain Mi', and uses Rani to deprotect Mi' to obtain the location data Mi.

2. The method according to claim 1, characterized in that, The method for negotiating and obtaining the session key K is as follows: 21) The Beidou navigation and positioning chip generates a temporary SM2 key pair (x, Rx) and a random number Ran; calculates H1=SM3(DID||Rx||PubS||Ran), and signs it with PrvD to obtain CDTN=SM2_Sign (PrvD, H1); and sends a DeviceHello message {DID, Rx, PubS, Ran, CDTN, Counter: 1} to the positioning chip server. 22) The positioning chip server verifies whether PubS is its own public key. If so, it uses PubD to verify CDTN and confirm the identity of the Beidou navigation and positioning chip. Then, it generates a temporary SM2 key pair (y, Ry), a random secret HS, and a random number r. It calculates the dynamically updated device identifier DID*=SM3 (DID||r) and CSTN1=SM2_Encrypt (PubD, DID*). Calculate HSTN=SM3 (Ry||HS||Ran), and obtain CSTN2=SM2_Sign (PrvS, HSTN) by signing with PrvS; send ServerHello message {TRy, CSTN1, HSTN, CSTN2, Ran, Counter: 2} to the Beidou navigation and positioning chip; 23) The Beidou navigation and positioning chip decrypts CSTN1 using PrvD to obtain DID*, updates the local DID to DID*; verifies CSTN2 using PubS, and after successful verification, calculates the shared key Z=SM2_KeyAgree (PrvD, Ry); derives the session key K=SM3-KDF (Z||HS||DID*); calculates FTN=SM3 (K||Rx||Ry||DID*), and sends a Finish message { FTN,Counter: 3} to the positioning chip server; 24) The positioning chip server calculates Z=SM2_KeyAgree (PrvS, Rx) and K=SM3-KDF (Z||HS||DID*) to verify whether the FTN calculated by the positioning chip server is consistent with the FTN calculated by the Beidou navigation and positioning chip. If they are consistent, the key negotiation is completed.

3. The method according to claim 1, characterized in that, In step 32), the generated random number Rani is used to protect Mi to obtain the location data Mi'=Mi XOR Rani; in step 33), the session key K is used to decrypt (CDTDi, IV=Rani) to obtain Mi'=SM4_Decrypt (K, CDTDi, IV=Rani).

4. The method according to claim 1, 2, or 3, characterized in that, When the set update trigger condition is met, the session key K is updated, and the method is as follows: 41) The Beidou navigation and positioning chip sends a session key update message (CDTDi, Rani, HDTDi, Counter:N, ReKey_Flag: 1) to the positioning chip server; ReKey_Flag is the update flag bit; 42) The positioning chip server verifies the session key update message. After successful verification, it generates new secret information HS* and random number r*. It calculates DID**=SM3 (DID*||r*) and sends {HS*,r*, random number R_new, signature SM2_Sign(PrvS, HS*||r*)} to the Beidou navigation and positioning chip. 43) The public key PubS of the Beidou navigation and positioning chip verifies the validity of the signature SM2_Sign(PrvS, HS*||r*). After successful verification, H=SM3(HS*||R_new) is calculated to verify the integrity of HS*. The Beidou navigation and positioning chip generates a new temporary key pair (x*, Rx*), and the positioning chip server generates a new temporary key pair (y*, Ry*). The shared key Z*=SM2_KeyAgree(PrvD, Ry*) is calculated. A new session key K*=SM3-KDF(Z*||HS*||DID**,128) is derived. The session key K* is synchronously switched to as the updated session key K.

5. The method according to claim 1, 2, or 3, characterized in that, The positioning chip server stores the decrypted location data Mi into an encrypted database and indexes it by DID*+Timestamp; Timestamp is a timestamp.

6. The method according to claim 1, characterized in that, The public and private keys (PrvD, PubD) of the terminal device are generated according to the SM2 algorithm; where PrvD is the private key and PubD is the public key.

7. The method according to claim 1, characterized in that, The terminals include wearable devices, mobile terminals, and embedded devices.

Images