A digital car key distributed security management method

Abstract

The application discloses a kind of digital car key key distributed security management methods.In the present application, by the random arrangement characteristics of fixed permutation matrix, the bit mapping relationship of gait feature vector is completely irregular, combined with the first dynamic verification factor generated by SM4 symmetric encryption algorithm, even if unauthorized users obtain gait feature data, it is also impossible to restore the verification factor by reverse deduction;At the same time, the weighted Kalman filtering algorithm used in GNSS and IMU integrated positioning dynamically adjusts the weight of observation data through signal-to-noise ratio, ensures that high-precision three-dimensional position coordinates can still be output in complex scenes, so that the third dynamic verification factor is deeply bound with real-time physical position. The distributed key fragmentation system constructed by the linkage of the two will split the complete root key into three independent fragments and store them in the vehicle security chip, mobile device and cloud server, which eliminates the system security risk caused by single-point key leakage, thereby improving the security and reliability of the overall method.

Description

Technical Field

[0001] This invention belongs to the field of automotive digital management technology, specifically a distributed security management method for digital vehicle key keys. Background Technology

[0002] Digital car key management refers to a technical system that standardizes and securely controls the entire lifecycle of keys—including generation, distribution, storage, updating, revocation, and destruction—when smart mobile terminal devices are used as digital keys for vehicles. As the core security foundation of digital car key technology, this system relies on a Trusted Execution Environment (TEE), Secure Element (SE), and cloud service platform to build an end-to-end encrypted channel from terminals such as mobile phones and smartwatches to the vehicle receiver. Its management process strictly follows international standard protocols such as the CCC (Consortium for Connected Cars and Vehicles), employing asymmetric encryption algorithms to ensure the uniqueness and non-copyability of keys. This enables digital key distribution and fine-grained access control, such as setting usage time limits, authorizing vehicle borrowing, and restricting driving ranges. Through rigorous key lifecycle management, this technology effectively solves the security risks of traditional physical keys, such as easy loss, difficulty in management, and easy duplication. It ensures the confidentiality, integrity, and non-repudiation of digital car keys during identity authentication, data transmission, and remote control processes, providing a key technological guarantee for promoting the development of intelligent, connected, and shared mobility in automobiles.

[0003] However, existing vehicle authentication technologies generally have multiple security shortcomings: they mostly adopt a single key storage architecture, with the root key centrally stored in the vehicle system or cloud server, which poses a single point of leakage risk; the verification factors are mostly static fixed values ​​or generated based on only a single biometric feature, which are easily bypassed by attackers through replay attacks or feature forgery, making the overall security protection capability difficult to cope with complex vehicle network attack scenarios. Summary of the Invention

[0004] The purpose of this invention is to provide a distributed security management method for digital car key keys in order to solve the problems mentioned above.

[0005] The technical solution adopted in this invention is as follows: A distributed security management method for digital car key keys, the method comprising the following steps:

[0006] S1: Generate a unique root key and split it into three encrypted fragments, which are stored respectively in the vehicle owner's mobile device, the in-vehicle security chip, and the automaker's cloud-based trusted server. The mobile device is equipped with a key status awareness component, which will synchronize the key dynamics between the cloud and the vehicle throughout the process, providing status support for subsequent verification procedures.

[0007] S2: When the car owner approaches the vehicle with a mobile device, the mobile device triggers the vehicle security chip to collect the car owner's real-time gait characteristics through StarFlash communication. It then combines the locally stored key fragment to generate the first dynamic verification factor and pushes it to the cloud server, waiting for the next secondary verification instruction.

[0008] S3: After receiving the first verification factor, the cloud server calls its own stored key fragment, matches it with the car owner's preset vehicle usage scenario permissions to generate a second dynamic verification factor, sends it to the mobile device, and simultaneously starts a cross-verification mechanism to trigger subsequent processes.

[0009] S4: The mobile device receives the second verification factor, combines it with the local key fragment and real-time location information to generate a third dynamic verification factor, and submits the three verification factors to the blockchain node to complete distributed consensus verification. After successful verification, a temporary session key is generated and synchronized to the vehicle-mounted security chip. At the same time, the verification result is fed back to the gait feature acquisition module to optimize the accuracy of the next recognition.

[0010] S5: After verifying the validity of the temporary session key, the onboard security chip performs a tiered unlocking operation: first, it uses UWB centimeter-level positioning to confirm the owner's location and unlock the corresponding door; after the owner enters the vehicle, it activates the vehicle's start permission based on the liveness detection result. The operation log is synchronized to the cloud and mobile devices to provide a basis for subsequent key deregistration.

[0011] S6: After the vehicle use ends, the mobile device sends a key deregistration request to the cloud. The cloud triggers the blockchain node to destroy the temporary session key and simultaneously instructs the onboard security chip to reset the key status. The mobile device's status awareness component updates the key availability status and clears local temporary verification data, preparing for the next verification process.

[0012] In a preferred embodiment, in step S1, when the signal strength of the star-flash node bound to the vehicle owner's mobile device is detected to be above -65dBm, the gait feature acquisition process is automatically triggered. An infrared depth camera in the vehicle cabin acquires the user's leg movement trajectory at a frame rate of 120 frames per second, while a 3-axis accelerometer under the seat simultaneously captures the user's center of gravity transfer data during walking. The data from both types of sensors are transmitted to the preprocessing unit of the vehicle security chip via a dedicated encrypted bus.

[0013] In a preferred embodiment, in step S2, after receiving the star flash trigger signal, the vehicle-mounted security chip immediately activates the root key fragment reading channel in the Hardware Security Domain (HSM). This channel adopts a physically isolated design and only responds to authorized instructions from the gait acquisition module. No external instructions can access it. The locally stored root key fragment is a 256-bit symmetric key fragment, which is written and locked in the storage area by a one-time fuse mechanism when the vehicle leaves the factory, and cannot be read, tampered with or exported externally. Subsequently, the gait feature acquisition module transmits the 12-dimensional gait feature vector (including normalized data such as stride length, stride frequency, leg swing angle, and center of gravity transfer rate) to the computing unit in the security domain through an encrypted dedicated bus. The computing unit first performs standardized preprocessing on the gait feature vector, maps the values ​​of each dimension to the 0-1 interval, and splices them to generate a 32-byte feature data block.

[0014] The formula for gait feature vector standardization preprocessing is:

[0015] ;

[0016] In the formula:

[0017] Let be the value of the i-th dimension in the original gait feature vector. It includes 12 core gait characteristic data such as stride length, stride frequency, and leg swing angle;

[0018] This is the global minimum value in the original gait feature vector;

[0019] The global maximum value in the original gait feature vector;

[0020] The value of the i-th gait feature after standardization is strictly limited to [0,1].

[0021] Standardization eliminates the dimensional differences of different time-phase feature dimensions, enabling heterogeneous data such as stride length (meter level) and step frequency (hertz level) to participate uniformly in subsequent hash operations, while avoiding the excessive influence of a single-dimensional feature on the calculation results.

[0022] In a preferred embodiment, in step S2, the SM3 hash algorithm engine XORs the root key fragment with the preprocessed feature data block and performs iterative grouping operations in 16-byte units. In each iteration, a weight factor dynamically calculated from real-time environmental parameters (ground flatness, light intensity, etc.) is introduced. After 64 rounds of compression transformation, a 256-bit hash value is generated. Finally, through truncation and permutation operations, the middle 128 bits of data are extracted from the 256-bit hash value, and the bit positions are adjusted based on the permutation matrix randomly generated when the vehicle leaves the factory, ultimately generating a 128-bit first dynamic verification factor. Throughout the entire operation, all original data (gait feature vector, root key fragment) flows in a closed loop within the security domain. The operation unit and the external interface adopt a unidirectional data transmission design, outputting only the final 128-bit verification factor to ensure that core sensitive data is not leaked outside the security domain.

