Autonomous operation vehicle supervision terminal identity authentication method

Abstract

The invention discloses an identity authentication method for a supervision terminal of an automatic driving commercial vehicle, which belongs to the field of vehicle supervision, and comprises the steps of deploying a unified password service platform, and calling various password services by a supervision platform so as to support various safety functions. In addition, by supervising terminal device registration, generating a device unified identifier and interacting with a unified password service platform, generation and distribution of a device initial key are realized. According to the method, an equipment SM9 private key acquisition process is introduced, and the secure acquisition of the equipment private key is realized through the generation of an SM2 public and private key pair. Meanwhile, a specific supervision terminal authentication process is provided, and the identity authentication security of the terminal equipment and the unified password service platform is guaranteed through a challenge-response mode. Moreover, the authentication entity relationship and the key updating mechanism are described in detail, and an all-dimensional and multi-level authentication system is constructed.

Description

Technical Field

[0001] This invention belongs to the field of vehicle supervision, and more specifically relates to a method for identity authentication of a monitoring terminal for autonomous driving operating vehicles. Background Technology

[0002] While continuously improving the performance of autonomous driving vehicles, the security of monitoring terminal access and data transmission is equally crucial. Currently, the application of secure cryptography in autonomous driving terminals is not yet perfect, and industry standards for its cryptographic application requirements have not yet been established. As autonomous driving monitoring deepens, a large number of monitoring terminals will be connected to the same monitoring platform, thus necessitating the guarantee of terminal access security. Furthermore, in practical operations, monitoring terminals need to transmit various data generated by autonomous vehicles to the monitoring platform, including vehicle identification, vehicle control mode, vehicle position, vehicle speed, acceleration, environmental perception and response status, and vehicle lighting and signal implementation status. Therefore, authentication of the monitoring terminal and the establishment of a secure data interaction channel are required before communication. Through research on the needs and shortcomings of terminal secure cryptography application technology development, the existing security issues of monitoring terminals mainly include the following aspects:

[0003] (1) Existing vehicle-mounted terminals have poor computing power. The limited computing power and storage resources of the terminals prevent them from adopting complex security mechanisms, security protection protocols, or security encryption algorithms, resulting in generally weak security defense capabilities. Once an attacker successfully controls a monitoring terminal in the monitoring platform, the attacker may impersonate a legitimate terminal to carry out alternating coordinated attacks on both the physical and information sides.

[0004] (2) Security risks of identity authentication when a large number of monitoring terminals access the platform. For example, in some autonomous driving platooning operations, the number of monitoring terminals is relatively large. After the terminals access the monitoring platform, they send authentication information at the same time, which leads to a decrease in service performance. At the same time, in the case of access failure, the monitoring terminals often continue to send requests, increasing the terminal's energy consumption. Therefore, it is necessary to simplify the authentication mechanism accordingly and adopt an efficient and lightweight authentication mechanism to reduce authentication latency and improve the efficiency of high-concurrency authentication.

[0005] (3) The security algorithm does not adopt the national cryptographic algorithm. As cybersecurity has risen to the level of national security, in recent years, relevant national authorities and regulatory agencies have put forward the requirements of promoting the application and implementation of the national cryptographic algorithm and strengthening the security and controllability of the industry from the perspective of national security and long-term strategy. Most of the existing terminal authentication schemes adopt international algorithms such as 3DES, but do not fully adopt the national cryptographic algorithm. With the gradual expansion of the field of automation, independent controllability is an important foundation and requirement in the technical means of supervising terminal security. Therefore, it is necessary to use the national cryptographic algorithm to carry out corresponding security protection for the supervised terminal.

[0006] To address the aforementioned issues in the authentication process of regulatory terminals, most existing terminal authentication methods are based on Public Key Infrastructure (PKI) systems. However, these methods face challenges such as large digital certificate sizes and high bandwidth and power consumption requirements during authentication, making them unsuitable for the authentication needs of a large number of terminals. To reduce the complexity of key management and use in public key systems, Shamir proposed Identity-Based Cryptography (IBC) in 1984. In IBC, the public key is the device or user's identity information, obtainable from uniquely identifiable information. During key generation (KGC), a user's private key is generated based on the user's identity information and sent to the corresponding user through a secure channel. Because the public key is directly calculated from identity information and the identifier is unique, no third-party institution (Certificate Authority, CA) is needed to guarantee the authenticity of the public key. This solves the certificate storage and management problems associated with CA institutions in traditional public key cryptography systems, reducing system communication and storage overhead by simplifying interactions with users or devices.

[0007] my country has consistently promoted the localization of cryptographic technology. In 2008, the State Cryptography Administration issued the SM9 commercial cryptographic algorithm model, laying a solid foundation for the application of identifier-based cryptography in my country. In 2016, the State Cryptography Administration officially released the SM9 cryptographic algorithm standard GM / T 0044-2016. The SM9 algorithm is currently the most widely used and standardized identifier-based cryptographic algorithm in China, and has been adopted as an international standard by the International Organization for Standardization. Because a user's public key is directly calculated from their identity information, the SM9 algorithm has been widely used in areas such as IoT terminal security authentication and secure data communication.

[0008] In summary, to address the challenges of identity authentication for regulatory terminals, on the one hand, an identity-based cryptographic system is adopted to achieve unified authentication of terminal identities. This avoids complex certificate management, reduces terminal computing overhead, and enables lightweight encryption and entity authentication for end-to-platform business data communication. On the other hand, standard national cryptographic algorithms are used to provide functions such as data encryption, data signing, and identity authentication, thereby achieving system security and independent control. Summary of the Invention

[0009] This invention relates to an identity authentication method for monitoring terminals of autonomous driving operating vehicles, including the deployment of a unified cryptographic service platform, registration of monitoring terminal devices, acquisition of the device's SM9 private key, monitoring terminal authentication, authentication entity relationship, and key update. This method utilizes the SM9 identifier issuance cryptographic scheme and the unified cryptographic service platform for secure and effective identity authentication, simplifies certificate management, supports the use of massive numbers of identifiers, improves the scalability of the cryptographic system, and enhances system security. This method provides an effective solution for autonomous driving monitoring.

[0010] To achieve the above objectives, the present invention employs the following technical solution: the method comprises:

[0011] (1) Deployment of a unified cryptographic service platform: By deploying a unified cryptographic service platform, support is provided for the regulatory platform to call various cryptographic services. The unified cryptographic service platform includes cryptographic infrastructure, identification management system and identity authentication system. Based on the SM9 algorithm, an identification cryptographic system is integrated and constructed to provide identification cryptographic services, including a key generation center, a key management center, a registration management center and a log recording center.

[0012] (2) Registration of monitoring terminal equipment: The monitoring equipment sends equipment information to the monitoring platform. The monitoring platform generates a unified identifier for the equipment and sends the registration information to the unified cryptographic service platform. The unified cryptographic service platform generates an initial key for the equipment and sends it to the monitoring equipment. The cryptographic module of the monitoring equipment stores the root key.

[0013] (3) Obtaining the device's SM9 private key: The monitoring device's built-in soft cryptographic module generates an SM2 temporary public-private key pair and performs HMAC calculation using the initial key pair identifier. It then returns the SM2 temporary public key and MAC to the monitoring device. The monitoring device sends an SM9 key request, including the device identifier, the SM2 temporary public key, and the MAC, to the unified cryptographic service platform. After verifying the MAC based on the key corresponding to the identifier, the platform sends the device identifier to the KGC. The KGC generates the SM9 device private key. The platform uses the SM2 temporary public key to encrypt the SM9 device private key and returns it. The monitoring device uses the SM2 temporary private key to decrypt and obtain the SM9 device private key and stores it.

[0014] (4) Supervisory terminal authentication: The supervisory device sends an authentication request to the unified cryptographic service platform. The unified cryptographic service platform responds and generates a random number r1 as a challenge. The built-in soft cryptographic module of the supervisory device uses the SM4 key to decrypt the SM9 device private key through the verification code or password, and generates a random number r2. The SM9 device private key is used to sign r1 and r2 to generate sign1. The supervisory device sends sign1 and device ID to the unified cryptographic service platform. The platform verifies sign1 based on the device ID and uses the SM9 platform private key to sign r2 and device ID to obtain sign2. The platform generates a data protection key and encrypts it with the device public key. Then, it sends sign2, platform ID and encrypted key to the supervisory device. The supervisory device verifies sign2 and decrypts key to achieve two-way authentication.

[0015] (5) Authentication entity relationships, including the two-way authentication relationships between the regulatory terminal and the regulatory platform, the regulatory terminal and the unified cryptographic service platform, and the regulatory platform and the unified cryptographic service platform;

[0016] (6) Key update: The regulatory terminal initiates a key update request to the regulatory platform. The regulatory platform generates a channel protection key to establish a secure channel. The terminal sends terminal identification information. The regulatory platform generates a new initial key based on the identification, encrypts and stores the key update log, and uses the channel protection key to encrypt and protect the new key.

[0017] In one scheme, the unified cryptographic service platform uses the SM9 algorithm to implement the identifier cryptographic service. The key generation center, key management center, registration management center and log recording center work together to eliminate the need for traditional certificate application and exchange, greatly reducing the complexity of the cryptographic system, and can record the complete history of device access and key operations through the log center.

[0018] In one approach, when the monitoring terminal device registers, it submits detailed device information including device name, model, and industry code. The monitoring platform generates a unique device identifier based on the received information and securely sends the identifier and the device's initial key to the monitoring device via encryption. At the same time, the terminal's cryptographic module securely stores the root key to prevent key leakage.

[0019] In one scheme, during the acquisition of the device's SM9 private key, the monitoring device first generates an SM2 temporary public-private key pair using its built-in soft cryptography module, and performs HMAC calculation on the device identifier using the initial key. Then, the device sends a key request containing the SM2 temporary public key, MAC, and device identifier to the unified cryptographic service platform. After verifying the validity of the MAC, the platform ensures that the request comes from a genuine registered device and generates an SM9 device private key that uniquely corresponds to the device identifier through KGC, thereby achieving secure distribution of the private key.

[0020] In one scheme, during the authentication process of the monitoring terminal, the monitoring device uses a password or verification code to trigger the soft password module to decrypt the SM9 private key, and adopts a dual challenge response mechanism of random numbers r1 and r2 during the authentication process, combined with the SM9 private key signature and the platform's two-way signature verification operation.

[0021] In one scheme, during the implementation of the two-way authentication, the data protection key generated by the unified cryptographic service platform is encrypted with the device's public key during transmission. Only the target monitoring device can decrypt and obtain it. At the same time, the platform sends sign2 and the platform identifier ID to the terminal.

[0022] In one scheme, the authentication entity relationship not only includes two-way authentication between the regulatory terminal and the regulatory platform, the regulatory terminal and the unified cryptographic service platform, and the regulatory platform and the unified cryptographic service platform, but also supports the unified cryptographic service platform to manage the identity and key of all entities in the multi-party interaction process.

[0023] In one scheme, during the key update process, the monitoring terminal initiates a key update request to the monitoring platform. The monitoring platform establishes a secure communication channel based on the channel protection key and generates a new initial key based on the identification information sent by the terminal. All logs generated during the key update operation are encrypted and stored, and the new key is sent after being encrypted with the channel protection key, which improves data security and operation traceability during the key update process.

[0024] In one approach, the method is applicable to supporting the dynamic access of various autonomous driving operational vehicle monitoring terminals, and achieves efficient and secure management of terminals at all levels through a unified cryptographic service platform, adapting to the growth in the number of autonomous driving terminals and the evolution of business needs.

[0025] Beneficial effects of this invention:

[0026] (1) This solution combines identifier cryptography technology to avoid the complexity of certificate management in traditional public key infrastructure (PKI), enhances the security and reliability of communication, and provides a solution for deploying identifier cryptography system on cloud cryptography platform.

[0027] (2) Considering the limited resources of vehicle-mounted terminals, this solution focuses on designing a relatively lightweight key management mechanism, which reduces the computing and storage overhead of terminal devices, meets the key security requirements and resource overhead requirements of low-cost cloud computing systems, has lightweight characteristics, and facilitates the development and application of subsequent regulatory terminals.

