Authentication method and device, electronic equipment, storage medium and product

CN115906029BActive Publication Date: 2026-07-21PRANUS BEIJING TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
PRANUS BEIJING TECH CO LTD
Filing Date
2022-11-23
Publication Date
2026-07-21

AI Technical Summary

Technical Problem

In existing technologies, the authentication process of mobile terminals is easily tampered with or modules replaced, leading to authentication failure and making it impossible to effectively manage the authorization of mobile terminals in enterprises and institutions with classified information.

Method used

The system employs a multi-token verification and multi-module authentication approach. The initial authentication module generates the first authentication token, which is then cascaded through several subsequent authentication modules. Each level of authentication module verifies the token sequentially, ensuring the integrity of the authentication process.

Benefits of technology

Even if the authentication interface or module is replaced, it can still effectively prevent bypassing the authentication process and improve the effectiveness and security of authentication.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115906029B_ABST
    Figure CN115906029B_ABST
Patent Text Reader

Abstract

Embodiments of the present application provide an authentication method and device, electronic equipment, storage medium and product, and relate to the technical fields of mobile Internet and authentication. The method comprises: authenticating to-be-authenticated software through a preset initial authentication module, generating a first authentication token if the authentication is successful; authenticating the to-be-authenticated software based on the first authentication token through a plurality of preset continuation authentication modules; wherein the initial authentication module is used to create a token and start an authentication process; the continuation authentication module authenticates based on the authentication process and modifies the token after completing the authentication. Embodiments of the present application solve the technical problem that, in the prior art, when an authentication program is called, a certain authentication process is neglected and tampered with or a related binary module is replaced with a module that has not been completed in the development stage, and the to-be-authenticated software bypasses the authentication and directly enters the main program.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the fields of mobile Internet and authentication, and more specifically, to an authentication method, apparatus, electronic device, storage medium, and product. Background Technology

[0002] With the rapid development of mobile terminal technologies, a business model has emerged that charges fees by licensing customer terminals. However, in scenarios involving classified information and other sensitive situations, mobile terminal manufacturers need to address the issue of licensing and managing these terminals, as their mobile terminals cannot connect to external networks.

[0003] If direct authorization of client terminals via the network is not possible, authorization tools are currently the most common alternative. Legitimate client terminals can use these tools to write their hardware information and signature to a designated authorization partition. The authentication software can then verify the data in this partition to determine the client terminal's legitimacy. However, this method requires the main program of the authentication software to call the authentication interface. If the authentication interface called by the main program is tampered with or the software modules related to the authentication process are replaced, the authentication process can be bypassed, allowing direct access to the authentication software, which could result in significant losses. Summary of the Invention

[0004] This application provides an authentication method, apparatus, electronic device, storage medium, and product to solve the technical problem in the prior art where, when an authentication program is invoked, a certain authentication process is negligently modified or a related binary module is replaced with a module that was not completed during the research and development stage, allowing the authentication software to bypass authentication and directly enter the main program.

[0005] According to one aspect of the embodiments of this application, an authentication method is provided, including:

[0006] The software to be authenticated is authenticated through a preset initial authentication module. If the authentication is successful, a first authentication token is generated.

[0007] The software to be authenticated is authenticated based on the first authentication token through several preset continuation authentication modules.

[0008] The initial authentication module is used to create a token and initiate the authentication process; the continuation authentication module performs authentication based on the authentication process and modifies the token after authentication is completed.

[0009] In one possible implementation, the software to be authenticated is authenticated based on the first authentication token through several preset continuation authentication modules, including:

[0010] Based on the startup process of the software to be authenticated, several continuation authentication modules are guided to perform cascade authentication on the authentication application based on the first authentication token.

[0011] The authentication at each level includes: obtaining the input second authentication token; if the fields of the second authentication token are the same as the preset fields in the current level's continuation authentication module, then the current level authentication is confirmed to be successful and a continuation authentication token for the current level is generated.

[0012] In one possible implementation, if the current level is the first level, then the input second authentication token is the first authentication token; if the current level is not the first level, then the input second authentication token is the relay authentication token generated after the previous level's authentication is successful.

[0013] In one possible implementation, the authentication order of each continuation authentication module is determined according to the time sequence of the startup process instructions of the software to be authenticated, guiding the authentication process of the software to be authenticated to be completed sequentially from the first-level continuation authentication module.

[0014] In one possible implementation, the authentication of the software to be authenticated is performed based on the first authentication token through several preset continuation authentication modules, and further includes:

[0015] Once a re-authentication module successfully authenticates the software to be authenticated, it grants the software the permissions corresponding to the core functions of that re-authentication module.