[0023] The iterative formula for the SM3 mixed operation is as follows:

[0024] ;

[0025] Parameter definition:

[0026] The hash intermediate value of the nth iteration is initialized to the standard initialization vector IV of the SM3 algorithm (consisting of 8 32-bit registers).

[0027] The 256-bit root key fragment is stored locally, while the symmetric key fragment is randomly generated and locked by a fuse when the vehicle leaves the factory.

[0028] A 32-byte data block composed of standardized 12-dimensional gait feature vectors;

[0029] The dynamic weighting factor is calculated from real-time collected environmental parameters (ground flatness, light intensity, etc.) through a logistic regression model, and its value range is [0.8, 1.2].

[0030] This is the core compression function of the SM3 algorithm, which includes message expansion, nonlinear transformation, and modulo operation.

[0031] The intermediate hash value after the (n+1)th iteration is used to generate a complete 256-bit hash value after 64 iterations.

[0032] Introducing dynamic weighting factors This allows the hash operation result to change dynamically with environmental parameters, breaking the fixed input pattern of traditional hash operations and significantly improving the uniqueness and unpredictability of the first dynamic verification factor. Even with the same synchronous characteristics, different verification factors will be generated under different environments.

[0033] The formula for generating the 128-bit first dynamic validation factor is:

[0034] ;

[0035] In the formula:

[0036] The 256-bit SM3 hash value generated after 64 rounds of iteration.

[0037] Truncate is a truncation function that extracts a continuous 128-bit data segment from a 256-bit hash value.

[0038] S is a fixed permutation matrix, randomly generated and stored within the safety domain when the vehicle leaves the factory. Its elements are non-repeating integers from 0 to 127, and it is displayed as a 16×8 block matrix.

[0039] ;

[0040] Permute is a permutation function that adjusts the bit positions of 128-bit data according to the permutation matrix SS.

[0041] This is the final 128-bit first dynamic validation factor.

[0042] By rearranging the bits of the truncated 128-bit data using a random permutation matrix, the resistance to reverse derivation of the verification factor is further enhanced. Even if an attacker obtains a portion of the verification factor sample, they will not be able to reconstruct the original gait features or root key fragments through reverse computation.

[0043] In a preferred embodiment, in step S3, after the cloud server receives the 128-bit first dynamic verification factor sent by the vehicle security chip via the StarSpark high-reliability communication link, it first initiates integrity verification within the cloud-based Trusted Execution Environment (TEE): It calls the SM3 hash algorithm to perform a secondary hash operation on the verification factor, compares the result with the hash digest attached during transmission by the vehicle chip, and confirms that the data has not been tampered with or forged during transmission; subsequently, it calls its own stored 256-bit root key fragment (this fragment, along with the key fragments of the vehicle and mobile devices, are split from the same 512-bit root key using the Shamir secret sharing algorithm, and the three together form a complete distributed key system), and performs an XOR operation on the first verification factor and the root key fragment to generate a 256-bit intermediate key. The system first obtains the key material; then it accesses the vehicle owner's identity and permission database and matches it with preset vehicle usage scenario permission rules. Permission dimensions include time range (e.g., weekdays 7:00-19:00), geofence (e.g., within a 3-kilometer radius of home address and office location), and vehicle function permissions (e.g., only unlocking the car door, allowing engine start, or turning on the air conditioner). The system verifies in real time whether the current time and vehicle location meet the scenario rules. If they match, the scenario permission is encoded into a 64-bit permission vector, and a 128-bit second dynamic verification factor is generated by iterative hashing with the intermediate key material using SM3. Finally, the second verification factor is pushed to the vehicle owner's bound mobile device through the StarFlash low-latency link. The transmission process uses the SM4 symmetric encryption algorithm to ensure that the verification factor is not stolen during cross-device transmission.

[0044] In a preferred embodiment, in step S3, while generating and sending the second verification factor, the cloud server immediately initiates a blockchain cross-validation mechanism: it synchronizes core data such as the first verification factor, scene permission matching results, and current timestamp to 12 consensus nodes in the distributed blockchain network (including the vehicle security chip, mobile device, cloud server, and third-party trusted nodes). The nodes complete data consistency verification within 200 milliseconds using the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm. Each consensus node calls its own stored key shard to perform secondary verification of the first verification factor, while simultaneously comparing the scene permissions with the locally stored vehicle owner permission data. If all nodes pass verification, the third verification factor generation process for the mobile device in step S4 and the distributed key matching process between the vehicle chip and the mobile device in step S5 are triggered simultaneously. If any node fails verification (such as permission mismatch or verification factor tampering), a temporary lock command is immediately sent to the vehicle security chip to prohibit vehicle unlocking operations. An abnormal warning message is pushed to the vehicle owner through the mobile device, and the abnormal record is written to the blockchain ledger to form an immutable audit log. In addition, the cloud server will feed back the verification result to the vehicle security chip to adjust the weight parameters of subsequent gait feature collection, further optimizing the accuracy and security of identity recognition.

[0045] In a preferred embodiment, in step S4, the 256-bit root key fragment bound to the vehicle in the local secure storage area is first called (this fragment and the fragment stored in the vehicle security chip are symmetric key pairs generated from the same source, and are only synchronized through end-to-end encryption when the devices are first paired). At the same time, the GNSS and IMU fusion positioning module is activated: the GNSS module collects real-time latitude, longitude, altitude and satellite signal-to-noise ratio data, and the IMU module synchronously outputs triaxial acceleration, angular velocity and heading angle information. The two types of data are fused and corrected by an improved Kalman filter algorithm to eliminate positioning drift when GNSS signal is blocked, and generate real-time three-dimensional position coordinates (including latitude, longitude and altitude) with an accuracy of ±1 meter.

[0046] The GNSS and IMU fusion positioning weighted Kalman filter formula

[0047] ;

[0048] In the formula:

[0049] The optimal 3D position estimate (including latitude, longitude, and altitude) after fusion at time k.

[0050] This is the position estimate at time k based on IMU inertial data.

[0051] The Kalman gain matrix is ​​calculated in real time from the prediction error covariance and the observation noise covariance.

[0052] The position observation value at time k acquired by the GNSS module;

[0053] The observation matrix maps the state vector to the GNSS observation space.

[0054] This is the signal-to-noise ratio weighting factor, calculated from the average signal-to-noise ratio of GNSS satellites, with a value range of [0.6, 1.0].

[0055] By introducing a signal-to-noise ratio weighting factor to dynamically adjust the weight of observations, the contribution of observation data is increased when the GNSS signal is good, and the weight is automatically reduced when the signal is blocked. The positioning accuracy is maintained by relying on IMU inertial data, ensuring that the position data with an accuracy of ±1 meter can still be stably output in complex scenarios.

