A terminal device management and control method based on a public key certificate

Abstract

The present application relates to the technical field of terminal equipment management and control, in particular to a terminal equipment management and control method based on public key certificate, the present application unifies a security model, is based on domestic and foreign general technical standards of security industry, is irrelevant with business rules, and the system is more efficient, unauthorized terminal equipment is rejected in the network protocol kernel level service, in addition, the safety factor is higher, and terminal management and control platform equipment certificate acquisition needs to pass the only path of self-research trusted authentication SDK of the office, and trusted authentication SDK acquisition needs to go through the relevant authorization approval process. The security protection of the kernel level can effectively prevent system infection risk, and finally supports domestic signal creation, which is based on large number decomposition inverse module operation or elliptic curve encryption algorithm, and the present application is not limited, and the signal creation environment can be flexibly selected and customized according to actual business requirements.

Description

Technical Field

[0001] This invention relates to the field of terminal device management and control technology, specifically a terminal device management and control method based on public key certificates. Background Technology

[0002] The current terminal control technology solution mainly focuses on the server side, based on the enterprise's private business rules and commercial protocol design, and is encapsulated and technically implemented at the operating system application level.

[0003] The specific options are as follows:

[0004] 1. Unique Identifier-Based Solution. First, system operators import a unique device identifier (UID) inherent to the trusted terminal and difficult for users to tamper with onto the server side. Alternatively, the system uses a random algorithm combined with user request information to calculate a unique authorization identifier. Then, when the trusted terminal initiates a business request, it carries this unique device identifier, which is transmitted via the internet to the server-side application system. The application system extracts the unique device identifier from the business request and compares it against pre-registered information in the system. If the comparison is successful, the business request is considered trustworthy. If the comparison fails, the system provides a corresponding error message. The advantages of this solution are its ease of implementation and the availability of many mature case studies. The disadvantages are that unique device identifiers are not easy to obtain and vary significantly between manufacturers; the binding between the unique authorization identifier and the terminal device is relatively loose, potentially leading to misuse and theft; application-level business rules are difficult to standardize among enterprises, hindering the formation of industry technical standards; and the implementation of application-level terminal control logic consumes significant resources and carries the potential risk of system-level attacks.

[0005] 2. Solutions based on standardized M2M protocols. For example, YD Company's terminal management technology solution is based on the lightweight M2M protocol LwM2M developed by the OMA (Open Mobile Alliance) international standardization organization. The LwM2M protocol includes three logical entities: the LwM2M server, the LwM2M client, and the LwM2M bootstrap server. The client is used by the terminals to be managed, and the server is used by YD Company's backend terminal management platform for terminal management and device monitoring. The advantages of this solution are good compatibility with international standards and scalability. The completeness of the protocol semantics allows YD Company to further deepen its terminal management technology solution to better meet customer needs in response to market changes. Currently, the terminal management business covers various scenarios such as hardware terminals, terminal software applications, and business data. The disadvantages are that this solution focuses on wireless network mobile communication technology standards such as 2G, 4G, WIFI, NB, and ZigBee. The lightweight M2M protocol has been optimized for network protocols in IoT scenarios, and terminal management is still implemented at the system application level, making it unsuitable for large-scale network attack scenarios.

[0006] 3. Client-Server (CS) based solutions. For example, BXY developed a proprietary client app and terminal management platform based on a proprietary protocol. The terminal management platform only supports network communication for devices customized for the platform. In the managed environment, mobile tablets and business PCs need to register with the platform using BXY's proprietary app and obtain approval from management personnel before they can use limited network resources. The advantage of this solution is its high degree of customization for government scenarios, which can better meet the needs of government clients. The disadvantage is the company's proprietary protocol customization, lacking standardization and ecosystem scalability. Summary of the Invention