[0016] In one possible implementation, the token data is generated in one of the following ways:

[0017] Create upper-level file nodes through the kernel interface, and write, modify, and read token data in the file nodes;

[0018] Temporary files are created through the upper-level function interface, and token data is written, modified, and read from the temporary files.

[0019] According to another aspect of the embodiments of this application, an authentication device is provided, comprising:

[0020] The first authentication module is used to authenticate the software to be authenticated through a preset initial authentication module. If the authentication is successful, a first authentication token is generated.

[0021] The second authentication module is used to authenticate the software to be authenticated based on the first authentication token through several preset continuation authentication modules.

[0022] The initial authentication module is used to create a token and start the authentication process; the continuation authentication module performs authentication based on the authentication process and modifies the token after authentication is completed.

[0023] According to another aspect of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method described in the above embodiments.

[0024] According to another aspect of the present application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method described in the above embodiments.

[0025] According to another aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in the above embodiments.

[0026] The beneficial effects of the technical solutions provided in this application are:

[0027] The authentication method provided in this application authenticates the software to be authenticated through a preset initial authentication module. If authentication is successful, a first authentication token is generated. Subsequently, several preset follow-up authentication modules authenticate the software to be authenticated based on the first authentication token. The initial authentication module creates the token and initiates the authentication process; the follow-up authentication modules perform authentication based on the authentication process and modify the token after authentication is completed. This application's solution authenticates the software to be authenticated through multiple token verifications and multi-module authentication. Even if the authentication interface or module is replaced, the software to be authenticated cannot bypass the authentication process through this vulnerability. This effectively prevents authentication failure caused by tampering with the authentication interface or replacement of software modules related to the authentication process, thus improving the effectiveness of authentication. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0029] Figure 1 This is a flowchart illustrating an authorization method.

[0030] Figure 2 A flowchart illustrating an authentication method provided in an embodiment of this application;

[0031] Figure 3 A schematic diagram of a token design provided for one embodiment of this application;

[0032] Figure 4 A schematic diagram of the overall authentication process provided in the embodiments of this application;

[0033] Figure 5 This is a schematic diagram of the structure of an authentication device provided in an embodiment of this application;

[0034] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0035] The embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions of the embodiments of this application.

[0036] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this application mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element establish a connection relationship through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term; for example, “A and / or B” can be implemented as “A,” or as “B,” or as “A and B.”

[0037] To accurately describe the embodiments of this application, "authorization" and "authentication" are explained. Authorization refers to the process by which a legitimate device writes its hardware information and signature to a preset authorization partition through a network, authorization tools, or other means. The essence of authorization is that a legitimate device confirms its legitimate identity. Authentication refers to the authentication process that runs after the authentication software starts, verifying whether the device with the software installed is a legitimately licensed device by comparing the hardware information and signature in the preset authorization partition. Generally, if the information verification matches, authentication is successful, and the authentication software runs normally; if the information verification does not match, authentication fails, the authentication software stops running, and displays a message indicating that a legitimate license has not been obtained.

[0038] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0039] Figure 1 This is a flowchart illustrating an authorization method. It is applicable to... Figure 1 The authorization method shown is illustrated as an example, and the method includes steps S101 to S103.

[0040] S101. Start the authentication main program for verification.

[0041] After the operating system and other software start up, the authentication main program runs first. If the authentication main program finds that the device where the software is located has not been authorized after verification, it will prevent the software from starting normally (often called blocking) and wait for the authorization process to start.

[0042] S102. Prepare for authorization.

[0043] The preparation process includes: inserting the authorizing party's physical key, such as a Ukey, into a personal computer (PC); connecting the terminal device to the PC using a USB cable or Ethernet cable; and installing the authorization tool on the PC, but not limited to this. The Ukey stores information such as the private key and the number of devices to be authorized.

[0044] S103. Start the authorization process and the authorization service program performs the authorization operation.

[0045] The authorization process involves the terminal device initiating an authorization request via an authorization tool. The terminal device sends its unique identifier or other hardware information to the authorization tool, which forwards this to the Ukey. The Ukey records this hardware information and decrements the number of devices that can be authorized by one. The Ukey then signs the hardware information using its private key and returns the signature information to the authorization tool, which forwards the signature information to the terminal device. The terminal device's authorization service program verifies the signature information using a pre-stored public key. If verification is successful, the terminal device's hardware information and signature information are written to a pre-defined authorization partition.

[0046] Figure 2 This is a flowchart illustrating an authentication method provided in an embodiment of this application. The embodiment of this application provides an authentication method, which includes steps S201 to S202.