[0056] In a preferred embodiment, in step S4, the second verification factor and the root key fragment are XORed to obtain a 256-bit temporary key material. Then, the fused three-dimensional position coordinates are converted into a 128-bit position feature vector (by mapping latitude, longitude, and altitude to 32-bit integers and concatenating them), and this vector is used as the initial vector (Ⅳ) of the SM4 algorithm. Next, based on the temporary key material, the subkey sequence required for 32 rounds of encryption is generated through the improved SM4 key expansion algorithm. At the same time, the satellite signal-to-noise ratio in the positioning data is introduced as a dynamic adjustment factor to make a small offset for each round of subkeys (the offset is positively correlated with the signal-to-noise ratio; the higher the signal-to-noise ratio, the smaller the offset, ensuring stronger encryption stability when the positioning accuracy is high). Finally, the second verification factor is used as the plaintext input of the SM4 algorithm, and the adjusted subkey sequence is used for group encryption operation to output a 128-bit third dynamic verification factor. The entire operation process is completed within the TEE environment, and all intermediate data is not exposed externally. Only the final verification factor is output to the StarFlash communication module for subsequent blockchain consensus verification.

[0057] The formula for generating the third dynamic verification factor in SM4 encryption is:

[0058] ;

[0059] In the formula:

[0060] This is the final 128-bit third dynamic validation factor;

[0061] A 128-bit second verification factor is pushed to the cloud server;

[0062] The 256-bit root key fragments stored locally on mobile devices are generated from the same source as the key fragments of the vehicle security chip;

[0063] To improve the SM4 key expansion algorithm, the following was added to the standard expansion procedure: Dynamically offset the subkey;

[0064] A signal-to-noise ratio weighting factor consistent with that used in fusion positioning, used to adjust the subkey nonlinear transformation parameters;

[0065] This is a 128-bit initial vector generated from the fused 3D position coordinates.

[0066] To improve the SM4 block cipher algorithm, a position-dependent initialization vector and a dynamic subkey sequence are used;

[0067] The above formula deeply integrates root key fragmentation, second verification factor and location environment parameters, so that the third verification factor simultaneously contains three dimensions: identity and permissions, location information and environmental status. Even if an attacker obtains root key fragments, they will not be able to generate a valid verification factor in an unauthorized location.

[0068] The formula for transforming location feature vectors is:

[0069] ;

[0070] In the formula:

[0071] It is a 128-bit position feature vector, which serves as the initial vector for the SM4 algorithm;

[0072] lat is the latitude value after fusion positioning, mapped to a 32-bit unsigned integer in the range of [-90, 90].

[0073] lon is the longitude value after fusion positioning, mapped to a 32-bit unsigned integer in the range of [-180, 180].

[0074] alt is the elevation value after fusion positioning, mapped to a 32-bit unsigned integer in the range of [-1000, 8848].

[0075] snr is the average signal-to-noise ratio of GNSS satellites, mapped to a 32-bit unsigned integer in the range [0, 60].

[0076] Encode is a coordinate encoding function that enables lossless mapping from floating-point coordinates to fixed-length integers.

[0077] concat is a byte concatenation function that concatenates four 32-bit integers into a 128-bit vector in sequence.

[0078] By integrating 3D position and environmental signal-to-noise ratio information into an SM4 initial vector, the encryption process is strongly bound to real-time position, avoiding the risk of repeated encryption caused by traditional fixed initial vectors, and further improving the uniqueness of the verification factor.

[0079] In a preferred embodiment, in step S5, the third dynamic verification factor generated by the mobile device is transmitted to the security domain interface of the vehicle security chip via a StarFlash low-latency link. The interface adopts an authentication mechanism based on physically unclonable functions and only receives encrypted data from the bound mobile device. The vehicle security chip calls the locally stored root key fragment and performs SM4 symmetric decryption operation on the third verification factor and the first dynamic verification factor. During the decryption process, real-time vehicle status parameters are introduced as dynamic offsets, and the operation result is compared bit-by-bit with the pre-stored permission verification template. Simultaneously, the consensus nodes of the cloud blockchain network synchronously perform cross-verification on the first, second, and third verification factors. Each node completes the consistency matching of verification factors through distributed key sharding. When the verification results of all nodes are consistent and the matching degree with the permission template reaches 99.9% or more, the vehicle security chip immediately triggers the vehicle unlocking command. The unlocking signal is directly transmitted to the door lock execution unit through the hardware control bus, without passing through the vehicle operating system, ensuring the security and real-time performance of the unlocking operation. If the verification results do not match, the security chip immediately cuts off all external data channels, starts the local key update mechanism, generates a new root key fragment, and synchronizes it to the cloud and the mobile device.

[0080] In a preferred embodiment, in step S6, after the vehicle is unlocked, the onboard security chip immediately updates the local dynamic key pool, marks the first dynamic verification factor generated this time as used and removes it from the list of valid factors, and simultaneously generates a temporary key seed required for the next verification, storing it in the volatile storage area of ​​the security domain, which is automatically destroyed after the vehicle is turned off. The mobile device synchronously updates the permission validity period, extending the validity period of this verification to 15 minutes, and automatically triggering a re-verification process after the time limit is exceeded. The cloud server generates a unique data fingerprint by performing SM3 hash operation on all data of this verification, including gait feature vector verification factor generation records and cross-validation results, and writes it into the blockchain distributed ledger. The ledger data is jointly maintained by 12 consensus nodes, and no node can tamper with or delete it alone. In addition, the onboard security chip automatically starts the gait feature template update process every 30 days, optimizing the feature vector dimension and weight based on recently collected gait data to improve the accuracy and anti-interference ability of subsequent identity recognition. The update process is completed in a closed loop within the security domain without involving external data interaction.

[0081] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0082] 1. In this invention, the random permutation of a fixed permutation matrix makes the bit mapping relationship of gait feature vectors completely unpredictable. Combined with the first dynamic verification factor generated by the SM4 symmetric encryption algorithm, a strong binding relationship is formed with the user's unique gait biometrics. Even if an unauthorized user obtains gait feature data, they cannot reverse-derive the verification factor. Simultaneously, the weighted Kalman filter algorithm used in GNSS and IMU fusion positioning dynamically adjusts the weight of observation data through signal-to-noise ratio, ensuring accurate 3D position coordinates even in complex scenarios. Based on this, the generated SM4 initial vector and dynamic subkey sequence deeply bind the third dynamic verification factor to the real-time physical location, generating valid verification data only within authorized geographical areas. The distributed key sharding system constructed by these two mechanisms splits the complete root key into three independent shards, stored separately in the vehicle security chip, mobile device, and cloud server. Verification factor generation and verification can only be completed when all three participate in the computation simultaneously, eliminating system security risks caused by single-point key leakage and thus improving the overall security and reliability of the method.

[0083] 2. In this invention, dynamic factor linkage allows the generation logic of verification factors to change in real time according to the user's biometrics, physical location, and environmental conditions. Even if an attacker obtains a verification factor sample at a certain moment, they cannot reuse it in other scenarios or at other times, significantly improving the system's resistance to replay attacks. The dynamic signal-to-noise ratio offset mechanism of the SM4 subkey maintains encryption stability when the GNSS signal is good, and maintains the randomness of verification factors by increasing the offset when the signal is obstructed, ensuring that the verification process can still operate stably in complex environments such as underground parking garages and tunnels. The combination of these two features constructs a multi-dimensional verification barrier, forming cross-protection from three levels: biometric uniqueness, physical location authenticity, and distributed key storage, allowing the entire system to maintain high availability while also possessing multi-dimensional security protection. Attached Figure Description

[0084] Figure 1 This is a schematic diagram illustrating the process principle of the present invention. Detailed Implementation

[0085] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0086] Example: Refer to Figure 1 A distributed security management method for digital car key keys includes the following steps:

[0087] S1: Generate a unique root key and split it into three encrypted fragments, which are stored respectively in the vehicle owner's mobile device, the in-vehicle security chip, and the automaker's cloud-based trusted server. The mobile device is equipped with a key status awareness component, which will synchronize the key dynamics between the cloud and the vehicle throughout the process, providing status support for subsequent verification procedures.

