A key management method and system based on a national secret technology

Abstract

The application discloses a key management method and system based on a national secret technology, and the method describes a key generation, request, storage and distribution process from an application perspective, and relates to the technical field of key management of rail transit. In response to a key generation request of rail transit equipment, a public key, a private key and a 32-byte SM3 fingerprint are generated, the public key and the 32-byte SM3 fingerprint are bound with a device identifier of the rail transit equipment, and a trust record is generated; in response to a key calling request of the rail transit equipment, a trust level and the 32-byte SM3 fingerprint are found from the trust record according to the device identifier of the rail transit equipment, and trust verification is performed; if the trust verification is passed, the public key of the rail transit equipment is acquired from the trust record, and a temporary session key is generated by performing a cryptographic operation according to the locally stored private key and the public key of the rail transit equipment. The method can realize lightweight and rapid authentication key management suitable for small embedded devices while ensuring national secret compliance.

Description

Technical Field

[0001] This application relates to the field of rail transit key management technology, and in particular to a key management method and system based on national cryptographic technology. Background Technology

[0002] As rail transit systems develop towards intelligence and networking, the security protection of critical information infrastructure is becoming increasingly important. As a core component of information security, the key management system in the rail transit field undertakes crucial responsibilities such as identity authentication, control command encryption, and ticketing data protection for various terminal devices including onboard terminals (such as Train Control and Management System (TCMS)), trackside controllers, and ticketing terminals, directly impacting train operation safety and operational stability.

[0003] In terms of technological development, existing key management solutions mainly fall into two categories: one is key management systems based on traditional commercial algorithms such as RSA and ECC. These solutions generally rely on third-party certification authorities (CAs) to build a trust system and complete device identity verification through multiple rounds of certificate checks. They are widely used in large servers and control center equipment in the rail transit backbone network. The other category is lightweight solutions for resource-constrained scenarios. Some solutions introduce the TOFU (Trust-On-First-Use) first-use trust model from GNU Privacy Guard (GPG), which simplifies the authentication process by caching trust records locally and effectively reduces interaction time.

[0004] In terms of key technologies, the TOFU model avoids the complex certificate chain verification process of traditional PKI systems by using a mechanism to establish trust relationships for the first time, making it particularly suitable for lightweight authentication scenarios in embedded devices. However, the core code of this model is developed based on a foreign open-source framework and natively only supports SHA series hash algorithms and RSA / ECC encryption algorithms, failing to support commercial cryptographic algorithm standards such as SM2, SM3, and SM4 approved by the State Cryptography Administration.

[0005] Meanwhile, China's cryptographic technology has developed rapidly, forming a complete national cryptographic algorithm system. Among them, SM2, based on elliptic curve cryptography, has a shorter key length than RSA at the same security strength; SM3, as a hash algorithm, has stronger collision resistance; and SM4, as a block cipher algorithm, has significant efficiency advantages in hardware implementation. To meet the compliance requirements of critical information infrastructure, the "Regulations on the Administration of Commercial Cryptography" and the "Regulations on the Security Protection of Critical Information Infrastructure" explicitly require key industries such as rail transit to adopt national cryptographic algorithms for security protection.

[0006] However, existing technical solutions face significant challenges in adapting to rail transit scenarios: traditional national cryptographic key management systems are mostly designed for server scenarios and rely on high-performance hardware security modules (HSMs). While these meet compliance requirements, they suffer from large hardware size, high power consumption, and high cost, and are not optimized for the resource constraints of embedded devices. The lightweight TOFU solution, while suitable for resource-constrained environments, suffers from insufficient support for national cryptographic algorithms. This contradiction between compliance and performance severely restricts the widespread application of national cryptographic algorithms in rail transit terminal equipment. Summary of the Invention

[0007] Therefore, it is necessary to provide a key management method and system based on national cryptographic technology to address the aforementioned technical problems.

[0008] The following technical solution is adopted in this specification: This manual provides a key management method based on national cryptographic technology, including: In response to the key generation request of the rail transit equipment, a public key and a corresponding private key of the rail transit equipment are generated using the national cryptographic algorithm, as well as a 32-byte SM3 fingerprint bound to the public key. The public key, the 32-byte SM3 fingerprint and the equipment identifier of the rail transit equipment are bound together to generate a trust record. The trust record includes the public key, the 32-byte SM3 fingerprint, the equipment identifier of the rail transit equipment and the trust level. In response to the key access request from the rail transit equipment, the trust level and 32-byte SM3 fingerprint are retrieved from the trust record based on the equipment identifier of the rail transit equipment, and trust verification is performed. If the trust verification is successful, the public key of the rail transit equipment is obtained from the trust record, and cryptographic operations are performed based on the locally stored private key and the public key of the rail transit equipment to generate a temporary session key; the session key is used for encrypted communication of the rail transit equipment.

[0009] Optionally, a public key and a corresponding private key for the rail transit equipment are generated using a national cryptographic algorithm, including: Call the random number generator to generate a 32-byte random number seed, and use the random number seed as the private key for the rail transit equipment; Based on the key type, the public key is obtained by calling the corresponding national cryptographic algorithm generation function using the private key; If the key type does not support the national cryptographic algorithm, an invalid parameter error code will be returned.

[0010] Optionally, the encryption service includes core tasks and general tasks; different tasks correspond to different key levels; cryptographic operations are performed based on the locally stored private key and the public key of the rail transit equipment to generate a temporary session key, including: A shared key is obtained based on the private key and public key using the national cryptographic SM2 key negotiation algorithm; Using the shared key as the original master key data, a key derivation function based on the SM3 algorithm is called to generate a session key. The inputs to the key derivation function include: the original master key data, the salt value associated with the rail transit equipment, and the key level identifier that identifies the encryption service level.