[0047] S201. The software to be authenticated is authenticated through a preset initial authentication module. If the authentication is successful, a first authentication token is generated.

[0048] The initial authentication module creates a token and initiates the authentication process. Once the authentication process is initiated, the authentication software will begin the authentication process.

[0049] For example, if the initial authentication module successfully authenticates the user, it issues an "authentication success type token" or similar data. The pseudocode for generating the token data is as follows:

[0050]

[0051]

[0052] The pseudocode uses the os_authentication function to implement the authentication process of the initial authentication module. It opens the corresponding file in the preset folder, writes the authentication success token after verification, and closes the file after writing is complete.

[0053] S202. The software to be authenticated is authenticated based on the first authentication token through several preset continuation authentication modules.

[0054] The process involves obtaining a first authentication token and performing authentication based on the authentication process. After authentication is completed, each preset successor authentication module modifies the received token and completes the token transfer until all successor authentication modules have completed the authentication operation for the software.

[0055] The authentication method provided in this application authenticates the software to be authenticated through a preset initial authentication module. If authentication is successful, a first authentication token is generated. Subsequently, several preset follow-up authentication modules authenticate the software to be authenticated based on the first authentication token. The initial authentication module creates the token and initiates the authentication process; the follow-up authentication modules perform authentication based on the authentication process and modify the token after authentication is completed. This application's solution authenticates the software to be authenticated through multiple token verifications and multi-module authentication. Even if the authentication interface or module is replaced, the software to be authenticated cannot bypass the authentication process through this vulnerability. This effectively prevents the authentication interface from being tampered with or the software modules related to the authentication process from being replaced, thus improving the effectiveness of authentication.

[0056] Figure 4 This is a flowchart illustrating an authentication method provided in an embodiment of this application.

[0057] In some embodiments, authentication of the software to be authenticated is performed based on the first authentication token using several preset continuation authentication modules, including:

[0058] Several continuation authentication modules guided by the startup process of operating system and other software perform cascade authentication on the authentication application based on the first authentication token.

[0059] The authentication at each level includes: obtaining the input second authentication token; if the fields of the second authentication token are the same as the preset fields in the current level's continuation authentication module, then the current level authentication is confirmed to be successful and a continuation authentication token for the current level is generated.

[0060] In one optional embodiment, if the current level is the first level, the input second authentication token is the first authentication token; if the current level is not the first level (such as the second level or above), the input second authentication token is the relay authentication token generated after the previous level's authentication is successful.

[0061] In this embodiment, the token is verified by a successive continuation authentication module. Even if a certain level of authentication module is replaced or tampered with, the next level continuation authentication module cannot complete the subsequent authentication operation when verifying the token because there is no token from the previous level. This can prevent the authentication interface from being tampered with or the software modules related to the authentication process from being replaced, thereby improving the effectiveness of authentication and effectively blocking the occurrence of abnormal authentication.

[0062] For example, assuming the first-level continuation authentication module is module A and the second-level continuation authentication module is module B, the pseudocode of the executed authentication procedure is as follows:

[0063] 1) Module A retrieves "authentication success token data" or similar data during startup and modifies the token data.

[0064]

[0065]

[0066] The authentication process of module A is implemented through the A_module_code function. The token file of the corresponding device node is opened in the corresponding folder, and it is verified whether the received token is the first authentication token generated by the initial authentication module. If the verification is successful, the second authentication success information and A token data are written into the first authentication token. After writing is completed, the file is closed.

[0067] 2) When module B boots, it obtains "A token data" or similar data and modifies the token data or directly boots all other modules.

[0068]

[0069] The authentication process of module B is implemented through the B_module_code function. The token file of the corresponding device node is opened in the corresponding folder, and it is verified whether the received token is the A token generated by module A. If the verification is successful, the second authentication success information and B token data are written into the first authentication token. After writing is completed, the file is closed.

[0070] In this embodiment, the combination of the token process name, token status, software version information, etc., is used as the overall token data. Each module verifies the token data according to the set token data format and encrypts the token data.

[0071] Optionally, the token can be encrypted and decrypted using Base64 (a method that uses 64 printable characters to represent binary data).

[0072] For example, a token data information design is as follows: Figure 3As shown, the token data includes: 32 bytes of the process name of the module, 8 bytes of token pass or fail status value, and 64 bytes of software version information, which are encrypted and decrypted using Base64.