[0007] The purpose of this invention is to provide a terminal device management and control method based on public key certificates. This invention is mainly based on a terminal system management and control technology solution at the network protocol kernel layer, which can play a good protective role, especially against the misuse and theft of illegal terminal devices.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a terminal device management method based on public key certificates, comprising the following steps:

[0009] S01: Authenticated terminals initiate HTTPS communication requests to the terminal management platform, while unauthenticated terminals send HTTPS communication requests via the centralized relay service module;

[0010] S02: Authenticated terminals verify the client device certificate of HTTPS communication requests through the terminal management platform; if the certificate is invalid, the terminal is considered an illegal device and access is denied, and the process proceeds to the next step, while unauthenticated terminals forward HTTPS communication requests to the terminal management platform through the centralized relay service module;

[0011] S03: If the certificate verification of an authenticated terminal fails, the terminal management platform returns a verification failure message to the authenticated terminal, while the unauthenticated terminal verifies the client device certificate of the HTTPS communication request of the authenticated terminal through the terminal management platform; if the certificate is invalid, the terminal is considered an illegal device and access is denied, and the process proceeds to the next step.

[0012] S04: Authenticated terminals start an independent process and load the trusted authentication SDK; if an unauthenticated terminal fails to verify its certificate, the terminal management platform returns a verification failure message to the centralized relay service module.

[0013] S05: Authenticated terminals initiate a registration request to the terminal management platform through the trusted authentication SDK, while unauthenticated terminals forward the verification failure message to the unauthenticated device through the centralized relay service module. Because the centralized relay service module has not registered a valid device certificate, the HTTPS communication request forwarding fails.

[0014] S06: Authenticated terminals verify the validity of the trusted authentication SDK request through the terminal management platform to prevent hackers from forging the SDK and stealing legitimate device certificates. The terminal management platform verifies whether the request carries a valid binary signature. If the signature is invalid, the terminal management platform rejects the request immediately. Unauthenticated terminals start an independent process through the centralized relay service module and load the trusted authentication SDK. The trusted authentication SDK is a dedicated device certificate registration SDK for this case. It adopts hard-to-read technology to effectively prevent the SDK from being decompiled and cracked, and adopts binary signature technology to effectively prevent the SDK from being tampered with and forged.

[0015] S07: Certified terminals apply for and purchase CA root certificates from CA certification authorities through the terminal management platform, while uncertified terminals initiate registration requests to the terminal management platform through the trusted authentication SDK;

[0016] S08: Authenticated terminals return CA root certificates to the terminal management platform through the CA certification authority. The terminal management platform caches the CA root certificates in the local secure storage area of ​​the system. Unauthenticated terminals verify the validity of the trusted authentication SDK registration request through the terminal management platform. To prevent hackers from forging SDKs and stealing legitimate device certificates, the terminal management platform verifies whether the request carries a valid binary signature. If the signature is invalid, the terminal management platform rejects the request immediately.

[0017] S09: Certified terminals calculate and issue valid device certificates based on the CA root certificate terminal management platform, while uncertified terminals apply for and purchase CA root certificates from the CA certification authority through the terminal management platform;

[0018] S10: Authenticated terminals send valid device certificates to the trusted authentication SDK through the terminal management platform, while unauthenticated terminals return CA root certificates to the terminal management platform through the CA certification authority. The terminal management platform caches the CA root certificates in the local secure storage area of ​​the system.

[0019] S11: Authenticated terminals send valid device certificates back to other authenticated terminals through the Trusted Authentication SDK. Authenticated terminals cache valid device certificates until they expire or are recalled, while unauthenticated terminals calculate and issue valid device certificates based on the CA root certificate terminal management platform.

[0020] S12: The authenticated terminal initiates an HTTPS communication request to the terminal management platform again, while the unauthenticated terminal sends a valid device certificate back to the trusted authentication SDK through the terminal management platform.