[0011] Optionally, the session key and private key are stored in fragments using a three-tier storage architecture, which includes a core layer, an auxiliary layer, and a cache layer. The core layer stores one-third fragments of the private key using an AT88SC0104C micro HSM chip, the auxiliary layer stores the encrypted second-third fragments of the private key using a LittleFS encrypted file system, and the cache layer stores trust records and session keys.

[0012] Optionally, the master key is updated every year, and the session key is updated every 7 days; the method further includes: When a fingerprint verification mismatch, device offline for more than 24 hours, or abnormal key operation is detected, a forced update process is immediately triggered, a new key is automatically generated and synchronized to the associated device, and the key information in the TOFU trust record is updated synchronously. The old key is destroyed immediately and cannot be recovered.

[0013] Optionally, the trust levels include: full level, marginal level, and untrusted level; The full level is only accessible to operations and maintenance personnel, who can perform critical operations such as generating, updating, and destroying core keys. The marginal level is accessible to the device itself, which can use session keys for encrypted data transmission but has no key modification privileges. The untrusted level directly rejects all key operations, triggering device isolation and alarms.

[0014] Optionally, the method further includes: After a user performs a key management operation, an audit log is generated and stored in an encrypted manner. The audit log is stored for 90 days and includes the device identifier, operator, operation type, operation time, and operation result. The audit log supports retrieval by device, time, and operation type.

[0015] This specification provides a key management system based on national cryptographic technology, including: The national cryptographic key generation and derivation module is used to respond to the key generation request of rail transit equipment and generate the public key and corresponding private key of rail transit equipment through national cryptographic algorithms. The TOFU trust model adaptation module is used to generate a 32-byte SM3 fingerprint bound to the public key, and bind the public key, the 32-byte SM3 fingerprint, and the equipment identifier of the rail transit equipment to generate a trust record. The trust record includes the public key, the 32-byte SM3 fingerprint, the equipment identifier of the rail transit equipment, and the trust level. The secure distribution and update module is used to respond to key access requests from rail transit equipment. It searches for the trust level and 32-byte SM3 fingerprint from the trust record based on the equipment identifier of the rail transit equipment and performs trust verification. If the trust verification is successful, it obtains the public key of the rail transit equipment from the trust record and performs cryptographic operations based on the private key stored locally and the public key of the rail transit equipment to generate a temporary session key. The session key is used for encrypted communication of the rail transit equipment.

[0016] Optionally, the modules of the system use shared memory to achieve data interaction, and the latency of a single interaction is controlled within 2ms.

[0017] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned key management method based on national cryptographic technology.

[0018] This specification provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the aforementioned key management method based on national cryptographic technology.

[0019] The above-mentioned technical solutions adopted in this specification can achieve the following beneficial effects: The key management method based on Chinese national cryptographic technology provided in this manual simplifies the complex certificate system into a local trust record table and replaces complex digital signature verification with SM3 fingerprints, achieving the effects of "trading space for time" and "trading pre-computation for real-time performance." It eliminates the heavy certificate management burden of traditional PKI systems, completing the most resource-intensive part (certificate verification) in advance, leaving only the most efficient lookup and comparison operations to be performed at runtime, thus achieving rapid authentication in a Chinese national cryptographic environment on embedded devices. While ensuring compliance with Chinese national cryptographic standards, it achieves lightweight and rapid authentication key management suitable for small embedded devices such as vehicle-mounted and rail-side devices. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0021] Figure 1 This specification provides a flowchart illustrating a key management method based on national cryptographic technology. Figure 2 This document provides a schematic diagram of a three-tier storage architecture with fragmented storage. Figure 3 This document provides a trust binding flowchart; Figure 4 This specification provides a timeline diagram of the entire lifecycle of a key in a rail transit scenario. Figure 5 This specification provides a schematic diagram of the overall architecture of a key management system based on national cryptographic technology. Figure 6 This specification provides a schematic diagram of a computer device for implementing a key management method based on national cryptographic technology. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative effort are within the scope of protection of this application.

[0023] Key management in the rail transit sector serves various terminal devices such as onboard terminals (e.g., Train Control and Management System (TCMS)), trackside controllers, and ticketing terminals. It undertakes critical responsibilities including identity authentication, control command encryption, and ticketing data protection, directly impacting train safety and operational stability. Current mainstream technical solutions can be divided into two categories: one is key management systems based on traditional commercial algorithms such as RSA and ECC. These solutions generally rely on third-party certification authorities (CAs) to build a trust system, completing device identity verification through multiple rounds of certificate checks. They are widely used in large servers and control center equipment in the rail transit backbone network, but suffer from complex architecture and long interaction links. The other category is lightweight solutions designed for small embedded devices. Some solutions introduce the GNU PG TOFU first-time trust model, simplifying the authentication process and reducing interaction time by locally caching trust records. However, their core code is bound to foreign algorithms, does not support national cryptographic standards, and cannot meet industry compliance requirements. Existing domestic national cryptographic key management systems are mostly developed for large-scale server scenarios, relying on high-performance hardware security modules (HSMs). While they can adapt to SM2 / SM3 / SM4 national cryptographic algorithms, the hardware is large, power consumption and cost are high, and memory usage and computational latency are not optimized for embedded devices, making them difficult to adapt to resource-constrained scenarios such as on-board and trackside applications. Currently, the rail transit sub-sector has not yet formed an integrated solution of "national cryptographic compliance + lightweight + rapid authentication." On-board and trackside equipment still face the core contradiction of "compliance and performance being mutually exclusive," which seriously restricts the comprehensive implementation of security protection for rail transit terminals.