[0088] S2: When the car owner approaches the vehicle with a mobile device, the mobile device triggers the vehicle security chip to collect the car owner's real-time gait characteristics through StarFlash communication. It then combines the locally stored key fragment to generate the first dynamic verification factor and pushes it to the cloud server, waiting for the next secondary verification instruction.

[0089] S3: After receiving the first verification factor, the cloud server calls its own stored key fragment, matches it with the car owner's preset vehicle usage scenario permissions to generate a second dynamic verification factor, sends it to the mobile device, and simultaneously starts a cross-verification mechanism to trigger subsequent processes.

[0090] S4: The mobile device receives the second verification factor, combines it with the local key fragment and real-time location information to generate a third dynamic verification factor, and submits the three verification factors to the blockchain node to complete distributed consensus verification. After successful verification, a temporary session key is generated and synchronized to the vehicle-mounted security chip. At the same time, the verification result is fed back to the gait feature acquisition module to optimize the accuracy of the next recognition.

[0091] S5: After verifying the validity of the temporary session key, the onboard security chip performs a tiered unlocking operation: first, it uses UWB centimeter-level positioning to confirm the owner's location and unlock the corresponding door; after the owner enters the vehicle, it activates the vehicle's start permission based on the liveness detection result. The operation log is synchronized to the cloud and mobile devices to provide a basis for subsequent key deregistration.

[0092] S6: After the vehicle use ends, the mobile device sends a key deregistration request to the cloud. The cloud triggers the blockchain node to destroy the temporary session key and simultaneously instructs the onboard security chip to reset the key status. The mobile device's status awareness component updates the key availability status and clears local temporary verification data, preparing for the next verification process.

[0093] In step S1, when the signal strength of the StarSignal node bound to the vehicle owner's mobile device is detected to be above -65dBm, the gait feature acquisition process is automatically triggered. The infrared depth camera in the vehicle cabin acquires the user's leg movement trajectory at a frame rate of 120 frames per second, while the 3-axis accelerometer under the seat simultaneously captures the user's center of gravity transfer data during walking. The data from both types of sensors are transmitted to the preprocessing unit of the vehicle security chip via a dedicated encrypted bus.

[0094] In step S2, after receiving the star flash trigger signal, the vehicle-mounted security chip immediately activates the root key fragment reading channel in the Hardware Security Domain (HSM). This channel adopts a physical isolation design and only responds to authorized instructions from the gait acquisition module. No external instructions can access it. The locally stored root key fragment is a 256-bit symmetric key fragment, which is written and locked in the storage area by a one-time fuse mechanism when the vehicle leaves the factory, and cannot be read, tampered with or exported externally. Subsequently, the gait feature acquisition module transmits the 12-dimensional gait feature vector (including normalized data such as stride length, stride frequency, leg swing angle, and center of gravity transfer rate) to the computing unit in the security domain through an encrypted dedicated bus. The computing unit first performs standardized preprocessing on the gait feature vector, maps the values ​​of each dimension to the 0-1 interval, and splices them to generate a 32-byte feature data block.

[0095] The formula for gait feature vector standardization preprocessing is:

[0096] ;

[0097] In the formula:

[0098] Let be the value of the i-th dimension in the original gait feature vector. It includes 12 core gait characteristic data such as stride length, stride frequency, and leg swing angle;

[0099] This is the global minimum value in the original gait feature vector;

[0100] The global maximum value in the original gait feature vector;

[0101] The value of the i-th gait feature after standardization is strictly limited to [0,1].

[0102] Standardization eliminates the dimensional differences of different time-phase feature dimensions, enabling heterogeneous data such as stride length (meter level) and step frequency (hertz level) to participate uniformly in subsequent hash operations, while avoiding the excessive influence of a single-dimensional feature on the calculation results.

[0103] In step S2, the SM3 hash algorithm engine XORs the root key fragment with the preprocessed feature data block and performs iterative grouping operations in 16-byte units. In each iteration, a weight factor dynamically calculated from real-time environmental parameters (ground flatness, light intensity, etc.) is introduced. After 64 rounds of compression transformation, a 256-bit hash value is generated. Finally, through truncation and permutation operations, the middle 128 bits of data are extracted from the 256-bit hash value, and the bit positions are adjusted based on the permutation matrix randomly generated when the vehicle leaves the factory, ultimately generating a 128-bit first dynamic verification factor. Throughout the entire operation, all original data (gait feature vector, root key fragment) flows in a closed loop within the security domain. The operation unit and the external interface adopt a unidirectional data transmission design, outputting only the final 128-bit verification factor to ensure that core sensitive data is not leaked outside the security domain.

[0104] The iterative formula for the SM3 mixed operation is as follows:

[0105] ;

[0106] Parameter definition:

[0107] The hash intermediate value of the nth iteration is initialized to the standard initialization vector IV of the SM3 algorithm (consisting of 8 32-bit registers).

[0108] The 256-bit root key fragment is stored locally, while the symmetric key fragment is randomly generated and locked by a fuse when the vehicle leaves the factory.

[0109] A 32-byte data block composed of standardized 12-dimensional gait feature vectors;

[0110] The dynamic weighting factor is calculated from real-time collected environmental parameters (ground flatness, light intensity, etc.) through a logistic regression model, and its value range is [0.8, 1.2].

[0111] This is the core compression function of the SM3 algorithm, which includes message expansion, nonlinear transformation, and modulo operation.

[0112] The intermediate hash value after the (n+1)th iteration is used to generate a complete 256-bit hash value after 64 iterations.

[0113] Introducing dynamic weighting factors This allows the hash operation result to change dynamically with environmental parameters, breaking the fixed input pattern of traditional hash operations and significantly improving the uniqueness and unpredictability of the first dynamic verification factor. Even with the same synchronous characteristics, different verification factors will be generated under different environments.

[0114] The formula for generating the 128-bit first dynamic validation factor is:

[0115] ;

[0116] In the formula:

[0117] The 256-bit SM3 hash value generated after 64 rounds of iteration.

[0118] Truncate is a truncation function that extracts a continuous 128-bit data segment from a 256-bit hash value.

[0119] S is a fixed permutation matrix, randomly generated and stored within the safety domain when the vehicle leaves the factory. Its elements are non-repeating integers from 0 to 127, and it is displayed as a 16×8 block matrix.

[0120] ;

[0121] Permute is a permutation function that adjusts the bit positions of 128-bit data according to the permutation matrix SS.

[0122] This is the final 128-bit first dynamic validation factor.

[0123] By rearranging the bits of the truncated 128-bit data using a random permutation matrix, the resistance to reverse derivation of the verification factor is further enhanced. Even if an attacker obtains a portion of the verification factor sample, they will not be able to reconstruct the original gait features or root key fragments through reverse computation.