[0021] S13: Authenticated terminals verify the client device certificate of HTTPS communication requests through the terminal management platform. If the device certificate is valid, the communication request is valid and proceeds to the next step. Unauthenticated terminals send a valid device certificate to the centralized relay service module through the trusted authentication SDK. The centralized relay service module caches the valid device certificate until the certificate expires or is recalled.

[0022] S14: Authenticated terminals forward communication requests to the business system cluster through the terminal management platform, while unauthenticated terminals initiate HTTPS communication requests again through the centralized relay service module via unauthenticated devices.

[0023] S15: Authenticated terminals complete routine business processing and return processing results through the business system cluster, while unauthenticated terminals forward HTTPS communication requests to the terminal management platform through the centralized relay service module;

[0024] S16: Authenticated terminals send business processing results back to the terminal management platform through the business system cluster, while unauthenticated terminals verify the client device certificate of the HTTPS communication request of the centralized relay service module through the terminal management platform. If the device certificate is valid, the communication request is valid and proceed to the next step.

[0025] S17: Authenticated terminals send business processing results back to other authenticated terminals through the terminal management platform, while unauthenticated terminals forward communication requests to the business system cluster through the terminal management platform.

[0026] S18: Unauthenticated terminals complete routine business processing and return processing results through the business system cluster;

[0027] S19: Unauthenticated terminals send the business processing results back to the terminal management platform through the business system cluster;

[0028] S20: Unauthenticated terminals forward the business processing results to the centralized relay service module through the terminal management platform;

[0029] S21: Unauthenticated terminals forward the processing results to unauthenticated devices through the centralized relay service module.

[0030] Preferably, in steps 2 and 3, the certificate is generated using domestic and international standard asymmetric encryption algorithms, which are compatible with commercial cryptography and other information technology innovation application scenarios, and the certificate verification uses operating system kernel-level network data packet filtering technology.

[0031] Preferably, in step 4, the trusted authentication SDK is the dedicated device certificate registration SDK for this case. It adopts anti-reading technology to effectively prevent SDK decompilation and cracking, and adopts binary signature technology to effectively prevent SDK tampering and forgery.

[0032] Compared with the prior art, the beneficial effects of the present invention are:

[0033] This invention presents a unified security model based on international and domestic security industry standards, independent of business rules, and offers higher system efficiency. Unauthorized terminal devices are denied service at the network protocol kernel level. Furthermore, it boasts a higher security level; terminal management platform device certificates must be obtained through our self-developed trusted authentication SDK, which requires completing relevant authorization and approval processes. Kernel-level security controls effectively prevent system infection risks. Finally, it supports domestic IT innovation, specifically whether based on large number factorization inverse modular arithmetic or elliptic curve cryptography. This solution is not limited, allowing for flexible selection and customization based on actual business needs in the domestic IT innovation environment. Attached Figure Description

[0034] Figure 1 This is a flowchart of the patent application for this invention;

[0035] Figure 2 This is a sequence diagram of the terminal device management and control process for the patented invention.

[0036] Figure 3 This is a sequence diagram of the uncertified terminal device management process for this invention patent. Detailed Implementation

[0037] The present invention will now be described in more detail by way of examples. These examples are merely illustrative and do not limit the scope of the present invention in any way.

[0038] Example 1:

[0039] First, the authenticated terminal initiates an HTTPS communication request to the terminal management platform, while the unauthenticated terminal sends its own HTTPS communication request via the centralized relay service module. The authenticated terminal verifies the client device certificate of the HTTPS communication request through the terminal management platform. If the certificate is invalid, the terminal is deemed an unauthorized device and access is denied, proceeding to the next step. Meanwhile, the unauthenticated terminal forwards the HTTPS communication request to the terminal management platform via the centralized relay service module. If the certificate verification fails for the authenticated terminal, the terminal management platform returns a verification failure message to the authenticated terminal. The unauthenticated terminal then verifies the client device certificate of the HTTPS communication request from the authenticated terminal through the terminal management platform. If the certificate is invalid, the terminal is deemed an unauthorized device and access is denied, proceeding to the next step. Next, authenticated terminals initiate an independent process and load the trusted authentication SDK. If an unauthenticated terminal fails certificate verification, the terminal management platform returns a verification failure message to the centralized relay service module. Authenticated terminals then initiate a registration request to the terminal management platform via the trusted authentication SDK. Unauthenticated terminals forward the verification failure message to the unauthenticated device via the centralized relay service module. Because the centralized relay service module has not registered a valid device certificate, the HTTPS communication request forwarding fails. Authenticated terminals verify the validity of the trusted authentication SDK request through the terminal management platform to prevent hackers from forging the SDK and stealing legitimate device certificates. The terminal management platform verifies whether the request carries a valid binary signature. If the signature is invalid, the terminal management platform immediately... The request is rejected. Unauthenticated terminals then initiate an independent process through the centralized relay service module and load the trusted authentication SDK. This trusted authentication SDK is a dedicated device certificate registration SDK used in this case. It employs anti-reading technology to effectively prevent SDK decompilation and cracking, and binary signature technology to effectively prevent SDK tampering and forgery. Authenticated terminals apply for and purchase CA root certificates from the CA certification authority through the terminal management platform, while unauthenticated terminals initiate registration requests to the terminal management platform through the trusted authentication SDK. Authenticated terminals return the CA root certificate to the terminal management platform through the CA certification authority. The terminal management platform caches the CA root certificate in the system's local secure storage area, while unauthenticated terminals verify the trusted authentication SDK registration request through the terminal management platform. To prevent hackers from forging SDKs and stealing legitimate device certificates, the endpoint management platform verifies whether the request carries a valid binary signature. If the signature is invalid, the endpoint management platform immediately rejects the request. Authenticated terminals calculate and issue valid device certificates based on the CA root certificate, while unauthenticated terminals apply for and purchase CA root certificates from a CA certification authority through the endpoint management platform. Authenticated terminals send valid device certificates back to the trusted authentication SDK through the endpoint management platform, while unauthenticated terminals return CA root certificates to the endpoint management platform through a CA certification authority. The endpoint management platform caches the CA root certificates in the system's local secure storage area. Authenticated terminals then send valid device certificates back to other authenticated terminals through the trusted authentication SDK.Authenticated terminals cache valid device certificates until they expire or are revoked. Unauthenticated terminals, on the other hand, calculate and issue valid device certificates based on the CA root certificate terminal management platform. Authenticated terminals then initiate HTTPS communication requests to the terminal management platform again, while unauthenticated terminals send valid device certificates back to the trusted authentication SDK through the terminal management platform. Authenticated terminals verify the client device certificate of their HTTPS communication requests through the terminal management platform. If the device certificate is valid, the communication request is valid, and the process proceeds to the next step. Unauthenticated terminals, however, send valid device certificates back to the centralized relay service module through the trusted authentication SDK. The centralized relay service module caches valid device certificates until they expire or are revoked. Authenticated terminals forward communication requests to the business system cluster through the terminal management platform, while unauthenticated terminals initiate HTTPS communication requests again through the centralized relay service module via their unauthenticated devices. Authenticated terminals then complete routine business processing through the business system cluster. The system processes and returns the processing result. Unauthenticated terminals forward HTTPS communication requests to the terminal management platform through the centralized relay service module. Authenticated terminals return business processing results to the terminal management platform through the business system cluster. Unauthenticated terminals verify the client device certificate of the HTTPS communication request from the centralized relay service module through the terminal management platform. If the device certificate is valid, the communication request is valid, and the process proceeds to the next step. Authenticated terminals return business processing results to other authenticated terminals through the terminal management platform. Unauthenticated terminals forward communication requests to the business system cluster through the terminal management platform. Unauthenticated terminals complete routine business processing through the business system cluster and return the processing result. Unauthenticated terminals then return business processing results to the terminal management platform through the business system cluster. Unauthenticated terminals forward business processing results to the centralized relay service module through the terminal management platform. Unauthenticated terminals then forward the processing results to unauthenticated devices through the centralized relay service module.