[0024] Considering the stringent requirements for safety, real-time performance, and stability in rail transit scenarios, existing technical solutions suffer from four key deficiencies, all of which directly impact the secure operation of terminal equipment: First, insufficient compliance. Traditional TOFU solutions rely on non-national cryptographic algorithms to build a trust system, which does not comply with the mandatory national cryptographic adaptation requirements of the "Regulations on the Security Protection of Critical Information Infrastructure" and the "Regulations on the Administration of Commercial Cryptography" for core infrastructure such as rail transit, posing a clear compliance risk. Second, poor lightweight adaptability. Traditional national cryptographic systems employ multi-layered encryption nesting designs to ensure security, typically requiring ≥200MB of memory and having a single authentication operation latency ≥50ms, while vehicle-mounted embedded terminals generally have CPU clock speeds ≤10 GHz. The resource constraints of 0MHz and ≤128MB of memory make it incompatible with this type of solution; third, the authentication efficiency is low. Traditional solutions relying on CA require multiple rounds of network interaction, such as certificate application, verification, and revocation status query, with a single authentication latency of ≥30ms. This is difficult to meet the business requirements of real-time communication between on-board and trackside equipment (control command transmission latency requirement ≤20ms), and may cause control command lag; fourth, the scenario adaptability is weak. Existing solutions have not designed storage and authentication mechanisms for complex working conditions such as outdoor deployment, vibration, and strong electromagnetic interference in rail transit. Key sharding is prone to storage anomalies in vibration environments, and fingerprint verification is susceptible to electromagnetic interference, leading to misjudgments, which directly threatens the safety and stability of train operation.

[0025] From the perspective of adapting the technical essence to the characteristics of rail transit scenarios, the root causes of the above-mentioned defects can be summarized in three points: First, the algorithm is out of touch with the scenario. The core code of the GNU PG TOFU model is a foreign open-source framework that natively only supports SHA series hash algorithms and RSA / ECC encryption algorithms. It does not reserve an extension interface for national cryptographic algorithms, resulting in a lack of underlying technical support for the integration of national cryptographic algorithms and the TOFU rapid authentication model, making it unable to meet the compliance requirements of rail transit. Second, the architecture design is redundant. Traditional national cryptographic systems are designed with large servers as the core target. In pursuit of ultimate security, they adopt redundant designs such as independent CA nodes, multi-layer key encapsulation, and off-site backup. They have not tailored the architecture for the resource constraints of small rail transit devices, resulting in excessive computing and storage overhead, making it difficult to adapt to embedded operating environments. Third, the scenario-based design is lacking. Existing solutions are all general-purpose key management solutions that do not fully consider the characteristics of scenarios such as real-time communication in rail transit, complex outdoor working conditions, and regular maintenance. The authentication process has not been optimized for low latency, and the storage mechanism does not adopt vibration-resistant and electromagnetic interference-resistant designs, resulting in insufficient adaptability of the solution in actual deployment and difficulty in meeting the rigid requirements of driving safety.

[0026] Therefore, how to achieve lightweight and fast authentication key management suitable for small embedded devices such as vehicle-mounted and trackside devices while ensuring compliance with national cryptographic standards has become a technical challenge that urgently needs to be solved in the field of rail transit information security.

[0027] This invention addresses four core pain points in key management for onboard and trackside small devices in the rail transit sub-sector: insufficient compatibility with national cryptographic standards, poor lightweight adaptability, low authentication efficiency, and weak scenario adaptability. It provides a lightweight, fast authentication key management system that fully complies with SM2 / SM3 / SM4 national cryptographic standards, is deeply adapted to the complex operating conditions of rail transit involving vibration, turbulence, and electromagnetic interference, and features low latency (≤20ms per authentication) and low resource consumption (≤50MB memory). This method achieves secure control over the entire lifecycle of key generation, trust binding, distribution, use, update, and destruction through an integrated design. It strictly meets the compliance requirements of the "Regulations on the Security Protection of Critical Information Infrastructure" while adapting to the resource constraints and real-time communication needs of onboard and trackside equipment. Ultimately, it ensures the security of identity authentication for rail transit terminal equipment, the real-time transmission of control commands, and the confidentiality of ticketing data, providing reliable technical support for the terminal security protection of critical information infrastructure in rail transit.

[0028] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0029] Figure 1 This is a flowchart illustrating a key management method based on national cryptographic technology, as described in this specification. The method includes the following steps: S101, in response to the key generation request of the rail transit equipment, generates the public key and corresponding private key of the rail transit equipment through the national cryptographic algorithm, and generates a 32-byte SM3 fingerprint bound to the public key. The public key, the 32-byte SM3 fingerprint and the equipment identifier of the rail transit equipment are bound together to generate a trust record. The trust record includes the public key, the 32-byte SM3 fingerprint, the equipment identifier of the rail transit equipment and the trust level.

[0030] In one embodiment, generating a public key and a corresponding private key for rail transit equipment using a national cryptographic algorithm includes: calling a random number generator to generate a 32-byte random number seed, and using the random number seed as the private key for the rail transit equipment; according to the key type, calling the corresponding national cryptographic algorithm generation function using the private key to obtain the public key; if the key type does not support the national cryptographic algorithm, returning an invalid parameter error code.

[0031] Specifically, the national cryptographic key generation and derivation module implements the steps for generating public keys for national cryptographic algorithms. Developed based on GMSSL 3.0, this module is adapted to the low-power and low-computing-power characteristics of rail transit on-board equipment, strictly adheres to national cryptographic standards, and implements hierarchical key generation and derivation, linked to the TOFU trust model. Specifically: after the on-board / trackside equipment powers on, it first verifies the device hardware fingerprint (to prevent tampering or replacement). Upon successful verification, the key generation process is triggered. The national cryptographic key generation and derivation module calls the `gm_key_generate` interface to generate the SM2 master key and the SM4 initial key. Simultaneously, it binds the device identifier and trust record through the TOFU adaptation module, generates the SM3 fingerprint, and encapsulates complete trust information.