[0124] In step S3, after receiving the 128-bit first dynamic verification factor sent by the vehicle security chip via the StarSpark high-reliability communication link, the cloud server first initiates integrity verification within the cloud-based Trusted Execution Environment (TEE): it calls the SM3 hash algorithm to perform a secondary hash operation on the verification factor, compares the result with the hash digest attached during transmission by the vehicle chip, and confirms that the data has not been tampered with or forged during transmission; then it calls its own stored 256-bit root key fragment (this fragment, along with the key fragments of the vehicle and mobile devices, are split from the same 512-bit root key using the Shamir secret sharing algorithm, and the three together form a complete distributed key system), and performs an XOR operation on the first verification factor and the root key fragment to generate 256-bit intermediate key material; then... The system accesses the vehicle owner's identity and permission database and matches preset usage scenario permission rules. Permission dimensions include time range (e.g., weekdays 7:00-19:00), geofence (e.g., within a 3-kilometer radius of home address and office location), and vehicle function permissions (e.g., only unlocking the car door, allowing engine start, or turning on the air conditioner). The system verifies in real time whether the current time and vehicle location meet the scenario rules. If they match, the scenario permission is encoded into a 64-bit permission vector, and a 128-bit second dynamic verification factor is generated by iterative hashing with the intermediate key material using SM3. Finally, the second verification factor is pushed to the vehicle owner's bound mobile device through the StarFlash low-latency link. The transmission process uses SM4 symmetric encryption algorithm to ensure that the verification factor is not stolen during cross-device transmission.

[0125] In step S3, while generating and sending the second verification factor, the cloud server immediately initiates the blockchain cross-validation mechanism: it synchronizes core data such as the first verification factor, scene permission matching results, and current timestamp to the 12 consensus nodes of the distributed blockchain network (including the vehicle safety chip, mobile device, cloud server, and third-party trusted nodes). The nodes complete data consistency verification within 200 milliseconds using the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm. Each consensus node calls its own stored key shard to perform secondary verification of the first verification factor, and simultaneously compares the scene permissions with the locally stored vehicle owner permission data. If all nodes verify the data... If the verification passes, the third verification factor generation process for the mobile device in step S4 and the distributed key matching process between the vehicle chip and the mobile device in step S5 are triggered simultaneously. If any node fails verification (such as permission mismatch or verification factor tampering), a temporary lock command is immediately sent to the vehicle security chip to prohibit vehicle unlocking operations. An abnormal warning message is pushed to the vehicle owner through the mobile device, and the abnormal record is written to the blockchain ledger to form an immutable audit log. In addition, the cloud server will feed back the verification result to the vehicle security chip to adjust the weight parameters of subsequent gait feature collection, further optimizing the accuracy and security of identity recognition.

[0126] In step S4, the 256-bit root key fragment bound to the vehicle in the local secure storage area is first called (this fragment and the fragment stored in the vehicle security chip are symmetric key pairs generated from the same source, and are only synchronized through end-to-end encryption when the devices are first paired). At the same time, the GNSS and IMU fusion positioning module is activated: the GNSS module collects real-time latitude, longitude, altitude and satellite signal-to-noise ratio data, and the IMU module outputs triaxial acceleration, angular velocity and heading angle information simultaneously. The two types of data are fused and corrected by an improved Kalman filter algorithm to eliminate positioning drift when GNSS signal is blocked, and generate real-time three-dimensional position coordinates (including latitude, longitude and altitude) with an accuracy of ±1 meter.

[0127] The GNSS and IMU fusion positioning weighted Kalman filter formula

[0128] ;

[0129] In the formula:

[0130] The optimal 3D position estimate (including latitude, longitude, and altitude) after fusion at time k.

[0131] This is the position estimate at time k based on IMU inertial data.

[0132] The Kalman gain matrix is ​​calculated in real time from the prediction error covariance and the observation noise covariance.

[0133] The position observation value at time k acquired by the GNSS module;

[0134] The observation matrix maps the state vector to the GNSS observation space.

[0135] This is the signal-to-noise ratio weighting factor, calculated from the average signal-to-noise ratio of GNSS satellites, with a value range of [0.6, 1.0].

[0136] By introducing a signal-to-noise ratio weighting factor to dynamically adjust the weight of observations, the contribution of observation data is increased when the GNSS signal is good, and the weight is automatically reduced when the signal is blocked. The positioning accuracy is maintained by relying on IMU inertial data, ensuring that the position data with an accuracy of ±1 meter can still be stably output in complex scenarios.

[0137] In step S4, the second verification factor and the root key fragment are XORed to obtain a 256-bit temporary key material. Then, the fused three-dimensional position coordinates are converted into a 128-bit position feature vector (by mapping latitude, longitude, and altitude to 32-bit integers and concatenating them), and this vector is used as the initial vector (Ⅳ) of the SM4 algorithm. Next, based on the temporary key material, the subkey sequence required for 32 rounds of encryption is generated through the improved SM4 key expansion algorithm. At the same time, the satellite signal-to-noise ratio in the positioning data is introduced as a dynamic adjustment factor to make a small offset for each round of subkeys (the offset is positively correlated with the signal-to-noise ratio; the higher the signal-to-noise ratio, the smaller the offset, ensuring stronger encryption stability when the positioning accuracy is high). Finally, the second verification factor is used as the plaintext input of the SM4 algorithm, and the adjusted subkey sequence is used for group encryption operation to output a 128-bit third dynamic verification factor. The entire operation process is completed within the TEE environment, and all intermediate data is not exposed externally. Only the final verification factor is output to the StarSpark communication module for subsequent blockchain consensus verification.

[0138] The formula for generating the third dynamic verification factor in SM4 encryption is:

[0139] ;

[0140] In the formula:

[0141] This is the final 128-bit third dynamic validation factor;

[0142] A 128-bit second verification factor is pushed to the cloud server;

[0143] The 256-bit root key fragments stored locally on mobile devices are generated from the same source as the key fragments of the vehicle security chip;

[0144] To improve the SM4 key expansion algorithm, the following was added to the standard expansion procedure: Dynamically offset the subkey;

[0145] A signal-to-noise ratio weighting factor consistent with that used in fusion positioning, used to adjust the subkey nonlinear transformation parameters;

[0146] This is a 128-bit initial vector generated from the fused 3D position coordinates.

[0147] To improve the SM4 block cipher algorithm, a position-dependent initialization vector and a dynamic subkey sequence are used;

[0148] The above formula deeply integrates root key fragmentation, second verification factor and location environment parameters, so that the third verification factor simultaneously contains three dimensions: identity and permissions, location information and environmental status. Even if an attacker obtains root key fragments, they will not be able to generate a valid verification factor in an unauthorized location.

[0149] The formula for transforming location feature vectors is:

[0150] ;

[0151] In the formula:

[0152] It is a 128-bit position feature vector, which serves as the initial vector for the SM4 algorithm;

[0153] lat is the latitude value after fusion positioning, mapped to a 32-bit unsigned integer in the range of [-90, 90].

[0154] lon is the longitude value after fusion positioning, mapped to a 32-bit unsigned integer in the range of [-180, 180].

[0155] alt is the elevation value after fusion positioning, mapped to a 32-bit unsigned integer in the range of [-1000, 8848].

[0156] snr is the average signal-to-noise ratio of GNSS satellites, mapped to a 32-bit unsigned integer in the range [0, 60].

[0157] Encode is a coordinate encoding function that enables lossless mapping from floating-point coordinates to fixed-length integers.

[0158] concat is a byte concatenation function that concatenates four 32-bit integers into a 128-bit vector in sequence.

[0159] By integrating 3D position and environmental signal-to-noise ratio information into an SM4 initial vector, the encryption process is strongly bound to the real-time position, avoiding the risk of repeated encryption caused by traditional fixed initial vectors, and further improving the uniqueness of the verification factor.