[0028] (3) This solution uses the monitoring terminal device ID as the public key and distributes exclusive private keys. It does not require pre-registration of digital certificates and authentication, thus achieving trusted identity authentication. It is both secure and easy to use.

[0029] (4) This scheme takes the SM9 algorithm as its core, avoids excessive bilinear pairing operations, reduces computation time and communication interaction overhead, and ensures the security of key generation, distribution and operation. It adopts digital signature technology to ensure that the data will not be modified during transmission and storage. It achieves non-repudiation by verifying the real identity of the supervision terminal and supervision platform through two-way authentication.

[0030] (5) In this scheme, each terminal device can independently own its own key pair and design a key update mechanism, thus avoiding the bottleneck problem of centralized key management.

[0031] (6) This solution focuses on autonomous driving application scenarios, proposes cryptographic application requirements and designs corresponding solutions, deeply integrates cryptographic technology, and uses cryptographic technology to ensure application security. Attached Figure Description

[0032] Figure 1 A diagram illustrating the deployment of a unified cryptographic identification cryptographic service platform;

[0033] Figure 2 Flowchart of the registration process for regulatory terminal equipment;

[0034] Figure 3 Flowchart for obtaining the device's SM9 private key;

[0035] Figure 4 Flowchart of the regulatory terminal certification process;

[0036] Figure 5 For authenticating the entity relationship diagram;

[0037] Figure 6 Flowchart for key update. Detailed Implementation

[0038] To facilitate understanding of the present invention, a more complete description will be given below with reference to the accompanying drawings. Typical embodiments of the invention are shown in the drawings. However, the invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete.

[0039] Unless otherwise defined, all technical and scientific terms used in this invention have the same meaning as understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. To facilitate understanding, the invention will now be described more fully with reference to the accompanying drawings. Typical embodiments of the invention are shown in the drawings. However, the invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to make the disclosure of the invention more thorough and complete.

[0040] This invention designs a lightweight authentication method for the identity of a monitoring terminal for autonomous driving operating vehicles based on Chinese national cryptographic algorithms. Using the SM9 lightweight cryptographic algorithm as its core, and combining it with the terminal device identifier, it achieves access identity authentication for the monitoring terminal during the application phase, ensuring secure terminal cryptographic applications. The main security functions implemented are as follows:

[0041] This invention eliminates the traditional processes of managing, transmitting, and verifying digital certificates, effectively saving network bandwidth and computing resources. It also allows for more flexible management of monitoring terminals and the keys corresponding to terminal identifiers. It achieves multiple security functions, including identity authentication, secure data transmission, encrypted data storage, and data integrity protection, thus constructing a comprehensive security protection system.

[0042] (1) Deployment of the unified cryptographic service platform

[0043] By deploying a unified cryptographic service platform, the regulatory platform can access various cryptographic services to support various security functions. The unified cloud cryptographic service platform supports security protection for all layers of the endpoint, network, and platform, as well as for all functional components and data. The unified cryptographic service platform deploys cryptographic infrastructure, including cloud server cryptographic machines and other cryptographic devices, an identification management system, and an identity authentication system.

[0044] For the identifier management platform, an identifier cryptography system is integrated and built based on the SM9 algorithm to provide identifier cryptography services. It deploys a key generation center, key management center, registration management center, and log recording center. Without the need to apply for and exchange certificates, the complexity of the cryptographic system is greatly reduced. It supports the access of massive numbers of devices and records relevant logs, flexibly supporting the future expansion needs of autonomous driving and realizing terminal device authentication. The platform architecture is as follows: Figure 1 As shown.

[0045] The deployment of a unified cryptographic service platform is the core process for establishing a secure foundation for the entire regulatory system. Its implementation begins with the physical deployment of cryptographic infrastructure. Hardware cryptographic device clusters are deployed in selected high-security data centers or compliant cloud environments. The core is a cloud server cryptographic machine (HSM) that meets national cryptographic standards. These devices constitute the hardware root of trust for cryptographic operations and key storage, ensuring that all critical cryptographic operations are performed within a protected security boundary. Physical deployment must strictly adhere to security compliance requirements, including rack isolation, access control, environmental monitoring, and redundant configuration to ensure continuous service availability. On top of the cryptographic device cluster, a unified cryptographic service middleware platform is built. This platform virtualizes and service-encapsulates the underlying cryptographic resources, providing standardized cryptographic service interfaces (APIs) such as SM2 / SM4 encryption / decryption, SM3 hashing, key generation, and other basic cryptographic functions, as well as more advanced key management services (KMS). The platform's core subsystems, the "Identification Management System" and the "Identity Authentication System," are also integrated and deployed during this stage. The construction of the identifier management system is particularly crucial. It uses the SM9 identifier cryptography algorithm as its engine, completely abandoning the traditional PKI certificate system and instead implementing cryptographic operations based on unique device identifiers. To this end, the system internally deploys a Key Generation Center (KGC), a Key Management Center (KMC), a Registration Management Center (RMC), and a Log Recording Center (LAC). The KGC is the system's trust anchor, holding the master key pair and capable of instantly generating a unique encryption or signing private key for any input valid device identifier ID (such as a pre-planned industry code + unique serial number combination) using the internal characteristics of the SM9 algorithm. The KMC is responsible for managing the symmetric keys (such as the initial key) and session keys used throughout the device's lifecycle, as well as their policies and applications. The RMC acts as the device's "registration book," handling all registered terminal identifier entry, validity verification, status management (activation / deregistration), and maintaining the binding relationship between identifiers and keys, ensuring the global uniqueness and authority of identifiers within the system. LAC is integrated throughout all critical stages, capturing and securely storing KGC private key generation records, KMC key operation audits, RMC registration / change events, and authentication system signature verification logs in real time, providing complete and non-repudiable security audit traceability capabilities.