[0032] The system utilizes a CH32V307 chip with built-in HRNG (entropy ≥ 128 bits) to generate SM2 asymmetric key pairs (256 bits) and SM4 symmetric keys (128 bits). This optimizes the key generation process and reduces power consumption (≤ 5mA). The core interface is associated with the rail transit equipment identifier. The main function of this key generation interface is to generate a national cryptographic key based on the specified key type and associate it with the rail transit equipment identifier. Interface input parameters include key type (SM2 or SM4), key pair output pointer, device identifier, TOFU trust status output, and error message output. Internally, the interface first calls a hardware random number generator to generate a 32-byte random number seed. Then, it selects the appropriate national cryptographic algorithm key generation function based on the key type: for SM2 asymmetric keys, it calls the SM2 key generation function; for SM4 symmetric keys, it calls the SM4 key generation function. If the key type is not supported, an invalid parameter error code is set, and failure is returned. After successful key generation, the trust adaptation interface is immediately called to complete the trust binding between the key and the device identifier.

[0033] By optimizing the key generation algorithm, the time for a single key generation is controlled to ≤5ms. It also supports batch generation of key pairs by onboard devices, generating ≤50 SM2 key pairs at a time, with a total batch generation time of ≤200ms. This fully adapts to the networking requirements of multiple terminals on trains (such as TCMS, ticketing terminals, and sensors). The generated key pairs employ a hierarchical management strategy: the master key is used for subkey derivation, and subkeys are allocated to different terminal modules according to their purpose. This ensures hierarchical security of the key system while facilitating unified management by maintenance personnel, avoiding the risk of key misuse.

[0034] Hierarchical Derivation Rules (aligned with rail transit key usage): Encryption services include core tasks and general tasks; different tasks correspond to different key levels; based on SM3-KDF, two levels of subkeys (session keys) are generated: a core key (for onboard control command encryption) and a general key (for ticketing data encryption). Subkeys are associated with the master key trust record and do not require separate authentication. The main function of the core interface is to generate subkeys based on the master key and a specified level, adapting to the key hierarchy requirements of rail transit scenarios. Interface input parameters include the master key, key level (0x01 for the core key and 0x02 for the general key), salt value (device identifier fragment), and subkey output pointer. The internal processing flow of the interface is as follows: First, 32 bytes of raw master key data are derived from the master key expression. Then, a 41-byte key derivation function input buffer is prepared. The first 32 bytes are filled with the master key data, the next 8 bytes are filled with the salt value (device identifier fragment), and the last 1 byte is set as the key level identifier. Finally, the key derivation function based on the SM3 algorithm is called to generate the corresponding subkey.

[0035] Among them, the session key and private key are arranged as follows: Figure 2 The system employs a three-tiered storage architecture for sharded storage, utilizing a "national cryptographic micro HSM + LittleFS + trust cache" three-tier architecture. This architecture is adapted to vehicle vibration and electromagnetic interference conditions, enabling secure sharded key storage and linking with TOFU trust records. The three-tiered storage architecture includes a core layer, an auxiliary layer, and a cache layer. Each layer is specifically designed for complex operating conditions such as rail transit vibration and electromagnetic interference, balancing security, stability, and access efficiency. Specifically: The core layer (top layer) stores one-third of the private key shards using the AT88SC0104C micro HSM chip; the auxiliary layer stores the encrypted second-third of the private key shards using the LittleFS encrypted file system; and the cache layer stores trust records and session keys. Core shards are stored in the micro HSM, backup shards are encrypted and stored in LittleFS, trust records are synchronously written to the cache and local storage, and shard checksums are associated with extended fields of the trust records to ensure consistency between storage and trust logic, with a total processing time of ≤5ms.

[0036] Specifically, the layers are as follows: 1. Core Layer (Top Layer): SM2 private key fragments 1 / 3 and SM4 master key are stored in the AT88SC0104C micro HSM chip. This chip uses industrial-grade packaging and features vibration resistance, electromagnetic interference resistance, and low power consumption (operating power consumption ≤5mA). It can be directly embedded into small on-board and trackside devices. The key fragment splicing requires simultaneous verification of the device hardware fingerprint and TOFUfull trust level. This dual verification ensures the security of the core key and is fully compatible with the bumpy operating environment of on-board devices. 2. Auxiliary Layer (Middle Layer): SM2 private key fragments 2 / 3 are encrypted using the SM4 algorithm and stored in the LittleFS encrypted file system. This file system is designed specifically for embedded devices and has the advantages of power failure resistance, low fragmentation rate, and small memory footprint (≤10MB). The storage path is directly associated with the rail transit equipment identifier ( / gm_key / [trust_id] / sub_key.bin), which facilitates tracing the key storage location by device dimension. At the same time, encrypted storage prevents fragments from being read illegally. 3. Cache layer (bottom layer): TOFU trust records and ordinary business session keys (after decryption) are cached in the device memory. The cache usage is ≤5MB, which will not cause device resource pressure. After the cache expires (72 hours), the latest data is automatically loaded from the auxiliary layer to ensure the validity of the cache. The single cache read latency is ≤3ms, which balances access efficiency and resource control and meets the real-time authentication requirements.

[0037] Sharding storage and retrieval logic: SM2 private key is used for sharding storage, and the verification code is stored in the TOFU extended field. The trust level is verified when the call is made. The core interface is adapted to the storage characteristics of rail transit equipment to ensure that shards are not lost under vibration environment. The code logic is the same as the previous optimized version and fits the working conditions.

[0038] The TOFU trust model adaptation module binds the public key and 32-byte SM3 fingerprint with rail transit equipment to generate a trust record. Specifically, the TOFU trust model adaptation module adopts a "native interface encapsulation + new adaptation interface" scheme to avoid source protocol conflicts and achieve rapid authentication binding of the national cryptographic key with rail transit equipment. The core logic is as follows: Interface adaptation design: Based on the TOFU native interface, the national cryptographic dedicated interface gm_tofu_adapt_key is encapsulated, adding a field associated with rail transit equipment identification (onboard terminal VIN code, trackside equipment number). The interface prototype and logic are adapted to the rail transit equipment identification rules. The main function of this interface is to adapt the national cryptographic key to the TOFU trust model. Its input parameters include the national cryptographic public key (SM2 format), rail transit equipment identification (16 bytes, VIN code or trackside number), TOFU trust status structure (extended equipment type field), and error information output parameters. The interface returns 0 upon successful execution and the corresponding error code upon failure.