[0160] In step S5, the third dynamic verification factor generated by the mobile device is transmitted to the security domain interface of the vehicle security chip via the StarFlash low-latency link. The interface adopts an authentication mechanism based on physically unclonable functions and only receives encrypted data from the bound mobile device. The vehicle security chip calls the locally stored root key fragment and performs SM4 symmetric decryption operation on the third verification factor and the first dynamic verification factor. During the decryption process, real-time vehicle status parameters are introduced as dynamic offsets, and the operation result is compared bit-by-bit with the pre-stored permission verification template. At the same time, the consensus nodes of the cloud blockchain network synchronously perform cross-verification on the first, second, and third verification factors. Each node completes the consistency matching of verification factors through distributed key sharding. When the verification results of all nodes are consistent and the matching degree with the permission template reaches 99.9% or more, the vehicle security chip immediately triggers the vehicle unlocking command. The unlocking signal is directly transmitted to the door lock execution unit through the hardware control bus, without passing through the vehicle operating system, ensuring the security and real-time performance of the unlocking operation. If the verification results do not match, the security chip immediately cuts off all external data channels, starts the local key update mechanism, generates a new root key fragment, and synchronizes it to the cloud and the mobile device.

[0161] In step S6, after the vehicle is unlocked, the onboard security chip immediately updates the local dynamic key pool, marking the first dynamic verification factor generated this time as used and removing it from the list of valid factors. Simultaneously, it generates a temporary key seed required for the next verification, storing it in the volatile storage area of ​​the security domain, which is automatically destroyed after the vehicle is turned off. The mobile device synchronously updates the permission validity period, extending the validity period of this verification to 15 minutes. After this time, a re-verification process is automatically triggered. The cloud server generates a unique data fingerprint from all data of this verification, including gait feature vector verification factor generation records and cross-validation results, using SM3 hashing, and writes it to the blockchain distributed ledger. The ledger data is jointly maintained by 12 consensus nodes, and no node can tamper with or delete it independently. Furthermore, the onboard security chip automatically initiates a gait feature template update process every 30 days, optimizing the feature vector dimensions and weights based on recently collected gait data to improve the accuracy and anti-interference capability of subsequent identity recognition. The entire update process is completed in a closed loop within the security domain, without involving external data interaction.

[0162] To verify the beneficial effects of this distributed security management method for digital car keys, three sets of comparative examples were designed, each corresponding to a core deficiency of current mainstream technical solutions:

[0163] Comparative Example 1: Traditional centralized key static verification method:

[0164] The vehicle's ECU stores a complete 256-bit root key. The vehicle owner generates a fixed verification factor using a preset 6-digit password. The mobile device transmits the password in plaintext to the vehicle system, which directly compares the password with the locally stored value to complete the verification. The cloud only records the verification timestamp and does not participate in key calculation or cross-validation. There is no dynamic factor generation or permission matching mechanism, and the verification process relies entirely on the vehicle's local system.

[0165] Comparative Example 2: Single Biometric Verification Method:

[0166] The system collects the driver's facial features using only the vehicle's front-facing camera, extracts a 16-dimensional facial feature vector, and directly uses it as a verification factor. There is no location binding or distributed key splitting. The verification process is completed locally on the vehicle's security chip, without data interaction with the cloud or mobile devices. There is no cross-validation or dynamic adjustment mechanism, and the facial feature data is transmitted in plaintext on the vehicle's internal bus.

[0167] Comparative Example 3: Single GNSS Positioning Verification Method:

[0168] The system obtains latitude and longitude data solely through the vehicle-mounted GNSS module, using the positioning coordinates directly as the only input for generating verification factors, without IMU fusion positioning or dynamic signal-to-noise ratio offset mechanisms. The root key is centrally stored on a cloud server, and the verification factors are generated by a single node in the cloud and then transmitted to the vehicle system. There is no blockchain consensus verification or distributed key sharding, and the verification results are only confirmed unilaterally by the cloud.

[0169] The performance comparison data is shown in the table below:

[0170] Success rate of replay attack resistance (%) 0 95 88 92 Key leakage risk (%) 0 100 75 100 Data tampering success rate (%) 0 85 70 80 Success rate of verification in complex scenarios (%) 99.5 90 82 65 Average verification latency (ms) 200 800 500 650 Cross-device data security level Financial grade (Level 5) Basic level (Level 1) General Level (Level 2) Basic level (Level 1)

[0171] The specific calculation methods for each indicator data include:

[0172] The calculation of the replay attack success rate includes: setting up a test environment to simulate a vehicle network attack scenario, using a professional network packet capture tool to capture 100 valid verification data packets at different times and locations, and then repeatedly sending the captured data packets to the target vehicle at different times (interval ≥ 2 hours) or in different geographical areas (distance ≥ 5 kilometers) than the original verification scenario, and counting the number of times the vehicle unlock was successfully triggered. The calculation method is: Replay attack success rate = (Number of successful unlocks ÷ Total number of replay tests) × 100%. Because this method deeply binds each verification factor to real-time gait features and geographical location and generates them dynamically, no unlock was triggered in 100 replay tests, resulting in a success rate of 0%. Comparative Example 1 uses a static fixed password, and 95 replay data packets successfully matched the unlock logic, resulting in a success rate of 95%. Comparative Example 2's facial feature verification factor has no dynamic adjustment mechanism, and 88 replays successfully unlocked, resulting in a success rate of 88%. Comparative Example 3's location verification factor only relies on coordinate information, and 92 replays completed unlocking through location matching, resulting in a success rate of 92%.

[0173] Key leakage risk: The test employed three mainstream key theft methods: side-channel attack, memory dump analysis, and firmware reverse engineering. Three rounds of attack tests were conducted on each of the 100 test vehicles equipped with different solutions, and the number of vehicles that successfully obtained the complete root key was counted. The calculation method is: Key leakage risk = (Number of vehicles successfully obtaining the complete root key ÷ Total number of test vehicles) × 100%. This method uses distributed key sharding storage, ensuring no complete root key exists on a single node; none of the 100 test vehicles had their complete keys stolen, resulting in a risk of 0%. In Comparative Example 1, the root key was centrally stored in the vehicle's ECU; all 100 vehicles successfully had their complete keys extracted, resulting in a risk of 100%. In Comparative Example 2, facial feature templates were stored in a weakly encrypted form on the vehicle's chip; the feature templates of 75 vehicles were reverse engineered, resulting in a risk of 75%. In Comparative Example 3, the root key was centrally stored on a cloud server; the cloud keys of all 100 vehicles were obtained through simulated attacks, resulting in a risk of 100%.

[0174] The data tampering success rate calculation method includes: injecting tampered feature data, verification factors, or location information into the verification data transmission link, conducting 100 tampering tests, and counting the number of times the tampered data successfully passed vehicle verification. The calculation method is: Data tampering success rate = (Number of successful verifications after tampering ÷ Total number of tampering tests) × 100%. This method uses blockchain distributed cross-verification and hardware-level data encryption, and all 100 tampered data were identified and intercepted, resulting in a success rate of 0%. Comparative Example 1 has no data verification mechanism, and 85 tampered data successfully matched the static password logic, resulting in a success rate of 85%. Comparative Example 2 relies solely on local feature matching, and 70 tampered facial features passed threshold matching, resulting in a success rate of 70%. Comparative Example 3 has no cross-node verification, and 80 tampered location data passed single-node verification in the cloud, resulting in a success rate of 80%.