[0046] The four centers mentioned above work together to form a complete identifier cryptography service system. The service platform's software architecture is designed as a highly cohesive, loosely coupled microservice model, with each service module communicating through an internal secure bus. The service layer abstracts the underlying HSM's secure computing capabilities and the characteristics of the identifier cryptography system into unified, programmable service interfaces, such as "GenerateSM9PrivateKeyById", "VerifyDeviceSignature", and "EncryptWithDevicePubKey", and exposes them to external regulatory platforms and regulatory terminal applications through well-designed RESTful APIs or gRPC interfaces. The platform needs to be configured with highly available load balancers and API gateways to handle concurrent requests from massive numbers of regulatory devices. To support the future massive terminal access volume and elastic expansion needs in the autonomous driving field, the platform adopts a distributed architecture during deployment. The identifier database, key cache, and log storage all need to be designed as horizontally scalable cluster solutions, and multi-site active-active or disaster recovery mechanisms should be considered. Security configuration management is the final critical step in platform deployment. This includes strictly setting hierarchical permissions and multi-factor authentication for platform administrators, configuring network access control policies (allowing only specified IP ranges from the monitoring platform to access specific APIs), enabling two-way certificate authentication or token mechanisms for API calls, setting strong cryptographic algorithm parameters (such as SM9 curve type and master key rotation strategy), ensuring the integrity of sensitive logs and encrypting their storage, and establishing an independent, encrypted management channel between the platform and the monitoring platform. The entire platform deployment process requires rigorous security assessments and penetration testing to ensure the robustness of this core trust infrastructure, providing reliable cryptographic support for upper-layer monitoring terminal authentication, data protection, and other security functions.

[0047] (2) Registration of regulatory terminal equipment

[0048] like Figure 2 The diagram illustrates the registration process for a monitoring terminal device. The monitoring device sends its information, including name, model, and industry code, to the monitoring platform. The monitoring platform generates a unified device identifier and sends the device registration information to the unified cryptographic service platform. The unified cryptographic service platform generates an initial device key and sends this key, along with the assigned device identifier, to the monitoring device. The monitoring device's cryptographic module stores the root key.

[0049] Registration of regulatory terminal devices is a crucial starting point for establishing a system identity trust chain. The entire process begins when the regulatory device (i.e., the terminal mounted on the vehicle) proactively sends its physical attribute information to the regulatory platform upon its first access to the system. This information packet must strictly adhere to predefined format specifications and typically includes a unique name set by the device manufacturer (for manual identification), the device hardware model, and an authoritative industry code uniformly assigned by national or industry management agencies (such as a unique device category code based on a specific classification standard). This information is transmitted to the regulatory platform's backend service cluster in plaintext or basic encryption form via the device's built-in communication module (such as a 4G / 5G CPE or V2X module). Upon receiving this raw device information, the regulatory platform immediately initiates the identifier allocation process: first, it verifies the data's legality (e.g., verifying whether the industry code is in the license database). After successful verification, the system automatically calls its internal identifier generation algorithm (usually based on a combination of timestamps, device feature codes, and random factors to generate a high-strength hash value) to generate a unique and non-repeatable unified device identifier within the system. This identifier is not only used for internal system tracking but also serves as a core index in the cryptographic system. Once the identifier is generated, the regulatory platform immediately sends a device registration request message to the registration management service interface of the unified cryptography service platform through a highly trusted internal security channel (e.g., configured with two-way SSL / TLS and whitelist access). The message contains at least the newly generated unified device identifier, the platform authorization token, and necessary device metadata (such as industry code).

[0050] Upon receiving the request, the Registration Management Center (RMC), a core component of the Unified Cryptography Service Platform, immediately initiates the registration process: First, it verifies the identity and validity of the supervisory platform's authorization token. If verification is successful, it binds the device identifier with the platform identity and records it in the registration database. Next, the Key Management Center (KMC) within the system is triggered to generate a high-strength initial symmetric key for the device (typically a 256-bit SM4 key or an equivalent key). This key is defined as the device's "root key," serving as the foundational seed for all subsequent security operations. After generation, the platform returns a security instruction packet to the supervisory platform's security service agent. This packet contains the initial key (usually encrypted using a transmission master key pre-shared between the cryptography service platform and the supervisory device terminal manufacturer, or the public key of the device's own hardware security module) and the device's Unified Identifier (UID), which has been authenticated by the system's authority. The supervisory platform then forwards this instruction packet to the supervisory device that initiated the registration request. Upon receiving the instruction packet, the dedicated cryptographic module (possibly a hardware-level SE chip or a Trusted Execution Environment (TEE) of equivalent security level) of the monitoring device (such as an in-vehicle T-Box or a dedicated control unit) first decrypts the initial key plaintext through a pre-set security mechanism and immediately stores it securely in the protected key area within the cryptographic module (this area has characteristics such as resistance to physical attacks and unauthorized reading), setting it as the device's root of trust. Simultaneously, the cryptographic module also receives and stores the unified device identifier issued by the platform, thus completing the anchoring of the device's identity within the cryptographic system. All key operations throughout the registration process (including identifier allocation records, key generation timestamps, and device information snapshots) are captured and encrypted in real time by the cryptographic service platform's log recording center, forming an immutable registration audit evidence chain, providing fundamental support for potential subsequent security traceability. This initial key will become the primary credential for the device to obtain its exclusive SM9 private key.

[0051] (3) Obtaining the device's SM9 private key

[0052] like Figure 3The diagram illustrates the process of obtaining the device's SM9 private key. The monitoring device's built-in soft cryptographic module generates an SM2 temporary public-private key pair and performs HMAC calculation using the initial key pair identifier. The built-in soft cryptographic module returns the SM2 temporary public key + MAC to the monitoring device. Upon receiving the SM2 temporary public key and MAC, the monitoring device sends an SM9 key request (including the device identifier, SM2 temporary public key, and MAC value) to the unified cryptographic service platform. The unified cryptographic service platform verifies the device MAC based on the key corresponding to the device identifier and then sends the device identifier to the KGC. The KGC generates an SM9 device private key based on the device identifier ID and returns it to the unified cryptographic service platform. The unified cryptographic service platform encrypts the SM9 device private key using the SM2 temporary public key and returns the encrypted SM9 device private key to the monitoring device. The monitoring device's built-in cryptographic module decrypts the SM2 temporary private key using the SM2 temporary private key to obtain and stores the SM9 device private key.