[0073] In another optional embodiment, the authentication order of each continuation authentication module is determined according to the time sequence indicated by the software startup process, guiding each continuation authentication module to complete the authentication procedure of the software to be authenticated in sequence, starting from the first-level continuation authentication module.

[0074] In this embodiment, it can be understood that the initial authentication module and the subsequent authentication modules selected according to the startup process of the operating system and other software have a certain order of startup time. The initial authentication module starts first, and then other subsequent authentication modules are started in a predetermined fixed order, with the dependent modules starting first and the dependent modules starting later.

[0075] In another optional embodiment, the authentication of the software to be authenticated is performed based on the first authentication token through several preset continuation authentication modules, and further includes:

[0076] Once any continuation authentication module has successfully authenticated the software to be authenticated, it grants the software the permissions corresponding to the core functions of that module.

[0077] In this embodiment, through the authentication process, while the authentication token is being transmitted, the permissions of the core modules within the software to be authenticated are gradually granted to the user of the software to be authenticated, so that the user can use the software to be authenticated.

[0078] By using multi-token verification and multi-module authentication in the above embodiments to authenticate the software to be authenticated, even if the authentication interface or module is replaced, the software to be authenticated cannot bypass the authentication process through this vulnerability. This can effectively prevent the authentication interface from being tampered with or the software modules related to the authentication process from being replaced, thereby improving the effectiveness of authentication.

[0079] In another embodiment, corresponding to the operating system, the token data is generated in one of the following ways:

[0080] Create upper-level file nodes through the kernel interface, and write, modify, and read token data in the file nodes;

[0081] Temporary files are created through the upper-level function interface, and token data is written, modified, and read from the temporary files.

[0082] In this embodiment, by using kernel technology and / or upper-layer file reading and writing methods, the operating system's authentication interface and multiple core modules of the operating system call the kernel interface to create upper-layer file nodes. By writing, modifying, and reading token data in the file nodes, and by having each module verify the token data before and after, the problem of the operating system bypassing the authentication process due to the authentication interface being blocked is avoided.

[0083] Optionally, "token data" can be generated in the kernel through communication between the upper-level operating system module and the kernel. This can be achieved by adding a virtual device driver to the kernel to create a device node, or by creating a file node in the upper-level operating system module. The upper-level interface can then be provided through the file created by the kernel, allowing the user to write, modify, and read the set token data into and from the corresponding memory space within the kernel.

[0084] The authentication method provided in this application authenticates the software to be authenticated through a preset initial authentication module. If authentication is successful, a first authentication token is generated. Subsequently, several preset follow-up authentication modules authenticate the software to be authenticated based on the first authentication token. The initial authentication module creates the token and initiates the authentication process; the follow-up authentication modules perform authentication based on the authentication process and modify the token after authentication is completed. This application's solution authenticates the software to be authenticated through multiple token verifications and multi-module authentication. Even if the authentication interface or module is replaced, the software to be authenticated cannot bypass the authentication process through this vulnerability. This effectively prevents the authentication interface from being tampered with or the software modules related to the authentication process from being replaced, thus improving the effectiveness of authentication.

[0085] See Figure 5 This is a schematic diagram of an authentication device 300 provided in an embodiment of this application. The authentication device 300 includes:

[0086] The first authentication module 301 is used to authenticate the software to be authenticated through a preset initial authentication module. If the authentication is successful, a first authentication token is generated.

[0087] In some embodiments, the first authentication module 301 includes:

[0088] Several continuation authentication modules guided by the startup process of operating system and other software perform cascade authentication on the authentication application based on the first authentication token.

[0089] The authentication at each level includes: obtaining the input second authentication token; if the fields of the second authentication token are the same as the preset fields in the current level's continuation authentication module, then the current level authentication is confirmed to be successful and a continuation authentication token for the current level is generated.

[0090] If the current level is the first level, then the input second authentication token is the first authentication token; if the current level is not the first level, then the input second authentication token is the relay authentication token generated after the previous level's authentication is successful.

[0091] Once any continuation authentication module has successfully authenticated the software to be authenticated, it grants the software the permissions corresponding to the core functions of that module.

[0092] The second authentication module 302 is used to authenticate the software to be authenticated based on the first authentication token through several preset continuation authentication modules.

[0093] The token data can be generated in one of the following ways:

[0094] Create upper-level file nodes through the kernel interface, and write, modify, and read token data in the file nodes;

[0095] Temporary files are created through the upper-level function interface, and token data is written, modified, and read from the temporary files.

[0096] The initial authentication module is used to create a token and initiate the authentication process; the continuation authentication module performs authentication based on the authentication process and modifies the token after authentication is completed.