[0175] The method for calculating the success rate of verification in complex scenarios includes: selecting three types of weak GNSS signal coverage scenarios—underground parking garages, urban tunnels, and densely built-up areas—and conducting 200 verification tests for each scenario, for a total of 600 tests. The number of successful vehicle unlocking tests is then counted. The calculation method is: Complex scenario verification success rate = (Number of successful unlocking tests ÷ Total number of tests) × 100%. This method uses GNSS+IMU fusion positioning and a dynamic signal-to-noise ratio offset mechanism. Only 3 tests failed due to extreme signal obstruction, resulting in a success rate of (597 ÷ 600) × 100% = 99.5%. In Comparative Example 1, the static password is unaffected by the scenario, with 540 successful unlocking tests, resulting in a success rate of 90%. In Comparative Example 2, facial recognition is affected by parking garage lighting, with 492 successful unlocking tests, resulting in a success rate of 82%. In Comparative Example 3, which relies solely on GNSS positioning, 390 tests failed due to signal loss, resulting in a success rate of 65%.

[0176] The average verification latency calculation method includes: the time interval from the user triggering the verification action (such as bringing the device close to the vehicle) to the vehicle responding with a successful unlock response. Each test vehicle is tested 50 times, and the arithmetic mean of all test data is taken. This method utilizes the StarFlash low-latency link and hardware-level parallel computation. The latency range of the 50 tests is 180-220ms, with an average of 200ms. In Comparative Example 1, the latency range for Bluetooth transmission and in-vehicle system computation is 700-900ms, with an average of 800ms. In Comparative Example 2, the latency range for facial feature acquisition and local matching is 450-550ms, with an average of 500ms. In Comparative Example 3, the latency range for cloud key generation and transmission is 600-700ms, with an average of 650ms.

[0177] The cross-device data security level calculation method includes: scoring based on the "Network Security Level Protection 2.0" standard, from four dimensions: data encryption strength, transmission security protection, storage security mechanism, and access control policy. Each dimension has a maximum score of 5 points, for a total of 20 points, corresponding to levels 1-5 (level 1 is the basic level, and level 5 is the financial level). This method uses the highest level of protection in all four dimensions (SM4 encryption, StarFlash security link, distributed storage, and TEE trusted execution), for a total score of 20 points, corresponding to level 5; Comparative Example 1 only uses basic symmetric encryption and local storage, for a total score of 4 points, corresponding to level 1; Comparative Example 2 uses facial feature encryption but has no transmission protection, for a total score of 8 points, corresponding to level 2; Comparative Example 3 uses cloud storage but has no distributed verification, for a total score of 4 points, corresponding to level 1.

[0178] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variations thereof is intended to include non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0179] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A distributed security management method for digital car key keys, characterized in that: The method includes the following steps: S1: Generate a unique root key and split it into three encrypted fragments, which are stored in the car owner's mobile device, the vehicle's security chip, and the car manufacturer's cloud-based trusted server, respectively; the mobile device is equipped with a key status awareness component to synchronize the key dynamics between the cloud and the vehicle throughout the process. S2: When the car owner approaches the vehicle with a mobile device, the mobile device triggers the vehicle security chip to collect the car owner's real-time gait characteristics through StarFlash communication. It then combines the locally stored key fragment to generate the first dynamic verification factor and pushes it to the cloud server, waiting for the next secondary verification instruction. S3: After receiving the first verification factor, the cloud server calls its own stored key fragment, matches the car owner's preset vehicle usage scenario permissions to generate the second dynamic verification factor, sends it to the mobile device, and at the same time starts the cross-verification mechanism to trigger the subsequent process. S4: The mobile device receives the second verification factor, combines the local key fragment with the real-time location information to generate the third dynamic verification factor, and submits the three verification factors to the blockchain node to complete the distributed consensus verification; after the verification is successful, a temporary session key is generated, synchronized to the vehicle security chip, and the verification result is fed back to the gait feature acquisition module. S5: After the vehicle security chip verifies the validity of the temporary session key, it performs a tiered unlocking operation: First, it uses UWB centimeter-level positioning to confirm the owner's location and unlock the corresponding door. After the owner enters the vehicle, it activates the vehicle start permission based on the liveness detection result. S6: After the vehicle use ends, the mobile device sends a key cancellation request to the cloud. The cloud triggers the blockchain node to destroy the temporary session key and simultaneously instructs the vehicle security chip to reset the key status. The mobile device's status awareness component updates the key availability status and clears the local temporary verification data to prepare for the next verification process.

2. The distributed security management method for digital car key keys as described in claim 1, characterized in that: In step S1, when the signal strength of the star flash node bound to the vehicle owner's mobile device is detected to be above -65dBm, the gait feature acquisition process is automatically triggered. An infrared depth camera inside the vehicle's cockpit captures the user's leg movement trajectory at a frame rate of 120 frames per second. At the same time, a 3-axis accelerometer under the seat simultaneously captures the user's center of gravity transfer data while walking. The data from both types of sensors are transmitted to the preprocessing unit of the vehicle's security chip via a dedicated encrypted bus.

3. The distributed security management method for digital car key keys as described in claim 1, characterized in that: In step S2, after receiving the star flash trigger signal, the vehicle-mounted security chip immediately activates the root key fragment reading channel in the hardware security domain. This channel adopts a physical isolation design and only responds to authorized instructions from the gait acquisition module. No external instructions can access it. The locally stored root key fragment is a 256-bit symmetric key fragment, which is written and locked in the storage area by a one-time fuse mechanism when the vehicle leaves the factory. It cannot be read, tampered with, or exported externally. Subsequently, the gait feature acquisition module transmits the 12-dimensional gait feature vector to the computing unit in the security domain through an encrypted dedicated bus. The computing unit first performs standardized preprocessing on the gait feature vector, maps the values ​​of each dimension to the 0-1 interval, and splices them to generate a 32-byte feature data block. The formula for gait feature vector standardization preprocessing is: ； In the formula: Let be the value of the i-th dimension in the original gait feature vector. This includes stride length, stride frequency, and leg swing angle data; This is the global minimum value in the original gait feature vector; The global maximum value in the original gait feature vector; The value of the i-th gait feature after standardization is strictly limited to [0,1].

4. The distributed security management method for digital car key keys as described in claim 1, characterized in that: In step S2, the SM3 hash algorithm engine XORs the root key fragment with the preprocessed feature data block and performs iterative grouping operations in 16-byte units. In each iteration, a weight factor dynamically calculated by real-time environmental parameters is introduced. After 64 rounds of compression transformation, a 256-bit hash value is generated. Finally, through truncation and permutation operations, the middle 128 bits of data are extracted from the 256-bit hash value, and the bit positions are adjusted based on the permutation matrix randomly generated when the vehicle leaves the factory, ultimately generating a 128-bit first dynamic verification factor. In the entire operation process, all original data flows in a closed loop within the security domain. The operation unit and the external interface adopt a unidirectional data transmission design, and only the final 128-bit verification factor is output. The iterative formula for the SM3 mixed operation is as follows: ； Parameter definition: Let N be the intermediate hash value of the nth iteration, and let N be the standard initialization vector of the SM3 algorithm. The 256-bit root key fragment is stored locally, while the symmetric key fragment is randomly generated and locked by a fuse when the vehicle leaves the factory. A 32-byte data block composed of standardized 12-dimensional gait feature vectors; The dynamic weighting factor is calculated from real-time collected environmental parameters using a logistic regression model, and its value ranges from [0.8, 1.2]. This is the core compression function of the SM3 algorithm, which includes message expansion, nonlinear transformation, and modulo operation. The intermediate hash value after the (n+1)th iteration is used to generate a complete 256-bit hash value after 64 iterations. The formula for generating the 128-bit first dynamic validation factor is: ； In the formula: This is a 256-bit SM3 hash value generated after 64 rounds of iteration; Truncate is a truncation function that extracts a continuous 128-bit data segment from a 256-bit hash value. S is a fixed permutation matrix, randomly generated and stored in the safety domain when the vehicle leaves the factory. The matrix elements are non-repeating integers from 0 to 127, and it is displayed in 16×8 block matrix form, specifically: ; Permute is a permutation function that adjusts the bit positions of 128-bit data according to the permutation matrix SS. This is the final 128-bit first dynamic validation factor.