[0039] The interface employs a dual mechanism of "algorithm identifier supplementation + data format standardization." First, the input SM2 public key is parsed, the core fields of the public key are extracted, and the alg_id=0x0002 national cryptographic algorithm identifier is added to ensure that the TOFU model can recognize the key type. Then, the rail transit equipment identifier (16-byte fixed length, the last 16 digits of the vehicle VIN code for on-board terminals, and a unique number for trackside equipment) is bound to the public key to generate a unique trust index. The encapsulated tofu_store_key interface is called to store the trust record (including public key, equipment identifier, SM3 fingerprint, and trust level) locally. This not only adapts to the identification rules of on-board and trackside equipment but also ensures the uniqueness and integrity of the trust record, laying the foundation for subsequent rapid authentication.

[0040] Optimized Chinese cryptographic fingerprint generation (SM3 replaces SHA-256): The `gm_tofu_get_fingerprint` function has been rewritten to generate a 32-byte fingerprint using SM3, adapting to the high security requirements of rail transit. The hash calculation logic has also been optimized to reduce CPU usage onboard equipment. The main function is to generate an SM3 fingerprint of the Chinese national cryptographic public key, adapting to the low computing power requirements of onboard equipment. The function's input parameters include the Chinese national cryptographic public key and a fingerprint output buffer, with an output of 32 bytes of fingerprint data. Internally, the function first exports the SM2 public key into its raw data format (containing a 1-byte identifier, 32 bytes of x-coordinate, and 32 bytes of y-coordinate), then calls the SM3 hash function from the GMSSL library to calculate the raw public key data, generating a 32-byte fingerprint output, and setting the fingerprint length parameter to 32.

[0041] To address the issue that TOFU's native cache only supports SHA series fingerprints, the trust cache space has been expanded to 32 bytes, perfectly matching the SM3 fingerprint length. A macro definition (#define SM3_FINGERPRINT_LEN 32) explicitly distinguishes between national cryptographic algorithms and traditional algorithm fingerprints, avoiding storage conflicts. Considering the 72-hour cycle of maintenance and inspection for rail transit equipment, the trust cache validity period is set to 72 hours. Within the cache validity period, device interactions do not require repeated fingerprint generation and trust record binding, significantly reducing redundant authentication overhead and lowering onboard equipment CPU utilization. Furthermore, a periodic backup mechanism is employed for cached data to prevent cache loss due to power outages.

[0042] Trust binding and verification process (adapted to the real-time requirements of rail transit): The initial trust binding process can be completed through Figure 3(TOFU and National Cryptographic Algorithm Adaptation Flowchart) The process is intuitively presented, requiring no third-party CA intervention and significantly reducing binding time: When the onboard terminal and trackside equipment initialize communication, the `gm_tofu_adapt_key` interface is called to synchronously transmit the device identifier (onboard VIN code / trackside equipment number) and the generated SM2 public key to the adaptation module. The module calls the `gm_tofu_get_fingerprint` function to generate a 32-byte SM3 fingerprint, encapsulating it into a complete trust record of "fingerprint + device identifier + initial full trust level," which is synchronously stored in the cache (for fast retrieval) and local storage (for persistent backup). The entire binding and verification process takes ≤10ms, fully meeting the latency requirements for real-time communication between rail transit onboard and trackside equipment. The subsequent trust verification logic during device interaction corresponds to... Figure 3 The parallel process design is as follows: the device queries the local trust cache through a unique identifier. If the fingerprint matches and the trust level is valid (not expired, not marked as abnormal), the identity authentication is passed directly without repeated negotiation. If the fingerprint does not match or the trust level is abnormal, an operation and maintenance alarm is immediately triggered and synchronized to the access control and audit module to record the alarm information. This facilitates operation and maintenance personnel to quickly troubleshoot the fault, which is in line with the business characteristics of rapid fault response and ensuring train operation safety in rail transit.

[0043] S102, in response to the key retrieval request of the rail transit equipment, retrieves the trust level and 32-byte SM3 fingerprint from the trust record based on the equipment identifier of the rail transit equipment, and performs trust verification.

[0044] S103, if the trust verification is successful, the public key of the rail transit equipment is obtained from the trust record, and cryptographic operations are performed based on the locally stored private key and the public key of the rail transit equipment to generate a temporary session key; the session key is used for encrypted communication of the rail transit equipment.

[0045] The secure distribution and update module implements trust verification, key distribution, and key update logic. Based on the SM2 protocol and combined with the "onboard-trackside-control center" topology of rail transit, the secure distribution and update module enables rapid key distribution and dynamic updates without the need for a CA, adapting to real-time communication requirements.

[0046] Encryption services include core tasks and general tasks; different tasks correspond to different key levels.

[0047] In one embodiment, cryptographic operations are performed based on the locally stored private key and the public key of the rail transit equipment to generate a temporary session key, including: obtaining a shared key based on the private key and the public key using the national cryptographic SM2 key negotiation algorithm; using the shared key as the original master key data, calling a key derivation function based on the SM3 algorithm to generate the session key; wherein the input of the key derivation function includes: the original master key data, a salt value related to the rail transit equipment, and a key level identifier that identifies the encryption service level.

[0048] The system employs a two-step approach: "TOFU pre-verification + SM2 negotiation." Distribution latency is ≤20ms, and the session key resides only in memory and is destroyed immediately after use. It adapts to the temporary communication needs of onboard and trackside equipment, with the core interface linked to the rail transit equipment topology. The interface execution process includes three core verification and negotiation steps: First, the trust verification interface is called to query the TOFU trust level corresponding to the target device's identifier. The system verifies the trust status of the target device; if the device's trust level is neither "fully trusted" nor "edge trusted," a trust rejection error code is immediately returned, terminating the key distribution process. Second, if the trust verification passes, the corresponding SM2 public key is retrieved from the trust record based on the target device's identifier. If a valid public key record for the target device cannot be found in the system, a key not found error is returned. Finally, based on successfully obtaining the public keys of both communicating parties, the national cryptographic SM2 key negotiation algorithm is invoked. Cryptographic operations are performed using the local SM2 private key and the rail transit equipment's SM2 public key to negotiate and generate a temporary SM4 session key for subsequent encrypted communication. The entire key distribution process strictly adheres to the pre-verification mechanism, ensuring that only trusted devices can participate in key negotiation.