[0053] After completing initial registration and securely storing the root key (i.e., the initial key), the monitoring terminal device needs to obtain its own SM9 signing private key to support subsequent advanced authentication operations. This crucial process is initiated by a software cryptographic module within the device's built-in secure execution environment (such as a TEE trusted execution environment or a dedicated cryptographic chip). First, this cryptographic module dynamically generates a pair of temporary SM2 asymmetric keys (containing a temporary SM2 private key `tmp_priv` and a corresponding temporary SM2 public key `tmp_pub`) in protected memory space. Then, the module calls the cryptographic computation engine, using the previously securely stored root key (initial key) as the HMAC key, to perform an HMAC-SM3 operation on the device's unified identifier UID (e.g., UID_A00001F8), generating a Message Authentication Code (MAC) value. This MAC is the cryptographic evidence that the device proves it holds a legitimate root key (i.e., its true identity) in this request. The cryptographic module encapsulates the calculated `tmp_pub` and `MAC` values ​​into a data structure and transmits it to the monitoring device's main application through the secure channel of the device's main control program.

[0054] The monitoring device's main program then constructs a structured SM9 key request message. This message must contain three core elements:

[0055] 1. Device Identifier (UID): Serves as the basis for indexing device identity and root key in the unified cryptographic service platform.

[0056] 2. Temporary SM2 public key tmp_pub: Used for subsequent secure reception of SM9 private key.

[0057] 3. MAC value: Serves as proof of the legitimacy of this request.

[0058] The message is sent to the private key service interface of the unified cryptographic service platform via a secure network connection (such as an encrypted channel based on IPSec or DTLS).

[0059] Upon receiving the request, the key service backend of the unified cryptography service platform immediately initiates the processing flow:

[0060] 1. Authentication: Based on the `UID` in the request message, the platform retrieves the root key bound to the device from the Key Management Center (KMC) security database. Using this root key, the platform re-performs the same HMAC-SM3 calculation on the received `UID`, and performs a strict bit-level comparison with the `MAC` value in the request message. If they do not match, the process is immediately terminated and a security event is logged; if they match, the request is confirmed as a legitimate request initiated by a legitimate device.

[0061] 2. SM9 Private Key Generation: The platform sends the verified `UID` to the Core Component Key Generation Center (KGC) via an internal secure service call mechanism. The KGC holds the top-level master key for the entire SM9 system. Upon receiving the `UID`, the KGC's core cryptographic module executes the SM9 signing private key generation algorithm. This algorithm takes the master signing key and the `UID` as input and generates a unique SM9 device signing private key `d_s` corresponding to that `UID` using a specific Key Derivation Function (KDF). This process ensures the repeatability of the private key: the same `UID` always generates the same `d_s`.

[0062] 3. Private Key Protection and Encapsulation: KGC returns the generated `d_s` to the key service backend. The backend uses the temporary SM2 public key tmp_pub received in step 1 to encrypt `d_s` using the SM2 public key encryption algorithm to obtain the encrypted SM9 private key ciphertext `enc_d_s`.

[0063] 4. Response Return: The key service backend encapsulates `enc_d_s` into a response message and returns it to the regulatory device that initiated the request via a secure network connection.

[0064] After receiving the response message, the communication module of the monitoring device forwards it back to the built-in soft cryptographic module:

[0065] 1. Decryption to obtain the private key: The cryptographic module uses its securely stored temporary SM2 private key `tmp_priv` (corresponding to `tmp_pub` in the request) to decrypt the received `enc_d_s`, successfully restoring the plaintext SM9 device signature private key `d_s`.

[0066] 2. Secure Storage: Upon acquiring `d_s`, the cryptographic module immediately writes it to a hardware-level secure storage area (such as the key slot of the SE security chip or the encrypted secure enclave of the TEE). This storage area has protection features against physical probes, unauthorized reading, and substitution attacks. Furthermore, to enhance key security, a configurable policy requires user activation (PIN / biometrics) before signing with `d_s`.

[0067] 3. Key cleanup: After successful decryption, the cryptographic module completely removes all temporary keys (`tmp_priv`, `tmp_pub`) and intermediate variables related to this operation from the secure memory, and only permanently retains the valid `d_s`.

[0068] At this point, the monitoring device has successfully and securely obtained its SM9 signing private key `d_s` based on its globally unique identifier `UID`. This private key will serve as a long-term identity credential for the device in subsequent secure scenarios such as two-way authentication and signing of critical data transmissions. The temporarily generated SM2 key pair only serves this secure key distribution process and is destroyed immediately after distribution, ensuring forward security throughout the entire key acquisition process. The Unified Cryptography Service Platform's Log Recording Center (LAC) will fully record this request, verification, key generation, and return operation, forming an audit evidence chain.

[0069] (4) Regulatory terminal certification

[0070] like Figure 4 The diagram illustrates the authentication process of the monitoring terminal. The monitoring device sends an authentication request to the unified cryptographic service platform. The unified cryptographic service platform responds to the authentication request and generates a random number r1. The unified cryptographic service platform sends the random number r1 to the monitoring device as a challenge. The monitoring device's built-in soft cryptographic module decrypts the SM9 device private key using the SM4 key via a verification code or password, generates a random number r2, and signs r1+r2 using the SM9 device private key to obtain sign1. The monitoring device sends sign1 and its device identifier ID to the unified cryptographic service platform. The unified cryptographic service platform verifies sign1 based on the device identifier ID and signs r2+device identifier ID using the SM9 platform private key to obtain sign2. The unified cryptographic service platform generates a data protection key and encrypts it using the device's public key. The unified cryptographic service platform sends sign2, the platform identifier ID, and the data protection key to the monitoring device. The monitoring platform's built-in soft cryptographic module verifies sign2 based on the platform identifier ID and decrypts the key, completing the two-way authentication.

[0071] The monitoring terminal authentication process is the core security handshake for achieving two-way trusted interaction between the vehicle and the cloud. Its execution begins with the monitoring device (such as the vehicle control unit) initiating an authentication request message to the unified cryptographic service platform's identity authentication service interface. This message must explicitly include the device's unique identifier ID (e.g., UID_A00001F8) to indicate its identity. Upon receiving the request, the unified cryptographic service platform's server immediately initiates a challenge-response mechanism: first, it generates a high-entropy random number `r1` (typically at least 256 bits long, based on a cryptographically secure random number generator), temporarily binds it to the session context, and records it. The platform then sends a challenge-response message containing `r1` to the monitoring device through a secure channel.