[0097] The apparatus in this application embodiment can execute the method provided in this application embodiment, and the implementation principle is similar. The actions performed by each module in the apparatus of each embodiment of this application correspond to the steps in the method of each embodiment of this application. For detailed functional descriptions of each module of the apparatus, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0098] This application provides an electronic device, including a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of the authentication method. Compared with related technologies, it can achieve the following: authentication of the software to be authenticated is performed through multi-token verification and multi-module authentication. Even if the authentication interface or module is replaced, the software to be authenticated cannot bypass the authentication process through this vulnerability. It can effectively prevent the authentication interface from being tampered with or the software modules related to the authentication process from being replaced, thereby improving the effectiveness of authentication.

[0099] In one alternative embodiment, an electronic device is provided, such as Figure 6 As shown, Figure 6The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of this application.

[0100] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0101] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0102] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0103] The memory 4003 stores computer programs that execute embodiments of this application, and its execution is controlled by the processor 4001. The processor 4001 executes the computer programs stored in the memory 4003 to implement the steps shown in the foregoing method embodiments.

[0104] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the steps and corresponding content of the aforementioned method embodiments.

[0105] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0106] The terms "first," "second," "third," "fourth," "1," "2," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the figures or text.

[0107] It should be understood that although arrows indicate various operation steps in the flowcharts of this application's embodiments, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of this application's embodiments, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all steps in each flowchart, based on the actual implementation scenario, may include multiple sub-steps or multiple stages. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and this application's embodiments do not limit this.

[0108] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application without departing from the technical concept of this application also fall within the protection scope of the embodiments of this application.

Claims

1. An authentication method, characterized in that, include: The software to be authenticated is authenticated through the preset initial authentication module. If the authentication is successful, the first authentication token is generated. The software to be authenticated is authenticated based on the first authentication token through several preset continuation authentication modules. The initial authentication module is used to create a token and start the authentication process; the continuation authentication module performs authentication based on the authentication process and modifies the token after authentication is completed. The step of authenticating the software to be authenticated based on the first authentication token through several preset continuation authentication modules includes: Based on the startup process of the software to be authenticated, several continuation authentication modules are guided to perform cascade authentication on the software to be authenticated based on the first authentication token. The authentication at each level includes: obtaining the input second authentication token; if the fields of the second authentication token are the same as the preset fields in the current level's continuation authentication module, then the current level authentication is confirmed to be successful and a continuation authentication token for the current level is generated. The relay authentication token is generated in the following way: The second authentication token is written with information about the successful authentication of the current level and the token data of the current level's continuation authentication module to obtain the relay authentication token.

2. The method according to claim 1, characterized in that, If the current level is the first level, then the input second authentication token is the first authentication token; if the current level is not the first level, then the input second authentication token is the relay authentication token generated after the previous level's authentication is successful.

3. The method according to claim 1, characterized in that, The authentication sequence of each continuation authentication module is determined according to the time sequence indicated by the startup process of the software to be authenticated. The system guides the authentication process of the software to be authenticated to be completed step by step, starting from the first-level continuation authentication module.

4. The method according to claim 1, characterized in that, The step of authenticating the software to be authenticated based on the first authentication token through several preset continuation authentication modules further includes: Once a re-authentication module successfully authenticates the software to be authenticated, it grants the software the permissions corresponding to the core functions of that re-authentication module.

5. The method according to any one of claims 1-4, characterized in that, The token data can be generated in one of the following ways: Create upper-level file nodes through the kernel interface, and write, modify, and read token data in the file nodes; Temporary files are created through the upper-level function interface, and token data is written, modified, and read from the temporary files.

6. An authentication device, characterized in that, include: The first authentication module is used to authenticate the software to be authenticated through the preset initial authentication module. If the authentication is successful, the first authentication token is generated. The second authentication module is used to authenticate the software to be authenticated based on the first authentication token through several preset continuation authentication modules. The initial authentication module is used to create a token and start the authentication process; the continuation authentication module performs authentication based on the authentication process and modifies the token after authentication is completed. The second authentication module is specifically used for: Based on the startup process of the software to be authenticated, several continuation authentication modules are guided to perform cascade authentication on the software to be authenticated based on the first authentication token. The authentication at each level includes: obtaining the input second authentication token; if the fields of the second authentication token are the same as the preset fields in the current level's continuation authentication module, then the current level authentication is confirmed to be successful and a continuation authentication token for the current level is generated. The relay authentication token module is used to write information about the successful authentication of the current level and the token data of the current level's continuation authentication module into the second authentication token to obtain the relay authentication token.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1-5.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-5.