[0049] Specifically, based on the private and public keys, a raw master key data can be derived from the master key expression. Then, a 41-byte key derivation function input buffer is prepared, the first 32 bytes are filled with the master key data, the next 8 bytes are filled with the salt value (device identification fragment), and the last 1 byte is set as the key level identifier. Finally, the key derivation function based on the SM3 algorithm is called to generate the corresponding 32-byte session key.

[0050] Key Update Mechanism: A differentiated key update strategy is implemented based on the rail transit operation and maintenance cycle and security requirements: the SM2 master key serves as the core key, with an update cycle set to one year, synchronized with the annual equipment maintenance cycle, reducing the impact of frequent updates on operation and maintenance efficiency; the SM4 session key serves as a temporary key, with an update cycle set to seven days, reducing the risk of key leakage. An abnormal update mechanism is also established: when fingerprint verification mismatch, equipment offline for more than 24 hours, or abnormal key operations are detected, a forced update process is immediately triggered, automatically generating a new key and synchronizing it to the associated equipment, synchronously updating the key information in the TOFU trust record, and immediately destroying the old key without recovery, ensuring the dynamic security of the key system and adapting to the high security requirements of rail transit.

[0051] Based on the TOFU trust level-based three-tier permission system, fine-grained control over key operations is achieved. Trust levels include: full, marginal, and untrusted. The full level is only accessible to operations and maintenance personnel (requiring additional verification of the operations and maintenance personnel's ID and password), enabling them to perform critical operations such as core key generation, updating, and destruction. The marginal level is accessible only to the device itself, allowing only the use of session keys for encrypted data transmission, with no key modification permissions. The untrusted level directly rejects all key operations, triggering device isolation and alarms.

[0052] In one embodiment, after the user performs key management operations, an audit log is generated and stored in an encrypted manner. The audit log is encrypted using the SM4 algorithm and has a storage period of 90 days. The audit log includes the device identifier, operator, operation type, operation time, and operation result. The generation time of a single log is ≤1ms, which will not affect the normal operation of the device. At the same time, the audit log supports retrieval by device, by time, and by operation type, adapting to the needs of rail transit safety audit and fault tracing.

[0053] In one embodiment, the present invention also provides a key management method based on national cryptographic technology. This method follows a full lifecycle flow of "key generation → trust binding → distribution → use → update → destruction," with each stage designed around the operational logic of rail transit equipment and precisely corresponding to the attached diagrams, ensuring the technical solution is implementable and verifiable. The core process is as follows (corresponding to...). Figure 4 (Timeline diagram of the entire lifecycle of keys in rail transit scenarios) 1. Key Generation and Trust Binding: After the on-board / railside equipment powers on, the access control module first verifies the device's hardware fingerprint (to prevent tampering or replacement). Upon successful verification, the key generation process is triggered. The key generation module calls the `gm_key_generate` interface to generate the SM2 master key and the SM4 initial key. Simultaneously, the device identifier and trust record are bound through the TOFU adapter module, generating the SM3 fingerprint and encapsulating complete trust information. The keys are stored in fragments according to a three-tier storage architecture.

[0054] 2. Key Distribution: Before establishing a communication link between the vehicle-mounted terminal and the trackside equipment, the distribution module first performs the following steps: Figure 3 The trust verification logic pre-verifies the trust status of the other party. After successful verification, it performs key negotiation based on the SM2 protocol to generate a temporary session key for the encrypted transmission of core information such as control instructions and ticketing data. The distribution log is synchronized to the control center for filing in real time. The entire distribution process takes ≤20ms, which is perfectly in line with the requirements. Figure 4 The timing requirements of the distribution phase must be met to satisfy real-time communication needs.

[0055] 3. Key Usage: When a business requirement triggers a key call (such as control command encryption or data decryption), the access control module first verifies the current subject's permission level. Once permission is granted, the storage module is notified to proceed. Figure 3 The key fragmentation structure reads the key fragments, completes fragment splicing and verification (the key can only be used if the verification code matches), and destroys the key object in memory immediately after the key is used up, thus eliminating the risk of leakage caused by key residue.

[0056] 4. Key Update: Upon reaching the preset update cycle (1 year for SM2 master keys, 7 days for SM4 keys) or upon detecting an anomaly, the update module automatically generates a new key, reusing the trust level corresponding to the old key (no need to rebind trust), and synchronously distributes the new key to associated devices. The old key and its fragments are immediately destroyed and cannot be recovered. The update log is uploaded to the operation and maintenance platform. Figure 4 The update phase logic balances security and operational efficiency.

[0057] 5. Key Destruction: When a device is decommissioned, scrapped, or a key expires and no longer needs to be retained, a full lifecycle cleanup process is triggered. The system deletes key fragments and trust records at all storage levels. The audit module records complete destruction information (including destruction time, operator, and device identifier) ​​to ensure that no key remains throughout its lifecycle, forming a secure closed loop. Figure 4 The design of the destruction phase.

[0058] It should be noted that the scalability of the method provided by this invention is all extended around the rail transit scenario, ensuring the practicality and compatibility of the extended solutions. The following alternative solutions may occur, all of which fall within the protection scope of this invention: 1. Algorithm replacement: The SM2 asymmetric encryption algorithm can be replaced with the SM9 national cryptographic algorithm without changing the overall architecture. Only the algorithm adaptation logic of GMAL needs to be optimized to adapt to high-security scenarios such as rail transit control centers and scheduling platforms, thereby improving the anonymity and anti-attack capabilities of key management. 2. Storage replacement: The micro HSM chip can be replaced with a dedicated Trusted Execution Environment (TEE) for rail transit. It builds a secure storage area based on the terminal hardware isolation characteristics, further improving the resistance to electromagnetic interference and physical tampering, and is suitable for trackside equipment in extreme outdoor working conditions. 3. **Scenario Expansion:** It can be directly adapted to other small devices such as rail transit ticketing terminals, signal controllers, and sensors. Only the device identification rules and key update cycle need to be adjusted. It is compatible with the device interface standards of mainstream manufacturers such as CRRC and CRRC Technology, achieving full scenario coverage. 4. **Function Expansion:** Key backup and recovery functions can be added, connecting to the off-site backup platform of the rail transit control center to improve the disaster recovery capability of the key system and adapt to the operation and maintenance needs of large rail transit lines.

[0059] The core innovations of this invention compared to existing technologies lie in three points, all of which are designed to address key pain points in the rail transit sub-field, thus forming a differentiated technological advantage: 1. Algorithm Integration and Innovation: For the first time, the TOFU fast authentication model is deeply integrated with the SM2 / SM3 / SM4 national cryptographic algorithms, and a lightweight national cryptographic adaptation layer (GMAL) is designed. Without modifying the core code of the TOFU open source framework, it avoids source protocol conflicts and solves the core contradiction between "national cryptographic compliance and real-time authentication" for small rail transit equipment. The authentication latency is ≤20ms, and the performance far exceeds that of traditional solutions. 2. Innovative Architecture Design: It adopts an integrated architecture of "hierarchical derivation + anti-working-condition sharding storage". The hierarchical key design meets the encryption needs of different scenarios. The three-level storage architecture is optimized for the vibration and electromagnetic interference conditions of rail transit. The combination of micro HSM + LittleFS + cache not only ensures key security, but also achieves low power consumption and low memory usage (≤50MB), making it suitable for small embedded devices. 3. Scenario Adaptation Innovation: The key distribution and update mechanism is optimized to fit the star topology of rail transit "vehicle-trackside-control center". No third-party CA intervention is required. The key update cycle is synchronized with the operation and maintenance cycle. At the same time, an abnormal forced update mechanism is established to balance authentication efficiency, operation and maintenance convenience and security, filling the gap in the "national cryptographic + lightweight + fast" key management solution in the rail transit sub-field.

[0060] When applying the key management method based on national cryptographic technology provided in this manual, it is not necessary to follow the instructions. Figure 1 The steps shown are executed in sequence. The specific execution order of each step can be determined as needed, and this manual does not impose any restrictions on it.

[0061] The above are one or more embodiments of the key management method based on national cryptographic technology provided in this specification. Based on the same idea, this specification also provides a corresponding key management system based on national cryptographic technology, such as... Figure 5 As shown.

[0062] Figure 5 This specification provides a schematic diagram of the overall architecture of a key management system based on national cryptographic technology, including: The national cryptographic key generation and derivation module is used to respond to the key generation request of rail transit equipment and generate the public key and corresponding private key of rail transit equipment through national cryptographic algorithms. The TOFU trust model adaptation module is used to generate a 32-byte SM3 fingerprint bound to the public key, and bind the public key, the 32-byte SM3 fingerprint, and the equipment identifier of the rail transit equipment to generate a trust record. The trust record includes the public key, the 32-byte SM3 fingerprint, the equipment identifier of the rail transit equipment, and the trust level. The secure distribution and update module is used to respond to key access requests from rail transit equipment. It searches for the trust level and 32-byte SM3 fingerprint from the trust record based on the equipment identifier of the rail transit equipment and performs trust verification. If the trust verification is successful, it obtains the public key of the rail transit equipment from the trust record and performs cryptographic operations based on the private key stored locally and the public key of the rail transit equipment to generate a temporary session key. The session key is used for encrypted communication of the rail transit equipment.

[0063] This system is designed based on the core requirements of "low computing power, low power consumption, and resistance to complex working conditions" for small-scale rail transit onboard and trackside equipment. The core architecture is reconstructed based on the GNU PG TOFU 2.4.0 open-source framework. A new national cryptographic algorithm adaptation layer (GMAL) is added to achieve seamless integration of national cryptographic algorithms and the TOFU model. The system is divided into five functional modules, each with clear responsibilities and efficient linkage. To meet the real-time communication requirements of rail transit equipment, data interaction between modules is achieved using shared memory (identified as 0x7F000001, accessible only to kernel mode and the current process to prevent unauthorized tampering). The latency of a single interaction is controlled within 2ms, significantly reducing cross-module communication overhead. The linkage logic of each module can be visually visualized through the attached diagram. The specific module division of labor is as follows: 1. TOFU Trust Model Adaptation Module: This module is responsible for interfacing with the TOFU native interface and GMAL, enabling rapid trust binding and verification of national cryptographic keys and rail transit equipment (onboard VIN code, trackside equipment number). The complete interaction process can be found in the attached diagram. Figure 2(TOFU and National Cryptographic Algorithm Adaptation Flowchart); 2. National Cryptographic Key Generation and Derivation Module: The key generation logic is optimized for the low power consumption characteristics of in-vehicle equipment. It uses a national cryptographic certified chip with a built-in random number generator to generate hierarchical keys conforming to national cryptographic standards, adapting to different encryption needs in various scenarios; 3. Lightweight Key Storage Module: Adopting a three-level architecture of "National Cryptographic Micro HSM + LittleFS + Trust Cache," it is specifically designed for vibration and electromagnetic interference conditions, achieving secure storage and efficient retrieval of key fragments. Figure 2 (Diagram of key fragmentation storage structure) Layered design; 4. Secure distribution and update module: Based on the SM2 key negotiation protocol, combined with the star topology of rail transit "onboard-trackside-control center", it realizes rapid key distribution and dynamic update, adapting to... Figure 5 (System Overall Architecture Diagram) Device Interaction Relationships; 5. Access Control and Audit Module: Based on TOFU trust level-based permission division, it achieves fine-grained control over key operations, while recording full-process audit logs, adapting to the needs of rail transit operation and maintenance management and security traceability. Among them, GMAL, as the core adaptation unit, undertakes three major responsibilities: algorithm format conversion, interface encapsulation, and data adaptation. It requires no modification to the core code of the TOFU framework, avoiding source protocol conflicts and achieving the goal of "lightweight transformation." It can perfectly adapt to Linux embedded systems. Its position and data flow in the overall architecture can be determined through... Figure 5 Clearly distinguish between them.

[0064] For specific limitations regarding the key management system based on national cryptographic technologies, please refer to the limitations of the key management method based on national cryptographic technologies mentioned above, which will not be repeated here. Each module in the aforementioned key management system based on national cryptographic technologies can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0065] This specification also provides a computer-readable storage medium storing a computer program that can be used to execute the above-described... Figure 1 The provided key management method is based on Chinese cryptographic technology.