[0040] Example 2:

[0041] In Example 1, the following steps are added:

[0042] In steps 2 and 3, the certificate is generated using domestic and international standard asymmetric encryption algorithms, which are compatible with commercial cryptography and other information technology innovation application scenarios. The certificate verification uses operating system kernel-level network packet filtering technology.

[0043] In step 4, the trusted authentication SDK is the dedicated device certificate registration SDK for this case. It adopts hard-to-read technology to effectively prevent SDK decompilation and cracking, and adopts binary signature technology to effectively prevent SDK tampering and forgery.

[0044] First, authenticated terminals initiate HTTPS communication requests to the terminal management platform, while unauthenticated terminals send HTTPS communication requests via the centralized relay service module. Authenticated terminals embed a trusted authentication SDK, which, based on our proprietary certificate signature protection technology and digital fingerprint technology, achieves operating system-level anti-tampering and anti-impersonation capabilities. In this solution, only the trusted authentication SDK can communicate encrypted with the terminal management platform and complete registration, effectively protecting against brute-force attacks by unauthorized terminal devices. Authenticated terminals verify the client device certificate of the HTTPS communication request through the terminal management platform; if the certificate is invalid, the terminal is considered an unauthorized device and access is denied, proceeding to the next step. Unauthenticated terminals forward HTTPS communication requests to the terminal management platform via the centralized relay service module. Certificates are generated using domestic and international standard asymmetric encryption algorithms, compatible with commercial cryptography and other information technology application scenarios. Certificate verification employs operating system kernel-level network packet filtering technology. The centralized relay service is primarily used for unauthenticated terminal devices to access the terminal management platform. The system embeds a trusted authentication SDK. For details on the SDK's functions, refer to the detailed description of the previously certified terminals. The terminal management platform module accepts the trusted authentication SDK registration request and completes the verification and registration of the terminal device. After registration, the platform returns a valid device certificate to the terminal. The device certificate can be extended to support national commercial cryptography and other information technology innovation environments. For service requests with attached device certificates, the platform verifies the certificate validity of the communication connection at the network protocol kernel level. If the verification passes, the platform forwards the relay service request to the designated business system. If the verification fails, the platform alarms and returns the corresponding error code information. If a certified terminal's certificate verification fails, the terminal management platform returns a verification failure message to the certified terminal. Uncertified terminals verify the client device certificate of the certified terminal's HTTPS communication request through the terminal management platform. If the certificate is invalid, the terminal is considered an illegal device and access is denied, proceeding to the next step. The certificate is generated using domestic and international standard asymmetric encryption algorithms, compatible with commercial cryptography and other information technology innovation application scenarios. Certificate verification uses operating system kernel-level network packet filtering technology. Certified terminals start an independent process and load the trusted authentication SDK; if an uncertified terminal's certificate verification fails, the terminal management platform returns a verification message to the centralized relay service module. Upon receiving the verification failure message, the trusted authentication SDK, a dedicated device certificate registration SDK for this case, employs anti-reading technology to effectively prevent SDK decompilation and cracking, and uses binary signature technology to effectively prevent SDK tampering and forgery. Authenticated terminals initiate registration requests to the terminal management platform via the trusted authentication SDK, while unauthenticated terminals forward the verification failure message to unauthenticated devices through the centralized relay service module. Because the centralized relay service module has not registered a valid device certificate, the HTTPS communication request forwarding fails. Authenticated terminals verify the validity of the trusted authentication SDK request through the terminal management platform to prevent hackers from forging the SDK and stealing legitimate device certificates. The terminal management platform verifies whether the request carries a valid binary signature.If the signature is invalid, the terminal management platform immediately rejects the request. Unauthenticated terminals then initiate an independent process through the centralized relay service module and load the trusted authentication SDK. This trusted authentication SDK is a dedicated device certificate registration SDK used in this case. It employs anti-reading technology to effectively prevent SDK decompilation and cracking, and binary signature technology to effectively prevent SDK tampering and forgery. Authenticated terminals apply for and purchase CA root certificates from the CA certification authority through the terminal management platform, while unauthenticated terminals initiate registration requests to the terminal management platform through the trusted authentication SDK. Authenticated terminals return the CA root certificate to the terminal management platform through the CA certification authority. The terminal management platform caches the CA root certificate in the system's local secure storage area, while unauthenticated terminals... To verify the validity of the trusted authentication SDK registration request and prevent hackers from forging the SDK and stealing legitimate device certificates, the endpoint management platform verifies whether the request carries a valid binary signature. If the signature is invalid, the endpoint management platform immediately rejects the request. Authenticated terminals calculate and issue valid device certificates based on the CA root certificate, while unauthenticated terminals apply for and purchase CA root certificates from the CA certification authority through the endpoint management platform. Authenticated terminals return valid device certificates to the trusted authentication SDK through the endpoint management platform, while unauthenticated terminals return CA root certificates to the endpoint management platform through the CA certification authority. The endpoint management platform caches the CA root certificates in the system's local secure storage area. Authenticated terminals then use the trusted authentication SDK to send valid device certificates to other terminals. The system returns a valid device certificate. Authenticated terminals cache the valid device certificate until it expires or is revoked. Unauthenticated terminals, on the other hand, calculate and issue a valid device certificate based on the CA root certificate terminal management platform. Authenticated terminals then initiate HTTPS communication requests to the terminal management platform again. Unauthenticated terminals, through the terminal management platform, return a valid device certificate to the trusted authentication SDK. Authenticated terminals verify the client device certificate in their HTTPS communication requests through the terminal management platform. If the device certificate is valid, the communication request is valid, and the process proceeds to the next step. Unauthenticated terminals, through the trusted authentication SDK, return a valid device certificate to the centralized relay service module. The centralized relay service module caches the valid device certificate until it expires or is revoked. Terminals forward communication requests to the business system cluster through the terminal management platform. Unauthenticated terminals initiate HTTPS communication requests again via the centralized relay service module through unauthenticated devices. Authenticated terminals complete routine business processing through the business system cluster and return the processing result. Unauthenticated terminals forward HTTPS communication requests to the terminal management platform through the centralized relay service module. Authenticated terminals send business processing results back to the terminal management platform through the business system cluster. Unauthenticated terminals verify the client device certificate of the HTTPS communication request from the centralized relay service module through the terminal management platform. If the device certificate is valid, the communication request is valid, and the process proceeds to the next step. Authenticated terminals then send business processing results back to the authenticated terminals through the terminal management platform.Unauthenticated terminals forward communication requests to the business system cluster through the terminal management platform. The business system cluster then completes routine business processing and returns the results. The business system cluster then sends the processing results back to the terminal management platform, which in turn forwards them to the centralized relay service module. Finally, the centralized relay service module forwards the processing results to the unauthenticated devices.