[0072] Upon receiving `r1`, the built-in soft password module of the monitoring device (such as in a TEE environment) activates the key usage authorization process:

[0073] 1. Private Key Unsealing: The user needs to enter a preset verification code or biometric password on the device's security interface (this password is used to protect the key encryption key KEK of the stored SM9 device private key `d_s`). The module derives the KEK using the input verification code, and uses the SM4-GCM algorithm to decrypt the ciphertext stored in the secure area, restoring the usable plaintext SM9 device signing private key `d_s`.

[0074] 2. Random number generation and signature: The module independently generates another high-entropy random number `r2` (with the same properties as `r1`), constructs a composite message `r1||r2` (a bit-level concatenation of `r1` and `r2`), and then uses the desealed `d_s` to perform the SM9 signature algorithm (a special signature process based on identifier cryptography) on the composite message to generate the device signature value `sign1`.

[0075] 3. Response Construction: The cryptographic module encapsulates `sign1` and the device identifier ID (UID) and sends it to the unified cryptographic service platform through the device's main program.

[0076] After receiving `sign1` and the device identifier, the authentication service backend of the unified cryptography service platform performs verification:

[0077] 1. Device identification verification:

[0078] Based on the received `identifier ID`, the SM9 algorithm's public key derivation feature (without needing to store a certificate) is used to instantly calculate the corresponding SM9 signature public key `Ppub_s` (this process is completed based on the platform's master signature public key and the identifier).