[0066] This instruction manual also provides Figure 6 The schematic diagram of the computer device shown is as follows: Figure 6 At the hardware level, the computer device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to achieve the above-mentioned functions. Figure 1 The provided key management method is based on Chinese cryptographic technology.

[0067] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0068] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. A key management method based on national cryptographic technology, characterized in that, include: In response to the key generation request of the rail transit equipment, a public key and a corresponding private key of the rail transit equipment are generated through the national cryptographic algorithm, and a 32-byte SM3 fingerprint bound to the public key is generated. The public key and the 32-byte SM3 fingerprint are bound to the equipment identifier of the rail transit equipment, and a trust record is generated and stored. Trust records include public keys, 32-byte SM3 fingerprints, equipment identifiers for rail transit equipment, and trust levels. In response to the key access request from the rail transit equipment, the trust level and 32-byte SM3 fingerprint are retrieved from the trust record based on the equipment identifier of the rail transit equipment, and trust verification is performed. If the trust verification is successful, the public key of the rail transit equipment is obtained from the trust record, and cryptographic operations are performed based on the locally stored private key and the public key of the rail transit equipment to generate a temporary session key; the session key is used for encrypted communication of the rail transit equipment.

2. The method according to claim 1, characterized in that, The public key and corresponding private key for rail transit equipment are generated using national cryptographic algorithms, including: Call the random number generator to generate a 32-byte random number seed, and use the random number seed as the private key for the rail transit equipment; Based on the key type, the public key is obtained by calling the corresponding national cryptographic algorithm generation function using the private key; If the key type does not support the national cryptographic algorithm, an invalid parameter error code will be returned.