[0045] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A terminal device management and control method based on public key certificates, characterized in that: Includes the following steps, Authenticated terminals: S01: Initiate an HTTPS communication request to the terminal management platform; S02: The terminal management platform verifies the client device certificate for HTTPS communication requests; if the certificate is invalid, the terminal is considered an illegal device and access is denied, then proceed to the next step; S03: If certificate verification fails, the terminal management platform returns a verification failure message to the certified terminal; S04: Start an independent process and load the Trusted Authentication SDK. The Trusted Authentication SDK is a dedicated device certificate registration SDK that uses hard-to-read technology and binary signature technology. S05: Initiate a registration request to the endpoint management platform via the trusted authentication SDK; S06: The terminal management platform verifies whether the trusted authentication SDK request is valid to prevent hackers from forging the SDK and stealing legitimate device certificates. The terminal management platform verifies whether the request carries a valid binary signature. If the signature is invalid, the terminal management platform rejects the request immediately. S07: The endpoint management platform applies for and purchases a CA root certificate from a CA certification authority; S08: The CA certification authority returns the CA root certificate to the endpoint management platform, and the endpoint management platform caches the CA root certificate in the system's local secure storage area; S09: The certified terminal calculates and issues a valid device certificate based on the CA root certificate terminal management platform; S10: The terminal management platform sends a valid device certificate back to the trusted authentication SDK; S11: The trusted authentication SDK sends a valid device certificate to the authenticated terminal, and the authenticated terminal caches the valid device certificate until the certificate expires or is recalled; S12: Send another HTTPS communication request to the terminal management platform; S13: The terminal management platform verifies the client device certificate for HTTPS communication requests from authenticated terminals. If the device certificate is valid, the communication request is valid, and the process proceeds to the next step. S14: The terminal management platform forwards communication requests to the business system cluster; S15: The business system cluster completes routine business processing and returns the processing results; S16: The business system cluster sends the business processing results back to the terminal management platform; S17: The terminal management platform sends the business processing results back to the certified terminals; Unauthenticated terminal: SS01: Sends an HTTPS communication request via the centralized relay service module; SS02: Forwards HTTPS communication requests to the terminal management platform via the centralized relay service module; SS03: The terminal management platform verifies the client device certificate for HTTPS communication requests. If the certificate is invalid, the terminal is considered an unauthorized device and access is denied. Proceed to the next step. SS04: If certificate verification fails, the terminal management platform returns a verification failure message to the centralized relay service module; SS05: The centralized relay service module forwards the verification failure message to the unauthenticated terminal because the centralized relay service module has not registered a valid device certificate, and the HTTPS communication request forwarding fails. SS06: The centralized relay service module starts an independent process and loads the trusted authentication SDK. The trusted authentication SDK is a dedicated device certificate registration SDK that uses hard-to-read technology and binary signature technology. SS07: The trusted authentication SDK initiates a registration request to the endpoint management platform; SS08: The terminal management platform verifies whether the trusted authentication SDK registration request is valid. To prevent hackers from forging the SDK and stealing legitimate device certificates, the terminal management platform verifies whether the request carries a valid binary signature. If the signature is invalid, the terminal management platform will reject the request immediately. SS09: The endpoint management platform applies for and purchases a CA root certificate from a CA certification authority; SS10: The CA certification authority returns the CA root certificate to the endpoint management platform, and the endpoint management platform caches the CA root certificate in the system's local secure storage area; SS11: Calculates and issues valid device certificates based on the CA root certificate terminal management platform; SS12: The endpoint management platform sends a valid device certificate back to the trusted authentication SDK; SS13: The Trusted Authentication SDK sends valid device certificates back to the Centralized Relay Service Module, which caches the valid device certificates until they expire or are recalled. SS14: Initiate an HTTPS communication request again via the centralized relay service module; SS15: The centralized relay service module forwards HTTPS communication requests to the terminal management platform; SS16: The terminal management platform verifies the client device certificate for HTTPS communication requests from the centralized relay service module. If the device certificate is valid, the communication request is valid, and the process proceeds to the next step. SS17: The terminal management platform forwards communication requests to the business system cluster; SS18: The business system cluster completes routine business processing and returns the processing results; SS19: The business system cluster sends the business processing results back to the terminal management platform; SS20: The terminal management platform forwards the business processing results to the centralized relay service module; SS21: The centralized relay service module forwards the processing results to unauthenticated terminals.

2. The terminal device management method based on public key certificates according to claim 1, characterized in that: In steps S02 and SS03, the certificate is generated using domestic and international standard asymmetric encryption algorithms, compatible with commercial cryptographic and information-based application scenarios, and the certificate verification uses operating system kernel-level network packet filtering technology.

Images