[0079] The derived `Ppub_s` is used to perform SM9 signature verification on the received composite challenge message `r1||r2` (where `r1` is a platform-generated random number, and `r2` is implicitly contained in `sign1` by the signature, which can only be extracted after successful signature verification). The validity of `sign1` is verified, and message integrity is confirmed (verification of `r1` proves it is the platform's expected challenge response; correct signature of `r2` confirms the device is the legitimate owner).

[0080] 2. Platform signature generation and key preparation: After successful signature verification:

[0081] The platform generates a data protection key (usually a 256-bit symmetric key, such as an SM4 session key).

[0082] The platform uses the SM9 signature master private key (or its derived service private key) held by the platform to perform an SM9 signature operation on the composite message `r2||Device ID`, generating the platform signature value `sign2`.

[0083] Similarly, based on the device's identifier ID, the SM9 encryption public key `Ppub_e` of the device is calculated using the public key derivation feature of the SM9 algorithm.

[0084] Use `Ppub_e` to encrypt the generated `key` with an SM9 public key to obtain the ciphertext `enc_key`.

[0085] 3. Authentication response return: The platform encapsulates `sign2`, the platform's own identifier ID (such as PID_ServicePlatform), and `enc_key` into a response message and sends it back to the monitoring device.

[0086] After receiving the response, the built-in cryptographic module of the monitoring device completes the final authentication:

[0087] 1. Platform identity verification:

[0088] Based on the received platform identifier ID `PID_ServicePlatform`, the SM9 signature public key `SP_pub` corresponding to the platform identifier is calculated using the SM9 public key derivation rules.

[0089] Use `SP_pub` to perform SM9 signature verification on the composite message `r2||Device Identifier ID`. Successful verification of `sign2` confirms that the response indeed comes from a trusted platform and ensures the correctness of `r2` (proving that the response is associated with the request).

[0090] 2. Key decryption and session establishment:

[0091] After successful signature verification, the cryptographic module uses its own securely stored SM9 encryption private key `d_e` (which can be derived from the identifier ID combined with the master encryption private key) to decrypt `enc_key` using SM9, restoring the plaintext data protection session key `key`.

[0092] The key is securely stored and set (within the validity period of this session).

[0093] 3. Key cleanup and state update: The module immediately clears temporary variables and plaintext `d_s` from memory (unless the policy requires continuous suspension) to ensure the secure use of the private key. Two-way authentication between the device and the platform is now complete.

[0094] The session key established through this authentication will be immediately used for end-to-end encryption (such as SM4-CBC / GCM) and integrity protection (such as HMAC-SM3) of subsequent regulatory data transmissions, ensuring secure communication. The cryptographic service platform records the challenge value, signature request, verification result, key generation, and audit identifier throughout the entire process, forming a complete chain of authentication evidence. The entire process integrates certificate-free public and private key management of the identity cryptography system, two-way challenge response to prevent replay attacks, user-assisted private key usage authorization, and secure key distribution mechanisms, providing a reliable foundation of identity trust for regulatory operations.

[0095] (5) Authentication Entity Relationship

[0096] like Figure 5 The diagram illustrates the authentication entity relationships. The monitoring terminal and the monitoring platform form a two-way authentication relationship; the monitoring terminal and the unified cryptographic service platform form a two-way authentication relationship; and the monitoring platform and the unified cryptographic service platform form a two-way authentication relationship.

[0097] The authentication entity relationship in the system is realized as a closed-loop trust chain built between three core entities, and the establishment of each two-way authentication relationship is based on cryptographic operations and process control:

[0098] 1. Direct trust anchoring between the monitoring terminal (vehicle-mounted equipment) and the unified cryptographic service platform

[0099] Throughout the entire device lifecycle, the terminal and the cryptographic platform directly establish two rounds of critical trust handshakes:

[0100] Initial Trust Establishment (Registration Phase): When the terminal is first started, it submits the device's physical credentials (name / model / industry code) to the cryptographic platform through the registration process (see step 2). After the cryptographic platform approves them, it issues an initial root key and a unique device identifier (UID). This process ensures the secure injection of the initial secret through a cryptographic security channel (such as the national cryptographic standard SSL).

[0101] Runtime two-way authentication (key acquisition and business authentication phases):

[0102] Private key acquisition and authentication (step 3): The terminal submits a MAC credential signed by the root key through a dynamically generated temporary SM2 public key. After the cryptographic platform verifies the authenticity of the MAC, it returns the SM9 device private key encrypted with the public key.

[0103] Business layer authentication (step 4): When the terminal initiates a business operation, it achieves two-way identity verification by exchanging random number challenges and SM9 signatures with the cryptographic platform (terminal signature r1||r2, platform signature r2||UID);

[0104] This authentication layer directly uses the public key certificate-free feature of the Identity Cryptosystem (SM9) to avoid PKI certificate chain overhead. At the same time, the terminal needs to dynamically complete the authentication handshake every time it accesses the cryptographic platform service.

[0105] 2. Operational-level trust binding between the monitoring platform and the unified cryptography service platform

[0106] As the central hub of operations, the regulatory platform establishes a strong security link with the cryptographic platform during the system initialization phase:

[0107] Platform Identity Registration: The regulatory platform registers with the cryptographic platform using legal credentials such as organization code / license to obtain a unique platform identifier (PID) and an SM9 platform private key (derived from the cryptographic platform's KGC master key);

[0108] Service call mutual authentication:

[0109] When the regulatory platform needs to call the cryptographic service (such as device registration forwarding, private key generation request), it first performs mutual SM9 signature authentication with the cryptographic platform: the platform sends its own PID signature time-sensitive token, and the cryptographic platform returns a session key encrypted with the service public key after verification;

[0110] Core operations (such as the platform forwarding MAC request in obtaining the device private key) must be performed through a pre-defined whitelisted API interface and accompanied by a platform-level digital signature (such as an SM2 signature). The cryptographic platform will only respond after verifying the signature.

[0111] Key collaborative management: The master key for transmission (used to encrypt data for communication with the terminal) securely stored on the monitoring platform is periodically rotated and encrypted and distributed by the cryptographic platform to ensure the security of key custody.

[0112] 3. Business-level trust transfer between regulatory terminals and regulatory platforms

[0113] At the business execution layer, the terminal and the regulatory platform establish indirect trust by relaying verification information through a cryptographic platform:

[0114] Device authentication translation process: When the terminal initiates a service request to the regulatory platform:

[0115] 1. The monitoring platform triggers the terminal to complete the direct authentication process with the cryptographic platform (step 4);

[0116] 2. The cryptographic platform encrypts the terminal authentication status (success / failure) and the session data key and returns it to the regulatory platform;

[0117] 3. After verifying the response signature, the regulatory platform obtains the `key` authorized for use by the terminal;

[0118] Platform identity terminal verification: When the regulatory platform transmits business data to the terminal:

[0119] Encrypt business data using a session key `key` issued by a cryptographic platform;

[0120] The attached command header (including timestamp) is signed by the monitoring platform using its own SM9 private key;

[0121] The terminal uses the locally stored cryptographic platform signature public key to verify the legitimacy of the supervisory platform's signature and confirm the source of the instruction.

[0122] (6) Key Update

[0123] like Figure 6 The diagram illustrates the key update process. The monitoring terminal initiates a key update request to the monitoring platform. The monitoring platform generates a channel protection key and establishes a secure transmission channel. The monitoring terminal sends its terminal identifier and other information to the monitoring platform, which generates a new initial key based on the identifier. The monitoring platform encrypts and stores the key update log. The monitoring platform then uses the channel protection key to encrypt and protect the new key.

[0124] When performing a key update operation in the monitoring system, the process is initiated by the monitoring terminal (such as an in-vehicle intelligent device). The terminal constructs a key update request message through its security module. This message includes the device's unique identifier, the current key version number, and a time-sensitive digital signature (usually signed using the device's SM9 private key). The terminal then sends the request to the service interface of the monitoring platform via a trusted network link. Upon receiving the request, the monitoring platform first performs a preliminary verification of the terminal's identity and records the operation log. Then, it initiates the key update session process: the platform's built-in cryptographic service module dynamically generates a high-strength temporary session key (e.g., a 256-bit key based on the SM4 algorithm) and derives the terminal's encryption public key using the SM9 identifier cryptographic algorithm based on the terminal's identifier. This public key is used to encrypt the temporary session key to form a protective ciphertext. The ciphertext, along with the platform's identity verification (including the platform identifier and session ID), is then encapsulated in a channel establishment response message and sent to the terminal. This establishes a short-term secure transmission channel based on symmetric encryption between the monitoring platform and the monitoring terminal.

[0125] After receiving the channel response, the monitoring terminal uses its own SM9 private key to decrypt and obtain a temporary session key, confirming that the channel's encryption capability is ready. It then generates detailed data containing complete device information (such as hardware serial number and security chip ID) and the current key hash, and encrypts this data using the temporary session key. The terminal submits the encrypted information along with the device identifier to the monitoring platform. Based on the received device identifier, the monitoring platform's key management system retrieves the original device file from the security database and performs the following operations through its cryptographic calculation engine: using a key derivation function conforming to national cryptographic standards (such as KDF based on SM3), combined with a high-strength random salt value, a device-specific entropy source, and a time factor, it generates a new initial root key (such as a 128-bit SM4 key). This key will replace the old key currently used by the terminal. Before storing the new key, the platform generates a structured log (covering fields such as terminal identifier, timestamp, operator, and key index) for the entire key update operation. The log is then encrypted using the platform's internally stored master encryption key and written to the tamper-proof audit storage area, ensuring that the operation process is traceable and non-repudiable.

[0126] Finally, the monitoring platform uses the previously established temporary session key to encrypt and protect the new initial key, forming the final update instruction package. Simultaneously, it attaches the platform's digital signature to the instruction package (using the platform's SM9 private key to sign the instruction hash) to prove the authenticity of the source and the integrity of the instruction. After this encrypted package is sent to the terminal, the terminal decrypts it using the temporary session key to obtain the new initial key and securely stores it within its hardware security module (HSM or TEE); the terminal simultaneously clears the temporary session key and any remnants of the old key. To verify the successful key update, the terminal sends a confirmation message signed with the new initial key to the monitoring platform. After verification and confirmation, the platform closes the session. At this point, the initial key held by the terminal has completed a secure rotation, and all operations are ensured by end-to-end encrypted transmission and a multi-party signature mechanism, guaranteeing the trustworthiness and confidentiality of the key update process.