5. The distributed security management method for digital car key keys as described in claim 1, characterized in that: In step S3, after the cloud server receives the 128-bit first dynamic verification factor sent by the vehicle security chip through the StarFlash high-reliability communication link, it first initiates integrity verification in the cloud trusted execution environment: calling the SM3 hash algorithm to perform a secondary hash operation on the verification factor, comparing the result with the hash digest attached when the vehicle chip is transmitted, and confirming that the data has not been tampered with or forged during transmission; then calling its own stored 256-bit root key fragment, performing an XOR operation on the first verification factor and the root key fragment to generate 256-bit intermediate key material; next, accessing the vehicle owner identity and permission database, matching the preset vehicle usage scenario permission rules, the permission dimensions include time range, geofence, and vehicle function permissions, the system verifies in real time whether the current time and vehicle location meet the scenario rules, if they match, the scenario permission is encoded into a 64-bit permission vector, and generated into a 128-bit second dynamic verification factor through SM3 iterative hash operation with the intermediate key material; finally, the second verification factor is pushed to the vehicle owner's bound mobile device through the StarFlash low-latency link.

6. The distributed security management method for digital car key keys as described in claim 1, characterized in that: In step S3, while generating and sending the second verification factor, the cloud server immediately starts the blockchain cross-verification mechanism: the first verification factor, the scene permission matching result, and the current timestamp data are synchronized to the 12 consensus nodes of the distributed blockchain network, and the nodes complete the data consistency verification; each consensus node will call its own stored key shard to perform secondary verification of the first verification factor, and at the same time compare the scene permission with the locally stored vehicle owner permission data. If all nodes pass the verification, the third verification factor generation process of the mobile device in step S4 and the distributed key matching process of the vehicle chip and the mobile device in step S5 are triggered simultaneously. If a node verification fails, a temporary lock command is immediately sent to the vehicle security chip to prevent the vehicle from unlocking. An abnormal warning message is also pushed to the vehicle owner via mobile device, and the abnormal record is written to the blockchain ledger to form an immutable audit log.

7. The distributed security management method for digital car key keys as described in claim 1, characterized in that: In step S4, the 256-bit root key fragment bound to the vehicle in the local secure storage area is first called, and the GNSS and IMU fusion positioning module is activated at the same time: the GNSS module collects real-time latitude, longitude, altitude and satellite signal-to-noise ratio data, and the IMU module outputs triaxial acceleration, angular velocity and heading angle information simultaneously. The two types of data are fused and corrected by an improved Kalman filter algorithm to eliminate positioning drift when GNSS signal is blocked and generate real-time three-dimensional position coordinates with an accuracy of ±1 meter. The formula for weighted Kalman filtering of GNSS and IMU fusion positioning is as follows: ； In the formula: For: the optimal 3D position estimate after fusion at time k; This is the position estimate at time k based on IMU inertial data. The Kalman gain matrix is ​​calculated in real time from the prediction error covariance and the observation noise covariance. The position observation value at time k acquired by the GNSS module; The observation matrix maps the state vector to the GNSS observation space. This is the signal-to-noise ratio weighting factor, calculated from the average signal-to-noise ratio of GNSS satellites, with a value range of [0.6, 1.0].

8. The distributed security management method for digital car key keys as described in claim 1, characterized in that: In step S4, the second verification factor and the root key fragment are XORed to obtain a 256-bit temporary key material. The fused three-dimensional position coordinates are then converted into a 128-bit position feature vector, which is used as the initial vector for the SM4 algorithm. Next, based on the temporary key material, the subkey sequence required for 32 rounds of encryption is generated through the improved SM4 key expansion algorithm. At the same time, the satellite signal-to-noise ratio in the positioning data is introduced as a dynamic adjustment factor to make a slight offset to the subkey in each round. Finally, the second verification factor is used as the plaintext input of the SM4 algorithm, and the adjusted subkey sequence is used to perform group encryption operation to output a 128-bit third dynamic verification factor. The entire operation process is completed within the TEE environment. All intermediate data is not exposed externally. Only the final verification factor is output to the StarFlash communication module for subsequent blockchain consensus verification. The formula for generating the third dynamic verification factor in SM4 encryption is: ； In the formula: This is the final 128-bit third dynamic validation factor; A 128-bit second verification factor is pushed to the cloud server; The 256-bit root key fragments stored locally on mobile devices are generated from the same source as the key fragments of the vehicle security chip; To improve the SM4 key expansion algorithm, the following was added to the standard expansion procedure: Dynamically offset the subkey; A signal-to-noise ratio weighting factor consistent with that used in fusion positioning, used to adjust the subkey nonlinear transformation parameters; This is a 128-bit initial vector generated from the fused 3D position coordinates. To improve the SM4 block cipher algorithm, a position-dependent initialization vector and a dynamic subkey sequence are used; The formula for transforming location feature vectors is: ； In the formula: It is a 128-bit position feature vector, which serves as the initial vector for the SM4 algorithm; lat is the latitude value after fusion positioning, mapped to a 32-bit unsigned integer in the range of [-90, 90]. lon is the longitude value after fusion positioning, mapped to a 32-bit unsigned integer in the range of [-180, 180]. alt is the elevation value after fusion positioning, mapped to a 32-bit unsigned integer in the range of [-1000, 8848]. snr is the average signal-to-noise ratio of GNSS satellites, mapped to a 32-bit unsigned integer in the range [0,60]. Encode is a coordinate encoding function that enables lossless mapping from floating-point coordinates to fixed-length integers. `concat` is a byte concatenation function that concatenates four 32-bit integers into a 128-bit vector in sequence.

9. The distributed security management method for digital car key keys as described in claim 1, characterized in that: In step S5, the third dynamic verification factor generated by the mobile device is transmitted to the security domain interface of the vehicle security chip through the StarFlash low-latency link. The interface adopts an identity authentication mechanism based on a physically unclonable function and only receives encrypted data from the bound mobile device. The vehicle security chip calls the locally stored root key fragment and performs SM4 symmetric decryption on the third verification factor and the first dynamic verification factor. During the decryption process, real-time vehicle status parameters are introduced as dynamic offsets. The calculation result is compared bit-by-bit with the pre-stored permission verification template. At the same time, the consensus nodes of the cloud blockchain network synchronously perform cross-verification on the first, second and third verification factors. Each node completes the consistency matching of verification factors through distributed key sharding. When the verification results of all nodes are consistent and the matching degree with the permission template reaches 99.9% or more, the vehicle security chip immediately triggers the vehicle unlocking command. The unlocking signal is directly transmitted to the door lock execution unit through the hardware control bus. If the verification results do not match, the security chip immediately cuts off all external data channels, starts the local key update mechanism, generates a new root key fragment and synchronizes it to the cloud and mobile devices.

10. The distributed security management method for digital car key keys as described in claim 1, characterized in that: In step S6, after the vehicle is unlocked, the on-board security chip immediately updates the local dynamic key pool, marks the first dynamic verification factor generated this time as used and removes it from the list of valid factors, and generates a temporary key seed required for the next verification, which is stored in the volatile storage area of ​​the security domain and is automatically destroyed after the vehicle is turned off.

Images