3. The method according to claim 1, characterized in that, Encryption operations include core tasks and general tasks; different tasks correspond to different key levels; cryptographic operations are performed based on the locally stored private key and the public key of the rail transit equipment to generate temporary session keys, including: Based on the private key and the public key, a shared key is obtained through the national cryptographic SM2 key negotiation algorithm; Using the shared key as the original master key data, a key derivation function based on the SM3 algorithm is called to generate the session key; wherein, the input of the key derivation function includes: the original master key data, the salt value related to the rail transit equipment, and the key level identifier that identifies the encryption service level.

4. The method according to claim 3, characterized in that, The session key and private key are stored in fragments using a three-tier storage architecture, which includes a core layer, an auxiliary layer, and a cache layer. The core layer stores one-third of the private key fragments using an AT88SC0104C micro HSM chip, the auxiliary layer stores the encrypted second-third of the private key fragments using the LittleFS encrypted file system, and the cache layer stores trust records and session keys.

5. The method according to claim 1, characterized in that, The master key is updated every year, and the session key is updated every 7 days; the method further includes: When a fingerprint verification mismatch, device offline for more than 24 hours, or abnormal key operation is detected, a forced update process is immediately triggered, a new key is automatically generated and synchronized to the associated device, and the key information in the TOFU trust record is updated synchronously. The old key is destroyed immediately and cannot be recovered.

6. The method according to claim 1, characterized in that, Trust levels include: full level, marginal level, and untrusted level; The full level is only accessible to operations and maintenance personnel, who can perform critical operations such as generating, updating, and destroying core keys. The marginal level is accessible to the device itself, which can use session keys for encrypted data transmission but has no key modification privileges. The untrusted level directly rejects all key operations, triggering device isolation and alarms.

7. The method according to claim 6, characterized in that, The method further includes: After a user performs a key management operation, an audit log is generated and stored in an encrypted manner. The audit log is stored for 90 days and includes the device identifier, operator, operation type, operation time, and operation result. The audit log supports retrieval by device, time, and operation type.

8. A key management system based on national cryptographic technology, characterized in that, include: The national cryptographic key generation and derivation module is used to respond to the key generation request of rail transit equipment and generate the public key and corresponding private key of rail transit equipment through national cryptographic algorithms. The TOFU trust model adaptation module is used to generate a 32-byte SM3 fingerprint bound to the public key, and bind the public key, the 32-byte SM3 fingerprint, and the equipment identifier of the rail transit equipment to generate and store a trust record. Trust records include public keys, 32-byte SM3 fingerprints, equipment identifiers for rail transit equipment, and trust levels. The secure distribution and update module is used to respond to key call requests from rail transit equipment, and to search for the trust level and 32-byte SM3 fingerprint from the trust record based on the equipment identifier of the rail transit equipment, and to perform trust verification. If the trust verification is successful, the public key of the rail transit equipment is obtained from the trust record, and cryptographic operations are performed based on the locally stored private key and the public key of the rail transit equipment to generate a temporary session key; the session key is used for encrypted communication of the rail transit equipment.

9. The system according to claim 8, characterized in that, The system uses shared memory to achieve data interaction between its modules, and the latency of a single interaction is controlled within 2ms.

Images