[0127] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0128] It should be understood that the above detailed description of the technical solutions of the present invention with reference to preferred embodiments is illustrative and not restrictive. Those skilled in the art can modify the technical solutions described in the embodiments or make equivalent substitutions for some of the technical features based on reading this specification; however, these modifications or substitutions do not cause the essence of the corresponding technical solutions to depart from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for identity authentication of a monitoring terminal for autonomous driving commercial vehicles, characterized in that, The method includes: (1) Deployment of a unified cryptographic service platform: By deploying a unified cryptographic service platform, support is provided for the regulatory platform to call various cryptographic services. The unified cryptographic service platform includes cryptographic infrastructure, identification management system and identity authentication system. Based on the SM9 algorithm, an identification cryptographic system is integrated and constructed to provide identification cryptographic services, including a key generation center, a key management center, a registration management center and a log recording center. (2) Registration of monitoring terminal equipment: The monitoring equipment sends equipment information to the monitoring platform. The monitoring platform generates a unified identifier for the equipment and sends the registration information to the unified cryptographic service platform. The unified cryptographic service platform generates an initial key for the equipment and sends it to the monitoring equipment. The cryptographic module of the monitoring equipment stores the root key. (3) Obtaining the device's SM9 private key: The monitoring device's built-in soft cryptographic module generates an SM2 temporary public-private key pair and performs HMAC calculation using the initial key pair identifier. It then returns the SM2 temporary public key and MAC to the monitoring device. The monitoring device sends an SM9 key request, including the device identifier, the SM2 temporary public key, and the MAC, to the unified cryptographic service platform. After verifying the MAC based on the key corresponding to the identifier, the platform sends the device identifier to the KGC. The KGC generates the SM9 device private key. The platform uses the SM2 temporary public key to encrypt the SM9 device private key and returns it. The monitoring device uses the SM2 temporary private key to decrypt and obtain the SM9 device private key and stores it. (4) Supervisory terminal authentication: The supervisory device sends an authentication request to the unified cryptographic service platform. The unified cryptographic service platform responds and generates a random number r1 as a challenge. The built-in soft cryptographic module of the supervisory device uses the SM4 key to decrypt the SM9 device private key through the verification code or password, and generates a random number r2. The SM9 device private key is used to sign r1 and r2 to generate sign1. The supervisory device sends sign1 and device ID to the unified cryptographic service platform. The platform verifies sign1 based on the device ID and uses the SM9 platform private key to sign r2 and device ID to obtain sign2. The platform generates a data protection key and encrypts it with the device public key. Then, it sends sign2, platform ID and encrypted key to the supervisory device. The supervisory device verifies sign2 and decrypts key to achieve two-way authentication. (5) Authentication entity relationships, including the two-way authentication relationships between the regulatory terminal and the regulatory platform, the regulatory terminal and the unified cryptographic service platform, and the regulatory platform and the unified cryptographic service platform; (6) Key update: The regulatory terminal initiates a key update request to the regulatory platform. The regulatory platform generates a channel protection key to establish a secure channel. The terminal sends terminal identification information. The regulatory platform generates a new initial key based on the identification, encrypts and stores the key update log, and uses the channel protection key to encrypt and protect the new key.

2. The method for identity authentication of a monitoring terminal for autonomous driving operating vehicles according to claim 1, characterized in that, In the unified cryptographic service platform, the identifier management platform uses the SM9 algorithm to implement identifier cryptographic services. The key generation center, key management center, registration management center and log recording center work together to eliminate the need for traditional certificate application and exchange, greatly reducing the complexity of the cryptographic system, and can record the complete history of device access and key operations through the log center.

3. The method for identity authentication of a monitoring terminal for autonomous driving operating vehicles according to claim 1, characterized in that, When the monitoring terminal device registers, it submits detailed device information including device name, model and industry code. The monitoring platform generates a unique device identifier based on the received information and securely sends the identifier and the device's initial key to the monitoring device in an encrypted manner. At the same time, the terminal's cryptographic module securely stores the root key to prevent key leakage.

4. The method for identity authentication of a monitoring terminal for autonomous driving operating vehicles according to claim 1, characterized in that, During the process of obtaining the SM9 private key for the device, the monitoring device first generates an SM2 temporary public-private key pair using its built-in soft cryptography module, and then performs HMAC calculation on the device identifier using the initial key. After that, the device sends a key request containing the SM2 temporary public key, MAC, and device identifier to the unified cryptographic service platform. After verifying the legality of the MAC, the platform ensures that the request comes from a real registered device, and generates an SM9 device private key that uniquely corresponds to the device identifier through KGC, thereby achieving secure distribution of the private key.

5. The method for identity authentication of a monitoring terminal for autonomous driving operating vehicles according to claim 1, characterized in that, During the authentication process of the monitoring terminal, the monitoring device uses a password or verification code to trigger the soft password module to decrypt the SM9 private key. In the authentication process, a dual challenge response mechanism of random numbers r1 and r2 is adopted, combined with the SM9 private key signature and the platform's two-way signature verification operation.

6. The method for identity authentication of a monitoring terminal for autonomous driving operating vehicles according to claim 1, characterized in that, During the implementation of the two-way authentication, the data protection key generated by the unified cryptographic service platform is encrypted with the device's public key during transmission. Only the target monitoring device can decrypt and obtain it. At the same time, the platform sends sign2 and the platform identifier ID to the terminal.

7. The method for identity authentication of a monitoring terminal for autonomous driving operating vehicles according to claim 1, characterized in that, The authentication entity relationship not only includes two-way authentication between the regulatory terminal and the regulatory platform, the regulatory terminal and the unified cryptographic service platform, and the regulatory platform and the unified cryptographic service platform, but also supports the unified cryptographic service platform to manage the identity and key of all entities in the process of multi-party interaction.

8. The method for identity authentication of a monitoring terminal for autonomous driving operating vehicles according to claim 1, characterized in that, During the key update process, the key update request initiated by the monitoring terminal to the monitoring platform is used by the monitoring platform to establish a secure communication channel based on the channel protection key, and generate a new initial key based on the identification information sent by the terminal. All logs generated during the key update operation are encrypted and stored, and the new key is sent after being encrypted with the channel protection key, which improves data security and operation traceability during the key update process.

9. The method for identity authentication of a monitoring terminal for autonomous driving operating vehicles according to claim 1, characterized in that, The method is applicable to supporting dynamic access of various autonomous driving operation vehicle monitoring terminals, and achieves efficient and secure management of terminals at all levels through a unified cryptographic service platform, adapting to the growth in the number of autonomous driving terminals and the evolution of business needs.

Images